Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Learning Functional Programming through Multimedia

timothy posted more than 10 years ago | from the function-of-art dept.

Programming 200

ijones writes "Andrew Cooke recently reviewed for Slashdot Purely Functional Data Structures, which is on my book shelf next to The Haskell School of Expression: Learning Functional Programming through Multimedia by Paul Hudak from the Yale Haskell Group. In his review, Cooke presented an overview of some available functional programming languages, such as OCaml, SML, and of course Haskell. Havoc Pennington once called Haskell 'the least-broken programming language available today.' Haskell is a purely functional, lazy, statically typed programming language. You can read more about Haskell itself here." Read on for ijones' review of The Haskell School of Expression.

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.

cancel ×

200 comments

Functional Programming through Multimedia? (-1)

Can it run Linux (664464) | more than 10 years ago | (#8580272)

Hah, that shit can't run on Linux(TM). Blow me.

Windows is hated by no one?! (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8580648)

windows (452268) [slashdot.org] is hated by no one?!

It is your duty as a Slashdot reader to officially and formally hate windows. [slashdot.org] Slashdot is impure until windows' freaks outnumber it's fans! Strike down this vile evil corporate monster today! Show it how much you hate it. Do Slashdot a favor and bloat windows' freaks [slashdot.org] list!

aahhh (-1, Flamebait)

Rabscuttle (597317) | more than 10 years ago | (#8580279)

first post?

God-fearing Muslims tormented by American SLUTS! (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8580283)

You Americans should be ashamed of yourselves!

Detainees at Guantanamo Bay are shackled for up to 15 hours at a time in hand and leg cuffs with metal links which cut into the skin. Their "cells" are wire cages with concrete floors and open to the elements - giving no privacy or protection from the rats, snakes and scorpions loose around the base. By contrast the camp guard dogs have wooden houses with air conditioning and green grass to exercise on. A diet of foul water and food up to 10 years out-of-date has left inmates malnourished.

But worst of all is the use of vice girls to torment the most religiously devout detainees. Prisoners who have never seen an "unveiled" woman before are forced to watch as the hookers touch their own naked bodies. One said an American girl had smeared menstrual blood across his face in an act of humiliation!

You make me sick! How dare you call yourselves the land of the free and the defenders of civilization. You make me sick! You are a bunch of depraved lunatics who deserve to drown in pig shit!

Re:God-fearing Muslims tormented by American SLUTS (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8580322)

I thought Guantanamo Bay is a BDSM Dungon and they are all there to enjoy the fun! :o)

In Soviet Russia... (-1, Funny)

Anonymous Coward | more than 10 years ago | (#8580306)

multimedia learns functional programming through YOU!

Two words: mod_haskell (0, Funny)

Anonymous Coward | more than 10 years ago | (#8580319)

If there's no Apache module for it, it's not a real language. End of discussion.

It's Real (4, Interesting)

Vagary (21383) | more than 10 years ago | (#8580508)

mod_haskell [cs.uu.nl]

Re:It's Real (1)

Richard W.M. Jones (591125) | more than 10 years ago | (#8580608)

It's also real (and a lot further developed than mod_haskell):

mod_caml [merjis.com]

Rich.

Sad news ... Stephen King dead at 56 (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8580327)


I just heard some sad news on talk radio - Horror/Sci Fi writer Stephen King was found dead in his Maine home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to popular culture. Truly an American icon.

It may teach you how to functionally program, (4, Funny)

Savatte (111615) | more than 10 years ago | (#8580328)

but chugging mountain dews and microwaving hot pockets are things that have to be learned through experience. Books are always a great source, but the lifestyle behind the teachings of the book can't be taught.

REDUNDANT? WTF (-1)

Anonymous Coward | more than 10 years ago | (#8580724)

don't worry Savatte. I thought it was funny. Someone else will too I'm sure. If I had mod points I'd mod you up.

Save $1.45 (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8580330)

Re:Save $1.45 (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8580378)

personnally the five finger discount is preferable for a pointles book that only serve for lighting fires

Re:Save $1.45 (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8580563)

What are you, like, 9 years old? Maybe you shouldn't listen to so much Linkin Park.

Good book, but won't get you up and running (5, Informative)

Ben Escoto (446292) | more than 10 years ago | (#8580346)

I've read this book and think this is a good book for learning Haskell (perhaps the best one) and that it explains monads well.

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 (1)

johnnyb (4816) | more than 10 years ago | (#8580377)

Very cool! I've been into functional programming a lot, but have never been able to get my mind fully around monads. All of the documentation available seems to assume that you already know what they are.

Is there any good stuff on monads for beginners on the web?

Re:Good book, but won't get you up and running (-1)

Anonymous Coward | more than 10 years ago | (#8580413)

yes there is right here [goatse.cx]

Re:Good book, but won't get you up and running (-1)

Anonymous Coward | more than 10 years ago | (#8580561)

Dude, goatse.cx has been down for months.

Re:Good book, but won't get you up and running (4, Informative)

jovlinger (55075) | more than 10 years ago | (#8580852)

Ask again in comp.lang.functiona;l the boffins there are pretty good at explaining this precise question (a VFAQ).

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.
datatype Maybe t = Fail | Ok t
you could write code like so:
case (funone ...) of
Fail -> Fail
| Ok r -> case (funtwo .. r .. ) of
Fail -> Fail
| OK s -> ....
All that fail handling gets old pretty quick. Instead, wouldn't it be nicer to write
runM (bindM (funone ...)
(\r-> bindM (funtwo .. r ..)
(\s -> ... )))
In haskell, this can also be written:
runM (funone ... `bindM` \r->
funtwo .. r .. `bindM` \s ->
...)
(or also using do syntax, but I really don't like that)

bindM is a monad combinator, the (\x -> ...) are monads. runM encapsulates the whole monad as a normal value.
unitM :: a -> Maybe a
bindM :: Maybe a -> (a -> Maybe b) -> Maybe b
runM :: Maybe a -> a
these are normal functions, no magic needed (written here using case rather than pattern matching to highlight similarity to above code)
unitM r = Ok a
runM m = case m of
Fail = error "oops!"
| Ok r = a

bindM m f = case m of
Fail = Fail
| Ok r = (f r)
(./'s ecode tag is Borken, I think)

... anyway, so what? The cool thing here is that in the case of IO (where instead of doign exception pattern matching, the monad combinators pass a representation of the whole external world), we can prove that the code inside the monads cannot ever directly access the world representation. Thus, the world is single-threaded through the computation. This is good, because then we can skip passing a representation, and just do the IO operations directly on the real world. So we can actually do side-effecting operations in a pure language.

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 (4, Interesting)

Godeke (32895) | more than 10 years ago | (#8580553)

Herein lies the rub in getting adoption of any of the more "esoteric" (read: not procedural) languages into the mainstream: libraries that require "understanding" of the functional model. After spending years interviewing programmers I can safely say that most barely remember the functional languages they were taught (if they were taught). Try to then force them to use an "alien" library that works in a functional way, and you might as well ask them to chop their arms off and thresh wheat.

I sometimes suspect that .NET may be the only hope of getting functional programming adopted by the maininstream. Currently the CLI has limitations that hamstring functional languages, but Microsoft has actually been bothering to try to rectify those problems. If they do, I would *love* to run ocaml or Haskell with the .NET infrastructure to back up the boring routine work. For that matter *any* major libarary of functionality accessable to a functional language.

Are Functional Libraries Different? (1)

Vagary (21383) | more than 10 years ago | (#8580742)

I haven't really given it much thought, but I've heard claims that functional libraries are designed very differently from imperative libraries and therefore .NET's (which is, lets face it, designed for C#) will not fit perfectly with CLI functional languages. Of course a functional-style wrapper around the .NET libraries could be written, but then we might as well be using the meager native functional libraries we already have.

Do you have any feeling for how well F# or H# will get along with the .NET API?

Re:Good book, but won't get you up and running (1)

jovlinger (55075) | more than 10 years ago | (#8580904)

I thought that the CLI security model was inherently incompatible with the sort of low-level stack and closure manipulation you need to either get tail-recursion of laziness.

Re:Good book, but won't get you up and running (0)

Anonymous Coward | more than 10 years ago | (#8581050)

Try F# [microsoft.com] . It's OCaml ported to .NET.

Re:Good book, but won't get you up and running (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8580611)

monads? Is that like gonads for moms?

Okay, that was a bad joke.

Learning Haskell is too easy. (3, Funny)

karmaflux (148909) | more than 10 years ago | (#8580349)

They've got a whole course [willamette.edu] online! FOR FREE!

News at 11. (1)

ultrabot (200914) | more than 10 years ago | (#8580420)

They've got a whole course online! FOR FREE!

Wow. That's indeed a good argument to scrap all those undocumented OSS languages we have been using for the past 10-15 years.

Follow the link, dumbass. (-1)

Anonymous Coward | more than 10 years ago | (#8580496)

It's a fucking joke.

This is how Indians learn? (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8580357)

No, too complicated for them.

The 'bottom' operator (5, Funny)

Anonymous Coward | more than 10 years ago | (#8580361)

Haskell is perhaps best known for its use of the bottom operator. When parenthetised, its ASCII representation looks kinda like a...

Well, I'll let you be the judge: (_|_)

Re:The 'bottom' operator (2, Funny)

Anonymous Coward | more than 10 years ago | (#8580655)

if 8==D (_|_)

Re:The 'bottom' operator (-1)

Anonymous Coward | more than 10 years ago | (#8580749)

|. . ^ . .|
\___/ \___/
. . | |
. . | |
. ._| |_
. / \ / \
. \_/#\_/
#######
fuc kfu ckfuckf uckfuc. kfuckf uckfuckfuck . fuck kfuckuk ku fuckefcuk.

The day I can... (1)

lpangelrob2 (721920) | more than 10 years ago | (#8580366)

Multimedia?

The day I can use Haskell to compile and output Flash files I'll be happy. Or cry. I'm not sure which at this point.

Re:The day I can... (1, Informative)

Anonymous Coward | more than 10 years ago | (#8580695)

Oddly enough...

I am working on a Haskell library that allows you to write haskell programs that output SWF files. It includes a scheme->SWF byte-code compiler so you can use scheme instead of action script.

Sorry, no URL.

Re:The day I can... (1)

lpangelrob2 (721920) | more than 10 years ago | (#8580723)

Oddly enough... I am working on a Haskell library that allows you to write haskell programs that output SWF files....
Yup. I'm crying.

:)

Learning *Functional* programming? (-1, Funny)

Anonymous Coward | more than 10 years ago | (#8580369)

As opposed to what, Dysfunctional programming? Yeah, we need more books on that...

Re:Learning *Functional* programming? (2, Insightful)

ameoba (173803) | more than 10 years ago | (#8580521)

I think these guys [oreilly.com] have you covered.

Re:Learning *Functional* programming? (2, Informative)

happyfrogcow (708359) | more than 10 years ago | (#8580587)

Above message is especially redundant, and not even funny. It's an exact duplication of a post from a previous functional programming thread on /.

Haskell (0, Troll)

ultrabot (200914) | more than 10 years ago | (#8580383)

Anyone noticed how incredibly unpractical Haskell is? It sacrifices too much by taking the FP purity too far.

Also, apparently the Haskell people are way too intimately associated with Microsoft (isn't Cambridge some kind of Microsoft stool pigeon these days?). One just *has* to suspect that they are up to no good. We need to inspect this connection further before giving them the benefit of a doubt ;-).

Yes, I truly felt like burning some of that Karma of mine :).

Re:Haskell (-1, Flamebait)

cmdr_of_taco (755650) | more than 10 years ago | (#8580412)

haskell is shit

Re:Haskell (1)

machead526 (755684) | more than 10 years ago | (#8580912)

Cambridge? Try New Haven. And, while the Yale CS department sends its fair share of CS undergrads to Microsoft, I'm not aware of any evidence that the faculty is too cozy with the company. (Disclosure: I graduated the Yale CS department six years ago, and went to work for Microsoft for a few years.)

no SMP support (0)

Anonymous Coward | more than 10 years ago | (#8580389)

lack of SMP support in Erlang and Haskell really makes them hard to choose for enterprise projects.

I'm a Dungeons and Dragons Player (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8580404)

Recently, I've been feeling lonely. Could anyone tell me a place to obtain Rohypnopl +5?

Some more useful Haskell resources (5, Informative)

tmoertel (38456) | more than 10 years ago | (#8580407)

If you're interested, I recently gave a short talk about Haskell for the local Perl Mongers. The slides and notes are available online here: Haskell for Perl Hackers [moertel.com] .

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? (1)

Chilliwilli (114962) | more than 10 years ago | (#8580419)

I just can't understand why it's not used more. Personally I feel I was taught Haskell too early.. I was taught in my first weeks at uni before I even knew C. At the time I really struggled, all I knew about programming was BASIC and Haskell seemed alien and I hated it and dismissed it completely until recently. Now that I have much more experience of programming and functional languages I sometimes wonder why I ever touch C++ or Java. If I'd be taught Haskell in my penultimate or final year of university I'm pretty sure I'd have taken to it far more kindly.

Re:Why isn't Haskell more popular? (-1)

Anonymous Coward | more than 10 years ago | (#8580519)

'caus it's sloooooooooow.

Re:Why isn't Haskell more popular? (1)

ameoba (173803) | more than 10 years ago | (#8580635)

It seems strange to introduce functional programming early & then abandon it for imperative programming. The general trend, when introducing FP early is to carry it through the early part of the curriculum to help stress the importance of doing things right & somewhat separate the theory from 'real world' work (it also puts people on a more even basis and prevents the PHP/VB/HTML kiddies from being able to pretend they know everything comming into the program). Some good arguments can be made towards this approach, but I think the real secret to a good CS program is having good professors who care about their work and motivated students; the language of instruction isn't really too important (unless it's exceptionally bad).

OTOH, when you see FP towards the end of the program, it's generally a case of "here's some things that we think you should be familiar with so you can sound educated at cocktail parties". In my case, it was "Programming Paradigms" class that talked about functional & logical programming (SML and Prolog) along with various abstract/theoretical language design ideas (and the professor introduced the unit on Prolog by saying "It's an interesting toy language but I can't see ever actually using it for anything productive").

Re:Why isn't Haskell more popular? (1)

Dusty (10872) | more than 10 years ago | (#8580847)

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? (1)

pHDNgell (410691) | more than 10 years ago | (#8580887)

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.

You should probably consider looking at assembler output from ocamlopt before saying stuff like this. Recursive loops are very efficient there. Although things like i++ are actually popular in OCaml, it's not necessarily done, and doesn't seem to add much efficiency.

(Can't speak for ghc, but I assume it's similar).

Re:Why isn't Haskell more popular? (2, Informative)

GnuVince (623231) | more than 10 years ago | (#8581047)

Most functional programming language implementations optimize tail-recursion, so it's not a problem. For example, in O'Caml, a non-tail-recursive factorial function looks like this:

let rec fact n =
if n <= 1 then 1
else n * (fact (n - 1));;
But, as you can see, the answer is kept on the stack, so that particular function can overflow. However, consider this one:

let fact n =
let rec fact_aux acc n =
if n <= 1 then acc
else fact_aux (acc * n) (n - 1)
in
fact_aux 1 n;;
Since the answer is always kept in acc, it's an iterative process, so it will never overflow if the compiler optimizes it. O'Caml does it, Scheme implementations do it, I think Haskell does it, many Common Lisp implementations do it, etc. So it's not a problem.

Re:Why isn't Haskell more popular? (1)

samweber (71605) | more than 10 years ago | (#8581056)

This is an example of one of my pet peeves: the "argument via stupid compiler". It's not actually the case that "the usual technique involves pushing the parameters...." -- that's just an explanation of recursion that is often given to first-year undergrads. Any compiler that actually implements a functional language this way would be considered unbelievably broken.

The problem is that not only are compilers much more intelligent than people usually give them credit for, but CPUs these days do so much prefetching and pipelining that it is very hard for a person to predict what instruction sequences would actually be most efficient.

Re:Why isn't Haskell more popular? (1)

lordholm (649770) | more than 10 years ago | (#8581085)

Usually compilers can detect this and treat recursive calls as loops instead of as function calls. I know that some C-compilers do this. In-fact, it is imperative in functional programming to be familiar with tail recursion and lazy evaluation.

If you don't know about these terms, then don't make any comments about the efficiency of functional languages.

By the way, treat languages as tools. I know Haskell, Erlang, C/C++/Objective-C, Java, PHP, Pascal, Python, MPD, AppleScript and 5 variants of assembler. What do I do with all these languages? Well I pick one that is suitable for the task at hand. And if none of them fits my needs, I pick a language that suits my needs and learn it.

Oh well, I'm ranting... but you probably get my point.

Re:Why isn't Haskell more popular? (1)

TwistedGreen (80055) | more than 10 years ago | (#8580926)

Ah, I don't really believe in any special 'formula' for learning. You either understand it, compartmentalize it, and use that understanding when you deem it appropriate... or you're missing something. Sure, a certain order can make this process easier, but in the end it shouldn't make a big difference. You're aware of your knowledge and your habits, and that's the first step. The next is adjusting them!

Using this 'habits' reason just seems to me like an excuse. If it really is worth it, embrace it! Why keep yourself in old ruts just for the sake of comfort?

I personally find functional programming to be quite deliciously elegant. I've dabbled in Scheme and yum, it's good stuff. You're right... it should be used more.

Re:Why isn't Haskell more popular? (2, Interesting)

jovlinger (55075) | more than 10 years ago | (#8580976)

The problem is that haskell is lazy.

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 program almost impossible. Chris Okasaki mentions that most lazy programs are analysed as if they were strict.

A second, smaller problem is that haskellers are really smart. really really smart. This makes easily approachable texts pretty thin on the ground. Two sentences in, you're being bombarded by catamorphisms, anamorphisms, and monoids.

Bird and Wadler is a really nice introductory text.

Graphical Programming and Learning (5, Insightful)

stuffduff (681819) | more than 10 years ago | (#8580432)

When I first started learning new languages I used to rewrite pong in them. It was very easy to 'see' if the code did what it should or didn't. That kind of feedback can really speed up the learning curve. I'm glad to see that the method hasn't been entirely lost.

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.

"Haskell" is crap (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8580441)

Yet another worthless programming language that isn't good for one fucking thing. Some nigger probably blew this new programming language out of his ass. All of you fucking faggots, jews, niggers, and wetbacks need rounded up and "dealt" with for fucking up the White man's life.

Dammit, I'm sick of it. WHITE POWER! KKK! HIEL HITLER! HAHA.

Audience (4, Insightful)

bobthemuse (574400) | more than 10 years ago | (#8580453)

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.

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 (4, Informative)

Ben Escoto (446292) | more than 10 years ago | (#8580566)

Who is the target audience for this book? I would assume programmers, of at least moderate experience.
Actually, the book is targeted mainly at novices (although experienced programmers who have never seen Haskell will also learn). In fact, the author even mentions high school students. This is from the preface (page xvi):
All the material in this textbook can be covered in one semester as an advanced undergraduate course. For lower-level courses, including possible use in high school, some mathematics may cause problems, but for bright students I suspect most of the material can still be covered.
So obviously an intimate knowledge of red-black trees is not required.

Here We Again (3, Interesting)

myownkidney (761203) | more than 10 years ago | (#8580465)

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.

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 (4, Informative)

Vagary (21383) | more than 10 years ago | (#8580568)

OCaml, which is not purely functional but still closely related to Haskell, is nearly as fast as C. Haskell somewhat acts as a testbed for ideas in the ML language family, and future versions of OCaml are expected to include many features that were first implemented in Haskell. I'd also suggest that Haskell is a good introductory language for future OCaml programmers as it ensures they won't just try and use OCaml like a weird imperative language.

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:Here We Again (1)

Chris_Jefferson (581445) | more than 10 years ago | (#8580613)

There are I think two main reason procedural languages are more popular.

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.

Also, I feel it is important to say that as time goes by functional languages are catching up with speed with C (and even surpasing it in some places). This is because we are damn good at writing optimisers nowadays and functional languages frequently allow compilers to make a lot more assumptions.

For example in C, imagine we have the following function:

void foo(int& i) {
if(i==1) g();
if(i==2) h();
}

(The & would be more useful in the case where i was a more complex structure of course!)

In C, we have to assume that the call to g() may have changed the value of i. In a functional language this is not true.

Avalibility? (1)

MountainLogic (92466) | more than 10 years ago | (#8580745)

Does Haskal or oCamal have supported production grade ports to Palm OS or other small/embedded platforms?

Re:Here We Again (2, Informative)

e aubin (121373) | more than 10 years ago | (#8580974)


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.

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 (instead of silently failing).

It might be hard (only at first) to wrap your head around higher-order functions, but all of you java programmers do the same thing (with ugly syntax) when you create inner classes.


For example in C, imagine we have the following function:

void foo(int& i) {
if(i==1) g();
if(i==2) h();
}

In C, we have to assume that the call to g() may have changed the value of i. In a functional language this is not true.

That is not true. If you were to transliterate this into caml, then the type of i would be a reference to foo, which g() could still change. Odds are though, you will very infrequently need to pass a reference.

Re:Here We Again (1)

Craig Davison (37723) | more than 10 years ago | (#8580975)

For example in C, imagine we have the following function:

void foo(int& i) {
if(i==1) g();
if(i==2) h();
}
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 (0)

Anonymous Coward | more than 10 years ago | (#8580625)

So why aren't you promoting your site anymore?

For those who are interested, these are the 'headlines' on his stupid site:

Student Discovers Love Potion

AIT Scientists Discover New Planet

AIT Hosts the Olympics

CENSORED Article on Gender Rights Activism

No More Pirated Software in Thailand?

Re:Here We Again (2, Informative)

Tellarin (444097) | more than 10 years ago | (#8580651)


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 (-1)

Anonymous Coward | more than 10 years ago | (#8580707)

You might want to mention that, in their day, LISP machines were the most powerful workstation platform around, not just some toys for bored accademics.

Re:Here We Again (4, Interesting)

Waffle Iron (339739) | more than 10 years ago | (#8580747)

I think that this choice of approaches to programming is similar to the choice in electrical engineering between solving problems in the time domain vs. frequency domain.

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.

Re:Here We Again (1)

Florian Weimer (88405) | more than 10 years ago | (#8580767)

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 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 (4, Insightful)

Ed Avis (5917) | more than 10 years ago | (#8580789)

Thus, there's a MASSIVE performance loss when a functional programming language is executed on any of the existing processors.
There's also a massive performance loss with many imperative languages when compared to C. Impure functional languages like OCaml or Scheme can give programs that run about half as fast as C when using a decent compiler. This compares favourably to Java or Perl (among others).
The day someone actually invents a function processor, we could start promoting these fringe langauges.
There have been Lisp Machines - okay, Lisp isn't a purely functional language but it is high-level and some of the same arguments apply. However, your point of view is a bit odd. There should be a processor with features mapping directly to language constructs before you can start using that language? People have tried this in the 1980s and earlier, with processors optimized for running Modula-2 or similar, but on the whole it turned out to be better to make general-purpose CPUs and write compilers for them. It's not as if current CPUs are a particularly good match for C's abstractions; a language with built-in lightweight parallellism could work well with hyperthreading, for example. In any case, even if the language and CPU are horribly mismatched and everything runs a hundred times slower, that could easily be fast enough for the application. CPUs are getting cheaper but programmers, on the whole, are not.

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 (5, Insightful)

talleyrand (318969) | more than 10 years ago | (#8580859)

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.
Hmmmmm
SELECT
*
FROM
PROGRAMMING_TYPES PT
WHERE
PT.name NOT IN ('functional', 'imperative')

>>> DECLARATIVE
(1 row(s) affected)
Yeah, I guess there's only two types of programming languages out there and clearly the previous code is only used in research/academic environments.

Re:Here We Again (4, Informative)

Ben Escoto (446292) | more than 10 years ago | (#8580861)

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.
You are exaggerating the performance penalty. See for instance the old version of The Great Computer Language Shootout [bagley.org] where Haskell is ranked faster than Java. Of course those benchmarks don't tell the whole story and should be taken with a grain of salt. In my experience though, Haskell is only about 4 times slower than C, compared to, for instance, Python, which is about 20 times slower (I am a big python fan, so this isn't a criticism of Python).

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 (2, Insightful)

Anonymous Coward | more than 10 years ago | (#8580905)

Sorry, but here you are completely mistaken (and I am a bit amazed how this post got ranked so high). By using a reasonably advanced compiler for a functional language, and knowing how to write good functional code (highly nontrivial issue), one can typically get 50% - 150% of the performance of GNU GCC. Just look at the figures in the "Great Compiler Language Shootout".

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 those one usually should not ask for their judgement, right?

When I saw LISP for the first time, I also could not imagine how something like that could ever be compiled to efficient machine code. By now, I do know, and I also know how to use the benefits of functional programming to implement freaky performance tricks virtually no imperative programmer would ever think about.

Re:Here We Again (1)

jovlinger (55075) | more than 10 years ago | (#8581035)

Troll?

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? I surely hope not.

Learning about functional programming... (2, Interesting)

rthille (8526) | more than 10 years ago | (#8580497)

way back when in college, the most interesting thing was that the program couldn't do I/O during the execution, only as an exit value. That makes useful daily programs difficult to write in a 'purely functional' language. The review talks about monads being a solution, but I can't see that putting something on the screen our worse a printer is something that can be undone. Therefore, I/O must be a side-effect, so how can a real 'purely functional' language like haskel do I/O?

It Works Like This: (2, Informative)

Vagary (21383) | more than 10 years ago | (#8580691)

Short answer: IO is an exit value, just like you said.

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 operators much like C's semicolon). Effectively Haskell monads allow all imperative constructs except for backwards jumps (goto).

The Haskell IO Monad is a purely functional mechanism for ensuring that modifications of the RealWorld are done in the correct order. It is implemented to call system calls which have real side-effects, but wrapping IO in a monad ensures that you can still reason about the order the side-effects will occur in. Since Haskell is lazy, these side-effects won't actually be triggered until necessary, either because the program needs an input value or it exits.

(I can give examples if anyone wants, but the resources at haskell.org [haskell.org] may be more helpful.)

Re:Learning about functional programming... (1)

Ben Escoto (446292) | more than 10 years ago | (#8580711)

way back when in college, the most interesting thing was that the program couldn't do I/O during the execution, only as an exit value. That makes useful daily programs difficult to write in a 'purely functional' language. The review talks about monads being a solution, but I can't see that putting something on the screen our worse a printer is something that can be undone. Therefore, I/O must be a side-effect, so how can a real 'purely functional' language like haskel do I/O?
Good question. There have been a variety of different alternatives proposed. For instance, some earlier functional languages took the entire program being a single function from the input (conceived of as a linked list) to the output (another linked list). However, since linked lists can be lazily generated in pure functional programming languages, this model does not imply that all the output must happen before all the input. The program would read the input and generate the output as it went along.

But the monad model is considered more flexible. Basically IO monads are just a way to use the type system to force a strict division between thinking (which is purely functional) and acting (which is imperative).

For instance, in C, it is possible that getchar() != getchar(). They can be compared because they are both ints. This is obviously non-functional (remember the definition of a function?). In Haskell, though, getChar isn't a function to ints, is a function to int monads (type IO Char). And you can't compare IO Chars, so getChar == getChar raises a type error. Voila, no functional violations. Similarly, any result which has a side effect or reads from the environment ends up with type IO.

Re:Learning about functional programming... (1)

jcupitt65 (68879) | more than 10 years ago | (#8580768)

Monads are like continuations, if you've ever programmed in that style with C.

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 the IO, and plain 'ol functional everywhere else.

Re:Learning about functional programming... (1)

Ben Escoto (446292) | more than 10 years ago | (#8581012)

Monads are like continuations, if you've ever programmed in that style with C.

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.
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 continuations or vice-versa.

Monads exploit the type system, not an extra argument. For instance the Haskell function putStr has type String -> IO (). There is no need to pass any extra parameter; you just pass it a string, and it prints it, returning a null value. Another way to do IO is to have a special "world" object that functions pass between each other (is this what you're describing?) but there are obvious drawbacks to this. For instance, what if a function modified the world object, and then passed back both the new and old versions?? Then your program would have to duplicate the world...

Re:Learning about functional programming... (0)

Anonymous Coward | more than 10 years ago | (#8580857)

The Key is that Monads impose a rigid sequencing. You're allowed side effects when you can prove that the results act in a certain functional way. (ie irrespective of evaluation order).

I once asked Hudak to come to philly from Yale and give a talk, and he did (at Drexel, a place I did a tour of duty at...) He was the best speaker we ever had, and a really cool guy. I spent the day walkin around penn/drexel with him.

Re:Learning about functional programming... (1)

Ed Avis (5917) | more than 10 years ago | (#8580870)

The way you do I/O in Haskell is that the main program has type 'an IO action'. So for example,

main = putStrLn "hello"

If you wanted to write two strings, you could use use the >> operator which glues two IO actions together. Or if you wanted to read a string and then write it, you would use a function of type 'IO String' to read a string - the type means 'an action which does something and returns a string' - and then glue it with >>= onto a function of type 'String -> IO ()' meaning 'make an IO action from a string'. It's weird, but workable (and there is syntactic sugar to avoid typing all these operators). All the way along you are just making these IO actions and returning them. You can quite easily put a bunch of IO actions into a list, or otherwise manipulate them - they don't get performed unless they become part of the 'main' action.

Re:Learning about functional programming... (0)

Anonymous Coward | more than 10 years ago | (#8580973)

(1) Create a "plan" what to output, what to output afterwards, what to input, how to process that input and create output depending on it.

(2) The "language" for such plans is a (not-so-special) certain data type, called IO. The basic operation on plans is concatenation: you have a plan to get A, and, provided you have A, a plan to do B with it. Then, you construct a plan that gets A and processes it to B.

(3) You construct these plans lazily. This is haskell, after all.

(4) Anything else you need is a magic location that allows you to execute plans. Not that we would not know something like this from C: its magic entry point where a plan that resides at that particular location is executed is called main().

Re:Learning about functional programming... (1)

scrytch (9198) | more than 10 years ago | (#8581021)

> Therefore, I/O must be a side-effect, so how can a real 'purely functional' language like haskel do I/O?

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 a list, you use a monad (thankfully the syntax sugar for list monads makes the monad invisible).

Some free alternatives (5, Informative)

Ben Escoto (446292) | more than 10 years ago | (#8580501)

If you want to learn Haskell here are my suggestions in order:

  1. Why functional programming matters [chalmers.se] by John Hughes. An oldie but goodie, this can get you motivated to actually learn the language.
  2. Hal Daume's Haskell tutorial [isi.edu] is very complete, free and much better than the "Gentle Haskell Introduction" which isn't very gentle at all.
  3. The Haskell Language definition [haskell.org] is the official language description.
  4. GHC's library reference [haskell.org] , which you will use constantly on anything non-trivial.
  5. The foreign language interface manual [unsw.edu.au] . Since Haskell has a small library you will probably need to call functions written in C a lot to get anything done. Luckily, Haskell's foreign function interface is quite nice.

New vs. Old (3, Interesting)

moberry (756963) | more than 10 years ago | (#8580503)

I think that there is a problem with newer programmers going into a language such as say, java, or C#. When i learned programming i learned C++ in ms-dos. We wrote our own string classes, used pointers, learned ADT's like, linked lists, and binary trees. Nowadays in java you write a program and use everyone elses stuff. there is a linked list class in Miscrosoft's .NET framework. Nothing is ever written from scratch anymore. IMHO you cant learn actual programming without getting into the nitty gritty your self.

Re:New vs. Old (4, Insightful)

Abcd1234 (188840) | more than 10 years ago | (#8580656)

Meh. A decent computing science course will have an extensive class in data structures, usually implemented in C, in which you'll likely cover at least linked lists and trees, followed by a second, more extensive course on general algorithms, in which you'll cover heaps and other more advanced data structures. If it doesn't, it ain't worth enrolling in. *shrug*

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 (1)

Vagary (21383) | more than 10 years ago | (#8580836)

In my program, the algorithms class was at the start of second year, so many students were still not comfortable with pointers. As a result, most people spent so much time struggling with the implementations that they didn't get a chance to sit back and appreciate the structures.

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 classes completing an implementation of linked lists in C (if this wasn't done in the C introductory class), then moving to a higher-level language for everything else. Because after all, once you've implemented one data structure in C, it's not difficult to implement them all.

Re:New vs. Old (-1)

Anonymous Coward | more than 10 years ago | (#8580728)

If every generation is forced to start from scratch, where does progress come from? What of "standing on the shoulders of giants"?

Re:New vs. Old (1)

SmackCrackandPot (641205) | more than 10 years ago | (#8580891)

If every generation is forced to start from scratch, where does progress come from? What of "standing on the shoulders of giants"? Because they might find something that everyone else has missed. You should consider algorithms to be like gold mining - most of the ground has already been well excavated, explored and mapped, but there are always areas that have still been unclaimed. Unless you know how CPU's operate, you don't know how to write efficient algorithms. You can't build complex systems out of basic components unless you know how each will interact with the others.

And more importantly, if the skills required to perform a task are reduced to "code assembly"; that type of work will more than likely be outsourced.

Re:New vs. Old (2, Insightful)

ThosLives (686517) | more than 10 years ago | (#8580773)

Ah, I would say that "writing a program" by putting together other people's building blocks is not programming but code assembly. I would actually say that most "programmers" out there really don't know how to program, and that's why we have lots of the issues present today. It does take a clarification on how literal you want to be with the verb "to program" because people who stack up components are programming in the strictest sense. However, I fear that few and far between are the folks who can code a full GUI in 32 K of RAM (GEOS for the Commodore64).

I would wager that most of the "true" programmers are those in imbedded systems and the like who actually have to generate the building blocks and frameworks of any language. The rest are something else - not to nock their contributions to the application world - but I think that some distinction ought to be made.

Re:New vs. Old (3, Insightful)

pHDNgell (410691) | more than 10 years ago | (#8580820)

Ah, I would say that "writing a program" by putting together other people's building blocks is not programming but code assembly. I would actually say that most "programmers" out there really don't know how to program, and that's why we have lots of the issues present today.

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 (0)

Anonymous Coward | more than 10 years ago | (#8581039)

Good post.

Languages (2, Interesting)

benjiboo (640195) | more than 10 years ago | (#8580504)

Do people think it's a good thing for a C++/Java/.NET programmer to go back to the drawing board for a few months and learn stuff like functional programming? I thought about coming up with a syllabus for myself of C, Haskell, LISP and Perl (which just evades me....)

Re:Languages (4, Insightful)

pHDNgell (410691) | more than 10 years ago | (#8581104)

Do people think it's a good thing for a C++/Java/.NET programmer to go back to the drawing board for a few months and learn stuff like functional programming?

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.

And to think... (-1, Offtopic)

!Squalus (258239) | more than 10 years ago | (#8580645)

I thought Eddie would never find a career when I watched Leave it To Beaver. He never seemed to have all that much going for him. To think, one day he would grow up and have a language named after him.

His pal Wally who seemed to have so much going for him is the model for Wally in the strip Dilbert. Functionally lazy, never wants to do work, and in fact, sees and avoids same at all costs.

Wonder who really turned out better in June's eyes? ;P

Hey Wally, what's up with the squirt these days?

Don't miss it! (5, Funny)

Anonymous Coward | more than 10 years ago | (#8580674)

If you liked

"Learning Functional Programming through Multimedia"

be sure to check out our new title:

"Learning Esperanto through Yoga"

Remember... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8580687)

When summer comes around, and it gets hot outside, and your
hemmoroids get even hotter, just look to the cool relief
of Preparation-H to get you on your way.

Consider the source (-1, Flamebait)

amightywind (691887) | more than 10 years ago | (#8580720)

Havoc Pennington once called Haskell 'the least-broken programming language available today.

Dubious praise, since he is a collaborater on the most-broken desktop available today, Gnome. Scheme is today's foremost computer language.

Some questions and comments (0)

Anonymous Coward | more than 10 years ago | (#8581083)

I've never done functional programming. The most esoteric I've ever gotten is Scheme:). From what I understand of functional programming you tend to describe what you want to do and let the compiler set up the low-level stuff for you. Am I wrong here? I think many more people would be more inclined to try out functional programming with one of the functional languages that target something like Microsoft's IL. That way they can still use the class libraries. Maybe functional programming doesn't integrate so well with IL(maybe it needs some lower level IL constructs to really be expressive), but if someone wrote a VS.NET plugin it might lower the fear factor in learning something new. I hear there are functional languages that do target IL right now. Any comments?

Mallocing a 'large chunk' (2, Interesting)

cheezit (133765) | more than 10 years ago | (#8581129)

This statement, from the 'more about Hskell' link:

"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?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...