The author chose Forth, Occam, APL, Simula, SNOBOL, Starset, and m4 as the set of seven with the objective of broadening the reader’s perspective. All of these languages have available implementations. Would you exchange any of these languages for a different “obscure” language?
Definitely Self. It’s what I believe to be the ultimate object programming experience. The language is still maintained (although pretty inactively) and there has been a new release just this year. Its optimization technologies underpin almost every dynamically typed programming language VM (V8, JSC, PyPy, …).
There are thousands of obscure languages, and possibly more that were never released. Off the top of my head I can name ICON, Alice, and Hope. But perhaps the most obscure language I am aware of (that to my knowledge, had a commercially available compiler, and only two commercial products were ever produced with it) is INRAC. The central conceit of INRAC is a line-oriented (each line is a sub-routine, except if it ends with a GOTO-NEXT-LINE marker), nondeterministic execution.
SNOBOL is so primitive that it is virtually unusable from a modern perspective. Interesting from the point of view of understanding how low the standards could be for a programming language back in the 1960’s, even though good languages were also being used at that time.
Instead of SNOBOL I would pick Icon, a modern and usable SNOBOL successor, which is mind expanding, and gives you a new perspective on programming, but in a GOOD way. https://www2.cs.arizona.edu/icon/
I’ve used occam exactly once and would pick erlang over it because occam is very limiting. It deliberately cannot express things like programs that can use an amount of memory or stack space that is determined at runtime. The entire communication structure and everything is all fixed up front. Channels aren’t first class values.
Occam was co-designed with the transputer. The 1980s transputers had communications links whose topology was fixed by the way the hardware was wired together. Much of the runtime support was implemented in silicon. So an occam program would be compiled to match the hardware it would run on. It wasn’t until the 1990s with the T9 project that transputers became more dynamic. There were some useful spinouts: the physical layer of the T9 fast links was reused by FireWire, the fast link crossbar switch was reused for ATM — but the T9 itself failed. I don’t know if there was a new more dynamic version of occam to go with the more capable hardware.
The conceptual model and formalism underlying Occam is what’s called a process calculus. It was developed by Milner. Later versions include CCS, the Pi-calculus, and his final version, the bigraph model. All of these have been influential in different ways, but the earlier formalisms map better to hardware.
All of these languages have available implementations.
Are you sure? I’ve looked for a Starset implementation in the past, and tried again just now. I can’t find it. The author is a professor at Suffolk University, and supervised a student implementing a Starset compiler, but it appears to not be publically available online.
There’s very little information available online about Starset, but it appears to be a database query language for a database model based on sets (rather than the more familar models based on relations, graphs, etc). I can’t even find a language specification online, just vague sketches about what the language does.
I would instead choose the language “Setl”, which is a general purpose programming language based on set theory. Sort of like APL, except for sets (and tuples, maps, relations, and powersets) instead of arrays. It may be obscure, but it was also influential. It borrowed the idea of set comprehensions from mathematics and made them into a programming language feature. The list comprehensions in Python, Haskell, etc, come from Setl. https://en.wikipedia.org/wiki/SETL https://setl.org/setl/
On Starset availability: I missed this caveat the first time: “Finally, a Starset interpreter, christened “Suffolk Starset” or s3, is developed and maintained by the team at my own Suffolk University. Its GitHub repository will be made public as soon as we release the first fully functional version.”
You probably have it installed right now. A templating system without any other dependencies out of the box that’s usable from a shell script. Yes really!
m4 has its origins in GMP, Strachey’s general-purpose macro-processor that was used to implement CPL and early versions of BCPL as a kind of macro-assembler. Another predecessor of m4 was used to implement RATFOR. Very intertwined with the prehistory of Unix and C, and one of the less well-known British influences. There’s more in the history section of gnu m4’s manual.
There’s a curious difference between macro processors and templating engines.
Macro processors typically just process one or more input files, maybe with some predefined macros that can adjust how the file is processed, like -Dfoo=bar on the command line. The variable namespace is flat.
Template processors take a template and some structured data as inputs. There’s better support for walking through nested data. There’s more emphasis on composing paetial templates in the context of some subtree of the data.
I feel like I used it a lot ~25 years ago, likely for configuration of some email system? It sounds very familiar, but I can’t figure out what it would have been for.
m4 is used to configure sendmail and for templating shell scripts in autoconf. Neither of these are fun to use so m4 has been rather tarnished by association.
Sendmail! Of course. I was thinking it was a different MTA and not the granddaddy of them all. Not “fun to use” is an understatement. My favorite sendmail quote is a take on the “million monkeys”[1] meme:
A million monkeys typing at a million keyboards for a million years could eventually produce the works of Shakespeare, but they still couldn’t create a valid sendmail.cf file.
Yup. There’s an 800+ page O’Reilly book just on the Sendmail configuration file. And you know you are in trouble when the configuration file [1] has a configuration file.
[1] It should really be listed as an esoteric programming language as it is Turing complete.
It’s a fun little tool and I use it for my blog; that said I would have a hard time recommending a language that lacks loops for anything more complex than a blog. (You can implement loops using recursive macros but it is not pretty.)
Flagged, this is just a product page y’all.
yes, and OP’s comment is LLM generated, a question with such false interest is a dead giveaway.
The author chose Forth, Occam, APL, Simula, SNOBOL, Starset, and m4 as the set of seven with the objective of broadening the reader’s perspective. All of these languages have available implementations. Would you exchange any of these languages for a different “obscure” language?
I honestly don’t think Forth is obscure as opposed to old. I’d pick something like ATS (http://www.ats-lang.org/) over Forth.
I’ve been learning this one. Quirky keyword usage, but amazing ideas & performance opportunity.
I have a very soft spot for M(UMPS), not sure if I’d change any of the propose languages for it…
Definitely Self. It’s what I believe to be the ultimate object programming experience. The language is still maintained (although pretty inactively) and there has been a new release just this year. Its optimization technologies underpin almost every dynamically typed programming language VM (V8, JSC, PyPy, …).
There are thousands of obscure languages, and possibly more that were never released. Off the top of my head I can name ICON, Alice, and Hope. But perhaps the most obscure language I am aware of (that to my knowledge, had a commercially available compiler, and only two commercial products were ever produced with it) is INRAC. The central conceit of INRAC is a line-oriented (each line is a sub-routine, except if it ends with a GOTO-NEXT-LINE marker), nondeterministic execution.
I know of Racter. What was the other one?
It was a program to help write poetry. I unfortunately don’t recall the name.
INRAC sounds interesting, I can’t find anything about it online, does anything about it even exist anymore?
Only in a few places. I have several entries about INRAC (an isolated entry from 2008 and there are several over a two month span in 2015) and I have found two repositories on Github but haven’t gone into depth with those). And that’s about it.
SNOBOL is so primitive that it is virtually unusable from a modern perspective. Interesting from the point of view of understanding how low the standards could be for a programming language back in the 1960’s, even though good languages were also being used at that time.
Instead of SNOBOL I would pick Icon, a modern and usable SNOBOL successor, which is mind expanding, and gives you a new perspective on programming, but in a GOOD way.
https://www2.cs.arizona.edu/icon/
I’ve used occam exactly once and would pick erlang over it because occam is very limiting. It deliberately cannot express things like programs that can use an amount of memory or stack space that is determined at runtime. The entire communication structure and everything is all fixed up front. Channels aren’t first class values.
Occam was co-designed with the transputer. The 1980s transputers had communications links whose topology was fixed by the way the hardware was wired together. Much of the runtime support was implemented in silicon. So an occam program would be compiled to match the hardware it would run on. It wasn’t until the 1990s with the T9 project that transputers became more dynamic. There were some useful spinouts: the physical layer of the T9 fast links was reused by FireWire, the fast link crossbar switch was reused for ATM — but the T9 itself failed. I don’t know if there was a new more dynamic version of occam to go with the more capable hardware.
Yeah I know. I took a class taught by David May.
I still think Occam sucks.
The conceptual model and formalism underlying Occam is what’s called a process calculus. It was developed by Milner. Later versions include CCS, the Pi-calculus, and his final version, the bigraph model. All of these have been influential in different ways, but the earlier formalisms map better to hardware.
Are you sure? I’ve looked for a Starset implementation in the past, and tried again just now. I can’t find it. The author is a professor at Suffolk University, and supervised a student implementing a Starset compiler, but it appears to not be publically available online.
There’s very little information available online about Starset, but it appears to be a database query language for a database model based on sets (rather than the more familar models based on relations, graphs, etc). I can’t even find a language specification online, just vague sketches about what the language does.
I would instead choose the language “Setl”, which is a general purpose programming language based on set theory. Sort of like APL, except for sets (and tuples, maps, relations, and powersets) instead of arrays. It may be obscure, but it was also influential. It borrowed the idea of set comprehensions from mathematics and made them into a programming language feature. The list comprehensions in Python, Haskell, etc, come from Setl.
https://en.wikipedia.org/wiki/SETL
https://setl.org/setl/
On Starset availability: I missed this caveat the first time: “Finally, a Starset interpreter, christened “Suffolk Starset” or s3, is developed and maintained by the team at my own Suffolk University. Its GitHub repository will be made public as soon as we release the first fully functional version.”
The github repository referenced is https://github.com/dzinoviev/starset (and is not available at the time of this writing).
I feel like no survey like this is complete without some logic programming. Maybe some Soufflé?
The previous volume had MiniKanren so maybe the editors felt that was a strong enough taste, maybe?
Really wish m4 wasn’t as obscure as it was.
You probably have it installed right now. A templating system without any other dependencies out of the box that’s usable from a shell script. Yes really!
I use it all the time.
m4 has its origins in GMP, Strachey’s general-purpose macro-processor that was used to implement CPL and early versions of BCPL as a kind of macro-assembler. Another predecessor of m4 was used to implement RATFOR. Very intertwined with the prehistory of Unix and C, and one of the less well-known British influences. There’s more in the history section of gnu m4’s manual.
There’s a curious difference between macro processors and templating engines.
Macro processors typically just process one or more input files, maybe with some predefined macros that can adjust how the file is processed, like -Dfoo=bar on the command line. The variable namespace is flat.
Template processors take a template and some structured data as inputs. There’s better support for walking through nested data. There’s more emphasis on composing paetial templates in the context of some subtree of the data.
I feel like I used it a lot ~25 years ago, likely for configuration of some email system? It sounds very familiar, but I can’t figure out what it would have been for.
m4 is used to configure sendmail and for templating shell scripts in autoconf. Neither of these are fun to use so m4 has been rather tarnished by association.
Sendmail! Of course. I was thinking it was a different MTA and not the granddaddy of them all. Not “fun to use” is an understatement. My favorite sendmail quote is a take on the “million monkeys”[1] meme:
[1] https://en.wikipedia.org/wiki/Infinite_monkey_theorem_in_popular_culture
Yup. There’s an 800+ page O’Reilly book just on the Sendmail configuration file. And you know you are in trouble when the configuration file [1] has a configuration file.
[1] It should really be listed as an esoteric programming language as it is Turing complete.
Yeah sendmail was my first exposure to m4 as well.
It’s a fun little tool and I use it for my blog; that said I would have a hard time recommending a language that lacks loops for anything more complex than a blog. (You can implement loops using recursive macros but it is not pretty.)