Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9273 > unrolled thread

code generation for the ternary operator

Back to article view | Back to comp.lang.java.programmer

Contents

  code generation for the ternary operator Roedy Green <see_website@mindprod.com.invalid> - 2011-10-28 06:46 -0700
    Re: code generation for the ternary operator Jaap Droogers <JaapDroogers@unusable.meel.homelinux.net> - 2011-10-28 16:07 +0200
      Re: code generation for the ternary operator markspace <-@.> - 2011-10-28 08:32 -0700
        Re: code generation for the ternary operator Owen Jacobson <angrybaldguy@gmail.com> - 2011-11-01 01:53 -0400
          Re: code generation for the ternary operator Roedy Green <see_website@mindprod.com.invalid> - 2011-11-01 06:25 -0700
            Source code representation (was: code generation for the ternary operator). Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-01 09:41 -0700
              Re: Source code representation Patricia Shanahan <pats@acm.org> - 2011-11-01 13:46 -0700
                Re: Source code representation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-01 16:09 -0700
                Re: Source code representation Roedy Green <see_website@mindprod.com.invalid> - 2011-11-01 23:54 -0700
              Re: Source code representation (was: code generation for the ternary operator). Gene Wirchenko <genew@ocis.net> - 2011-11-01 17:33 -0700
                Re: Source code representation (was: code generation for the ternary operator). Roedy Green <see_website@mindprod.com.invalid> - 2011-11-02 01:19 -0700
                  Re: Source code representation (was: code generation for the ternary operator). Gene Wirchenko <genew@ocis.net> - 2011-11-02 09:42 -0700
                Re: Source code representation (was: code generation for the ternary operator). Lew <lewbloch@gmail.com> - 2011-11-02 07:45 -0700
                Re: Source code representation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-02 10:58 -0700
                  Re: Source code representation Gene Wirchenko <genew@ocis.net> - 2011-11-02 14:11 -0700
                    Re: Source code representation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-02 15:21 -0700
                      Re: Source code representation Gene Wirchenko <genew@ocis.net> - 2011-11-02 16:07 -0700
              Re: Source code representation (was: code generation for the ternary operator). Roedy Green <see_website@mindprod.com.invalid> - 2011-11-01 23:52 -0700
                Re: Source code representation (was: code generation for the ternary operator). Gene Wirchenko <genew@ocis.net> - 2011-11-02 09:47 -0700
                  Re: Source code representation (was: code generation for the ternary operator). Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-02 20:58 +0000
                    Re: Source code representation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-02 15:27 -0700
                      Re: Source code representation Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-02 23:18 +0000
                      Re: Source code representation Lew <lewbloch@gmail.com> - 2011-11-02 17:30 -0700
                  Re: Source code representation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-11-02 15:30 -0700
                    Re: Source code representation Gene Wirchenko <genew@ocis.net> - 2011-11-02 21:30 -0700
                      Re: Source code representation Lew <lewbloch@gmail.com> - 2011-11-02 22:07 -0700
              Re: Source code representation Arne Vajhøj <arne@vajhoej.dk> - 2011-11-05 21:01 -0400
        Re: code generation for the ternary operator Arne Vajhøj <arne@vajhoej.dk> - 2011-11-05 20:56 -0400
      Re: code generation for the ternary operator rossum <rossum48@coldmail.com> - 2011-10-29 13:01 +0100
      Re: code generation for the ternary operator Lew <lewbloch@gmail.com> - 2011-10-29 10:46 -0700
    Re: code generation for the ternary operator Henk van Voorthuijsen <voorth@xs4all.nl> - 2011-10-28 08:05 -0700
      Re: code generation for the ternary operator Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-28 15:41 +0000
    Re: code generation for the ternary operator Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-28 10:31 -0700
      Re: code generation for the ternary operator Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-10-29 03:24 +0200
    Re: code generation for the ternary operator Wanja Gayk <brixomatic@yahoo.com> - 2011-10-29 00:23 +0200
      Re: code generation for the ternary operator Lew <lewbloch@gmail.com> - 2011-10-29 10:50 -0700
        Re: code generation for the ternary operator Wanja Gayk <brixomatic@yahoo.com> - 2011-11-01 13:36 +0100
    Re: code generation for the ternary operator Michal Kleczek <kleku@poczta.onet.pl> - 2011-10-31 17:38 +0100

Page 1 of 2  [1] 2  Next page →

#9273 — code generation for the ternary operator

I wonder if anyone has ever looked at the byte code and/or the hotspot
code generated by code like this:

final int count = lines * 3 + ( b1 ? 2 : 0 ) + ( b2 ? 2 : 0 ) ;

vs:

int count = lines *3;
if ( b1 ) count += 2;
if ( b2 ) count += 2;

