5 ms·

I was about to note that the OP clearly hasn't used Clojure if he uses it as a negative example in terms of reliability, but then I remembered — I promised myse

by jwr 14y ago

I was about to note that the OP clearly hasn't used Clojure if he uses it as a negative example in terms of reliability, but then I remembered — I promised myself not to get too deeply into these kinds of silly discussions. So, dear OP, good luck writing your large-scale multithreaded high-performance distributed applications using Perl. And BTW, I do use Perl quite a bit and I really like it, for certain tasks. But I'd never make these kinds of comparisons.

regularfry 14y ago
That's not a comparison he makes.
adrianhoward 14y ago
I was about to note that the OP clearly hasn't used Clojure if he uses it as a negative example in terms of reliability, but then I remembered — I promised myself not to get too deeply into these kinds of silly discussions. Erm... He didn't? He said: "While so much of the shiny-chasing buzz in the micro-ISV startup built-it-and-they-will-fund world seems to chase Clojure and Node.js and app-in-a-page tricks, Perl 5 continues to be my workhorse." No comment on the reliability (or otherwise) of Clojure. And much as I love Clojure - there's an element of truth there. Lots of folk using it because it's the new-and-shiny rather than it being necessarily the best solution. I know I've binned some Clojure stuff that would have been fun for me - because adding the JVM to the mix in production wouldn't have helped us actually get stuff done. (and while it's an unfair comparison - since it's a vastly younger language - the transition to 1.3 wasn't fun for many folk :-)
- jshen 14y ago
  "Lots of folk using it because it's the new-and-shiny rather than it being necessarily the best solution" How do you know what is in people's head? I assert that lots of folk are using perl because it's comfortable to them rather than it being the best solution.
  - kamaal 14y ago
    The difference between computer science and software engineering is Software engineering is real work for the real world. Often the constraints are money, time, resources. So demands of a software project in the real world are very different than the academia. Although you can argue that Lisp is far more a better language than Perl, based on some parameters you wish to evaluate. Others might have totally different parameters, for example in terms of mere usability and pace of getting things done, Perl will fare better than Lisp. While evaluating two technologies it is really important to define the parameters you wish to evaluate them upon. Without that we are just comparing Apples and Oranges and then arguing that nutrition on one isn't better than the other. Unless we define who needs an Apple and who needs an Orange for what reasons, we won't be able to say which is better than what for what purposes. There fore comfort is really a subjective term. For a professor sitting in a university with endless time at his disposal Lisp will make the perfect and most comfortable language. But me sitting on P1 ticket assigned to me, and given 45 minutes to provide with solution has no other option but to use Perl. In other news I just have a weekend to hack up a automation or produce a quick prototype. You know what language I'm going to use, Its Perl. Not because I hate Lisp or I'm uncomfortable. Its just there is no other option.
    - hkolek 14y ago
      You said it yourself, comfort is a subjective term. So why do you talk as if Lisp were objectively more complicated. If I'm familiar with Lisp but have no clue about Perl I don't need to be a university professor with endless time to choose Lisp over Perl every time. To me, Perl looks vastly more complicated than Lisp. I believe you'd find that if you'd know Lisp like you do Perl you'd be at least as productive as you're in Perl.
      - adrianhoward 14y ago
        To me, Perl looks vastly more complicated than Lisp. I believe you'd find that if you'd know Lisp like you do Perl you'd be at least as productive as you're in Perl. As somebody who loves both Lisp and Perl I'd probably say you'd be as productive (unless you were sitting in a domain that one language or the other was a better fit for). Well - apart from CPAN and the testing infrastructure. And the editor/IDE support is worse unless you're already an emacs person... but those are just coz Clojure is young. I'm thoroughly sick of the Lisp == academic == hard myth. It's just nonsense. I've taught newbie devs Lisp and Perl in the past and both groups seem to take it on at about the same pace.
fffggg 14y ago
Others have noted that your reply is a non-sequitur. However, I'd like to address it anyway, specifically the "luck" part. I have written all of what you describe: large-scale multithreaded high-performance distributed applications using Perl. When necessary I have written perlXS bindings to C routines, but this is surprisingly infrequent. Most high performance system interfaces are exposed to Perl in an efficient manner. I've had Perl processes with tens of gigs memory resident. I have written non-blocking state machines in Perl which serviced (or served) over 100k connections in parallel. Which have run on over 100k machines at once. I have worked on huge modular, multi-team undertakings in Perl. The single caveat is that separate processes and explicitly shared memory is the parallelism tool of choice with Perl. Luck wasn't a part of any of this. Perl will scale quite well, and if you think it doesn't you likely have a few things to learn about what the language/platform can do.
- gizzlon 14y ago
  Just curious: what did you use for IPC at this scale?
  - fffggg 14y ago
    I'm describing about a dozen separate projects above. For same-system fast IPC I often used an in-house library (with Perl bindings) which implemented a memory mapped, sharable hash table. Unfortunately it hasn't been released as open source. The closest similar project might be http://fallabs.com/kyotocabinet/ http://fallabs.com/kyotocabinet/ however it's inferior in a few important ways.
smueller 14y ago
FWIW, my team has both written large-scale and high-performance distributed applications using Perl. In fact, we've even done it mostly IN Perl with just tiny bits of C sprinkled here and there. Runs on millions worth of relatively commodity hardware in several data centers across the globe. The only threading going on is at the C level, though. Your point about these comparisons being dubious (paraphrasing) is perfectly valid, by the way.

by jwr 14y ago

I was about to note that the OP clearly hasn't used Clojure if he uses it as a negative example in terms of reliability, but then I remembered — I promised myself not to get too deeply into these kinds of silly discussions. So, dear OP, good luck writing your large-scale multithreaded high-performance distributed applications using Perl. And BTW, I do use Perl quite a bit and I really like it, for certain tasks. But I'd never make these kinds of comparisons.

regularfry 14y ago

That's not a comparison he makes.

adrianhoward 14y ago

I was about to note that the OP clearly hasn't used Clojure if he uses it as a negative example in terms of reliability, but then I remembered — I promised myself not to get too deeply into these kinds of silly discussions. Erm... He didn't? He said: "While so much of the shiny-chasing buzz in the micro-ISV startup built-it-and-they-will-fund world seems to chase Clojure and Node.js and app-in-a-page tricks, Perl 5 continues to be my workhorse." No comment on the reliability (or otherwise) of Clojure. And much as I love Clojure - there's an element of truth there. Lots of folk using it because it's the new-and-shiny rather than it being necessarily the best solution. I know I've binned some Clojure stuff that would have been fun for me - because adding the JVM to the mix in production wouldn't have helped us actually get stuff done. (and while it's an unfair comparison - since it's a vastly younger language - the transition to 1.3 wasn't fun for many folk :-)

jshen 14y ago
"Lots of folk using it because it's the new-and-shiny rather than it being necessarily the best solution" How do you know what is in people's head? I assert that lots of folk are using perl because it's comfortable to them rather than it being the best solution.
- kamaal 14y ago
  The difference between computer science and software engineering is Software engineering is real work for the real world. Often the constraints are money, time, resources. So demands of a software project in the real world are very different than the academia. Although you can argue that Lisp is far more a better language than Perl, based on some parameters you wish to evaluate. Others might have totally different parameters, for example in terms of mere usability and pace of getting things done, Perl will fare better than Lisp. While evaluating two technologies it is really important to define the parameters you wish to evaluate them upon. Without that we are just comparing Apples and Oranges and then arguing that nutrition on one isn't better than the other. Unless we define who needs an Apple and who needs an Orange for what reasons, we won't be able to say which is better than what for what purposes. There fore comfort is really a subjective term. For a professor sitting in a university with endless time at his disposal Lisp will make the perfect and most comfortable language. But me sitting on P1 ticket assigned to me, and given 45 minutes to provide with solution has no other option but to use Perl. In other news I just have a weekend to hack up a automation or produce a quick prototype. You know what language I'm going to use, Its Perl. Not because I hate Lisp or I'm uncomfortable. Its just there is no other option.
  - hkolek 14y ago
    You said it yourself, comfort is a subjective term. So why do you talk as if Lisp were objectively more complicated. If I'm familiar with Lisp but have no clue about Perl I don't need to be a university professor with endless time to choose Lisp over Perl every time. To me, Perl looks vastly more complicated than Lisp. I believe you'd find that if you'd know Lisp like you do Perl you'd be at least as productive as you're in Perl.
    - adrianhoward 14y ago
      To me, Perl looks vastly more complicated than Lisp. I believe you'd find that if you'd know Lisp like you do Perl you'd be at least as productive as you're in Perl. As somebody who loves both Lisp and Perl I'd probably say you'd be as productive (unless you were sitting in a domain that one language or the other was a better fit for). Well - apart from CPAN and the testing infrastructure. And the editor/IDE support is worse unless you're already an emacs person... but those are just coz Clojure is young. I'm thoroughly sick of the Lisp == academic == hard myth. It's just nonsense. I've taught newbie devs Lisp and Perl in the past and both groups seem to take it on at about the same pace.

fffggg 14y ago

Others have noted that your reply is a non-sequitur. However, I'd like to address it anyway, specifically the "luck" part. I have written all of what you describe: large-scale multithreaded high-performance distributed applications using Perl. When necessary I have written perlXS bindings to C routines, but this is surprisingly infrequent. Most high performance system interfaces are exposed to Perl in an efficient manner. I've had Perl processes with tens of gigs memory resident. I have written non-blocking state machines in Perl which serviced (or served) over 100k connections in parallel. Which have run on over 100k machines at once. I have worked on huge modular, multi-team undertakings in Perl. The single caveat is that separate processes and explicitly shared memory is the parallelism tool of choice with Perl. Luck wasn't a part of any of this. Perl will scale quite well, and if you think it doesn't you likely have a few things to learn about what the language/platform can do.

gizzlon 14y ago
Just curious: what did you use for IPC at this scale?
- fffggg 14y ago
  I'm describing about a dozen separate projects above. For same-system fast IPC I often used an in-house library (with Perl bindings) which implemented a memory mapped, sharable hash table. Unfortunately it hasn't been released as open source. The closest similar project might be http://fallabs.com/kyotocabinet/ http://fallabs.com/kyotocabinet/ however it's inferior in a few important ways.

smueller 14y ago

FWIW, my team has both written large-scale and high-performance distributed applications using Perl. In fact, we've even done it mostly IN Perl with just tiny bits of C sprinkled here and there. Runs on millions worth of relatively commodity hardware in several data centers across the globe. The only threading going on is at the C level, though. Your point about these comparisons being dubious (paraphrasing) is perfectly valid, by the way.