The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
blog.dbpatterson.com
The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
1–10 of 104 posts
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#2Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#3This article was interesting, having only used frameworks that either do everything or just the minimum (think Rails vs Sinatra, or Django vs Tornado). I was beginning to wonder if there was a middle ground in web frameworks. The idea of a web library, not a framework, really appeals to me. Is there anything like Snap for Python or Ruby?
http://docs.pylonsproject.org/en/latest/docs/pyramid.html
The routing system in particular looks quite similar.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#4This article was interesting, having only used frameworks that either do everything or just the minimum (think Rails vs Sinatra, or Django vs Tornado). I was beginning to wonder if there was a middle ground in web frameworks. The idea of a web library, not a framework, really appeals to me. Is there anything like Snap for Python or Ruby?
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#5Agree with this 100%. I think dynamically typed languages are a transitional technology we'll mostly leave behind as the kinks get worked out of modern type systems.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#6Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#7Having a compiler that will tell you all the places that you need to change things is an amazing productivity booster. Agree with this 100%. I think dynamically typed languages are a transitional technology we'll mostly leave behind as the kinks get worked out of modern type systems.
I can count on one hand the number of type issues which have caused trouble for me in Ruby over > 5 years of producing complex systems with it. I haven't used Haskell though so would be interested to see some examples of this. If his audience is Ruby users, it is not very informative to just say it is better in a general way. The main point of comparison in the article point 1 seems to be with unit tests, however there are no concrete examples given of a failing test from a real program where types would have helped. A strong type system adds friction and verbosity, so it would need to come with a lot of advantages for me to prefer it to Ruby, which will not allow something like 2 + "2" but does try to get out of your way as much as possible.
It's quite hard to compare type systems as they vary so much but at least here is he comparing just two systems Ruby/Haskell, so comparisons can be straightforward examples of situations where types have caused him trouble with direct comparisons. I'd be interested to see an example of something like a telephone number (from untrusted user input) where the Haskell type system is superior to having some checks on formatting, and an explanation for those less familiar with Haskell of what advantages the type system gives.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#8Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#9[deleted]
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#10Having a compiler that will tell you all the places that you need to change things is an amazing productivity booster. Agree with this 100%. I think dynamically typed languages are a transitional technology we'll mostly leave behind as the kinks get worked out of modern type systems.
It would have been interesting (and perhaps a little more convincing) to see some examples of the Haskell type system boosting productivity in such a dramatic way. I can count on one hand the number of type issues which have caused trouble for me in Ruby over > 5 years of producing complex systems with it. I haven't used Haskell though so would be interested to see some examples of this. If his audience is Ruby users…
In my experience a good type system doesn't add much friction and the extra documentation you get from specifying types more than pays for itself in the long run.