Perl6: The World's Worst ML?
aearnus.github.io
aearnus.github.io
Really? Every other language?
https://mitpress.mit.edu/sites/default/files/sicp/full-text/...
> The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells.
> A computational process is indeed much like a sorcerer's idea of a spirit. It cannot be seen or touched. It is not composed of matter at all. However, it is very real. It can perform intellectual work. It can answer questions. It can affect the world by disbursing money at a bank or by controlling a robot arm in a factory. The programs we use to conjure processes are like a sorcerer's spells. They are carefully composed from symbolic expressions in arcane and esoteric programming languages that prescribe the tasks we want our processes to perform.
> A computational process, in a correctly working computer, executes programs precisely and accurately. Thus, like the sorcerer's apprentice, novice programmers must learn to understand and to anticipate the consequences of their conjuring. Even small errors (usually called bugs or glitches) in programs can have complex and unanticipated consequences.
> Fortunately, learning to program is considerably less dangerous than learning sorcery, because the spirits we deal with are conveniently contained in a secure way. Real-world programming, however, requires care, expertise, and wisdom. A small bug in a computer-aided design program, for example, can lead to the catastrophic collapse of an airplane or a dam or the self-destruction of an industrial robot.
...
> The dialect of Lisp used in this book is called Scheme.
> One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be. (Fred Brooks)
Programming is much closer to swordsmithing. It is possible to create a sword that is both deadly and beautiful, but the former always takes precedence over the latter. Furthermore, there are clearly-defined constraints: you cannot smith an axe and call it a sword, just as you cannot write a web scraper and call it a raytracing engine. Art does not have this limitation. In any art medium, you can imagine creating a horribly mangled artifact, like a canvas smeared with random colors, or a piece of discordant music, or a violently disorienting video game -- and yet these would still be considered art. But a program full of syntax errors is like a cracked sword without a hilt: useless. Art cannot be useless.
A program full of syntax errors may not be a valid program, but it can be valid art.
Is this a valid program?
Well, probably not, right now as I'm writing this. But all it takes is someone writing an interpreter that maps words to a suitable instruction set. It probably won't do anything sensible, where do you draw the line? Translating code to other forms and back has a long history that very often has been about doing it for the sake of it rather than for functionality or practicality.
I've linked to this elsewhere:
https://www.reddit.com/r/programming/comments/b9fqwj/93_of_p...
But much more famous were the many incarnations of DeCSS that sought to to blur the lines between code and other expression:
"Is this a valid program?" is syntactically and semantically valid Ruby for example. But in itself it will just throw an error [some might argue this means it is not a valid program, but these errors are part of the normal runtime control flow of Ruby]. Depending on environment, however, it can do something else.
E.g. if your environment contains this:
def program?; 42; end
def valid(arg); arg; end
def a(arg); arg; end
def this(arg); arg; end
def Is(arg); arg; end
Is this a valid program?
A lot of random text will be valid programs in any number of existing languages without any intent for them to be so. But any random text can be valid programs in an infinite number of possible languages that does not yet exist.
So the question of what is a valid program is very much a philosophical one about whether or not the intent of the author matters in the face of processors that can re-interpret the data in ways it was not intended.
The programming I do for work is not. It needs to meet deadlines, and match expectations.
But I have dozens of projects sitting around that exist just for the sake of existing, or for some goal that is more about "because I think it'd be aesthetically pleasing" than because it's practical. Many people do. Sometimes it is an exploration of code for the sake of code. Sometimes it is an exploration of the effects of code.
Some of them might become practical one day. Then they'll cease to be as fun as they are now. I just spent most of the night wrangling a garbage collector for my ahead-of-time Ruby compiler for example - first time I've been able to spend serious time on it for a couple of years. The entire project is very much "because I can" and "because it pleases me" than for practical reasons; I make choices I wouldn't make if I needed to get something working within constraints. I make choices that actively cause more effort.
But conversely a lot of practical code has a feeling of art as well, in that there is the straight-forward way of doing it, the way everyone is used to, and then there is that way of doing it that blows your mind by showing possibilities you had not even imagined. Examples of that to me would be TCCBOOT [0]. The story of TCC itself is art to me - the original obfuscated version was 2048 byes of source. But to then take that, and turn it into something very little more and make it compile an OS during boot was not a practical goal, and not driven by utility - it was a mindbending demonstration of the possibility of producing a compiler that could compile a kernel from source and be competitive with loading a pre-compiled binary, and the beauty of what you can achieve with that simplicity. Nobody uses it. That's not the point.
The point is a lot of who saw it went on to think differently about how dynamic systems can be.
Massalin's Synthesis kernel [10] stands out to me as another example that for me crosses the boundaries and is both outstanding engineering and art in challenging the ideas of how systems could be built in ways that make me look at it just as much because of the beauty of it as because of the practical ideas. (The main thing it brought was the idea of making the kernel adapt to its clients by generating custom code for system calls; to me it is art because it turned the idea of a kernel as something static on its head; and conceptually we're still just scraping the very surface of dynamic code generation in kernels that Massalin's thesis started playing with). There are many works like that, where the specific implementations are irrelevant - nobody uses the Synthesis kernel - but where the ideas are as important as any expressed in more overt or "intentional" art.
> Furthermore, there are clearly-defined constraints: you cannot smith an axe and call it a sword, just as you cannot write a web scraper and call it a raytracing engine.
You might just find someone do that just to spite you. Just like someone wrote a paper on translating images of paint splatters into Perl [1] for the sake of it.
In fact someone has been there, done that, already, sort of [2] - not ray-tracing, but an art installation that downloaded random 3d models with a scraper and combined them.
Specific tasks and projects have constraints. Outside of that people make what they want, often for no particular reason, or for reasons that in retrospect look totally idiotic.
> Art does not have this limitation. Art does not have this limitation. In any art medium, you can imagine creating a horribly mangled artifact, like a canvas smeared with random colors, or a piece of discordant music, or a violently disorienting video game -- and yet these would still be considered art. But a program full of syntax errors is like a cracked sword without a hilt: useless. Art cannot be useless.
Software is full of horribly mangled artefacts that are considered valuable for the sake of it. The IOCCC [3] is a prime example, but so many projects I admire are projects that have all kinds of fatal or less fatal flaws but have something about them that is more art than craft. The entire history of esoteric languages [4] for example is about communicating ideas rather than making something useful. Sometimes they are mocking other languages - like INTERCAL, with it's wordy syntax drawing parallels to COBOL and FORTRAN, and it's reverse goto (come from) making regular goto's seem trivial - sometimes they are an exploration of minimalism, like Brainfuck, sometimes they are an exploration of what is possible - in Befunge control flow changes the direction source code is read in.
Whole categories of software has more to do with the aesthetics or other textual aspects of the program than utility - quines, obfuscated programs and golfing springs to mind.
Often the crossover is very direct: Whole genres of art are intimately tied with programming: Chiptunes are both closely tied to the hardware of the platforms they originated from, but many subsets are also intrinsically linked to a history where musical scores where expressed using custom players where musicians where often also the person to code the player. Rob Hubbard [5] is a famous example of a musician whose music was expressed as code (it was driven by data, but most of his C64 tracks are data for a single, specific iteration of his player code, so having "score" is insufficient; the score is incomplete without the code).
Many of his tracks stand out not just because of the musical qualities, but because they represented code as art. E.g. the Monthy on the Run theme [6] was renowned because of the technical challenge of getting that close to sounds of a string instrument on something as crazily basic as the C64 SID chip. I like the tune, but the masterpiece of art in that work is figuring out how to do that with patterns as simple as this: [7]. Another classic example would be his music for International Karate [8] which is a track I still love that is less impressive in terms of code (because the track demands less), but that still demonstrates an impressive mastery off both.
From the same era we also see graphics expressed as code to a greater and greater extent: The exploration of computational graphics became more and more important, but also the exploitation of the capabilities of the available systems to make graphics that was linked intimately to code. E.g. the various "FLI" modes on the C64 [9], or even just plain demos, where the code was part of the artwork: the systems could not display the art without the co-mingled code.
[0] https://bellard.org/tcc/tccboot.html and https://bellard.org/otcc/ [1] https://www.reddit.com/r/programming/comments/b9fqwj/93_of_p... [2] http://www.customarttools.com/blog/2016/2/26/fmdelivery [3] https://ioccc.org/ [4] https://esolangs.org/wiki/Esoteric_programming_language [5] https://www.c64-wiki.com/wiki/Rob_Hubbard [6] https://www.youtube.com/watch?v=4EcgruWlXnQ [7] https://www.youtube.com/watch?v=YIA_0cvS2gQ [8] https://www.youtube.com/watch?v=dvmSpZWW45k [9]http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm [10] http://www.scs.stanford.edu/nyu/04fa/sched/readings/synthesi...
This gives me an interesting idea: perhaps what makes something an art form is simply the degree to which it is done idly. I take it back: swordsmithing is an art form, but only in modern times, because we now produce swords primarily for their aesthetic value, rather than their utility in slaying foes. Likewise, programming today is mostly in the service of creating useful things to satisfy immediate needs -- but it's not hard to imagine a future where all programming is done by AI, and humans only program for fun. In that scenario, I think I would be much more willing to label it an art form.
Conversely, though, a lot of art is intentionally created and is someones job, so I find that distinction rather strained.
It's very specifically not a language that works like a finely tuned scientific instrument. It has the messiness of a paintbrush for an impressionist not the scalpel precision of an architect's toolkit.
It has just such a different feel that people who don't come from that mindset won't get it. It's not a superior language, just one that has a different way about it.
Mostly this:
>Ultimately, I think that we’re pretty happy with Perl 6 being the “World’s Worst ML”, so long as it can also (simultaneously) be: the “World’s Worst Smalltalk”, the “World’s Worst Lisp”, the “World’s Worst Snobol”, the “World’s Worst QCL”, the “World’s Worst Erlang”, the “World’s Worst Prolog”, the “World’s Worst Python”, the “World’s Worst C”, and even the “World’s Worst Perl 5”.
Because that was one of our design goals too. :-)
It's the worst ML because it's not an ML at all -- but it has the impressive ability to be able to emulate the behavior of one.
Otherwise it comes off as more cheap shots. Thanks for adding your comment, though! It helps :)
print_maybe :: Show a => Maybe a -> IO ()
print_maybe (Just m) = print m
print_maybe (Nothing) = putStrLn "nothing"
print_maybe = print . maybe "nothing" show print_maybe = putStr . maybe "nothing" ((++ "\n") . show)
print_maybe c = c >>= (\d -> print d >> putStr "\n")
sub print-maybe ( $_ ) {
say $_ // "nothing"
}
my &print-maybe = { say $_ // "nothing" }
(Think of defined-or `//` as having a slightly different slant to it than `||`.)
Myself I mostly write too long, slightly dry comments that get mostly ignored, or entirely misunderstood. Or so it seems at times. On the positive side, I feel I'm getting to the point a bit quicker, and with less triple negatives these days, any time now I might even get my point across in less than a few hundred words. Compared to you that get it across in 9 words, and the odd dozens of syllables, I still got ways to go!
---
Your comment would have been more useful with a short citation, but nevertheless, thanks! I didn't expect to be able to find that on Wikipedia (I assumed it was 'multi threaded language' or so).
So ML is a functional language. Apparently functional languages are not quite obscure enough, we need more words and abbreviations for things!
But then, I'm not sure perl has that facility at all.
A well-known ML example is Backus-Naur Form (BNF), which is a meta-language for specifying well-formed statements in a language. We use BNF to drive XTRAN's parsing engine, which executes the BNF at parse time.