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.
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...
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.
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..."
"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),"
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!
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.
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.
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.
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.
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?
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.
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" :)
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. :)
"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.
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.
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)
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.
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.
>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.
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.
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.
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.
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.
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.
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
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.
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)
"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.)
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.
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.
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!
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!
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 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.
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 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 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 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, '~~'.
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.
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.
> 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?
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'
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...
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.
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.
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.
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.
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.
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.
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.
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.
> 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).
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.
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!
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.
> 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.
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?
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. ;)
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).
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):
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.
335 comments
[ 5.0 ms ] story [ 289 ms ] threadThat'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!
Making a backwards-incompatible change to a programming language == making and launching a new language, with all its difficulties.
I would not want to write anything big in Perl 5. But for small-ish scripts (say, less than a thousand lines) it is pretty hard to beat.
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.
This isn't even remotely true. No static types, no thank you. Runtime errors due to misspelled methods? Missing hash keys? Hilarious.
Boy, I hope this scalar isn't undefined!
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 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>?
Perl 6 needs to find a problem that it can solve well. Perhaps a great web framework?
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..."
I'm not using it everyday yet either, but it's not a whole new language. More like just a few cleanups to sensitive portions of the API.
Doesn't look small and I already saw several things I was using that have changed behaviour. Someday I might even learn how to use them. :)
Why?
I don't know Perl, but I saw the presentation and was blown away. Installed it today, and definitely will try building something with it soon.
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.
This is a serious problem and will I suspect one day be understood to be the biggest long-term mistake made when designing Python 3.
I wrote a comment about this a few months back at https://news.ycombinator.com/item?id=9791211 (see second half of the initial comment and then the followups).
Even in Perl's supposedly superior support has issues. See how deep the rabbit hole goes by reading the first response to the question here:
https://stackoverflow.com/questions/6162484/why-does-modern-...
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 post to linked you contained a piece of boiler-plate code which accounts for said cases.
> Have you considered how your formatting is going to look when people intersperse Right to Left words in your output for example?
There are modules to handle this. It of course means that you have to stop using non-Unicode-aware functions like `sprintf`.
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.
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.
I used to be a big fan of Perl but it seems to have fallen behind the times, I doubt Perl 6 is enough to catch up.
ps: I found this talk pretty convincing about pragmatism https://www.youtube.com/watch?v=lpu-3UF_b48
also: https://www.youtube.com/watch?v=JpqnNCx7wVY
>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.
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.
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.
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" :)
[1]: http://blog.ndk.io/2014/02/11/jvm-slow-startup.html
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. :)
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.
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)
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.
[0] https://www.elastic.co/guide/en/elasticsearch/guide/current/...
TicketMaster used to have a Perl codebase but I think the murmurings I've heard point to them having switched everything to Java.
print "match" if something =~ /thing/i
Captures with $1 etc. are there as are named captures using the same syntax in the regex.
But this thread really ought to be focused on Perl 6.
In Perl 6 one can write:
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.Perl 6 is not Perl 5.
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.
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.
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.
(I'm randomly scanning http://faq.perl6.org)
One thing Go does well is provide the gofmt tool. There is only one way to format code properly.
Does Perl 6 have something like this?
I imagine something on this front will materialize for Perl 6 sooner than later.
1: https://metacpan.org/pod/Perl::Critic
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)
[0] https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tid...
[1] https://metacpan.org/pod/Perl::Critic
[2] http://shop.oreilly.com/product/9780596001735.do
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?
[0] https://news.ycombinator.com/item?id=10195091
[1] http://journal.stuffwithstuff.com/2015/09/08/the-hardest-pro...
[2] https://metacpan.org/source/SHANCOCK/Perl-Tidy-20150815/lib/...
As the current de-facto maintainer of PPI, the answer is rather simple:
P::T predates PPI by almost two years: https://metacpan.org/source/SHANCOCK/Perl-Tidy-20021130/CHAN... https://metacpan.org/source/ADAMK/PPI-0.1/Changes
and:
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.
Basically "No method modifiers and I have to write my own constructors? Really?" always drives me away within a few hours.
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.
I don't know how to convert this into ruby then without needing to manually gensym a bunch of names:
> As for writing your own constructors, you only need to do so if you actually need to initialize somethingWhich is required if you're going to use value objects as much as possible rather than spraying mutable state everywhere.
Sounds like you want something like: https://github.com/nicknovitski/modifiers
> Which is required if you're going to use value objects as much as possible rather than spraying mutable state everywhere.
Using Ruby's Struct class for this often avoids needing explicit constructors.
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.
The basic idea is this:
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.http://api.rubyonrails.org/classes/ActiveSupport/Callbacks/F... has an example, I think.
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 :)
Sure, I was just addressing the "I don't know how to do that." Rails offer this for models in certain circumstances, for example.
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
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.
Pretty sure we'll manage to resolve the confusion shortly.
I've genuinely no idea why you think I was being condescending.
This may be the first time (yeah, English, but do wear a kilt a fair bit) I've ever run into a problem with an American overdetecting sarcasm.
Ruby eventually added `prepend`, which I demonstrated upthread, and is a genuinely generic, in-language solution to the problem you're talking about.
Anyway, if that's not how you meant it, I completely understand. Text is hard. No harm, no foul. Sorry for misunderstanding.
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)
I sat on it for another evening, but I'm not sure of the best word for you, to be honest.
https://gist.github.com/wycats/0a354a96d00d47fa4e04
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.
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, never stop being you
> 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)
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: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.
1: http://design.perl6.org/S04.html#Phasers
2: http://design.perl6.org/S04.html#Exception_handlers
Perl is for poetry. For seeing the impossible and going back.
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.
Perl is not the first nor will it be the last (imperative) programming language helps people fail too easy.
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.
[0] https://gist.github.com/jnthn/040f4502899d39b2cbb4
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).
Um, this has been there for decades:
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, '~~'.
1: http://perldoc.perl.org/perlop.html#Smartmatch-Operator
Given how much of contemporary programming is munging, I can see it really picking up steam.
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.
I hope Perl 6 will get its own camel book!
I imagine its relevance to the Perl 6 that was announced today is next to nil.
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.
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?
If I remember right, % used to be deprecated in Python 3, but was undeprecated again by popular demand.
https://www.python.org/dev/peps/pep-0461/
json.loads(foo) blahblahException foo is bytes not text.
That said I still endorse py3 for new things
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...
http://web.archive.org/web/2011/http://merlyn.posterous.com/...
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.
> 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.
I adore the elegance of your wording.
: )
I commented because I didn't want the top comment to devolve into a Perl v. Python argument because I love both.
Looking at my comment now, it doesn't read as on topic.
Thank you for moderating. HN is my favorite place to read the news!
What ends up becoming off-topic on HN, btw, is as much about upvotes and replies as it is about the original comment.
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.
> get that they're different languages
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 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.
For web development, check out Mojolicious[2] or Dancer2[3]
And Task::Kensho[4] lists recommended modules for various tasks.
[1] http://modernperlbooks.com/books/modern_perl_2014/
[2] https://metacpan.org/release/Mojolicious
[3] https://metacpan.org/release/Dancer2
[4] https://metacpan.org/pod/Task::Kensho
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.
1: http://perlbrew.pl/
2: https://github.com/tadzik/rakudobrew
And then you have a well documented mental migration path to Perl 6 since it tends to be explained in terms of deltas to Perl 5.
Completely brilliant.
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.
[1]: http://siliconangle.com/blog/2011/08/31/qa-with-yukihiro-mat...
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.
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.
That has 46 terms before hitting the right pattern.
It also gives http://oeis.org/A188668 which has only four terms before hitting 1, -2, 4, ..., -232.
I guess one could try and tweak either to get a matching sequence, but I don't see a trivial way to do it that is mathematically 'nice'.
It is easier to start with http://oeis.org/search?q=0%2C0%2C1%2C_%2C_%2C_%2C_%2C_%2C_%2..., though.
It gives me http://oeis.org/A242067 "Number of triangular numbers between n^2 and n^3 (excluding the bounds)."
So, this sequence 'must' be "n plus number of triangular numbers between n^2 and n^3 (excluding the bounds)."
33, not 32, right? (20 through 232, inclusive)
TBH, I almost never use list comprehensions either, preferring regular functions, and the list monad or applicative.
But in direct answer to your question, no, but it's part of the answer[1].
1: https://en.wikipedia.org/wiki/List_comprehension#Perl_6
http://oeis.org/
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!
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?
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.
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?
I have the same feeling when gcc shit itself STL compiling errors.
http://learnxinyminutes.com/docs/perl6/ is a pretty good intro to Perl 6 if you just want to jump into things.
http://www.jnthn.net/papers/2015-spw-perl6-course.pdf is more slowly paced but provides greater detail.
Also, the people in #perl6 on Freenode are all awesome and are usually quick to help beginners unless they are in the middle of fixing some crazy bug.