Learning Functional Programming through Multimedia 200
| The Haskell School of Expression: Learning Functional Programming through Multimedia | |
| author | Paul Hudak |
| pages | 363 |
| publisher | Cambridge University Press |
| rating | 9 |
| reviewer | Isaac Jones |
| ISBN | 0521644089 |
| summary | Learn to program in a functional style in Haskell by implementing graphics, music, and robots simulations. |
As the title implies, The Haskell School of Expression introduces functional programming through the Haskell programming language and through the use of graphics and music. It serves as an effective introduction to both the language and the concepts behind functional programming. This text was published in 2000, but since Haskell 98 is the current standard, this is still a very relevant book.
Haskell's standardization process gives us a window into two different facets of the community: Haskell is designed to be both a stable, standardized language (called Haskell 98), and a platform for experimentation in cutting-edge programming language research. So though we have a standard from 1998, the implementations (both compilers and interpreters) are continually evolving to implement new, experimental features which may or may not make it into the next standard.
For instance, the Glasgow Haskell Compiler has implemented a meta-programming environment called Template Haskell. Haskell is also easy to extend in directions that don't change the language itself, through the use of Embedded Domain-Specific Languages (EDSLs) such as WASH for web authoring, Parsec for parsing, and Dance (more of Paul Hudak's work) for controlling humanoid robots.
Before we get too far, I should offer a disclaimer: The Haskell community is rather small, and if you scour the net, you may find conversations between myself and Paul Hudak or folks in his research group, since I use some of their software. That said, I don't work directly with Hudak or his research group.
In fact, the small size of the Haskell community is a useful feature. It is very easy to get involved, and folks are always willing to help newbies learn, since we love sharing what we know. You may even find that if you post a question about an exercise in The Haskell School of Expression , you'll get a reply from the author himself.
I consider this book to be written in a "tutorial" style. It walks the reader through the building of applications, but doesn't skimp on the concepts (indeed, the chapters are meant to alternate between "concepts" and "applications"). In some ways, the code examples make it a little difficult to jump around, since you are expected to build upon previous code. The web site provides code, however, so you can always grab that and use it to fill in the missing pieces.
For readers who wish to use this book as a tutorial, and to implement all of the examples (which is highly recommended), I suggest that you grab the Hugs interpreter and read the User's Guide while you're reading the first few chapters of The Haskell School of Expression. Hugs is very portable, free, and easy to use. It also has an interface with Emacs. Unfortunately, some of the example code has suffered from bit-rot, and certain things don't work out-of-the-box for X11-based systems. The bit-rot can be solved by using the "November 2002" version of Hugs. This is all explained on SOE's web page.
The Haskell School of Expression should be very effective for programmers who have experience in more traditional languages, and programmers with a Lisp background can probably move quickly through some of the early material. If you've never learned a functional language, I highly recommend Haskell: Since Haskell is purely functional (unlike Lisp), it will more or less prevent you from "cheating" by reverting to a non-functional style. In fact, if you've never really looked at functional programming languages, it may surprise you to learn that Haskell has no looping constructs or destructive assignment (that is, no x = x + 1). All of the tasks that you would accomplish through the use of loops are accomplished instead through recursion, or through higher-level abstractions upon recursion.
Since I was already comfortable with recursion when I started this book, it is hard for me to gauge how a reader who has never encountered recursion would find this book's explanation of the concept. The Haskell School of Expression introduces recursion early on, in section 1.4. It is used in examples throughout the book, and if you follow along with these examples, you will most certainly be using it a lot. The introduction seems natural enough to me, but I note that Hudak does not give the reader any extra insight or tricks to help them along. Not to worry, though; recursion is very natural in Haskell and the reader may not even notice that they are doing something a little tricky.
The use of multimedia was a lot of fun for me, and should quickly dispel the myth that IO is difficult in Haskell. For instance, Hudak has the reader drawing fractals by page 44, and throughout the book, the reader will be drawing shapes, playing music, and controlling animated robots.
Any book on Haskell must be appraised for its explanation of monads in general and IO specifically. Monads are a purely functional way to elegantly carry state across several computations (rather than passing state explicitly as a parameter to each function). They are a common stumbling block in learning Haskell, though in my opinion, their difficulty is over-hyped.
Since input and output cause side-effects, they are not purely functional, and don't fit nicely into a function-call and recursion structure. Haskell has therefore evolved a way to deal safely and logically with IO through the use of monads, which encapsulate mutable state. In order to perform IO in Haskell, one must use monads, but not necessarily understand them.
Some people find monads confusing; I've even heard a joke that you need a Ph.D. in computer science in order to perform IO in Haskell. This is clearly not true, and this book takes an approach which I whole-heartedly agree with. It gets the reader using monads and IO in chapter 3 without explaining them deeply until chapters 16 (IO) and 18 (monads). By the time you get there, if you have heard that monads are confusing, you might be inclined to say "how is this different from what we've been doing all along?" Over all, I was pleased with the explanation of monads, especially state monads in chapter 18, but I felt that the reader is not given enough exercises where they implement their own monads.
If you're worried that drawing shapes and playing music will not appeal to your mathematic side, you will be pleased by the focus on algebraic reasoning for shapes (section 8.3) and music (section 21.2), and a chapter on proof by induction (chapter 11).
After reading this book you will be prepared to take either of the two paths that Haskell is designed for: You can start writing useful and elegant tools, or you can dig into the fascinating programming language research going on. You will be prepared to approach arrows, a newer addition to Haskell which, like monads, have a deep relationship to category theory. Arrows are used extensively in some of the Yale Haskell group's recent work. You will see a lot of shared concepts between the animation in The Haskell School of Expression and Yale's "Functional Reactive Programming" framework, Yampa. If you like little languages, you'll appreciate how useful Haskell is for embedded domain-specific languages. It may be even more useful now that Template Haskell is in the works. Andrew Cooke described Purely Functional Data Structures as a great second book on functional programming. In my opinion, The Haskell School of Expression is the great first book you're looking for.
You can purchase Learning Functional Programming through Multimedia from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It may teach you how to functionally program, (Score:4, Funny)
Good book, but won't get you up and running (Score:5, Informative)
However, it won't get the reader fully up and running as a productive Haskell programmer, because for that it is basically required that you master the GHC's (Glorious/Glasgow Haskell Compiler) standard library. Otherwise you won't know how to use a fast unboxed array, etc. This library is actually intelligently designed, but it is poorly documented, and there are lots of quirks for people who aren't totally familiar with Haskell yet. The best way to learn still seems to be to read the Haskell newsgroup and look at other people's code.
But Haskell is an extremely interesting language and well worth learning IMHO.
Re:Good book, but won't get you up and running (Score:2)
Is there any good stuff on monads for beginners on the web?
Re:Good book, but won't get you up and running (Score:5, Informative)
For now, think of monads as bathroom fixtures and monad combinators as plumbing.
You COULD implement variables with state by creating a purely-functional assoc-list and explicitly threading it through your code. The state monad does that for you automatically, by forcing you to write your code as higher order functions, and by linking up the plumbing for you behind the scenes.
As a much simpler example, consider exception handling, were instead of returning a value of type t, a function that can fail returns the type (Maybe t), indicating failure or a returned result.you could write code like so:All that fail handling gets old pretty quick. Instead, wouldn't it be nicer to writeIn haskell, this can also be written:(or also using do syntax, but I really don't like that)
bindM is a monad combinator, the (\x ->
if this doesn't seem like magic, you are either much to smart, or have missed something.
Re:Good book, but won't get you up and running (Score:2, Informative)
Re:Good book, but won't get you up and running (Score:2)
Re:Good book, but won't get you up and running (Score:2)
Re:Good book, but won't get you up and running (Score:5, Interesting)
I sometimes suspect that
Are Functional Libraries Different? (Score:2)
Do you have any feeling for how well F# or H# will get along with the
Re:Are Functional Libraries Different? (Score:3, Interesting)
C# and F# interop [microsoft.com] has a link on how to call C# from F#. However, it is interesting that F# uses some of the OCaml library [microsoft.com] *in addition* to the
Re:Good book, but won't get you up and running (Score:2)
Re:Good book, but won't get you up and running (Score:3, Interesting)
Re:Good book, but won't get you up and running (Score:4, Interesting)
I, for one, do all kinds of wild data gymnastics in SQL, and wonder if more could be done to 'get people in the door' with SQL DML statements as a lead-in.
Always wanted to do more with functional programming, wondering if EMACS Lisp might prove more immediately fruitful...
Haskell, SQL and relational algebra (Score:4, Informative)
You might want to have a look at HaskellDB [sourceforge.net] which is a Haskell library for writing statically checked queries using a relational algebra-like syntax. It lets you write things like:
Re:Good book, but won't get you up and running (Score:4, Interesting)
Functional languages can implement declarative syntaxes easily, but the real defining factor is that functions are "first order" objects, which can be applied, manipulated and passed. Frankly, if SQL had first order functions, many wild data gymnastics would be vastly simpler. I grumble at the lack of code reuse in SQL (and I say that as a big fan of the ease of use of SQL on the whole). For example, in SQL I must repeat my subquery every time I wish to apply it.(1) Calculations must be specified both in the select list and the conditional if they are used in both places, instead of being defined once and the results being available (some SQL dialects have workarounds for this). Recursion is right out (a hallmark of functional languages is heavy use of recursive functions) which makes navigating tree structures a total bear (PSQL has extensions for trees, but not very clean ones).
Perhaps future developments that bring SQL closer to the true relational model (which has deep roots in set theory) which would make it possible to bring it closer to a true functional language as well. I think SQL would benefit wildly from the ability to define common structures (functions) and yet be able to apply the optimizer to the end result.
(1) Footnote: T-SQL has "user defined functions", but the impose a nasty overhead because they are not part of the query optimization process.
Re:Good book, but won't get you up and running (Score:2, Informative)
Others (Joe Celko, for one "SQL For Smarties") have proposed that a L-R list would work better, in that instead of storing the connection points, you are storing the edges as L-R pairs. The only problem is updating the L and R keys on inserts and deletes would require either triggers or using stored procedures to maintain the key list, so this would bog
Re:Good book, but won't get you up and running (Score:2)
Learning Haskell is too easy. (Score:3, Funny)
The 'bottom' operator (Score:5, Funny)
Well, I'll let you be the judge: (_|_)
Re:The 'bottom' operator (Score:2, Funny)
Some more useful Haskell resources (Score:5, Informative)
If you want to see some Haskell code, I have some more concrete examples here:
I have written a lot of little projects in Haskell. You can find some of them in links from my user info page [moertel.com].
Also, one of the best resources on Haskell is the HaWiki: HaWiki [haskell.org].
Do give Haskell a try. It is an amazing programming language.
Why isn't Haskell more popular? (Score:2)
Re:Why isn't Haskell more popular? (Score:2)
Re:Why isn't Haskell more popular? (Score:2)
I just can't understand why it's not used more.
I'd guess because implementing recursive programs on a CPU isn't very efficient. The usual technique involves pushing the parameters on to the stack on every function call, leading to a stack that's full of data that's identical or almost identical. 'Destructive assignments' (i.e. i++) inside a loop are a much better match for the CPU's architecture.
Re:Why isn't Haskell more popular? (Score:2)
You should probably consider looking at assembler output from ocamlopt before saying stuff like this. Recursive loops are very efficient there. Although thi
Re:Why isn't Haskell more popular? (Score:3, Informative)
But, as you can see, the answer is kept on the stack, so that particular function can overflow. However, consider this one:
Since the answer is always k
Re:Why isn't Haskell more popular? (Score:2)
A naive seat-of-the-pants answer. I assume you're basing this on some old saw you've heard repeated somewhere>
Re:Why isn't Haskell more popular? (Score:2)
A naive seat-of-the-pants answer. I assume you're basing this on some old saw you've heard repeated somewhere
Nope. It was my experience of implementing a heuristic tree search algorithm for permutation groups in Prolog, back in 1988. The recursive version would run out of stack. I ended up using an iterative solution, as AFAIR tail recursion reduced the stack usage but not enough to stop it from running out.
I'd be interested to see a way of implementing recursion (purely for my own entertainment) that
Re:Why isn't Haskell more popular? (Score:2)
Using this 'habits' reason just seems to me like an excuse. If it really is worth it, embrace it!
Re:Why isn't Haskell more popular? (Score:3, Interesting)
yes, this is a real problem. I've spoken w/ some of the implementors, and they really thought that strictness analysis would get them a whole lot more.
Lazyness sucks not so much for speed (but this is indeed an issue), but for interacting with foreign functions, and mostly because it breaks tail-recursion. You don't often notice, because haskellers tend to use programming idioms which don't rely solely on tail-recursion.
It also makes predicting the performace of your
Re:Why isn't Haskell more popular? (Score:2)
Maybe I'll try again after I finish playing around with Ruby
Graphical Programming and Learning (Score:5, Insightful)
Today, if you don't have enough flashy multimedia to attract the user to stay and look at what you have to say, you never even get your foot in the door. Chances are that someone who has taken the time to learn to both use the technology and apply it in a meaningful way probably has something to say.
With a generation of multimedia oriented programmers available I expect to see a much higher degree of interactivity in many different areas, from thing like mouse gestures to multi-dimensional navigation metaphores where we can simultaniously demonstrate our interests and our abilities so that we can arrive at the appropriate 'step' in whatever process we are trying to achieve.
Audience (Score:5, Insightful)
Who is the target audience for this book? I would assume programmers, of at least moderate experience. It's not like there are thousands of script/VB kiddies jumping over themselves to learn functional languages. Makes me wonder, how many semi-experienced programmers are there out there who aren't comfortable with using/understanding recursive functions?
Re:Audience (Score:5, Informative)
Here We Again (Score:3, Interesting)
Functional language are only good in theory. Sure, you can easily write programs in them, but they abstract over how the program is executed. And the programs are going to be executed in an imperative manner; machine code is imperative, remember?
Thus, there's a MASSIVE performance loss when a functional programming language is executed on any of the existing processors. Because the compilers can't think and optimise the code to best fit the imperative model. Where as the human being s can. That's why we should stick to imperative programming languages.
The day someone actually invents a function processor, we could start promoting these fringe langauges. Till then, let's keep Haskell as part of CS811
Thank you for listening. That's the end of my rant.
Counter-Rant (Score:5, Informative)
OTOH, it is theoretically possible to automatically multithread purely functional programs, especially if they're lazy like Haskell. So it could end up being a very important language on multi-processor and distributed systems.
Finally, Haskell has an excellent foreign function interface for when you need C-like performance and control.
Re:Counter-Rant (Score:2)
Re:Counter-Rant (Score:2)
Re:Counter-Rant (Score:2)
Constructs like "task A requires B" are quite powerful indeed... too bad the only platforms this language is used for are missiles
Re:Here We Again (Score:2)
a) inertia. Till quite recently much programming was done in assembler, and procedural languages used to map much better to assembler code efficently. I would argue that as processors become more complex this is actually becoming increasing less true.
b) It's much easier to hack out some program in procedural language and then hack bits of it randomly until it kind of works. Programming in functional languages requires more thought.
Al
Avalibility? (Score:2)
Re:Here We Again (Score:2, Informative)
This is nonsense. Functional programming almost always requires less thought because:
They are garbage collected
Programs tend to be much shorted
There are fewer assignments
Type systems catch a huge number of stupid mistakes
Functional programming is only feels harder because your are forced to correct your errors
Re:Here We Again (Score:2)
That's C++, not C. You cannot pass by reference in C. Plus we don't have to assume that the call to g() may have changed the value of i. The fact that you're passing it to foo() leads me to believe that it's not declared globally, outside of foo(), g() and h().
Did you mean to pass i to g()? Also, what's your point? I don't get it.
Re:Here We Again (Score:2, Informative)
You forget at least two things,
Functional languages are indeed used in production environments like Erlang from Ericsson for instance.
And there used to be Lisp machines.
So there are languages used in the "real" world and there "is/was" hardware available.
Re:Here We Again (Score:5, Interesting)
To me, functional programming is similar to the frequency domain. There are certain problems that are almost impossible to solve in the time domain that are trivial to solve in the frequency domain. However, the frequency domain is harder to understand, and the real universe actually operates in the time domain. Moreover, some problems that are trivial in the time domain blow up when analyzed in the frequency domain.
There few if any EEs who would advocate discarding all time domain calculations in favor of the alternative. That also applies to tools; few people would throw away their oscilliscopes just because they have a spectrum analyzer available.
That's what bothers me about "pure" languages of any form. You're intentionally throwing away some of the available tools to prove a point.
Sometimes a functional approach can provide an extremely powerful way to solve a problem with a tiny amount of code. However, sometimes another part of the same program would be better done in a more mundane fashion. The functional style's tendency to make you think about every problem "inside out" and to make you solve every problem in a "clever" way can get to be grating. I like to keep the option to use each style as needed, so I prefer languages that support features from a variety of programming styles.
Haskell lets you do both (Score:4, Informative)
Take a look at this one-page TCP port scanner that I wrote in Haskell. [moertel.com] Imperative and functional styles mixed together, with neither sacrificing for the other.
To use your time- and frequency-domain metaphor, Haskell is the well-educated EE who can use both kinds of analysis -- and slide between the two with ease.
Re:Here We Again (Score:2)
See e.g. scheme.
It supports and *encourages* functional programming but also has "set!"-operators, is almost "syntax-free" and by using macros you can adapt scheme to whatever "programming paradigm" which will pop up in the next years.
Re:Here We Again (Score:2)
There are lots of applications implemented in Excel spreadsheets. The stuff some people (who consider themselves non-programmers) do with Excel (or any other spreadsheet) is just amazing.
Excel is a bit limited (especially if you don't use VBA), but it's certainly some form of functional, purely applicative programming.
Re:Here We Again (Score:5, Insightful)
Do you also discourage the use of Perl, or shell scripts, or Tcl, or Java? Or is it just functional languages that you don't like because they do not map to existing processors?
Re:Here We Again -- Choices (Score:2)
Re:Here We Again (Score:5, Insightful)
Re:Here We Again (Score:2)
Re:Here We Again (Score:5, Informative)
Just as plenty of people are willing to put up with Python's slowness in exchange for better debugging, faster development, dynamic typing, etc., I think plenty of people would benefit by moving from C to Haskell, which is purely functional, has a great type inferencing system, never seg faults, etc.
One final note is that Haskell programs can often be optimized in Haskell itself and approach C speeds. This is because Haskell is compiled and statically typed and can deal with unboxed elements and so forth. This is a big difference from Python and other dynamically typed languages where optimization sometimes must be done in C for best results.
Re:Here We Again (Score:4, Insightful)
Predicting how a lazy program will perform is hard, and figuring out where it hurts is even harder. This is in part due to the massive restructurings the compiler does. One small annotation may be sufficient for the compiler to infer a function's strictness. Knowing where to put the annontation, tho, is nigh guesswork. Then I refactor the function, and there goes my strictness again.
But, this _is_ preferable to writing in C, I'll agree with you there.
(*) However, I think the worker-wrapper transformation may be the most beautiful optimization I've ever seen.
Re:Here We Again (Score:5, Insightful)
In other words, I don't want to waste time fucking around with pointers when I could be working on something more pertinant to the task at hand. I don't care HOW my matrix gets sorted. I just care that it does. If I waste some cycles, so what? This computer performs 53 MILLION in between each monitor refresh. If writing in a more abstract language permits me to get twice as much done per day of programming (and in my experience, it's more like 5-10 times), I'm willing wait.
Besides, while computers may no be able to "think," code optimization is not reasoning as much as it is pattern based. In fact, modern refactoring tools are better optimizers than most programmers, because they know more of these patterns. And unlike human programmers, refactoring tools aren't tempted to glaze over modern day essentials like bounds or type checking, resulting in fewer bugs and better security.
Re:Here We Again (Score:2, Insightful)
Yes, it is easy to write slow code in functional languages. Especially for beginners who do not know or care about the fine print. But tho
Re:Here We Again (Score:2)
Anyways, ocaml is quite performant; when people compare its performace to that of C, people aren't really stretching the truth.
Compiling strict languages like scheme and ML to machine code is possible. Doing it well is harder, but several very good compilers exist.
Perhaps you meant _lazy_ functional languages? There are some bigger performance problems in that world, true; see a post above.
Lastly, is performance the only benchmark we use for selecting languages? Is it even the most important one?
Re:Here We Again (Score:3, Insightful)
If this discussion was 25 years ago it would have been "OO languages? They are only good it theory. Sure you can easily write programs in them, but they abstract over how the program is executed.
Re:Here We Again (Score:3, Funny)
Alternative OSes are only good in theory. Sure, you can easily get a basic install up and running, but they depend too much on arcane instructions. The OS will ultimately be used by a human; humans are visual, remember?
Thus, there's a MASSIVE usability loss when an alternative OS is used by any normal person. Because Windows is bes
Re:Here We Again (Score:3, Insightful)
I haven't got the exact figures, but I reckon 99% of all code written out there must be written in Imperative (sometimes pseudo OO) languages. There must be SOME reason functional languages are not so popular.
This was also true of procedural languages versus assembly prior to the mid '70's, true of COBOL versus other languages prior to the early '80's, true of C versus OO languages prior to the mid '90's...
It's not just for mutual funds that the past is a poor predictor of the future.
Functional la
Totally false (Score:5, Informative)
Functional language are only good in theory.
This is totally not true. I build real programs that do real stuff in SML every day.
Thus, there's a MASSIVE performance loss when a functional programming language is executed on any of the existing processors.
This is also completely false. Optimizing high-level languages is often easier, because there is more semantic information to exploit (types, higher-order code). My SML programs typically run about 20% slower than a C counterpart, while being much shorter, more frequently correct, and more secure.
Re:Here We Again (Score:2)
while(1){} will run extremely fast. Not a lot of use however.
However what is difficult is to write large side effect free computer systems.
Functional languages will do that for you efficiently. Don't get hung up with speed it is not always that important. If it is write the bits that are in C and assembler, but do the bits that are not in a higher level language.
The day someone actually invents a function processor, we could start promoting these fringe langauges
Learning about functional programming... (Score:3, Interesting)
It Works Like This: (Score:3, Informative)
Long answer:
Monads are a pattern for hiding a state that gets passed from a sequence of functions. For example, when you assign to a variable in an imperative language, the value of that variable in the implicit state is updated and all future phrases accessing that variable will get the new value. If you're using a Haskell state monad it works the same way, but you need to explicitly specify which phrases can be executed in the future (using sequencing
Re:Learning about functional programming... (Score:2)
Good question. There have be
Re:Learning about functional programming... (Score:2)
Functions are passed their usual arguments, plus an extra parameter which is the thing that should be called after this function has done its work. This function parameter can have a lot of extra stuff inside it which represents the 'state' of the system.
It's rather like chopping your functional program into two parts: you have somthing a bit like an imperative programming language (but which is still pure functional) for th
Re:Learning about functional programming... (Score:2)
You are mistaken, or at least explaining things in a confusing way. Contiuation passing style and monads aren't related. In Haskell you can using monads without using continu
Re:Learning about functional programming... (Score:2)
I was trying to explain it from an implementation point of view: monads are implemented with continuations, and many C programmers will have come across them.
Re:Learning about functional programming... (Score:2)
I/O is not a "side" effect, it is a specified effect, not something that happens "along with" some other value being computed. It is however not deterministic, so it's contained within the I/O monad. Nondeterminism is one of the things monads are good for.
Basically any time you need something done in a sequence, whether it's executing "commands", reading input, producing output, or just producing
Re:Learning about functional programming... (Score:2)
appart from monads, IO can be done either by continuations: (read (\x->E) as anonymous function taking argument x, with body E)
This works because each IO function takes an additional argument -- what to do next. That way, there is no way to 'rewind' the computation.
Another way
Some free alternatives (Score:5, Informative)
New vs. Old (Score:3, Interesting)
Re:New vs. Old (Score:5, Insightful)
Of course, after you've learned *how* a linked list is implemented, you should never have to roll your own. And if you do find yourself rolling your own, you should seriously question *why* before continuing, as there are many high quality, well tested implementations already floating around (for example, glib).
The How Obfuscates The Why (Score:2)
In Haskell, structures like linked lists and binary trees are implemented with a single line of code. Yes, you don't see the actual memory addresses being used, but these are also barriers to understanding.
I'd advocate algorithm c
Re:New vs. Old (Score:3, Insightful)
Re:New vs. Old (Score:4, Insightful)
Um, no. Writing a program is always assembling building blocks unless you always start by writing an assembler for your target hardware.
The good programmers are the ones who assemble the correct building blocks the right way. The people who reinvent the linked list for every project are the ones who cause us the most problems (and yes, I've reinvented many linked lists in the past).
Once you break free from the mentality that you must always make your own malloc(), printf(), hashtables, trees, linked lists, etc... you can move on to higher level issues like the actual application you're working on.
Re:New vs. Old (Score:2)
First off, what do you consider "real programming?" I always felt it was the ability to take an input, process it, and create an output. You don't need to understand ANYTHING about data structures to do that.
Or is it not "real programming" unless you avoid all of the convenient shortcuts which permit programmers to do things that are more complex than the addition and transformation of bytes?
You don't need to understand the cellular biology behind tree growth to be a carpenter. I'm sure i
Re:New vs. Old (Score:2)
Languages (Score:3, Interesting)
Re:Languages (Score:5, Insightful)
Absolutely. It's a tragedy to go through life as a programmer without knowing FP. The more you learn about programming in general, the better you will be a programming.
I thought about coming up with a syllabus for myself of C, Haskell, LISP and Perl
I always recommend against perl. Very few people understand perl (no matter what they tell you), and I've yet to see a significant perl program without several significant bugs because of lack of proper exception handling or ambiguity (stuff like if($var) where $var can be false on what would otherwise be considered valid input).
I'd definitely recommend python instead if you want to learn some scripting (maybe ruby if you like stuff that looks like perl, but has a more reasonable philosophy).
C, like any other assembler, is OK to learn, but shouldn't be used for much of anything except to write extentions in high level languages.
Haskell is good. OCaml is good. Scheme is a good lisp derivative that's small enough to learn pretty easily.
You might want to add smalltalk and/or objective C in there. Smalltalk is pure OO (the OO version of Haskell, if you will). Objective C is C with smalltalk-style OO. When combined with the NeXTSTEP frameworks, you can learn a lot of very useful patterns.
A big part of functional programming is programming without side effects. Learning to program without side effects can greatly help you create more stable applications.
Re:Languages (Score:2)
Book recommendations (Score:3, Informative)
I'd like to strongly recommend some books. The first is Modern C++ Design [moderncppdesign.com] by Andrei Alexandrescu. The second is On Lisp [paulgraham.com] by Paul Graham. In conjunction with that, you will need an introductory text on Lisp if you don't already know it and a good book on C++ templates. While I don't know what the best Lisp text currently in print is, I'd be willing to give Graham's ANSI Common Lisp [paulgraham.com] a try on the st
Don't miss it! (Score:5, Funny)
"Learning Functional Programming through Multimedia"
be sure to check out our new title:
"Learning Esperanto through Yoga"
Mallocing a 'large chunk' (Score:3, Interesting)
"Furthermore, malloc is fairly expensive, so programmers often malloc a single large chunk of store, and then allocate "by hand" out of this."
I've seen this type of statement elsewhere in defense of non-C languages. And yet I've very rarely seen this done in code that wasn't either in 1) an embedded system or 2) a device driver or kernel module.
In those cases where I have seen this in application code, it has been accompanied by lots of other newbie gaffes. I'd question the sanity of anyone who thinks that a user-level app will benefit from a hand-coded heap manager.
But perhaps there are exceptions...does anyone actually do this routinely?
Re:Mallocing a 'large chunk' (Score:2)
Bit of a stretch, tho, I agree.
Re:Mallocing a 'large chunk' (Score:2)
Re:Mallocing a 'large chunk' (Score:2)
Re:Mallocing a 'large chunk' (Score:2)
Given a choice I try to use the stack wherever possible (but not alloca(); I've been burned). This can increase the image size at runtime and effectively preallocates a bunch of space in a more structured way. But it's not a replacement for truly dynamic allocation.
One more tutorial (karma whoring) (Score:3, Informative)
Lots of other comments, as well as the story, have pointed to a number of good tutorials and introductions. I'd like to recommend also the one I wrote for IBM developerWorks. I believe my tutorial is a bit better for real beginners to FP than are most of the others out there.
Anyway, you can find it at IBM dW(free registration required) [ibm.com] or at my own Gnosis Software site [gnosis.cx].
A challenge for Haskell hackers (Score:4, Interesting)
void invert_permutation(
int in[],
int out[],
int len
) {
int i;
for (i = 0; i < len; i++)
out[in[i]] = i;
}
Write the same function in Haskell, in linear time. Use whatever representation of a list seems natural for you.
I set this very simple problem to every pure functional programming enthusiast I meet, including several professors at a University known for that sort of thing. I've yet to hear a good answer...
Re:A challenge for Haskell hackers (Score:3, Informative)
Builds a new array with the same dimensions (indices from a..b), initializes it with a list of tuples that gets created using "zip" which takes the elements of the input array as the indices of the output array. Note: the signature in the first line is optional.
Nice, isn't it?
Can you honestly say.. (Score:2)
Sure, I don't like using C for general-purpose programming as much as the next HLL programmer, but FP languages are simply mind-boggling, and no - that's not a good thing.
Re:Can you honestly say.. (Score:3, Insightful)
It's simply wrong to assume that because you see code you don't understand when you're looking at an advanced language that you don't know, that those languages "are simply mind-boggling, and no - that's not a good thing".
What those languages are, are different than what you're used to. There's a reason for that - what you're used to is largely an ad-hoc collection of crap that evolved before people understood what
Re:A challenge for Haskell hackers (Score:2, Informative)
Now, if you want to use [Int] as a representation, so that the example permutation is [3,2,1], then you need to first add the indices (linear time), reducing it to the previous problem, and then extract the corresponding lis
Re:A challenge for Haskell hackers (Score:3, Insightful)
Using unboxed types I could probably transliterate that code, but I'm kind of rusty in Haskell. I just find it more interesting that I could probably crash your process by passing -1 for len.
Re:A challenge for Haskell hackers (Score:2)
It's Real (Score:5, Interesting)
Re:It's Real (Score:2)
mod_caml [merjis.com]
Rich.
Re:Learning *Functional* programming? (Score:3, Insightful)
Re:Learning *Functional* programming? (Score:3, Informative)