5 ms·

How many new initiatives use Perl though? There's a lot of legacy code in that list.

brunov 17y ago
- http://www.takkle.com/college_recruiting/athletes http://www.takkle.com/college_recruiting/athletes - http://duckduckgo.com/ http://duckduckgo.com/ - http://www.yellowbot.com/ http://www.yellowbot.com/ - http://osx.iusethis.com/ http://osx.iusethis.com/ - http://www.thumb-rate.com/ http://www.thumb-rate.com/ - http://hiveminder.com/splash/ http://hiveminder.com/splash/ many more here: http://www.catalystsites.org/ http://www.catalystsites.org/
jrockway 17y ago
Perl is what I use for my new initiatives, and it's a choice I've made through careful consideration of many alternatives. Perl has the right "balance" of languages features for web applications. Some options I've tried and what I didn't like: Haskell is much faster and a better language in general, but just doesn't have enough usable libraries for writing web applications. (My first Haskell web application was an application that generated an image of the latest Twitter post from a user using a given hashtag. It went together quickly enough, but I didn't really feel like "wow, this was a great web development experience that has changed my life". I do feel that way about Haskell for text processing and system programming, ironically. It definitely beats Perl there. But for simple and complex web applications, Perl is much better.) CL has the best development tools of any language, so I really wanted to like it, but it doesn't really have a coherent community. I started writing a web application in CL to allow clients to email us files, even when they were behind a firewall that blocked outgoing email and ftp (!). This didn't go too well; I really didn't like cl-who or html-template, and there were no other options. (People in #lisp agreed with me, but their advice was to "just write my own". The answer to every question about libraries on #lisp is "just write your own".) I started porting Template::Refine from Perl to CL (see template-refine and cl-template-refine on my github), so I could generate HTML. closure-xml and cl-stp are great XML libraries, BTW. The next thing I wanted was a dependency-injection framework. There were no libraries for that, so I had to "just write my own". cl-junkie is on my github (junkie, "dependency injection", get it?), but I got bored and didn't finish it. I ended up not needing the app anyway. Too much yak-shaving lets you get over the excitement of your actual idea, and leads to it never being done. With Perl I can get a working application before I am not excited anymore. (Then I get excited about cleaning up the libraries, and do that afterwards. Bootstrapping++) Moving along, there is Scala and Clojure. Scala is a fine langauge, it really "gets" functional programming. Clojure is not to my liking. (And it's not the parentheses; I have a shit-ton of "production" Emacs Lisp lying around.) These languages are both cases of the "oh, just write your own libraries" community problem. Even worse is the potential to reuse Java libraries. I don't see the point of using a nice functional language with overly-verbose libraries that are going to randomly throw NullPointerExceptions. Many other problems I have with Java carry over to Scala and Clojure if you use Java libraries. (Design pattern overload, extremely poor object system, no types that cannot be null, etc.) (I know I said "bootstrapping++" above, and that you can bootstrap clean Scala/Clojure libraries off the messy Java ones. But it's just too painful for me. It's not boring, it's just pure pain.) I use Scala for Android applications simply because there is absolutely no other option. (I couldn't get any Clojure code to compile, and I am certainly not going to use plain Java. I prefer Scala to both anyway, but obviously I would prefer various non-JVM languages to those.) So then there are Ruby and Python. Both are basically Perl with very tiny superficial differences, so there is no reason to waste my time becoming good at those. (Similarly, if you are a Ruby guru, you will probably not be too excited to switch to Perl. Same language, except you aren't a guru anymore.) I think Perl's libraries are, in general, more extensive and more mature than Python or Ruby's. But for the beaten path, you will do fine with any. Ruby has this "Rails" thing that I hear is pretty popular. One thing I've noticed, though, is that the Perl community is better at stealing from Ruby and Python than those communities are at stealing from us. DBIx::Class is significantly more advanced than any Python or Ruby ORM that I know of, KiokuDB is the only sane object database among those three languages, etc., etc. But Ruby and Python still don't have anything close. OTOH, Python's WSGI and Ruby's Rack are great ideas... so the Perl community now has PSGI and Plack. So you can see why I find it compelling to stick with Perl. Good ideas eventually migrate over here, and the community supports them. Anyway, if I had a point, it's that there is no reason to disqualify Perl from "what should I write my new app in" discussions, except ignorance. Perl has its tradeoffs, but so does anything else available. (Don't let "I last used Perl in 1995, so Perl must still be the same as it was in 1995," ruin your next application development project!)
- DanielStraight 17y ago
  Ruby and Python are basically Perl with superficial differences? How in the world did you come to that conclusion? I don't think I have ever seen anyone make that argument before.
  - jrockway 17y ago
    I can only explain in terms of an experiment: Write an algorithm (or app) in your favorite language of the three. Then port it to a different one of those three. Now port to Common Lisp or Haskell, and see how your code feels different. I find that Ruby/Python/Perl basically let you write the same program with different syntax. "$self->foo" instead of "@foo". I find that Haskell changes the way you actually program. Example: Nobody (except me) uses a type like Haskell's Error monad in Perl; they use exceptions. (Similarly, look for a "web framework" in Perl/Python/Ruby. Perl has Catalyst. Python has Django. Ruby has Rails. They are all different, true, but the idea is the same. If three people each started the same project on those various frameworks, the end result, code-wise, would be very similar.)
    - btilly 17y ago
      While you will have that experience with a lot of code, there are some concepts that don't translate so easily. As an experiment port this Ruby to Perl: def each (arg,*more_args) ( [] != more_args ) ? arg.each {|l| each(*more_args) {|r| yield [l]+ r }} : arg.each { |r| yield [r] } end each( 1..2, 'a'..'c', 'A'..'D') { |args| puts args.join " " } Then port this Python to Perl: def fib(): fn2 = 1 fn1 = 1 while True: (fn1, fn2, oldfn2) = (fn1+fn2, fn1, fn2) yield oldfn2 g = fib() for i in range(20): print i, g.next() See what I mean?
      - jrockway 17y ago
        Some people refer to carbonated sugary beverages as "soda" and others say "pop", but both are still speaking the same language.
SwellJoe 17y ago
We had the "What language?" talk when we started work on Cloudmin, as well as when we began planning some web services. Perl ended up on top in both cases. Admittedly, we have a historic codebase of several hundred thousand lines of Perl, but we've both worked in Python at least as much as Perl in the past several years and there is a version of our API in Python that we could have started from. We weren't forced to choose Perl for legacy reasons, but we chose it, anyway. We're pretty much agnostic about languages; we prefer dynamic languages, but not much beyond that. Our website is running on Drupal and several custom modules in PHP. We'll be adding those afore-mentioned web services via frontend PHP code, but the backend will be Perl. Haskell might make an appearance at some point in the future for concurrency work where performance matters, but for now, Perl is plenty fast and has reasonable concurrency mechanisms for our needs. So, we're still cranking out tens of thousands of lines of Perl every year, and will be launching a couple of new products in the next six months also written in Perl. But, I will mention that our products directly and easily support PHP, Ruby on Rails and Django deployments, but not Catalyst. And it's because we're simply not hearing requests for Catalyst from paying customers. Maybe the Catalyst developers are more old-school and don't trust a control panel (even one written in Perl), or maybe there's a helluva a lot more PHP and a handful more Ruby on Rails and Django developers out there (note that PHP developers using our software outnumber RoR and Django developers to a degree that makes the latter two practically noise in the signal). So, realistically, I have to agree. Perl is a niche language for new developments, but then again, so are Python and Ruby.
bobbyi 17y ago
Youporn is a top 50 site and was started in 2006.

- http://www.takkle.com/college_recruiting/athletes http://www.takkle.com/college_recruiting/athletes - http://duckduckgo.com/ http://duckduckgo.com/ - http://www.yellowbot.com/ http://www.yellowbot.com/ - http://osx.iusethis.com/ http://osx.iusethis.com/ - http://www.thumb-rate.com/ http://www.thumb-rate.com/ - http://hiveminder.com/splash/ http://hiveminder.com/splash/ many more here: http://www.catalystsites.org/ http://www.catalystsites.org/

jrockway 17y ago

Perl is what I use for my new initiatives, and it's a choice I've made through careful consideration of many alternatives. Perl has the right "balance" of languages features for web applications. Some options I've tried and what I didn't like: Haskell is much faster and a better language in general, but just doesn't have enough usable libraries for writing web applications. (My first Haskell web application was an application that generated an image of the latest Twitter post from a user using a given hashtag. It went together quickly enough, but I didn't really feel like "wow, this was a great web development experience that has changed my life". I do feel that way about Haskell for text processing and system programming, ironically. It definitely beats Perl there. But for simple and complex web applications, Perl is much better.) CL has the best development tools of any language, so I really wanted to like it, but it doesn't really have a coherent community. I started writing a web application in CL to allow clients to email us files, even when they were behind a firewall that blocked outgoing email and ftp (!). This didn't go too well; I really didn't like cl-who or html-template, and there were no other options. (People in #lisp agreed with me, but their advice was to "just write my own". The answer to every question about libraries on #lisp is "just write your own".) I started porting Template::Refine from Perl to CL (see template-refine and cl-template-refine on my github), so I could generate HTML. closure-xml and cl-stp are great XML libraries, BTW. The next thing I wanted was a dependency-injection framework. There were no libraries for that, so I had to "just write my own". cl-junkie is on my github (junkie, "dependency injection", get it?), but I got bored and didn't finish it. I ended up not needing the app anyway. Too much yak-shaving lets you get over the excitement of your actual idea, and leads to it never being done. With Perl I can get a working application before I am not excited anymore. (Then I get excited about cleaning up the libraries, and do that afterwards. Bootstrapping++) Moving along, there is Scala and Clojure. Scala is a fine langauge, it really "gets" functional programming. Clojure is not to my liking. (And it's not the parentheses; I have a shit-ton of "production" Emacs Lisp lying around.) These languages are both cases of the "oh, just write your own libraries" community problem. Even worse is the potential to reuse Java libraries. I don't see the point of using a nice functional language with overly-verbose libraries that are going to randomly throw NullPointerExceptions. Many other problems I have with Java carry over to Scala and Clojure if you use Java libraries. (Design pattern overload, extremely poor object system, no types that cannot be null, etc.) (I know I said "bootstrapping++" above, and that you can bootstrap clean Scala/Clojure libraries off the messy Java ones. But it's just too painful for me. It's not boring, it's just pure pain.) I use Scala for Android applications simply because there is absolutely no other option. (I couldn't get any Clojure code to compile, and I am certainly not going to use plain Java. I prefer Scala to both anyway, but obviously I would prefer various non-JVM languages to those.) So then there are Ruby and Python. Both are basically Perl with very tiny superficial differences, so there is no reason to waste my time becoming good at those. (Similarly, if you are a Ruby guru, you will probably not be too excited to switch to Perl. Same language, except you aren't a guru anymore.) I think Perl's libraries are, in general, more extensive and more mature than Python or Ruby's. But for the beaten path, you will do fine with any. Ruby has this "Rails" thing that I hear is pretty popular. One thing I've noticed, though, is that the Perl community is better at stealing from Ruby and Python than those communities are at stealing from us. DBIx::Class is significantly more advanced than any Python or Ruby ORM that I know of, KiokuDB is the only sane object database among those three languages, etc., etc. But Ruby and Python still don't have anything close. OTOH, Python's WSGI and Ruby's Rack are great ideas... so the Perl community now has PSGI and Plack. So you can see why I find it compelling to stick with Perl. Good ideas eventually migrate over here, and the community supports them. Anyway, if I had a point, it's that there is no reason to disqualify Perl from "what should I write my new app in" discussions, except ignorance. Perl has its tradeoffs, but so does anything else available. (Don't let "I last used Perl in 1995, so Perl must still be the same as it was in 1995," ruin your next application development project!)

DanielStraight 17y ago
Ruby and Python are basically Perl with superficial differences? How in the world did you come to that conclusion? I don't think I have ever seen anyone make that argument before.
- jrockway 17y ago
  I can only explain in terms of an experiment: Write an algorithm (or app) in your favorite language of the three. Then port it to a different one of those three. Now port to Common Lisp or Haskell, and see how your code feels different. I find that Ruby/Python/Perl basically let you write the same program with different syntax. "$self->foo" instead of "@foo". I find that Haskell changes the way you actually program. Example: Nobody (except me) uses a type like Haskell's Error monad in Perl; they use exceptions. (Similarly, look for a "web framework" in Perl/Python/Ruby. Perl has Catalyst. Python has Django. Ruby has Rails. They are all different, true, but the idea is the same. If three people each started the same project on those various frameworks, the end result, code-wise, would be very similar.)
  - btilly 17y ago
    While you will have that experience with a lot of code, there are some concepts that don't translate so easily. As an experiment port this Ruby to Perl: def each (arg,*more_args) ( [] != more_args ) ? arg.each {|l| each(*more_args) {|r| yield [l]+ r }} : arg.each { |r| yield [r] } end each( 1..2, 'a'..'c', 'A'..'D') { |args| puts args.join " " } Then port this Python to Perl: def fib(): fn2 = 1 fn1 = 1 while True: (fn1, fn2, oldfn2) = (fn1+fn2, fn1, fn2) yield oldfn2 g = fib() for i in range(20): print i, g.next() See what I mean?
    - jrockway 17y ago
      Some people refer to carbonated sugary beverages as "soda" and others say "pop", but both are still speaking the same language.

SwellJoe 17y ago

We had the "What language?" talk when we started work on Cloudmin, as well as when we began planning some web services. Perl ended up on top in both cases. Admittedly, we have a historic codebase of several hundred thousand lines of Perl, but we've both worked in Python at least as much as Perl in the past several years and there is a version of our API in Python that we could have started from. We weren't forced to choose Perl for legacy reasons, but we chose it, anyway. We're pretty much agnostic about languages; we prefer dynamic languages, but not much beyond that. Our website is running on Drupal and several custom modules in PHP. We'll be adding those afore-mentioned web services via frontend PHP code, but the backend will be Perl. Haskell might make an appearance at some point in the future for concurrency work where performance matters, but for now, Perl is plenty fast and has reasonable concurrency mechanisms for our needs. So, we're still cranking out tens of thousands of lines of Perl every year, and will be launching a couple of new products in the next six months also written in Perl. But, I will mention that our products directly and easily support PHP, Ruby on Rails and Django deployments, but not Catalyst. And it's because we're simply not hearing requests for Catalyst from paying customers. Maybe the Catalyst developers are more old-school and don't trust a control panel (even one written in Perl), or maybe there's a helluva a lot more PHP and a handful more Ruby on Rails and Django developers out there (note that PHP developers using our software outnumber RoR and Django developers to a degree that makes the latter two practically noise in the signal). So, realistically, I have to agree. Perl is a niche language for new developments, but then again, so are Python and Ruby.

bobbyi 17y ago

Youporn is a top 50 site and was started in 2006.