Fragile Fences
 

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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Re: Fragile Fences
 

Roedy Green <look-on@mindprod.com.invalid> writes:

> 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.

However, if it was painfully obvious where an "}" was missing, then
you would not be surprised to see the errors. It is only because
there is no feasible way for a human to keep track of the pairing
that it becomes a problem.

In fact, the use of begin- and end-block markers is usually a
violation of the DRY (Don't Repeat Yourself) principle - the same
information (where blocks start and end) is present in two forms: The
markers for the compiler and the indentation for humans. If these get
out of sync, the compiler spews errors that are not easily visible in
the source.

(That as actually a reason for languages that use only indentation to
delimiter blocks ... something I still have a hard time accepting :)

> From an engineering point of view, this structure is far too delicate.

Absolutely. It can fail invisibly to the user ... until he tries to
compile.

> If engineers designed buildings the way computer programmers design
> computer languages, the first woodpecker that came along would destroy
> civilisation.

(Ah, Weinberg's law :)

....

> 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.

What I hear you say is that the concept of a block should be
abstracted out, so that the markers becomes simply that. There is no
such thing as half a block, so there should never be only an opening
marker. It's not so much the pairing of the { and }, but that they
are secondary to the block they delimiter, artifacts of the real
concern.

> 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.

That would be merely guiding, not enforcing, the pairing.

> 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.

That could be implemented as a marker line in the margin, pointing out
the block that you are currently inside, as well as highlighting the
delimiting markers.

...
> 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.

Hear, hear! There is no case where you will need a program with
unbalanced brackets, parentheses, square brackets, etc. They should
always be introduced and removed together.

> 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.

The only problem with this is the desire to copy half-written code
around, before filling in the blanks. Programmers do think in text,
not syntax trees (most of the time). But maybe that's exactly the
problem :)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Re: Fragile Fences
 

On Tue, 05 Jul 2005 10:50:30 +0000, Roedy Green wrote:

> If engineers designed buildings the way computer programmers design
> computer languages, the first woodpecker that came along would destroy
> civilisation.

Well, the better comparison would be an architect that just happens to
leave a decimal dot in some calculations out... with "interesting"
results. You are after all not actually "building" your program, as
specifying it.

--
You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

Re: Fragile Fences
 

On Tue, 05 Jul 2005 15:45:20 +0200, Lasse Reichstein Nielsen
<lrn@hotpop.com> wrote or quoted :

>What I hear you say is that the concept of a block should be
>abstracted out, so that the markers becomes simply that. There is no
>such thing as half a block, so there should never be only an opening
>marker. It's not so much the pairing of the { and }, but that they
>are secondary to the block they delimiter, artifacts of the real
>concern.

Exactly. Internally to the SCID, blocks are a single node object
with dependent children for the stuff inside one level deep.

You need an editor that recognizes that.

OSs make you treat files an atomic units. You can have a file missing
a big or end "marker" Blocks should be the same sort of beast. We
should think of the block as the thing, the {} are just decorations on
it to help human see it. Indenting coloured backgrounds nesting
stripes in the margin etc all could also be used to help make these
boundaries more obvious.

My brain HATES nesting of any kind. I am nesting retarded. I have
terrible trouble of keeping track of even 3 levels. I need all the
visual cues and disability aids possible to compensate.

At the bare minimum, if I am working at level 4 editing, I should not
be able to inadvertently meddle with level 2 block boundaries.

I go further. You should not be able to shift boundaries, just move
code in or out of a block. I think the key is editors that refuse to
let your code ever be unbalanced. They would take getting used to,
but in the long run they would make it much easier to manage complex
structure.





--
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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Re: Fragile Fences
 

On Tue, 05 Jul 2005 15:45:20 +0200, Lasse Reichstein Nielsen
<lrn@hotpop.com> wrote or quoted :

>That would be merely guiding, not enforcing, the pairing.

There is so much resistance to this sort of thing it will have to be
introduced gradually. At first people think of it as the editor being
mean. once they learn to work within the guidelines, they will see
that restriction as benign.

You can certainly automatically MARK begin ends better than you do
now. Few will complain about that, except the "I code in binary" boys
who see coding as a sort of test of manliness.


The eclipse people have been very clever in the way they mask the fact
the code exits internally as a parse tree. The ASCII files are
generated from it partly to mollify. Eclipse thereby managed to
bypass much of the Luddite reactions I got when I first brought up the
idea of SCIDs.

On the other hand, that tying to Java source has prevented them from
really taking off on SCID possibilities.

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


--
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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Re: Fragile Fences
 

On Tue, 05 Jul 2005 15:45:20 +0200, Lasse Reichstein Nielsen
<lrn@hotpop.com> wrote or quoted :

>That could be implemented as a marker line in the margin, pointing out
>the block that you are currently inside, as well as highlighting the
>delimiting markers.

you need a lot of visual cues to remind you where you are. One of the
must infuriating errors I make using Eclipse is when I have an
abstract class and fairly similar implementations of it. I think I am
editing class A but really I am working on class B.

I handle this on my website with my header on each page that tells you
where are at all times in the file hierarchy, with different sections
having different colour schemes.

I need something like that when coding I can watch out the corner of
my eye.

In parking lots there have symbols -- animals for example, for each
section that help you remember where you are or where you were.
You could do the same with sections of code, assign them an icon and
get back to it just by clicking on a bookmark bar.

--
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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Re: Fragile Fences
 

On Tue, 05 Jul 2005 15:45:20 +0200, Lasse Reichstein Nielsen
<lrn@hotpop.com> wrote or quoted :

>The only problem with this is the desire to copy half-written code
>around, before filling in the blanks. Programmers do think in text,
>not syntax trees (most of the time). But maybe that's exactly the
>problem :)

