Comment by ChuckMcM | Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

I really enjoyed Bret's article. I don't necessarily agree with all of it but the main argument is quite sound.

Bret writes: "People understand what they can see." which is true for some people but not true for all people. I've got one daughter who is very verbal, one very visual. They learn differently. This in a minor nit though, his exploration of the 'code' / 'example' model is good.

I particularly liked the commentary on something like:

   ellipse(60, 50, 50, 100) 
            \   \   \    \
             \   \   \    +- What does this mean?
              \   \   +----- Or this,
               \   +-------- Or this,
                +----------- Or this?

(We'll see how that comes out in the formatting)

TOPS-20 had a really interesting macro language for programming commands, it was the inspiration for a lot of self-describing command line interfaces like the ones made popular on Cisco gear. Basically you could write it like

   DRAW ellipse AT X=60 Y=50 THAT IS 50 HIGH, 100 WIDE

But all of the 'fill text' was really unnecessary for the parser so if you wrote:

   ellipse 60 50 50 100

It would be just as intelligible. The point being that the training wheels got out of your way when ever you wanted them too, and if you were ever stuck you could type ? and it would tell you what your choices were.

Not enough learning environments put this sort of dynamically sizing help into the system where it is needed such that it helps novices and doesn't slow down experts.

In some languages like perl, there's a named parameter form that's becoming more common. If I were to rewrite the example in perl, it would look like this:

  ellipse(x=>60, y=>50, height=>50, width=>100);

Yes, it is more typing, but you don't need fancy auto-complete to give you hints when reading.

There's also nothing from stopping us from making a "training wheels" interface in javascript:

  draw-ellipse({x:60, y:50, height:50, width:100});

  function draw-ellipse(o) {
    ellipse(o.x, o.y, o.height, o.width);
  }

Ah, but doesn't this have the same problems all NLP systems have? It gives illusion of flexibility that gets shattered every time user allows himself to believe in it. What if I prefer to write them in different order? Or if some version of named parameters is in use, what if I like some other synonym for height? Strict syntax is a good thing as long as it is also brittle.

Now, an IDE that generates a training text like that on the fly and allows you to fill in the values without actually storing the training text would be nice. Something like intellisence popups, but inline and expanded.

> Now, an IDE that generates a training text like that on the fly and allows you to fill in the values without actually storing the training text would be nice. Something like intellisence popups, but inline and expanded.

That's the best idea i've heard in a long time. The IDE already has the information but hovering every function call with the mouse to get parameter information is a PITA and breaks the flow of reading. A hotkey to inline them on all your code at once would be brilliant.

The problem with making the "training wheels" optional, is people will leave them off. All of a sudden your code is not useful or readable to anyone unfamiliar with your code. Even yourself. Sure you might know what the parameters in `ellipse 60 50 50 100` do right now, but what if you haven't worked on drawing code for 6 months?

It seems to me like what he's talking about is less a bicycle with training wheels than it is a self-balancing segway. A bicycle with training wheels is annoying to anyone but a beginner... what he's talking about is something that isn't annoying to a pro... even if they don't lean on it as much.

Reply on news.ycombinator.com