I wondered how clever it is.  This is just curiosity. This is not
critical code.

Which style do you prefer?
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [next] | [standalone]

#9274

On 28-10-11 15:46, schreef Roedy Green:
> I wonder if anyone has ever looked at the byte code and/or the hotspot
> code generated by code like this:
>
> final int count = lines * 3 + ( b1 ? 2 : 0 ) + ( b2 ? 2 : 0 ) ;
>
> vs:
>
> int count = lines *3;
> if ( b1 ) count += 2;
> if ( b2 ) count += 2;
>
> I wondered how clever it is.  This is just curiosity. This is not
> critical code.
>
> Which style do you prefer?

The second: clean code!
I don't like  code that I don't understand at the first glance.
Always use curly brackets:

int count = lines *3;
if ( b1 ) {
   count += 2;
}
if ( b2 )  {
   count += 2;
}

Don't try to do the optimizing work for the JIT compiler, she can handle 
it herself very good.

Jaap Droogers

[toc] | [prev] | [next] | [standalone]

#9276

On 10/28/2011 7:07 AM, Jaap Droogers wrote:

> On 28-10-11 15:46, schreef Roedy Green:
>> int count = lines *3;
>> if ( b1 ) count += 2;
>> if ( b2 ) count += 2;

> Always use curly brackets:

I prefer Roedy's version here, it's easier to read.  Never say never, 
and never say always.  You can omit braces when they reduce code 
readability.

[toc] | [prev] | [next] | [standalone]

#9330

On 2011-10-28 15:32:44 +0000, markspace said:

> On 10/28/2011 7:07 AM, Jaap Droogers wrote:
> 
>> On 28-10-11 15:46, schreef Roedy Green:
>>> int count = lines *3;
>>> if ( b1 ) count += 2;
>>> if ( b2 ) count += 2;
> 
>> Always use curly brackets:
> 
> I prefer Roedy's version here, it's easier to read.  Never say never, 
> and never say always.  You can omit braces when they reduce code 
> readability.

Having spent some time in languages with poor IDE support, I'd weaken 
that: you can omit braces, when they reduce code readability, if the 
language or its tools permits easy mechanical reformatting. While the 
Java ecosystem has some good code formatters, not every language is so 
fortunate.

I've come to miss having a machine tell me if my formatting really 
matches my semantics, now that I don't have that on a daily basis.

-o

[toc] | [prev] | [next] | [standalone]

#9338

On Tue, 1 Nov 2011 01:53:32 -0400, Owen Jacobson
<angrybaldguy@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>Having spent some time in languages with poor IDE support, I'd weaken 
>that: you can omit braces, when they reduce code readability, if the 
>language or its tools permits easy mechanical reformatting. While the 
>Java ecosystem has some good code formatters, not every language is so 
>fortunate.

In SCID thinking the brackets are LOGICALLY there, but whether they
are currently VISIBLE, is something you set as an option.  It is
rather egotistical of other programmers to force me to read code their
way. (I am for {} all the time in real code.  I just stripped them
from that example for brevity.)

see http://mindprod.com/project/scid.html

I could imagine some people displaying code with no { } at all, except
perhaps for loop and methods, showing structure purely by indentation.
For scanning code, you want to get hide clutter, perhaps even
arithmetic or other housekeeping.
.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It's difficult to be rigorous about whether a machine really knows,
thinks, etc., because we’re hard put to define these things. 
We understand human mental processes only slightly better than
a fish understands swimming. 
~ John McCarthy (born: 1927-09-04 died: 2011-10-23 at age: 84).
Inventor of the term AI (Artificial Intelligence), 
the short-circuit OR operator (|| in Java), 
and LISP (LIst Processing Language) that makes EMACS 
(Extensible MACro System) so addictive.

[toc] | [prev] | [next] | [standalone]

#9341 — Source code representation (was: code generation for the ternary operator).

On 11/1/11 6:25 AM, Roedy Green wrote:
> On Tue, 1 Nov 2011 01:53:32 -0400, Owen Jacobson
> <angrybaldguy@gmail.com>  wrote, quoted or indirectly quoted someone
> who said :
>
>> Having spent some time in languages with poor IDE support, I'd weaken
>> that: you can omit braces, when they reduce code readability, if the
>> language or its tools permits easy mechanical reformatting. While the
>> Java ecosystem has some good code formatters, not every language is so
>> fortunate.
>
> In SCID thinking the brackets are LOGICALLY there, but whether they
> are currently VISIBLE, is something you set as an option.  It is
> rather egotistical of other programmers to force me to read code their
> way. (I am for {} all the time in real code.  I just stripped them
> from that example for brevity.)
>
> see http://mindprod.com/project/scid.html
>
> I could imagine some people displaying code with no { } at all, except
> perhaps for loop and methods, showing structure purely by indentation.
> For scanning code, you want to get hide clutter, perhaps even
> arithmetic or other housekeeping.
> ..
>
I've often thought about a "new" way of representing code, where the 
logical structure is stored in not-necessarily-human-editable format, 
but the tools for managing the code allow it to be presented in a format 
chosen by the particular maintainer.

