7 ms·

You know what rocked? Perl 4. I started on Perl 4 in the mid-1990s. It was fantastic! I started replacing thousand-line C programs with hundred-line Perl progr

by beat 12y ago

You know what rocked? Perl 4. I started on Perl 4 in the mid-1990s. It was fantastic! I started replacing thousand-line C programs with hundred-line Perl programs that were more robust and worked better, and replacing shell scripts made of awkward sed/awk pipelines with neat, tight Perl. Arrays and hashes as first class data structures? Marvelous! Then Perl 5 ruined it all. The ridiculous, bloated "object oriented" syntax rendered it basically unreadable, without adding much useful functionality. The layers of syntax options forced teamwork-driven Perl (I wrote about 10k lines of it) to pay close attention to coding standards, closer than more consistent languages, just to not step on each other or have fights. Then along came Python and Ruby, which shared most of the benefits of Perl (scripting, mostly), but added very clean, elegant OO syntax. Everyone who actually cared about writing decent OO scripts switched. Plus Python had much better math libs, and Ruby soon had Rails. And Perl 6? Fourteen years and nothing to show for it, and it'll have to be backwards compatible to all the things violently wrong with Perl 5. There's no use case that isn't already covered by Python and Ruby. Unless some new technology comes along and Perl jumps in firstest with mostest (like Ruby did with Rails), no one will really care. The average age of Perl programmers has been increasing by about one year per year since 2002 or so. I don't see that changing anytime soon.

silvestrov 12y ago
The perl developers greatly underestimated the importance of syntactic sugar and familiarity. (Java was helped a lot by looking like C). PHP was much more friendly towards new programmers than Perl 5, it was so much easier to make simple web pages. So it took over. It didn't matter that Perl 5 was more advanced. (oh, you uploaded module to same dir and didn't remember to add something to @INC)
- riffraff 12y ago
  > The perl developers greatly underestimated the importance of syntactic sugar and familiarity. I don't think that's the case. The problem is that the generation of tools that have stuff in common with perl (awk, sed, shell) are completely unfamiliar to programmers which started programming in the last 15 years, compared to those that started 30 years ago.
  - silvestrov 12y ago
    Look at how much boilerplate code you need in Perl 5 to create a class versus C++/Java's simple class MyClass { } You need to assign to a variable named @ISA, you need to return 1; at the bottom of the file. And 'public' members have to be listed in the EXPORT variable. It is really funny that Perl 5 OO need more boilerplate code than Java!
    - klibertp 12y ago
      What? I'm not a PERL programmer - I used it a bit before it grew OO features, roughly at the same time I used Turbo Pascal, so really long ago. Yet, in these examples: http://stackoverflow.com/questions/1037312/how-do-i-create-a-perl-class http://stackoverflow.com/questions/1037312/how-do-i-create-a... I see no boilerplate you speak of. If you look at this http://stackoverflow.com/questions/1037312/how-do-i-create-a-perl-class/1039075#1039075 http://stackoverflow.com/questions/1037312/how-do-i-create-a... answer you'll see comparison to C++, which isn't exactly in the favour of the latter in terms of conciseness. And then, even if it was true and you really needed to "add public methods to EXPORT variable" that's no different than modern JavaScript, right? That's how modules work in JS. Having to "return" something at the end of a module is a requirement in Lua, too - again, it's just how the module system works. Anyway, I don't know PERL, but knowing many other languages I find your claims suspicious. It reads as if you were a recent Java convert who tries to rationalize his decision to leave PERL or something like that.
    - simcop2387 12y ago
      A small correction there, you aren't making them public by putting them in EXPORT. What you're doing is actually using another module to munge the namespace that used your class. In fact by default all functions defined in a package that is used as a class are public by default. And here's the boiler plate for more modern perl: package MyClass; use Moose; 1; You can define properties of the class using has 'property'; This will setup any accessors and also handle initializing them in the constructor that's created for you by default.
      - mrottenkolber 12y ago
aytekin 12y ago
Big rewrites = death
- frik 12y ago
  It seems so. * Perl 6: almost everyone is on Perl 5, or switched to another language * Python 3: many libraries and devs will stick with Python 2, several devs switched to Go * PHP 6: unicode rewrite never released, new features backported to 5.3+, several books were published in advance with PHP 6 in the title, next release will be named PHP 7 to avoid confusion * Lua 5.2+: half of the community stuck with 5.1 as supported with LuaJIT and is many applications (World of Warcraft, Photoshop Lightroom, Facebooks AI platform, etc.) * VB.Net: many stick with VB 6, many switched to web development * VBA.Net: everyone still use VBA 6/7 in various Office applications * ASP.Net: many stuck with ASP coded in VBS/JS, many switched to similar platforms e.g. PHP The opposite: * Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind
  - ceronman 12y ago
    > The opposite: > * Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind It seems too soon to tell what's going to happen with io.js. It was released just a few days ago.
  - malandrew 12y ago
    io.js has one major advantage over your other examples: it is tracking the same javascript that browsers are running. When every major browser is moving in the same direction with a language, any server-side counterpart is best served moving in the same direction. Without browsers, io.js would have likely ended up in the same place as all the examples above.
  - mateuszf 12y ago
    * Angular.js - Don't want to be preaching - but it looks like version 2 will be die in the same way.
perlgeek 12y ago
> And Perl 6? Fourteen years and nothing to show for it ... except a nearly feature-complete [1] compiler [2] and an impressive test suite [3] [1] http://perl6.org/compilers/features http://perl6.org/compilers/features [2] http://rakudo.org/ http://rakudo.org/ [3] https://github.com/perl6/roast/ https://github.com/perl6/roast/ > and it'll have to be backwards compatible to all the things violently wrong with Perl 5 Not at all. The whole point about Perl 6 is that it breaks backwards compatibility to fix the things that are wrong with Perl 5.
- chrisdone 12y ago
  > The whole point about Perl 6 is that it breaks backwards compatibility I think this is is a contributor to why Perl 6 will never amount to anything. That boat has sailed. Python 3 broke backwards compatibility and to my knowledge everybody is still using Python 2. Python has a lot of energy right now, so that might save it, or it might go the way of Perl when the next cool language comes out and everybody jumps ship.
  - scrollaway 12y ago
    Everybody IN ENTERPRISE is still using Python 2. Realistically, most of the Python ecosystem is compatible 2+3, we are seeing new libraries and programs compatible 3.3+-only, and there's no broad reason to use Python 2 anymore, with minor exceptions.
    - perlgeek 12y ago
      > and there's no broad reason to use Python 2 anymore, with minor exceptions. If you count big chunks of legacy python 2 code a "minor exception", I agree. Anyway, the big difference between python 2 -> 3 transition and the Perl 5 and Perl 6 coexistence is that nobody within the Perl community tried to end-of-live Perl 5. Yes, that means less incentives for migrating to Perl 6, but it also reduces the risk for Perl 5 users.
      - sp332 12y ago
gaius 12y ago
Indeed. While personally I think Tcl is a better language than either, professionally I jumped straight from Perl 4 to Python, bypassing Perl 5 altogether. The combination of needing rigid standards to make a codebase maintainable in big projects, with the dynamic nature of the language meaning that tool support for it was scarce, was a double whammy. Now that I think about it, not even that big projects, teams of 10 or so devs, getting bogged down in language issues that Python simply didn't have (and no one even wished for tool support for, the was no need!)
- biomimic 12y ago
  Tcl is Fantastic.
- sukilot 12y ago
  This sounds less like "perl 5" was a downgrade, and more like, "switching from sysadmin scripts to building enterprise projects (in ~2001-~2008 Amazon.com was written in Perl) made Perl less fun".
_paulc 12y ago
Absolutely right - Perl 4 had a clear niche (text processing, UNIX system scripting etc) and did this very well. Perl 5 added so much cruft and ugly syntax on top of this in an attempt to try to become more 'general purpose' that it lost its focus. At this point it became easier to switch to Python for 'real' programming. There are still a lot of problems in the Perl 4 space and to be honest I wish that distributions shipped with a supported version of 4.036.
- b2gills 12y ago
  It would be rather pointless to ship Perl4, as Perl5 is almost completely backwards compatible with Perl4. Most of the parts where backwards compatibility was removed weren't actually used to a large extent. Also Perl5 didn't add that much syntax, and a big reason it was ugly is that Perl4 didn't leave a lot of space for the extra features. Which is also why Perl6 breaks backwards compatibility. There are also some features that were eventually removed from Perl5, but not really. For example setting $[ was removed (it was a pretty stupid idea), but if you try to use it Perl loads the module arybase which re-implements that feature. (removing it simplified the internals)
- duskwuff 12y ago
  If you seriously think that Perl5 is less suitable for text processing than Perl4 was, I suspect you haven't actually used the language in a while... it's still perfectly good for that. Perhaps even better, since 5.8 added extensive support for Unicode (without requiring explicit conversions and breaking everything like Python 3 did).
  - ptx 12y ago
    From a quick skimming through the docs[0], Perl 5.8's Unicode support sounds a lot like Python 2's except that the default encoding is latin1 instead of ASCII - i.e. unlike the Python 3 way of explicitly decoding binary data into Unicode text at the point where it's read (where presumably the encoding of the data is known), it will defer the decoding until the data is used (at some completely unrelated point in the program) and decode it with some assumed globally agreed upon encoding. Since there is no globally agreed encoding (Windows even has different legacy encodings between Win32 and the command prompt!) this will appear to work as long as the data is ASCII but later, when you least expect it (and someone inputs a non-ASCII string), give UnicodeDecodeError in Python 2 or garbage data in Perl 5.8. Ned Batchelder gave an excellent talk[1] that explains how the Python 3 approach to Unicode works. I think it makes a lot more sense once you understand it; the Python 2 way was clearly broken, and it looks like Perl 5 has the same problem but hides it better. [0] http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod [1] http://m.youtube.com/watch?v=sgHbC6udIqc http://m.youtube.com/watch?v=sgHbC6udIqc
proveanegative 12y ago
Is there an actively maintained fork of Perl 4 (or earlier) somewhere? Sounds like there should be.
- perlgeek 12y ago
  There's really not much point. Perl 5 is 99% backwards compatible with Perl 4, so if you think Perl 4 was great, just use the Perl 5 compiler (but none of the new features).
  - duskwuff 12y ago
    Perl5 even still supports some of the really ugly features of Perl4 that people generally wish would go away (like &function_calls, and nested'packages'like'this.)
razzmataz 12y ago
The irony here, then, is that Perl 5 took the object system that Python had in 1995 as an example to emulate.
snarfy 12y ago
Even Duke Nukem Forever shipped before Perl 6.
mpdehaan2 12y ago
MooseX::Declare makes Perl OO actually pretty good. I like the traits system. Not that I'd pick it as a first starting point for new work, it's nice for using with existing legacy work.

by beat 12y ago

silvestrov 12y ago

The perl developers greatly underestimated the importance of syntactic sugar and familiarity. (Java was helped a lot by looking like C). PHP was much more friendly towards new programmers than Perl 5, it was so much easier to make simple web pages. So it took over. It didn't matter that Perl 5 was more advanced. (oh, you uploaded module to same dir and didn't remember to add something to @INC)

