4 ms·

Arguably Ruby and Python rank just as high, if not higher, on all of the first line, and do so without Perl's cruft and bloat. There's more to a language than

Arguably Ruby and Python rank just as high, if not higher, on all of the first line, and do so without Perl's cruft and bloat. There's more to a language than just it's syntax, and even if Perl can have some pretty compact syntax - and it certainly can - that doesn't make up for it's weaknesses in other areas. Namely, it's Object Oriented programming that is a bad joke, it's weak-ass multithreading, the fact it's a walking memory leak, it's attempt to shoehorn two completely different variable scoping paradigms into one language, it's vast and bewildering array of special cases and exceptions to it's own rules....I could go on and on. Disclaimer: I have used a great deal of both Perl and Ruby.

kscaldef 16y ago
Wait, are you saying that Ruby _doesn't_ have "weak-ass" multithreading, horrible memory leaks, and screwed up variable scoping?
- grammaton 16y ago
  Compared to Perl?
- tsuraan 16y ago
  One nice thing about ruby is that it has quite a few viable implementations floating around. MRI or YARV are probably what you have installed on your computer by default, but if multithreading and sane garbage collection are concerns of yours, JRuby is the right implementation to target. I'm not sure what's wrong with ruby's variable scoping, but I haven't used it for a while, so my memory of the ugly details of the language is a bit dim :)
  - joe_the_user 16y ago
    "One nice thing about ruby is that it has quite a few viable implementations floating around." That's not nice all in my opinion. I don't want "choice" concerning what implementation of my language to use. Unless I have some strange, specialized need, I want one implementation that is guaranteed to work. I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost. The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on. The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that. There are good things about Ruby but dueling implementation breeding uncertainty is not one of them.
    - tsuraan 16y ago
      That's not nice all in my opinion. We definitely have different points of view then. I see single-implementation languages as things to fear. Software projects die, sometimes suddenly. The genius in charge might get hit by a bus, a particular implementation might violate the wrong company's patents, or the owner of an implementation might see an opportunity for profit. When you have options for language implementations, these risks are at least mitigated. Unless I have some strange, specialized need, I want one implementation that is guaranteed to work. I'd love guarantees of perfection too, but I've never seen one. I'm guessing that if I ever did see a guarantee of perfection, I wouldn't be able afford the software it was attached to. Software Engineering, like every other field of engineering, is about tradeoffs. Sometimes they're difficult tradeoffs, but it's your job as a professional to inform yourself and make the best decision you can. I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost. The point of garbage collection is that it allows you to focus on other things first, and then come back and look at your memory use. Even in a language running on a really advanced GC, like the Oracle JVM, you can't ignore your garbage. You need to close files when you're done with them or you will run out of file handles unnecessarily. You need to keep track of your heap use or your program will thrash and your GC will have problems. There's no silver bullet, but being informed about the details of your platform will help you. The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on. Forks are based on common code. We're talking about separate implementations, with different teams and different goals. Nobody working on YARV cares whether ruby interacts well with java libraries. JRuby developers do care. Different teams, different focus. I don't think a winner is going to pop out, and I don't see why one is needed. I do think a better GC for non-JVM ruby would be really good, and somebody probably will make a compliant ruby implementation that has one, but that won't hurt anything. If it's an overall better implementation people will move to it, and YARV will probably go into the background. The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that. The thing about C++ is that it's a standard, not a piece of software. There are dozens of active implementations focusing on the embedded space, windows, solaris, and other platforms. No one implementation is the best for all purposes, and a professional chooses the correct tool for the job. There are good things about Ruby but dueling implementation breeding uncertainty is not one of them. Is anybody really feeling uncertain about ruby's future because it can run on the JVM as well as running in a less dependency-encumbered environment? I can see people being unhappy about the most common ruby implementation having a crap GC and really bad threading support, but having people working on their own ruby implementations is only going to improve the situation.
- msbarnett 16y ago
  I'm curious as to what your issue with Ruby's variable scoping is? It seems very straightforward and intuitive to me. Especially compared with Perl's mix of dynamic and lexical scoping.
  - chromatic 16y ago
    Ruby's variable scoping relies on the compiler guessing the programmer's intent, as its syntax fails to distinguish between "Introduce a binding of this name within the current scope" and "Assign to the variable bound to this name".
    - grammaton 16y ago
      What are you getting at with this?
      - chromatic 16y ago
        Ambiguity seems, to me, to conflict with the desire for clarity and reliability. Any language which allows a typo in an assignment statement to create a new variable name binding silently is insufficiently safe for my purposes. I don't claim that Ruby and Python have security holes form this behavior, but people rightly criticize PHP's register_globals for similar reasons.
        grammaton 16y ago
        "Any language which allows a typo in an assignment statement to create a new variable name binding silently is insufficiently safe for my purposes." Um...Perl has exactly this problem. The only difference is that it's worse because the variable in question gets created as a global variable of the local package - which is naturally visible to anything else that wants to see it, btw. This is exactly why they created "use strict", and underscores the "Perl philosophy" in an elegant nutshell - instead of fixing the underlying problem, just create a hack around it and expect everyone to "know" that they should use it as a best practice.
