Hacker News Reader

Comment by cortesoft | Hacker News Reader

This is not ‘no code’, anymore than someone programming in Python is doing ‘no code’ just because they aren’t programming in assembly.

A visual coding language is just providing a different abstraction, but it is still in the same space as other abstractions like a high level language such as Python.

Now, it might be hiding more behind the abstraction than a traditional high-level language, but that is a difference in degree and not kind. It does, however, mean that there are going to be more things that can’t be expressed in the visual language because the abstraction is too broad to be broken down enough. This means that a lot of the tasks that need to be done can’t use the abstraction and need a different programming language.

View on HN

The way we make progress is by hiding more and more things under better and better abstractions. So this is the way forward - if the abstractions are better.

But there are two problems here. The first is that you can make better abstractions in text-based languages, too. In fact, it's easier to do there. So the visual coding language is always easily caught by text-based languages. They may be easier to use for the layman, but they don't offer anything extra to the professional.

The second problem is that abstractions always have limits. Good (useful) languages give you a way to escape from the abstractions when you need to. Evil languages sucker you in and then trap you in a too-limited abstraction from which you can't escape. (It's not just visual languages, either. The original Pascal, before the Turbo extensions, had exactly this problem.)

> The first is that you can make better abstractions in text-based languages, too.

Not always:

The most general data structure is a directed graph. Is a formal textual description as good as shapes connected by arrows?

MIMD parallelism is straightforward with dataflow. (No worries about synchronization: processes wait until they've received all their inputs before running.) Again, shapes connected by arrows partially ordered in two dimensions is a more natural representation than text.

Finite state machines. Again, shapes connected by arrows is clearer.

>> The first is that you can make better abstractions in text-based languages, too.

>> Not always

Why are you writing and reading in text / code? Surprise, surprise - the English language is text / code. Please, to support your arguments send in some pictures or models or videos etc.

I've been working on http://web.onetel.com/~hibou/fmj/FMJ.html

It's ongoing work, and visible progress has been slow over the past year or so. Recently I've been refactoring the code, and improving the type system. One thing worth noting is that representation of functions as a graphs makes type inference more straightforward.

English and other languages are text because our ears hear a single stream of speech and written languages reflect that. Historically, computer programs are single streams of instructions because computers have until recently had processors only capable of doing one thing at a time, and we've usually programmed with text (GRAIL and DRAKON being exceptions) because that's all most terminals could display.

But for finding your way around a city by subway, representing an electric circuit, an organic molecule, or an elementary particle interaction, we use diagrams.

We should just use category-theoretic diagrams for everything.

> The most general data structure is a directed graph. Is a formal textual description as good as shapes connected by arrows?

Oh yes. My company used a "visual" programming language for a workflow project and it's pretty much a directed graph with nodes -- the whole thing takes 50 printed pages to see the whole thing and is pretty much impossible to understand. And it's not even that complicated of a workflow.

> Finite state machines. Again, shapes connected by arrows is clearer.

Only for mostly trivial state machines.

Reply on news.ycombinator.com