R
Roedy Green
I have been working with Eclipse and some large enum classes. It has
pounded home an issue of language design I have been raising ever
since the 1960s.
The symptom is this. I have a heavily nested structure of enum, enum
constants, methods, loops etc.
The beginning and end over every last one of these coding elements is
marked with the same vanilla { .. }.
When I am typing I can watch a million error messages appear or
disappear just by inserting or removing one } in some trivial if. The
compiler reinterprets the program in a totally different and
completely bizarre way from the most trivial change. Classes unnest
and renest for example.
From an engineering point of view, this structure is far too delicate.
If engineers designed buildings the way computer programmers design
computer languages, the first woodpecker that came along would destroy
civilisation.
I spend more time sorting out commas, () {} than everything else put
together. This is especially true when constructing code by cut and
paste Frankenstein style from remotely similar code. My snippets may
or may not be balanced.
You want some way of permanently tying the begin and end marker
together so that the compiler knows ever after they are married
together. Any unbalance has then be isolated to whether it is inside
or outside that pair. The compiler can then be much cleverer in
telling you exactly where the missing or extra { } is.
Even the formatter should understand this anchor pairing and hence can
deal more rationally with imperfect programs.
Eclipse is a SCID so it could handle the problem in many ways:
1. Using variable size {}, or variable colour so you can tell
begin/end class, method loop pairs. It is thus not enforcing anything,
just letting you know what sort of animal you are dealing with. You
won't casually delete a huge begin/end class marker.
2. hover help that tells you what sort of "fence" ( { [ character you
are dealing with e.g. "begin for" start xxx method, end xxx class. It
could also remind you where you are in Class X in method y nested X
deep.
This information could also appear as pseudo comments that are not
really in the code but just optionally generated that look like
comments when editing. They constantly automatically update to
describe the current structure.
3. name your large loops and blocks, and have pseudo comments
generated that show you when the matching end is.
You might even have these comments optionally included in exported
source to help the unfortunate scidless maintain the code.
4. allow you to freeze certain fence characters. They become read
only. This prevents a unbalance error from propagating past inside or
outside the fence and making sure you never accidentally delete major
punctuation like class boundaries. By default method and class {} are
not deleteable. Only the whole method or class is or some of its
contents, but not { without } or vice versa.
Your program become like a set of rigid containers into which you can
pour code.
5. refuse a paste that would unbalance class/method begin end.
refuse a del ins that would unbalance class/method begin end.
maybe even block/loop too. Obviously you would have to make this
configurable for those would consider this aid Nazi.
6. Perhaps {} must be considered non-characters. You must insert them
by highlighting a block and hitting a key to insert the {} at once
with no unbalanced {} permitted. Ditto when you remove one end it
removes the other at the same time, and optionally the block contents.
We need to start thinking of IDEs as data entry devices, not text
editors. Data entry would never let a data structure get globally
messy the way IDEs do. You are not typing an ASCII text. You are
entering a data structure. You really should be logically cutting and
pasting parsed trees, not text. Think about how a tree node editor
works.
--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm
Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
pounded home an issue of language design I have been raising ever
since the 1960s.
The symptom is this. I have a heavily nested structure of enum, enum
constants, methods, loops etc.
The beginning and end over every last one of these coding elements is
marked with the same vanilla { .. }.
When I am typing I can watch a million error messages appear or
disappear just by inserting or removing one } in some trivial if. The
compiler reinterprets the program in a totally different and
completely bizarre way from the most trivial change. Classes unnest
and renest for example.
From an engineering point of view, this structure is far too delicate.
If engineers designed buildings the way computer programmers design
computer languages, the first woodpecker that came along would destroy
civilisation.
I spend more time sorting out commas, () {} than everything else put
together. This is especially true when constructing code by cut and
paste Frankenstein style from remotely similar code. My snippets may
or may not be balanced.
You want some way of permanently tying the begin and end marker
together so that the compiler knows ever after they are married
together. Any unbalance has then be isolated to whether it is inside
or outside that pair. The compiler can then be much cleverer in
telling you exactly where the missing or extra { } is.
Even the formatter should understand this anchor pairing and hence can
deal more rationally with imperfect programs.
Eclipse is a SCID so it could handle the problem in many ways:
1. Using variable size {}, or variable colour so you can tell
begin/end class, method loop pairs. It is thus not enforcing anything,
just letting you know what sort of animal you are dealing with. You
won't casually delete a huge begin/end class marker.
2. hover help that tells you what sort of "fence" ( { [ character you
are dealing with e.g. "begin for" start xxx method, end xxx class. It
could also remind you where you are in Class X in method y nested X
deep.
This information could also appear as pseudo comments that are not
really in the code but just optionally generated that look like
comments when editing. They constantly automatically update to
describe the current structure.
3. name your large loops and blocks, and have pseudo comments
generated that show you when the matching end is.
You might even have these comments optionally included in exported
source to help the unfortunate scidless maintain the code.
4. allow you to freeze certain fence characters. They become read
only. This prevents a unbalance error from propagating past inside or
outside the fence and making sure you never accidentally delete major
punctuation like class boundaries. By default method and class {} are
not deleteable. Only the whole method or class is or some of its
contents, but not { without } or vice versa.
Your program become like a set of rigid containers into which you can
pour code.
5. refuse a paste that would unbalance class/method begin end.
refuse a del ins that would unbalance class/method begin end.
maybe even block/loop too. Obviously you would have to make this
configurable for those would consider this aid Nazi.
6. Perhaps {} must be considered non-characters. You must insert them
by highlighting a block and hitting a key to insert the {} at once
with no unbalanced {} permitted. Ditto when you remove one end it
removes the other at the same time, and optionally the block contents.
We need to start thinking of IDEs as data entry devices, not text
editors. Data entry would never let a data structure get globally
messy the way IDEs do. You are not typing an ASCII text. You are
entering a data structure. You really should be logically cutting and
pasting parsed trees, not text. Think about how a tree node editor
works.
--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm
Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes