

From Ruby to Haskell, Part 1: Testing - twopoint718
http://bendyworks.com/geekville/articles/2012/12/from-ruby-to-haskell-part-1-testing

======
danneu
Just talking aloud, here. Sorta frustrated.

I recently dove into Scala for fun and I enjoy its terse syntax (often more
terse than Ruby's!) and principles. I was really excited about it at first.

But the excitement went away pretty quickly last weekend when I actually tried
building things with it.

Setting up a Sinatra app in Ruby is a matter of 'gem install sinatra', a
'require "sinatra"', and you're ready to roll.

Meanwhile setting up a Scalatra app in Scala was a far more involved process,
every tutorial getting me to use a tool called 'giter8' just to copy down app
boilerplate from github. I also ran into general difficulties just setting up
IntelliJ/Eclipse, falling back to Vim which makes compilation errors feel like
runtime errors since I had to go back to the terminal to see that my program
didn't even compile.

I pine for a world where I can just `scale install scalatra` (or pop it into
my Scalefile), `$ vim app.scala`, and begin coding.

I still plan on writing some "Scala for Rubyists"-type blog posts, but it's a
shame I couldn't figure out and enjoy the actual workflow. I'd have more
patience coming from an ecosystem that didn't make things as easy as Ruby's
does, but I've realized that tools/workflow/environment are showstoppers no
matter how much you enjoy a language.

~~~
KirinDave
You are not alone in this. Scala has had ecosystem problems for a long time
and because of the community status, that's unlikely to get much better
anytime soon.

One of the reasons I've been preferring haskell and clojure for my work is
because scala's toolchain abused me so badly.

~~~
jhchabran
As I've just scratched Scala's surface, I don't get what you meant by the
community status. Considering how important the ecosystem is, could you point
some resource to understand ? Thanks

------
freshhawk
Heh, never seen someone so defensive about using Haskell before.

I'm not sure that the "here's now to do this Ruby thing in Haskell" method of
learning Haskell is a good way to go about it. It would work well to teach
Python or JS but not a Lisp or Haskell or Prolog. They differ at a lower level
and require different mental models to even understand them, nevermind
thinking in them.

I don't see it helping if you are trying to cram monads, laziness, side effect
free programming, inferred types _and_ new syntax into the mental model of
code execution you use for Ruby.

Has anyone learned that way and found it useful? Do you learn a few things in
a familiar context while cargo-culting the rest and then fill in the gaps
later? Does it just click all of a sudden?

My biggest struggle was learning to think in Haskell and this type of mixed
metaphor teaching material would just make things worse. That might not apply
to everyone, but if it applies to you then you aren't alone. Try learning the
execution model with little toy programs first, then move on to the kind of
software you are used to writing once you know how to look at Haskell code and
reason about what it does.

~~~
jeffdavis
"Has anyone learned that way and found it useful? Do you learn a few things in
a familiar context while cargo-culting the rest and then fill in the gaps
later? Does it just click all of a sudden?"

That's how I learned to write my first useful programs.

Maybe there is a better way, but that is the direct answer to your direct
question.

Except I wouldn't say that it clicks "all of a sudden". It's a long process of
learning. One day something doesn't work, and you think it should, and you
just keep narrowing it down and eventually come to some deeper realization.
It's the top-down approach to learning.

I've been trying to learn haskell bottom-up for a while, and I've done a few
things and have some understanding of the theory. But I don't have anything to
show for it. Every time I learn some new theoretical thing, I think "wow, what
could I program with this?", at which point I've already lost. Because once I
start thinking about the language rather than the utility, I'm not likely to
create anything amazing.

I think that I'd be more successful if the next idea I had I just coded up in
haskell (even though I don't really know it) and pushed through to a solution
by any means necessary. But for me, learning a new language is secondary to
realizing my visions; and my visions rarely start from an empty file any more.

That being said, I think a mix of bottom-up and top-down is probably best.
There are some fundamental things that you need to learn deeply at some point
to be good. Not sure the exact stages that these things should be learned,
though.

~~~
freshhawk
Interesting, I did bottom up first and then when I started to feel that same
itch to actually build something useful things were more top down.

I agree that a mix of bottom-up and top-down is probably best, I was curious
about other paths because I found that starting with bottom-up worked really
well for me and wondered if that generalized to other people or was just well
suited to my learning style. My experience makes me think that a solid
foundation is essential but it's entirely likely that's just "that's the way i
learned" bias.

------
gtani

       move from perhaps the most dynamic language to what is perhaps the most static?
    

I don't think this continuum has any meaning, but s/he should look at GHC
Typeables, deferred type checking and the type holes work in the "most static"

[http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now...](http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdalike_holes/)

<https://news.ycombinator.com/item?id=4380900>

[http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntim...](http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime)

~~~
gtani
Here's where the "most dynamic/static/whatever" probably came from

<http://james-iry.blogspot.com/2010/05/types-la-chart.html>

------
coderhs
Why? whats the need or advantage of going to Huskel from Ruby??

~~~
danneu

        > If you read it as "stop using Ruby and start 
        > using Haskell", you read it wrong. 
    

He also goes into why he likes some of the things Haskell brings to the table
in the remainder of the article.

