Programming 2.0

Repeated - clickable:

http://subtextual.org/demo1.swf

http://subtextual.org/subtext2.swf - most interesting. Recommended.

http://coherence-lang.org/Onward09video/Onward09video.mp4

Sites:

http://subtextual.org/

http://coherence-lang.org/

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.

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

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.

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.

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.

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.

Dataflow languages are certainly great for many application domains for which they aren't currently used.

Alternative visual layouts remain to be proven in practice. This is another of a long line of experiments in alternative ways of editing source code. They always tend to work great for smallish examples, then start to quickly become unwieldy. I mean at the end of the second video you can already see that table becoming huge even with just three types of attacks. Imagine a real game with dozens of them and more complicated logic. Your computation is now spread out over meters horizontally and you'd find yourself dizzily scrolling back and forth to try to understand it all. Yes, being able to focus the table can help alot and if you got good at it maybe it'd be fine, but it remains to be proven in a real system. I'd like to see a major application built atop the system first.

What'd be really great is if you could also see/edit a textual (or pseudo-textual) representation and go back and forth.