51–60 of 62 posts
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…
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…
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…
It isn't how we teach math in the two countries I've lived in. Lisp is just as weird. Many people see a mathematical expression and panic. A level up from them, people see a mathematical expression in some source code and expect it to respect the symbol precedence that they were taught in grade school -- which they can "understand" without knowing how the language parses and abstracts all that away. And maybe their understanding is flawed but they can survive as programmers for decades without ever going deeper. Lisps, FORTHs, etc., don't allow you to proceed without understanding.
Earlier quoted context omitted.
There's more than one good way to define "esoteric" but it gave me cognitive whiplash to hear the term used about lambda calculus. I can understand that perspective, there are plenty of purpose-built esolangs which are very close to the OG lambda calculus, and depending on your background the whole thing might seem bizarre and unfamiliar and ancient and irrelevant. At least logically I see that could happen, but my h…
Coding used to be about learning about the mathematical underpinnings of computation and then learning a specific mapping from the math to the software implementation. These days we don't teach that to undergrads (or maybe they get it in passing in a survey class.) We don't teach parsing. It seems we teach a list of features you should expect in your Python implementation or Linux version. Maybe you get a class on SQ…
Earlier quoted context omitted.
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 pr…
Earlier quoted context omitted.
> 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. Forth, (I think even more so than lisp), is fragmented, because its philosophy is not that you write “a forth program”, but that you write “a forth” that does what you need it to do. Don’t like the sign MOD chose to compute ‘-3124 modulo -17’? Don’t add a new one, but chang…
Interesting view. The way I approached Forth was to create a DSL that made it easier to write the application in. The biggest issues that I had with Forth were: hard to work on code as a team, the 'screens', finding it increasingly hard to name words.
You must have had the luxury of zillions (that is: > 16 kilobytes) of RAM and ROM.
> The biggest issues that I had with Forth were: […] the ‘screens’
Most Forths on larger machines, where you had the luxury of not needing to tweak the base system to fit all your code in are fine working with source files.
Screens were an invention for smaller systems (for those who don’t know: early forth didn’t have a file system, but just a way to load 1 kilobyte blocks from disk. Code was written in such 1 kB blocks, called ‘screens’ because 1kB effectively filled a 16 line by 64 character terminal screen)
Earlier quoted context omitted.
Coding used to be about learning about the mathematical underpinnings of computation and then learning a specific mapping from the math to the software implementation. These days we don't teach that to undergrads (or maybe they get it in passing in a survey class.) We don't teach parsing. It seems we teach a list of features you should expect in your Python implementation or Linux version. Maybe you get a class on SQ…
High-five! I also learned about all this as physics undergrad trying to escape from Fortran.
Although I discuss esolang history in the Spectrum piece (something I get deeper into on my blog, https://esoteric.codes), the book is a monograph of my esolangs specifically: Folders, Entropy, Olympus and more; some are collected at https://danieltemkin.com/Esolangs. It’s meant to make esolangs approachable, focusing on concept rather than technical aspects of the languages. I wrote it to encourage people to experiment with esolangs and to show the community-based nature of the work: the delightful conversation that happens when another programmer takes your language in a direction you would never have conceived of.
The languages range from fully implemented works to pieces that are not implementable (e.g. Past Tense is a language whose programs are not runnable by definition and would cease to be programs if they were https://github.com/rottytooth/PastTense). There’s one where even articulating a program into words or symbols invalidates it: only unreified thought is valid.
The languages are presented first as prompts. In the second half, I present details on those that are implemented, showing the sometimes surprising results of carrying out the initial idea. I hope it will expand the conversation around esoteric languages as an art form.
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.
The author's Olympus language is amusing, programs are expressed as prayers to ancient Greek gods. https://danieltemkin.com/Esolangs/Olympus/ It reminded me of an overambitious educational game idea: The player builds interpreters for prayers directed at several gods, each cult having its own theurgic practices resembling different programming paradigms: https://gashlin.net/blog/pages/2010-12-25-shell-script-of-th...
I was interested by the Olympus language when I saw it in TFA, but I'm a little sad that the authors website doesn't have even a basic spec. I still cant tell if the epithets are syntactic, or you just need some amount of them, like PLEASE in intercal EDIT: According to https://esolangs.org/wiki/Olympus , you need more epithets if the line of code is more demanding (?), and you need to use varying ones, but other tha…
> I try to write everything in JavaScript when I can and have it run in the browser. Question for the author if they are here: why not use one of the many languages that compile to Wasm to write compilers for esoteric languages?