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

61–70 of 104 posts

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

#61

Post by sethg »

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.

I think dynamic and static type systems will eventually meet somewhere in the middle. Haskell has a “Dynamic” type for those times when you really do want to include dynamic types in your program. And some researchers have experimented with “soft typing” systems for dynamic languages like Scheme and Python, where a type analyzer tries to infer the types of expressions from how they are used.

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

#62

Post by mratzloff »

danssig wrote: post #57

Not a single line of code to illustrate the point? Not even one?

I was coming in to write this. Rule #1 for these kinds of blog posts: include code samples! Sometimes I want to read long, detailed articles. Other times I just want to look at the "pretty pictures", so to speak.

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

#65

Post by grey-area »

frio wrote: post #55
grey-area wrote: post #43

Earlier quoted context omitted.

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 But then in Ruby if you want to you can encapsulate behaviour and your intent in objects instead of types - as concepts become more complex, you may introduce an object which encapsulates the data and provides checked interfaces fo…

You can start with simple types in Haskell too, FWIW. To take your phone number example, let's say I'm making a very simple program that dials a number. In Ruby, I'm talking about something like: aNumber = "+0123456789" def dial(number) # does the dialling return someConnection end dial(aNumber) (It's been a long time since I've done any Ruby, so forgive any glaring syntax faults.) That method expects a string - aNum…

This is IMHO far more useful and interesting comparison than the original article; thanks for taking the time to write it.

I think the concrete examples really help show up the differences between the languages here. I might quibble with your initialisation in ruby (I'd expect it to be initialised with a string and hide the internal representation), but it is clear here why the Haskell type system might help you avoid issues with changing an interface and forgetting to change things which call it (though I can't say I've run into that a lot in Ruby, I can see where it might be useful, particularly with large groups collaborating or a large program).

I would argue that the compilation step is what is responsible for finding errors at compile time rather than runtime, but then the type system is perhaps required to enforce that.

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

#66

Post by carterschonwald »

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…

I'm slightly confused by this. Is it not the case with rails that many of the .rb files are generated via rails?

I think you're over thinking / pessimizing what happens with haskell code.

1) for any self contained project (library or executable) in haskell, the directory structure determines the module names. if you're wondering how the functions imported from the Foo.Bar module are implemented you simply go to the subdir #root/Foo/Bar.hs

2) Types. when you're writing use case specific code, you are going to define use case specific types, and they will be declared. More over, it is good practice to give explicit type ascriptions to haskell code to make sure that it does in fact have the type you expect. This means that you can jump into a module and by also recursively looking at its imports (and you know where those are in the fs), you can figure out exactly whats going on.

3) cabal-install (cabal), and your project specific project.cabal file make life great. Why? the foo.cabal file will tell you which module has the Main function if you're making an executable, what other packages (and their versions) your code might be importing, which language extensions are enabled, etc.

Point being, there are no need for "framework specific conventions" of the sort you're concerned about because those problems are solved by Haskell specific conventions :)

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

#67

Post by zopa »

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…

I think you've stated the main Snap vs. Yesod distinction in Haskell-land: "here are some tools" versus "do this." There's advantages to each approach, and luckily there are solid Haskell frameworks for both.

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

#68

Post by dustingetz »

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.

see "Horrors of Static Typing"[1]

the thesis is that there are places where the type system just gets in the way, and there are places where it is invaluable.

[1] http://phillyemergingtech.com/2012/system/presentations/Horr...

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

#69

Post by pjmlp »

Produce wrote: post #48
pjmlp wrote: post #41

Earlier quoted context omitted.

Why a failure? String is final in most languages OO languages.

I would consider having any final classes in a standard library to be a failure. One of the pillars of OOP is extensibility.

Then you should learn about the fragile base class problem,

http://www.cas.mcmaster.ca/~emil/Publications_files/Mikhajlo...

API design is a very complex issue. Any change in a base class can have unintended consequences.

Specially in components sold as libraries to development companies, where you as a customer don't have access to the source code.

You're right, one of the OOP pillars is extensibility, but inheritance is just one way of doing it.

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

#70

Post by SkyMarshal »

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 we'll mostly leave behind as the kinks get worked out of modern type systems.

While my favorite language right now is Haskell due to its sophisticated type system and ambitious design goal of enabling engineers to coral and isolate error-causing code into monads, I have to disagree.

Dynamic languages can be looked at as the next evolution of non-memory-managed -> memory-managed. Next is statically/strongly typed -> dynamically-typed. In both cases you go from manual management of some feature of the language, to having the vm or compiler do it for you, and that increasing abstraction and automation is the story of language development (and technology in general).

Non-memory-managed languages like C, C++, ObjC are still around and are used by highly skilled developers to squeeze the utmost performance out of the system, Chromium/Chrome/V8 being a good everyday example.

But where that kind of optimization is not strictly needed or where the automatic memory management of, say the Hotspot JVM, is sufficient, memory-managed languages will flourish. Further, memory-managed languages benefit from the continuous improvement in vm technology, and over time continue to approach non-managed in many situations.

I expect something similar to happen with type systems. Where a particular project does not need the strict control provided by a type system, dynamically typed languages will flourish (as they are in the startup web space).

Perhaps one day, vm's and dynamic type inference will be so good that neither manual memory-managed languages nor strongly typed ones will be necessary,but given Haskell's design goals and the type of difficult problems it's trying to solve (software assurance, security, etc.) I don't expect that will be anytime soon. They'll all continue to coexist for the foreseeable future.

Having said that, Haskell's type system is a pleasure to use, and imho actually increases productivity by both requiring and helping you think more clearly about the data flowing through your code.

Post reply on HN