Hacker News Reader

Comment by afarrell | Hacker News Reader

I’m interested to know what sort of insights you get from creating a language like this.

I can answer this. The biggest insight I've gained from going deep into language implementation is that primitive and fundamental concepts do not go away even if things are abstracted by high level features in high-level languages. For example, loops, jumps, will find themselves underlying in any language implementation regardless of the languages abstractions.

Do you mean for all imperative languages? Functional or declarative languages can do away with loops and jumps. Not trying to nitpick, perhaps you had some further insights when creating this

> Do you mean for all imperative languages? Functional or declarative languages can do away with loops and jumps.

At the programmer interface, sure. At the implementation level ("underlying"), all that abstraction is being turned into loops and jumps.

The functional language does do away with loops, but when the rubber nets the road, you don’t have any choice: somewhere, something will execute the equivalent of “for(int i = 0; i <= 10; i++) {}”.

When I implemented Mindcode, I realized that “while” is the basic construct and that all enumerations and looping compiled down into goto.

Mindcode is a Ruby-like language for the Mindustry game. Mindustry has an assembly-like language with a visual editor in-game. Mindcode has a more traditional text-based flow.

> somewhere, something will execute the equivalent of “for(int i = 0; i <= 10; i++)

Not necessarily; depending on what's going in in the loop, you can compile the code into parallel non-looping instructions that execute on multiple cores or threads. No loops needed.

That's a very specific special case. For instance, if you have more iterations than cores or processors, you'll still need to do looping somewhere.

In the general case, the statement is still true.

It's a specific case but not a very specific case, and one that is becoming more common as core counts are exploding.

And anyway, even if it were a very specific case it's still an existence proof that disproves the assertions that "all that abstraction is being turned into loops and jumps." as one other poster put it. The replies here are speaking in very absolute terms ("you don’t have any choice", "loops and jumps cannot ever go away regardless of the higher level abstractions"), which are not true in an absolute sense.

The OP said:

> Do you mean for all imperative languages? Functional or declarative languages can do away with loops and jumps

And everyone here is answering them so far from the perspective of imperative languages. But depending on the program, it's not necessarily the general case in declarative languages, where we have much more freedom to compile things as we want, including without loops where they would be used in an imperative language.

Since this is a thread about language design and we're talking about alternative paradigms and how things get compiled to instructions, it's absolutely true that if our problem can be parallelized we don't have to loop at all. This is not a special case, but something that is generally applicable to many kinds of situations. Now that we're entering a world of potentially 1000s of cores available on consumer CPUs in the near future, what I'm saying is going to become the general case more and more.

If the iteration bounds are statically known (i.e. 0...10 in above example) you can avoid the loop by unrolling it, or using some kind of explicit parallelism, like SIMD for example.

In general, the iteration bounds aren't known and some kind of loop is required.

Totally reductionist on my part, but when you've written assembly by hand you realise that loops and jumps cannot ever go away regardless of the higher level abstractions.

At least I'm not aware of any CPUs that are not imperative in operation.

OP said

> primitive and fundamental concepts do not go away even if things are abstracted by high level features in high-level languages.

Loops do not go away in fp. They are just hidden under layers of abstraction.

Most fp loop-like things are recursion. Traditional iterative loops are abstractions over goto. Arguably a function call is an abstraction of goto (JMP)+stack manipulation.

So they are both abstractions over goto, but i would say they are sibling abstractions not parent/child.

This implies a compelling challenge: create a language where the concept of a loop or iterator is abstracted away.

APL and other array programming languages are this.

The loops are obviously there deep down the the language that they are implemented in but you never explicitly use them.

Reply on news.ycombinator.com