Re: [Haskell-beginners] minimal Haskell concepts subset

Hi Matt, the first and best I found was http://learnyouahaskell.com/chapters. The point is that I spent too much time (almost a year) learning, and I am not -productive- yet. Productive in the sense of time writing and debugging, not in the sense of number of characters written. Nothing in particular, it just was too much time. My background is, in order of experience: Java, C++, Delphi, Python, C#, Bash, Scala, Basic, Pascal and maybe others I forgot. The first two I really know and could learn the best practices. The rest I know only the minimal concepts but could do something important already. Haskell has been harder than Basic, my first programming language. When I was 13-year old, somebody told me: "each line is an order the computer follows in sequence". That was enough intuitive to me. After that I was taught: for, goto, if, print and input. The last concepts and harder were the while and the subroutines. Maybe I am get messy with the lots of alternatives to do a same thing in Haskell. After months in Java I started the habit of always search for the best practices - and I found them. Ok, it is long enough email. Maybe I have some kind of non-haskell-related addiction. Davi

But a good OO program is very loosely coupled and doesn't really behave like a series of statements one after the other. Particularly as, if you're making full use of polymorphism, much of the time you simply can't tell from looking at the code precisely what happens inside a particular method call, only that it fulfils a particular contract. Which is actually not that dissimilar to what happen in FP . . . Julian Porter julian.porter@porternet.org http://www.porternet.org On 25 Jul 2011, at 22:17, Davi Santos wrote:
Hi Matt, the first and best I found was http://learnyouahaskell.com/chapters. The point is that I spent too much time (almost a year) learning, and I am not -productive- yet. Productive in the sense of time writing and debugging, not in the sense of number of characters written.
Nothing in particular, it just was too much time. My background is, in order of experience: Java, C++, Delphi, Python, C#, Bash, Scala, Basic, Pascal and maybe others I forgot. The first two I really know and could learn the best practices. The rest I know only the minimal concepts but could do something important already.
Haskell has been harder than Basic, my first programming language. When I was 13-year old, somebody told me: "each line is an order the computer follows in sequence". That was enough intuitive to me. After that I was taught: for, goto, if, print and input. The last concepts and harder were the while and the subroutines.
Maybe I am get messy with the lots of alternatives to do a same thing in Haskell. After months in Java I started the habit of always search for the best practices - and I found them.
Ok, it is long enough email. Maybe I have some kind of non-haskell-related addiction.
Davi _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Hi Davi, On Jul 25, 2011, at 11:17 PM, Davi Santos wrote:
the first and best I found was http://learnyouahaskell.com/chapters. The point is that I spent too much time (almost a year) learning, and I am not -productive- yet.
I think Learn You a Haskell is a good book. But if it is all too overwhelming I echo the recommendations for Graham Hutton's book - it is short and simple. Other than that, I can only say: write, write, write. I lot of things are easier than they seem once you start using them. If you are a Unix user, a good way to start is to write small utilities you'd write in sh, Python, Perl, or Ruby in Haskell from now on. Start with stupid, obvious implementations, and refine them as you learn new abstractions and patterns. This worked very well for me, some of my first Haskell programs were: - Randomly pick n lines from a file. - Normalize sets of scores. - Filter lists of features in files. Just basic things that I needed at work, and I'd normally write a Python script for. Once you have written some code and read about an abstraction, you'll probably think "oh, this would improve program XYZ". Good luck, Daniël

Daniël,
I was on that road already.
I made a relatively complex file parser and other things.
Unfortunately I will stop learning for a while, because my actual project
isn't adequate to use Haskell.
But I already can feel functional concepts being useful to apply in other
languages.
The time spent was worthy.
And I have no fear of novelties* anymore. ; )
Davi
* -> even ~70-year old "novelties" :)
On Sat, Jul 30, 2011 at 9:01 AM, Daniël de Kok
Hi Davi,
On Jul 25, 2011, at 11:17 PM, Davi Santos wrote:
the first and best I found was http://learnyouahaskell.com/chapters. The point is that I spent too much time (almost a year) learning, and I am not -productive- yet.
I think Learn You a Haskell is a good book. But if it is all too overwhelming I echo the recommendations for Graham Hutton's book - it is short and simple.
Other than that, I can only say: write, write, write. I lot of things are easier than they seem once you start using them. If you are a Unix user, a good way to start is to write small utilities you'd write in sh, Python, Perl, or Ruby in Haskell from now on. Start with stupid, obvious implementations, and refine them as you learn new abstractions and patterns.
This worked very well for me, some of my first Haskell programs were:
- Randomly pick n lines from a file. - Normalize sets of scores. - Filter lists of features in files.
Just basic things that I needed at work, and I'd normally write a Python script for.
Once you have written some code and read about an abstraction, you'll probably think "oh, this would improve program XYZ".
Good luck, Daniël
participants (3)
-
Daniël de Kok
-
Davi Santos
-
Julian Porter