Hacker News new | past | comments | ask | show | jobs | submit login
Perl6: The World's Worst ML? (aearnus.github.io)
100 points by hyperpallium 15 days ago | hide | past | web | favorite | 46 comments

To put it a bit over the top: In every other language you write code. Perl is magic and you write spells. It suppose to be this way, because the way it works is sorcery. I don’t know about you, but I always wanted to be a wizard, not a typist.

> In every other language you write code. Perl is magic and you write spells.

Really? Every other language?


> 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.

"we conjure the spirits of the computer with our spells" is one of my favorite quotes about computers with "Computer programming is an art form, like the creation of poetry or music" (Donald E. Knuth)

I have to disagree. Programming is certainly a craft, but it is not an art form. Programming is fundamentally a means to an end, whereas art can be an end in itself.

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 cracked sword without a hilt can't be called a sword, but it can be called art.

A program full of syntax errors may not be a valid program, but it can be valid art.

It may be art, but it is not programming anymore. Therefore reinforcing the idea that programming is not art.

What makes a valid program is not easy to define.

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:


But much more famous were the many incarnations of DeCSS that sought to to blur the lines between code and other expression:


A valid program in a given programming language has a precise definition.

Yes, but a given string of text does not specify a language.

"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
Then the string

    Is this a valid program?
Will execute and return 42.

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.

Sure, but only because "art" is essentially boundaryless and actively resists attempts to define it. If you stretch the definition far enough, everyone is an artist and everything is an artistic medium.

What you're responding to (and disagreeing with) is partially a misquote; see the full paper Computer Programming as an Art, which is Knuth's 1974 Turing Award lecture. (Available at http://www.paulgraham.com/knuth.html or http://www.cs.bilkent.edu.tr/~canf/knuth1974.pdf and reprinted with some minor corrections as the first chapter of the collection Literate Programming.)

Thanks, this is really interesting. I had a vague idea that "art" used to mean something different, but I didn't know it was akin to what we now call "engineering." By that definition, programming is unquestionably an art, but I would still argue that it doesn't fit under the more modern definition.

A lot of programming is an end in itself.

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...

Code is a medium; consequently, artists will use it to make art. I would agree that most of the examples you cited are artistic, but this does not make programming an art form, any more than a beautiful sword makes swordsmithing an art form or a beautiful sewer pipe makes civil engineering an art form.

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.

I work with software development, but the majority of my programming is still done idly, and to me that is the case for a lot of people who work with development, and many who do not.

Conversely, though, a lot of art is intentionally created and is someones job, so I find that distinction rather strained.

> The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.... Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. […] The magic of myth and legend has come true in our time.

> 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)

I'm not up on the newest Perls, but back in the day I wrote a lot of Perl 5. It always felt like having a nice conversation with my computer where I was eventually able to convince it to provide me with what I wanted it to do and sometimes it would just make leaps and figure it out for me or do what I meant.

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.

I concur!

I'd rather work with a typist than a wizard.

And I respect that.

It's been a while since I played with Perl. I haven't looked at Perl6 at all. But reading Damian Conway's addendum at the bottom, really makes me want to play around with 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. :-)

Wait what prolog?

Similarity that jumps out to me is that both include a large degree of support for grammars.

It’s the worst ML because it doesn’t look exactly like Haskell? Oh, no, it’s just click baiting using an easy target.

While I won't deny that using an eye catching title like that got me more clicks, I was trying to joke around with regards to Perl 6's flexibility.

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.

Considering the amount of crap that is heaped on Perl 6 for even daring to exist, maybe in the future you might consider using language that highlights something that you find impressive.

Otherwise it comes off as more cheap shots. Thanks for adding your comment, though! It helps :)

The rewrite he included down the bottom from one of the Perl 6 developers is very readable, I might actually have a play with Perl 6 next time I get a moment.

It's certainly not as readable as the Haskell version, despite the claim to the contrary in the comments. But it's nice to see them supporting this style of programming.

Sure, but for anyone with any familiarity with that style (I know it from Erlang), it's immediately clear what it does.

Yeah a bit and haskell is not even the most readable ML in my opinion sml is much more readable as it does not have as many strange symbols scattred around.

There are relatively few symbols in the core language; mostly just '|', '->', '=>', '::', '=', '_', ',', lambda (\_ ->) , and brackets, but people do sometimes go over the top with operators.

I used to joke that Perl5 was the worst Lisp. I think the author is being jocose.

I thought this was sarcasm. Both code snippets are gibberish to me.

Since it's a Perl article, can we golf? Just as Conway shows that we can re-write the Perl, also the Haskell can be re-written. In general, manually dispatching by pattern matching on a `Maybe` type I think indicates that you should be using `maybe`; I would want to replace

    print_maybe :: Show a => Maybe a -> IO ()
    print_maybe (Just m) = print m
    print_maybe (Nothing) = putStrLn "nothing"

    print_maybe = print . maybe "nothing" show

If we are going to golf, here is a small Perl6 version:

    sub print-maybe ( $_ ) {
      say $_ // "nothing"
Or to translate your code:

    my &print-maybe = { say $_ // "nothing" }
Of course both of the above take advantage of all Perl6 types being Maybe types already.

(Think of defined-or `//` as having a slightly different slant to it than `||`.)

not quite the same as what I wrote -- it would be more akin to:

    print_maybe = putStr . maybe "nothing" ((++ "\n") . show)
or maybe something like:

    print_maybe c = c >>= (\d -> print d >> putStr "\n") 
but that's already too long to finish

According to https://hackage.haskell.org/package/base- , `print` already appends a newline, so I think that `print m` is not the same as `putStr $ show m` and hence that the refinements you suggest are unnecessary.

Sometimes I feel my only purpose here is to repost xkcd:


At least as good a purpose as any other. I would even go as far as claiming it as one of the finer purposes one can have. Using ones abilities selflessly in a way that helps bring a smile peoples faces is one of the finer aspect of humanity, at least if you ask me.

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!

what is ML?

> ML (Meta Language) is a general-purpose functional programming language.


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!

The term "meta-language" shouldn't be used to identify a specific language; it's a general term for a language that describes or manipulates another language(s). For instance, the rules language for XTRAN, our Expert System, is a meta-language, and we call it "meta-code", because it manipulates many different computer languages (including itself!), as well as data and text.

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.

Meta languages normally imply that you can program the language syntax itself via an extensive macro system.

But then, I'm not sure perl has that facility at all.

It does. It's small and hacky, but powerful enough to do things like http://p3rl.org/Moops

Far too overloaded a term these days :(

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact