The "other" languages

Praise or bash your exotic language of choice.

I'm currently looking into J. It achieves great terseness at the price of the syntax being incomprehensible by the average human. Where other languages would use keywords, J uses symbols.

I am however mesmerized by the promises of high-level power.

Example code (J is interpreted):
1
2
3
4
5
6
   mean =. +/ % #
   mean 1 2 3 4 5
3
   mean 1 2 3 4 5 6
3.5
   

Not so much a programming language, but I've been finding awk really useful at work lately.
J is awesome (and the people who use it in finance are equally awesome), but my heart belongs to Forth (or, to be hip and edgy, Factor).

(Factor to Forth is kind of like J to APL, a modern revival of a unique programming paradigm started by a way-ahead-of-its-time language from the 60s.. although the Forth fandom is definitely more numerous than the adepts of the "Alien Programming Language")
Last edited on
I've been seeing a lot of J, K, and APL lately and it seems really interesting. Though incredibly unreadable if you've never seen it before. Are they really used in the real word? I can't see how they would actually accomplish anything nontrivial
@ResidentBiscuit they are - personally, I've seen them in active use at Maple Securities, to give a specific example, and from the look of things, they are not alone.

The APL interpreters/IDEs are not free though:
http://www-142.ibm.com/software/products/us/en/workapl2formult
http://www.dyalog.com/prices_conditions.html
I can't see how they would actually accomplish anything nontrivial

You've seen them used mostly in Project Euler, am I correct? ... solving problems which I wouldn't call "trivial". Otherwise, what do you mean by "nontrivial"?

From what I've seen so far, J is primarily a mathematician's language.
Besides the built-in math "verbs" (as opposed to being put in a math library), J offers pretty plotting and graphing libraries, and eagerly supports extended precision i.e. big integer arithmetic.
You would never really want to program with it but its pretty cool:

http://en.wikipedia.org/wiki/Chef_(programming_language)