- Roboprog 16y ago
  I found Ruby's variable scoping to be quite clean: local by default, unless prefixed to be an instance variable (and a few conventions for statics and constants, I think). I wish Perl had similar scoping rules instead of the layered on later techniques of "my" and "the blessed hash". But I still like Perl :-) However, the rest sounds like a valid criticism of Ruby.
berntb 16y ago
>>Namely, [Perl]'s Object Oriented programming that is a bad joke >>Disclaimer: I have used a great deal of both Perl and Ruby. You haven't used Perl lately -- then you would have known about Moose. Perl's OO is now arguably much cooler than the OO of alternative scripting languages... Your point about variable scoping is really strange. Or stupid. Could you elaborate? (Threading do suck, imho. But so it seems to do for most other scripting languages?)
- grammaton 16y ago
  In point of fact I do know about moose, since, like every other Perl user on the planet, I've been around the CPAN block at this point. And that's just the problem - it's in CPAN, not in Perl itself. I can get an object system just as good (or better) in either Ruby or Python without having to go and download an add on. By itself, Perl - without any modules or extensions or any other crutches - has horrid OOP. As far as scoping goes, I shouldn't have to explicity declare a variable lexically scoped - and I can't think of any other language where I do. Only Perl - and only because it's visibly hacked in after the fact, along with a number of other features. Threading is not great for Ruby or Python either, because they use green threads - but Perl has problems bigger than that with it's threading.
  - berntb 16y ago
    So your complaint is really that you have to install stuff to get better defaults in Perl? :-) Sorry, but that is hard to take seriously. >>I shouldn't have to explicity declare a variable lexically scoped Are you saying you don't like strict? Without that, you're fscked if you spell a variable name wrong in the same way, twice... (I really don't get that not all scripting languages have strict.) I've avoided threading in scripting languages as the plague, but I tend to agree with you as far as I've read. :-)
    - grammaton 16y ago
      > So your complaint is really that you have to install stuff to get better defaults in Perl? :-) No, my point is that if you compare it to another programming language simply as a language, it is basically missing a major feature. If you take Ruby, Python, and Perl, and line them up next to each other simply as languages, Perl is at the bottom of the pile on it's own merits where OOP is concerned. > Are you saying you don't like strict? Even if I use strict, good software development practice would dictate using a lexically scoped variable at all times unless I really need something else. That's one of the reasons lexical scoping is the default in so many languages at this point.
rjbond3rd 16y ago
> ...it's Object Oriented programming that is a bad joke... Disclaimer: I have used a great deal of both Perl and Ruby. Evidently not everyone has kept up with Moose (released back in 2007, part of the Perl renaissance, can be learned in a few minutes.)
- grammaton 16y ago
  Not part of the core language, is an add on. Nice trick, but Perl - that is to say, the language itself - still has pretty crappy OOP. Or has Moose been adopted as a core part of the language now?
  - Vivtek 16y ago
    Really, with Perl the distinction "part of the core language" is meaningless. You can install a CPAN bundle for a hardcore Perl in one shell command, or get it all preinstalled. Strawberry Perl for Windows has all the good stuff in a single installer, for instance, and if you're on Unix you've similarly got no excuse. Really. "Core language" is kind of twentieth. Moose is very well-established in the Perl community. That's as core as it gets.
  - chromatic 16y ago
    Not part of the core language, is an add on. So is DBI, Perl::Critic, cpanminus, perlbrew, Dist::Zilla, Perltidy, and (depending on your version) autodie. That's why my definition of a great Perl programmer includes pervasive use of the CPAN--you're restricting yourself unnecessarily if you avoid it.
    - grammaton 16y ago
      Quite correct, and it's almost axiomatic at this point that CPAN is Perl's killer app. That said, I wasn't referring to great programmers - I was referring to the language itself. I'm not sure I understand why basically having to patch your language to get a feature that others have out of the box is not seen as a weakness of that language. Now, we can talk about Perl + CPAN and all the jazz you find therein, but that's a different discussion. My point is, taken by itself, the language Perl does not have an especially good Object system, especially if you consider Ruby and Python the competition. "So is DBI, Perl::Critic..." What's your point? Database bindings and lint like code checking are not features every developer - or even a good chunk of the developers out there - are going to need, or have use for. By that logic I could point out that Perl still wins no points because Ruby and Python - and just about every other contender out there - has their own equivalents. I'm not referring to CPAN or the the gobs of stuff in it - I'm referring to the language itself And while we're on CPAN, much of the popular and useful material in CPAN has equivalents in Ruby and Python that are every bit as mature and useful.

