Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

blog.dbpatterson.com

Post reply on HN
Print view View original

21–30 of 104 posts

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#21

Post by djhworld »

pjmlp wrote: post #16
cageface wrote: post #10

Earlier quoted context omitted.

I worked almost exclusively in Ruby and Python over the last ten years and coming back to static languages after that long was a real eye-opener. A good type system doesn't just help you catch a certain class of bugs. It completely changes the way you write code. Functions become self-documenting, aggressive refactoring becomes routine, the underlying architecture of your code emerges much more clearly. And you usual…

I used to like dynamic languages. Nowadays I will take a static language with automatic type inference over a dynamic language anytime, preferably one that with direct support for FP. The IDE support, code navigation and refactoring, and runtime performance just beat dynamic languages all the time. For the few use cases where dynamic types really make a difference, that can be supported by some kind of variant type o…

Haskell isn't quite there in terms of IDE support (there is "Leksah") but I find myself writing most Haskelly code in emacs/vim with GHCI open in a separate terminal.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#22

Post by dagw »

cageface wrote: post #10
grey-area wrote: post #7

Earlier quoted context omitted.

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…

I worked almost exclusively in Ruby and Python over the last ten years and coming back to static languages after that long was a real eye-opener. A good type system doesn't just help you catch a certain class of bugs. It completely changes the way you write code. Functions become self-documenting, aggressive refactoring becomes routine, the underlying architecture of your code emerges much more clearly. And you usual…

Pretty much same experience here. I'm currently working a pretty large and fairly old Python code base. And while I'd still consider python my favorite language, I no longer really feel comfortable recommending it (or any other equally dynamic language) for large, long lived, projects that's worked on by several developers.

Sure, all problems can be solved in theory with things like meticulous documentation, rigorous coding standards that everybody follows and lots of detailed tests. But in practice those sort of informal constraints will break down over years as developers of varying skill levels come and go. Better to formally force as much of that as possible with a decent type system.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#23

Post by microtonal »

tikhonj wrote: post #20
DanWaterworth wrote: post #18

Earlier quoted context omitted.

Here http://shootout.alioth.debian.org/u32/which-programming-lang...

I think he wants the server benchmarks in particular rather than general speed. I found some on the Snap framework web site[1], but they may be a little out of date. [1]: http://snapframework.com/blog/2010/11/17/snap-0.3-benchmarks

A slightly more recent benchmark:

http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-...

Also includes Yesod and Warp.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#24

Post by lucian1900 »

wylie wrote: post #2

This 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?

werkzeug is a nice web library and Flask merely collects several existing libraries (werkzeug, jinja2, sqlalchemy, wtforms).

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#25

Post by microtonal »

[deleted] wrote: post #12
sandGorgon wrote: post #9

Earlier quoted context omitted.

what issue are you referring to here ? Could you link to any relevant discussions.

[deleted]

The most common and impactful source of problems or bugs are ones of misconception, not TypeErrors, therefore anything that lets you iterate faster or get something out the door quicker is desirable. (I heard him say something to that effect in a talk)

He must have a typechecker in his head ;). My experience with learning Clojure (knowing Haskell) is that I constantly bumped into bugs where I thought "Haskell's type checker would have caught this".

Usually, when I write new functions in Haskell, I write down the type signatures first. This helps catching many errors. For instance, if your type signature is:

  f :: Integral n => [a] -> n
You can not accidentally apply a function (in f) to f's argument that assumes a list of lists, or return something that is not an integral number.

This cuts both ways: strongly encoding semantics using the type system catches many potential bugs in functions, but it also provides guarantees to the caller of a function. For instance, I know for sure that f does not return a 0/nil/None pointer, I know that the number is exact (since it is integral), etc.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#26

Post by danneu »

I've been learning Haskell on the side for a while and was hoping for something more after reading the title, but the post pretty much just points out a few preferences that OP has.

I spend very little time in Rails hung up on any of the issues expressed.

With some experience with frameworks like Express/Noir/Sinatra, I find that Rails is productive for me because of (A) convention and (B) getting common things done with terse code like `belongs_to :forum, counter_cache: true, touch: true`, and (C) not having to write glue code for basic things.

This quote...

> In addition, there is also very little “convention” with Snap. It enforces nothing, which has the consequence (in addition to allowing you to make a mess!) of having the whole application conforming to exactly how you think it should be organized.

...is precisely the deal breaker for me. If OP thinks it's hard to add/edit Rails code because it's spread out, then a lack of convention suddenly isn't a very compelling scenario for productivity. At least you know where to look.

I've been in a Node.js kick recently, consuming a lot of Express-stack repos on Github of smart people, and the experience is baffling. Deciding where to put code in my application just isn't a problem I want to solve when I'm trying to write a non-trivial, non-single-paged application.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#27

Post by DanWaterworth »

tikhonj wrote: post #20
DanWaterworth wrote: post #18

Earlier quoted context omitted.

Here http://shootout.alioth.debian.org/u32/which-programming-lang...

I think he wants the server benchmarks in particular rather than general speed. I found some on the Snap framework web site[1], but they may be a little out of date. [1]: http://snapframework.com/blog/2010/11/17/snap-0.3-benchmarks

Let's be clear, the article is comparison between frameworks. The benchmarks should therefore reflect the comparative speed of the same web application written using both rails and snap. I'm not aware of any attempt to do this, so I attempted to approximate it using the speed of the language in general and you can see that from the results I posted that the slowest Haskell GHC is faster than the 25% percentile of MRI ruby 1.9. This is a useful observation; A simple pong benchmark has absolutely no bearing whatsoever.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#28

Post by [deleted] »

danneu wrote: post #26

I've been learning Haskell on the side for a while and was hoping for something more after reading the title, but the post pretty much just points out a few preferences that OP has. I spend very little time in Rails hung up on any of the issues expressed. With some experience with frameworks like Express/Noir/Sinatra, I find that Rails is productive for me because of (A) convention and (B) getting common things done…

[deleted]

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#29

Post by delinka »

OT: The title of this article without the parenthesized would be "...as productive than Ruby/Rails." Want a more link-baity title? Try "...more productive than Ruby/Rails?" making it a question. Not so baity, but with Moar English? "...at least as productive as..."

This goes back to my little rant from last week: Please proof read your blog posts. In this case, reread the title with and without the parenthesized modifications and see if the English still holds together.

Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

#30

Post by maxcan »

grey-area wrote: post #7
cageface wrote: post #5

Having 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…

I can't count on one hand the number of commits with >500 changes that did not introduce a single bug or regression due to the compiler catching a huge amount of little typoes and mistakes that would have slid by in a dynamic language.

Its like how most vehicle accidents involving impact speeds of over 300 MPH involve planes and not cars or boats. Its not that cars and boats are safer..

Post reply on HN