riffraff 12y ago
> The perl developers greatly underestimated the importance of syntactic sugar and familiarity. I don't think that's the case. The problem is that the generation of tools that have stuff in common with perl (awk, sed, shell) are completely unfamiliar to programmers which started programming in the last 15 years, compared to those that started 30 years ago.
- silvestrov 12y ago
  Look at how much boilerplate code you need in Perl 5 to create a class versus C++/Java's simple class MyClass { } You need to assign to a variable named @ISA, you need to return 1; at the bottom of the file. And 'public' members have to be listed in the EXPORT variable. It is really funny that Perl 5 OO need more boilerplate code than Java!
  - klibertp 12y ago
    What? I'm not a PERL programmer - I used it a bit before it grew OO features, roughly at the same time I used Turbo Pascal, so really long ago. Yet, in these examples: http://stackoverflow.com/questions/1037312/how-do-i-create-a-perl-class http://stackoverflow.com/questions/1037312/how-do-i-create-a... I see no boilerplate you speak of. If you look at this http://stackoverflow.com/questions/1037312/how-do-i-create-a-perl-class/1039075#1039075 http://stackoverflow.com/questions/1037312/how-do-i-create-a... answer you'll see comparison to C++, which isn't exactly in the favour of the latter in terms of conciseness. And then, even if it was true and you really needed to "add public methods to EXPORT variable" that's no different than modern JavaScript, right? That's how modules work in JS. Having to "return" something at the end of a module is a requirement in Lua, too - again, it's just how the module system works. Anyway, I don't know PERL, but knowing many other languages I find your claims suspicious. It reads as if you were a recent Java convert who tries to rationalize his decision to leave PERL or something like that.
  - simcop2387 12y ago
    A small correction there, you aren't making them public by putting them in EXPORT. What you're doing is actually using another module to munge the namespace that used your class. In fact by default all functions defined in a package that is used as a class are public by default. And here's the boiler plate for more modern perl: package MyClass; use Moose; 1; You can define properties of the class using has 'property'; This will setup any accessors and also handle initializing them in the constructor that's created for you by default.
    - mrottenkolber 12y ago

aytekin 12y ago

Big rewrites = death

frik 12y ago
It seems so. * Perl 6: almost everyone is on Perl 5, or switched to another language * Python 3: many libraries and devs will stick with Python 2, several devs switched to Go * PHP 6: unicode rewrite never released, new features backported to 5.3+, several books were published in advance with PHP 6 in the title, next release will be named PHP 7 to avoid confusion * Lua 5.2+: half of the community stuck with 5.1 as supported with LuaJIT and is many applications (World of Warcraft, Photoshop Lightroom, Facebooks AI platform, etc.) * VB.Net: many stick with VB 6, many switched to web development * VBA.Net: everyone still use VBA 6/7 in various Office applications * ASP.Net: many stuck with ASP coded in VBS/JS, many switched to similar platforms e.g. PHP The opposite: * Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind
- ceronman 12y ago
  > The opposite: > * Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind It seems too soon to tell what's going to happen with io.js. It was released just a few days ago.
- malandrew 12y ago
  io.js has one major advantage over your other examples: it is tracking the same javascript that browsers are running. When every major browser is moving in the same direction with a language, any server-side counterpart is best served moving in the same direction. Without browsers, io.js would have likely ended up in the same place as all the examples above.
- mateuszf 12y ago
  * Angular.js - Don't want to be preaching - but it looks like version 2 will be die in the same way.

perlgeek 12y ago

> And Perl 6? Fourteen years and nothing to show for it ... except a nearly feature-complete [1] compiler [2] and an impressive test suite [3] [1] http://perl6.org/compilers/features http://perl6.org/compilers/features [2] http://rakudo.org/ http://rakudo.org/ [3] https://github.com/perl6/roast/ https://github.com/perl6/roast/ > and it'll have to be backwards compatible to all the things violently wrong with Perl 5 Not at all. The whole point about Perl 6 is that it breaks backwards compatibility to fix the things that are wrong with Perl 5.

chrisdone 12y ago
> The whole point about Perl 6 is that it breaks backwards compatibility I think this is is a contributor to why Perl 6 will never amount to anything. That boat has sailed. Python 3 broke backwards compatibility and to my knowledge everybody is still using Python 2. Python has a lot of energy right now, so that might save it, or it might go the way of Perl when the next cool language comes out and everybody jumps ship.
- scrollaway 12y ago
  Everybody IN ENTERPRISE is still using Python 2. Realistically, most of the Python ecosystem is compatible 2+3, we are seeing new libraries and programs compatible 3.3+-only, and there's no broad reason to use Python 2 anymore, with minor exceptions.
  - perlgeek 12y ago
    > and there's no broad reason to use Python 2 anymore, with minor exceptions. If you count big chunks of legacy python 2 code a "minor exception", I agree. Anyway, the big difference between python 2 -> 3 transition and the Perl 5 and Perl 6 coexistence is that nobody within the Perl community tried to end-of-live Perl 5. Yes, that means less incentives for migrating to Perl 6, but it also reduces the risk for Perl 5 users.
    - sp332 12y ago