kscaldef 16y ago

Wait, are you saying that Ruby _doesn't_ have "weak-ass" multithreading, horrible memory leaks, and screwed up variable scoping?

grammaton 16y ago
Compared to Perl?
tsuraan 16y ago
One nice thing about ruby is that it has quite a few viable implementations floating around. MRI or YARV are probably what you have installed on your computer by default, but if multithreading and sane garbage collection are concerns of yours, JRuby is the right implementation to target. I'm not sure what's wrong with ruby's variable scoping, but I haven't used it for a while, so my memory of the ugly details of the language is a bit dim :)
- joe_the_user 16y ago
  "One nice thing about ruby is that it has quite a few viable implementations floating around." That's not nice all in my opinion. I don't want "choice" concerning what implementation of my language to use. Unless I have some strange, specialized need, I want one implementation that is guaranteed to work. I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost. The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on. The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that. There are good things about Ruby but dueling implementation breeding uncertainty is not one of them.
  - tsuraan 16y ago
    That's not nice all in my opinion. We definitely have different points of view then. I see single-implementation languages as things to fear. Software projects die, sometimes suddenly. The genius in charge might get hit by a bus, a particular implementation might violate the wrong company's patents, or the owner of an implementation might see an opportunity for profit. When you have options for language implementations, these risks are at least mitigated. Unless I have some strange, specialized need, I want one implementation that is guaranteed to work. I'd love guarantees of perfection too, but I've never seen one. I'm guessing that if I ever did see a guarantee of perfection, I wouldn't be able afford the software it was attached to. Software Engineering, like every other field of engineering, is about tradeoffs. Sometimes they're difficult tradeoffs, but it's your job as a professional to inform yourself and make the best decision you can. I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost. The point of garbage collection is that it allows you to focus on other things first, and then come back and look at your memory use. Even in a language running on a really advanced GC, like the Oracle JVM, you can't ignore your garbage. You need to close files when you're done with them or you will run out of file handles unnecessarily. You need to keep track of your heap use or your program will thrash and your GC will have problems. There's no silver bullet, but being informed about the details of your platform will help you. The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on. Forks are based on common code. We're talking about separate implementations, with different teams and different goals. Nobody working on YARV cares whether ruby interacts well with java libraries. JRuby developers do care. Different teams, different focus. I don't think a winner is going to pop out, and I don't see why one is needed. I do think a better GC for non-JVM ruby would be really good, and somebody probably will make a compliant ruby implementation that has one, but that won't hurt anything. If it's an overall better implementation people will move to it, and YARV will probably go into the background. The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that. The thing about C++ is that it's a standard, not a piece of software. There are dozens of active implementations focusing on the embedded space, windows, solaris, and other platforms. No one implementation is the best for all purposes, and a professional chooses the correct tool for the job. There are good things about Ruby but dueling implementation breeding uncertainty is not one of them. Is anybody really feeling uncertain about ruby's future because it can run on the JVM as well as running in a less dependency-encumbered environment? I can see people being unhappy about the most common ruby implementation having a crap GC and really bad threading support, but having people working on their own ruby implementations is only going to improve the situation.
msbarnett 16y ago
I'm curious as to what your issue with Ruby's variable scoping is? It seems very straightforward and intuitive to me. Especially compared with Perl's mix of dynamic and lexical scoping.
- chromatic 16y ago
  Ruby's variable scoping relies on the compiler guessing the programmer's intent, as its syntax fails to distinguish between "Introduce a binding of this name within the current scope" and "Assign to the variable bound to this name".
  - grammaton 16y ago
    What are you getting at with this?
    - chromatic 16y ago
      Ambiguity seems, to me, to conflict with the desire for clarity and reliability. Any language which allows a typo in an assignment statement to create a new variable name binding silently is insufficiently safe for my purposes. I don't claim that Ruby and Python have security holes form this behavior, but people rightly criticize PHP's register_globals for similar reasons.
      - grammaton 16y ago
        "Any language which allows a typo in an assignment statement to create a new variable name binding silently is insufficiently safe for my purposes." Um...Perl has exactly this problem. The only difference is that it's worse because the variable in question gets created as a global variable of the local package - which is naturally visible to anything else that wants to see it, btw. This is exactly why they created "use strict", and underscores the "Perl philosophy" in an elegant nutshell - instead of fixing the underlying problem, just create a hack around it and expect everyone to "know" that they should use it as a best practice.
