Larry Wall's quest for a 100-year programming language(thenewstack.io)
thenewstack.io
Larry Wall's quest for a 100-year programming language
https://thenewstack.io/larry-walls-quest-100-year-programming-language/
20 comments
> Larry Wall doesn't want to design a language anymore, he wants to create the ultimate platform for creating languages.
racket has managed to do that while delivering a pretty damn good language too. i'm long-term optimistic about perl6.
racket has managed to do that while delivering a pretty damn good language too. i'm long-term optimistic about perl6.
When racket is running on the Chez scheme VM...now that will be special...and fast.
Actually if you define the COBOL slang well, you can add a construct which will allow dropping back down into Perl 6 so that you can intermix both languages and use each to their strengths in the same file.
That is how the string literal and regex sub-languages work in Perl 6.
Frankly while that is a nice feature, and makes it easy to test bug fixes to the compiler using the REPL, I don't think that it is the best selling point. Mostly because it is only used by a handful of modules currently, and most users of those modules don't care how they work.
I think it is better to say that Perl 6 is a rather flat language. Once you learn a feature, you can use it everywhere. For example there are languages that have special syntax for use in list slicing, whereas it isn't special in Perl 6. (instead you can use a lambda to do more complex slicing)
What this means is if you see a construct that you've already seen, but it is used in a place you didn't think it would work, you can pretty much guess immediately how it works. For example an <code>if</code> block can be parameterized using the exact same syntax as parameterizing the block of a <code>for</code> loop. Which is useful so that you don't have to create a temporary variable, or call the same method twice. (It isn't all that useful when using the comparison operators which only return True or False though)
The most oft heard complaint among people who are adept at Perl 6, is about having to go back to another language. I think the main reason for this is Perl 6 bends to your will, and other languages bend you to it's will.
That is how the string literal and regex sub-languages work in Perl 6.
Frankly while that is a nice feature, and makes it easy to test bug fixes to the compiler using the REPL, I don't think that it is the best selling point. Mostly because it is only used by a handful of modules currently, and most users of those modules don't care how they work.
I think it is better to say that Perl 6 is a rather flat language. Once you learn a feature, you can use it everywhere. For example there are languages that have special syntax for use in list slicing, whereas it isn't special in Perl 6. (instead you can use a lambda to do more complex slicing)
What this means is if you see a construct that you've already seen, but it is used in a place you didn't think it would work, you can pretty much guess immediately how it works. For example an <code>if</code> block can be parameterized using the exact same syntax as parameterizing the block of a <code>for</code> loop. Which is useful so that you don't have to create a temporary variable, or call the same method twice. (It isn't all that useful when using the comparison operators which only return True or False though)
The most oft heard complaint among people who are adept at Perl 6, is about having to go back to another language. I think the main reason for this is Perl 6 bends to your will, and other languages bend you to it's will.
> Javascript
I think Python would be so much better. These languages are almost the same technically, but Python has the better syntax and better errors.
(ok I just realise it hasn't the same support for lambdas but they just make me think of node.js style anyway...)
I think Python would be so much better. These languages are almost the same technically, but Python has the better syntax and better errors.
(ok I just realise it hasn't the same support for lambdas but they just make me think of node.js style anyway...)
You would have to name off a long list of languages before you hit one I didn't think was better than Javascript.
Python does seem to hit the sweet spot of "user friendly" and "maintainable" that Javascript shoots for but never hits.
I actually consider Dart the "perfect" Javascript. I wish it had wider adoption, and ways to integrate a GUI that aren't "AngularDart in a web browser."
Kotlin is my latest fetish. I haven't played around with its JS transpiler yet, or it's native builds, but I'm cautiously hopeful.
Python does seem to hit the sweet spot of "user friendly" and "maintainable" that Javascript shoots for but never hits.
I actually consider Dart the "perfect" Javascript. I wish it had wider adoption, and ways to integrate a GUI that aren't "AngularDart in a web browser."
Kotlin is my latest fetish. I haven't played around with its JS transpiler yet, or it's native builds, but I'm cautiously hopeful.
haxe comes a little closer to the perfect javascript than dart does, just because it has algebraic datatypes and pattern matching. also one of the easiest languages i've seen to just pick up and start using based on familiarity with other common languages.
(as a Perl programmer, FWIW) I think Python is beating Perl due to better support for integrating with C++, or at least more modern C/C++ libraries have bindings for Python. Otherwise, if you argue for syntactic simplicity, you at least have to explain why Lisp doesn't dominate (or why do Lisp dialects based on Java become popular instead of directly Lisp?). I don't understand yet the apparent appeal of Go, except maybe its support for concurrency (definitely needed).
I think it's actually more about the errors than the syntax. But Python getting rid of braces by enforcing indentation is just the way to go IMO.
Don't want to start another tiresome thread about LISP syntax, but I'm one of those people who prefer C style expressions - as long as no heavy higher-level functional programming is required, for which I by now see almost no practical use at all.
As a funny quip, Larry Wall referred to LISP looks as "oatmeal with fingerclips mixed in".
Don't want to start another tiresome thread about LISP syntax, but I'm one of those people who prefer C style expressions - as long as no heavy higher-level functional programming is required, for which I by now see almost no practical use at all.
As a funny quip, Larry Wall referred to LISP looks as "oatmeal with fingerclips mixed in".
May I ask what exactly you mean with "integrating with C++"?
Because RPerl does exactly this and works with both Perl5 and Perl6 thanks to its own Perl11 philosophy (Perl5 + Perl6 = Perl11).
Basically it translates a medium-magic subset of Perl 5 into C/C++ using Inline::C and Inline::CPP.
Because RPerl does exactly this and works with both Perl5 and Perl6 thanks to its own Perl11 philosophy (Perl5 + Perl6 = Perl11).
Basically it translates a medium-magic subset of Perl 5 into C/C++ using Inline::C and Inline::CPP.
You will all be Lisping eventually; it’s just a matter of time. The Javanistas are already running to Clojure, and someone will eventually realize that indentation is a ridiculous basis for program structure, then the Pythonistas will be programming in Hy, and so on.
If someone is looking for a 100-year programming language, C is a promising contender. If you go back to include BCPL and CPL, that gets you back to the early 60's. However LISP goes all the way back to 1958, which gets it to the 59 year mark, and it's still in use.
From a language age point of view, FORTRAN and COBOL are closing in on a quarter of a century. I don't know the odds of COBOL surviving the full century but I'm very confident that large chunks of FORTRAN will still be in widespread use when it hits the century mark.
The ease of which code can be wrapped and reused, from FORTRAN into C or C++ libraries, which are then wrapped or reused in almost any other language, has led to FORTRAN being buried at the base of many existing libraries where FORTRAN was originally the only language for such tasks.
The ease of which code can be wrapped and reused, from FORTRAN into C or C++ libraries, which are then wrapped or reused in almost any other language, has led to FORTRAN being buried at the base of many existing libraries where FORTRAN was originally the only language for such tasks.
Fortran hit a half century in 2004, and yes I agree Fortran will still heavily be in use in 2054. There is far too much legacy scientific code for it to vanish.
The only way that won't be the case is if AI is available to translate all that Fortran to a better language...I guess we'll see... :-)
The only way that won't be the case is if AI is available to translate all that Fortran to a better language...I guess we'll see... :-)
"easy things should be hard"? Figuring out what I was thinking when I wrote the script two years ago?
Ok you jest. Pretty sure there's a transcription error there.
"Easy things should be easy, and hard things should be possible."
https://en.wikiquote.org/wiki/Larry_Wall at the bottom of the page. Anyone passingly familiar with Perl has probably encountered it as a guiding principle of the language design.
If perl 5 had use strict; and -w enabled by default maybe the write only line noise crud would be less prevalent and we'd still be using perl rather than python? It's not actually that hard to write readable, clean perl. Python's signficant whitespace seemed like such a rubbish idea at first but wow, how much easier is it to read code written by inexperienced hackers when there is no choice in formatting. That strength dominating the lack of default strict and warnings, (maybe oo bolted on syntax too?) in perl probably won the day for python because after a decade of writing python it still feels like a step down from perl and I miss it some, although not as bitterly as all these lispers seem to miss lisp ;-)
"Easy things should be easy, and hard things should be possible."
https://en.wikiquote.org/wiki/Larry_Wall at the bottom of the page. Anyone passingly familiar with Perl has probably encountered it as a guiding principle of the language design.
If perl 5 had use strict; and -w enabled by default maybe the write only line noise crud would be less prevalent and we'd still be using perl rather than python? It's not actually that hard to write readable, clean perl. Python's signficant whitespace seemed like such a rubbish idea at first but wow, how much easier is it to read code written by inexperienced hackers when there is no choice in formatting. That strength dominating the lack of default strict and warnings, (maybe oo bolted on syntax too?) in perl probably won the day for python because after a decade of writing python it still feels like a step down from perl and I miss it some, although not as bitterly as all these lispers seem to miss lisp ;-)
Having loved getting to write some Perl 5 here and there I think I know how to write object oriented Perl, but I still have no idea why it needs to be so different from the way you would expect it to work (besides political reasons or for it to feel different than other OO languages).
Modern Javascript owes an enormous philosophical debt to perl and Larry Wall, who pioneered the whole "take some nice parts from Lisp but leave the parens" approach to language design.
I'm hopeful that the wonderful ideas from Perl 6 will be adopted into a language people use sooner rather than later. I guess that language could be Perl 6 but I'm doubtful.
Modern Javascript owes an enormous philosophical debt to perl and Larry Wall, who pioneered the whole "take some nice parts from Lisp but leave the parens" approach to language design.
I'm hopeful that the wonderful ideas from Perl 6 will be adopted into a language people use sooner rather than later. I guess that language could be Perl 6 but I'm doubtful.
My understanding is that OO wasn't so much designed into perl 5 as bolted on later with a pretty cool and useful hack. This makes writing your first few perl objects a bit awkward. "Bless an array, why? What's that got to do with what I want?" There's better library support that came in after I'd stopped writing much perl, but looks quite clean by comparison. Too late for me, sadly. Still python isn't so bad when you need to script something your colleagues might need to read. It could have been different though and I would have preferred a more Perl flavoured world. Maybe it will come again..?
http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod
http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod
> It's not actually that hard to write readable, clean perl.
The real issue is that it's trivially easy to write very clever, perfectly functional, and completely unreadable Perl.
A lot of Java's verbosity is due to the fact that inexperienced developers need to have their hand slapped by the compiler pretty frequently. "No, stop, what was it you really meant to do there?"
Of course now with Kotlin and Go we're swinging back the other way.
The real issue is that it's trivially easy to write very clever, perfectly functional, and completely unreadable Perl.
A lot of Java's verbosity is due to the fact that inexperienced developers need to have their hand slapped by the compiler pretty frequently. "No, stop, what was it you really meant to do there?"
Of course now with Kotlin and Go we're swinging back the other way.
The article points out that Perl can read and execute COBOL if it's configured properly, which is neat, but ... what's the point of saying "this is written in Perl" is it's actually written in COBOL and running on the Perl interpreter? This reminds me a little bit of the JVM. There are dozens of languages that can be converted to JVM bytecode, but only one of them is Java.
Anyway, Perl's endless configurability is a mark against it, in my opinion. When I read Java or C++ or whatever, I have to wrap my head around what the developer intends to do, but the syntax is always the same. With Perl, you not only have to figure out what the developer intended, but what the developer told Perl the syntax is supposed to mean in this particular scenario. That's a big part of why Perl is considered a "write-only" language.
Also, I think we already have a hundred year language: Javascript. It's shitty, but it's good enough, it's forgiving, until it rises up to smite you, and it's ubiquitous. I don't think we'll ever really kill it off.