From what I could tell, Raku appears to be from Rakudo, the Perl 6 compiler, which is a shortened form of rakuda-dou (="way of the camel" in Japanese). Rakudo also means "paradise". The "raku" from "way of the camel" means "camel", while the "raku" from "paradise" means "fun" or "enjoyable" (or "music").
Incidentally, it also happens to sound similar to "roku" (="six").
There was something strangely familiar about the word "raku" but it took me a moment to make the connection. In Finnish, "raakku" is a common name for the mollusc species Margaritifera margaritifera, better known as the… freshwater pearl mussel! [1] I'm really not sure if this is an amazing coincidence or yet another layer of linguistic brilliance.
Oh wow, I didn't know that, but I know that there is/was a band called "Raakku ja helmet". I always thought "Raakku" was a humorous nickname of the singer, because "raakkua" means "to cry like a crow", i.e. not so well. But "raakku" meaning "a mussel" brings a whole new level of meaning: "Mussel and the Pearls".
I understand that impression but I think it requires a different point of view. They are highly adapted in multiple quite complex ways. It's possible we're using divergent definitions of "sophisticated". I was using the one that means complex, developed, and refined for an environment rather than the definition of being tasteful, intellectually pleasing, and socially experienced.
Not everything that ever lived is as adapted as the camel and not in as many ways. it has huge fat stores so it can go a long time between meals. It can go a long time without even drinking. It has for thick enough it won't sunburn but thin enough it won't overheat easily. They have a third, translucent eyelid that opens to the side like something you might see on a reptile, but they still have the two main lashed eyelids like most mammals. They have a long, strong swatting tail. Their feet, unlike a horse or goat, are not hooved. They have a split foot with webbing in the middle that resists sinking in sand or soft soil. They're able to drink brackish or even salt water. They can eat stone fruits like dates with the stone. They'll eat cactus with the spines because their mouths are so tough. They eat fish, seeds, grains, and all sorts of things. They can eat foods far too salty for other animals and will even eat bones. Arabian camels will travel tens of kilometers a day in the wild to forage, in conditions many animals couldn't even survive, but can go two weeks between meals when they must.
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.
I'll agree that comparing to any other organism is going too far.
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.
So as a Japanese speaker, I don't think I ever would have made the 'raku' == 'rakuda' camel connection.
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.
Raku isnt falling from public favor, it hasn't made it yet. It's an entirely different language to Perl 5. Like the difference between C and C# or Java.
Yea, sorry I'm not super familiar with the project, but that is the general vibe I get about Perl.
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!
I think explains a lot of the polarised reactions people have towards Perl. It's trivial to understand the difference between the scalar var $foo and the array var $foo[0] if someone explains it to you or you read it; but if you're trying to Google-as-you-go, you don't even know what to search for. Those in the former group are more likely to find Perl delightful, while to the latter it's just frustrating.
Interesting. A good book is very efficient at teaching you how to think in that particular language, rather than translating the ideas you have in another language into the new language. How do you learn that with your method? It sounds to me that it would require a long time programming in the new language to come to the same realisations by yourself.
I've been developing software for more than ten years and it is rare now that I encounter anything genuinely new "idea wise" in a programming language.
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.
This is how to learn to mimic a new language and avoid actually learning it. It’s the difference between carrying around a French phrase book and being able to converse like a native.
> Raku appears to be from Rakudo, the Perl 6 compiler, which is a shortened form of rakuda-dou (="way of the camel" in Japanese). Rakudo also means "paradise". The "raku" from "way of the camel" means "camel", while the "raku" from "paradise" means "fun" or "enjoyable" (or "music").
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
>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.
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...
>Mission accomplished 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...
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.)
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...
That would be Rakuv רקוב, just Raku doesn't have any meaning in Hebrew. It does sound similar when pronounced though.
(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.)
Naming matters. Nim changing from "Nimrod" matters. Cockroachdb's name is offputting. Perl 6's name has caused endless confusion and by itself sabotaged both Perl 5 and Perl 6. Perl 6 has interesting ideas but I don't even want to touch it because its naming issue is so toxic. I'm glad they're going to rename it.
“Nimrod” is a funny case. In the Bible, Nimrod is a king and a mighty hunter. In Looney Toons, Elmer Fudd, a decidedly not-mighty hunter, is sarcastically dubbed “Nimrod”, and so the connotation is reversed for those of us who are first exposed to the name as a sarcastic jibe from Bugs Bunny rather than the name of a Biblical figure.
Agree. To name another example, I personally can't take seriously anything named 'webinar'.
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.
>Agree. To name another example, I personally can't take seriously anything named 'webinar'
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".
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.
It was not a version upgrade from Perl5, but instead practically a new language with some similar design principles. So the name was both holding Raku back by associating it with the warts of Perl5, and also holding Perl5 back because people assumed "Perl 6 was the upgraded version so why use the old one". People have been talking for a long long time that the language is different enough to deserve a different name, and things finally seem to have come to a head recently. As a Perl 5 fan and an early ~Perl 6~Raku enthusiast, I'm happy about this change, though it's almost certainly coming too late. Better late than never, I guess.
I believe the issue was that Perl 6 had too many changes that made it hard to convert apps from earlier version.
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.
The sibling comments aren't wrong. However, Perl 6 was originally intended to be the next version of Perl. For a long time it was vapourware, however, and development restarted on Perl 5.
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.
Perl 6 sounds like a successor of Perl 5 but in reality it is a totally new language. Many long time Perl 5 users think a new name for a new language would have been better.
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.
Thid said, Python 2 vs 3 did not matter for a beginner. Beside print they would not see a difference.
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).
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...
Kudos for making this change! This is what the folks at Microsoft should have done when ASP became ASP.NET and ASP.NET became ASP.NET Core. I know... keeping the root of the name the same makes management think the technology is fundamentally the same (and, therefore, cheaper) but the SEO confusion trying to find the right version of an answer is a PITA.
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.
I'm amazed that Perl is still around. I personally find it the least readable language that I've ever used, and that includes a lot of languages. But some people really seem to love it, for reasons a bit beyond me.
How familiar are you with Perl, and how much have you used it?
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.
>How familiar are you with Perl, and how much have you used it?
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:
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.
I've worked on large 20 year old Java and C applications (OLTP and batch processes) and I can assure you that they can be as ugly as any old Perl code you have dealt with.
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.
And a C-ism, and a C++-ism, and a Java-ism, and probably at least one other I'm not thinking of at the moment.
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, $_); };
But I would likely opt for the following if doing it myself:
# Report duplicate lines once
my %lineseen;
my @linedups = grep { ++$lineseen{$_}==2 } (<>);
Assuming I was using <>, which I generally don't since File::Slurp is usually available and clearer.
There's always <STDIN> if <> is too cryptic. I think what most fail to grok, if they've only glanced at Perl, is context. Above all Perl is a context-based language. It's the opposite of Python's spell-everything-out approach but just as valid. Perl also excels at whipupitude.
Except that <> isn't just <STDIN>, it reads from each line of each file specified as an argument on the command line or STDIN if no files were specified. This dual use (and magical-ness) is why I shy away from it in actual programs (but it is useful for one liners, which is why it does this), as it can be confusing.
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.
<> is actually <ARGV>. And actually the least cryptic spelling IMO is "readline(*ARGV)" or just bare readline, which still compiles to the same opcodes. Sure, <> is more common, but it's easier to find what readline and ARGV mean.
File::Slurp is broken AF though, and obsoleted by File::Slurper since the original can't be fixed without breaking accidentally working code in the wild.
Still mostly fine so long as you know you're only dealing with 7-bit ASCII, IIRC, but Caveat Emptor.
Ah, well I actually use Path::Tony's slurp functionality mostly, depending on if it's already available in the project (which it is in any I set up).
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.
Huh, I worked at a company that wrote 1.5 million lines of perl together, and we never ended up with those problems. Maybe you picked the wrong co-workers? You can screw up in any language.
Yeah ... most of my 2-company-ago's software stack was written in Perl. Worked very well.
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.
I have a decent amount of experience with Perl 5 and one of Perl's greatest features is also sometimes it's greatest liability, versatility. It's permissiveness tends to facilitate poor coding styles and methods which is why there's alot of bad Perl out there. Plus Perl 5 is just different for lack of a better term. If your proficient newer languages, Perl 5 and the Perl way of doing things probably seems a little strange.
It's different from the newer languages, it's different from the older languages, it's it's own thing. I find it really beautiful for that reason.
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.
I totally agree, I didn't mean what I said in a negative way at all. That's how I got into Perl. What made it cool to me was just how different it was. It's experimental, esoteric and functional all at the same time depending on how you use it.
Seriously...? I last worked with Perl in college (more than a decade ago) and thats perfectly understandable to me. There is nothing un-readable about that code as long as you understand Perl conventions. The more important part regarding code quality was whether that piece of code was encapsulated into an independent function or a snippet of a wall of text.
You should see C++ Templates! Even the idiomatic examples in cppreference.com will blow up your head and require multiple re-reads.
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.
Even if you never want to write any Perl code, I definitely recommend checking out some of the features of Raku. As someone who is interested in language design but never has (or likely will) use Perl for a project, I still found reading about Raku's feature set super interesting. Here's a whimsical slide deck that introduces a lot of the most interesting features: [0]. Even if you find yourself shaking your head at all the craziness, you at least have to admire Raku's success at fulfilling its goals of being a post-modern language optimized for fun (-Ofun).
I love Perl - the syntax, community, Larry Wall's writings and The Monastery. Occupationally I'm forced to write Ruby for a living these days but Perl's influence is there and enhances my appreciation or Ruby. I came into programming after reading in the Dreaweaver Bible that you could extend the search facility with regular expressions. Jeffrey Friedl's monumental Mastering Regular Expressions was listed for further reference and I was hooked. Perl was the natural language to learn if you were inspired by regexen and wanted to create dynamic websites back in the early 2000s so I sought-out Larry Wall's Programming Perl. That book is such a joy to read. I still dip into it today just for the quality of the writing ... and a little nostalgia.
Take time to really grok Perl and you may find the soundbite swipes at Perl don't make sense any longer.
Just because you can't read it, is not a good reason to hate it. But, as Larry says, "It is better to be hated by those who don't know you, than by those who do"
I find programming perl fun inversely to program size and proportionally to the need to slice and dice text. I didn't learn perl until the perl 5 era, but from what I can tell, I would've been as satisfied with perl 4, before they bolted on OO and tried to expand the applicable problem domain of the language. I mostly just use it as a super-charged awk and bash replacement for scripting.
The bolted on OO is really just one new function...bless(). The rest is package namespaces, which are also used for non OO purposes.
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.
It's not terrible to get working, but for many people a major point of OO is encapsulation and it doesn't work out of the box like that. You have to install another package or use the inside-out object model to prevent direct access to package variables and 'private' functions are usually by naming convention only.
It's just another example of Perl's biggest strength and weakness. Total freedom to build something amazing or shoot yourself in the foot.
Python and Perl have almost exactly the same OO model, yet many people quite like Python's OO, so that can't be it surely...
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'm not necessarily a fan of the OO in those either :)
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).
It's also pretty neat that you can bless any type as an object. People use the hash most often for obvious reasons, but you can use a scalar/string, array, etc, if you wish.
That's fair, though as mentioned, not much different from other scripting languages with OO. The _private convention seems to work ok in practice, if not in theory.
I also find it one of the least readable language. Or more precisely, the language that requires the most effort to be made readable. Every language can be made unreadable.
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.
True, it's very easy to make your code unreadable but other languages have the same drawback too. I would never pick it as the language for team projects. But with Perl you can really pack a lot of power into each line of code. It's hard to beat for scripting.
This is great news both for Perl and for Raku. I will probably bother to take a serious look at Raku now, sometime, if anything just for curiosity. Why not before? I have no good answer for that.
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.
I was a Perl dev a long time ago, and I think it made me a stronger coder. I still miss it, and I've not coded Perl for real in a decade.
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.
Interesting perspective there. Worth noting that Larry Wall trained as a linguist and "often compares Perl to a natural language and explains his decisions in Perl's design with linguistic rationale" [0]
> 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.
> On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.
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!
I think the reference was to languages in general. In James Joyce's Ulysses there are four or five chapters which all tell basically the same story, but written in wildly different styles - one like an ancient legend, another a 'stream of consciuosness', and so on.
Why not before? Because Perl is you know, dead. Jokes aside, it's a pretty nice language apart from the !$double .@sigils. If I'd switch from Perl 5, I'd probably switch to Ruby, as Perl 6 oops Raku is quite slow.
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]
Ok, twigils, whatever. They're next to each other so they're double the crazyness. Like the $#last_index in Perl. In Raku the . and ! are used to designate a private or public variable within a class definition. I got it backwards, which sort of proves the whole point. Push a private array nested into another and you have a bunch of gibberish worse than in Perl, where you'd only prefix it with \. Use an auxilliary variable and it feels too verbose. OTOH @{$hash{array_ref}} dereferentiation in Perl is quite annoying. And no, $hash{array_ref}->@ is definitely not how you fix this mess. I agree that sigils offer some insight into what type of the variable you are looking at.
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.
%hash is an actual hash with a nested array ref inside. If $hash is a reference to such a hash, yes. Never used the second syntax and I doubt that it works with something other than subroutines, but in that case it's either hash() where hash is an actual sub, or $hash->() where $hash is a subroutine reference. Both return an array refetence.
See? Confusing. That's why people hate Perl. At least I'm glad dereferencing is gone in Raku.
Ruby is also quite slow. The last benchmarks I saw makes it pretty clear Raku has closed the gap with Ruby (at least the mainline C implementation of Ruby) on a lot of fronts, and is likely to be faster for many things in another year or two and the VM gets better at optimization. My google fu isn't up to finding those benchmark results now, but it's no secret that Ruby is pretty sluggish compared to Perl 5.
I sure hope it will be faster because in my own tests it's slower than Tcl. And I've tested at least two releases a year since october 2016 when the stable Rakudo came out.
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.
I really wish the Perl 6 -> Raku change could let it catch up with other languages such as Python.
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.
Assuming you mean rename the next version of a programming language — I think that’s a horrible idea. The entire point of continuing with the previous name is that eventually the community will move onto the new language. I’m guessing Perl 6 made too many incompatible changes from Perl 5 though I don’t know much about them.
Perl 6 started out as a plan for the next version of Perl.
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#.
I don't understand this comment. What needs to 'catch up'? They are vastly different languages with different philosophies, there's problems better solved in either language.
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 ...
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.
I'd imagine that chances are high that whatever name you pick for something in one language - there would be another language in this world in which same or similar word means bad/offensive thing.
The social problem of the name is less similar to Lisp than I think you're making it, but I do agree it is probably not a terrible thing in the end and could be considered good. I don't think it's going to be impactful enough to "save" or not save the language (as someone mentioned elsewhere, if you called Betamax by a different name, it's unlikely the ultimate outcome would have changed).
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.)
When someone says they want to work in Perl6/Raku, they likely have vastly different problems than someone using Erlang/Elixer. There is overlap of course (both general purpose), but I can't imagine using Erlang for scripting, while Raku is first class here.
I can't imagine scripting in Erlang. Or rather, I've seen it done and it wouldn't be my first choice.
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.
As a testament to this statement I wrote a Google maps API scraper to get a list of driving distances from a pair of csv tables - shortname + address and shortnames to and from, in about 1 hour, and the whole thing clocked in at 90 lines of code including about 40 lines of comments.
That seems about right for a competent Python coder. It or Powershell or Linux command line tools would have very little code and be very easy to whip something up. Perl would be great here as well or honestly any dynamic language with great library support.
Elixir still has to borrow arrays from Erlang and it's a pretty ugly implementation at that so no - I would not agree that Elixir has an excellent set of first-class generic data structures.
Neither Elixir or Erlang have real arrays, unless you want to count tuples. That said, I don’t see how that correlates to scripting, the data structures that are first class in Elixir are very ergonomic and certainly flexible enough to tackle pretty much any task you’d use a scripting language for.
I guess it depends on what you're comfortable in? I myself have tons of Elixir scripts that I use to automate much of my life. It's replaced ruby as my go-to for one-off scripts.
Oh man I just love and adore Crystal. I am a long time rubyist and I have to say they just nailed it with Crystal. I just wish I had more opportunity to use it professionally!
It must be time to take my Ruby skills and go and learn this. Is it really as easy as it sounds like it should be for a lazy, dynamic-typing sort of Ruby dev to pick up?
If you have never worked with a strongly typed language before there might be some getting used to that, but any pain is well worth it. Catching all your mistakes at compile time and not at runtime is so amazing. Oh and it’s literally 100x faster than Ruby in some cases.
> Catching all your mistakes at compile time and not at runtime is so amazing
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.
I don't get it. How many types do I need, before the kind of data I am talking about becomes better represented by an object comprised of smaller pieces?
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?
Is a 100ms startup time really a big deal for something that is either going to be manually triggered or cronjobbed and expected to take on the order of minutes?
Ruby scripting has occupied the sysadmin space for over a decade yet on my 2013 Macbook Pro the latest Ruby 2.6.5 takes around 250ms to start. That's a mere 1/4 of a second. Sure, Python, Perl and PHP have shorter startup times but surely this is a non-problem?
You know that you are timing the compiler and not the compiled program here?
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.
Elixir/Erlang isn't a general purpose language. You pointed-out one reason why - scripting. Computation is another area where the language is deficient. I'd go so far as to say Elixir's failure to challenge mainstream languages for mindshare is down to to it occupying a niche - lightweight concurrency and distributed systems.
Their point was that elixir is a good language for scripting. I'm not sure if this is true but I don't see any reason it couldn't be. I don't think "distributed systems" are niche... I think every web application I've worked on fits that description, which is basically my whole career at all different kinds of companies.
For concurrency I think Raku has slightly more developed async support than Python, but the bigger advantage, I think, is in parallelism where, aside from the CPython GIL limiting practical parallelism in the main implementation (which is a big deal), Python as a language lacks the parallel iterables produced by the hyper (parallel but constrained to return in order) and race (parallel and not constrained in order) methods on the Iterable role in Raku, or anything like Raku’s hyperoperators that are semantically concurrent and parallelizable at the discretion of the optimizer. (Come to think of it, while also parallel, all those are also high-level concurrency constructs that Python lacks equivalents to.)
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.
Sounds like multiprocessing.Pool.imap and imap_unordered? When dealing with io you also have async/await equivalent iterators like asyncio.as_completed().
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 })
}
(Note that `start` does not need a block unless you are grouping more than one statement as I have above.)
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;
(Note that the left side of `xx` is _thunky_ so there are ten different Promises with ten different random wait times.)
---
You should see the `react`/`supply` and `whenever` feature.
I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).
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?
If it's entirely CPU bound, you can use multiprocessing to negate most of the GIL issues, and transparently send inputs/outputs between the parent and child processes. If it's I/O bound, then AsyncIO is a great way to express asynchronous workflows. If it's a combination of both I/O and CPU bound workloads, there are ways to mix multiprocessing and AsyncIO to better saturate your cores without losing the simplicity or readability of Python: https://github.com/jreese/aiomultiprocess
Very true, I had not even thought about the multiprocessing package; it's sometimes not as convenient as multithreading but it'll get those other cores working.
Indeed and as a Perl developer I make use of XS/external libraries, cooperative multitasking (event loops/promises), and forking to cover these use cases. It doesn't preclude wanting the additional option to take advantage of threads in a useful way, since they do exist.
Why should first-class concurrency needs be required to script in Elixir? This question seems to imply that Python is somehow a default language and special requirements must be needed to justify writing in something else. Elixir is general-use and pleasant to write scripts in so seems reasonable to me for someone to do so if that's their thing.
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 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.
I think so, at least in some ways. I've shipped a project using PowerShell to script Windows Server/Hyper-V, and it was a pretty pleasant experience. Having a scripting language that not only does typical scripting stuff (wrangling text, etc.) and understands your application's objects is excellent.
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).
It's a trip, and it took me a little while to wrap my head around. However, I now much prefer it to working with other concurrency abstractions (such as callbacks).
More to the point, does Python 3 have operators that transform sequential operations into operations that are both concurrent and parallelizable, and, in the case of iteration, provide control of parallelism parameters and whether results are constrained to be in-order or not.
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.”
The `start` statement prefix operator is a bit like Go's `go` keyword.
(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);
But what he was really talking about is something more like the following.
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
I'm embarrased to say I write scripts in node :P I used to write scripts in python but I've been writing so much JS that it's just easier for me in node. Plus, node defaults to locally installed deps so I don't have to deal with virutal environments.
Well just from experience untangling async calls in python is a nightmare and sometimes hard to reason about. The red/blue function problem is real. Meanwhile dispatching concurrent long-running scripting tasks is basically trivial in elixir (Enum.map over Task.async, then Enum.map over Task.await)
I'm guessing because Python's concurrency relies on the Global Interpreter Lock. Although I think concurrent.futures might address that. Haven't worked with python concurrency libraries in a bit.
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?
tldr; Using a scripting language that allows for native threads or has a strong concurrency model builtin to the core would be beneficial for any CPU bound scripting task...
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.
As I've posted above, I'm a bit confused by CPU-bound work being processed in a scripting language. If you're planning on doing intense CPU-bound work, maybe use a lower-level language? I'm not saying abandon Python: you can extend Python with C or just use IPC to transfer data between a Python front-end and a computation back-end.
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.
At one time it was an obvious dichotomy that you would not use a scripting language for CPU bound work, but these days it is a much more blurry line. Partly because modern efficient languages are becoming ergonomic enough to work well as scripting languages while still giving you very good performance.
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 totally you feel you, I guess I thought your question was substantially more surface level than it was. My apologies.
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:
Erlang is great, and I miss working with it, but I'd never want to write much in the way of 'quick scripts' with it. Something like Ruby feels much more productive for that.
Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason - standard libraries for file, dir and pathname manipulation written in a concise language. Scripting is a style of coding, not just a means to an end. It is here that dynamic languages excel. Clojure is the leanest of the JVMs but doesn't it still rely on Java for file, dir and pathname manipulation?
> Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason
Ruby is a JVM language, in that JRuby is a very complete competitive, current, and widely-used-in-production Ruby implementation.
You should definitely educate yourself about Groovy. It's my favorite scripting language, particularly because it enables a true scripting style, but actually works well as a full application development language too (though I would always want a backbone of static typed code).
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.
GraalVM does in fact fix that. There's a (new-ish) project called babashka that lets you do some basic scripting for example: https://github.com/borkdude/babashka
Oh certainly. I've done production work with Erlang, and it's great for building systems. I also love the Prolog syntax (I've also since done some side projects in Prolog for great fun).
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.
In fact Elixir and Erlang are the only reasonably known dynamic languages that differentiate on concurrency. The rest either do higher order event loop concurrency, which is ok, but not a differentiator, or do worse, shared memory multithreading (threads, coroutines with synchronous channels, mutexes, etc.)
I don't really know what "differentiate" means, but Clojure has support for CSP-channel style with core.async, shared-memory with transactions using atoms/refs, and actor-ish style with the agents.
> 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.
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.
Perl 5 was released in 1994. At this point, the "5" isn't really a version number anymore. It's just part of the name.
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.
Which in turn suggests the Java (and others') solution of dropping the 5 and making the minor version the new major version. Look out for Perl 31.0 soon.
And as another example, Mac OS X (10), which debuted in 2000, has had every subsequent version continued to be named 10.X. Just this week, macOS 10.15 Catalina was released.
Funny that the name Mac OS X went to OS X and then (back) to macOS, but the 10.X name persists.
I can say that at least currently, there is no appetite for Perl attempting to "reclaim" the Perl 6 version in the foreseeable future. It would be a disaster in both community relations and marketing. It will either be Perl 7 or Perl 34+.
I thought the relationship went the other way, that AS 3 was going to be standardised as ECMAScript 4? Not that it matters, I’m likely remembering incorrectly!
Standards are a two-way street, and we're probably both right from different points of view. (Especially, because AS 2 also had a number of the features proposed for ES 4, so even if AS 3 was "solely" inspired to be an implementation of the ES 4 standard, ES 4 itself took inspiration from AS 2.)
This is not entirely unlike that. Somewhere along the way, everybody realized Perl 6 was not the path forward from Perl 5, and so Perl 6 never really took the place of Perl 5, just like PHP6 never took the place of PHP 5. It looks like a pretty similar scenario, if you squint, I think.
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."
For those that can remember back that far, MacOS also jumped from 5 to 7. (7 was the first version that supported running multiple applications at once.. not counting the MultiFinder hack that came before it by a few years.)
It certainly did not. System 6 (including MultiFinder if you had enough RAM to support it ;) was active for several years in the early 90s before System 7 came out. The label "MacOS", meanwhile, didn't show up until a few years after that.
Doh, yes, system 6 was current for quite a while. I wonder what other thing from that era I confused it with. I swear something around that time skipped a 6.
Solaris skipped from 2.6 to 7. UnixWare also jumped from 2.x to 7. HP/UX skippped from 3.x to 6.x. In perhaps the strangest version jump of all time, Darwin jumped from 1.4.1 to 5.1, as part of Mac OS X 10.1.1.
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.
Windows 95 was Windows 4.0. There are several parts of Windows 95 that even indicated this in a user-visible way.
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.
Microsoft had to skip 9 because programmers are lazy.
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.
That would be an issue, but I don't think there is an appetite for a new major version of Perl at this point.
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.
Maybe it’s better to find a new name for the next Perl 5 language version. It would simplify internet searches. It should be clearly distinct from Raku though.. Angular is in a similar mess to Perl, very hard to find decent information on web crawlers
no, it's called cperl now. perl5 didn't see not much improvements for the last 20 years, the development happens only in cperl, which is the perl5 successor.
Even if file names/packages don't clash, there's still a conflict when it comes to documentation, articles, blog posts, books, stack overflow questions and other documents that might or might not be updated.
Hey Ovid. I'm curious...if P6 had been performant and production worthy enough for your tau-station game, how much easier would the project be than with P5 + Moose? Just curious...I remember you saying years ago that you would've used it if you could've at the time.
The https://taustation.space/ game runs great on Perl 5, but yes, with a robust Perl 6, many things would have been easier to implement. But by "robust" I don't mean just the language—I also mean the ecosystem.
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;
}
}
raku:
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;
}
And for those who don't "grok" the above, here it is in Python 3, just so you can see how clean raku's OO syntax is:
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)
Red looks interesting. Though I don't like the mapping of tables to "model". In general, I find that a model should be a consumer of an ORM, not the ORM itself. Otherwise, you expose to much to the business layer and it's harder to refactor.
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).
Rather reminds me of what happened with Palm OS 5 and Palm OS 6. Both ended up adopting separate names but because OS 6 wasn't backwards compatible the sheer weight of legacy software kept it from ever catching on.
I kinda wish something like this would happen with LuaJIT, so it can get out of Lua’s shadow.
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.
I find Perl 5 best for the kinds of fire-and-forget text processing scripts that are a bit too complicated for awk but not involved enough to bring in a "real" language. It's a double-edged sword - in a throwaway script it's awesome to not have to bother converting between the number 12 and the string "12", both numeric and string operators will work on them the same way. In a large project that kind of thing is just going to cause a bunch of untraceable bugs due to unidentified invisible behavior. Or you need to resort to weird hackarounds like "0 but true". Also: $_ is like that, only more so.
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.
I very much prefer "typeless data with typed operators" over Javascript's "typeless data with typeless operators" or basically any language that was forced to add ===.
It did, but CTAN was just a network of FTP mirrors. CPAN was that initially too, but quickly got supporting software to automatically download/update packages and resolve dependencies, which AFAIK nobody else did at the time. Even Linux package managers didn't get that until a couple years later.
One thing that fascinates me about Raku/Perl6 is how hard it leans into object-oriented programming at a moment when so many other new languages seem to be trending in a distinctly functional direction.
Raku excels at slicing and dicing input data. So, if you need to read from a database or a csv or anything similar, Raku is amazing at taking that data and converting it into the format to do processing on.
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.
Perl 5 has never been at the end of its life (though it was intended to be 15 years ago, things changed), this is one part of what this rename is meant to clarify. It still has a major release each year and modules are released to CPAN constantly: https://metacpan.org/recent
A lot of my colleagues in NLP and text processing still prefer to write in Perl. Granted they are mostly the old guard but it is prevalent in academic language technology research.
.. in the old guard of language technology research I guess, because in my NLP lab, no one knows the first thing about Perl (everything is done in Python)
More than that. I wrote my first machine learning project in Perl.
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.
There are many more tasks in NLP than what SpaCy offers even though it is a nice API. I use SpaCy near daily, but academic research goes beyond NER, dep parsing and PoS tagging.
For instance, [1] is a tool for text-to-pictograph translation system I worked on. The core engine is entirely written in Perl 5.
Years ago I worked with Rogue Wave Software, which sold C++ libraries. There was a customer who wanted to sort a huge dataset, and RW's sort code took something like 15 minutes to sort. Perl took 15 seconds. I don't know if it was ever figured out why, but it was (is) just one of those signs of how Perl still can be amazing at some things.
Still have my O'Reilly 1st Annual Perl Conference bag around. Good times.
we are using it internally for a lot of management apps. we just deployed a new authorization frontend for graphite / carbon using cro that is handling several million daily requests (per small EC2 instance).
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.
I like raku's grammars, and I appreciate the idea of having them as first class, in a way other languages don't have them.
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.
Had they done it fifteen years earlier, I think Perl could have been the language to learn for Data Science. It still is a fantastic language to slice, clean up, and extract information from text files, and it was already very widely used in bioinformatics.
"a fantastic language to slice, clean up, and extract information from text files, and it was already very widely used in bioinformatics" is a description of Perl 5, not Perl 6.
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.
I'm pretty sure GP is referring to Perl 5, not the newly renamed Raku. Perl 5 had a lot of use in bioinformatics, and to my knowledge lasted quite a while after the general Perl exodus, until eventually being replaced by biopython.
If the confusion regarding Perl 5/6 never happened, it might have retained that popularity in that domain.
IMHO Perl's reputation for noisy code is mostly the result of code golf examples online and denoting variables with an explicit type character.
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.
You're right. I find Rust code much harder to comprehend. But the sigils and the arrow operator are kind of annoying. I think Ruby fixed most of Perl's annoyances and created new ones.
It will have quite interesting implications, especially for former Perl 5 syntax enthusiasts. One could say in Polish they "code in cancer" ("programuje w raku").
No. "Z raku" would mean that "raku" accompanies you and the play on words would be gone because it would be either "programuje z raku" ("one is accompanied by raku the programming language") or "programuje z rakiem" ("codes having/with cancer").
Its runtime is quite a bit faster and enjoys a smaller memory footprint. It is also more amenable to "bash on steroids" scripting, and has a quarter-million canned solutions in CPAN.
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.
One thing perl provides is a few examples of how to handle utf-8 better than Python does.
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.
I love Python and I don't see the subset of the world dominated by Python changing to Raku any time soon. But there are some things that made me smile and nod and want to read more about the language. Two, off the top of my head.
1. Raku treats math in a manner that wouldn't surprise a mathematician. Or grade school student, for that matter. Witness:
(Raku prefers rational to floating point math when possible, but of course you can force floating point if you prefer that behaviour.)
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]
As a Perl programmer, this is basically a post I might have written (aside from knowing it's not dominant anymore :) One more really cool aspect is the first class Unicode support, which Perl can do but you have to work at it.
Maybe creativity. Perl world has always been proud to be able to solve the same thing in twenty different, often arcane, ways. Sometimes this is a good trait, other not so.
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.
There are static site generators written in Python you could use to publish a blog, like Pelican (https://blog.getpelican.com/) and Lektor (https://www.getlektor.com/). But yeah, if you want software that works like WordPress and generates pages dynamically on the fly, I'm not sure there's any good Python-based alternatives.
> 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.
I used a workflow automation system at my previous gig that used java heavily on the backend. Rakuraku Workflow was the name. I hated it. The name, that in japanese means something like “easy easy” (楽々) didn’t help much. It was a mess.
I wish them the best of luck, but in my experience rebranding a seriously off track project is often the treatment of last resort. It’s the vancomycin of struggling projects.
You're thinking of "Raca" from Matthew, it wouldn't make sense for him to call it based on that verse though since it's not a pleasant word. Jesus specifically says not to call your brother Raca. Why would he call his language that...
That's "rhakos" and doesn't explain it well since this comes from "Rakudo", but Rhakos means torn off cloth according to Strong's Greek concordance. I guess it fits though.
so, raku is shortened for rakudo the perl compiler. rakudo itself might be japanese but i can't confirm.
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.
In the same boat on the "why haven't people moved on"... Perl use to be ubiquitous but over time it's really gone to the wayside vs. Python tooling for more complex stuff, and back to basic BASH for the simple scripting needs.
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."
It’s the Perl culture, to do even simple things in the weirdest way possible and everyone will call you a wizard. Whereas the Python community praises complex ideas expressed as simple code and frowns on tricks. That’s why all but the the most obsessive have moved on. And from what I’ve seen Perl 6 takes it to the next level.
You pretty clearly have very little familiarity with "Perl culture" and even less with Perl6/Raku.
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.
It's unfortunate but that's the bread-and-butter of comment sections mentioning Perl (Perl 5 and Perl 6). And what's with "the most obsessive"? What's this supposed to imply?
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.
> it's always a hacked-together mess from an engineer who's likely no longer with the company.
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
{
}
type of thing. He didn't know how to operate a programmer's text editor.
I would rather deal with that than a project with millions of classes which are mostly empty full of useless comments that tell you nothing about how the project is put together.
> 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!!
> I'm unclear why people continue to use Perl at all
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
I would argue that becoming "legacy" is akin to bit rot. Sure, it still runs, but everyone that knew how it worked has left the company, and it's written in a language that is no longer in vogue and will require specifically hiring people with that skill to maintain.
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.
For people who are curious as to why people moved to Python. Some will say because college kids are taught Python, but I think that is a side effect.
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.
People like easy to read languages. Many years ago, when I first got back into development, I decided to choose to learn Python or Perl. After doing some research, it seemed Perl was more widespread. But Python was easier to read, so I went that route instead(luckily). I think the popularity of Basic and Golang vs their competitors of the time help prove this point. People say that Go is only popular because of Google, but I honestly feel if Rust and Go switched owners, it would have played out the same way.
And other people love chasing new shiny things. I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does.
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.
I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl.
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.
> I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl
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.
Okay, I see. You should use what most easily provides the features you want, to be sure, and it certainly has not been battle tested the way, say, Catalyst has. But I think you are still selling it short. Mojolicious is foremost about consistency and practicality, beauty (if you would consider it that) is simply a side effect; and it is probably in more use than you think.
> That's just a saying, it doesn't mean that there's one specific reason
> 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.
Modern web development doesn't use these, and mod_perl is certainly not recommended anymore - CGI still has its uses, but don't use CGI.pm. A modern webapp is written in Mojolicious or a Plack based framework, and they can all deploy transparently via a standalone server, or any PSGI or CGI server, or even mod_perl or fastcgi if you really need to.
If you do not build gigantic monolithic applications and instead stitch together lots of things that do just one thing each using jobs engines and APIs for injecting data and collecting data most of the worker updates become trivial - minutes rather than months. It becomes irrelevant if a worker is written in perl, python, C, java, scala, etc.
Genuinely curious - and not trying to be a jerk... but where do you find Perl fits well? I can only imagine needing it if I'm stuck on a legacy OS/strictly governed environment where it's the only option I have. (ie: governmental work etc.)
Oneliners that range from simple text processing to complex magic. Wonderful web applications in Mojolicious. Lexical scoping and strict variable checking. Four strong event loop ecosystems, futures and promises, and an in development async/await syntax all for collaborating asynchronous tasks. Great integration with shared libraries through XS and FFI. A consistent culture of documentation and testing for everything on CPAN. And mainly, familiarity with the language.
Perl is really great at text processing. Pretty much any kind. A lot of folks dislike first-class regexes, but if they're magic in a lot of contexts like this.
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.
In this case, it's a Perl concept related to DWIM (Do What I Mean), where the features will make practical assumptions about what you need to accomplish in their implementation, so you don't have to worry about the details. It can be abused (and is) but is also very useful for quick oneliners in particular.
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.
If it involves a lot of text processing, Perl tends to be either my first choice or pretty close to it. Perl's also surprisingly fast for an interpreted scripting language (especially when it comes to text processing). I've used it pretty heavily for system automation tasks, too, and thus generally continue to do so unless there's some specific reason why I'd need to use a different language (and usually there ain't).
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.
Not grandparent, but to me, Perl's niche is short log-processing scripts (like, 200 lines or fewer). Once it looks like it will either need an input other than a text file or grow to a significant length, I tend to rewrite in something else.
However, for short log processing scripts, I've not found anything with even close to the same productivity.
Brain dead workers. Ask what to do. Fetch the needed data. Do the thing with that job. Signal job completion or failure. Die. Wait for a supervisor to restart you for the next job.
Yep. Nowadays Erlang (or Elixir) would be my tool of choice for that, but before discovering those (or when that felt like overkill) a quick Perl script would be my way to go.
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).
> FWIW: I'm unclear why people continue to use Perl at all
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...
Hi, would you mind reviewing the site guidelines? I'm afraid your comments have already been breaking them quite a bit, and we ban accounts that do that.
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.
Not sure how to edit, but for those who don't understand this comment, Zoffix was a key Perl6 contributor who recently left because the community and Larry Wall wouldn't change the name to something else like "Raku" among other things I guess. Now that they have made this change, I'm curious if he'd ever come back and start running the test suites again.
Julia itself is stable. Julia allows writing libraries (packages) that are as performant as built-in libraries; in some cases it's hard to remember that these external packages are ... external and sometimes not as stable as the core language and standard libraries.
There is no CUDA API in the standard language. The tools for automatically generating CUDA code from Julia code is the CUDAnative.jl package, which at this point is pretty stable and has fairly widespread use.
Well, that's what reaching 1.0 was supposed to represent, but I don't (get to) use it (for the kind of work I do) so I cannot say for sure if that actually worked out in practice.
There were packages I wanted to add features to last week that I've used daily for years, and when I went to go check them out, I noticed they hadn't been touched since the 1.0 release which is now over a year ago. So I think the stability of 1.0 has worked out well since, in contrast to pre-1.0, these days core packages don't even need maitanance and will still continue to work perfectly well for years.
The naming is a very good idea since it really is a totally different language and the numbering made it seem like an incremental upgrade. Whether it's too late will remain to be seen. Also, now maybe there is space for an actual Perl 6! :-)
Well right now I avoid using any tool written in python that doesn't have os-level packages because there still isn't a clean way to use python repos without deep understanding of how python works.
I think this is more connect with the lack of familiarity with the language ecosystem than anything. I avoid tools written in node.js, even if installing is somewhat easy, most because I don't really know how to manage them later.
Btw, nowadays with a modern pip a simple `pip install --user package-name` works.
No, it's due to two reasons. Devs don't ever think about who might be interested in using their tools and just assume that everyone who might want to use their work has just as much knowledge as they have in their particular mineshaft.
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.
Perl certainly has a similar spread of problems and solutions, some of which clearly were inspired by python and ruby solutions. local::lib, Carton, perlbrew/plenv are all recommended immediately to solve these problems, but they are still solutions one has to go looking for, it's easy to first fall into problematic setups by not using them (at least all modern CPAN clients will set up a local::lib by default now).
The Python situation had a major difference: the current maintainers of Python 2 and Python 3 are the same, and Python 2 is still intended to be EOLd. A clean break would surely have avoided many problems but it's hard to speculate how it would have gone.
Call me a pessimist, but its too little too late... I learned regex in perl so the language will always have a soft spot in my heart. But Python has trounced Perl for almost any task. There simply is no reason to learn perl unless youre in the unfortunate position of managing some legacy stack.
> Call me a pessimist, but its too little too late...Python has trounced Perl for almost any task.
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
It's almost as if Python marks the pinnacle of programming language research which isn't the case at all. In fact, I daresay no language can since programming languages are a matter of compromises and trade-offs. A language's compromises and trade-offs you're willing to put off with might not be the same for another person. There's an interesting phenomenon I've observed in the Perl community (or at least the Raku for the most part) which seems to be rare in other places: Whenever a situation arises where Raku might not be the best candidate for, community members aren't afraid to consider/suggest/recommend other programming languages as viable options.
It does but it's still annoying to write on a line as opposed to Ruby or Lua. Writing Python one liners with significant whitespace is out of the question I guess.
Raku includes an incredible amount of new tools for writing one-liners. Furthermore, you can convert your one-liner into a command line app simply by wrapping the code in a `sub MAIN($pos-arg, :$named-arg) { ... }`.
Incidentally, it also happens to sound similar to "roku" (="six").