Roboprog 16y ago
I found Ruby's variable scoping to be quite clean: local by default, unless prefixed to be an instance variable (and a few conventions for statics and constants, I think). I wish Perl had similar scoping rules instead of the layered on later techniques of "my" and "the blessed hash". But I still like Perl :-) However, the rest sounds like a valid criticism of Ruby.

berntb 16y ago

>>Namely, [Perl]'s Object Oriented programming that is a bad joke >>Disclaimer: I have used a great deal of both Perl and Ruby. You haven't used Perl lately -- then you would have known about Moose. Perl's OO is now arguably much cooler than the OO of alternative scripting languages... Your point about variable scoping is really strange. Or stupid. Could you elaborate? (Threading do suck, imho. But so it seems to do for most other scripting languages?)

grammaton 16y ago
In point of fact I do know about moose, since, like every other Perl user on the planet, I've been around the CPAN block at this point. And that's just the problem - it's in CPAN, not in Perl itself. I can get an object system just as good (or better) in either Ruby or Python without having to go and download an add on. By itself, Perl - without any modules or extensions or any other crutches - has horrid OOP. As far as scoping goes, I shouldn't have to explicity declare a variable lexically scoped - and I can't think of any other language where I do. Only Perl - and only because it's visibly hacked in after the fact, along with a number of other features. Threading is not great for Ruby or Python either, because they use green threads - but Perl has problems bigger than that with it's threading.
- berntb 16y ago
  So your complaint is really that you have to install stuff to get better defaults in Perl? :-) Sorry, but that is hard to take seriously. >>I shouldn't have to explicity declare a variable lexically scoped Are you saying you don't like strict? Without that, you're fscked if you spell a variable name wrong in the same way, twice... (I really don't get that not all scripting languages have strict.) I've avoided threading in scripting languages as the plague, but I tend to agree with you as far as I've read. :-)
  - grammaton 16y ago
    > So your complaint is really that you have to install stuff to get better defaults in Perl? :-) No, my point is that if you compare it to another programming language simply as a language, it is basically missing a major feature. If you take Ruby, Python, and Perl, and line them up next to each other simply as languages, Perl is at the bottom of the pile on it's own merits where OOP is concerned. > Are you saying you don't like strict? Even if I use strict, good software development practice would dictate using a lexically scoped variable at all times unless I really need something else. That's one of the reasons lexical scoping is the default in so many languages at this point.

rjbond3rd 16y ago

> ...it's Object Oriented programming that is a bad joke... Disclaimer: I have used a great deal of both Perl and Ruby. Evidently not everyone has kept up with Moose (released back in 2007, part of the Perl renaissance, can be learned in a few minutes.)

grammaton 16y ago
Not part of the core language, is an add on. Nice trick, but Perl - that is to say, the language itself - still has pretty crappy OOP. Or has Moose been adopted as a core part of the language now?
- Vivtek 16y ago
  Really, with Perl the distinction "part of the core language" is meaningless. You can install a CPAN bundle for a hardcore Perl in one shell command, or get it all preinstalled. Strawberry Perl for Windows has all the good stuff in a single installer, for instance, and if you're on Unix you've similarly got no excuse. Really. "Core language" is kind of twentieth. Moose is very well-established in the Perl community. That's as core as it gets.
- chromatic 16y ago
  Not part of the core language, is an add on. So is DBI, Perl::Critic, cpanminus, perlbrew, Dist::Zilla, Perltidy, and (depending on your version) autodie. That's why my definition of a great Perl programmer includes pervasive use of the CPAN--you're restricting yourself unnecessarily if you avoid it.
  - grammaton 16y ago
    Quite correct, and it's almost axiomatic at this point that CPAN is Perl's killer app. That said, I wasn't referring to great programmers - I was referring to the language itself. I'm not sure I understand why basically having to patch your language to get a feature that others have out of the box is not seen as a weakness of that language. Now, we can talk about Perl + CPAN and all the jazz you find therein, but that's a different discussion. My point is, taken by itself, the language Perl does not have an especially good Object system, especially if you consider Ruby and Python the competition. "So is DBI, Perl::Critic..." What's your point? Database bindings and lint like code checking are not features every developer - or even a good chunk of the developers out there - are going to need, or have use for. By that logic I could point out that Perl still wins no points because Ruby and Python - and just about every other contender out there - has their own equivalents. I'm not referring to CPAN or the the gobs of stuff in it - I'm referring to the language itself And while we're on CPAN, much of the popular and useful material in CPAN has equivalents in Ruby and Python that are every bit as mature and useful.