Its a programming language discuised as a recipy :)
The project euler problems fall under the category "trivial" programming wise, as do pretty much all math-related problems (except if it's a very complex computation that requires lots of arcane trickery to just get a result).
If we're going into esoteric languages, Shakespeare wins hands-down.
Romeo, a young man with a remarkable patience.
Juliet, a likewise young woman of remarkable grace.
Ophelia, a remarkable woman much in dispute with Hamlet.
Hamlet, the flatterer of Andersen Insulting A/S.

                   Act I: Hamlet's insults and flattery.
                   Scene I: The insulting of Romeo.
[Enter Hamlet and Romeo]
Hamlet:
You lying stupid fatherless big smelly half-witted coward! You are as
stupid as the difference between a handsome rich brave hero and thyself!
Speak your mind!
You are as brave as the sum of your fat little stuffed misused dusty
old rotten codpiece and a beautiful fair warm peaceful sunny summer's
day. You are as healthy as the difference between the sum of the
sweetest reddest rose and my father and yourself! Speak your mind!
You are as cowardly as the sum of yourself and the difference
between a big mighty proud kingdom and a horse. Speak your mind.
Speak your mind!
[Exit Romeo]
                   Scene II: The praising of Juliet.
[Enter Juliet]
Hamlet:
Thou art as sweet as the sum of the sum of Romeo and his horse and his
black cat! Speak thy mind!
[Exit Juliet]
                   Scene III: The praising of Ophelia.
[Enter Ophelia]
Hamlet:
Thou art as lovely as the product of a large rural town and my amazing
bottomless embroidered purse. Speak thy mind!
Thou art as loving as the product of the bluest clearest sweetest sky
and the sum of a squirrel and a white horse. Thou art as beautiful as
the difference between Juliet and thyself. Speak thy mind!
[Exeunt Ophelia and Hamlet]

                   Act II: Behind Hamlet's back.
                   Scene I: Romeo and Juliet's conversation.
[Enter Romeo and Juliet]
Romeo:
Speak your mind. You are as worried as the sum of yourself and the
difference between my small smooth hamster and my nose. Speak your
mind!
Juliet:
Speak YOUR mind! You are as bad as Hamlet! You are as small as the
difference between the square of the difference between my little pony
and your big hairy hound and the cube of your sorry little
codpiece. Speak your mind!
[Exit Romeo]
                   Scene II: Juliet and Ophelia's conversation.
[Enter Ophelia]
Juliet:
Thou art as good as the quotient between Romeo and the sum of a small
furry animal and a leech. Speak your mind!
Ophelia:
Thou art as disgusting as the quotient between Romeo and twice the
difference between a mistletoe and an oozing infected blister! Speak
your mind!
[Exeunt]
Last edited on
Lol wut, is that really what shakespear wrote? I couldn't stop laughing at the "speak your mind" phrase.
I'm really digging Clojure lately.
It's an esoteric programming language. It's quite interesting how it works. The first line is a title (omitted in that example; I don't know why) and then you follow with a list of characters (such as Romeo, Juliet, Hamlet, Othello, etc.) which you name and describe (the description is ignored by the parser) at the top of the file. These are your variables. They have to be named after a character from a Shakespearean play.

Next, you have acts and scenes which are like functions (you can jump between acts and scenes by saying something like "Let us return to Act II Scene I"). Each Act and Scene has a number in Roman numerals and a title (I believe the parser ignores the title as it does with character descriptions). Control just flows down the program unless you explicitly return to an earlier Act/Scene.

You state which characters are in the scene at various times using the [Enter] and [Exit] directives and that lets you use those variables in that scope. Then you can have one character store data in another character. I can't remember exactly how the arithmetic works, but you start with "You are " and then describe them qualitatively, using positive, neutral and negative adjectives. I can't remember, but I think "You are as <adjective> as <character>" just takes the value from one character and stores it in another. "Speak your mind!" tells a character to output its data as ASCII. You can also do input and use characters as stacks, but I don't remember how that works.

My second favourite esoteric language is Rail:
1
2
3
$ 'main' (--):
 \
  \-[Hello World!\n\]o-# 

You basically draw a train track in ASCII and that tells the interpreter what to do.
The project euler problems fall under the category "trivial" programming wise, as do pretty much all math-related problems (except if it's a very complex computation that requires lots of arcane trickery to just get a result).


I think I sort of understand what your saying, but I pretty much have to disagree on this.

Math related problems like Project Euler are all about algorithm design, and problem solving, which is the most non-trivial aspect of programming in my opinion.

Math related problems like Project Euler are all about algorithm design, and problem solving, which is the most non-trivial aspect of programming in my opinion.


Most programs do not need low-level algorithms like that, and even if they do, these algorithms are usually already implemented in software libraries, sometimes even in standard ones. Much more non-trivial aspect of programming is high level design and architecture. Most (all?) people get it wrong. Well, I doubt there is anyone who doesn't get it wrong more often than not.
Much more non-trivial aspect of programming is high level design and architecture. Most (all?) people get it wrong. Well, I doubt there is anyone who doesn't get it wrong more often than not.


True. I was thinking about the field of mathematical research, game AI, modeling, statistical analysis, signal processing etc. All of these areas are heavily dependent on mathematical algorithm design, and most definitely are not trivial in any sense.

Sure syntactically they are trivial, but programming isn't all syntax and design architecture.
Last edited on
I'm not saying that writing a function that maps some input to some output is always easy, I'm saying it's a trivial problem programming wise because there isn't that terribly much you can do wrong (again, relatively speaking. If it's a very complex computation that spans hundreds to thousands of lines of code spanning multiple files, you still probably screw up somewhere), and checking for partial correctness usually isn't that hard either. Designing large and complex systems is a much more involved task, and the only way to measure the quality of the result is the difficulty you face when your employer suddenly wants another feature until next week.
Topic archived. No new replies allowed.