Larry Wall has approved renaming Perl 6 to Raku(github.com) |
Larry Wall has approved renaming Perl 6 to Raku(github.com) |
Perl6 is basically a different language much to the chagrin of many Perl users. A lot of Perl users are entrenched in Perl5.
FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011.
Every time Perl comes up in a professional environment for me I'm reluctant to say I'm capable, because it's always a hacked-together mess from an engineer who's likely no longer with the company. (obviously this is VERY anecdotal to my career)
I dropped Perl from my resume about a decade ago because I just frankly don't want to work with it. The language is terse, and I don't think anyone who's starting off these days would be spending their time well by learning it. Make your own opinions, but mine is/has always been "ewww."
Because there's a huge amount of applications and websites still built in it, and it's still a great language so new projects are written in it all the time.
source: my very prosperous career, which has been almost entirely in Perl for the last 15 years
Because it works. Scripts/software that works does not experience bit rot. As long as it works, people will continue to use it.
Edit: OK, fine. It seems the downvoters are convinced that the code does in fact experience bit rot, and spoils with time. Probably like fish.
It does the job
Great language, large library on cpan, great eco system, people enjoy using it, they have a large code base that's run fine for decades. Choose 1 or more.
> I moved on in 2011
You're right, it's all about you and what you do...
http://blogs.perl.org/users/ovid/2019/08/is-perl-6-being-ren...
It already supports a variety of parallel techniques but it's about to get easier and safer (e.g. safe I/O).
Moving forward I'm assuming you're talking about Raku and not about Perl (or Perl 5).
Do you mean little too late to be endorsed by a multi-million company? Or little too late for everything (personal projects, academia, etc.)? I'm trying to clarify this because I've never understood this sailed ship mentality regarding programming languages. And I know you're not saying this but it almost sounds like Raku is supposed to be a replacement for Python. It isn't. They're different languages, both good in some areas and bad in other areas. These areas need not be necessarily overlapping.
Whenever I read this kind of comments, they always remind of the following phrase I came across:
There are two things that a programming language needs to be acceptable:
- Be Python
- Be a language I have used recently
Well, I think Perl beats Python in quick and concise one-liners written from the command line, doesn't it?
Not that I know much Perl, though.
The idea here is to post thoughtful and substantive comments, not aggressive ones, and to avoid the flamewar style, which degrades discussion quality and provokes worse from others.
Btw, nowadays with a modern pip a simple `pip install --user package-name` works.
Second, the creators of the language didn't bother thinking about how people are supposed to ship software when they were dreaming up the language. Languages are cool, maintenance and support aren't.
I'm not even saying my pet language is immune, I don't know that I'd use Ruby tooling that didn't have OS packaging if I didn't have deep knowledge of Ruby. I plan on figuring out just enough of python to be able to use python tooling, but I think it's super-stupid that no one thinks of that use case and so requires that everyone has expertise before they can use at a basic level. Should I have python 2 or 3 installed on my machine? Why can't I have both and have the language just choose and default sanely? Python seems to be utterly stupid in this regard.
Stupid, but that's the world as it is right now. I single out python because there's more devs writing more interesting python projects that are totally useless to anyone who isn't a python dev than any other lang. Also then again, Ruby devs/teams who do make tools for broader consumption usually package their stuff up because everybody knows Ruby tooling is total shit. Python devs don't seem to have this awareness of this limitation of their ecosystem, beaten in myopia only by the juggernaut of uselessness that is the nodejs ecosystem.
Then again is ruby really that bad? Everybody knows you have to use a ruby version manager, you can't get very far at all in Ruby without one. I don't think they're really all that hard for an even mediocre dev to instrument. Is it really worth setting up virtualenv or whatever the heck pythonistas are using for env management these days for basic usage of a project written in python? How much of it do I have to know? Is it going to bite me in the ass one day like nodejs does just about every time I have to deal with it? Questions I don't want to deal with, so I strongly consider rewriting python tools in ruby at a bare minimum level because I don't want to take the time to ship personal tooling.
My second remaining use is experimental coding. It is probably about familiarity and experience (I've been writing perl since Perl 4), but I find it to be the most fluid, most "fun" language for noodling around and trying out ideas.
I use Python for things other people will have to work on, because it is the current popular kid, so most folks have at least seen it. Not because I especially like it - the GIL is still a performance killer, purity of essence arguments keep obviously useful things (like case statements) out, and (as I'm sure will be demonstrated shortly) there are always annoying people around to condescendingly tell you why you're wrong to want things like case statements.
Which magic do you mean: supernatural, illusion, or fiction?
https://en.wikipedia.org/wiki/Magic
>Magic may refer to:
>Magic (supernatural), a set of beliefs and practices distinct from religion and science
https://en.wikipedia.org/wiki/Magic_(supernatural)
>Magic (illusion), the art of appearing to perform supernatural feats
https://en.wikipedia.org/wiki/Magic_(illusion)
>Magic in fiction, the genre of fiction that uses supernatural elements as a theme
I've heard that Perl's also massively popular in the genetics/bioinformatics world. I'm assuming a lot of their data is in textual formats, and thus would benefit from a language that's fast at processing that data. I have no experience here, though.
However, for short log processing scripts, I've not found anything with even close to the same productivity.
Incidentally, apply this to web requests/responses and you've invented CGI (where Perl was incredibly useful, even if PHP happened to be a bit more popular).
Not to be confused with the Perl feature called magic, where functionality can be attached to a variable to affect what happens whenever it is accessed. Though this is often used to implement the former concept.
As a counterpoint, I think we can both agree that writing production software in one of the toy languages that pops up on HN frontpage every day is a bad idea. Writing in a language that is old enough that it has become niche has many of the same issues. It doesn't really matter whether the software is poorly understood because the language is new enough to be niche or old enough to be niche; the outcome is the same.
Perl is an old language, pre OOP. It's a language from the 90s, when everyone was hacking together code not knowing what the future would be like. There is a lack of organization. Perl is like C in syntax, features, and in speed. Python is like C++. Every failing you can find in Perl stems from it being a PP language first, from dirty code to kids not learning it in college.
Raku attempts to address every failing of Perl, yet be better than Python. If it succeeds, who knows, but I hope it gets at least a chance to make something of itself.
Would I write an API in perl? Nope.
Would I write something that massages the data that APIs spit out and processes it, drops into a queues, generates jobs, etc? Absolutely.
Mostly because I will write a few hundred lines of code for existing CPAN modules to solve the problem that I have, letting me to move on to doing something else. I like boring tools that just work. In 99.99% of the times the tools/whatever you are writing is not inline, does not need to have amazing performance. It just need to work and be braindead simple. Perl excels at that. I still daily use code that I wrote over 25 years ago and modified it a couple of times since that point ( integrating git ).
Edit: Can't reply below so I will reply here:
Re: I would not write an API in perl.
> I see you have not tried Mojolicious.
I have seen it, tried it, got excited about it and immediately came to my senses because I asked myself "Why on earth would I build or advise people to build an API in perl? It is slow. It is bad for concurrency. It probably has a pile of corner cases that I'm or some other people are going to discover. If I need to ingest something via web I will throw a simple nodejs app. Millions played with it actively in a "web" sphere, and hit most of the corner cases. There are thousands articles on stackoverflow and we have dozens of skeleton servers that already have all the needed foundations, including federated databases that support live password changes, traffic sharding, online promotion and switches, dynamic reloads, do-at-most-once queues, do-at-least-once queues, etc etc. Why would I want to reinvent all of this when the job of the API is to get the stuff and if the question cannot be answered via a couple of lookups push the request to a worker?"
Re: CPAN in 2019
> n 2019, I can only think you haven't looked around much recently.
Maybe. I have not seen it to be the case two months ago.
In 2010, that may have been true.
In 2019, I can only think you haven't looked around much recently.
Yes, Perl's threading support is terrible, and I do wish it was as effortless as in Raku. But you'd be surprised how often you actually only need an event loop and non-blocking implementations, and for the rest of the time there's Mojo::IOLoop->subprocess or IO::Async::Function to provide a thread-like model with efficient forking.
Why not? There are CPAN frameworks that make it a breeze.
The most efficent "modern" web development I have done has been with Perl.
Mojolicious, Catalyst, Dancer – take your pick.
I see you have not tried Mojolicious.
Why don't you specify this single reason you allude to?
I think there are plenty of reasons, and they work to reinforce each other.
Perl was the popular language once upon a time ago. But it stagnated while new technology came in to replace the old.
Because there have not been million people with different levels of skills poking and prodding Mojolicious into good, bad, ridiculous, disgusting, ugly and beautiful uses, posting on Stackoverflow, getting answers, getting smacked down, or getting those things marked as known bugs. I use code to achieve a business objective, not to create a beautiful code or use a wonderful framework.
Just framework itself is not enough - it needs to have skeletons for services that would handle common edge cases -- database failures with automated switch to standby, internal request queues with retries, configurable. Clean interface to external configurations that should be changeable in-flight without a restart; patterns for interfacing with other systems, etc.
> Yes, Perl's threading support is terrible,
Some of the basic crypto modules and modules that use those basic crypto modules are not thread safe. In 2019. Modules that were written a decade ago. I'm not interested in figuring out those bugs in production.
I wrote a pretty complex API using Dancer. I'm not going there again.
Perl 5 is in decline, no doubt. But it isn't because whomever you're visualizing when you wrote the above is an annoying nerd. People can and do disagree on the 'why'; I personally think it is the general decline of Unix-style syntax combined with the natural ebb and flow of language evolution.
If "what you've seen" is watching the compiler developers work through language design, the origin of your misconception at least makes a little sense, even if that's obviously a weird, unfair basis.
By all means, hate on perlmonks.org if you like. Just don't spread insulting nonsense.
That's what programming is.
In my realm I need things to be supportable by lots of people. I use languages that are modern + people want to use, I document like crazy, I use opinionated frameworks that have good track records, I need to hire engineers that can support the code I/others write, etc etc. I don't find your comment to be true, and will even go as far to say I've worked with very clean legacy code.
Tangential: If you look at any "popularity of language" studies Perl has been on a downward spiral for over a decade. Ex: https://www.tiobe.com/tiobe-index/perl/
I see "well that's just x" as a poor argument for, well... anything.
Oh man, in 1996 I was at Nortel. Some Ms. C. in Computer Science (no longer with the company) left behind Perl cruft whose indentation levels didn't even match up:
whatever
{
}
I've seen a lot of negligently written code with broken windows on the surface, that deep down turns out to be criminally insane.
If somebody's doesn't give a shit enough to indent their code, they usually don't give a shit enough to design it either.
The only Perl I use these days is oooooooold software (MRTG) I guess with the exception of Spam Assassin and RT...
Anymore Grafana backed by InfluxDB w/Telegraf is my jam for the same general problem set (TIG stack).
RRD is pretty efficient so I don't have much need to change.
> there should be a cryptocurrency based on Proof of Spam Assassination
Did you know that the blocking proof-of-work algorithm in Bitcoin today, derives from the Hashcash proof-of-work algorithm, which was originally designed to prove you are not a spammer!!
Only if you chose to write perl code in this way. The same could be said for many languages
That's exactly why I've never mentioned Java on my resume (or in earlier times, Visual Basic) =D
> a reason
Singular, in English that means there's a single reason.
> I think there are plenty of reasons, and they work to reinforce each other
Care to expand on this?
Genuinely interesting, a thread where people complain about a language and they are so careless with the language they use to try and get their point across...
Not particularly since you seem very combative... but here it goes, from the top of my head: without Moose/Moo etc OOP is (was? no clue, I don't follow development any more) just cumbersome and archaic (and with it you'll run into strange things when you hit errors), support in modern IDEs is lacking, there are few developers and therefore a smaller community, it's often not among the officially provided SDKs etc. Those are all interconnected. You can't easily hire Perl developers. Nobody wants to pay large sums to compete about the few there are to provide an SDK for a language that is on its way out. Nobody wants to work with a language that's not really supported by businesses. There's no large community to improve tools. Of course, I don't mean literally nobody, just very little. It's a vicious circle.
I liked Perl (it has a special place in my heart), I've written a ton of stuff in Perl, some of it I still support, but I can't say that I've missed it in the last five or so years since I've stopped actively writing it. I still occasionally log into the perl-focused community I used to frequent and they are still getting about a post a week. I never gave Perl6 a chance, simply because it would be a switch to another language where knowing Perl didn't really transfer, so I might as well go where the music plays. And yeah, CPAN-modules are nice and all, but a lot of it always looked to me as if written for a contest of clever code, not to be read & understood easily.
Asking people to back up what they say is 'combative'? Nothing else in this post has a ring of truth either
Incidentally, it also happens to sound similar to "roku" (="six").
Also, while 'raku' is the reading for 楽, which connotes easy, simple and other good things, it is also the reading for a bunch of other characters--namely, 落, which means or carries the connotation of falling, declining or otherwise missing the mark.
When I see the 'raku' transliteration in the context of Perl, I think of 落. Not sure if that says something about my subconscious perception of Perl or not, but I can't help but think 'Raku' is a bad choice for the name of a language mired in indecision and falling from public favor.
On another note, I find the inclination of tech projects towards poorly translated Japanese words amusing. It nicely compliments the phenomena you see in the use of random English words for the naming of Japanese cars, condo buildings, and other 'prestigious' products. So if you find that ridiculous, you should find these 'Japanese' technology names ridiculous as well.
Rakudo means paradise: https://jisho.org/word/楽土
Rakuda is a camel: https://jisho.org/word/駱駝
One of the worst problems for adoption of perl6 has been always overthinking. "Hey, look at my cool name" has never convinced anybody to use a computer language. Too many names.
Raku is a good name indeed. Like a promise of prune and simplify all the former zoo of names that could finally allow the people to focuse in the program
You're overthinking it. I don't think those who came up with the names did so to, or cared to, convince people to use the language with them...
(Hebrew word formation is from 3-consonant roots, not concatenation, so removing a letter doesn't give a related word. It's either an invalid word or a different root with 3rd voiceless consonant רקוא which is a not a root / רקוע Raku'a "flattened" but that doesn't sounds quite differently.)
Secondarily, while Perl has never appealed to me I am more likely to admit I'm checking out Raku because the chances that someone will ask me to look at and debug their cousin's friend's manager's Perl 3 CGI app is considerably reduced.
Rakudos, even!
But my main worry about it is that I suspect it has brought along with it the community's dysfunctional fascination with over-the-top cleverness and arcane constructs. I'll probably stick with Python and Perl 5 on an as-needed basis, but Raku will be fun to look in on for brain stimulation.
My best case hope is maybe it's clarified some things! Like having an agreed on best practice for how objects are implemented, that would be nice.
Edit: sorry for the confusion. I meant popularity-wise. I wish the change would clarify to people that Perl 6 and Perl 5 are basically two different languages and people should at least consider Perl 6 as an option when they start a new project.
The features demonstrated in this talk are worth a watch (or at least a scroll through the slide deck): http://tpm2016.zoffix.com/
First, it was thought that Perl 6 would be the replacement for Perl 5.
But it was long ago recognized that there was no clear upgrade path from Perl 5 to Perl 6, so it was agreed that Perl 6 was a "sister" language to Perl 5 rather than the successor.
Except that many people expected that Perl 6 would be the replacement, so that stalled many projects. So an "alias" for Perl 6 was created, but that didn't seem to help.
Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way.
If I had my choice, I'd program in raku because it's a lovely language addressing many pain points (including being one of the few dynamic languages with a working concurrency model). But it's not adopted widely enough yet for that to happen. Time will tell ...
Lua has breaking changes all the time, which makes sense for its original purpose — embedding — where you don’t need to follow updates. As such the version supported varies among different environments. But LuaJIT has an ecosystem that they try not to break. It’s more of a “conventional” scripting language because of that. It also has an FFI that isn’t in plain Lua.
CPAN invented the software repository, and I'm glad it was there so PyPI/Gems/NPM/etc. could learn from its mistakes.
Every few years I tried an alpha of Perl 6, but it was always too slow and unstable to get anything real done, and it was always a totally different implementation from the previous one I'd tried. Maybe this name change shows they're getting serious now.
One thing that struck me,
12. Both raku.com and raku.org are currently available.
I was surprised that a 4 letter .com or .org is still available. So I looked it up and turns out to be not true.
And it was interesting half of the discussion had domain name availability as factor.
[1] https://github.com/perl6/problem-solving/issues/81#issuecomm...
Names matter.
google, in their infinite wisdom, doesn't want to translate the word because they think i am typing it wrong and they know exactly what i meant to type... but anyways, i think it has to do with paradise or heaven, but i could be wrong.
Webinar is similar in spanish to the word huevina that means "egg beaters" (a replacement cheap and second quality). It sounds also like "web-vaina" (a vaina is "something" and specially used when something annoying happens) and has common roots with words like "huevín" (little testicle) and "huevada" (something irrelevant, lacking of any real interest and a total lose of time).
Definitely looks like something created to be dismissed. I can't thing in a worst 'hype' word for replace (without any real need or reason) the perfectly neutral and good old term 'videoconference'. Webinar is the kind of term that Ned Flanders would use.
Seeing that webinars have caught on like wildfire, become a multi-billion dollar business, and forced all kinds of eLearning and online platforms to say they offer the ability to produce/share "webinars", I'd say this is rather a counter-example.
I.e. more like "A few might find X or Y name off-putting, some outliers might even come with contrived meanings in unrelated not-exactly homonyms in different languages that supposedly would make a name unsuitable, but in most cases nobody really cares".
That created some kind of limbo where people weren't sure if they should use perl 5 or perl 6 (”why develop in perl 5, when it is probably a dead end and perl 6 is the future” and at the same time "why should I convert to perl 6, what if it will be a failure and I wasted my time?")
By renaming it, it revives Perl 5 so developent can continue, and at the same time Perl 6 is presented as a new language, now whichever wins will be based on its merit.
When Perl 6 finally arrived, it was too much of a step change from Perl 5 to convince many people (myself included). Meanwhile, Perl 5 had continued to develop and was, in no way, in need of a replacement.
The name Perl 6 was damaging to the popularity of Perl because beginners were confused whether they should learn Perl 5 or Perl 6. The same confusion existed in Python: Python 2 vs. Python 3 but the Python Wiki was always very clear. Until a certain point, it recommended Python 2 and after Python 3 became very popular, it recommended Python 3. That sort of clarity was missing in Perl. Due to the number of new programmers learning Perl decreased rapidly and finally Python overtook in popularity.
Not that much.
>Nim changing from "Nimrod" matters
Hardly.
>Cockroachdb's name is offputting.
Not enough to matter. They still raised over $60 million in funding...
Many people have internalized Marketing/SEO/enterprise-pointy-hair-boss thinking about "what matters", but in the grand scheme of things, naming is not really that relevant...
Most of the anti-Perl comments I've heard have been from people who really didn't know it very well, if at all.
Some of them might have glanced at some Perl code and saw a dense regex and dismissed it as "line noise". Well, yeah, if you don't know regexes you would be forgiven for thinking it was line noise, but if you did know regexes it should look no more like line noise than a similarly dense regex in any other language.
For a long time now, Perl has allowed regexes to be commented. Commenting dense regexes and splitting them up in to short regexes assigned to judiciously named variables is just good style in any language, and has been the norm in Perl for a long time. Furthermore, modern Perl style guidelines advise code to be written with verbose, English words instead of ancient Perl one-character special variable names.
So setting aside both dense, uncommented regexes and ancient single-letter special variable names, both of which have been recognized as poor style in Perl for decades now, I'm really not sure what the complaints about Perl readability are about. To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.
If you include non-mainstream languages, some languages which have a lot of fans here on HN are arguably a lot less readable than Perl to someone only familiar with traditional Algol-style languages. In particular, I'm thinking of Forth and Haskell. Yet you rarely hear complaints on here about their readability.
It's what my company's entire code base is written in. So every hour of every work day for the past 6 months.
>To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.
It's no one thing, but a bunch of little things that compound on top of each other. Until you get something like this:
while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };
Mostly though it's how it's used. It can technically do anything, so a lot of the times it is asked to do everything. Until one day you wake up to find you have hundreds of perl files, all tens of thousands of lines long, that all interconnect in an insane Object Oriented hierarchy soup stretching across every conceivable programming space - from database control to money processing to security to web site design.
Indeed, I hope this thread gets picked up by http://n-gate.com/
Take time to really grok Perl and you may find the soundbite swipes at Perl don't make sense any longer.
I'm never sure what people don't like about OO Perl. There's a tiny bit of boilerplate in a constructor, other than that, it doesn't seem different from other OO script languages.
But it is also one of the most writable language. In Perl, for most problems, there is a quick and dirty way of addressing it. It is especially true when it comes to processing text files, the thing that Perl is best known for.
Many languages try to be clean and consistent, it is obviously good for readability, but it means that choices have to be made. Sometimes the best way is the "wrong" way and you have to fight against the language. Perl solved that problem by not having a "wrong" way of doing things, screw cleanliness and consistency.
Also, first class regex are awesome for quick and dirty text processing.
You're correct about "over-the-top cleverness and arcane constructs" being a problem, but it's also about using code as communication. We code in _languages_, and on one extreme is coding newpaper style - lowest common linguistic denominator. On a good day this is a common, understandable language, and on a bad day it is trying to communicate with stilted baby talk. On the other extreme is dense linguistic cleverness. On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.
As coders we like to talk about using the right tool for the job, but in code we so often assume that the most stilted repetative pattern is always best. It often is - like newspapers, we can't (or shouldn't) assume our audience is well-versed in our material. But we have other constraints as well. I often argue in favor of _skimmability_ over _readability_ of code. That means that the attention/focus of the eye is important. Stilted languages with minimal syntax give you almost no control over that. More fluid languages like Perl give you a lot more flexibility. Learning to use that flexibility to increase clarity...for MOST people, not just for yourself...is a skill that most of us have only limited practice at, and none of us have mastered.
But it's a good idea to work at it, and when done well you communicate MORE with LESS, and it's something people notice because it's not buried in the midst of visual noise.
> On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.
So true. I think Perl golf could be Samuel Beckett.
If Raku's "bad day" is basically like "one of the most influential and important authors of the 20th century" (according to Wikipedia)… well, then, maybe I should check Raku out!
In this case, `!$double` isn't a sigil. `!` is just the old prefix operator for negating a value [1]. If you meant to write `$!double`, then it's the twigil [2] for class attributes [3]. Twigils could be considered as secondary sigils but they affect the scoping of a variable. In this instance, `!` is for class attributes and will only be found there.
As for `.@sigils`, I've never seen this syntax. I'm probably out of the loop in this one.
As an aside, sigils are one of Raku's interesting features. They convey information [4] that might not be easy to discern from just looking at the code. What kind of structure is this variable holding? Is it holding an array? A hash? A code object? What's the scope of this variable? Is it class-scoped? Is it dynamically-scoped? Is it a compile-time variable?
> ... Raku is quite slow.
This is a legitimate reason for avoiding the language. However, it's worth pointing out that Raku core developers have made great improvements to the language in the speed department since it was first officially released in 2015. They recognize there's a lot of room for improvement. [5]
[1] https://docs.perl6.org/routine/!
[2] https://docs.perl6.org/language/variables#index-entry-Twigil
[3] https://docs.perl6.org/language/variables#index-entry-$!
[4] https://docs.perl6.org/language/faq#Why_sigils?_Couldn't_you...?
[5] https://docs.perl6.org/language/faq#Is_Perl_6_fast_enough_fo...?
Over the years (announced in 2000, delivered in 2015) it evolved into a distinct language.
In the meantime, Perl5 suffered from the Osbourne Effect.
Meanwhile a rift developed in the Perl community. Some are for Perl 5 forever. Some are Perl 6 forever. Some Perl 5 people blame Perl 6 for Perl 5's perception as a dead language. Some Perl 6 people blame Perl 5's reputation for being "write only" and "dead" for difficulty getting people to try Perl 6.
IMHO, both sides are correct, both sides over-state their case.
Renaming Perl 6 has been discussed for close to a decade, by people who are Perl 5, Perl 6, and just plain Perl partisans.
It's been a difficult decision. Many people have worked very hard on both projects, and have strong feelings tied up in the issue. Important contributors to the projects have quit as a result the issues.
This isn't a change that was lightly made. It's far bigger than the Python 2 to Python 3 divergence. It's more like moving from C to C#.
Lisp has a social problem: It's been called Lisp too long. People look at some simplified LISP 1.5-esque thing in a programming languages textbook and see a "pure" language (which isn't so pure compared to Haskell, but the creep of what "functional programming" means is its own post) which is completely useless. They don't see modern Common Lisp with its package management facility and its packages which you can manage which provide actual functionality and its FFI bindings to external libraries and the fact it compiles to optimized machine code... no, they only see some parentheses thing which is interpreted-and-therefore-slow (you know... like Javascript on V8... ) and is too elegantly pure to be bound to the outside world. Meanwhile, all the Foogols get new names every couple decades (PL/I to Ada to C to C++ to Java to C#... ) so everyone knows they're completely up to date.
My point is, Perl is a tainted name, because everyone knows Perl is dead and Perl 6 is the Duke Nukem Forever of programming languages. Calling it Raku is a chance to get what the Perl 6 team actually did out into the world without the stench of death following it.
+1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol?
"Raku" = "cancer" in Polish. Not a lot of Polish enthusiasm forthcoming, I'd imagine.
The reason I think it's not related to the Lisp issue is because the relation of Perl 5 and Perl 6 was like an unofficial successor with a compatibility mode, like C and C++, whereas the relations between Lisps that create the social problem you highlight of people not knowing about "Real Lisp" are the relations of very incompatible forks with varied functionality running around calling themselves "Lisps" or "members of the Lisp family" and people confusing that with "Lisp". (There were some "Perl 5/6, C/C++" types of relations in the path to Common Lisp like Flavors/CLOS but no one remembers or cares about those outside of Lisp users...) Another reason is the timing, why the name change now, years later -- it turns out Perl (5) is less dead or possessing a stench of death as you put it than people might want, it's still vigorous in its own rights, and so really it makes most sense to just call the new thing by a new name and not destroy both. (Larry's wineskin comment is nice.) The Python 2/3 situation is a closer analog if we counterfactually imagine Python 3000 came out with the current 3.7 feature set, syntax updates, and backwards incompatibility. Python 2 users (me among them) would still have dragged their feet, since Python 2 would still have been useful, still had its own vigor, the same as presently, but it might have resulted in renaming some later version of Python 3 instead of the current situation of renaming the continuation of Python 2 (Tauthon).
Going back to the lisp issue to further elaborate why I think it's not very related to this one, the languages that called themselves Lisp (not a Lisp, but Lisp or Some Lisp) shared a heritage going back to the original McCarthy Lisp. The merely "a lisp" languages used that for marketing, but were actually called something different (Clojure, Scheme, even Racket which has to further distinguish itself from Scheme). You see the heritage in the actual Lisp 1.5 manual, where one of the earliest examples should quickly dispel any illusions today about "Lisp's" supposed purity when they show the function 'length implemented with a program block and goto. By only modifying the top-level function define format and substituting ADD1 with 1+, the program works to this day in Common Lisp. For members of the lisp family that don't call themselves lisp, you're not going to be able to make such a trivial transformation, because there's no shared code heritage, just a vaguely shared s-exp-ness to the syntax. And right after that the manual describes the "pseudo-function" 'trace, which to this day is lacking in supposedly modern languages or requires a bunch of IDE ceremony to set up. It's present in CL and behaves the same, though. Continuing to call CL as simply Lisp seems pretty well-deserved.
The Lisp social problem then is that people run into members of the vaguely defined lisp family like Scheme (especially with SICP formerly being a common gateway for freshmen or HS students) or Clojure and confuse "a lisp" with "Lisp". They can spread their confusion further by releasing a project/blog like "let's write a lisp interpreter!" that can be understood correctly as "let's make a program that interprets code for a lisp¹" but tends to be misunderstood (sometimes even by the author) as "let's make a program that interprets code for Lisp".
Of course I also think this "social problem" is way overstated, especially these days when it's so trivial to dispel the old myths and when the gateways via Clojure or Racket are actually good in their own right and so don't leave the same impressions of "Lisp's a neat toy" that only seeing SICP Scheme could. But if people keep talking about the problem as if it is big, perhaps it will become self-fulfilling, hence my long comment in disagreement. ;)
¹ aka a member of the lisp family based on my vague membership criteria that probably don't even pass Steele's 3-part acceptance test in https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf that requires as its final step (atanh -2) to return a complex number. (Bonus if the correct complex number.)
Elixir is worth a look. It's a pretty productive little language with a great concurrency model.
I hope that doesn't mean that when Perl needs a major number version change again, they'll chose 6. It would be pretty confusing to have 2 Perl 6.
If you did a "major version bump" from here, you'd probably have to bring the "5" along for the ride. Like Java version 2, where you had J2EE version <X> for years.
In reality, there probably never will be another major version bump of Perl 5, in the marketing sense. The minor version number is really the major version number now.
To avoid confusion they would probably break the version convention entirely and name it with the year instead. So instead of Perl6 it would be Perl'19.
There is no DBIx::Class (or related schema loader) for Perl 6. I don't know how mature the web frameworks are. Or even basic stuff like Excel reader/writers (we use lots of Excel for backend data analysis).
On the other hand, most of the async stuff we currently use can be thrown out. With raku's gradual typing, our in-house type libraries can be tossed out. Our local modules for making it easier to write clean procedural and OO code could be thrown out.
And the raku code would be far more concise and easy to read. Here's a simple Point object in Moose:
package Point {
use Moose;
use overload '""' => \&Str, fallback => 1;
use Moose::Util::TypeConstraints;
subtype "PointLimit" => as 'Num'
=> where { $_ >= -10 && $_ <= 10 }
=> message { "$_ must be a Num between -10 and 10, inclusive" };
has [qw/x y/] => (
is => 'rw',
isa => 'PointLimit',
required => 1,
);
sub Str {
my $self = shift;
return sprintf "[%f,%f]" => $self->x, $self->y;
}
}
class Point {
subset PointLimit of Rat where -10.0 .. 10.0;
has PointLimit $.x is rw is required;
has PointLimit $.y is rw is required;
}
class PointLimit:
def __init__(self, name):
self.name = name
def __get__(self, point, owner):
return point.__dict__.get(self.name)
def __set__(self, point, value):
if not -10 < value < 10:
raise ValueError('Value %d is out of range' % value)
point.__dict__[self.name] = value
class Point:
x = PointLimit('x');
y = PointLimit('y');
def __init__(self, x, y):
self.x = x
self.y = y
def __str__(self):
return "[%f,%f]" % (self.x, self.y)I wasn't aware that there was one beyond the poor sods charged with maintaining my youthful sins.
We're still out there, but it's not "cool" to talk about.
Not only that, but when Perl 5 was at the end of its life, comparing its libraries to both Python and Ruby, you'd often find the best library was for Perl.
Raku should be far faster than Python and Ruby and may in the future have better libraries with excellent concurrency support, making it a good choice to do processing over the data, not just converting it to the format you need. It has an easy interface with C and C++, so you can import libraries from there too, if you need more speed.
Before Python came to fame Perl was primarily used by two groups: 1) sys admins who needed bash style 1 liners, but in a cleaner language (This is where the dirty code stereotype comes from.) and 2) Web devs. Much of the early pre PHP internet and even post PHP internet was written in Perl. When Perl on hiatus the web world turned into this mess of frameworks like it is today. It used to be a more unified world.
And then there is the rare 3rd group. I worked on earlier ML projects in Perl before Python was a thing. I enjoyed Perl more than Python and so did the people around me. Moving to Python / R was somewhat painful knowing it could have been better. I hope Raku takes up this torch and is good as it appears to be.
Still have my O'Reilly 1st Annual Perl Conference bag around. Good times.
raku is a great language to work with for us. it is feature rich, has good abstractions, and developer friendly. if you like the syntax then give it a try.
But you have parser libraries that work very well in all major languages, and I'm not sure being integrated in the language makes Raju more valid for any project.
What it does, imo, is offer a special way to solve some stuff by already being there. But it's like saying someone would choose python for a project because it has a built-in set data type.
PyPi has caught up with CPAN in terms of sheer number of packages, but there are still a lot of differences in what those packages cover. You might find solutions in CPAN without a counterpart in PyPi.
More narrowly, every time I deal with databases in python, I find myself missing perl's DBI, which provides the same API for all databases with a corresponding DBD. Python should get a similar universal database interface someday.
To put this another way, my 10-year-old perl-based web crawler did not have a problem crawling websites with umlauts in the hostname. Python is fixing supporting that new 2008 standard next year.
Read https://www.evanmiller.org/why-im-learning-perl-6.html or the follow-up https://www.evanmiller.org/a-review-of-perl-6.html
Or, Why Perl 6 is the "Game of Thrones" of programming languages: https://techbeacon.com/app-dev-testing/why-perl-6-game-thron...
Lots more where those came from...
1. Raku treats math in a manner that wouldn't surprise a mathematician. Or grade school student, for that matter. Witness:
$ python3 -c 'print(0.3 == 0.1 + 0.2)'
False
$ ruby -e 'puts 0.3 == 0.1 + 0.2'
false
$ perl6 -e 'say 0.3 == 0.1 + 0.2'
True
2. Concurrency is a language goal in Raku and I think that's notable, compared to Python. Parallelism, concurrency, and asynchrony including multi-core support.[1]
And Perl programs do not spontaneously decompose when copypasted also.
And CPAN is still a very profitable gold mine to explore.
Movable Type is about the only blog framework not written in PHP. If you thought Perl was a bad language, PHP is way, way worse. And Movable Type is also the only one that can use Postgres for storage.
I could not find any blog engine in Python.
> If you thought Perl was a bad language, PHP is way, way worse
In fairness to PHP, it's a lot better today than it used to be. (Though modern PHP would probably strike a Pythonista as too Java-ish.) And WordPress has had tons of engineering resources poured into it for a decade-plus now, whereas Movable Type has been maintained on a relative shoestring due to its fall from popularity.
Even if Perl 6 is completed, I don't think it is a practical workhorse for many real world situations.
To me being able to create grammars in Perl 6 to parse text data sounds really compelling. However, every time I have played around with them, Perl 6 has been so slow, that I have reverted to using regular expressions in another language.
http://blogs.perl.org/users/ovid/2019/08/is-perl-6-being-ren...
If the confusion regarding Perl 5/6 never happened, it might have retained that popularity in that domain.
Interestingly enough 落(raku) also has the connotation of failure or missing the target, so not very auspicious in the context of a new language either!
Perl <=5 did make it, it was quite big in the 90s and early 2000s.
A sanely written Perl program is nowhere near line noise. Compare to supposedly beautiful languages like Rust and the ratio of punctuation characters to alphanumeric is pretty much on par.
The execution, the thing, the multibillion dollar industry, are excellent, and the world would be worse for their nonexistence.
The naming, on the other hand, is indeed a disaster. I too can't take it seriously, although I can't quite put my finger on why as well as the GP can. To me it just sounds like the "lite" version of something, but to the extreme where it might as well be the toy version.
Yet another case of buzzword intolerance, it would seem.
Mission acomplished then, if we take a look to the low interest in people to massively adopt the language since it was released in 2015
Yeah, as if the name is what caused the non-adoption of a 20 years late replacement for a language that had already fallen out of fashion with developers (and with many growing pains in the compiler and tooling to boot).
If anything, they used the "Perl 6" for most of the time, which renders the argument even more moot...
Because 2015 - 2000 does not equal 20.
The project started in 2000.
---
It would have been a much worse language if it had been released even a few months earlier. (That was before the GLR landed.)
---
Also just about every time a new feature was added in the first few years the existing features were redesigned so that everything was consistent.
So despite having many features from many languages, it feels like all of those features belonged together.
Because of the time taken back then, it is actually really easy to add new features to the language now. (Try adding first-class regexes to any other existing language.)
For example, all of the normal operators are just subroutines with a special name. Which means you can create a new operator that works exactly like a built-in operator by giving it a similar special name. (From a certain viewpoint, Raku doesn't have built-in operators.)
Also regexes (which have been redesigned to be easier to read) and string literals are actually Domain Specific Languages in Raku. Which means you can also add your own similar feature if you felt so inclined.
---
I like to think of it this way:
A language like Python is a good toolbox.
Raku is also like a good toolbox, except it is also a fully decked out machine shop for creating new tools that no one has thought of yet.
Everyone who has worked in a machine shop knows it takes a few years to get one setup just-right.
---
Also there is a saying:
It can be good, fast, or cheap. Pick at most two.
Raku was created entirely by volunteers, so by definition it has to be cheap.
Which means there was only ever a choice between fast or good.
I'm glad the choice was to make it good rather than fast.
(Especially since the whole reason to create it was to make something that was more good than Perl was at the time.)
I started to use Python when 3 was taking off. Did some code on 2 for a few months, then just swapped the interpreter without any modification of the code (beside print).
For advanced devs the story may be different.
Yes, even though I don't dislike Algol and the Algol syntax style, necessarily, I just wish they'd imported more Lisp influence sooner.
Ruby 2.5 has a jit which uses the C compiler to generate dynamically linked objects. It looks more like a workaround but it produces fast code. Then there's Jruby, Rubinius, Truffle, mruby. Crystal too, which is a different language but yet similar. No need to learn Go. Just take your Ruby background and pretty much start using it for writing Crystal.
Thankfully JRuby already has a functioning JIT and TruffleRuby is getting very close to a 1.0 release.
J2EE 1.4 -> Java EE 5
Both “2” and “1.”.
Funny that the name Mac OS X went to OS X and then (back) to macOS, but the 10.X name persists.
Great improvements are not enough compared to other languages, even Ruby which is quite slow itself. Have you wrote anything in Node, Dart or Lua? They feel like a F1 car where Raku is an 17th century cart.
Either way shows exactly what is the structure of `hash`.
See? Confusing. That's why people hate Perl. At least I'm glad dereferencing is gone in Raku.
It's just another example of Perl's biggest strength and weakness. Total freedom to build something amazing or shoot yourself in the foot.
There's no private data or private methods in Python objects. All the properties are right there for anyone to read, protected only by convention.
JavaScript and Perl have almost exactly the same OO model, yet many people quite like JavaScript's OO, so that can't be it, surely...
There's no private data or private methods in JavaScript objects. All the properties are right there for anyone to read, protected only by convention.
(It's closer than it looks. Perl's "bless" function means almost the same as JavaScript's ".__proto__ =", and inside-out data hiding is possible in JavaScript much the same as Perl, although hardly anyone uses it in either language.)
I try to use OO sparingly when possible, and in Perl that generally just means I've been using a hash and decide it'd be more convenient that it keep some functions to itself rather than pass it around to other functions.
I will say in Perl's defense, the bare implementation really made me appreciate what OO actually is under the hood. I felt like I understood it much better, especially since it takes a mixed approach (rather than 'everything must be an object, including Program.cs' which I never really enjoyed).
Saying they are no more complex and adapted than any other organism sells them far short. Yet they're more stubborn than a mule, somewhat slower than a horse, they smell worse than either, and they'll spit on a person like a llama. They've been known to bite. Their shape is not is amenable to riding although they are used as mounts. So there are things one might really want to change before spending a lot of time with one.
So those feet that are great on sand were made for walking on snow covered ground.
Likewise food is scarce in both the arctic during the winter and in the desert.
But if we focus on vertebrates, they are all so very very complex and adapted. Everything you've listed for a camel is at best a cherry on top. All other vertebrates are within a couple percent, and many of them have feature lists just as long.
Perl 5 is better than Python in many ways, but worse in other ways. Raku seems to have none of the downsides Perl 5 had, but all of the upsides. Raku looks like it could be a valid replacement for Python in the ML space.
Also, back then, Perl 5 had better libraries than Python. Though, that was quite a while ago.
I don't Perl much, but aren't those both scalars and @foo is an array variable. $foo[0] would be a scalar that is the first element of @foo, right?
The main questions I have when doing something in an unfamiliar language are now:
1. What is the syntax for X
2. Can it do Y
3. Is there a library/builtin for Z
For anything else, I've probably been there, done that, got the t-shirt.
I remember using some books to get a structured introduction when I started out many years ago though.
Nowadays I'll probably just open whatever existing code there is, go "ah, so it's like that", and hack away with the help of Google.
The stuff that takes actual learning tend to be major frameworks for me, not so much whatever programming language is used.
Not everything counts equally. If something affects the adoption by 1M users, and another is only a concern for 100 weirdos, the second is not exactly a major issue to focus on...
noun: weirdo;
1) a person whose dress or behaviour seems strange or eccentric.
Yep, weirdos will never ever have any influence on Perl development or Perl community.
https://www.ecured.cu/Larry_Wall#/media/File:Imagen_Larry_Wa...
For instance, [1] is a tool for text-to-pictograph translation system I worked on. The core engine is entirely written in Perl 5.
I have previously stated that I would like it to be an alias of sorts.
use v5.30;
use v2019;
---
Perhaps even something like:
use Perl v2019;
For example, if you have a column on table A and you later need to move that to table B, a clean model can encapsulate that change. Hard to do when the ORM is being treated directly as the model.
I'm only a novice in Perl5 land (Python is usually my go-to along with Linux CLI tools and Powershell on Windows, or honestly a lot of SQL these days but sometimes I reach for Perl5 when it has something I need) but I always keep an eye out for different and interesting technologies and Perl6 is definitely on my radar to check in on every now and then. As you've pointed out, it seems to have a lot of power that could reduce a lot of the one-off scripts I write. I do a lot of basic text file manipulation and any feature that can save me time is valuable even if there is more stuff to learn. To me, Perl6 appears to allow for writing beautifully succinct and readable OO, Imperative, or FP like code. However, if I just need to wrangle some data (throwaway code) it looks like it can be for text what APL is for arrays (a powerful Swiss army knife).
On another note, while I have you here, do you ever plan on putting out another Perl book, but one on Perl 6 (I know there are several already published).
Clojure would be a great language for small-ish scripts if it weren't the dog-slow startup times, and has excellent concurrency support.
I hear that GraalVM might fix that but I sadly haven't had a chance to play with that yet.
My favourite for scripting right now is Joker: https://github.com/candid82/joker
Joker is a Clojure dialect which is interpreted, thus it starts super fast (but runs slower, but fast enough for scripts). Its design is to be batteries included for all things scripting. So it's just a self contained executable with everything you need for scripting. It's implemented in Go.
I use it wherever I would have used bash or powershell prior.
There is also Babashka: https://github.com/borkdude/babashka which is a similar idea, it's an interpreted dialect of Clojure with fast start times designed for scripting. The difference with Joker is that it is newer and more experimental, and it is implemented in JVM Clojure, compiled with GraalVM and has no Windows support for now.
Anyways, I really recommend the use of Joker. Its awesome for scripting. I just put its binary in all my bin folders and script with it. It's great.
Why I suggested Elixir is because it has all the strengths of Erlang but is also a better scripting language, and would compete better with Raku on a more equal footing in that respect.
Probably “set themselves apart from others”.
for @a { .say }
my $lambda = { .say }
@a.map( $lambda );
for @a -> $item { say $item }
if $a.method() -> $result { say $result }
my $lambda = -> $result { say $result }
Raku is a much more consistent language than beginners expect. The above is just one example of this.
Because it is so consistent; once you learn something in one place, you can use that knowledge everywhere in the language.
But first you have to realize that is even a possibility.
It would take a long time to come to that conclusion if you write Raku by copy-pasting code.
That is because very few languages are as strangely consistent as Raku.
It makes little difference for Perl that this experiment in a next generation version of the language is still alive and going its own way. The result is the same...people kept moving forward with version 5, and if it needs a new version, it can't use version 6 because 6 was already used for that other experiment (that failed to take the place of Perl 5).
The primary goal of PHP6 was to implement full unicode support and drop mbstring. However, that took much longer than expected and multiple major features ended up getting backported to 5.3, 5.4 and 5.6; to the point that PHP 7 became the new feature version while PHP6 was worked on. They eventually gave up and PHP7 was released with unicode support built fairly deep, but basic string types and the like still being byte arrays.
PHP7 was PHP6, without the native and full unicode coverage requirement.
"after DirectX 3 was released, Microsoft began developing versions 4 and 5 at the same time. Version 4 was to be a shorter-term release with small features, whereas version 5 would be a more substantial release. The lack of interest from game developers in the features stated for DirectX 4 resulted in it being shelved, and the corpus of documents that already distinguished the two new versions resulted in Microsoft choosing to not re-use version 4 to describe features intended for version 5."
Ruby is a JVM language, in that JRuby is a very complete competitive, current, and widely-used-in-production Ruby implementation.
So as a developer it's all the same until you start leveraging the features of your particular runtime but this does make code sharing viable
Saying that I see absolutely nothing wrong with that perl code you are highlighting as being obtuse or ugly. Anyone who understands Perl should not have an issue with that line. It is clear and concise.
There are a variety of things that Perl programmers would consider idiomatic (depending, I would say, on the background of the Perl programmer). Using something like (foo && bar) in this manner is actually quite common in some Perl code bases (although, I suspect it is more commonly used where there are multiple conditions that are chained -- Damian Conway's "Perl Best Practices" book has some examples of those).
In the example given, I suspect the author of that code did it that way to reduce the length and put it on one line. I understand the desire for concise code, but if it were me, I would spread it out more to make it easier to read (mostly, I just wouldn't put it all on one line). I like having concise code also, but there is a fairly definite line that I try not to cross. If I have to work hard at all to keep track of the pieces, it's time to either add some more whitespace (horizontally or vertically, or sometimes both), change some of the constructs, or add some temporary variables to make the intent clear.
I am the person most likely to have to deal with the code a year later, so like many others, I try to not confuse my future self.
That's a business culture thing. If you set the expectation, that it's okay to do that, people might do that. If you set the expectation that it's not okay, people shouldn't.
The equivalent C and Python are likely just as ugly (given that the equivalent python might be using a far too complex range statement or put it on a single line using : and ;, which is possible...).
That said, as bad code goes, that's not really that bad. The only non-standard things are <> and $_, and if you don't know what those are, you really haven't done the minimum of learning about the language (<> might be somewhat exotic in that form depending on the codebase, but $_ is not something you can get way with not knowing about). In all, the major problem with it is that it's not commented and uses poor variable names, which is something every language needs to deal with. I would write it like so if I wanted it on a single line (but I would probably use 2-3 lines):
# Report each duplicated line once
my (%lineseen,@linedups); # This was required in yours too right? I assume you're using strict...
while (<>) { (++$lineseen{$_}==2) && push(@linedups, $_); };
# Report duplicate lines once
my %lineseen;
my @linedups = grep { ++$lineseen{$_}==2 } (<>);
Some people will look at this as evidence that Perl should be relegated to one-liners, but I find immense usefulness in combining my more engineered aspects with one-liners, and providing myself with a "project evaluator". What I do is create a simple bash script which just calls perl and sets the library include path to the project lib, includes a few useful things to always have (Path::Tiny, Try::Tiny, Data::Dumper, etc), and passed the rest of the args to Perl. Using DBIx::Class for SQL manipulation and/or using complex API client libraries I've written combined with the abilities of perl to do things easily as a one-liner is amazing.
Still mostly fine so long as you know you're only dealing with 7-bit ASCII, IIRC, but Caveat Emptor.
It's easier to just say File::Slurp in mixed company so people immediately know what it is if they look it up, rather than them be confronted with a grab-bag of functions.
The specific example cited
while(<>){ $h{$_}++ && ... }
is quite understandable to anyone who has used Perl for more than a few weeks. Its a common pattern. Complaining about this, which is, for the uninitiated, looping over reading each line from STDIN until EOF, incrementing a hash variable indexed by each line, etc.
This is a very common pattern in perl. Draw your own conclusion as to whether complaining about idiomatic language from a "skilled practitioner" is something one should take without a grain or two of salt.
And of course, being Perl, there are many ... many ... ways to accomplish the same task. Leveraging CPAN modules. I'd leave discovering some of the as an exercise for the reader.
Who knew you could do that in a programming language? Not sure I would have ever thought to try.
I even love the above sample while loop, you can tell the person who posted it is good because they can't create too heinous an example. The <> and $_ provide what I think of as visual anchors that describe a path for the data to follow. Obviously some style minded author could do it better, but it's not bad. The real line noise is from the one-liners for systems tasks I think.
You should see C++ Templates! Even the idiomatic examples in cppreference.com will blow up your head and require multiple re-reads.
while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };
my @output-array = lines.unique; my @output-array = lines(:!chomp).unique;
We use Perl::Critic [0] to deal with issues like that. It has enabled us to develop a very consistent style, and helps new devs adopt to it quite quickly.
It seems Unix vendors really don't like low version numbers. Of course, Windows famously jumped from 3.x to 95, so it's not like they're any better.
Microsoft was surprisingly good at not skipping numbers, until the jump from Windows 8.1 to Windows 10, which also lead to the NT kernel jumping from 6.x to 10.
A lot of programs refused to work if there was a `9` in the version name.
That was of course because those programs needed something newer than Windows 95 or Windows 98. So they just did a string search for `9` in the version name.
There may be a few programs that wouldn't work on `8.9` or `10.9` if they were released for the same reason.
Elixir, on the other hand, has many nice features for scripting, such as better string handling, process pipe-lining, and an excellent set of first-class generic data structures (beyond just map and list). It also happens to have Erlang's fantastic concurrency model.
Have you tried Crystal? Both are on my list of programming languages to look into next, together with Elm, Reason and Zig.
Elixir had a long startup time for one-off scripts in my experience, but Elixir’s syntax is still one of my favorites for scripting.
Python as a language can support parallelism via threads, and CPython as an implementation can via multiprocessing, but those are both very low level abstractions; Raku has higher level abstractions which allow much more succinct expression of parallel operations.
lliamander replied that Elixir does too and it's worth a look
To that, 7thaccount replied that Perl6 and Elixir fill different niches.
So far, it seems Perl6 fills a niche that requires scripting and first-class concurrency. My question then is: what is this niche that requires very solid concurrency but also scripting. In other words, what does Perl6 have in terms of concurrency that Python does not (given they are both scripting languages)?
I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
-----
Python's concurrency model is good for waiting on network or disk I/O because of its GIL (Global Interpreter Lock): https://realpython.com/python-gil/#the-impact-on-multi-threa...
If your program is CPU bound the GIL will slow you down. I'm sure since the python ecosystem is quite vast there are ways around the GIL... but then you have to worry about every library you use not supporting "real" multi-threading, or (b)locking for no reason and shitting all over your efforts.
sub foo ( Int \n where 1..100 ) {
# ___ start is a prefix operator that creates a Promise
# V
start { sleep n.rand; (1..n).pick }
}
my $result = foo(10);
say $result.status; # Planned
say await $result; # 6 (after a delay)
# this is nearly identical to foo above
sub bar ( Int \n where 1..100 ) {
Promise.in( n.rand ).then({ (1..n).pick })
}
There are combinators like `Promise.allof` and `Promise.anyof`.
You usually don't need to use `Promise.allof`, because you can use `await` on a list.
my @promises = Promise.in(1.rand) xx 10;
my @results = await @promises;
---
You should see the `react`/`supply` and `whenever` feature.
When I have a bit of Raku code that is too slow I complain (send a bug report) and then someone else figures out why the JIT isn't doing a better job and fixes it.
Then bingo-bango it ends up even faster than using NativeCall to call into the C code.
Of course there may be a delay before someone gets around to figuring it out; so in the meantime, NativeCall is actually very easy to use.
---
I would like to note that someone wrote Perl6/Raku code and the equivalent C/C++ code. They reported that the Perl6/Raku code was faster. (It was before Raku was brought up as an alias/name.)
I'm fairly sure that the reason the C/C++ code was slower is that it copied strings around rather than using pointers and indexes into other strings like MoarVM does.
I actually love doing CPU bound work in Groovy which is usually described as a scripting language. But it gets converted straight to java byte code which is JIT'd and ends up as machine code. It only takes a few static typed hints here and there and it runs in the same league as C++ implementations. And it gets Java's excellent concurrency support for free.
I'm personally with you. I also don't tend to think object boxing is really the performance bottleneck for most applications, and if/when it is, likely the other requirements should've already ruled out using one (a scripting language).
It's like writing Nifs for Elixir, yeah sure you _can_, they have their purpose, but you could also just write another application to do that one thing and like you said, use IPC.
So in summary, we agree with each other, here's to:
the right tool for the job!
Hear, hear!
It would be, but IME Crystal, or statically typed programming languages that don't have a type system at least as powerful as Haskells in general, don't get anywhere remotely close to that, and the overhead added to get what they do give is of dubious net benefit outside of large projects.
And even with Haskell, while you can express a much richer set of constraints in types, there's also more space for bugs in the type level programming.
Compared with
time crystal eval <<<"puts 1"
time ruby <<<"puts 1"Rather try "echo 'puts 1' > puts.cr && crystal build puts.cr && time ./puts"
BTW, you can dramatically decrease the cold startup times of ruby if you call it with the options '--disable-gems --disable-rubyopt' if that's an option to you. For many scripts it certainly is.
But even on a 8 years old machine with spinning rust, after the ruby stuff is cached in the OS filesystem cache, my startup time are smaller than 10ms.
Why would I want to spend my time "type level programming"?
Maybe I don't understand what's meant by a type. Is it on the level of string/double/int, or is it expected to cover more (string with a well formatted ISO 8601 datetime, etc)? What is accomplished that couldn't be done in vanilla Ruby with an object representing a more complex datatype with its own getters/setters to cover validation?
I don't know of many instances where scripting and concurrency would be needed in the same application. But if you wanted to use single language both for scripting tasks and applications that require concurrency, then Raku or Elixir would work.
One instance I can actually think of, that would be specific to Erlang/Elixir, is if you have a long running service that you sometimes run batch jobs against (like importing data from a CSV). An Elixir script can hook directly into an Elixir/Erlang service and interact with it using message passing. It's a heck of a lot simpler than RMI, and avoids the need to expose new HTTP endpoints specifically for such tasks.
Some differences:
* You can actually write your whole application in Elixir, whereas I could not see doing that with PowerShell
* In Erlang/Elixir, instead of objects you have processes. Think of your application as a microservice architecture on steroids, using the Erlang RPC protocol as a means for inter-process communication.
Because each process just sends and receives messages, your script can just send messages to any of the processes that make up your application, as if they were your own service. All you have to do is connect to the remote application using the Erlang Distribution Protocol (to connect different runtimes over the network).
To which the answer is “not only does Python not have them, but with the GIL CPython couldn't do much with them even if the language had them.”
edit: that is, as far as I can tell, after a quick Google, it's not too different from Python's Thread object.
(In that when I translate Go into Raku, I usually replace `go` with `start`.)
my Channel \input .= new;
my Channel \output .= new;
start for input -> \message { output.send(message) }
start for output -> \message { say message }
input.send(5);
sub foo () {
sleep 10;
42
}
# ___
# V V
my $delayed-result = start foo();
say 'Hello World'; # Hello World
say $delayed-result.status; # Planned
say await $delayed-result; # 42