$s->bytes returns the number of bytes of the NFKC-normalized
and UTF-8 encoded $s. This is subject to change.
While UTF-8 is a good default encoding, it seems odd to tie standard functions into things which cannot be presumed. Without having the ability to specify encoding, you will have one function for UTF-8 and a different one (roll your own?) for every other encoding out there.
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.
I honestly don't see how in a C-style language, using different names for the exact same construct found in every other C-style language adds any real value.
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 ;)
>> "This actually shows a useful IRC channel for once."
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.
#Haskell is another room that is useful. There is constant deep, on-topic discussion between experienced users who will also go out of their way to help newbies, without rockstar cliques who are too important to allow that in their channel.
"I honestly don't see how in a C-style language, using different names for the exact same construct found in every other C-style language adds any real value."
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.
Thanks for the reference. I quickly skimmed it, and as far as I can tell the only thing it offers compared to a traditional switch/case statement, is the evaluation of expressions, as opposed to just accepting constants.
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.
While UTF-8 is a good default encoding, it seems odd to tie standard functions into things which cannot be presumed. Without having the ability to specify encoding, you will have one function for UTF-8 and a different one (roll your own?) for every other encoding out there.
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"))
they want:
(bytes string :in-charset "some-charset")
Why bloat the interface and implementation of "bytes" like this? Pick a reasonable charset by default; let users write code that does what they want in the (rare) corner-cases.
(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.)
You missed my point entirely. Text in memory should be unicode and not encoded, as nothing else would really make sense. In that case bytes() refers to the size of string when rendered in a specific encoding. You are not getting the "size" of the actual string.
But you have to remember, even though there are millions of encodings and character sets, UTF-8 Unicode makes up 99.99% of real-world use-cases. So it makes sense to make that 99.99% easy.
(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.)
While UTF-8 is a good default encoding, it seems odd to tie standard functions into things which cannot be presumed. Without having the ability to specify encoding, you will have one function for UTF-8 and a different one (roll your own?) for every other encoding out there.
Uhm... read the both these lines, not just one of them like you did before:
<jnthn> chars($string) # characters
<jnthn> bytes($string) # how many bytes
I guess you should reread my comment. I'm fully aware of that you can get chars with chars(), but that's not what I'm pointing out.
If 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.
This is what happens when all the hype moved on the next language. What remains is a kind, good community. But it's too late, a language also needs momentum and hype.
I disagree with your statement. Momentum and hype are good for attracting those who choose a language based on its momentum and hype. If you are choosing a language to perform a task based on any objective criteria, momentum and hype interfere with your ability to choose and are therefore repulsive.
You are quoting the standard perl attitude: languages are not cool/uncool, they are only useful or un-useful. Meanwhile Perl is not 'cool,' most people have moved on from Perl, Perl 6 will never ship, and Perl is dying.
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.
How can you write "Perl 6 will never ship"? Rakudo has monthly stable releases; last week they released their 17th stable release in a row.
(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?)
Its been a long time in development, and is completely dependent on a stable Parrot - something very few people use. Its been almost 10 years, I just don't think it will ship 1.0. DNF.
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.
People said we'd never release Parrot 1.0 either (people said that as recently as November) -- but why speculate when you can measure?
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.
Calling it Parrot 1.0 doesn't mean its stable. You can call it 10.0, doesn't mean people are gonna switch.
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.
What else would we call Parrot 1.0? We believe that Parrot 1.0 represents a stable platform on which people can start to build compilers.
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.)
If I said nobody whatsoever under 30 codes Perl, you would count in my poll. I said nobody I know. I realize there are some of you, but you must know that there aren't many of you, right?
Ok, here's your premise: Perl is dying.
And here's your argument: I don't know anyone below thirty in Atlanta that uses it.
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.
Most people I know that code Perl are in the 25-30 range, and I consider myself pretty widely connected in the community. Why do you care about age, anyway... it's a programming language, not a boy band.
That's a very silly data point for several reasons.
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 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.
TIOBE's flaws are well-documented throughout the Internet (look out Ruby -- Delphi, RPG, and Logo are hot on your heels!). In particular, no third party has ever been able to duplicate their results, whereas anyone with access to any of the hundreds of CPAN mirrors can verify those numbers.
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!
Does it have Perl in the name? Then it may be great, but its not cool. The kids think it sucks. And if you don't care about the kids, then you don't care about the future.
I don't like perl, for one reason or another we never got along. I respect the hell out of it though. Perl is so far from dead it's achieved complete success and become invisible.
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.
Yeah, Perl 5 pays the bills. I code in it every day. I am most fluent in Perl. My point is that the long-delay of Perl 6 and the large volumes of crusty CGI code around has created an image problem.
Unfortunately, a lot of so called objective criteria are either entirely subjective or difficult to measure. Are variable names that begin with special characters like '$' easier for the brain to handle than those without? It'd be an interesting topic for a study (assuming one could be done), but lacking any clear empirical evidence, debates will rage on about this and other minutia.
I have to agree with evilneanderthal. Pick the tool that does the job. For most batch processing jobs, Perl is the tool that will get it done the fastest both in run and development time. It's just built to process that kind of data, and the community has built an excellent library to do so.
All in all I agree with you, but I think momentum can be part of objective criteria. Not in the language itself, but as part of a human ressources or marketing strategy. Also, sometimes the language with momentum is the one with the library. Case in point: Cocoa bridge under Leopard exists for Python, Ruby and .. not for Perl.
If many languages/libraries have SortedCollection, or a collection which is always a sorted sequence, why not have something like a "TrimmedString?" It'll be a string that's always in the trimmed state. That would eliminate lots of "trim()" calls.
If foo contains an instance TrimmedString, why can't it just return itself after the first + operation?
If 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.)
The traits referred to in this log are primarily things that Perl has inherited from Ruby, rather than things Ruby took from Perl in the first place (which, to be fair, was rather little).
When I clicked the link, I fully expected to see a scary line-noise-y Perl script implementing a chatbot that persuades people to upgrade to Perl 6 :-)
59 comments
[ 2.0 ms ] story [ 126 ms ] threadThis, together with "This is subject to change", strikes me as slightly inconsistent and unreliable function.
I honestly don't see how in a C-style language, using different names for the exact same construct found in every other C-style language adds any real value.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:
they want: Why bloat the interface and implementation of "bytes" like this? Pick a reasonable charset by default; let users write code that does what they want in the (rare) corner-cases.(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:
If 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.
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.
http://www.perlmonks.org/?node_id=142797
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.
If 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.)
Isn't it..