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

11–20 of 104 posts

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

#11

Post by masklinn »

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.

> Agree with this 100%. I think dynamically typed languages are a transitional technology

54 years old transitional technologies?

Look the split between dynamic typing and static typing is as old as computing itself (older actually, see untyped v typed lambda calculi), as it looks to me you're asserting properties your prover can't cash.

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

#14

Post by cageface »

masklinn wrote: post #11
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.

> Agree with this 100%. I think dynamically typed languages are a transitional technology 54 years old transitional technologies? Look the split between dynamic typing and static typing is as old as computing itself (older actually, see untyped v typed lambda calculi), as it looks to me you're asserting properties your prover can't cash.

Dynamic languages are easy to implement. Type systems that are rigorous enough to be useful but flexible enough to be expressive are much, much harder to design. I think we're still not quite there yet but we've made a lot of progress in the last decade. Even after ten years of Ruby experience I find myself writing code in Scala that has fewer bugs and is vastly easier to understand and maintain.

Maybe my background in chemistry colors my view but I don't see 54 years as really such a long time for any intellectual discipline. We're still in the early days of software engineering, IMO.

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

#15

Post by chc »

[deleted] wrote: post #8

[deleted]

Dude, Clojure isn't even purely functional, nor is it meant to be. I respect Rich Hickey a lot too, but that doesn't mean he's some kind of god who blesses functional things. In reality, Haskell is much more at the forefront of functional programming than Clojure is — it actually embraces FP down to its core, purity and curried functions and all, while Clojure takes the more pragmatic stance of maintaining easy Java interop. Haskell's whole purpose is to push the boundaries of functional programming, while Clojure's purpose is to be a very useful modern Lisp that separates value and identity. Clojure is a really nice language and IMO more practical than Haskell in general, but it is not the last word on FP.

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

#16

Post by pjmlp »

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…

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 or reflection.

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

#19

Post by chc »

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…

The thing is, it's not that straightforward. It's not about avoiding type errors that would have cropped up in Ruby, but about getting the type system to encode as much of your program's semantics as possible. For example, in Ruby, you use strings and symbols for a lot of disparate things. In Haskell, you'd introduce a type for each purpose to encode your intent in a way the compiler understands†. In Haskell, you're actually going out of your way to create more potential type errors, because that's more stuff the compiler can check for you.

† Concrete example off the top of my head: In Ruby, we do `foo.instance_variable_get(:@bar)`. If we accidentally write `foo.instance_variable_get(:bar)`, that's a hard error, but it isn't a type error. Haskellers would generally express a constraint like that with the type system, so the compiler would let them know when they made such a mistake.

(Also, don't forget that every unintended nil is a type error! If you've been doing heavy Ruby work for years and gotten fewer than six NoMethodErrors, I will hang my head in shame.)

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

#20

Post by tikhonj »

DanWaterworth wrote: post #18
vjeux wrote: post #13

Where are the benchmarks?

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

Post reply on HN