Live data from Hacker News

Forty-Four Esolangs: The Art of Esoteric Code

spectrum.ieee.org

41–50 of 62 posts

Re: Forty-Four Esolangs: The Art of Esoteric Code

#41

Earlier quoted context omitted.

Forth isn't an esoteric programming language. The word “esoteric” has a specific meaning in this context.

What do you mean? It has a tiny compiler and is quite difficult to understand, are there are any other qualities required for inclusion or is there some secret that I'm not aware of?

FORTH is difficult to understand? I respectfully disagree. Well... I mean... if you can grok C, you can grok FORTH is my assertion. If you can't grok C or assembly, then sure, FORTH is pretty esoteric. But in that example, so is C.

It is most assuredly different than typical languages, but I don't think that means "esoteric". As an industry, we're sort of lost if "esoteric" means anything that doesn't look like Algol.

Re: Forty-Four Esolangs: The Art of Esoteric Code

#43
post #4

I don't know the list of languages included in the book, but anyone interested should try out: - J: https://www.jsoftware.com/#/ you'll learn arbitrary dimension arrays, verb composition and more - Lisp: I don't know the right Lisp to recommend. Macros stand out as something to learn - Forth: I don't know the right Forth to recommend. The stack is an interesting metaphor - A constraint-based language: maybe https://w…

Forth would be neat on an RPN calculator.

/random

Re: Forty-Four Esolangs: The Art of Esoteric Code

#44

Earlier quoted context omitted.

What do you mean? It has a tiny compiler and is quite difficult to understand, are there are any other qualities required for inclusion or is there some secret that I'm not aware of?

FORTH is difficult to understand? I respectfully disagree. Well... I mean... if you can grok C, you can grok FORTH is my assertion. If you can't grok C or assembly, then sure, FORTH is pretty esoteric. But in that example, so is C. It is most assuredly different than typical languages, but I don't think that means "esoteric". As an industry, we're sort of lost if "esoteric" means anything that doesn't look like Algol…

Forth is a bit of a headtrip for people due to (a) how it parses and executes and (b) the stack-based nature of it. Particularly, symbols traditionally considered syntactic are fair game* for user-space definitions, and some words are "immediate" which means that they act at compile time, where others act at runtime. This combination seems particularly challenging for students of languages which don't mix compile-time and runtime, only use a stack for function calls, etc.

I'm of the opinion that one must write a forth to grok forth, and I'm far from alone in that. However, I'd not quite call forth itself esoteric. But to many, it's a language family... of which most of the members are esoteric inasmuch they only have a single user.

* shout-out to my friend whose forth supports lists, hash tables, and structs through syntactic sugar... https://github.com/cstrainge/sorth

Re: Forty-Four Esolangs: The Art of Esoteric Code

#45
post #44

Earlier quoted context omitted.

FORTH is difficult to understand? I respectfully disagree. Well... I mean... if you can grok C, you can grok FORTH is my assertion. If you can't grok C or assembly, then sure, FORTH is pretty esoteric. But in that example, so is C. It is most assuredly different than typical languages, but I don't think that means "esoteric". As an industry, we're sort of lost if "esoteric" means anything that doesn't look like Algol…

Forth is a bit of a headtrip for people due to (a) how it parses and executes and (b) the stack-based nature of it. Particularly, symbols traditionally considered syntactic are fair game* for user-space definitions, and some words are "immediate" which means that they act at compile time, where others act at runtime. This combination seems particularly challenging for students of languages which don't mix compile-tim…

My bigger problem with read other people's Forth is that no two Forths are the same. The language itself isn't really the problem. It is that you can only approach someone else's Forth code bottom-up otherwise you just don't understand at all what is going on. Most other languages allow you to dive in from the top, learn as much abstraction as required to get the job done and then you can move on.

Re: Forty-Four Esolangs: The Art of Esoteric Code

#46
post #5

Ook! I love esoteric languages. They're a never ending rabbit hole, and they really force you to revisit all of your assumptions about what it means to program. The most interesting ones for me were the Lambda calculus and Brainfuck. And of course there is Forth. Which always felt like it was just around the corner from some kind of breakthrough but it never really happened. Collaborative software projects and all of…

