4 ms·

I spend less time “working around language deficiencies, inadequate tooling and all the rest of it” in Perl than in, for example, Python.

by mxey 13y ago

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.
  - nailer 13y ago
    > You really prefer Python threading to anything?! The Python 'process' and 'queue' modules rock (yes, multiple single threaded processes still counts as multithreading). I've had apps on the front page of HN / Smashing Mag using them, happily taking advantage of a multicore server. I swear half the people who bitch about the GIL have never used either of these modules (not you, people in general).
    - berntb 13y ago
      I answered a comment re threading, not different multi process implementations. (All the popular scripting languages have bad threading support and try to do everything with multiple processes, afaik. It should be possible to add good support, but I guess it isn't really worth it?)
      - nailer 13y ago
        > I answered a comment re threading, not different multi process implementations. I'd argue single process multiple threads, vs multiple process single thread, vs not blocking, are different solutions to the same problem: how do I take advantage of multiple cores? Saying other solutions don't apply, despite solving the problem, is a bit arbitrary.
        Mithaldu 13y ago
        As long as multi-processes can't share variables, nevermind complex data structures made of variables, they don't apply to the problem multi-threading solves.
        nailer 13y ago
        shrug The queue module takes complex data structures, provides them to processes, which when finished doing whatever they do, send them back to other queues and in turn more processes. It works, complex data structures are being shared. There's no nightmarish locking issues. Not sure what else you want. Are you entirely sure you're not discounting the solution because It's Not What Java Does?
- mxey 13y ago
  In Python I miss a switch statement, anonymous functions longer than a single line, and an object system with the power of Moose. I don't think shared-by-default threading is a good idea, and Python's GIL makes it close to pointless. I also miss a web framework like Django or Rails in Perl. I never liked Catalyst, but have not spent much time with it. I cannot judge if the tooling is less obvious, but think the tools are better, especially in regard to testing. There is a virtualenv equivalent called local::lib, but I recommend the bundler equivalent called carton ;-)
  - hammondos 13y ago
    If you like Django/Rails I'd suggest you check out Perl's Mojolicious - very modern Perl web framework. There's also Dancer - both seem much easier to use & set up than Catalyst
    - mxey 13y ago
      Dancer or Mojolicious are more like Sinatra or Flask, not like Rails or Django
      - arunix 13y ago
        Indeed. Perl does have Jifty and Gantry which do have out of the box support for the M part of MVC, but for whatever reasons they never became as popular as Django/Rails.
        hernan604 13y ago
        With perl I always include the M inside my application class/module. And I use only VC from the web framework. That way, i get thin controllers only for url mapping which in that case will access my application class/module instance. Thats where the real code will be, in my application and not-in-the-web-framework. With this environment its easy to switch and test other web frameworks avaliable because i will only need to create the thin controllers and re-use my templates. Plus, when i need a cronjob, i use my application without the VC. In the end the real deal is: dont tie your application with webframeworks. Always use the M inside the application and from the web framework use VC only with thin controllers. Put the real code inside the aplication. Make the framework use the application. Dont make the framework your application. follow me @ https://github.com/hernan604 https://github.com/hernan604
- eCa 13y ago
  There will most likely never be an integrated web framework [0] or a standard way of event-driven programming. There's more than one way. I think Perlbrew [1] is closest to virtualenv. [0] But there is Mojolicious, Dancer, Catalyst, etc [1] http://perlbrew.pl/ http://perlbrew.pl/
  - __david__ 13y ago
    I've been liking plenv [1] better than perlbrew. plenv + carton [2] is very nice (comparable to ruby's rbenv and bundler). [1] https://github.com/tokuhirom/plenv https://github.com/tokuhirom/plenv [2] http://search.cpan.org/perldoc?Carton http://search.cpan.org/perldoc?Carton

I spend less time “working around language deficiencies, inadequate tooling and all the rest of it” in Perl than in, for example, Python.

by 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.
- nailer 13y ago
  > You really prefer Python threading to anything?! The Python 'process' and 'queue' modules rock (yes, multiple single threaded processes still counts as multithreading). I've had apps on the front page of HN / Smashing Mag using them, happily taking advantage of a multicore server. I swear half the people who bitch about the GIL have never used either of these modules (not you, people in general).
  - berntb 13y ago
    I answered a comment re threading, not different multi process implementations. (All the popular scripting languages have bad threading support and try to do everything with multiple processes, afaik. It should be possible to add good support, but I guess it isn't really worth it?)
    - nailer 13y ago
      > I answered a comment re threading, not different multi process implementations. I'd argue single process multiple threads, vs multiple process single thread, vs not blocking, are different solutions to the same problem: how do I take advantage of multiple cores? Saying other solutions don't apply, despite solving the problem, is a bit arbitrary.
      - Mithaldu 13y ago
        As long as multi-processes can't share variables, nevermind complex data structures made of variables, they don't apply to the problem multi-threading solves.
        nailer 13y ago
        shrug The queue module takes complex data structures, provides them to processes, which when finished doing whatever they do, send them back to other queues and in turn more processes. It works, complex data structures are being shared. There's no nightmarish locking issues. Not sure what else you want. Are you entirely sure you're not discounting the solution because It's Not What Java Does?
mxey 13y ago
In Python I miss a switch statement, anonymous functions longer than a single line, and an object system with the power of Moose. I don't think shared-by-default threading is a good idea, and Python's GIL makes it close to pointless. I also miss a web framework like Django or Rails in Perl. I never liked Catalyst, but have not spent much time with it. I cannot judge if the tooling is less obvious, but think the tools are better, especially in regard to testing. There is a virtualenv equivalent called local::lib, but I recommend the bundler equivalent called carton ;-)
- hammondos 13y ago
  If you like Django/Rails I'd suggest you check out Perl's Mojolicious - very modern Perl web framework. There's also Dancer - both seem much easier to use & set up than Catalyst
  - mxey 13y ago
    Dancer or Mojolicious are more like Sinatra or Flask, not like Rails or Django
    - arunix 13y ago
      Indeed. Perl does have Jifty and Gantry which do have out of the box support for the M part of MVC, but for whatever reasons they never became as popular as Django/Rails.
      - hernan604 13y ago
        With perl I always include the M inside my application class/module. And I use only VC from the web framework. That way, i get thin controllers only for url mapping which in that case will access my application class/module instance. Thats where the real code will be, in my application and not-in-the-web-framework. With this environment its easy to switch and test other web frameworks avaliable because i will only need to create the thin controllers and re-use my templates. Plus, when i need a cronjob, i use my application without the VC. In the end the real deal is: dont tie your application with webframeworks. Always use the M inside the application and from the web framework use VC only with thin controllers. Put the real code inside the aplication. Make the framework use the application. Dont make the framework your application. follow me @ https://github.com/hernan604 https://github.com/hernan604
eCa 13y ago
There will most likely never be an integrated web framework [0] or a standard way of event-driven programming. There's more than one way. I think Perlbrew [1] is closest to virtualenv. [0] But there is Mojolicious, Dancer, Catalyst, etc [1] http://perlbrew.pl/ http://perlbrew.pl/
- __david__ 13y ago
  I've been liking plenv [1] better than perlbrew. plenv + carton [2] is very nice (comparable to ruby's rbenv and bundler). [1] https://github.com/tokuhirom/plenv https://github.com/tokuhirom/plenv [2] http://search.cpan.org/perldoc?Carton http://search.cpan.org/perldoc?Carton