I think it would be awkward at first, but you can still do a lot of
pasting, it is just the sucker side would only work in balanced
chunks, or would insist you balance the clipboard before pasting.

I have found that a badly unbalance piece of code can take a long time
to fix. The compiler is useless. It is totally befuddled.

Perhaps then you to introduce the concept you are allowed to unbalance
a maximum of one deep, so the compiler knows the possible range of
where the missing pair is , AND INSERTS it, provisionally and blinks
it until you confirm.

There need not be one size fits all. This is a configurable editor,
not a language feature. Because some people want the total freedom of
Notepad dose not mean others should be blocked from getting more
automated code cranking.

Look at this from management's point of view. Which technique lets you
crank out more working code per hour?

--
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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Re: Fragile Fences
 

Eclipse kinda(loosely but simliar idea) already implements two of your
suggestions (2,4) if you have the curser on a {} type thing it puts a
block around the oposing one. Body tags can be shrunk on the left hand
side by clicking the arrow, the body has now disapeared and u cant edit
it... cant see it either though... I think as ide's continue to evolve
we will maybe just start seeing these(prob in VIM before eclipse ;).
Great ideas, i could see myself using all of that.

Re: Fragile Fences
 

On 5 Jul 2005 16:21:34 -0700, "ChrisWSU" <cnlwsu@gmail.com> wrote or
quoted :

>I think as ide's continue to evolve
>we will maybe just start seeing these(prob in VIM before eclipse ;).
>Great ideas, i could see myself using all of that.

I have been pushing the SCID idea for a decades. Most of the reaction
has been extreme hostility. See my essay
http://mindprod.com/projects/scid.html

“All truth passes through three stages. First, it is ridiculed.
Second, it is violently opposed. Third, it is accepted as being
self-evident.”
~ Arthur Schopenhauer

I think SCIDs are moving into stage 3.

I had a smile wrapping around my head as I was exploring Eclipse. My
partner was puzzled why I was so elated. I explained that I had been
envisioning SCID editing tools for many years, now here many of them
were, working even more smoothly than I had envisioned them, in
Eclipse. It was like one those dreams where money keeps appearing
everywhere.

The handling of block delimiter balancing though is still almost the
nightmare it was in the old days of text editors.

Using eclipse is a bit like having a Korean tutor (Remo William's
Chiun) over your shoulder constantly pointing at your typos and other
errors as you make them, but not saying much, or when he does speak,
in strange English.

You don't have a compile-edit cycle any more. You normally discover
and fix problems the instant you make them BUT YOU DON'T HAVE TO
REPAIR THEM right way. I am learning to pay more attention to its
hints as I type and fix problems right way. It makes for ever so much
smoother operation.


I am quite impressed. Normally switching IDEs makes you unproductive
for weeks till you learn the new one. I am already more productive
with Eclipse after just a few days.

If I had the money I'd send a gift certificate to everyone who had
anything to do with creating this marvel so they could buy a huge
bouquet of flowers for someone they love.

--
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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Re: Fragile Fences
 

On Tue, 05 Jul 2005 21:37:47 GMT, Roedy Green wrote:
> I have found that a badly unbalance piece of code can take a long
> time to fix. The compiler is useless. It is totally befuddled.

On the other hand, it isn't the compiler's job to fix your source
code.

> Perhaps then you to introduce the concept you are allowed to
> unbalance a maximum of one deep, so the compiler knows the possible
> range of where the missing pair is , AND INSERTS it, provisionally
> and blinks it until you confirm.

Why should the *compiler* be doing these things? Doesn't your *editor*
show you how the parentheses match?

In my experience, the automatic code formatting provided by my editor
lets me spot this kind of error almost immediately, since things don't
align as they should below the missing (or additional) parenthesis.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e