Live data from Hacker News

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

blog.dbpatterson.com

31–40 of 104 posts

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

#31
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?

I've noted that split as well - and wondered indeed if there is no middle ground. Recently it occurred to me that perhaps there is no real need for that middle ground.

The fact that Django comes with even more batteries included than Python itself does not mean you have to use each and every battery. And ignoring stuff you don't need is often easier than extending an even moderately complex 'middle ground framework' in a meaningful way without making a mess of it.

If I compare that to my own experience, that is exactly what I've started to do over time.

A thing I've become accustomed to is splitting my applications cleanly in 'front-end' (focus on interaction with humans) and 'backend' (focus on business logic, (persistent) state and interaction with other applications/machines).

For front-end applications I've no real need for a number of things Django offers (ORM, authentication/authorization mostly). For building back-end applications Django has even more bits I do not really need.

This lead to a situation where I asked myself 'what does Django still offer me? Is it not easier to use a more limited framework for either use case or gobble together my own frameworks from various bits and pieces?'.

For front-end applications I could've (and have tried to) build a framework-to-fit from various bits and pieces such as cherrypy, jinja for templating, babel for i18n, routes for routing, etc. However creating a solid working framework this way, with all bits working together nicely - and keeping up to date with the development of its various bits and pieces - is a lot of work. Just using Django an ignoring the bits I don't need turned out to be far easier, leaving more time spending on my actual problem.

And for building my backend-applications I don't need all the stuff listed above - I simply need a robust and reasonable fast networked server which can host my business logic. The 'minimalist' frameworks then offer just what I need without getting in the way too much.

So in conclusion: if you want to build something that is mostly logic with a machine-machine interface, the minimalist frameworks offer a solid foundation and you have no real need for all the extras a 'mega framework' or even a 'middle ground framework' offers you. If you want to build something that has to interact with humans, you actually do need most of what the prevailing 'mega frameworks' offer you and leaving out the bits you don't want is easy. Hence there is no real need for 'middle ground' frameworks.

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

#33
post #19

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…

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…

I agree very much.

As far as I'm concerned Java's biggest failure, orders of magnitude worse than all others, is to make java.lang.String a final class.

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

#34
post #33
post #19

Earlier quoted context omitted.

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…

I agree very much. As far as I'm concerned Java's biggest failure, orders of magnitude worse than all others, is to make java.lang.String a final class.

I don't know:

1. having nullable references by default strikes me as a bigger issue

2. I don't see any reason I'd want to subclass String, actually (though I could see wanting to create an alternate implementation e.g. ropes-based). So String being a final class makes perfect sense as far as I'm concerned (unless it were an interface or some sort of "proxy" class as is often done in Cocoa). On the other hand, I'd give a phalange to easily create an unrelated type (typesystem-wise) with the same implementation. What `newtype` provides in Haskell.

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

#35

The single sentence that surprised me the most: "For performance, there is no question that Haskell will win hands down on any performance comparison".

Why is that surprising?

Haskell is a compiled language with a very clever optimizing compiler, so it tends to be pretty fast by any standard. On top of this, it has recently had some improvements to its IO manager which is particularly important for web servers.

Ruby, on the other hand, is notoriously slow.

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

#36
Until it has produced as many sites, I consider any such statements as anecdotal.

That is, I'd rather measure a system's productivity with actual production in the wild than with any of the systems "inherent" capabilities.

It might be productive for the author, but I don't see the general web programming public finding it more productive. People have learned Ruby to use Rails, but not many have ventured to learn Haskell to use its frameworks.

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

#38
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?

In the Ruby world Ramaze is right there between Rails and Sinatra.

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

#39
post #13

Where are the benchmarks?

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

This one is probably more relevant: http://shootout.alioth.debian.org/u64q/which-programming-lan...

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

#40
post #16

Earlier quoted context omitted.

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.

I just make use of EclipseFP, it is a very comfortable IDE for Haskell.

http://eclipsefp.github.com/

Post reply on HN