Learning Haskell will improve your overall programming skill, it will change your mind. The best tutorial to learn Haskell: http://learnyouahaskell.com/ .And it is the tutorial that I enjoy the most (including tutorials ruby, php, backbone, jquery, etc)
The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
71–80 of 104 posts
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#72Earlier 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…
I'm at this point right now - what are the best static languages with type inference for the dynamic language crowd? Haskell? Scala? Go? Rust? Something I haven't heard of? All of the above?
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#73Not 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.
When discussing structural issues, like routing, code samples will be either deceiving or extremely verbose, because the ideas like that involve interaction of multiple components that simply doesn't happen in "hello world" examples.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#74I'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 s…
Firstly: no, it should not be the case that many of the .rb files are generated via rails. Or at least, it shouldn't be. Generators are a crutch.
Secondly: the sort of conventions you're talking about in Haskell modules also exist in Ruby. They just aren't enforced by the compiler, and because Rails is an application framework rather than a library, it has its own set of completely different conventions which make sense for application code. This is a double-edged sword. On the one hand you get a convention which makes more sense for the specific type of application Rails assumes you're building; on the other you are encouraged to write code which may end up difficult to extract out of the application you're writing, and may be less well-designed because of it.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#75Having 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…
Wow, interesting perspective. Let me attempt to summarize what you said:
When compilers/runtimes become smart enough, you won't need a static type system, because the runtime one will catch all your errors.
Here's why I think it's wrong:
Catching errors is not something that I want done at runtime.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#76Earlier quoted context omitted.
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.
When discussing structural issues, like routing, code samples will be either deceiving or extremely verbose, because the ideas like that involve interaction of multiple components that simply doesn't happen in "hello world" examples.
Yep, the same is true of the benefit static typing gives you for refactoring. Real world examples where the benefit is really significant are too big to put in a blog post. It should not require too much imagination to make the point clear to an experienced developer.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#77Having 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…
You still have to catch all the type errors "manually". Dynamic types doesn't mean you're free to avoid managing types, it just means you're going to get no feedback at compile-time about the errors you forgot to catch.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#78I really hope Haskell/Snap starts getting picked up by everyday web developers so someone can start exposing ridiculous things like: > 11111111111111111111111111111 - (length []) => 1729917383
Can someone explain what is happening in this example? I'm learning Haskell right now and this makes no sense.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#79The single sentence that surprised me the most: "For performance, there is no question that Haskell will win hands down on any performance comparison".
Ruby is as slow as PHP (see: Debian Language Shootout), and Rails is even worse because you're operating at a ridiculous stack depth. MRI and YARV are horrible at doing GC on deep stacks.
Re: The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.
#80Earlier quoted context omitted.
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 avoi…
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.
It is. A Ruby (or Python, or JavaScript, ...) source code inspector cannot, in general, infer concrete types for variables. You're allowed to say (JS example)
var x = "fred";
x = 3;
Of course, there are cases where you can infer useful things about your code, but for most real-world JS code, it would produce a lot of false positives or false negatives, and wouldn't be very useful. (Think about monkeypatching...)