How Perl 6 just sells itself (excerpt from IRC)
use.perl.org
use.perl.org
Perl has a marketing problem, and the first step towards fixing it is to accept that cool matters. There are very few young Perl programmers.
(If you believe that a group of people who've demonstrated that they can make and meet commitments over a long period of time will suddenly stop, how can you believe that any group of people will ever release any software that takes longer than a week or two to write?)
I think Perl 5 will take the good parts, and use them, and that Perl 6 is a pure R&D platform. Moose being a good example.
I would love to be wrong. But in the meanwhile I can't even work with other people my age in the language of choice because none of them know Perl.
It sucks.
We released Parrot 1.0 in March. We released Parrot 1.1 in April. We released Parrot 1.2 in May. We'll release Parrot 2.0 in January 2010 and Parrot 3.0 in January 2011.
Keep that in mind as you look at the daily Rakudo status reports. As of last week, Rakudo passed 68% of the current spectests. The passing test velocity has only increased this year.
I'm not as well informed as you, but I'm just really skeptical about a 10 year old project shipping 1.0. I'm pissed off that Perl has died in the meanwhile. Something went terribly wrong and the language was mis-managed.
It's not a finished platform (which is why we continue to produce new releases), but we have a documented and well-understood deprecation policy.
We'll add new features, but we believe that the current set of features in Parrot 1.0 is sufficient to build a workable language.
(As for the question of "Is Perl dead?", the rate of uploads to the CPAN certainly disagrees. That's a measurable data point. I won't address the question of Perl 5's release policy and backwards compatibility concerns here; I've discussed them at length elsewhere.)
As to CPAN uploads: Nobody I know under 30 in Atlanta knows Perl. I'm not exaggerating. Thats the important data point to me.
Don't you actually see where your logic slipped? Sure, CPAN having doubled their upload rates last year doesn't mean anything, but the few young acquaintances of your personal social circle really add up to your statistically proved statement.
Do I know young Perl devs, personally? No, but that is also true for every other language (I don't know any other programmer personally, odd no?). But what would that prove anyway? It's too small of a sample size to reach any conclusion.
And, as jrockway said, there are lots of young Perl coders out there, they just don't happen to be my neighbors.
I just get frustrated that its not popular with the startup crowd :(
Perhaps this may help turn Perl back into a good lover for u ;-)
First, the age of 30 is arbitrary, unless there's some reason that only the experiences of people under 30 matters. Perhaps everyone over 30 stops coding, or dies, or fails to create anything interesting -- but you haven't demonstrated that.
Second, the choice of Atlanta is arbitrary. Is Atlanta a sufficient statistical representative of all of the locations of programmers in the world?
Third, your choice of "people I know" is arbitrary. Can you demonstrate that you know a representative sample of available programmers in the Atlanta area? (What happens if you expand the definition of "programmers" to include "people who occasionally write a program"?)
Fourth, your experience doesn't compare. An anecdote is not a piece of data.
The rate of change on the CPAN is not the sole determinant of Perl's viability, but there is a single, well-understood place to share reusable code with other Perl programmers. It's measurable data, and it's normative for certain types of Perl usage.
What you provided isn't data. It's just noise.
What about that noise? This is pretty typical Perl thinking: pretend everything is ok, nothing to see here. Lots of CPAN commits, we have one metric to cling to. Everything is ok.
Generally I take everything I read with a large pinch of salt unless all the facts are presented and can be proven so don't believe either of these are fact especially the TIOBE one!
If you don't think Perl 6 is cool you must not know anything about it.
A large amount of infrastructure at my workplace is written in (and much of it will continue to be written in) perl. Perl5 is sort of like vi, it'll probably be on whatever system you're logging into in some form or other.
One of my co workers is a Perl6 evangelist, to the point of caricature.
That may not be cool by your (or Reddit's or TechCrunch's or whatever) standards and it may very well never be as popular for writing the next big web app but but as one of the underpinnings of the internet it's cool by me.
That's cool. Maybe not cool on the same axis as Rails and Twitter but cool nonetheless.
Meanwhile, I'm going to keep using Python. ;)
Its fallen a bit behind on the BridgeSupport API: http://bridgesupport.macosforge.org/
Does PyObjC now fully support BridgeSupport?
If someone builds something phenomenally cool with perl6 there's no reason it won't have a resurgence as well.
Isn't it..
foo + " " + barIf you send a TrimmedString to a String, then all bets are off. This would make the use case: if you start with a TrimmedString, you always have a TrimmedString. (Barring operations that are deliberate conversions.)
<jnthn> bytes($string) # how many bytes
$s->bytes returns the number of bytes of the NFKC-normalized
and UTF-8 encoded $s. This is subject to change.
This, together with "This is subject to change", strikes me as slightly inconsistent and unreliable function.
<sjohnson> will Perl 6 contain a switch / case structure?
<japhb> sjohnson: given/when.
Apart from that, Perl 6 seems to be moving forward. I still think it looks kinda lacking compared to languages I like to use, but like mentioned in the IRC excerpt, language debates tends to get kinda pointless ;)
You'd be surprised. The log isn't uncommon, especially on freenode, where you often end up being able to chat to really knowledgeable people who have built very cool stuff.
Did you notice the next line?
"<japhb> sjohnson: and it's quite powerful."
That implies it's more than just switch/case. If it's not quite the same thing as switch/case, then it's appropriate to give it a different name, even if it fills the same functional role.
I can see the rationale behind using a different name for the construct, but I still think it would have made more sense to stick to switch/case.
See here for his full explanation: http://dev.perl.org/perl6/doc/design/apo/A04.html (see RFC 022).
This is an interesting trend that I've noticed in programmers recently -- they want everything to be a parameter to a function they've found. Instead of:
(bytes (encode-to-charset string "some-charset"))
(bytes string :in-charset "some-charset")
(I blame this on auto-completing IDEs. Once you've guessed the name of a function with the help of your IDE, you expect it to do everything you want... reading about parameters to the function is easy... but finding another function is hard. Therefore, bloated interfaces are in demand.)
See my other comment: http://news.ycombinator.com/item?id=628031
(I will admit that I'm confused as to why you would need to know the length of a string's representation in a certain encoding unless you are writing a network protocol.)
Uhm... read the both these lines, not just one of them like you did before:
<jnthn> chars($string) # characters
<jnthn> bytes($string) # how many bytesIf you are going to have a function for the size a "rendered" unicode string and there are 200+ ways to render it, it seems odd to tie a function to one and only of those ways, giving you one function for one encoding, and another one for all the other ones.