In other words, you have the language constructs (classes, methods, 
fields, statements, aspects, loops, etc...) modeled, and then have view 
in front of that model which make them "look" like something that can be 
manipulated easily by the programmer.

I would imagine such a system has a bit of ramp-up time, but it would 
eventually allow you to be much more productive. The "concrete" manor 
that the object model stores things would allow you to refactor very easily.

[toc] | [prev] | [next] | [standalone]

#9346 — Re: Source code representation

On 11/1/2011 9:41 AM, Daniel Pitts wrote:
...
> I've often thought about a "new" way of representing code, where the
> logical structure is stored in not-necessarily-human-editable format,
> but the tools for managing the code allow it to be presented in a format
> chosen by the particular maintainer.
>
> In other words, you have the language constructs (classes, methods,
> fields, statements, aspects, loops, etc...) modeled, and then have view
> in front of that model which make them "look" like something that can be
> manipulated easily by the programmer.
>
> I would imagine such a system has a bit of ramp-up time, but it would
> eventually allow you to be much more productive. The "concrete" manor
> that the object model stores things would allow you to refactor very
> easily.

I think one of the more difficult problems would be adjusting revision
control systems, including diff and merge programs. They would
themselves presumably work on the abstract representation, but have to
present their results in the programmer's view.

Patricia

[toc] | [prev] | [next] | [standalone]

#9347 — Re: Source code representation

On 11/1/11 1:46 PM, Patricia Shanahan wrote:
> On 11/1/2011 9:41 AM, Daniel Pitts wrote:
> ....
>> I've often thought about a "new" way of representing code, where the
>> logical structure is stored in not-necessarily-human-editable format,
>> but the tools for managing the code allow it to be presented in a format
>> chosen by the particular maintainer.
>>
>> In other words, you have the language constructs (classes, methods,
>> fields, statements, aspects, loops, etc...) modeled, and then have view
>> in front of that model which make them "look" like something that can be
>> manipulated easily by the programmer.
>>
>> I would imagine such a system has a bit of ramp-up time, but it would
>> eventually allow you to be much more productive. The "concrete" manor
>> that the object model stores things would allow you to refactor very
>> easily.
>
> I think one of the more difficult problems would be adjusting revision
> control systems, including diff and merge programs. They would
> themselves presumably work on the abstract representation, but have to
> present their results in the programmer's view.
>
> Patricia
I agree, I had thought the exact same thing actually ;-)

[toc] | [prev] | [next] | [standalone]

#9363 — Re: Source code representation

On Tue, 01 Nov 2011 13:46:21 -0700, Patricia Shanahan <pats@acm.org>
wrote, quoted or indirectly quoted someone who said :

>
>I think one of the more difficult problems would be adjusting revision
>control systems, including diff and merge programs. 

Circa 1995  I proposed a new way of doing version control that would
interface with SCIDs that keeps you more up to date on what other
programmers are up to.  See
http://mindprod.com/project/dynamicversioncontrol.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It's difficult to be rigorous about whether a machine really knows,
thinks, etc., because we’re hard put to define these things. 
We understand human mental processes only slightly better than
a fish understands swimming. 
~ John McCarthy (born: 1927-09-04 died: 2011-10-23 at age: 84).
Inventor of the term AI (Artificial Intelligence), 
the short-circuit OR operator (|| in Java), 
and LISP (LIst Processing Language) that makes EMACS 
(Extensible MACro System) so addictive.

[toc] | [prev] | [next] | [standalone]

#9351 — Re: Source code representation (was: code generation for the ternary operator).

On Tue, 01 Nov 2011 09:41:00 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

[snip]

>I've often thought about a "new" way of representing code, where the 
>logical structure is stored in not-necessarily-human-editable format, 
>but the tools for managing the code allow it to be presented in a format 
>chosen by the particular maintainer.

     One problem is whether you can replicate my way.  I like my code
formatted a certain way.  If your tool can not do this, I will not
like using it.  I will avoid it if at all possible.

     Other people feel the same way about their formats.  Miss very
many possibilities, and you will have bad will from [|potential]
users.

     I was wading through the editor settings for Visual Studio and
ended up having to shut off a lot of the formatting, because the
formatting done was not to my taste.

     I was just looking through the editor settings for Dreamweaver.