gaius 12y ago

Indeed. While personally I think Tcl is a better language than either, professionally I jumped straight from Perl 4 to Python, bypassing Perl 5 altogether. The combination of needing rigid standards to make a codebase maintainable in big projects, with the dynamic nature of the language meaning that tool support for it was scarce, was a double whammy. Now that I think about it, not even that big projects, teams of 10 or so devs, getting bogged down in language issues that Python simply didn't have (and no one even wished for tool support for, the was no need!)

biomimic 12y ago
Tcl is Fantastic.
sukilot 12y ago
This sounds less like "perl 5" was a downgrade, and more like, "switching from sysadmin scripts to building enterprise projects (in ~2001-~2008 Amazon.com was written in Perl) made Perl less fun".

_paulc 12y ago

Absolutely right - Perl 4 had a clear niche (text processing, UNIX system scripting etc) and did this very well. Perl 5 added so much cruft and ugly syntax on top of this in an attempt to try to become more 'general purpose' that it lost its focus. At this point it became easier to switch to Python for 'real' programming. There are still a lot of problems in the Perl 4 space and to be honest I wish that distributions shipped with a supported version of 4.036.

b2gills 12y ago
It would be rather pointless to ship Perl4, as Perl5 is almost completely backwards compatible with Perl4. Most of the parts where backwards compatibility was removed weren't actually used to a large extent. Also Perl5 didn't add that much syntax, and a big reason it was ugly is that Perl4 didn't leave a lot of space for the extra features. Which is also why Perl6 breaks backwards compatibility. There are also some features that were eventually removed from Perl5, but not really. For example setting $[ was removed (it was a pretty stupid idea), but if you try to use it Perl loads the module arybase which re-implements that feature. (removing it simplified the internals)
duskwuff 12y ago
If you seriously think that Perl5 is less suitable for text processing than Perl4 was, I suspect you haven't actually used the language in a while... it's still perfectly good for that. Perhaps even better, since 5.8 added extensive support for Unicode (without requiring explicit conversions and breaking everything like Python 3 did).
- ptx 12y ago
  From a quick skimming through the docs[0], Perl 5.8's Unicode support sounds a lot like Python 2's except that the default encoding is latin1 instead of ASCII - i.e. unlike the Python 3 way of explicitly decoding binary data into Unicode text at the point where it's read (where presumably the encoding of the data is known), it will defer the decoding until the data is used (at some completely unrelated point in the program) and decode it with some assumed globally agreed upon encoding. Since there is no globally agreed encoding (Windows even has different legacy encodings between Win32 and the command prompt!) this will appear to work as long as the data is ASCII but later, when you least expect it (and someone inputs a non-ASCII string), give UnicodeDecodeError in Python 2 or garbage data in Perl 5.8. Ned Batchelder gave an excellent talk[1] that explains how the Python 3 approach to Unicode works. I think it makes a lot more sense once you understand it; the Python 2 way was clearly broken, and it looks like Perl 5 has the same problem but hides it better. [0] http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod [1] http://m.youtube.com/watch?v=sgHbC6udIqc http://m.youtube.com/watch?v=sgHbC6udIqc

proveanegative 12y ago

Is there an actively maintained fork of Perl 4 (or earlier) somewhere? Sounds like there should be.

perlgeek 12y ago
There's really not much point. Perl 5 is 99% backwards compatible with Perl 4, so if you think Perl 4 was great, just use the Perl 5 compiler (but none of the new features).
- duskwuff 12y ago
  Perl5 even still supports some of the really ugly features of Perl4 that people generally wish would go away (like &function_calls, and nested'packages'like'this.)

razzmataz 12y ago

The irony here, then, is that Perl 5 took the object system that Python had in 1995 as an example to emulate.

snarfy 12y ago

Even Duke Nukem Forever shipped before Perl 6.

mpdehaan2 12y ago

MooseX::Declare makes Perl OO actually pretty good. I like the traits system. Not that I'd pick it as a first starting point for new work, it's nice for using with existing legacy work.