Hacker News Reader

Comment by flukus | Hacker News Reader

I don't think the leap to visual programming is necessary considering we have tools like make that work essentially identically and remain text based. All this is really doing is moving the dependency declaration to lines instead of words and this would get very messy very quickly.

An example in make (if I'm reading in the right direction) format which I'd argue is more readable and could scale much better would be:

  doA: doC doE
  doB: doD doE
  doC: doE
  doD:
  doE

View on HN

Shouldn't it be like

doE: doC, doB, doA doD: doB

etc?

anyways the problem with this approach is that doD() is assumed to be a general function (or statement or async command) that is not by definition bound to doB(), but rather in this specific case we need it to be executed after doB() is done.

> but rather in this specific case we need it to be executed after doB() is done.

Why is that? If it needs any result from doB() then it is a dependencies that must be specified. If it needs to be done only after doB is successful then it is a dependency, just an implicit one we rely on the procedural execution to handle. In either case some sort of surrogate dependency (or better syntax) would have to be introduced.

But the point is that either would necessitate or be aided by graphical programming.

ok imagine doB() is a function that loads a record from the database and doD() is for example a password hash matcher (really imperfect example, just trying to get the point across). You might want to use both doB() and doD() in other contexts as well, so basically it is not the case that you would want to execute doD() always after executing doB(), neither is it the case that executing doD() always requires executing doB() beforehand. It just happens that in a specific case you would want to execute doB() and then pass its result to doD().

Reply on news.ycombinator.com