It does not do what I want.  <sigh>

>In other words, you have the language constructs (classes, methods, 
>fields, statements, aspects, loops, etc...) modeled, and then have view 
>in front of that model which make them "look" like something that can be 
>manipulated easily by the programmer.

     A loop already can be manipulated easily by a competent
programmer.

>I would imagine such a system has a bit of ramp-up time, but it would 
>eventually allow you to be much more productive. The "concrete" manor 
                                                      ^^^^^^^^^^ ^^^^^
     Or it would be a straitjacket.

     I do not understand the captioned words as used.  Should "manor"
be "manner"?

>that the object model stores things would allow you to refactor very easily.

     How would you deal with the case of syntax errors?  I sometimes
have a placeholder.  A simple example would be:
          i=0;
          while (i<SomeValue*****)
             {
             <various looping statements>
             }
The point is that I might not know exactly what the looping condition
has to be.  (In this case, I might be wondering if I will need a flag
for early exit.)  I want to able to enter a placeholder should I need
it.

     VB 6 had a switch for compiling each line as entered.  I did not
like it and disabled it as part of my configuration.  Sometimes, in
mid-line, I would note that I had to change something else.  When the
option was enabled, I would move off the line and often get a syntax
error.  I knew that.  I prefer to be told about compilation errors
when I ask, not to be interrupted by an overeager compiler.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9365 — Re: Source code representation (was: code generation for the ternary operator).

On Tue, 01 Nov 2011 17:33:07 -0700, Gene Wirchenko <genew@ocis.net>
wrote, quoted or indirectly quoted someone who said :

>     One problem is whether you can replicate my way.  I like my code
>formatted a certain way.  If your tool can not do this, I will not
>like using it.  I will avoid it if at all possible.

I have three problems with that way of thinking.

1. if you are in a team environment, you have to use a common tidier
to avoid false deltas.  You can tidy it to whatever you want to edit,
but you must tidy it back to corporate standard before checkin.  You
can't expect others to follow your formatting rules not part of what
the corporate formatter does.  I worked in a place before the days of
formatters and each programmer thought he "owned" some of the code and
formatted it in a unique way, and fights broke out over variations.
Part of the problem came because some programmers had big screen and
others tiny ones.  The big screen programmers wanted long lines, the
others short.

2. Surely you would not reject an IDE just because its formatter did
not do precisely what you wanted.  So why reject a SCID? You would
export code for presentation to some formatter of your own that did
the touch-ups. Surely in an IDE you would not maintain your coding
conventions manually. Would you?

3. that is only one factor. The SCID would give you overwhelming
advantages to compensate for that loss, which is aesthetic, not so
much productive.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [next] | [standalone]

#9377 — Re: Source code representation (was: code generation for the ternary operator).

On Wed, 02 Nov 2011 01:19:08 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

>On Tue, 01 Nov 2011 17:33:07 -0700, Gene Wirchenko <genew@ocis.net>
>wrote, quoted or indirectly quoted someone who said :
>
>>     One problem is whether you can replicate my way.  I like my code
>>formatted a certain way.  If your tool can not do this, I will not
>>like using it.  I will avoid it if at all possible.
>
>I have three problems with that way of thinking.
>
>1. if you are in a team environment, you have to use a common tidier
>to avoid false deltas.  You can tidy it to whatever you want to edit,
>but you must tidy it back to corporate standard before checkin.  You
>can't expect others to follow your formatting rules not part of what
>the corporate formatter does.  I worked in a place before the days of
>formatters and each programmer thought he "owned" some of the code and
>formatted it in a unique way, and fights broke out over variations.
>Part of the problem came because some programmers had big screen and
>others tiny ones.  The big screen programmers wanted long lines, the
>others short.

     Straw man.  An obvious extension of my argument is that the team
might have a format that they wish to keep, and the tool does not
allow for it.

>2. Surely you would not reject an IDE just because its formatter did
>not do precisely what you wanted.  So why reject a SCID? You would

     I might if the offness were severe enough.

     Why?  If it does not do what I want.

>export code for presentation to some formatter of your own that did
>the touch-ups. Surely in an IDE you would not maintain your coding
>conventions manually. Would you?

     Actually, I do.  IOW, yes, I do follow my conventions.

>3. that is only one factor. The SCID would give you overwhelming
>advantages to compensate for that loss, which is aesthetic, not so
>much productive.

     I have heard that argument too many times.  The advantages are
often not really so overwhelming and come with disadvantages that do
not get much mention.  I am not buying into something until I am
reasonably sure that it actually will be a benefit.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9373 — Re: Source code representation (was: code generation for the ternary operator).

