As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Like most ppl, I started with and still do a lot of imperative code(mostly Java, Ruby, Javascript).
I've never been a big fan of OO, either because I never understood it properly or because I don't think OO.
Got my first glimpse of FP via javascript, passing functions around, closures, etc. Have been in love with FP since then.
Recently, I've developed interest in Clojure (and may be Scala) and someday might even have a go at Haskell. I like what I see in the functional approach, but how do I think functional? I've been doing imperative stuff for the past 3-4 yrs and my brain tends to think imperative while approaching a problem.
How can I unlearn the imperative style(do I need to?) and think more functionally ?
No. Don't unlearn imperative style as you'll still need it. Even many well-done FP libraries look somewhat imperative under the covers. It's better to think in terms of adding FP to your list of tools and techniques rather going full-metal with one technique or the other.
Now, as to how you go about learning the FP style? Toy projects - or utility project you write for your own use. Or hell, write yourself yet another blog - but with a twist! The key thing, as was stated above, is practice. When doing so, avoid shared state. Strive for purity (that is, avoid side effects) in as many places as you can. Use closures, pattern matching (if the language supports it) and lambda functions. Think in terms of functions being first-class data types in your program - take them as input and return them as output. The list goes on, but you'll see the same concepts repeated time and again if you're watching for them.
If you feel you need a gentle nudge in this regard, use a tool (language) that encourages the FP style such as F# or Scala.
If you feel you need more of a "tough love" kind of help, reach for Haskell :)
Otherwise use the tool of your choice and just keep FP concepts (above) in mind. If you decide go this route there's a pretty good book called Real-World Functional Programming that uses F# and C# to illustrate techniques that apply in both a "mostly" FP language (F#) and a "mostly" OO language C#.
Go for Haskell. Because it's pure you are forced to think functional. In F# or Scala you still can write very imperative code. I strongly recommend the book by Graham Hutton on Haskell.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am looking to learn functional programming with an am to integrate Boost.phoenix into my project.
What language is most similar so that I can find books that will illustrate functional programming concepts in a way that can be readily applies in that context... Are haskell and ocaml similar?
ALternately are there any good functional programming books written in general terms that can be applied to Boost.phoenix?
Phoenix enables functional programming (FP) in C++. Consequently, the language that will be most synergistic is going to be C++.
If you want to learn functional programming on its own terms, languages like Haskell and Scheme may be better choices.
http://www.boost.org/doc/libs/1_51_0/libs/phoenix/doc/html/index.html
I don't have any experience with Phoenix (I've skimmed the docs), but I do have some with C++, OCaml, and Haskell so I may be able to help there.
First off, if you learn functional programming you'll find it doesn't translate prettily to C++ - it ends up messier and more verbose than if done in an actual functional language. Nevertheless, it is still worth learning the techniques as they will give you more tools and a different mindset.
Are haskell and ocaml similar?
They are both influenced by ML so they are quite similiar (well, sorta, see the comments). OCaml is closer to C++ because of it's imperative and OO features, but I recommend you learn Haskell as it is more functional, more mindbending, and has more resources. An interesting thing about ML-like languages that they translate quite nicely to template metaprogramming.
ALternately are there any good functional programming books written in general terms that can be applied to Boost.phoenix?
The docs of Phoenix seem to use fairly standard terms. The one thing which could be confusing is their use of the word 'functor' - in C++ it means function object but in languages like Haskell it is something else.
Here are a few terms that you should look for:
lambda / anonymous function
first class function
function application
partial application and currying
composition
strict/non-strict/lazy evaluation
recursion
closures
Here are two free books which I recommend reading as they are a great introduction to functional programming:
http://learnyouahaskell.com/chapters (Haskell)
http://mitpress.mit.edu/sicp/full-text/book/book.html (Scheme)
I don't know much about Phoenix but I think that Okasaki's Purely Functional Data Structures can give you more or less general look how to write programs in functional style.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I looked at Haskell web frameworks like Snap and Yesod. Most seem to implement an MVC-ish approach reminding me of web frameworks like Ruby on Rails. Yes, MVC can be achieved with FP, but IMHO it doesn't show the great advantages of an FP approach. As HTTP is a stateless protocol, I would have hoped that there might be an Haskell framework that takes a more original, more pure functional approach. Are there any?
I'm not sure which features in FP you would like a framework to utilize, but I think Yesod uses some features to great benefit. (Happstack does as well, but I'm just not as familiar with it.)
Type-safe URLs eliminate an entire class of typo-generated bugs, plus automatically deal with input validation.
Proper typing practically eliminates XSS attacks.
Depending on the scope of data you're dealing with, using either STM or MVars for your storage needs make it easy to avoid race conditions and deadlocks in multi-threaded applications.
I'm sure there's a lot more that I'm not thinking of, but I hope that makes the point. But perhaps what you're looking for is something like a continuation-based framework. I personally think they're a bad idea (I'm a believer in REST), but I suppose it might seem more "functional."
It depends what you're trying to achieve. If by stateless you actually mean stateless, I use the templating framework Hakyll to generate static pages. It has an interesting structure to deal with dependencies and file updates.
I think WardB was asking not about fancy types, but rather about the denotative/stateless semantics of FP, in contrast to imperative/nondenotative (and often nondeterministic) semantics of things like IO and STM.
It's this denotative aspect that supports precise & tractable reasoning.
The term "functional" has been stretched to embrace imperative/nondenotative programming as well, which often leads to confusion.
Peter Landin recommended replacing "functional" with "denotative" to help clear up exactly this sort of confusion.
I don't know of any denotative (nonimperative) Haskell web frameworks.
Getting there would probably require breaking some long-standing imperative mental habits.
Which is to say: interesting work!
I was looking for the same but haven't really found it. Specifically I was looking for a continuations approach that renders traditional HTTP sessions unnecessary. These sorts of frameworks are quite popular in Scheme. The closest that I found was Chris Eidhof's answer to the Arc Challenge :-
https://gist.github.com/260052
It's a sketchy prototype and probably many man-months away from being something that you could use for serious work. If my Haskell skills were better, I might be tempted to try and develop it.
I also believe that WASH also took this approach but that seems to have died. I'm pinning my hopes on mysnapsession as I believe that is also looking at a continuations based session facility which would be exciting because I have been very impressed with the quality of the rest of Snap and the momentum behind it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
LISP or Haskell, I need to learn functional programming, but I heard that lisp is very old, any advice between those two languages ?
Just to echo the others, I'd learn both Scheme (a more functional Lisp dialect) and Haskell. Scheme / Lisp have some useful tricks to teach you about 'code is data / data is code' and macros. Scheme encourages a good functional style and I would recommend the 'The Little Schemer' series of books to get you started on this. SICP is also a fantastic text http://mitpress.mit.edu/sicp/full-text/book/book.html and possibly one of the best books ever written on programming. Scheme is more accessible as a first functional language.
Once you've got the hang of Scheme you'll probably find yourself becoming frustrated with the lack of libraries, lack of parallelism and the small, although excellent, community. This is where I was when I decided to learn Haskell. Haskell is very mature, very useful and very functional and it is quite a challenge to learn once you move off the basics and so having a grounding in another functional language will help enormously. You won't regret learning either (or both).
Why not both? LISP is very easy to learn (I'd go for the Scheme dialect - see http://racket-lang.org) so I'd start with that. If you like it, stick with it, but I'd also give Haskell a go, although it is (in my experience) considerably harder to wrap your head around.
The great thing about computing these days is that you can try all these languages for free, apart from your time. When I started programming LISP was only available on mainframes, which put a bit of a crimp on trying to learn it.
Haskell, because once you've learned Haskell, you will love it. And then, you will be able to learn Common LISP. However, if your editor is Emacs, then go start with Lisp.
If you want to learn functional programming through implementing a compiler or interpreter of a language, then Lisp or ML should be a better first choice as they're much simpler to implement than a lazy language. Otherwise you'd better learn both.
Choosing based on age is silly, Haskell has been around much longer than say C# and its history extends back a lot further. Anyway I'd recommend learning both eventually, for learning functional programming, Haskell is specifically about purely functional programming (in a number of senses of the meaning). Scheme is a functional orientated descendant of lisp.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
i was thinking learn a more low level language like C, but before it i'd like some opnion about:
what's the second language do you recommend to learn?
learn a low level language will make me a better programmer?
it's really necessary learn a second programming language?
Going backwards:
(3) Absolutely - you'll increase your ability by orders of magnitude by learning multiple languages.
(2) A low level language will make you a better programmer - alternatively a functional language will help as well.
(1) Low-level: go with C. Functional, try Scheme or Haskell. C also gives you the ability to write extension modules to Python if you ever have the need.
what's the second language do you recommend to learn?
Something imperative (i.e. same paradigm) but different. Python is dynamically typed with significant whitespace, so something statically types without significant whitespace: e.g. Java or C#.
These would also make a nice stepping stone towards C. The benefit of C is you really know what's going on, but with the disadvantage that you have to control it all. This level of control is not need for most business problems.
it's really necessary learn a second programming language?
Really subjective, but most good developers know many (consider for a web app: Python, Ruby, C#, Java on the server; SQL on the database and JavaScript on the client; and then the mark-up...).
You benefit from being able to see other approaches to problems and thus create better solutions. So once you have covered more imperative languages move into other paradigms like functional.
I agree with your choice of C, which leads on to C++. If nothing else, learning C will teach you why people these days tend to prefer languages with automatic memory management - but it will potentially also give you a feeling of programming "close to the metal" (without the pain of programming in assembly language), and help you to understand how a processor actually works. Not always useful knowledge but it's nice to know.
Whatever you choose, I recommend a statically-typed language - C, C++, Java, and some functional programming languages fit this bill. Java might be a good choice if you find C a bit tough at first.
I'd say learning any new language makes you a better programmer. However, will learning C make you a better Python programmer? Probably not; why should it?!
Define "necessary"! By a strict definition, no. But you're missing out on the experience of having to think about things in a different way (even if it's only a slightly different way).
I would stay with the same paradigm, but leave options open for another paradigm (functional programming). Probably C# is a good choice, because
If you decide to learn C/C++ later, it'll become a bit easier.
If you decide you want to learn functional programming later, you can switch to F# but still use existing code written in C#, because you stay within .NET framework.
Python is not known to be a remarkably fast language. You should consider learning a language which allows better computational performance. But good old ANSI C is probably too low level, despite you can write very fast programs with it. C# has OK performance for a just-in-time compiled language, and if you need more performance later, you can still extend your knowledge towards F# or C.
Although I don't use Microsoft Windows privately and advertise Linux and Open Source frequently, it's probably a good idea to offer some knowledge about Microsoft technology in case you intent to earn money with programming.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
For those of you experienced in both Haskell and some flavor of Lisp, I'm curious how "pleasant" (to use a horrid term) it is to write code in Haskell vs. Lisp.
Some background: I'm learning Haskell now, having earlier worked with Scheme and CL (and a little foray into Clojure). Traditionally, you could consider me a fan of dynamic languages for the succinctness and rapidity they provide. I quickly fell in love with Lisp macros, as it gave me yet another way to avoid verbosity and boilerplate.
I'm finding Haskell incredibly interesting, as it's introducing me to ways of coding I didn't know existed. It definitely has some aspects that seem like they would aid in achieving agility, like ease of writing partial functions. However, I'm a bit concerned about losing Lisp macros (I assume I lose them; truth be told I may have just not learned about them yet?) and the static typing system.
Would anyone who has done a decent amount of coding in both worlds mind commenting on how the experiences differ, which you prefer, and if said preference is situational?
Short answer:
almost anything you can do with macros you can do with a higher-order function (and I include monads, arrows, etc.), but it might require more thinking (but only the first time, and it's fun and you'll be a better programmer for it), and
the static system is sufficiently general that it never gets in your way, and somewhat surprisingly it actually "aids in achieving agility" (as you said) because when your program compiles you can be almost certain that is correct, so this certainty lets you try out things you might be otherwise afraid to try -- there is a "dynamic" feel to programming although it's not the same as with Lisp.
[Note: There is a "Template Haskell" that lets you write macros just as in Lisp, but strictly speaking you should never need it.]
First of all, don't worry about losing particular features like dynamic typing. As you're familiar with Common Lisp, a remarkably well-designed language, I assume you're aware that a language can't be reduced to its feature set. It's all about a coherent whole, isn't it?
In this regard, Haskell shines just as brightly as Common Lisp does. Its features combine to provide you with a way of programming that makes code extremely short and elegant. The lack of macros is mitigated somewhat by more elaborate (but, likewise, harder to understand and use) concepts like monads and arrows. The static type system adds to your power rather than getting in your way as it does in most object-oriented languages.
On the other hand, programming in Haskell is much less interactive than Lisp, and the tremendous amount of reflection present in languages like Lisp just doesn't fit the static view of the world that Haskell presupposes. The tool sets available to you are therefore quite different between the two languages, but hard to compare to one another.
I personally prefer the Lisp way of programming in general, as I feel it fits the way I work better. However, this doesn't mean you're bound to do so as well.
There's less need for metaprogramming in Haskell than in Common Lisp because much can be structured around monads and the added syntax makes embedded DSLs look less tree-like, but there's always Template Haskell, as mentioned by ShreevatsaR, and even Liskell (Haskell semantics + Lisp syntax) if you like the parentheses.
Concerning macros, here is a page which talk about it : Hello Haskell, Goodbye Lisp. It explains a point of view where macros are just not needed in Haskell. It comes with a short example for comparison.
Example case where a LISP macro is required to avoid evaluation of both arguments :
(defmacro doif (x y) `(if ,x ,y))
Example case where Haskell does not systematically evaluates both argument, without the need of anything like a macro definition :
doif x y = if x then (Just y) else Nothing
And voilà
I'm a Common Lisp programmer.
Having tried Haskell some time ago my personal bottom line was to stick with CL.
Reasons:
dynamic typing (check out Dynamic vs. Static Typing — A Pattern-Based Analysis by
Pascal Costanza)
optional and keyword arguments
uniform homoiconic list syntax with macros
prefix syntax (no need to remember precedence rules)
impure and thus more suited for quick prototyping
powerful object system with meta-object protocol
mature standard
wide range of compilers
Haskell does have its own merits of course and does some things in a fundamentally different way, but it just doesn't cut it in the long term for me.
In Haskell you can define an if function, which is impossible in LISP. This is possible because of laziness, which allows for more modularity in programs. This classic paper: Why FP matters by John Hughes, explains how laziness enhances composability.
There are really cool things that you can achieve in Lisp with macros that are cumbersome (if possible) in Haskell. Take for example the `memoize' macro (see Chapter 9 of Peter Norvig's PAIP). With it, you can define a function, say foo, and then simply evaluate (memoize 'foo), which replaces foo's global definition with a memoized version. Can you achieve the same effect in Haskell with higher-order functions?
As I continue my Haskell-learning journey, it seems that one thing that helps "replace" macros is the ability to define your own infix operators and customize their precedence and associativity. Kinda complicated, but an interesting system!