Other's have mentioned that Forth isn't an esoteric language, however if you want a Forth written for an esoteric language I have written one for SUBLEQ (see https://esolangs.org/wiki/Subleq). Although SUBLEQ is more of an esoteric machine than a language, it also sort of qualifies as one (and has an entry on the esolangs Wiki).

It's available at https://howerj.github.io/subleq.htm if you want to try it online.

Re: Forty-Four Esolangs: The Art of Esoteric Code

#47
post #44

Earlier quoted context omitted.

FORTH is difficult to understand? I respectfully disagree. Well... I mean... if you can grok C, you can grok FORTH is my assertion. If you can't grok C or assembly, then sure, FORTH is pretty esoteric. But in that example, so is C. It is most assuredly different than typical languages, but I don't think that means "esoteric". As an industry, we're sort of lost if "esoteric" means anything that doesn't look like Algol…

Forth is a bit of a headtrip for people due to (a) how it parses and executes and (b) the stack-based nature of it. Particularly, symbols traditionally considered syntactic are fair game* for user-space definitions, and some words are "immediate" which means that they act at compile time, where others act at runtime. This combination seems particularly challenging for students of languages which don't mix compile-tim…

Why is RPN a head trip? Or rather... I don't think it's as much a head trip as prefix or infix notation. You've got your data. You've got your operation. Sometimes the data is on a stack. Sometimes it's on a heap. Just a little different way of specifying which is where.

Also... +1 on the "you've got to write it to understand it." And in the 80s, the documentation wasn't super. Leo Brodie's book was great to get you started, but understanding things like ' (tick) and how to program in "idiomatic forth" was a challenge. So I would add, "not only do you have to code FORTH to understand FORTH, you also have to rip someone elses' FORTH program apart to understand the more advanced bits." -- I could be wrong about that today, it's been a while since I did a survey of FORTH documentation.

Re: Forty-Four Esolangs: The Art of Esoteric Code

#48
post #44

Earlier quoted context omitted.

Forth is a bit of a headtrip for people due to (a) how it parses and executes and (b) the stack-based nature of it. Particularly, symbols traditionally considered syntactic are fair game* for user-space definitions, and some words are "immediate" which means that they act at compile time, where others act at runtime. This combination seems particularly challenging for students of languages which don't mix compile-tim…

My bigger problem with read other people's Forth is that no two Forths are the same. The language itself isn't really the problem. It is that you can only approach someone else's Forth code bottom-up otherwise you just don't understand at all what is going on. Most other languages allow you to dive in from the top, learn as much abstraction as required to get the job done and then you can move on.

I was famous at IBM for the quip: "The good news about FORTH is you can use it to write your own DSLs to model the problem you're working on. The bad news is the person down the hall already has." But we still used a metric butt-load of FORTH for board bring-up and firmware.

But more to your point. FORTH was used in a time when the predominant mode of coding was to construct more complex programs from less complex programs, so application developers usually got their hands dirty with some lower level aspects. That is... the application programmers chose the lower level abstractions they wanted to use. Now that we're beyond that and have, as an industry, decided that van Rossom and Latner are the only people who are allowed to define low-level abstractions, it's a lot harder to do that.

(Again, file this one under "old man yells at cloud.")

[2nd edit]

Maybe it's best to think of FORTH as a DSL construction kit. Lisp is kinda-sorta the same way. As you point out, it's super easy for someone to develop DSLs that require coders to understand not only their application domain, but also how the language and it's underlying hardware abstractions operate. And when you're using someone else's DSL, you have to understand how they thought about the problem domain. And we stopped teaching how to analyze that in the 80s.

Re: Forty-Four Esolangs: The Art of Esoteric Code

#49

Earlier quoted context omitted.

Forth isn't an esoteric programming language. The word “esoteric” has a specific meaning in this context.

What do you mean? It has a tiny compiler and is quite difficult to understand, are there are any other qualities required for inclusion or is there some secret that I'm not aware of?

This is a copy-paste of what I wrote elsewhere:

> Here's the definition from the esoteric programming language wiki, which is a lovely resource for anyone interested https://esolangs.org/wiki/Esoteric_programming_language:

> "An esoteric programming language is a computer programming language designed to experiment with weird ideas, to be hard to program in, or as a joke, rather than for practical use."

Post reply on HN