Gene Wirchenko wrote:
> Daniel Pitts wrote:
> 
> [snip]
> 
> >I've often thought about a "new" way of representing code, where the 
> >logical structure is stored in not-necessarily-human-editable format, 
> >but the tools for managing the code allow it to be presented in a format 
> >chosen by the particular maintainer.
> 
>      One problem is whether you can replicate my way.  I like my code
> formatted a certain way.  If your tool can not do this, I will not
> like using it.  I will avoid it if at all possible.
> 
>      Other people feel the same way about their formats.  Miss very
> many possibilities, and you will have bad will from [|potential]
> users.
> 
>      I was wading through the editor settings for Visual Studio and
> ended up having to shut off a lot of the formatting, because the
> formatting done was not to my taste.
> 
>      I was just looking through the editor settings for Dreamweaver.
> It does not do what I want.  <sigh>

For workaday programmers, house style is also an issue.  Whatever your particular preference, at work you have to put the braces and indentation where the boss says to.  (Ah, I see Roedy made the same point.)

But prettifiers exist and are quite common and highly customizable.  Some shops take advantage of this, letting programmers goof up on style a little and cleaning it up on the way in to the VCS.

Regardless, I don't know that there is an intermediate format to store source code that improves upon, well, source code.  The usual intermediate format is object code.  Decompilers certainly exist and work well.

As for your particular predilection to store invalid code in source, well, that's just bad practice.  Oh, not while it's sitting in your editor or IDE, but that use case doesn't call for an intermediate format.  The one that could, were it not for the aforementioned superiority of simply storing the damn source, what's the big effing deal?, is when you share the code, at which point you certainly won't want non-syntactic code going forth. DBTB - Don't Break The Build!

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9382 — Re: Source code representation

On 11/1/11 5:33 PM, Gene Wirchenko wrote:
> On Tue, 01 Nov 2011 09:41:00 -0700, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net>  wrote:
>
> [snip]
>
>> I've often thought about a "new" way of representing code, where the
>> logical structure is stored in not-necessarily-human-editable format,
>> but the tools for managing the code allow it to be presented in a format
>> chosen by the particular maintainer.
>
>       One problem is whether you can replicate my way.  I like my code
> formatted a certain way.  If your tool can not do this, I will not
> like using it.  I will avoid it if at all possible.
Of course. The idea is that the view would be formatted to the 
individual contributors taste. Including folding of constructs you don't 
want to default visible, and potentially flowchart views or dependency 
graphs, etc... With an model that is more than an AST, much is possible.
>
>       Other people feel the same way about their formats.  Miss very
> many possibilities, and you will have bad will from [|potential]
> users.
>
>       I was wading through the editor settings for Visual Studio and
> ended up having to shut off a lot of the formatting, because the
> formatting done was not to my taste.
>
>       I was just looking through the editor settings for Dreamweaver.
> It does not do what I want.<sigh>
This is getting a little off topic, but I would like to say the IntelliJ 
IDEA has a very flexible configuration for formatting that can do most 
of what you want.  At the same time, being personally inflexible in what 
style you're willing to work in will limit your ability to work on many 
teams.  I recently have started working on an open-source project which 
has different style than I am used to, or even prefer. Luckily, IntelliJ 
IDEA can be set up to switch between styles for different projects.
>
>> In other words, you have the language constructs (classes, methods,
>> fields, statements, aspects, loops, etc...) modeled, and then have view
>> in front of that model which make them "look" like something that can be
>> manipulated easily by the programmer.
>
>       A loop already can be manipulated easily by a competent
> programmer.
A single loop, yes, but aspects (joins and advice) can be more difficult 
to navigate. My idea was to make *everything* easier (or no more 
difficult) than it already is.
>
>> I would imagine such a system has a bit of ramp-up time, but it would
>> eventually allow you to be much more productive. The "concrete" manor
>                                                        ^^^^^^^^^^ ^^^^^
>       Or it would be a straitjacket.
Some programmers I know should be in a straitjacket :-)

