

Can Haskell power the next Ruby on Rails? - psibi
http://www.stackbuilders.com/news/can-haskell-power-the-next-ruby-on-rails

======
beat
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++.

------
xiaoma
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.

------
programminggeek
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
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
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.

