Programming 2.0

I like how this approach emphasizes the structural aspects of programming. However, at the same time it discriminates against the linguistic aspects of programming.

I think it is a great tool for education, but I doubt you can build manageable and understandable complex systems with that approach.

kib22• 16 years ago

Interesting read; what's the status of his Subtext project ?

ebiester• 16 years ago

It's called Coherence now, but I haven't seen too much lately from it. http://alarmingdevelopment.org/ is his blog.

kib22• 16 years ago

Thanks ebiester!

vog4• 16 years ago

The use of the word "copy" is very confusing.

What the author means when he says "copying" is completely different from the usual meaning of the word. He should have called it "linking" or even better "instantiating" (in the sense of prototype-based OO).

This is especially annoying at the end of Demo1 where he concludes that "copy & paste is decriminalized". This sounds much less revolutionary if you translate "copy" into what he actually means. Then it reads like "instantiating and changing objects is decriminalized", which is elementary common sense in programming.

weavejester• 16 years ago

It seems a rather clumsy interface for writing software in, and it doesn't seem to solve any real problems. Programming 2.0 this ain't.

vog4• 16 years ago

The unity of "if-then-else", "switch" and "polymorphism" is praised as one big advantage of schematic tables. It is suggested (though not explicitly said) that this is the first approach which combines them, and that the 2-dimensionality plays a crucial part on that.

However, this unity has been achieved by the ML languages decades ago. The schematic tables would look much less revolutionary if they were compared with the "case" statement of Haskell or the "match" statement of OCaml.

Also, the comparisons in code size and readability would look very different if the schematic table was compared with code written in a high-level language instead of Java.

tetha• 16 years ago

Hum, holes I see in the argumentation:

- The graph structure for the recursion case of fibonacci is easier to read. At least for this simple computation, I strongly disagree. Granted, I am influenced by Programming 1.0, but I don't see how things become much simpler than fib(i-1) + fib(i-2).

- The damage calculation function is horribly factored. The switch statement is duplicated and should be joined or handled differently. Some quick code movements result in this: switch(attack) { case MAGIC: damage = magic_base_damage; damage = account_surprise_attack(surprise, damage) damage = reduce_damage_linear(damage, defense) break;

      case MELEE:
          damage = melee_base_damage
          damage = account_surprise_attack(surprise, damage)
          damage = reduce_damage_fractional(damage, defense)
      break;
  }

I'll leave out the functions, because they are a simple extract method from the function he gave. Once you notice this, and you are in an object oriented language, you can replace this type code with polymorphism and probably form a template method in order to remove the duplication in the general structure of damage calculation. In fact, at this point, I like the refactored solution more, because now it displays the underlying structure of the damage calculations (get base damage, add surprise bonus, apply damage reduction). [[Note: I wrote this while watching it. I arrived at the polymorphic solution after writing this, and at least in my opinion, my solution is pretty clear, opposed to his example. In my polymorphic solution, there is 3 times 1 call downward which returns 1 value upwards, which would be a nice simple W-shape.]]

I am not saying that his way has no advantage, and I don't want to bash it too much. I even kinda like it. I would just like to see examples which are harder to rip apart, because at least for me, the refactored damage calculation is pretty clear.

Later on, he brings that argument "I can see everything in the table at once". I really hate this argument. I really, really hate it. Yes, it is nice that I can look at these 3 or 4 values in this example. Yes, I can nicely see them on the screen. And now, I imagine something where we have like 20 - 30 different things. A good class hierachy just swallows this and it is simple to look at the relevant stack of classes. In a table, I need to look at ALL of them, resulting in a lot of horizontal scrolling.

Soo.. tl;dr? I think this is interesting, and interesting for small examples, but I don't see how this scales and I don't see too large examples above well-written textual code.

vog4• 16 years ago

That's exactly what I thought about it, too. The example function is close to spaghetti and needs at least one helper function with a well-chosen name.

The previous example (if-then-else with a complicated boolean logic) has a similar problem: Nobody should write such a mess in the first place. Instead, give speaking names to terms like "a" and "!a & (b|c)". And with "speaking names" I don't mean stupid stuff like "isAandBorC", but something like "waterSuppyOutOfLimits". That way, humans no longer need to think in boolean algebra but in terms of the problem's domain.

He is focusing on the structural aspect of programming, making spaghetti code more manageable by easier dynamic investigation of (partial) special cases.

However, statements like "names are just comments" show that he's completely missing the linguistic aspect of programming. With well-chosen names you don't have to look at the low-level details to understand what's happening. That's what makes abstractions powerful.

Programming 2.0

Related Stories