>
>       I do not understand the captioned words as used.  Should "manor"
> be "manner"?
Yes, consider that a typo :-)
>
>> that the object model stores things would allow you to refactor very easily.
>
>       How would you deal with the case of syntax errors?  I sometimes
> have a placeholder.  A simple example would be:
>            i=0;
>            while (i<SomeValue*****)
>               {
>               <various looping statements>
>               }
> The point is that I might not know exactly what the looping condition
> has to be.  (In this case, I might be wondering if I will need a flag
> for early exit.)  I want to able to enter a placeholder should I need
> it.
I think a good solution to that particular problem is to have an 
unimplemented predicate method:
while (thisLoopShouldContinue(i) {...}

@ToImplement boolean thisLoopShouldContinue();

In general, "uncompilable fragments" would probably have to be supported 
at some levels. Since the tool would maintain a structured model, the 
fragments couldn't accidentally interfere with other parts of the code. 
For example, and extra ")" or "}" would be localized to the context it 
was entered in.
>
>       VB 6 had a switch for compiling each line as entered.  I did not
> like it and disabled it as part of my configuration.  Sometimes, in
> mid-line, I would note that I had to change something else.  When the
> option was enabled, I would move off the line and often get a syntax
> error.  I knew that.  I prefer to be told about compilation errors
> when I ask, not to be interrupted by an overeager compiler.

You're talking a lot about old-tech editors.  Would you disable 
spell-checking on a document editor?  Modern IDEs will highlight errors 
and warnings, without a lot of fuss.  Yes, I sometimes leave a line 
half-finished too, and I'm grateful that my IDE will remind me to go 
back to that line when I get distracted on something else.

[toc] | [prev] | [next] | [standalone]

#9384 — Re: Source code representation

On Wed, 02 Nov 2011 10:58:55 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

>On 11/1/11 5:33 PM, Gene Wirchenko wrote:
>> On Tue, 01 Nov 2011 09:41:00 -0700, Daniel Pitts
>> <newsgroup.nospam@virtualinfinity.net>  wrote:
>>
>> [snip]
>>
>>> I've often thought about a "new" way of representing code, where the
>>> logical structure is stored in not-necessarily-human-editable format,
>>> but the tools for managing the code allow it to be presented in a format
>>> chosen by the particular maintainer.
>>
>>       One problem is whether you can replicate my way.  I like my code
>> formatted a certain way.  If your tool can not do this, I will not
>> like using it.  I will avoid it if at all possible.

>Of course. The idea is that the view would be formatted to the 
>individual contributors taste. Including folding of constructs you don't 
>want to default visible, and potentially flowchart views or dependency 
>graphs, etc... With an model that is more than an AST, much is possible.

     Yes, that is the idea, but where is the execution?  I find my
style to be readable for what I do.  I do not want to lose it.

>>       Other people feel the same way about their formats.  Miss very
>> many possibilities, and you will have bad will from [|potential]
>> users.
>>
>>       I was wading through the editor settings for Visual Studio and
>> ended up having to shut off a lot of the formatting, because the
>> formatting done was not to my taste.
>>
>>       I was just looking through the editor settings for Dreamweaver.
>> It does not do what I want.<sigh>

>This is getting a little off topic, but I would like to say the IntelliJ 
>IDEA has a very flexible configuration for formatting that can do most 
>of what you want.  At the same time, being personally inflexible in what 
>style you're willing to work in will limit your ability to work on many 
>teams.  I recently have started working on an open-source project which 
>has different style than I am used to, or even prefer. Luckily, IntelliJ 
>IDEA can be set up to switch between styles for different projects.

     Oh, if I have to work with a particular format, then I use it.
Given a choice, I use my preferences.

>>> In other words, you have the language constructs (classes, methods,
>>> fields, statements, aspects, loops, etc...) modeled, and then have view
>>> in front of that model which make them "look" like something that can be
>>> manipulated easily by the programmer.
>>
>>       A loop already can be manipulated easily by a competent
>> programmer.

>A single loop, yes, but aspects (joins and advice) can be more difficult 
>to navigate. My idea was to make *everything* easier (or no more 
>difficult) than it already is.

     Good luck.  You are going to have to replicate a lot.

>>> I would imagine such a system has a bit of ramp-up time, but it would
>>> eventually allow you to be much more productive. The "concrete" manor
>>                                                        ^^^^^^^^^^ ^^^^^
>>       Or it would be a straitjacket.
>Some programmers I know should be in a straitjacket :-)

>>       I do not understand the captioned words as used.  Should "manor"
>> be "manner"?

>Yes, consider that a typo :-)

     And what does "'concrete' manner" mean?

>>> that the object model stores things would allow you to refactor very easily.
>>
>>       How would you deal with the case of syntax errors?  I sometimes
>> have a placeholder.  A simple example would be:
>>            i=0;
>>            while (i<SomeValue*****)
>>               {
>>               <various looping statements>
>>               }
>> The point is that I might not know exactly what the looping condition
>> has to be.  (In this case, I might be wondering if I will need a flag
>> for early exit.)  I want to able to enter a placeholder should I need
>> it.

