6 ms·

Can Haskell power the next Ruby on Rails?

29 points by psibi 13y ago

beat 13y ago
I've had similar thoughts about Clojure, as I've been using it for back end work rather than Ruby. Clojure has a lot of the same elegance I've come to love in Ruby, all wrapped in yummy functional goodness. Then again, as a dynamic language, it has many of the same shortcomings. Scala has tried to go down the same route with the Play! framework. I tried it, but frankly, I found Scala very obtuse and difficult. I don't like languages that make me feel like the biggest problem is that I'm stupid, because I know I'm not stupid (by contrast, when I hit ignorance-based problems in Clojure, the solution when discovered makes me feel smarter and makes the language look even lovelier). Scala reminds me uncomfortably of the things I don't like about C++.
programminggeek 13y ago
No, it can't. Haskell is not a prototyping language. Ruby (and more generally dynamic languages like PHP/Python) are and Rails like frameworks are amazing tools for prototyping when you don't know what you are building, need to iterate quickly, and need to prove out an idea. Dynamic languages are great for building things that are very dynamic, things that are in fact a kind of prototype. Haskell and other languages with things like type checking and compilers and so on are designed to be safer, smarter, and are better long term for projects where the cost of complexity and maintenance are more significant and the development investment will get a payback. If you don't know if a project is going to work, you shouldn't spend a huge investment to find out if it will work. So, use a tool like Wordpress, Drupal, Rails, Django, etc. to build out the minimum viable thing that you can build to prove out the idea and see if there is a real business there. Once you prove out the prototype and you know it is going to be a long term project that can pay for itself in terms of ongoing development investment, you need to throw the prototype away and build it with a tool like C#, Go, Java, Haskell, etc. Most projects never realize they are no longer a prototype and should no longer be written in a prototyping language. Thus, you get all of the problems that come with a prototype without a lot of the solutions that we already have for solving them like compilers and such. Interestingly, if you use a tool like Rails, there is enough there that you can get far past the point of a prototype before realizing it is no longer the right tool for the job. This is evidenced by the fact that there are now a ton of people talking about large project OOP and structure in Ruby and Rails, without them realizing that it's always going to be an uphill battle in Ruby because of the language itself. So, if the question is if Haskell can be the next great prototyping language, then I don't think it is. If the question is if Haskell can be the language that you could migrate a project to after you realize it's no longer a prototype, then yeah it might be. Building a large production product with long term maintenance and scaling needs in a prototyping language is very likely a bad idea and is probably why there are so many projects that start to be really difficult in dynamic languages after they reach a certain size.
- cordite 13y ago
  Sure, the type checker forces you to think more when you are actually typing. It makes up for being easy and rapid to refactor, repurpose, and reuse--arguably making it competitive to prototype with.
  - programminggeek 13y ago
    I actually agree, but I don't think most people do and there are times when static typing isn't as much fun - like say pulling data from an API and shoveling it on to a page or through some filtering or something like that or just doing some random UI manipulation with jQuery or the like. Most developers see the pain and are given a deadline and so they do it dirty and hope to have a chance to pay downy that technical debt later. Later almost never happens until the system crashes beyond repair and the instability starts costing money in the form of downtime. In the grand scheme of things, maintenance is always the most expensive part of a system, but "prototyping" languages that aren't particularly safe or maintainable are inherently going to be more expensive to maintain and deal with over the long term. Ironically, dynamic languages like Ruby have taken the route of getting really good at unit testing and TDD instead of investing in moving their codebases from "prototypes" to "production" or "LTS" or whatever you would want to call a mature, complex codebase that will need to be maintained and evolved over time. I'm a huge proponent of TDD, and I love Ruby, but the more I use Ruby, the more I see the problems of not having a compiler.
xiaoma 13y ago
I wonder what Justin would think of Scala? I've seen rails programmers put Scala Play apps together at a good speed. While Scala doesn't enforce Haskell's pure functional paradigms, it does allow them. And it almost goes without saying that type safety was a top priority in its design.

