7 ms·

I am a Perl user and I do like it very much (warts and all). This article reminded me of another self-deprecatory Perl article: http://ebb.org/bkuhn/blog/2012

by Surio 13y ago

I am a Perl user and I do like it very much (warts and all). This article reminded me of another self-deprecatory Perl article: http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html And yes, as the article says, Here's to 26 more! :-)

lmm 13y ago
That's an interesting article but seems to be missing the actual why of it. He still likes perl because... culture? Some people are still writing software in perl or cobol, sure - and some of that is good software that solves real problems. But the reason we think of the average programmer in one of these obsolete languages as "some sort of second-class technology citizen" is that, well, they are. Compared to the rest of us they spend more time working around language deficiencies, inadequate tooling and all the rest of it, and less time making interesting things. Right now I'm a huge Scala fan. I've had that experience of feeling that I never want to program in any other language again (and every other language I've gone to, even those I used to like, feels clumsy and tedious by comparison). But I hope that in 25 years' time I'll have moved on to something even better. Language design isn't done, and languages are getting better all the time.
- mxey 13y ago
  I spend less time “working around language deficiencies, inadequate tooling and all the rest of it” in Perl than in, for example, Python.
  - lmm 13y ago
    Interesting. What does Python make harder? In Perl I find myself missing list comprehensions, shared-by-default threading, a well-integrated object system, and a comprehensive, integrated, popular web framework. (Also a standard way of doing event-driven programming, but that's a fair criticism of Python too). And while I'm sure the tooling functionality is there, everything just seems less obvious and standard (e.g. where's the virtualenv equivalent?)
    - berntb 13y ago
      You really prefer Python threading to anything?! You haven't found any of the major Perl web frameworks? You haven't seen Moose for OO? perlbrew? (Don't get me started on list comprehension, extra stuff to learn because Python lack real maps with real lambdas.) And so on... Do you always have opinions on stuff you have no clue about?! Start with getting the Modern Perl book and read it (free pdf). Ask (/search) on Perlmonks.
      - lmm 13y ago
        > You really prefer Python threading to anything?! Sure. When I just want "run this task in the background, I don't particularly care about throughput but don't block entirely". There's a niche where a proper task queue is too heavy and shared variables are a perfectly adequate communication mechanism. > Don't get me started on list comprehension, extra stuff to learn because Python lack real maps with real lambdas. They're a nicer abstraction for many purposes. Look at their Haskell origin, or Scala for/yield.
        berntb 13y ago
        For stuff so trivial that even the GIL is no problem, most any utility should work... (You don't seem to know that Perls are usually not compiled with threading support?) It just isn't interesting to talk about. I argued that list comprehension's use cases are generally solved better with "real" lambdas + map (==> less to learn). To note that most every feature have some use case they are extra good for is not relevant. But again -- why do you discuss subjects you obviously don't know? Ask instead.
        kbenson 13y ago
        You don't seem to know that Perls are usually not compiled with threading support? I've heard this a few times now, and find it interesting. I guess people that compile their own do it without threading support, but I would guess the majority of Perl interpreters out there were bundled from some third party (usually the distro), and those almost always have threading enabled. Also, that's a good thing. I've made quite heavy use of threads over the years and find Perl's abstraction of OS threads is actually quite nice to use, as long as you play to their strengths. I.e. pre-create your threads, and thread them like pthreads with easier IPC. If you want "green" threads, use any of the numerous packages that provide it.
- virtualsue 13y ago
  I run into many Scala fans amongst Java developers. It's the current shiny thing in that technology area. Good old Java (of a similar age to Perl) is usually what they're making their living doing...
  - lmm 13y ago
    Sucks to be them; I'm fortunate enough to do Scala professionally. I think "shiny" is unnecessarily dismissive; the productivity and safety advantages are real enough.
  - stevan_little 13y ago
    Actually Perl 5 is older then Java by about a year (yes, Perl had OO support before Java even left the lab). But Perl itself is much older then Java, by several years.
- amerika_blog 13y ago
  The Perl culture is very much "Wild West" meets the race to space. It's a language for people who are comfortable enough around theory that they don't need syntax to force them to use it. At the same time, it's highly evolutionary -- it supports the fastest, dirtiest, hackinest method of getting to the goal -- and thus has prototyping built in to production. I often write Perl scripts twice. The first is a tape-up job to "git 'er done" and the second is a more elegant and architected approached. This method matches the configuration of most jobs. The client doesn't (fully) know what they want. Last-minute, world-bending exceptions arise. Well-intentioned schemes gang aft agley. With this prototyping-production, I'm able to get something up and working, and can fix it later if the client has foresight. Theory is great. I am the first to defend theory. But if it doesn't correspond to application, there's another word for it: arbitrary. (You may note the difference between two predominant value systems illustrated in that sentence.)
  - berntb 13y ago
    I had similar experience when I started Perl. I was used to take a problem of a certain size, sit down and think for a while. Then code C for maybe 3 to 10 days. When I did a similar problem in Perl, the time to think for a problem of that size was longer than the time to throw a solution at the wall! You could design using code, then refactor/rewrite if it got too bad. Best of all: So much more fun.
- cafard 13y ago
  I guess I would need to know who "the rest of us" and the "interesting things" are.
- liveoneggs 13y ago
  wow. You're an unbelievable ass and, obviously, immature/inexperienced to boot.
- eCa 13y ago
  > Language design isn't done, and languages are getting better all the time. That is actually what Perl is doing. With its loose original design it can evolve amazingly, and in ways that couldn't be foreseen.

by Surio 13y ago

lmm 13y ago

That's an interesting article but seems to be missing the actual why of it. He still likes perl because... culture? Some people are still writing software in perl or cobol, sure - and some of that is good software that solves real problems. But the reason we think of the average programmer in one of these obsolete languages as "some sort of second-class technology citizen" is that, well, they are. Compared to the rest of us they spend more time working around language deficiencies, inadequate tooling and all the rest of it, and less time making interesting things. Right now I'm a huge Scala fan. I've had that experience of feeling that I never want to program in any other language again (and every other language I've gone to, even those I used to like, feels clumsy and tedious by comparison). But I hope that in 25 years' time I'll have moved on to something even better. Language design isn't done, and languages are getting better all the time.

mxey 13y ago
I spend less time “working around language deficiencies, inadequate tooling and all the rest of it” in Perl than in, for example, Python.
- lmm 13y ago
  Interesting. What does Python make harder? In Perl I find myself missing list comprehensions, shared-by-default threading, a well-integrated object system, and a comprehensive, integrated, popular web framework. (Also a standard way of doing event-driven programming, but that's a fair criticism of Python too). And while I'm sure the tooling functionality is there, everything just seems less obvious and standard (e.g. where's the virtualenv equivalent?)
  - berntb 13y ago
    You really prefer Python threading to anything?! You haven't found any of the major Perl web frameworks? You haven't seen Moose for OO? perlbrew? (Don't get me started on list comprehension, extra stuff to learn because Python lack real maps with real lambdas.) And so on... Do you always have opinions on stuff you have no clue about?! Start with getting the Modern Perl book and read it (free pdf). Ask (/search) on Perlmonks.
    - lmm 13y ago
      > You really prefer Python threading to anything?! Sure. When I just want "run this task in the background, I don't particularly care about throughput but don't block entirely". There's a niche where a proper task queue is too heavy and shared variables are a perfectly adequate communication mechanism. > Don't get me started on list comprehension, extra stuff to learn because Python lack real maps with real lambdas. They're a nicer abstraction for many purposes. Look at their Haskell origin, or Scala for/yield.
      - berntb 13y ago
        For stuff so trivial that even the GIL is no problem, most any utility should work... (You don't seem to know that Perls are usually not compiled with threading support?) It just isn't interesting to talk about. I argued that list comprehension's use cases are generally solved better with "real" lambdas + map (==> less to learn). To note that most every feature have some use case they are extra good for is not relevant. But again -- why do you discuss subjects you obviously don't know? Ask instead.
        kbenson 13y ago
        You don't seem to know that Perls are usually not compiled with threading support? I've heard this a few times now, and find it interesting. I guess people that compile their own do it without threading support, but I would guess the majority of Perl interpreters out there were bundled from some third party (usually the distro), and those almost always have threading enabled. Also, that's a good thing. I've made quite heavy use of threads over the years and find Perl's abstraction of OS threads is actually quite nice to use, as long as you play to their strengths. I.e. pre-create your threads, and thread them like pthreads with easier IPC. If you want "green" threads, use any of the numerous packages that provide it.
virtualsue 13y ago
I run into many Scala fans amongst Java developers. It's the current shiny thing in that technology area. Good old Java (of a similar age to Perl) is usually what they're making their living doing...
- lmm 13y ago
  Sucks to be them; I'm fortunate enough to do Scala professionally. I think "shiny" is unnecessarily dismissive; the productivity and safety advantages are real enough.
- stevan_little 13y ago
  Actually Perl 5 is older then Java by about a year (yes, Perl had OO support before Java even left the lab). But Perl itself is much older then Java, by several years.
amerika_blog 13y ago
The Perl culture is very much "Wild West" meets the race to space. It's a language for people who are comfortable enough around theory that they don't need syntax to force them to use it. At the same time, it's highly evolutionary -- it supports the fastest, dirtiest, hackinest method of getting to the goal -- and thus has prototyping built in to production. I often write Perl scripts twice. The first is a tape-up job to "git 'er done" and the second is a more elegant and architected approached. This method matches the configuration of most jobs. The client doesn't (fully) know what they want. Last-minute, world-bending exceptions arise. Well-intentioned schemes gang aft agley. With this prototyping-production, I'm able to get something up and working, and can fix it later if the client has foresight. Theory is great. I am the first to defend theory. But if it doesn't correspond to application, there's another word for it: arbitrary. (You may note the difference between two predominant value systems illustrated in that sentence.)
- berntb 13y ago
  I had similar experience when I started Perl. I was used to take a problem of a certain size, sit down and think for a while. Then code C for maybe 3 to 10 days. When I did a similar problem in Perl, the time to think for a problem of that size was longer than the time to throw a solution at the wall! You could design using code, then refactor/rewrite if it got too bad. Best of all: So much more fun.
cafard 13y ago
I guess I would need to know who "the rest of us" and the "interesting things" are.
liveoneggs 13y ago
wow. You're an unbelievable ass and, obviously, immature/inexperienced to boot.
eCa 13y ago
> Language design isn't done, and languages are getting better all the time. That is actually what Perl is doing. With its loose original design it can evolve amazingly, and in ways that couldn't be foreseen.