>I think a good solution to that particular problem is to have an 
>unimplemented predicate method:
>while (thisLoopShouldContinue(i) {...}
>
>@ToImplement boolean thisLoopShouldContinue();

     That is unnecessarily complex for my example (which is a common
case for me).  It might be a matter of *seconds* before I determine
what goes in the place.  I do not need a "to be done".  All I need is
something wrong so if it compiles, there is an error message.  I might
already have part of the expression.

>In general, "uncompilable fragments" would probably have to be supported 
>at some levels. Since the tool would maintain a structured model, the 
>fragments couldn't accidentally interfere with other parts of the code. 
>For example, and extra ")" or "}" would be localized to the context it 
>was entered in.
>>
>>       VB 6 had a switch for compiling each line as entered.  I did not
>> like it and disabled it as part of my configuration.  Sometimes, in
>> mid-line, I would note that I had to change something else.  When the
>> option was enabled, I would move off the line and often get a syntax
>> error.  I knew that.  I prefer to be told about compilation errors
>> when I ask, not to be interrupted by an overeager compiler.
>
>You're talking a lot about old-tech editors.  Would you disable 
>spell-checking on a document editor?  Modern IDEs will highlight errors 

     If it interfered.  I use Word.  I have turned off spelling
suggestions since they are often laughable.  I turned grammar checking
long ago since I have good grammar and could never figure out what the
suggestions meant.

>and warnings, without a lot of fuss.  Yes, I sometimes leave a line 
>half-finished too, and I'm grateful that my IDE will remind me to go 
>back to that line when I get distracted on something else.

     My "*****" works wonders for that.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9396 — Re: Source code representation

On 11/2/11 2:11 PM, Gene Wirchenko wrote:
>       My "*****" works wonders for that.

Sometimes, it is better to bend yourself to a tools whim than to refuse 
to use the tool.  I grant you that is not always, true, but the tool was 
created to make life easier for some.  Instead of saying why a tool will 
get in your way, consider thinking of ways to make the tool better.

To each their own.  You are one of the rare few that refuse to let 
useful tools help them in their daily lives, because past versions of 
them didn't live up to your expectations.

I can only please a certain number of people a day, and today is not 
your day. Tomorrow doesn't look good either. Ciao.

--
Daniel.

[toc] | [prev] | [next] | [standalone]

#9402 — Re: Source code representation

On Wed, 02 Nov 2011 15:21:38 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

>On 11/2/11 2:11 PM, Gene Wirchenko wrote:
>>       My "*****" works wonders for that.
>
>Sometimes, it is better to bend yourself to a tools whim than to refuse 
>to use the tool.  I grant you that is not always, true, but the tool was 
>created to make life easier for some.  Instead of saying why a tool will 
>get in your way, consider thinking of ways to make the tool better.

     Sometimes.  And sometimes, it is better to just keep it simple
and get on with it.

>To each their own.  You are one of the rare few that refuse to let 
>useful tools help them in their daily lives, because past versions of 
>them didn't live up to your expectations.

     Well, no.  There are plenty of people who choose to continue
using something that works for them and avoid something that does not.

>I can only please a certain number of people a day, and today is not 
>your day. Tomorrow doesn't look good either. Ciao.

     Do not develop a developer's tool today or tomorrow.  How is
Friday looking?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9362 — Re: Source code representation (was: code generation for the ternary operator).

On Tue, 01 Nov 2011 09:41:00 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :

>
>In other words, you have the language constructs (classes, methods, 
>fields, statements, aspects, loops, etc...) modeled, and then have view 
>in front of that model which make them "look" like something that can be 
>manipulated easily by the programmer.

I have been pushing the SCID idea for decades. There has been very
strong resistance to it. I think it is based on the following:

1. I talk about all the wild an crazy things you COULD do with code
display it if were pre-parsed into a tree.  Most of these things
remind people of the clownish decor in a McDonald's restaurant.  They
imagine garish colours, dancing paperclips, animated icons...  And run
in horror.  They don't get in that what I am about is CUSTOMISATION,
so you can have the display EXACTLY the way YOU like it, completely
independent of what other people like.  None of this would be
mandatory.  They look at my prototype JDisplay listings and recoil at
the garishness. http://mindprod.com/jgloss/jdisplay.html

2. People have SCID-like tools that just got in the way of editing.

3. People like the security of text files.  Database have a habit of
losing everything, perhaps with software is discontinued, OSes
changes.

4. Experienced programmers think of programming as manipulating text.
They have to be weaned to think more of thinking of programming as
more like plumbing where you interconnect names.  Eventually editing
will be much more visual where you select methods, drag variables into
place, and do a lot of selecting from a list of what the SCID
considers most plausible.

I have been pitching some of these ideas to IntelliJ.  I am using the
notion of almost-subliminal differences in the way text is rendered to
give additional information about each symbol without having to look
back at the definition.  Given that you are not supposed to even
notice the difference perhaps contrarians will then argue for more
distinctive warping.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It's difficult to be rigorous about whether a machine really knows,
thinks, etc., because we’re hard put to define these things. 
We understand human mental processes only slightly better than
a fish understands swimming. 
~ John McCarthy (born: 1927-09-04 died: 2011-10-23 at age: 84).
Inventor of the term AI (Artificial Intelligence), 
the short-circuit OR operator (|| in Java), 
and LISP (LIst Processing Language) that makes EMACS 
(Extensible MACro System) so addictive.

[toc] | [prev] | [next] | [standalone]

#9378 — Re: Source code representation (was: code generation for the ternary operator).

On Tue, 01 Nov 2011 23:52:26 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

>On Tue, 01 Nov 2011 09:41:00 -0700, Daniel Pitts
><newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
>quoted someone who said :
>
>>
>>In other words, you have the language constructs (classes, methods, 
>>fields, statements, aspects, loops, etc...) modeled, and then have view 
>>in front of that model which make them "look" like something that can be 
>>manipulated easily by the programmer.
>
>I have been pushing the SCID idea for decades. There has been very
>strong resistance to it. I think it is based on the following:
>
>1. I talk about all the wild an crazy things you COULD do with code
>display it if were pre-parsed into a tree.  Most of these things
>remind people of the clownish decor in a McDonald's restaurant.  They
>imagine garish colours, dancing paperclips, animated icons...  And run
>in horror.  They don't get in that what I am about is CUSTOMISATION,
>so you can have the display EXACTLY the way YOU like it, completely
>independent of what other people like.  None of this would be
>mandatory.  They look at my prototype JDisplay listings and recoil at
>the garishness. http://mindprod.com/jgloss/jdisplay.html

     What would it take to implement such?  If it is much effort at
all, it gets in the way or is difficult to justify.  Writing a
text-processing utility is simpler.

>2. People have SCID-like tools that just got in the way of editing.

     Yes.  I have utilties that process text files.  I would like to
be able to use them on source code without having to jump through a
hoop.

>3. People like the security of text files.  Database have a habit of
>losing everything, perhaps with software is discontinued, OSes
>changes.

     I would say "simplicity" instead of "security", but it is about
the same argument.  Text files convert to other systems fairly easily,
too, but SCID between two SCID systems might not.

>4. Experienced programmers think of programming as manipulating text.
>They have to be weaned to think more of thinking of programming as
>more like plumbing where you interconnect names.  Eventually editing
>will be much more visual where you select methods, drag variables into
>place, and do a lot of selecting from a list of what the SCID
>considers most plausible.

     Typing is much faster than mousing for me.  The text interface is
also simpler.  I can use my own editor that fits my preferences rather
than getting locked into a GUI IDE.

>I have been pitching some of these ideas to IntelliJ.  I am using the
>notion of almost-subliminal differences in the way text is rendered to
>give additional information about each symbol without having to look
>back at the definition.  Given that you are not supposed to even
>notice the difference perhaps contrarians will then argue for more
>distinctive warping.

     I tend to find such things distracting and prefer to not have
them.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9383 — Re: Source code representation (was: code generation for the ternary operator).

On Wed, 02 Nov 2011 09:47:44 -0700, Gene Wirchenko wrote:

> On Tue, 01 Nov 2011 23:52:26 -0700, Roedy Green
>>3. People like the security of text files.  Database have a habit of
>>losing everything, perhaps with software is discontinued, OSes changes.
> 
>      I would say "simplicity" instead of "security", but it is about
> the same argument.  Text files convert to other systems fairly easily,
> too, but SCID between two SCID systems might not.
>
Agreed. At present the main issue in moving code is line terminators 
(unless you're fighting the ASCII <--> EBCDIC battle). The benefit of 
text is that file transfer software (FTP, Kermit, etc) does this 'for 
free' but even if it doesn't, very simple tools such as tr, dos2unix and 
unix2dos  will solve that problem.

I have a nasty suspicion that the transfer weapon of choice between SCID 
implementations might turn out to be voluminous XML.

>      Typing is much faster than mousing for me.  The text interface is
> also simpler.  I can use my own editor that fits my preferences rather
> than getting locked into a GUI IDE.
>
Exactly the same here - I use a portable editor (microEmacs) which can be 
easily set up to use exactly the same keystrokes on almost any system 
with an ANSI C compiler. In particular, its ability to associate 
customisable formatting conventions (tab-length, line-wrap, auto-indent, 
etc) with the file extension so something I really miss in editors that 
don't support it.

I prefer to develop Java with a command line, text editor and ant. I've 
used IntelliJ and generally liked it once I'd gotten used to that busy 
screen, except for one thing: apart from specific refactoring facilities 
its text editor seemed to be missing all but the most basic editing 
functions - there were times I'd have killed for a general-purpose regex-
based search-and-replace facility.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web