I honestly did not expect to see the day Perl 6 gets finished. This must have been one of the most difficult - if not the most difficult - births in the history of programming languages.
At work, I have been using Perl 5 increasingly often over the past two years, mainly because handling unicode in Python 2 is not a lot of fun (and I still haven't come around to learning Python 3), and I have rediscovered why I used to like it so much.
So far I have not looked into Perl 6 seriously, because I did not see the point to do so before it was finished. Guess I know now what I'll be doing this Christmas. :)
Also, you gotta love Larry for quotes like this one: "This is why we say all languages are religious dialects of Perl 6..."
If you haven't had the time to learn the transition from Python 2 to 3, don't expect to find time to transition from Perl 5 to 6. Perl 6 is orders of magnitude more different from Perl 5 than Python 3 is from Python 2.
Perl 6 is not different, its a new language. You don't transition from Perl 5 to Perl 6. You learn Perl 6 as a new language and use it.
That's completely different compared to the case of Python, where Python 3 is a continuation from Python 2. But breaks backwards compatibility with the entire ecosystem. Bulk of the language remains same, you are migrating non backwards compatible parts.
You can build Perl6 and try it right now if you want, see my [early Perl 6](http://g14n.info/2015/03/early-perl6/) article for detailed building instructions.
Tiny correction: I heard it as "all languages are really just dialects of Perl 6," which makes a bit more sense in context. Either way it's a cute Wall witticism, of which there were many that night. Word has it that there will be a video in a couple of weeks, at which point you can judge for yourself!
There is really no way for a simple program to account for all of those possible edge cases. Something as simple as a print of a string can be a minefield depending on what is in those characters. And it's not like the old days where you could safely filter out all non-printable characters to avoid most problems. Have you considered how your formatting is going to look when people intersperse Right to Left words in your output for example?
The boilerplate on there is only a start. Any time you read or write a Unicode string, or do any manipulation of the string, you need to consider possible edge cases, and they can be nightmarish.
Consider something as simple as outputting zero padded numbers (so they form a nice column in the output), except that the numbers might not be Arabic, zero might not be 0, they might not be written in the direction you expect, and padding might not even make sense. This is how you go crazy.
"At work, I have been using Perl 5 increasingly often over the past two years, mainly because handling unicode in Python 2 is not a lot of fun (and I still haven't come around to learning Python 3),"
> One of the most impressive things Larry demonstrated was the sequence operator, and Perl 6's ability to intuit sequences.
say 1, 2, 4 ... 2**32
> This correctly produced a nice tidy list of just 32 values -- rather than the 4,294,967,296 you might expect.
Someone with more time than me needs to find an IQ test that is based around sequence questions like this and plug them all into Perl 6. So we can find out what Perl 6's IQ is and whether it has achieved AI.
This is cool but I still don't get how it is able to distinguish between linear, power, exponential, etc. sequences so easily. Would be incredibly interested in reading about the technology they're using for this and how complex it can get.
Ah so it's similar to the haskell list comprehension syntax, converted to a point-free form (and with added guessing/defaulting due to the ambiguities therein).
[x*2 | x <- [1..10]] -- linear
[2^x | x <- [1..10]] -- exponential
[1 | x <- [1..10]] -- constant
IIRC haskell list comprehensions can't do fib without naming the list so it can refer to itself. OTOH, these perl list comprehensions seems unable to express things that combine values from several lists, eg:
[ x*y | x <- [2,4..8], y <- [-1,0,1] ] -- [-2,0,2,-4,0,4,-6,0,6,-8,0,8]
Course, haskell also has a weak form of [x1,x2..xn] syntax for a linear sequence, as in [2,4..8]. That's always felt a bit of an unnecessary wart in haskell to me, although the simpler [x..y] and [x..] are very handy syntaxes.
TBH, I almost never use list comprehensions either, preferring regular functions, and the list monad or applicative.
(*2) [1..10] -- linear
(2^) [1..10] -- exponential
repeat 1 -- constant
fibs = 0 : 1 : zipWith (+) fibs (tail fibs) -- fibonacci obvs
(*) <$> [2,4..8] <*> [-1,0,1] -- same as [ x*y | x <- [2,4..8], y <- [-1,0,1] ]
I would assume that it has those too. Due to the main implementation being Pugs for a while, the language absorbed a lot of Haskellisms (chiefly laziness).
The range operator (..) is also pretty cool, since we're all lazy now. Here's an infinite lazy list of prime numbers in Perl 6 (declared as a constant because you presumably don't want to change 'em):
With things like this, it makes me glad I write C++ (and that gets bashed enough!). I do not miss the days of maintaining a Perl codebase (and trying to decipher what on earth code was doing). This is insane.
Perl is a language sufficiently different from the main bulk of languages that one must make an earnest effort to learn it before one can read it. Your complaint is similar to someone declaring Japanese insane just because of the way its writing system looks like gigantic and erratic complexity to the inexperienced.
You pretty clearly have an emotional attachment to Perl, which is sort of lovely to see, but it's causing you to be undeservedly condescending to people who don't have that attachment, which is not lovely.
I'm sorry if my comment seemed condescending, but it is a sad fact that many people learned Perl only by reading code and looking up small bits and pieces they don't immediately grok (instead of turning towards and consuming, complete and well-written learning resources both in the perldoc references and books) and then walk away with completely skewed impressions and share them with the world at large.
I wish i had a more polite way of pointing this out when people make complaints, but i have not found one yet. Maybe you have a suggestion?
> to be undeservedly condescending ... is not lovely.
It seems like you have just diagnosed someone's behavior without them asking for a diagnosis and your diagnosis is that they are being condescending. See the problem there?
And this followed what some might call undeserved condescension: "Pulling out my hair in frustration from trying to deal with Perl written by other people saved me all manner of haircut money in the 90s.".
If you think I'm being undeservedly condescending, and this isn't lovely, perhaps we can find another way to talk about Perl 6?
You can torture my words rhetorically to score emotional points, but I don't know what you think you prove by it.
If you find my jocular expression of my very real experiences with Perl to be condescension, I'm going to have to let you know that I don't believe Perl to be all that worried about it, incapable as it is of having an emotional state.
It's hard to learn, but not necessarily hard to understand. That hard learning experience theoretically pays dividends in productivity later as you and more succinctly and quickly express your intent.
It's not hard to learn, as evidenced by all the people writing functioning perl after reading only a few scripts. It just takes a long time to learn entirely. ;)
Ah yes but it is mainly because many languages borrow C-style syntax so you can understand it without many brain gymnastics.
You are correct, however. I did try learning Japanese and was just as unsuccessful at that as with Perl; I did maintain an old Perl codebase at one point and learned enough to get by but I would never jump at the opportunity to do it again!
I still have that, but thankfully get to use clang instead which has more helpful messages (although you do need to look about 5 errors deep in the error tree to get to the nub of the problem).
Congrats to the perl community. We should keep an open mind and learn from what they have accomplished.
If perl 6 turns out to be useful for the larger software engineering community (and is more widely adopted), this is wonderful. If not, then we still have another interesting language in the great river of interesting tech things.
Either way, the perl community will continue to do what it does best!
> Perl 6 has an asynchronous looping construct called whenever ... runs whenever a value arrives ... can live in a ... react block (works like entering an event loop)
my $code = supply {
whenever IO::Notification.watch-path($src-dir) {
emit .path if .path ~~ /<.pm .p6> $/;
}
}
So now, whenever something in $src-dir changes and its path ends with '.pm' or '.p6' that path will be emitted -- which in this case means it'll be pushed to any construct pulling from $code. Such as:
This is probably the most interesting link in this entire thread.
The "react" keyword is just a channel subscription, and inside it has a pattern matcher. Channels are first-class citizens, and you're encouraged to chain channels rather than falling into callback hell. It's like Go and Ruby had a child.
If anything piqued my interest in Perl 6, it was this.
One of my favorite new features is phasers[1] (loop flow control shortcuts), and as a subcomponent of that, how CATCH[2] is implemented as a phaser so it's within the block that had the error still has access to the variables in the same scope.
Correct. $ is an anonymous scalar (which autovivifies to 0 and increments in $++). There's also anonymous array @ and anon hash %. The hash form you can see in action here, in the one-liner mad-libs code: http://rosettacode.org/wiki/Mad_Libs#Perl_6
Perl 6 appears to be the SNOBOL of our times, with grammars being a first-class lex, plenty of functional idioms, APL influences and a reasonable object system.
Given how much of contemporary programming is munging, I can see it really picking up steam.
Given how long it took to replace Perl 6, and the fact that I (and most others I know) have moved onto other languages, I can't decide if I'm more (a) surprised, (b) impressed, or (c) indifferent.
Kudos to Larry for sticking with it, and for (I'm sure) introducing interesting ideas into the world of programming languages. That said, I have to wonder how many people will really use Perl 6 in their day-to-day work, and how many will look at it as a curiosity.
For me, I'm afraid that Python and Ruby have replaced Perl, despite more than 10 years in which Perl was my go-to language. Maybe I'll return to it, but I sorta doubt it.
I don't know, there's something to be said for a language that isn't a moving target. You learn it really well inside and out and your effort isn't wasted as it is thrown away for some hot new fad language in a couple of years or find that everything you learned is now deprecated because the authors decided that functional programming is the bees knees.
Perl 6 has slides, IRC, a skim-through (learnxinyminutes), reference docs, examples, but alas no solid tutorial. This, IMO, will be a major problem if it persists until Christmas.
I'm really surprised this site is the source y'all chose to upvote. Not only was the second-newest article published in 2012, they also have an assortment of other questionable content[0][1]. Advertising from rotten.com and a category named "Jonny Jihad" are also professional touches.
I mean, whatever floats your boat, but HN, is this really one of your go-to trusted news sources?
I was delighted to see pigdog.org appear on the front page of HN; I thought it had died years ago (and I guess it mostly did). The Pigdog Journal was a Big Deal for a certain clique of nerds/technologists in the late 90s/early 00s. (You know, when Perl was also a Big Deal.) The web was a smaller, zanier place then; for those that remember that web, pigdog.org brings a wave of nostalgia.
If you doubt the legitimacy of the post, I can confirm there was an event[0]. I was also there, and the blog post syncs up to what I remember from the event. I am surprised there isn't some official post event write up from the event organizers, though.
Here are the official words from Larry. There will be 2 beta releases and the major one in December.
Larry goes by the handle TimToady
http://imgur.com/1Vrpl2G
So is this a real thing? I've never seen this pigdog website before, it's second newest article was published in 2012, and there's no mention of this on the perl 6 home page or in the perl 6 announcements mailing list..
At FOSDEM earlier this year, Larry gave the presentation they describe, and said that they were expecting a beta release at Christmas this year. So the general concept is legit, regardless of the site.
I don't see how that makes this look any more legitimate. The FOSDEM website says they had over 5000 people attending, so it's not like Larry's talk was a big secret. And Perl 6 has been right around the corner forever, so a fake "Perl 6 is released" page could seem timely and legit in concept at almost any time in the last 10 years.
Even if it's true, if they want anybody to pay attention they should announce it on perl6.org or at least a more professional looking page. If I were at work and opened a page with rotten.com banner ads, and "software jihad" all over the place, I'd close it immediately and hope nobody saw it.
Not being privy to the talk, my assumption was that the final shipping feature list was solidified, and that's what was being announced. It's still due at Christmas, and that was already known. I think the article's meaning was somewhat ambiguous with the title, and HN just ran with it. Nothing has been released (but apparently there's two beta's officially planned now, the first of which is in a week or so).
> if they want anybody to pay attention they should announce it on perl6.org or at least a more professional looking page.
Right. I think that's the intent -- this christmas.
But Larry can't stop someone posting an article that incorrectly suggests that 6.0.0 has been launched and then someone else posting an HN article/thread that you and lots of others (me too) decide to participate in.
From what little I've played around with the language in the past, I really like it, and I'm glad the community can put the "still in development" talking point behind it.
Also, one of my favorite things about Perl 6 is that the Rakudo interpreter prints some of the nicest error messages I've ever seen. It actually offers suggested solutions, and it points out Perl 5->6 migration gotchas.
Perl was the first programming language I ever used, and i think 6 was being worked on even then. I've moved on to ruby as my goto, but my (limited) memories of perl are fond, and I'm happy to see its still moving forward.
Method modification is trivially done through "alias" and then just redefining the method in Ruby, if you re-open the same class. If you subclass, then "super" is sufficient. I'm curious what you actually mean here.
As for writing your own constructors, you only need to do so if you actually need to initialize something, and since instance variables can be used without having initialized them in a constructor (they'll just default to nil), I'm curious what you mean here too.
> Method modification is trivially done through "alias" and then just redefining the method in Ruby
I don't know how to convert this into ruby then without needing to manually gensym a bunch of names:
use Class::Method::Modifiers;
sub foo { 2 }
before foo => sub { warn "before foo 1" };
around foo => sub {
my ($orig, $self) = (shift, shift);
warn "around foo";
(1, $orig->$self(@_), 3);
};
before foo => sub { warn "before foo 2" };
> As for writing your own constructors, you only need to do so if you actually need to initialize something
Which is required if you're going to use value objects as much as possible rather than spraying mutable state everywhere.
You can do this. I tried to draw up a quick gist, but I am late, and I've been writing too much Rust...
The basic idea is this:
module Mst
def self.included(base)
# define a method on base using define_method named :before, which takes an
# argument and a block
# in that method, you grab the method with that name, using .method()
# you then define a new method, named method, which calls the block and
# then calls the original method
end
end
class Foo
include Mst
def test
puts "test"
end
before :test do
puts "before"
end
end
Module named after you. You can see how the logic only changes a bit for after and around. You could then wrap this up as a library, and all you'd need to do is the include.
I hope, however, that you can understand from the POV of somebody who keeps being driven off ruby by ruby being too much work, that "you could make it less work by first porting all the perl5 libraries that make perl5 OO more pleasant" isn't really a convincing solution :)
Yeah, I was responding to a post that claimed it was trivial; that's cute but not trivial - although it does demonstrate that using 'alias' to rename isn't necessary, which is nice to know.
I can absolutely see how I'd turn this into a full Class::Method::Modifiers re-implementation, so I'll totally stipulate to 'trivial if' :D
Wut? I just complimented the code you posted, and changed my mind from "the unconstructive guy upthread said trivial, which it isn't, but steve's been kind enough to give me enough information to see it's trivial if I write a port of CMM, and said port is basically identical rather than requiring the crappy alias approach".
I've genuinely no idea why you think I was being condescending.
I don't know where steveklabnik hails from, but in the US "cute" is sometimes meant with a condescending overtone. I seem to recall you are from the UK (Scotland?) from the last YAPC I was at, so I suspect this is a dialect difference causing a misunderstanding.
Hey! Just woke up to this. Sorry, it seems as someone else mentioned,
That's cute, but $FOO.
is seen as really condescending here. It's literally diminutive, suggesting that something might be small and pretty, but not worth adult consideration for Real Stuff.
Anyway, if that's not how you meant it, I completely understand. Text is hard. No harm, no foul. Sorry for misunderstanding.
Ok, so, on the one hand, I wasn't trying to be condescending, which is why I didn't say 'but' after 'cute' - the 'cute' was a genuine compliment.
On the other hand, the thread started off with "I've already got stuff in perl that does X and it looks like I'd have to write it myself in ruby", then somebody replied with "this already works in ruby, just use alias" then when I provided an example that wouldn't you showed me how to write a library to support said example in ruby.
So I now know much better 'how to write it myself in ruby', and I am genuinely grateful for that, but it still wasn't an answer to the original question so 'cute' seemed like the appropriate compliment.
The actual answer I was looking for seems to be "people who're bad at ruby will always suggest alias, prepend will handle some cases, and then you can write not that much code if you want the other cases, but there's no perl5+Moo quality experience to be had without implementing at least part of it yourself".
Which is totally fine by me, I just need to talk somebody better than me at ruby into implementing it and then try and convince everybody to upgrade :D
(also, if you have a suggestion for a word other than cute that would express "really pretty even though it doesn't answer the question" while seeming positive rather than negative about this fact I'm all ears)
mst might speak for himself at another time, but i have a personal reason to post, so i will say this:
Please do not take this conversation as an affront and throw away what has so far come of it. It has shown you, and Ruby at large, an API that has been proven to be good and useful, and the Ruby community has come up with a way to implement it in a generalized way. I hope to someday be able to learn Ruby and use its OO with similar ease and pleasure as i can use the OO system in Perl 5. So please, do not throw this away. It is a valuable chance to do the same thing Perl has done so many times: Recognize something useful and make it your own.
Steve and I had a previous similar conversation; this one got further subject wise, but the original was also a fair few posts deep and we didn't accidentally piss each other off that time.
Pretty sure we'll manage to resolve the confusion shortly.
"before", "after", and "around" method modifiers are pretty common in Ruby Aspect-Oriented Programming libraries (AOP has pretty much fallen out of favor for Ruby, but I'm pretty sure at least some of these are still maintained.)
Except that package doesn't provide before/after/around.
What I really want is CLOS. But the closest in perl/python/ruby/javascript is Moose/Moo.
There's also, btw, a moosex gem where some rubyists are trying to port the perl stuff - but Moose/Moo are pervasive in modern OO perl whereas most existing ruby code is done the ugly, boilerplate-y way.
It was not my first language but the memories are fond. It just sat so well on my head by making things you thought of possible with little resistance. Impedance mismatch was minimized. Hard to explain. Became a master text wrangling language by making regex a first class citizen.
My sense, playing with Perl 6, is that it could become a "pro tool" -- very deep and powerful. It needs to mature some (though it is very solid already) and to grow its ecosystem (though it can run much of CPAN via Inline::Perl5).
A couple of other things that haven't been much highlighted:
- Perl 6 right now runs very well on two back ends: a custom VM and the JVM. It is spinning up a Javascript back end, I think primarily for NodeJS.
- Concrete representations are carefully separated from core semantics, so Perl 6 currently supports native values from C, Perl 5, Python, etc. It should be able to support native arrays as required for high performance scientific computing etc.
They switched to MoarVM, which was a simplier and much faster rebooted variant of Parrot to get a timely Perl6 release.
But it is still open to use any VM as backend.
Currently there are two in rakudo, in parrot can be re-added trivially, e.g. to support other architectures and a better threading model
Perl 6 basically hoovered every good programming concept they could think of (and some that ended up being not so good, which have hopefully been shaken out over the last decade). If you want a small language, this is not it. If you want an amazingly powerful language that just allows you to do what you want with a minimum of fuss, pull up a seat.
Perl 5 has a Tidy'ing tool[0], as well as a Lint[1] tool. Both are based on rules created from (originally) Best Practices [2]. These rules of course can be modified to taste, so you can set your own rules/filters before checking in your changes to a repo (or, whatever)
Perltidy predates PBP by a long time. Perltidy is a bit of a huge mess, and it has its own parsing code and is nearly impossible to hack on. We really need a PPI-based re-implementation.
There was a very interesting submission to HN on why code formatting utilities aren't easy things to write, [0] called, The Hardest Program I've Ever Written [1]
The code of Perl Tidy at least looks pretty good! [2]. Perhaps there's a reason why PPI isn't used, that I'm not famliar with, other than - as you say, it predates it. Perl::Critic uses PPI, yes?
For the longest time Perl was considered unparsable, primarily due to the two features of function parens being optional, and the argument-slurpiness of function calls being unknowable without introspecting the function reference that ends up being the final one, at runtime. In the most famous example this can lead to a / after a function call being considered either the division operator or the start of a regex; with both interpretations resulting in valid Perl code. It took a while for anyone to come up with a schema in which Perl could be parsed while also being round-trippable. It took PPI a while to get there and be stable, and meanwhile P::T had already become stable itself.
No, but Perl 5 has Perl::Critic[1], which is a configurable opinionated code and style analyzer. It defaults to using the Perl Best Practices book by Damian Conway, with configurable levels of exactness. You can modify the rules to suit your particular needs/team.
I imagine something on this front will materialize for Perl 6 sooner than later.
I read it that way at first, and was going to comment on it, then I figured the point was smart match being able to distinguish, not being able to do your own test.
Yes, I'm aware, but when using smart matching (that is, the given/when pair which has had it's fair share of trouble, and is currently experimental after having not been), you sometimes want to be able to distinguish between those types of tests when doing a smart match[1].
I believe the article was referencing this, and so while yes, anyone who knows how to use Perl will use the appropriate operator for the appropriate type of type operation, there are reasons to still want to distinguish what type of match is done by the smart match operator, '~~'.
""Any infix operator can be replaced by itself in square brackets..." Later someone asked, "In a world of user-defined operators everywhere, how do you define precedence?" And Larry pulled out is tighter() and is looser(), noting that Perl 6 even has customizable precedence levels. "You can add an infinite number...""
It's been said that most of programming is about managing complexity. I'm unhappy with Perl in general because it makes it really easy to hide complexity. Perl 6 looks like it makes it even worse.
Yes, it looks like an amazingly powerful and sophisticated language, and an amazing and respectable accomplishment, but my gut feeling is I'll hate seeing some in production...
A nice feature is that imports honor scope, so you can use a module and import functions or operators within a scope and not worry about it causing problems elsewhere.
Perl was the first high-level language I learned and I've used it many times during interviews. I still think I can solve most non language-specific interview questions extremely efficiently with Perl. Go Perl!
Long ago, Perl as a coding Leatherman, along with C/C++/Java.
Python took Perl's place on my belt. I'm using Python2, because all the reasons everyone else gives, and because it's Python2 at work. I've been wondering when I'd finally decide/be able to move to Python3.
And now I'm rubbing that faint Leatherman imprint on my belt, and wondering if I'll just skip Python3 for Perl6.
I would never want to use Perl at my day job, but I also wouldn't want to live in a programming universe where Perl didn't exist. Perl is a place where the pure joy of coding thrives.
I always found it obtuse and overly terse to the point of non-maintainability or readability, far worse than even C++. But that could be due to my lack of understanding, or being used to C-style languages and syntax.
Here's something that's normally not too fun to deal with in Python and Ruby: asynchronous operations. Perl 6 has promises, C#-style async/await, Go-style channels, and Reactive Extensions-style Supplies built in as first-class ways to deal with asynchrony, concurrency, and parallelism. It can also take advantage of as many threads as you'll give it. Since I deal with web services a lot, this is a huge boon for me.
But I don't really want to give a laundry list of features, because that alone is not a compelling enough reason to pick a language (P6 obviously needs to develop an ecosystem). As someone who appreciates both OO and FP, both static and dynamic typing, P6 really hits a sweet spot. I encourage you to look at Perl 6 as a new language with the feel of Perl but which solves many modern problems.
I actually like Clojure quite a bit and used Racket (with How to Design Programs) when I first began my foray into becoming a programmer. Here are a few reasons why I'm more excited about Perl 6 now than I am about Clojure (although I still think Clojure is great):
1) Async. While I was initially enamored of core.async, I've found promise combinators and supplies to be a more useful and higher level abstraction for the type of work I do. I also had huge problems debugging generated core.async code, but maybe that's changed over time. I suppose I could use RxJava with Clojure for supplies, but I have a feeling that it's not really seen as being in the same style. This is also why I'm not as big of a fan of Go as I once was, too.
2) As peatmoss mentioned, startup time. I work at a web hosting company and as you can imagine we write lots of small scripts. Clojure really can't compete in this area.
3) Gradual typing. Perl 6 supports gradual typing, with functions being checked at compile time and methods being checked at run time (the latter was a decision to allow both a powerful metaobject protocol and also easy interop with other languages using things like Inline::Python). I know that Clojure has core.typed, but that's not really what I'm looking for, although I do think it's an excellent project.
A final quality of life difference: Perl 6 has invested a lot of effort into awesome error messages, including things like suggesting a close lexical variable if you mistyped one. While every Clojurist learns to deal with the stack trace o' doom, there's something good to be said about this. :)
As a fan / dilettante of Clojure, I'd say no. The JVM is many nice things, some nasty things, but definitely not lightweight in terms of things like startup speed that I'd expect of Perl 6.
"The JVM is many nice things, some nasty things, but definitely not lightweight in terms of things like startup speed"
The jvm startup speed is actually surprisingly good these days. We were experimenting with writing several commandline tools with Scala, and didn't think they would work because of this "well-known" issue. Turns out it was fast enough even to enable letting Scala handle things like the code completion and still have it feel very snappy.
I'd agree that the JVM itself isn't so bad in terms of startup time. However, the last time I compared Clojure and Scala, Clojure took significantly longer to start up (even though what I was doing in Clojure was nothing compared to all the libraries I was pulling in with Scala!)
Edit: I should add that there's a Perl 6 JVM backend. While it's not as up-to-date as the default MoarVM, it could also be ready "for Christmas" :)
"too late" for what? Perl 6 is a super modern programming language with all the flexibility and fun of Perl 5. If you are looking for a multi-paradigm scripting language with an hybrid typing system then it's very relevant, just go and read its specs: I think you will find tons of interesting features that will make you want to use it some day.
There are quite a few Perl shops in LA writing new code and more than a few maintaining apps that have been around for a while. Lacking the sex appeal of Node and Go (or whatever the next hotness will be) doesn't mean something isn't relevant.
Why build something in Perl? The same reasons you'd write something in Python, Ruby, C#, Java, etc:
- Mature tooling
- Excellent library support
- Code samples written for relevant projects by vendors for their libraries [0]
- Experts available
Given the fact that there are a lot of good options, it's probably best to factor in, "Do I like it?" and/or "Would someone pay me for it?". For all the above the answer is yes.
Additionally, Perl 6 is more or less a new language. If it scratches enough developer's itches, it'll likely take off on its own. It's mostly getting flack due to taking forever and Perl 5's perceived lack of sex appeal. I think if you frame your question with languages like Lua, Haskel, Schema, etc you'll find a good set of answers from users in each community.
The typing and grammar mechanism aren't common, it may influence other languages. Also, Perl managed to survive even without mainstream relevance so the community will probably keep enjoying it.
This was something that was tangentially addressed yesterday - the idea was that Perl 6 isn't meant to be a flavor of the week language, but something that could conceivably last for decades.
One interesting thing Larry mentioned related to that long term view was that due to Perl 6 being a multi paradigm language, it could potentially become the defacto teaching language in academia, because it fulfills the roles of OO, functional, procedural, and logic programming in a single package. Eventually, that new generation of Perl 6 learners would go on to form startups and create bigger and better things. I'm not sure if this will come to fruition, but I think it's certainly worth keeping an eye on.
>What would you build in Perl today that you wouldn't build in another language instead?
By that logic we should just stick to assembler or C. You can built anything in C, if you really wanted to.
Perl or any other language, remains relevant as long as there are system depending on it and developers who use it. I view Perl a little like Cobol, you and I might not see it every day, but for a rather large, and perhaps a little obscure, subset of people it's still the tool they use every day.
If you have 10 Perl developers employed already, it might be a wasted of effort to retrain to Python, Node, C# or what ever, and just do you next project in Perl 6.
The biggest threat to Perl 6 might be Perl 5 though.
There is nothing stopping a resurgence of Perl, if it's an order of magnitude better than competitors. If the combination of modern Perl techniques and the language make it a good enough fit for a new interesting framework or tool, then we might all be writing Perl again in a few years.
Just needs to get more jobs posted for it first. Going back to the original comment:
>What would you build in Perl today that you wouldn't build in another language instead?
You could turn it around too: what could you build in another language that you couldn't build in Perl? Well, nothing really. It's a matter of taste, and I think what continues to set Perl apart is its syntax, which could be really good and readable when you don't try to do code golf.
I didn't say could or couldn't, we're talking about turing equivalent languages of course so that question is meaningless, I said would. You can code anything you want in native assembly, or in brainfuck even. But why would you? If you have some impressionable new college grad just getting into the industry how would you convince them to use Perl to build things instead of any other option?
I find that anything involving a lot of regular expressions is easier to write in Perl than in Python. Perl and JavaScript are the only two mainstream languages I know of where regular expressions are first-class citizens (compared to Python, where you need to do `re.compile(r'...')` and store that somewhere).
Regexes are really easy in Ruby as well (which cribbed a lot from Perl). There's an OO syntax, but also support for the Perl built-ins so this works fine in Ruby:
print "match" if something =~ /thing/i
Captures with $1 etc. are there as are named captures using the same syntax in the regex.
The regex sublanguages and engines in Ruby and Python are knockoffs of the equivalents in earlier Perls.
But this thread really ought to be focused on Perl 6.
In Perl 6 one can write:
print "match" if something ~~ /<thing>/
It looks superficially similar. But it's a scalable parsing feature, not a mere regex. That line of code will work when `something` is ten thousand lines of complex Perl 6 code and `thing` is the top rule in a grammar for parsing Perl 6 code.
I was showing Ruby code to show how its regex handling is much like Perl 5 - Perl 5 would use a sigil on 'something'. Ruby is less like Perl 6 regex-wise due to the smart match (among many other things).
> Ruby is less like Perl 6 regex-wise due to the smart match (among many other things).
In both Perl 5 and Perl 6, smart match (`~~`) with a regex on the right hand side is just an alternate spelling (Perl 5) or correct spelling (Perl 6) for `=~`. It's a tiny, trivial difference.
But a Perl 6 "regex" can be an arbitrary full blown parser or compiler. And it assumes character=grapheme. In these two regards, as in several others, Perl 6 is quite unlike Perl 5 and other langs that adopted Perl 5 regexes and/or that adopted Unicode codepoints (or worse) rather than graphemes as their fundamental "character" unit.
You don't have to compile and store regexes in python. re.match(pattern, string) can be used right away and it will internally cache the compiled version of your most recently used patterns.
I'm also curious in which type of application regex is so important that it will be a deciding factor of language choice. I mean, if you have a regex in one out of 100 files, does it really matter if you have to write 2 lines instead of one.
Too late for what? There is a difference between relevant and trendy. Perl, in many cases, is extremely modern. The Unicode support of Perl 5 is nothing short of state-of-the-art. CPAN is still an amazing resource. The web and OO frameworks for Perl are fresh as ever.
I mean, yeah. We're all going to be using Node.js in another year or two. But that's because our industry is bloody ridiculous. Not because Perl is ill-equipped for the "modern" age (People raving about MVC, the actor model, and promises in 2015 is tiring)
According to http://rakudo.org/how-to-get-rakudo/ , Perl 6 is just a specification. What changes do you see in the specification between now and Christmas?
Note that the 'Synopsis' has been demoted to be closer to a set of design docs than a formal specification - it's more about the test suite these days (cf first two paragraphs of http://design.perl6.org/).
Jnthn made a list of things that are supposed to be fixed by Christmas [1] as well as a list of things that probably won't make it into the 6.0 release [2].
I'm pretty excited about the release of perl6. perl6 has a number of interesting use cases and features. I'll be happy to watch it evolve as more people pick it up and find new/interesting uses.
"What exactly is the “Great List Refactor” (GLR)? For several years Rakudo developers and users have identified a number of problems with the existing implementation of list types — most notably performance. But we’ve also observed the need for user-facing changes in the design, especially in generating and flattening lists. So the term GLR now encompasses all of the list-related changes that seem to want to be made."
I may not write a bunch of Perl 6, but the planet is better for having Perl 6. That says a lot about the person who guided Perl 6 to completion, he's a gem of a guy. Thank you Larry!
It's unnecessarily condescending, especially given that Ruby got `?` and `!` suffixes from Lisp, which far predates Ruby, and that Ruby itself is in many ways a descendent of Perl.
The goal of Ruby is to make programmers happy. I started out to make a programming language that would make me happy, and as a side effect it’s made many, many programmers happy. Especially Web developers. But Ruby hasn’t reached developers who work on embedded devices, mobile devices, controllers, things like that. I hope to make them happy too. -- Matz [1]
Larry Wall's comment recognizes Ruby culture and acknowledges that it is a good thing. Not surprising given that Perl 6, like Ruby is an everything-is-an-object language with a lineage from Smalltalk. Programmer productivity/happiness was one of its goals as well.
Well, Ruby also has quite a bit of lineage in Perl, so there's another layer to that as well. I think a lot of Ruby programmers that are unfamiliar with Perl would be surprised with how similar they are in some respects.
I really don't think Larry meant that to be condescending.
The "worst" I could imagine is that he was poking a little fun at Ruby programmers. I'm sure he was just trying to be funny, but sometimes it's easy to misinterpret what people mean when you don't actually hear them say it, but only read it in print.
I'd be very surprised if the comment was at all malicious.
If you have perl code to maintain and dependcies break, its not easy to use or at all intuitive. You run cpan, it tries to set itself up, 40 minutes later its trying to autoselect the same broken mirror. Is this going to go on forever?
Run again. Select repo, it kind of works.
Get 6 pages of build output and a broken install.
Its one of the first repos, a great idea, its just frustratingly obtuse.
> 40 minutes later its trying to autoselect the same broken mirror
Sounds like you're in a network with particularly misbehaved firewalls. The initial phase of the auto-setup is very fast, since it only checks file paths. The network part might be slow if some part of your network infrastructure messes with connections and cuts them without properly resetting, resulting in super long timeouts.
Not sure what you expect in such a situation.
> a broken install.
No you don't, unless it's an extremely old or shitty library you chose to dep on, since things build, run their tests, and only install when those pass. The 6 pages of output help you identify which tests failed and maybe why. Also, often test failures are simply because you have a system the author didn't write for, which hurts just as much with the other packaging systems.
Broken install = it didn't install. I had no idea why. I did get there after some hours of struggle . Part of the problem is the libraries on our system are everywhere.
Sorry I sounded cranky, truthfully I'm probbly just unfamiliar. I'm a developer not an admin, just want to install packages. We developers love the package systems and cpan pioneered a lot of it.
A great package manager goes a long was to helping a languages success.
I'm comparing to Gems, composer, npm, rpm which for what I've done with them work pretty flawlessly and easily.
cpanminus (cpanm) is an attempt to make a zero-configuration client
that automatically does the right thing for most users. It's also
designed to run well on systems with limited resources (e.g. a VPS).
It doesn't come with Perl, but it's easy to install.
It integrates easily with local::lib.
> I had no idea why. ... Sorry I sounded cranky, truthfully I'm probbly just unfamiliar.
Yes. CPAN does a lot to help the user and gives a lot of information, but all that information truly does contain 99% of what you need.
It progresses in phases (prep, make, test, install) just like most other make-based software (99% of the stuff installed on your linux boxes) and after each phase it will say "<phase> OK"/"<phase> NOT OK", so you only have to read for that, then scan upwards to see what errors you got from gcc or whatever. In other words, and i'm not trying to be mean, but: You only have to read what is on your screen.
As for "Gems, composer, npm, rpm", i know that the three non-npm ones don't run tests on install (npm probably doesn't either), so you might be conflating "flawless and easily" with "system incompatibilities are found at runtime, instead of install time". I.e. it's highly likely that what you like of them isn't that they've progressed beyond CPAN.pm, but that they've yet to catch up to it.
At a previous job perl was used everywhere. As a language, it's quite nice. CPAN is horrible, though. No staging/stable/whatever versioning, new modules requires updating versions of existing modules which frequently broke - it's just not something that's enterprise friendly.
I tried but failed to find a company that would support and curate a subset of CPAN modules properly. Does one exist now?
There are multiple tools to do this on your own, with CPAN::Mini and friends, or Carton.
I also don't know how long it's been since you last tried, but cpantesters and the other odds and ends of the ecosystem have helped tremendously in reducing published bugs. ( http://matrix.cpantesters.org/?dist=System-Command%201.115 )
Checkout Pinto, http://perlmaven.com/pinto-tutorial, which allows you to host your own CPAN mirror and have stacks. So you could have a "development" stack and a "production" stack, or a "perl-5.8" stack and a "perl-5.16" stack. Whenever you add or upgrade a module, it only affects one stack.
The ending of the last-released HL2 episode had a very “to be continued” feel to it, but more importantly, Valve has made statements about future releases moving away from “the episodic format” to “smaller releases” and possibly returning “to genuinely scaring the player,” but it all seems rather dead now. This section in Wikipedia has some relevant sources: https://en.wikipedia.org/wiki/Half-Life_(series)#cite_ref-37
Probably the funniest / saddest / most hopeful part of the whole saga is that at some point, a group of fans organized a sit-in at Valve HQ to plead for a commitment to HL3 :)
So, for someone who has never read or written Perl code, where should I start? Perl 5 or 6? I get that they're different languages, but I want to see what "Perl" is like.
I'm not sure you do get it, unless you are talking about the "feel" of using it, in which case use either. They aren't just different languages because there's some things that break backwards compatibility, they are vastly different in many ways.
If you want to know what current deployed Perl is like, look at Perl 5. If you want to look at what the "Perl" future is, look at both Perl 5 and Perl 6, since they'll both be around. If you want to see something new and different, look at Perl 6.
I was talking about the "feel", indeed. So for example, if someone wanted to experience what a Lisp is like, I could point them to Scheme.
I want to know what "Perl" is like, but the fact that Perl 5 and 6 share the same name is a tad confusing for a newcomer. Precisely because I have no idea what "standard" Perl is.
I guess Perl 5 it is, since it's already on my machine.
Then I recommend perlbrew[1] for Perl 5, and rakudobrew[2] for Perl 6 if you decide you want to take a look there as well. They will let you quickly build and install any particular version of Perl you like, and allow switching between versions if you have the need. The Version of Perl included in most distros is rather old as, Perl 5 sees regular releases with new features.
The one main hint I have for you (beyond reviewing the Modern Perl book, as my sibling comment recommends) is to understand context and what that means in Perl. Perl can look deceptively similar to C and other procedural languages, but there are some somewhat (still) radical ideas underneath that will leave you either scratching your head or grumbling in frustration if you don't understand context (list or scalar), and how it's relevant in almost everything Perl does.
Someone should implement a Duke Nukem Forever clone in Perl 6.
Pretty excited about Perl 6. Haven't used Perl in a long time but there seems to be quite a bit of cool stuff and I'm very excited to see what a language where Larry had more free reign will be like. Xmas reading/coding here we go (how fitting)
Oh my. I expect the next version of Perl to read my thoughts and to not require any source code from fallible mortals. The jury is still out whether this will produce more bugs than it abolishes. The answer is expected in time for the end of the universe.
In a perl article, you give a non-matching pattern?
Its just one of those little things we don't think of often, but a lot of folks buy these devices and its a weird form of censorship beyond what's normally intended.
quetion for the early adopters: if i develop an end-user app in perl6 on linux, how easy is it for me to deliver it to a non-technical windows and/or mac osx user?
Since Rakudo also targets the JVM, not just MoarVM (the dedicated VM), I imagine it's not terribly too much work to get to the point where the app, included modules, and Rakudo/Perl 6 itself can be bundled together for delivery.
oddly enough, a coworker and i were joking about how perl 6 would come out in the next 100 years on monday and just a few days later larry wall made us look foolish.
I haven't looked, but I really hope Perl 6 held on to the 50 different ways to do any one thing. Pulling out my hair in frustration from trying to deal with Perl written by other people saved me all manner of haircut money in the 90s.
I suspect if anything, there will actually be more ways to do it in Perl 6. It can be used entirely from an object-oriented point of view, or entirely from a functional programming point of view. This is construed to be a feature of the language.
Flexibility is Perl's greatest strength and weakness. Perl forces you into dealing with other people's thought processes as a consequence of allowing your own code to be expressive and better reflect your thought processes. If this is not a tradeoff you're willing to make, Perl is most likely not for you. But I find it to be educational to see the variety in well-written Perl code (i.e. not from from Matt's Script Archive).
I suspect a lot of people didn't take the time to actually learn Perl which is why there's so much "there's-more-than-one-way-to-do-it" Perl code in the wild.
For whatever reason, I went the PHP route and I can say from nearly 20 years experience that PHP has the same problem even if it doesn't have the same philosophical approaches as Perl. Too many people who never actually learned the language producing near unmaintainable code.
The worst part is that people who believe they learned Perl by doing, instead of reading the reference docs and structured introductory texts, believe themselves to know Perl and speak publicly in the belief that the knowledge gained that way represents universal fact.
If you have globals, nulls, gotos, or whatever dangerous (but sometimes useful) features (e.g. states); surprise surprise people will end up using them at one time or another.
Perl is not the first nor will it be the last (imperative) programming language helps people fail too easy.
> Double check me on this, but Perl 6 doesn't yet have a goto statement, nor does it have globals.
AFAIK, Perl 6 has a goto statement in the spec (one big change is that Perl 6 is a spec), it just isn't yet implemented in any of the implementations. But presumably the target is to have the whole spec implemented for the release this Christmas. (EDIT: Actually, no, goto won't be in "6.Christmas" [0])
For globals, its has global scope ("our") but variables with global scope are still namespaced based on where they are declared, so while they are globally visible, they lack some of the more problematic features associated with globals.
I guess I didn't make it clear enough but I was speaking in general terms and I wasn't just talking about Perl. i.e. I'm defending the people who weren't experienced enough not to realize that you shouldn't use a language's features just because they exist. Even when you have experience, people get tempted to just get things done regardless of how spaghetti the solution is
I love Perl [I have been to perl monger meetings and I had to look up how to 'unshift' in python today].
But Python3 is mostly just Python2 with a print function instead of a print keyword. It is occasionally non-trivial to port large existing code bases from Python2 to Python3, but it is practically always trivial for a Python2 programmer to write new code in Python3.
And stuff like map returning an iterator (instead of a list). Print being a function is the one everybody knows, but this one is the one that is more common for me. That and bytes/Unicode subtleties. Code rarely is much different in substance however.
> it is practically always trivial for a Python2 programmer to write new code in Python3.
Until you need to use some library that doesn't support python3. I think I've made the transition from python3 to python2 more than I have the other way around.
I've been writing forward compatible py2 code for years using the __future__ imports to ensure proper semantics are preserved. When all my external dependencies have py3 support it becomes a breeze to upgrade using 2to3 and the rare occasional manual fixup.
Not sure why this was downvoted. I'm currently still in Python2 and looking to upgrade to Python3. Having solid automated tests is vital for us to do it confidently.
But do you have tests for your tests? Assuming tests are written in Python2, gotta make sure they don't start testing the wrong things when you upgrade them...
The way I think of it, the code tests the tests. It's the the same way keys and locks verify each other.
Is there some sort of failure mode you're thinking of where I'd still see all the tests run but the test framework would give false success for something?
That argument is becoming a good way to tell who hasn't actually tried Python 3 lately, or is using out of date libraries.
More and more of the bigger libraries are ported already, and a lot of the others have been replaced by newer libraries that work with Python 3. If the library you're trying to use doesn't support Python 3, it's probably a good indication most people have moved on to something better...
Or until you trip over the API differences between str and bytes in Python 3 that do not exist in Python 2 (because str == bytes in Python 2). Chiefly, printf-style formatting...
>>> b"%u" % 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for %: 'bytes' and 'int'
Not quite. I recently ported a script from Perl (which I can barely read) to Python (I used to know 2 pretty well) and took the opportunity to see what the differences between 2 and 3 are.
There's a pretty big page of changes, rules for maintaining compatibility and suggestions and it pretty much killed all my enthusiasm.
I'm speaking from memory and might be wrong, but one annoying thing was that I couldn't detect the Python version and print an error message, instead the P2 interpreter would throw an error at runtime when encountering a P3 construct.
There are many nice P3 books and libraries, but 2 vs 3 is still a PITA.
Learning atomic parts of anything is very easy. Its using those atomic parts to build complex systems that is hard.
If there is a operator in Perl 6, which you don't have in Python- Your options are to rewrite those semantics in Python most of them pretty large, and they won't be easy to read either.
Ease of learning is a irrelevant metric. You can't use a needle to replace a saw, if you do you are only going to end up doing more work.
If you learn both by learning from a well-written book, then they are equally easy, though Perl, by its depth, might require a slightly bigger time investment.
He lost his house? That sucks. Was that related to his felony charges? Like many others here I feel quite an affinity to the Perl community, sad to hear about that.
Larry Wall Unveils Perl 6 and no comments on hacker news an hour later.
That's the new headline that sums up Perl: an anachronistic programming language that may never recover from the perl 5->6 decade long 'freeze'. Also the language is crazy to write substantial programs in!
Yeah, the freeze killed momentum and left the community to wither. Python's transition was much better but is still not quite complete, and consumed a lot of time and effort.
Making a backwards-incompatible change to a programming language == making and launching a new language, with all its difficulties.
If Python's transition actually was much better, that says quite a bit about how awful the Perl transition is gonna be - since the Python 2->3 transition seems pretty widely acknowledged to be a disaster.
Which is exactly what Python should have done. Call Python3 a new language and not try to kill/degrade Python2 but have both live on... which they will anyway regardless.
Is it so crazy though? With frameworks like Mojolicious and Dancer, you can set up a whole website using syntax familiar to someone coming from Sinatra on Ruby or Express on NodeJS.
I've spent a year now using Perl exclusively at my job, and I love it. It's incredibly powerful, expressive, concise, and well-documented. It's a lot like js where the language has some cruft but as long as you're not working with any cowboys you can build some really elegant software.
Perl is awesome for writing big programs in. One of the things that people find frustrating about Perl is its expressiveness -- that is, there are many different ways of doing the same thing. The result is sometimes that you get 100 different people doing things 100 different ways.
This is not so much a problem with the language as it is with programmers not learning to agree on a set of idioms that they will use for a project. They are not reading each others code and having discussions about what they want to see.
Languages that impose "the one true way" cut down on the apparent problems, but you are still going to have massive issues down the road if you build large projects because nobody is paying attention to what the other people are doing. Especially on large projects, it is vital that people read and comment usefully about design issues. In such large projects, removing the choice of idioms available though language design is a bit like deciding not to carry a canary down the mine with you because it keeps getting killed by poisonous gas.
The expressiveness of Perl allows you to choose the idioms that will work best for your team/project. It is true that it requires more discipline and communication, but these are the things that are necessary for success on a big project anyway.
I haven't written any Perl code for years now, but I have always been fond of it. I find that I can write better code in Perl than in many of the more restrictive languages that I've used.
Then you might be pleasantly surprised to learn that Perl 6 has a type system and compile time errors functions (but methods are runtime errors - on purpose).
As for missing hash keys... It sounds like you are using a hash when you really want an object. There are cases where that's preferable, but part of that trade-off is that you need to make sure the data is as you expect it. Perl 6 supports tightly packed (C struct equivalent) objects if you choose.
"I wouldn't write anything big in <insert language>" is pretty much always a true statement. What changes it is the framework.
I can write a web application in some homebrew <insert language> and it can grow to 40 developers, 1000 db tables and thousands of files. But it would be terrible to work on (I know I've seen it). Or i can write the same thing with a framework, and have it much more manageable.
Realistically, when was the last time you say down and wrote a big application in vanilla <insert language>?
It does need to find an audience. People using Perl 5.x are probably working in conservative companies that stuck with what worked. Perl 6 will need 2-3 years to bake. Python 3.x is just gaining some tractions 7 years after its release.
Perl 6 needs to find a problem that it can solve well. Perhaps a great web framework?
The companies I know using Perl are generally not so conservative - many of them also have Go code bases, heavy focus on DevOps, and so on. They tend to keep using Perl because they have developers who love programming in Perl...
He admits freely that he is ignorant about Perl, so i am unclear why you would bother to subject anyone else to such childish insults borne from nothing but fear and hate of the unknown.
I'm not sure what do you mean? I didn't write this rant. I find it amusing because it has some food for thought – for instance side note about rewarding idiotic behaviour.
AFAIK Erik Naggum used Perl for a fair amount of time so I wouldn't call it a "fear and hate of the unknown" and it is about Perl hence also on topic.
The raw and naked idea is not entirely incorrect. Literally everything else in the sentences making up that section is.
> Erik Naggum used Perl for a fair amount of time
> Did you even bother reading it?
Did you? I quote from the screed:
I once studied perl enough to read perl code and spot bugs in other
people's programs [...], but I don't write in it and I don't ever
plan to use it for anything
I don't know about you, but i find that unambiguous.
At work, I have been using Perl 5 increasingly often over the past two years, mainly because handling unicode in Python 2 is not a lot of fun (and I still haven't come around to learning Python 3), and I have rediscovered why I used to like it so much.
So far I have not looked into Perl 6 seriously, because I did not see the point to do so before it was finished. Guess I know now what I'll be doing this Christmas. :)
Also, you gotta love Larry for quotes like this one: "This is why we say all languages are religious dialects of Perl 6..."