I can't wait for Perl 6.
Whose irony tag are you closing? I looked at the page source and couldn't find an opening irony tag.
^^ here you go.
Perl - the Detroit of scripting languages
41–50 of 100 posts
Re: Perl - the Detroit of scripting languages
#42Earlier quoted context omitted.
I challenge your efficiency claims. The benchmarks just do not support. I mean, roughly in parity with Python and PHP, 20x slower than Clojure on average, 30x slower than Haskell, and on many tasks 100x slower than C. Over the whole bredth of the Alioth shootout programs, Perl trades places with JRuby as the slowest tested language.
Most of what I do involves loading text files with fixed width records. A file is between 500M and 4Gb. Then I do things with these records. So far I have not found anything faster than perl unpack (1), but I would be happy to. I plan to investigate Go soon. Would you have another suggestion? 1 : or marginally faster, with the advantages negated by the time it takes to write the code. However, a 10x improvement would…
"So far I have not found..."
What else have you tried?
Re: Perl - the Detroit of scripting languages
#43To add two different thoughts: * Perl is widely used and has inspired many other languages. These are not small accomplishments. * How many major revision bumps can a language undergo before it loses its identity? How many breaking changes are allowed before it becomes something else? Perhaps the name is about something more than the language as crystallized at any one point in time? But how do you convey that to the…
To the last point:
I'm fairly sure that the identity of a language is defined by its teaching materials.
Up until 2012 all Perl teaching materials were largely based on text written in the early 90s. And as well, any newbie program tended to look like it was almost Perl 4. This was in spite of there being a concensus and strong effort to push among the active Perl community that modern Perl was the way forward.
Then two things happened: The books Modern Perl by chromatic and Beginning Perl by Ovid were written. I used these two books to teach newbies and their code is nothing like the code of newbies of old.
If these two books reach enough penetration, they will change the identity of Perl.
Re: Perl - the Detroit of scripting languages
#44> Moe is an attempt to show a way forward, not be a way forward.
I can certainly appreciate the desire to make something fun, either for your personal edification, or to try to engage the constructive aspect of your community, I have to wonder: is there enough manpower left in the Perl community to handle all five-six of these revitalization efforts, while also continuing the march to Perl 6 and maintaining 25 years of backwards compatibility? The analogy to Detroit really couldn't be more apt.
In 1998 Perl had a substantial portion of all programmers simply because it was the best free tool for a wide range of jobs. In 2013 nearly every problem has a language more appropriate than Perl. You don't have a captive audience anymore. These days, almost every language is marginal and makes a living by cultivating a small but fanatical base. In order to play the new game, Perl has to find a new pitch, and "we finally work like real modern programming languages" is pretty weak. There are thousands of languages with real object systems, real exceptions, real functions, etc. Until Perl throws its weight behind something more interesting and substantial than "backwards compatibility with filth" and "someday, it might be nicer" it can expect the current trend of net emigration and a Detroit-like heat death to continue.
Re: Perl - the Detroit of scripting languages
#45Earlier quoted context omitted.
Most of what I do involves loading text files with fixed width records. A file is between 500M and 4Gb. Then I do things with these records. So far I have not found anything faster than perl unpack (1), but I would be happy to. I plan to investigate Go soon. Would you have another suggestion? 1 : or marginally faster, with the advantages negated by the time it takes to write the code. However, a 10x improvement would…
"So far I have not found..." What else have you tried?
I think it's important to note that there is an implication in his question of the code of the alternative being as easy to read and write as Perl. One could of course write a much faster text processing tool in Assembler, but well ...
Re: Perl - the Detroit of scripting languages
#46> Moe is an attempt to show a way forward, not be a way forward. I can certainly appreciate the desire to make something fun, either for your personal edification, or to try to engage the constructive aspect of your community, I have to wonder: is there enough manpower left in the Perl community to handle all five-six of these revitalization efforts, while also continuing the march to Perl 6 and maintaining 25 years…
> In 2013 nearly every problem has a language more appropriate than Perl.
Citation needed. Seriously, please stop making such broad statements based on your feelings and opinions and instead please make an earnest effort to separate objective facts from your subjective perception.
And just to address another point: Perl has multiple real object systems that are inter-compatible (with one small exception), and are considerably more powerful than the OO of Ruby or Python. The only real complaint you can level against Perl is that they need to be installed from CPAN; which is not a very useful complaint since all the useful bits in Perl need to be installed from CPAN anyway.
Re: Perl - the Detroit of scripting languages
#47Earlier quoted context omitted.
Most of what I do involves loading text files with fixed width records. A file is between 500M and 4Gb. Then I do things with these records. So far I have not found anything faster than perl unpack (1), but I would be happy to. I plan to investigate Go soon. Would you have another suggestion? 1 : or marginally faster, with the advantages negated by the time it takes to write the code. However, a 10x improvement would…
Well that's great... For your very narrow use case.. It is not however an effective rebuttal to the points brought up in a more general case.
"It is not however an effective rebuttal to the points brought up in a more general case."
Where is this general case? I clicked thru the presentation and it boils down to here are some obscure yet interesting and trendy corners of the computational world where Perl doesn't work well, therefore we have to change everything.
We could have had the same presentation 20 years ago, just the trendy weird corners would have to change to match the times. Doesn't mean those trendy corners are useless, just not required to write 'good code'.
Not that the goals are inherently awful. I don't do anything requiring UTF-8 at work. Someday I probably will, and it'll probably be a PITA.
I tend to see this kind of presentation as rabble rousing. "Here's some stuff that other languages care about, although you don't care, but it obviously doesn't prevent any of you from being profitable and gainfully employed writing good code so its obviously not required, which is why Perl doesn't have it. If I can convince you to care about it, Perl would gain it or more likely you'd just leave Perl. Hope you feel uplifted, here's some internet meme pictures, k thx bye" I'm not sure other languages consider it "insightful" when they get a cut and paste rephrasing of the same presentation, which is possibly the most interesting part of the whole story.
Re: Perl - the Detroit of scripting languages
#48In perl5 : - I can have a prototype running in a matter of minutes - I have access to a vast library of modules doing everything I need (which helps the former) - I write quick and efficient code Do I really care about what other people think about the languages and tools I use? No. However, I do care about efficiency and results And, uh, working with a language that has been out for tens of years makes me believe my…
I challenge your efficiency claims. The benchmarks just do not support. I mean, roughly in parity with Python and PHP, 20x slower than Clojure on average, 30x slower than Haskell, and on many tasks 100x slower than C. Over the whole bredth of the Alioth shootout programs, Perl trades places with JRuby as the slowest tested language.
"The benchmarks just do not support."
I don't make money writing benchmarks. I would challenge that given a flexible enough language, they're nearly meaningless.
Another very important point is most of my Perl is glue between enormous systems. Spending any time optimizing it would be a waste of time/money. I'm not writing real time video encoding here.
Re: Perl - the Detroit of scripting languages
#49In perl5 : - I can have a prototype running in a matter of minutes - I have access to a vast library of modules doing everything I need (which helps the former) - I write quick and efficient code Do I really care about what other people think about the languages and tools I use? No. However, I do care about efficiency and results And, uh, working with a language that has been out for tens of years makes me believe my…
In 10 years you could say exactly the same thing, except that:
- Perl 6 will STILL be in development
- You just lost 10 years of development experience and related marketability because now all those fad-du-jour systems are established industry leaders
- Nothing would have have changed back in Perl 5 land because everyone can only develop in 5.8.x or 5.10.x in case they break something.
The upside of course is that there will still be COBOL and perl programmers making a living ...
Re: Perl - the Detroit of scripting languages
#50Earlier quoted context omitted.
Most of what I do involves loading text files with fixed width records. A file is between 500M and 4Gb. Then I do things with these records. So far I have not found anything faster than perl unpack (1), but I would be happy to. I plan to investigate Go soon. Would you have another suggestion? 1 : or marginally faster, with the advantages negated by the time it takes to write the code. However, a 10x improvement would…
Well that's great... For your very narrow use case.. It is not however an effective rebuttal to the points brought up in a more general case.
Wait, you think opening and reading files of various sizes is a narrow case for a language named Practical Extraction and Report Language?