29 points by psibi 13y ago

beat 13y ago

I've had similar thoughts about Clojure, as I've been using it for back end work rather than Ruby. Clojure has a lot of the same elegance I've come to love in Ruby, all wrapped in yummy functional goodness. Then again, as a dynamic language, it has many of the same shortcomings. Scala has tried to go down the same route with the Play! framework. I tried it, but frankly, I found Scala very obtuse and difficult. I don't like languages that make me feel like the biggest problem is that I'm stupid, because I know I'm not stupid (by contrast, when I hit ignorance-based problems in Clojure, the solution when discovered makes me feel smarter and makes the language look even lovelier). Scala reminds me uncomfortably of the things I don't like about C++.

programminggeek 13y ago

No, it can't. Haskell is not a prototyping language. Ruby (and more generally dynamic languages like PHP/Python) are and Rails like frameworks are amazing tools for prototyping when you don't know what you are building, need to iterate quickly, and need to prove out an idea. Dynamic languages are great for building things that are very dynamic, things that are in fact a kind of prototype. Haskell and other languages with things like type checking and compilers and so on are designed to be safer, smarter, and are better long term for projects where the cost of complexity and maintenance are more significant and the development investment will get a payback. If you don't know if a project is going to work, you shouldn't spend a huge investment to find out if it will work. So, use a tool like Wordpress, Drupal, Rails, Django, etc. to build out the minimum viable thing that you can build to prove out the idea and see if there is a real business there. Once you prove out the prototype and you know it is going to be a long term project that can pay for itself in terms of ongoing development investment, you need to throw the prototype away and build it with a tool like C#, Go, Java, Haskell, etc. Most projects never realize they are no longer a prototype and should no longer be written in a prototyping language. Thus, you get all of the problems that come with a prototype without a lot of the solutions that we already have for solving them like compilers and such. Interestingly, if you use a tool like Rails, there is enough there that you can get far past the point of a prototype before realizing it is no longer the right tool for the job. This is evidenced by the fact that there are now a ton of people talking about large project OOP and structure in Ruby and Rails, without them realizing that it's always going to be an uphill battle in Ruby because of the language itself. So, if the question is if Haskell can be the next great prototyping language, then I don't think it is. If the question is if Haskell can be the language that you could migrate a project to after you realize it's no longer a prototype, then yeah it might be. Building a large production product with long term maintenance and scaling needs in a prototyping language is very likely a bad idea and is probably why there are so many projects that start to be really difficult in dynamic languages after they reach a certain size.

cordite 13y ago
Sure, the type checker forces you to think more when you are actually typing. It makes up for being easy and rapid to refactor, repurpose, and reuse--arguably making it competitive to prototype with.
- programminggeek 13y ago
  I actually agree, but I don't think most people do and there are times when static typing isn't as much fun - like say pulling data from an API and shoveling it on to a page or through some filtering or something like that or just doing some random UI manipulation with jQuery or the like. Most developers see the pain and are given a deadline and so they do it dirty and hope to have a chance to pay downy that technical debt later. Later almost never happens until the system crashes beyond repair and the instability starts costing money in the form of downtime. In the grand scheme of things, maintenance is always the most expensive part of a system, but "prototyping" languages that aren't particularly safe or maintainable are inherently going to be more expensive to maintain and deal with over the long term. Ironically, dynamic languages like Ruby have taken the route of getting really good at unit testing and TDD instead of investing in moving their codebases from "prototypes" to "production" or "LTS" or whatever you would want to call a mature, complex codebase that will need to be maintained and evolved over time. I'm a huge proponent of TDD, and I love Ruby, but the more I use Ruby, the more I see the problems of not having a compiler.

xiaoma 13y ago

I wonder what Justin would think of Scala? I've seen rails programmers put Scala Play apps together at a good speed. While Scala doesn't enforce Haskell's pure functional paradigms, it does allow them. And it almost goes without saying that type safety was a top priority in its design.