not if we find a way around the chicken and egg problem.
brainstorm: assume a projection based system and no backwards
compatibility issues (an IDE and SCM and code review tool etc.
magically exists which supports the new system): then you could do:
* locked blocks. Parts of your code should be freely refactorable.
Other parts should be offlimits, except for special occasions. Your
SQL statements, for example, since they correspond to something
outside the code system (ie: the database). What if you could mark
some blocks as locked so that they wouldn't be refactorable and would
give you a warning when you try to do so. You could still unlock it if
you decide it's what you really want to do, but this gives you
protection against accidental changes. This is really just some
metadata stored on the blocks which editors agree to respect so that
you don't shoot yourself.
* postit notes: store notes to yourself and other developers in the
source. We do this today with comments, but it could be made more
rigorous, searchable, nicely highlighted etc. And you can make them
invisible when you don't want to see them anymore.
* inline unit tests. Why are your unit tests in a separate class. It
should be easy to put the test for a method right next to the method,
and hide it when you don't want to look at it. the test is stripped
when you compile for deployment.
* optimizations: creating optimizations as part of the compilation
step used to be the job of the compiler, but if you have a standard
AST format that is fed into the compiler then you could easily build
lots of cool optimizations between the code editor and the compiler,
rather than inside the compiler itself. This opens up such
optimizations to a much wider audience than just compiler hackers. I
expect we'd see a Cambrian Explosion of extensions and optimizations
very quickly.
- j
On Sep 10, 2009, at 7:30 PM, Casper Bang wrote:
>
> There doesn't seem to be many aspects untouched such an approach. The
> whole multi-line String discussion would become utter pointless as
> would line lengths. But there would also be some interesting AOP
> scenarios (which I am usually against when it comes to external
> configuration and byte-code weaving) as well as design-by-contract,
> post and precondition checks which could be toggled invisible etc. A
> perspective tool (Mylyn) would kick @$$ too in such an editor. Is it a
> pipe-dream? I really hope not.
>
> /Casper
>
> On 11 Sep., 04:00, Reinier Zwitserloot <reini...@gmail.com> wrote:
>> Brian, the central idea behind AST editing also involves moving the
>> process of editing, rendering, and compiling into user-space. So, for
>> your grid setting endeavour, you could code up a plugin or macro or
>> other mechanism which knows how to render the insert instructions.
>> And
>> it would look much, much better; it would look a little like this:
>>
>> grid.setAllWidgets:
>>
>> ----------------------------------------------------------
>> | new Label("User ID"); | usernameBox |
>> ----------------------------------------------------------
>> | new Label("Password"); | passwordBox |
>> ----------------------------------------------------------
>>
>> except nicer looking, with actual lines and not fake ascii ones.
>> When
>> you change the grid's explicit dimensions, the table will INSTANTLY
>> reflect this. In fact, you can tab/enter/some other shortcut in your
>> table simile and the grid constructor call would automatically adjust
>> - because what you're actually editing is a single grid set widgets
>> plugin, which includes generating everything in that code snippet -
>> the grid constructor, as well as each setWidget() call. The AST here
>> is a custom type, the rendering and editing of which is left to the
>> plugin. Where other tools need to interop (for 'find callers' and
>> other such tools), the plugin reports the actual source
>> representation
>> instead of this graphical device.
>>
>> Are you starting to see how revolutionary such a thing would be?
>>
>> On Sep 10, 7:18 pm, Brian <brian.irei...@gmail.com> wrote:
>>
>>> There is a part of me that likes this idea (mostly the part of me
>>> that
>>> has to read other people's code). The other part of me would mourn
>>> the
>>> loss of the ability to express something by bending the general
>>> style
>>> rules.
>>
>>> I've been using GWT recently and have struggled with writing clear
>>> code for constructing views. What I'm experimenting with in some
>>> cases
>>> is to make the code a visual representation of the layout. This
>>> began
>>> with and works very nicely for VerticalPanel. In my current
>>> guidelines, adding an element to a VerticalPanel is not allowed to
>>> take more than one line. If it's something simple like a Label
>>> that I
>>> don't need to retain access to, I just construct a new one inline.
>>> Otherwise, I write a method to create the element. For example:
>>
>>> VerticalPanel panel = new VerticalPanel();
>>> panel.add(new Label("Login"));
>>> panel.add(makeLoginForm());
>>> panel.add(makeLoginButton());
>>> panel.add(makeForgotPasswordLink());
>>
>>> This also has the advantage of naming the pieces of the UI. While
>>> this
>>> is also a slight burden, I'm generally in favor of it for the sake
>>> of
>>> clarity.
>>
>>> I then applied this to a Grid. In the specific case, it was a simple
>>> 2x2 grid:
>>
>>> Grid grid = new Grid(2, 2);
>>> grid.setWidget(0, 0, new Label("User ID"));
>>> grid.setWidget
>>> (0, 1, usernameBox);
>>> grid.setWidget(1, 0, new Label("Password"));
>>> grid.setWidget
>>> (1, 1, passwordBox);
>>
>>> Note that with a fixed width font, the 2nd statements line up with
>>> each other. I'm not normally a fan of putting multiple statements on
>>> the same line, but in this case, it makes the intent of the code
>>> very
>>> clear. (The multiple statements, of course, still need to reasonably
>>> fit on one line of text.)
>>
>>> While I'm very particular about consistent style, it's nice to be
>>> able
>>> to be creative when the situation calls for it.
>>
>>> (BTW, I've usually preferred spaces instead of tabs, but tabs would
>>> make it easier to make sure that the statements stay lined up. In
>>> fact, using tabs explicitly expresses the intent for them to line
>>> up.)
>>
>>> -Brian
>>
>>> On Sep 9, 11:10 pm, Joshua Marinacci <jos...@marinacci.org> wrote:
>>
>>>> RANT!
>>
>>>> Why, in the 21st century, are we still writing code with ascii
>>>> symbols
>>>> in text editors, and worried about the exact indentation and
>>>> whether
>>>> to use tabs, spaces, etc?!!
>>
>>>> Since the IDE knows the structure of our code, why aren't we just
>>>> sharing ASTs directly, letting your IDE format it to your desire,
>>>> and
>>>> only sharing the underlying AST with your fellow developers.
>>>> Encoding,
>>>> spaces, braces, etc. is a detail that only matters when presented
>>>> to
>>>> the human.
>>
>>>> What we do today is like editing image files from the commandline!
>>
>>>> On Sep 9, 2009, at 7:32 PM, Ryan Waterer wrote:
>>
>>>>> While experienced programmers might not worry about the braces
>>>>> on a
>>>>> single line, they become invaluable to any junior programmers.
>>>>> I've
>>>>> trained a few in which they couldn't understand why the following
>>>>> code segment simply stopped working. (Let's not even start a
>>>>> discussion about System.out.println as a valid debugging tool, ok?
>>>>> This is just an example of a n00blet mistake )
>>
>>>>> for (int y = 0; y < lines; y++)
>>>>> for (int x = 0; x < columns; x++)
>>>>> System.out.println("The sum is: " + sum);
>>>>> sum += cells[y][x];
>>
>>>>> I agree that the braces add a bit of "clutter" to the visual look
>>>>> and feel of code. However, I feel that it helps with the overall
>>>>> maintainability of the code and therefore, I disregard the way
>>>>> that
>>>>> it looks.
>>
>>>>> --Ryan
>>
>>>>> On Wed, Sep 9, 2009 at 8:24 PM, Jess Holle <je...@ptc.com> wrote:
>>>>> I'll agree on the newlines and indents, but the braces are silly.
>>
>>>>> One might debate the extra whitespace inside the ()'s, but I
>>>>> find it
>>>>> more readable with the whitespace -- to each his/her own in that
>>>>> regard.
>>
>>>>> TorNorbye wrote:
>>>>>> On Sep 9, 5:27 pm, Reinier Zwitserloot <reini...@gmail.com>
>>>>>> wrote:
>>
>>>>>>> Here's a line from my code:
>>
>>>>>>> for ( int y = 0 ; x < lines ; y++ ) for ( int x = 0 ; x <
>>>>>>> columns ; x+
>>>>>>> + ) sum += cells[y][x];
>>
>>>>>> I guess that's where we disagree.
>>
>>>>>> for (int y = 0; y < lines; y++) {
>>>>>> for (int x = 0; x < columns; x++) {
>>>>>> sum += cells[y][x];
>>>>>> }
>>>>>> }
>>
>>>>>> is IMHO better because:
>>>>>> (a) I can see immediately that I'm dealing with a nested
>>>>>> construct
>>>>>> here, and that's it's O(n^2)
>>>>>> (b) I can more easily set breakpoints on individual statements of
>>>>>> this
>>>>>> code while debugging - and similarly other "line oriented"
>>>>>> operations
>>>>>> (like quickfixes etc) get more cluttery when it's all on one
>>>>>> line.
>>>>>> Profiling data / statement counts / code coverage highlighting
>>>>>> for
>>>>>> the
>>>>>> line is also trickier when you mash multiple statements into one
>>>>>> line.
>>>>>> (c) I think it's less likely that I would have made the "x <
>>>>>> lines"
>>>>>> error that was in your code when typing it this way because the
>>>>>> handling of y and x were done separately on separate lines
>>>>>> (though
>>>>>> this is a bit speculative)
>>>>>> (d) I removed your spaces inside the parentheses, because they
>>>>>> are
>>>>>> Bad! Bad!
>>
>>>>>> (Ok c and d are padding)
>>
>>>>>> I am -not- looking to minimize the number of lines needed to
>>>>>> express
>>>>>> code. If I wanted that, I'd be coding in Perl. I deliberately
>>>>>> add
>>>>>> newlines to make the code more airy and to group logical
>>>>>> operations
>>>>>> together. I always insert a newline before the final return-
>>>>>> statement
>>>>>> from a function etc.
>>
>>>>>> I think the extra vertical space you've gained, which arguably
>>>>>> could
>>>>>> help you orient yourself in your code by showing more of the
>>>>>> surrounding context, is lost because the code itself is denser
>>>>>> and
>>>>>> more difficult to visually scan.
>>
>>>>>> Oh no, a formatting flamewar -- what have I gotten myself into?
>>
>>>>>> -- Tor
>>
>>>>>> P.S. No tabs!
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
