Dear everyone, My first language is C, and I've strong intention in learning a pure functional programming language. My very first question is how to think in the functional programming way, anyone has some ideas. Really appreciate.... Regards, Jun
Hi, here my path (in correct order) I followed to learn to think functionally: 1) Curry-Howard Isomorphism 2) Type Theory & Functional Programming 3) The Hindley-Milner Type inference algorithm 4) Basic Category Theory 5) Notions of computation and monads 6) Denotational semantics 7) Monads for functional programming 8) Theorems for free. 9) A History of Haskell: Being Lazy With Class These are all papers you can find on Google. Then you can start to read some Haskell tutorial. It is not easy, but these readings are necessary to open your mind to the fantastic world of Functional Programming (I come from 15 Years of C++). Luca. On Dec 16, 2010, at 3:46 PM, Jun HU wrote:
Dear everyone,
My first language is C, and I've strong intention in learning a pure functional programming language. My very first question is how to think in the functional programming way, anyone has some ideas. Really appreciate....
Regards,
Jun _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
On Thu, Dec 16, 2010 at 04:41:24PM +0100, Luca Ciciriello wrote:
Hi, here my path (in correct order) I followed to learn to think functionally:
1) Curry-Howard Isomorphism 2) Type Theory & Functional Programming 3) The Hindley-Milner Type inference algorithm 4) Basic Category Theory 5) Notions of computation and monads 6) Denotational semantics 7) Monads for functional programming 8) Theorems for free. 9) A History of Haskell: Being Lazy With Class
These are all wonderful topics. But I strongly disagree with the notion that one must understand all of these before even starting a Haskell tutorial (!), or even that one must understand all of these to be able to "think functionally" in some sense. -Brent
2010/12/16 Brent Yorgey
On Thu, Dec 16, 2010 at 04:41:24PM +0100, Luca Ciciriello wrote:
Hi, here my path (in correct order) I followed to learn to think functionally:
1) Curry-Howard Isomorphism 2) Type Theory & Functional Programming 3) The Hindley-Milner Type inference algorithm 4) Basic Category Theory 5) Notions of computation and monads 6) Denotational semantics 7) Monads for functional programming 8) Theorems for free. 9) A History of Haskell: Being Lazy With Class
These are all wonderful topics. But I strongly disagree with the notion that one must understand all of these before even starting a Haskell tutorial (!), or even that one must understand all of these to be able to "think functionally" in some sense.
... aaaaand I'm going to agree with Brent here. It took me a while to have many things "click", but I found it hard to thoroughly read many papers. The mathematical notation which I'm not familiar with often is a problem to stay focused. What helped for me was reading tutorials and practice. Reading about people's problems on Café, and reading the replies. Re-reading several times a tutorial, weeks apart. I wish I had Real world haskell was I was starting, but I have it now and I'm glad I do. I can't claim I understand more than Haskell 98, but it's more than enough for a start. David.
On 12/16/2010 08:46 AM, Jun HU wrote:
My first language is C, and I've strong intention in learning a pure functional programming language. My very first question is how to think in the functional programming way, anyone has some ideas. Really appreciate....
I cannot claim C as my first language, but I do say it is my "natural" language; I have written more code in it than I have in any other, and I've been using it for nigh on 20 years. I also cannot claim to think in the functional programming way, but it definitely has changed my thinking. (Thinking about it now, I believe functional programming has had a bigger effect than I had considered. But I am definitely not a Haskell guru.) I believe the biggest difference between functional programming and procedural is thinking equationally rather than operationally. With procedural programming as in C (and object oriented languages, which in my experience are more procedural than not), the tendency is to think operationally: "First this happens, then it does this, then that,...." Now, back at UT Austin (I grew up in the land of Dijkstra), at the time anyway, they were fond of axiomatic thinking: "At this point in the program text, the state is this; at that point in the text, the state is that...." That is definitely a significant improvement, and I attribute what decent code I have written to that approach, but it definitely is not as natural as either operational or equational thinking. In Haskell especially, but in other functional languages to a lesser extent (and also when doing functional approaches in a non-functional language), it is very important to think equationally: "This means that; this other thing is that...." Now, equational thinking is easy for stuff like add_one n = n + 1 But it is not immediately apparent how that extends to something that needs recursion, say. The big "Ah-ha!" moment for me is the realization that recursion and mathematical induction are the same thing (ok, it's not a surprise; the big deal was when I internalized it). With that, you can deal with anything equational and recursive as equational and inductive. The change in thinking is as big as the difference between operational and axiomatic. Equational thinking extends beyond basic function definitions; I think it is the key to the type system, classes, and most of the other neat language features. At this point, I am still struggling with category theory, although I have been able to make use of monads reasonably elegantly (in my (humble) opinion, of course). I think there is another step there, although I haven't made it. (I am willing to change my traditional definition, "Programming is applied formal logic," to include at least abstract algebra and category theory at this point, though.) -- Tommy M. McGuire mcguire@crsr.net
Thanks for all these kind replies... Suddenly, I found I returned to the
beginning of the internet, the feeling
is lost for long time, the warm hearts, kind helps and the passion of
programming. Thank you very much.
@luca - fantastic list of the references, try to read some and do some
practices ...
@Tomme, you speak out exactly my problem - the conversion from operational
point of view to equational one.
It's really the most difficult one. I'm working on combinatorial
optimization. For me, the time and the states inherent
in every computation. The variable (mutable one) is the essential spirit of
all programs. Like in Tabu Search:
1. Find the best neighbor solution in a set of neighbor solutions
2. Apply the chosen neighbor solution (state change)
3. Put previous solution in Tabu, (state change)
4. Continue 1st Step if not reach the stop criteria (state verification)
above algorithm involves heavily with the changes of the state during the
search and
structured control constructors (if, then, while, for.... ). Living on the
land of Dijkstra, it really need the enormous
power to change the "state".
2010/12/16 Jun HU
Dear everyone,
My first language is C, and I've strong intention in learning a pure functional programming language. My very first question is how to think in the functional programming way, anyone has some ideas. Really appreciate....
Regards,
Jun
Jun HU
My first language is C, and I've strong intention in learning a pure functional programming language. My very first question is how to think in the functional programming way, anyone has some ideas. Really appreciate....
Well, programming is about building a house. Using the imperative procedural paradigm (C) you express how to build the house (what do you need to do to reach the goal?), much like in a recipe. Using the declarative functional paradigm (Haskell) you express what the house is, much like in a scheme or specification. Haskell is about as functional as a programming language can get by concept, because with the equals sign (=) you write actual equations. In most other languages the equals sign expresses assignment, not equation. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/
On Thursday, 16. December 2010 15:46:57 Jun HU wrote:
Dear everyone,
My very first question is how to think in the functional programming way, anyone has some ideas.
I don't think any answer to this question will help you much. You really have to do some coding. Get a book and do the exercises, then the question will eventually answer itself. -- Martin
Dear everyone,
Thanks for all these kind advices, really appreciate.
Finally, happy coding...
Merry Christmas
Jun
2010/12/19 Martin Drautzburg
On Thursday, 16. December 2010 15:46:57 Jun HU wrote:
Dear everyone,
My very first question is how to think in the functional programming way, anyone has some ideas.
I don't think any answer to this question will help you much. You really have to do some coding. Get a book and do the exercises, then the question will eventually answer itself.
-- Martin
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
participants (7)
-
Brent Yorgey -
David Virebayre -
Ertugrul Soeylemez -
Jun HU -
Luca Ciciriello -
Martin Drautzburg -
Tommy M. McGuire