Incidentally, it also happens to sound similar to "roku" (="six").
Also, while 'raku' is the reading for 楽, which connotes easy, simple and other good things, it is also the reading for a bunch of other characters--namely, 落, which means or carries the connotation of falling, declining or otherwise missing the mark.
When I see the 'raku' transliteration in the context of Perl, I think of 落. Not sure if that says something about my subconscious perception of Perl or not, but I can't help but think 'Raku' is a bad choice for the name of a language mired in indecision and falling from public favor.
On another note, I find the inclination of tech projects towards poorly translated Japanese words amusing. It nicely compliments the phenomena you see in the use of random English words for the naming of Japanese cars, condo buildings, and other 'prestigious' products. So if you find that ridiculous, you should find these 'Japanese' technology names ridiculous as well.
Rakudo means paradise: https://jisho.org/word/楽土
Rakuda is a camel: https://jisho.org/word/駱駝
One of the worst problems for adoption of perl6 has been always overthinking. "Hey, look at my cool name" has never convinced anybody to use a computer language. Too many names.
Raku is a good name indeed. Like a promise of prune and simplify all the former zoo of names that could finally allow the people to focuse in the program
You're overthinking it. I don't think those who came up with the names did so to, or cared to, convince people to use the language with them...
(Hebrew word formation is from 3-consonant roots, not concatenation, so removing a letter doesn't give a related word. It's either an invalid word or a different root with 3rd voiceless consonant רקוא which is a not a root / רקוע Raku'a "flattened" but that doesn't sounds quite differently.)
Webinar is similar in spanish to the word huevina that means "egg beaters" (a replacement cheap and second quality). It sounds also like "web-vaina" (a vaina is "something" and specially used when something annoying happens) and has common roots with words like "huevín" (little testicle) and "huevada" (something irrelevant, lacking of any real interest and a total lose of time).
Definitely looks like something created to be dismissed. I can't thing in a worst 'hype' word for replace (without any real need or reason) the perfectly neutral and good old term 'videoconference'. Webinar is the kind of term that Ned Flanders would use.
Seeing that webinars have caught on like wildfire, become a multi-billion dollar business, and forced all kinds of eLearning and online platforms to say they offer the ability to produce/share "webinars", I'd say this is rather a counter-example.
I.e. more like "A few might find X or Y name off-putting, some outliers might even come with contrived meanings in unrelated not-exactly homonyms in different languages that supposedly would make a name unsuitable, but in most cases nobody really cares".
That created some kind of limbo where people weren't sure if they should use perl 5 or perl 6 (”why develop in perl 5, when it is probably a dead end and perl 6 is the future” and at the same time "why should I convert to perl 6, what if it will be a failure and I wasted my time?")
By renaming it, it revives Perl 5 so developent can continue, and at the same time Perl 6 is presented as a new language, now whichever wins will be based on its merit.
When Perl 6 finally arrived, it was too much of a step change from Perl 5 to convince many people (myself included). Meanwhile, Perl 5 had continued to develop and was, in no way, in need of a replacement.
The name Perl 6 was damaging to the popularity of Perl because beginners were confused whether they should learn Perl 5 or Perl 6. The same confusion existed in Python: Python 2 vs. Python 3 but the Python Wiki was always very clear. Until a certain point, it recommended Python 2 and after Python 3 became very popular, it recommended Python 3. That sort of clarity was missing in Perl. Due to the number of new programmers learning Perl decreased rapidly and finally Python overtook in popularity.
Not that much.
>Nim changing from "Nimrod" matters
Hardly.
>Cockroachdb's name is offputting.
Not enough to matter. They still raised over $60 million in funding...
Many people have internalized Marketing/SEO/enterprise-pointy-hair-boss thinking about "what matters", but in the grand scheme of things, naming is not really that relevant...
Secondarily, while Perl has never appealed to me I am more likely to admit I'm checking out Raku because the chances that someone will ask me to look at and debug their cousin's friend's manager's Perl 3 CGI app is considerably reduced.
Rakudos, even!
Most of the anti-Perl comments I've heard have been from people who really didn't know it very well, if at all.
Some of them might have glanced at some Perl code and saw a dense regex and dismissed it as "line noise". Well, yeah, if you don't know regexes you would be forgiven for thinking it was line noise, but if you did know regexes it should look no more like line noise than a similarly dense regex in any other language.
For a long time now, Perl has allowed regexes to be commented. Commenting dense regexes and splitting them up in to short regexes assigned to judiciously named variables is just good style in any language, and has been the norm in Perl for a long time. Furthermore, modern Perl style guidelines advise code to be written with verbose, English words instead of ancient Perl one-character special variable names.
So setting aside both dense, uncommented regexes and ancient single-letter special variable names, both of which have been recognized as poor style in Perl for decades now, I'm really not sure what the complaints about Perl readability are about. To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.
If you include non-mainstream languages, some languages which have a lot of fans here on HN are arguably a lot less readable than Perl to someone only familiar with traditional Algol-style languages. In particular, I'm thinking of Forth and Haskell. Yet you rarely hear complaints on here about their readability.
It's what my company's entire code base is written in. So every hour of every work day for the past 6 months.
>To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.
It's no one thing, but a bunch of little things that compound on top of each other. Until you get something like this:
while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };
Mostly though it's how it's used. It can technically do anything, so a lot of the times it is asked to do everything. Until one day you wake up to find you have hundreds of perl files, all tens of thousands of lines long, that all interconnect in an insane Object Oriented hierarchy soup stretching across every conceivable programming space - from database control to money processing to security to web site design.
Indeed, I hope this thread gets picked up by http://n-gate.com/
Take time to really grok Perl and you may find the soundbite swipes at Perl don't make sense any longer.
I'm never sure what people don't like about OO Perl. There's a tiny bit of boilerplate in a constructor, other than that, it doesn't seem different from other OO script languages.
But it is also one of the most writable language. In Perl, for most problems, there is a quick and dirty way of addressing it. It is especially true when it comes to processing text files, the thing that Perl is best known for.
Many languages try to be clean and consistent, it is obviously good for readability, but it means that choices have to be made. Sometimes the best way is the "wrong" way and you have to fight against the language. Perl solved that problem by not having a "wrong" way of doing things, screw cleanliness and consistency.
Also, first class regex are awesome for quick and dirty text processing.
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.
You're correct about "over-the-top cleverness and arcane constructs" being a problem, but it's also about using code as communication. We code in _languages_, and on one extreme is coding newpaper style - lowest common linguistic denominator. On a good day this is a common, understandable language, and on a bad day it is trying to communicate with stilted baby talk. On the other extreme is dense linguistic cleverness. On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.
As coders we like to talk about using the right tool for the job, but in code we so often assume that the most stilted repetative pattern is always best. It often is - like newspapers, we can't (or shouldn't) assume our audience is well-versed in our material. But we have other constraints as well. I often argue in favor of _skimmability_ over _readability_ of code. That means that the attention/focus of the eye is important. Stilted languages with minimal syntax give you almost no control over that. More fluid languages like Perl give you a lot more flexibility. Learning to use that flexibility to increase clarity...for MOST people, not just for yourself...is a skill that most of us have only limited practice at, and none of us have mastered.
But it's a good idea to work at it, and when done well you communicate MORE with LESS, and it's something people notice because it's not buried in the midst of visual noise.
> On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.
So true. I think Perl golf could be Samuel Beckett.
If Raku's "bad day" is basically like "one of the most influential and important authors of the 20th century" (according to Wikipedia)… well, then, maybe I should check Raku out!
In this case, `!$double` isn't a sigil. `!` is just the old prefix operator for negating a value [1]. If you meant to write `$!double`, then it's the twigil [2] for class attributes [3]. Twigils could be considered as secondary sigils but they affect the scoping of a variable. In this instance, `!` is for class attributes and will only be found there.
As for `.@sigils`, I've never seen this syntax. I'm probably out of the loop in this one.
As an aside, sigils are one of Raku's interesting features. They convey information [4] that might not be easy to discern from just looking at the code. What kind of structure is this variable holding? Is it holding an array? A hash? A code object? What's the scope of this variable? Is it class-scoped? Is it dynamically-scoped? Is it a compile-time variable?
> ... Raku is quite slow.
This is a legitimate reason for avoiding the language. However, it's worth pointing out that Raku core developers have made great improvements to the language in the speed department since it was first officially released in 2015. They recognize there's a lot of room for improvement. [5]
[1] https://docs.perl6.org/routine/!
[2] https://docs.perl6.org/language/variables#index-entry-Twigil
[3] https://docs.perl6.org/language/variables#index-entry-$!
[4] https://docs.perl6.org/language/faq#Why_sigils?_Couldn't_you...?
[5] https://docs.perl6.org/language/faq#Is_Perl_6_fast_enough_fo...?
Edit: sorry for the confusion. I meant popularity-wise. I wish the change would clarify to people that Perl 6 and Perl 5 are basically two different languages and people should at least consider Perl 6 as an option when they start a new project.
The features demonstrated in this talk are worth a watch (or at least a scroll through the slide deck): http://tpm2016.zoffix.com/
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#.
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.
+1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol?
"Raku" = "cancer" in Polish. Not a lot of Polish enthusiasm forthcoming, I'd imagine.
The reason I think it's not related to the Lisp issue is because the relation of Perl 5 and Perl 6 was like an unofficial successor with a compatibility mode, like C and C++, whereas the relations between Lisps that create the social problem you highlight of people not knowing about "Real Lisp" are the relations of very incompatible forks with varied functionality running around calling themselves "Lisps" or "members of the Lisp family" and people confusing that with "Lisp". (There were some "Perl 5/6, C/C++" types of relations in the path to Common Lisp like Flavors/CLOS but no one remembers or cares about those outside of Lisp users...) Another reason is the timing, why the name change now, years later -- it turns out Perl (5) is less dead or possessing a stench of death as you put it than people might want, it's still vigorous in its own rights, and so really it makes most sense to just call the new thing by a new name and not destroy both. (Larry's wineskin comment is nice.) The Python 2/3 situation is a closer analog if we counterfactually imagine Python 3000 came out with the current 3.7 feature set, syntax updates, and backwards incompatibility. Python 2 users (me among them) would still have dragged their feet, since Python 2 would still have been useful, still had its own vigor, the same as presently, but it might have resulted in renaming some later version of Python 3 instead of the current situation of renaming the continuation of Python 2 (Tauthon).
Going back to the lisp issue to further elaborate why I think it's not very related to this one, the languages that called themselves Lisp (not a Lisp, but Lisp or Some Lisp) shared a heritage going back to the original McCarthy Lisp. The merely "a lisp" languages used that for marketing, but were actually called something different (Clojure, Scheme, even Racket which has to further distinguish itself from Scheme). You see the heritage in the actual Lisp 1.5 manual, where one of the earliest examples should quickly dispel any illusions today about "Lisp's" supposed purity when they show the function 'length implemented with a program block and goto. By only modifying the top-level function define format and substituting ADD1 with 1+, the program works to this day in Common Lisp. For members of the lisp family that don't call themselves lisp, you're not going to be able to make such a trivial transformation, because there's no shared code heritage, just a vaguely shared s-exp-ness to the syntax. And right after that the manual describes the "pseudo-function" 'trace, which to this day is lacking in supposedly modern languages or requires a bunch of IDE ceremony to set up. It's present in CL and behaves the same, though. Continuing to call CL as simply Lisp seems pretty well-deserved.
The Lisp social problem then is that people run into members of the vaguely defined lisp family like Scheme (especially with SICP formerly being a common gateway for freshmen or HS students) or Clojure and confuse "a lisp" with "Lisp". They can spread their confusion further by releasing a project/blog like "let's write a lisp interpreter!" that can be understood correctly as "let's make a program that interprets code for a lisp¹" but tends to be misunderstood (sometimes even by the author) as "let's make a program that interprets code for Lisp".
Of course I also think this "social problem" is way overstated, especially these days when it's so trivial to dispel the old myths and when the gateways via Clojure or Racket are actually good in their own right and so don't leave the same impressions of "Lisp's a neat toy" that only seeing SICP Scheme could. But if people keep talking about the problem as if it is big, perhaps it will become self-fulfilling, hence my long comment in disagreement. ;)
¹ aka a member of the lisp family based on my vague membership criteria that probably don't even pass Steele's 3-part acceptance test in https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf that requires as its final step (atanh -2) to return a complex number. (Bonus if the correct complex number.)
Elixir is worth a look. It's a pretty productive little language with a great concurrency model.
I hope that doesn't mean that when Perl needs a major number version change again, they'll chose 6. It would be pretty confusing to have 2 Perl 6.
If you did a "major version bump" from here, you'd probably have to bring the "5" along for the ride. Like Java version 2, where you had J2EE version <X> for years.
In reality, there probably never will be another major version bump of Perl 5, in the marketing sense. The minor version number is really the major version number now.
To avoid confusion they would probably break the version convention entirely and name it with the year instead. So instead of Perl6 it would be Perl'19.
There is no DBIx::Class (or related schema loader) for Perl 6. I don't know how mature the web frameworks are. Or even basic stuff like Excel reader/writers (we use lots of Excel for backend data analysis).
On the other hand, most of the async stuff we currently use can be thrown out. With raku's gradual typing, our in-house type libraries can be tossed out. Our local modules for making it easier to write clean procedural and OO code could be thrown out.
And the raku code would be far more concise and easy to read. Here's a simple Point object in Moose:
package Point {
use Moose;
use overload '""' => \&Str, fallback => 1;
use Moose::Util::TypeConstraints;
subtype "PointLimit" => as 'Num'
=> where { $_ >= -10 && $_ <= 10 }
=> message { "$_ must be a Num between -10 and 10, inclusive" };
has [qw/x y/] => (
is => 'rw',
isa => 'PointLimit',
required => 1,
);
sub Str {
my $self = shift;
return sprintf "[%f,%f]" => $self->x, $self->y;
}
}
class Point {
subset PointLimit of Rat where -10.0 .. 10.0;
has PointLimit $.x is rw is required;
has PointLimit $.y is rw is required;
}
class PointLimit:
def __init__(self, name):
self.name = name
def __get__(self, point, owner):
return point.__dict__.get(self.name)
def __set__(self, point, value):
if not -10 < value < 10:
raise ValueError('Value %d is out of range' % value)
point.__dict__[self.name] = value
class Point:
x = PointLimit('x');
y = PointLimit('y');
def __init__(self, x, y):
self.x = x
self.y = y
def __str__(self):
return "[%f,%f]" % (self.x, self.y)I wasn't aware that there was one beyond the poor sods charged with maintaining my youthful sins.
We're still out there, but it's not "cool" to talk about.
Lua has breaking changes all the time, which makes sense for its original purpose — embedding — where you don’t need to follow updates. As such the version supported varies among different environments. But LuaJIT has an ecosystem that they try not to break. It’s more of a “conventional” scripting language because of that. It also has an FFI that isn’t in plain Lua.
CPAN invented the software repository, and I'm glad it was there so PyPI/Gems/NPM/etc. could learn from its mistakes.
Every few years I tried an alpha of Perl 6, but it was always too slow and unstable to get anything real done, and it was always a totally different implementation from the previous one I'd tried. Maybe this name change shows they're getting serious now.
Not only that, but when Perl 5 was at the end of its life, comparing its libraries to both Python and Ruby, you'd often find the best library was for Perl.
Raku should be far faster than Python and Ruby and may in the future have better libraries with excellent concurrency support, making it a good choice to do processing over the data, not just converting it to the format you need. It has an easy interface with C and C++, so you can import libraries from there too, if you need more speed.
Before Python came to fame Perl was primarily used by two groups: 1) sys admins who needed bash style 1 liners, but in a cleaner language (This is where the dirty code stereotype comes from.) and 2) Web devs. Much of the early pre PHP internet and even post PHP internet was written in Perl. When Perl on hiatus the web world turned into this mess of frameworks like it is today. It used to be a more unified world.
And then there is the rare 3rd group. I worked on earlier ML projects in Perl before Python was a thing. I enjoyed Perl more than Python and so did the people around me. Moving to Python / R was somewhat painful knowing it could have been better. I hope Raku takes up this torch and is good as it appears to be.
Still have my O'Reilly 1st Annual Perl Conference bag around. Good times.
raku is a great language to work with for us. it is feature rich, has good abstractions, and developer friendly. if you like the syntax then give it a try.
But you have parser libraries that work very well in all major languages, and I'm not sure being integrated in the language makes Raju more valid for any project.
What it does, imo, is offer a special way to solve some stuff by already being there. But it's like saying someone would choose python for a project because it has a built-in set data type.
One thing that struck me,
12. Both raku.com and raku.org are currently available.
I was surprised that a 4 letter .com or .org is still available. So I looked it up and turns out to be not true.
And it was interesting half of the discussion had domain name availability as factor.
[1] https://github.com/perl6/problem-solving/issues/81#issuecomm...
PyPi has caught up with CPAN in terms of sheer number of packages, but there are still a lot of differences in what those packages cover. You might find solutions in CPAN without a counterpart in PyPi.
More narrowly, every time I deal with databases in python, I find myself missing perl's DBI, which provides the same API for all databases with a corresponding DBD. Python should get a similar universal database interface someday.
To put this another way, my 10-year-old perl-based web crawler did not have a problem crawling websites with umlauts in the hostname. Python is fixing supporting that new 2008 standard next year.
Read https://www.evanmiller.org/why-im-learning-perl-6.html or the follow-up https://www.evanmiller.org/a-review-of-perl-6.html
Or, Why Perl 6 is the "Game of Thrones" of programming languages: https://techbeacon.com/app-dev-testing/why-perl-6-game-thron...
Lots more where those came from...
1. Raku treats math in a manner that wouldn't surprise a mathematician. Or grade school student, for that matter. Witness:
$ python3 -c 'print(0.3 == 0.1 + 0.2)'
False
$ ruby -e 'puts 0.3 == 0.1 + 0.2'
false
$ perl6 -e 'say 0.3 == 0.1 + 0.2'
True
2. Concurrency is a language goal in Raku and I think that's notable, compared to Python. Parallelism, concurrency, and asynchrony including multi-core support.[1]
And Perl programs do not spontaneously decompose when copypasted also.
And CPAN is still a very profitable gold mine to explore.
Movable Type is about the only blog framework not written in PHP. If you thought Perl was a bad language, PHP is way, way worse. And Movable Type is also the only one that can use Postgres for storage.
I could not find any blog engine in Python.
> If you thought Perl was a bad language, PHP is way, way worse
In fairness to PHP, it's a lot better today than it used to be. (Though modern PHP would probably strike a Pythonista as too Java-ish.) And WordPress has had tons of engineering resources poured into it for a decade-plus now, whereas Movable Type has been maintained on a relative shoestring due to its fall from popularity.
Names matter.
google, in their infinite wisdom, doesn't want to translate the word because they think i am typing it wrong and they know exactly what i meant to type... but anyways, i think it has to do with paradise or heaven, but i could be wrong.
Perl6 is basically a different language much to the chagrin of many Perl users. A lot of Perl users are entrenched in Perl5.
FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011.
Every time Perl comes up in a professional environment for me I'm reluctant to say I'm capable, because it's always a hacked-together mess from an engineer who's likely no longer with the company. (obviously this is VERY anecdotal to my career)
I dropped Perl from my resume about a decade ago because I just frankly don't want to work with it. The language is terse, and I don't think anyone who's starting off these days would be spending their time well by learning it. Make your own opinions, but mine is/has always been "ewww."
Because there's a huge amount of applications and websites still built in it, and it's still a great language so new projects are written in it all the time.
source: my very prosperous career, which has been almost entirely in Perl for the last 15 years
Because it works. Scripts/software that works does not experience bit rot. As long as it works, people will continue to use it.
Edit: OK, fine. It seems the downvoters are convinced that the code does in fact experience bit rot, and spoils with time. Probably like fish.
It does the job
Great language, large library on cpan, great eco system, people enjoy using it, they have a large code base that's run fine for decades. Choose 1 or more.
> I moved on in 2011
You're right, it's all about you and what you do...
http://blogs.perl.org/users/ovid/2019/08/is-perl-6-being-ren...
It already supports a variety of parallel techniques but it's about to get easier and safer (e.g. safe I/O).
Moving forward I'm assuming you're talking about Raku and not about Perl (or Perl 5).
Do you mean little too late to be endorsed by a multi-million company? Or little too late for everything (personal projects, academia, etc.)? I'm trying to clarify this because I've never understood this sailed ship mentality regarding programming languages. And I know you're not saying this but it almost sounds like Raku is supposed to be a replacement for Python. It isn't. They're different languages, both good in some areas and bad in other areas. These areas need not be necessarily overlapping.
Whenever I read this kind of comments, they always remind of the following phrase I came across:
There are two things that a programming language needs to be acceptable:
- Be Python
- Be a language I have used recently
Well, I think Perl beats Python in quick and concise one-liners written from the command line, doesn't it?
Not that I know much Perl, though.