Hacker News new | past | comments | ask | show | jobs | submit login

Text does have the advantage of incumbency. When programming languages were first developed, we had teletype terminals which only accepted a limited character set and no graphical input devices, and CPUs which could only execute a single instruction at a time. That constrained the languages people could develop. After adding decent graphics terminals and multi-core CPUs, and noting that most algorithms have instructions which can be executed in parallel, implementing programs as directed graphs makes a lot more sense.

Text-based languages can still be very different from one another. There's only the appearance of similarity now because most programming languages, and all mainstream ones, are descendants of ALGOL60, influenced to a greater or lesser extent by Smalltalk and Lisp. There's almost nothing in common between Prolog and C, for example.

How can you read any program without the (source) code on hand? The same problem occurs, for example, with Java byte code.

That isn't my issue. My issue is that which you may see in APL. Even if you got APL source code, you wouldn't necessarily be able to read it. FMJ source isn't textual. If you don't have the FMJ runtime on hand, no only can you not run the source, you cannot READ it, either.

And programming as a directed graph isn't a bad idea, but there must be a canonical, easily readable, textual format, that is the DEFAULT, regardless of how you manipulate it.

Tangenting off your mention of parallelism, I wonder if one of the potential advantages of a graphical language is that it strongly encourages people to keep their code clean and maintainable. I imagine code with a tangled structure that relies heavily on side effects would be downright painful to look at in a graphical language - just a rat's nest of criss-crossing lines.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact