Book Reviews
Recent reviews from Slashdot readers:
- Advanced Excel for Scientific Data Analysis Learn to turn Excel into something that rivals Mathematica using VBA, brains, and a heaping helping of fortitude.(Jack Herrington's review.)
- Nagios 3 Enterprise Network Monitoring A great book for anyone using Nagios as more than a casual user.(jgoguen's review.)
- Schneier on Security Schneier argues that security is not something you can buy; it is something you must get.(Ben Rothke's review.)
Submitting a review for consideration is easy; please first read Slashdot's book review guidelines. Updated: 2008114 by samzenpus
7249910
story
Comments: 173 +- Developers: Haskell 2010 Announced on Tuesday November 24, @05:05PM
Posted
by
kdawson
on Tuesday November 24, @05:05PM
from the eddie-and-the-beav dept.
from the eddie-and-the-beav dept.
background: url(//a.fsdn.com/sd/topics/topicprogramming.gif); width:80px; height:48px;
programming
paltemalte writes "Simon Marlow has posted an announcement of Haskell 2010, a new revision of the Haskell purely functional programming language. Good news for everyone interested in SMP and concurrency programming."
Related Stories
Executive ability is prominent in your make-up.
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
Is it just me ? (Score:4, Insightful)
I admit that a function with no side effects can ease making things thread safe, but are recursive style functional programming languages really used that much in "SMP and concurrency programming" nowadays. I wrote some code in that category but I never envisioned a functional programming language would suit the job. Am I the only one ? ;-))
Thanks for your replies,
Re:Is it just me ? (Score:5, Insightful)
Functional languages are enjoying an enormous renaissance in the field of multithread, multicore and/or multiprocessor environments.
There are a few really major obstacles to doing multi-* well. The major theoretical one is Amdahl's Law, which puts some extreme limits on how much multi-* can help you. The major practical one is our current obsession with side-effect languages. We need major theoretical advancements to get past Amdahl's Law (if, in fact, it can be gotten past at all). Functional programming is a great way to get past side-effect-based programming, though.
In a proper functional language, there is no such thing as iteration. There can't be. The instant you say, "each time through the loop, increment the counter, and as soon as it hits this certain value stop," you have stopped programming in a functional style.
As an example of some really cool concurrent languages that emphasize recursion and functional programming, look at Clojure, Scala, Erlang and F#. All of these languages provide iteration and other side effect techniques if you really need them -- but all of these languages emphasize recursion.
Parent
Re:Is it just me ? (Score:5, Informative)
Parent
Re: (Score:3, Informative)
You misunderstand what he means by "getting past" Amdahl's Law. That wouldn't involve somehow changing the fact that only speeding up part of a program can only do so much to speed the whole program- it'd involve radically changing the proportion of various algorithms which can be parallelized. For instance, if somebody were to come up with a constructive proof that P [wikipedia.org]=NC [wikipedia.org] that'd certainly do the trick (though most people's guess is that that's false).
Re: (Score:3, Insightful)
Amdahl's law is not like Moore's "law". Amdahl's law is an observation of mathematics. You can't ever get around the fact that if you increase the performance of 90% of the instructions in a program, you still have to deal with the other 10%. Even if you increase the performance of 90% of the instructions by 100x or something large, if the other 10% take a long time (like disk access) its going to kill your performance.
It makes the implicit assumption that there is a '10%'. The whole point of some pure functional languages is that essentially all of it can be parallelized, 99% or more in some cases. There are programs where the sequential part is 0.001%, if that.
However, another comeback I've heard is that the "end goal" of parallelization is not necessarily to do the same thing in less time, but to do more in the same time. That is, you increase the "parallelizable" bit while keeping everything else constant. For example
Re: (Score:2)
I guess not, since that's what these folks put together.
Seriously though, it's my experience that there aren't too many people out there writing much with concurrency and SMP in mind to start with. I'm not sure how they did it, but if they can bring parallelism to another method of programming, then fine by me. The more people get used to utilizing the multiple cores available to them, the better IMHO.
Re:Is it just me ? (Score:4, Informative)
I'm not sure what you mean by "recursive style", but the biggest commercial users of functional programming languages tend to be companies behind high-traffic websites that need to handle a lot of concurrent requests. Facebook developed their real-time chat application in Erlang, for instance, and Twitter uses Scala to handle its message queue.
Parent
Re:Is it just me ? (Score:4, Informative)
> I'm not sure what you mean by "recursive style",
Look at Quicksort in Haskell :
qsort [] = []
qsort (x:xs) = qsort (filter (= x) xs)
This is what I mean, no loops, recursion. I used Prolog and ML to solve logic problems and it is pretty handy. Prolog is especially suited for solving logic problems ( "logic programming" ).
Parent
Re: (Score:2)
Hehe /. screwed the Haskell code, look here for the source :
http://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell [haskell.org] ;-)))
Re: (Score:2)
> I'm not sure what you mean by "recursive style",
Look at Quicksort in Haskell :
qsort [] = []
qsort (x:xs) = qsort (filter (= x) xs)
This is what I mean, no loops, recursion.
Well, all functional programming languages use recursion, so "recursive style functional programming languages" is a bit redundant :)
Re:Is it just me ? (Score:5, Interesting)
Most procedural programming languages use (or at least support) recursion, too. The difference is that (1) pure functional language cannot express certain algorithms with iteration instead of recursion because of the lack of mutable state, and (2) languages that don't support tail call optimization (at least in the trivial case of self-recursive tail calls) generally also don't efficiently support recursion, since recursion results in the accumulation of stack frames. A consequence of #1 and #2 is that pure functional languages almost without exception, as well as many less purely functional languages that designed to support programming in a functional style (e.g., Scheme), feature tail call optimization and have tail-recursive constructs as the most idiomatic way of expressing certain algorithms, whereas languages that aren't functional or designed with functional-style programming in mind, often have an iterative approach as the most idiomatic -- and most efficient -- expression of the same algorithms.
Parent
Re:Is it just me ? (Score:5, Informative)
I would add a couple other "must have" features in functional languages:
* The ability to pass a function as an argument to another function (i.e. higher order functions, like qsort in the C standard library).
* Support for a points-free programming style in which things can be passed from one function to another without naming them.
Some other features that perhaps aren't technically required but make functional programming a lot easier:
* Closures, local function definitions, garbage collection, partial evaluation of function.
Parent
Re: (Score:2)
Re: (Score:3, Informative)
I guess I was thinking more of the fairly universal concept that you can use the result of one function as an argument to another without giving it a name. For instance:
result = f(g(x))
instead of
foo = g(x); result = f(foo)
Haskell applies a points-free style in more cases than we're used to seeing in other languages, which is sometimes useful but I agree it is just as often an annoyance to those who are trying to understand someone else's code. I was thinking of a rather looser definition of points
Re: (Score:2)
Yes, I realise all that. I was just pointing out that all functional languages use "recursive style", as ls671 puts it.
Re: (Score:2)
Almost all programming languages support recursion so recursion is recursively redundant ! ;-))
Re: (Score:3, Insightful)
Except that
1. Slashdot thought you're writing HTML and ate half of your code
2. Put it into a module and load in ghci, then try something like "qsort [1..10000]". Watch the slowness.
3. The efficient implementation in Haskell uses iteration and is 100 times less readable than equivalent code in C.
I really like Haskell, but this is not the best example of its strenghts.
Re:Is it just me ? (Score:5, Funny)
Parent
Re: (Score:3, Funny)
See: Recursive
Re:Is it just me ? (Score:4, Informative)
Parent
Re:Is it just me ? (Score:5, Informative)
Erlang and Scala are both languages designed to support programming in a functional style, and both are "recursive style" languages in that they optimize tail calls generally (Erlang) or at least in the most important case of self-recursive calls (Scala) and thus make tail-recursive (or, in Erlang's case, more general tail calling with unlimited depth) programming styles efficient.
Neither is a pure functional programming language, true.
Parent
Re: (Score:2)
If by "recursive style functional programming languages" you mean (more or less) functional programming languages that support tail call optimization so that tail calls, including self-recursive calls, are efficient, then the answer is "yes".
Besides Haskell, Erlang, for instance, is such a language , and
Re: (Score:2)
Interestingly enough, there is talks about implementing “soft tail call” and "“hard tail call” optimization in the JVM:
http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm [sun.com]
Re: (Score:2)
Whether it works or not depends on what your task is and how you try to solve it. There are several ways to do concurrency in Haskell, and they're each appropriate in different instances. If you're just calling a lot of pure functions, then "par" and "seq" might be what you need. If you need shared, mutable state, then STM might be a good approach. If you want to do mes
Re:Is it just me ? (Score:4, Interesting)
The idea is that you can split up the program in parallel tasks in a fully automated way. If you as a programmer even have to think about parallelizing, I’m sorry, but then your compiler is “doin’ it wrong” and your languages is from the stone age. ^^
An a bonus, when you can completely rely on a function with the same input producing the same output, you can also throw caching in there algorithmically (where required, on-demand, whatever you wish)
But bla... that is all just the stuff on the surface. Like explaining the pointlessness of “metaprogramming” when there stops being a difference between data and code.
I find the most amazing thing about Haskell as it is today, is that things that need the addition of new constructs to the language and a big change in the compiler, are just your normal library in Haskell. It can look like a whole new language. But it’s just a library. And that is amazing! ...I just have no words for it...
Then, when you get to the GHC extensions, things that are as much on the forefront of Informatics science as the LHC on physics, with everybody else copying it years later... Sorry, but if you like elegance in programming,
The thing is, that it’s crazy hard to learn. Which is not a fault in language design. Because it’s very elegant. It’s simply the fact that it is so far ahead of anything in your everyday language. You won’t expect to sit in a spaceship and drive it like your car too, would you? Or program the LHC like a VCR.
Yes, I am a fan. Even if I sometimes hate it for being so damn smart compared to me the normal programmer. But I became so much a better programmer in all other languages, it’s crazy.
It’s simply a completely different class of skill. And that is why one should learn Haskell. Fuck the “Oh, we’re now only coding in Haskell” attitude. When you really understand the ideas behind it, every language becomes Haskell. And you can write practically bug-free programs of...
Aaah, what am I saying. <John Cleese>Oh it’s driving me mad... MAD!</John Cleese> *slams cleaver into the table*
*head developer comes in*
Head developer: Easy, Mungo, easy... Mungo... *clutches his head in agony* the war wound!... the wound... the wouuund...
Manager: This is the end! The end! Aaargh!! *stabs himself with a steel lambda sculpture*
Parent
Amazing day... (Score:5, Funny)
Re: (Score:2)
Yeah, and you may thank them when attached to a heart-lung machine that was NOT written in C/C++ instead, because B. Curry’s gonna kick yo ass with that attitude! ;P
Reminds me of Life of Brian... (Score:3, Funny)
"The current committee is still discussing how to go about finding a new committee"
A fitting name for this Haskell programming language might have been "Python" hadn't it all ready been taken.
Re:Reminds me of Life of Brian... (Score:4, Funny)
A fitting name for this Haskell programming language might have been "Python" hadn't it all ready been taken.
Actually, naming it "Python" would be doubly-fitting.. in fact, I think we should rename *all* programming languages "Python", just so it doesn't get confusing :)
Parent
Re:Reminds me of Life of Brian... (Score:5, Funny)
Parent
Re: (Score:3, Funny)
Well that's one way to ensure that Python retains lambdas, map and filter.
But I'm lazy... (Score:5, Funny)
So I don't think I'll look at the article until I actually need to program in Haskel....
Re: (Score:2, Redundant)
Re:But I'm lazy... (Score:5, Insightful)
Parent
Re: (Score:2)
Re: (Score:2)
But learning Haskell is only in a small part about writing Haskell. It’s mainly about getting to the next level in programming skill. And becoming much better in every language.
Besides: Want to earn some big money for doing actual “mission-critical” software, that lives depend on, and that really means something? There’s no way to do serious business like that without Haskell, and not go crazy. ^^
So there you go. If you want to continue doing basically a front-end to a database on co
Oh, be still my heart.... (Score:3, Funny)
Haskell! Haskell! Every geek's favorite mental masturbation toy!
meh (Score:2)
screw all that syntactic sugar, lambda expressions ftw!
NoNPlusKPatterns (Score:2)
NoNPlusKPatterns... Seems that they're finally banned.
http://www.mail-archive.com/haskell@haskell.org/msg01261.html [mail-archive.com]
Re: (Score:2)
Re: (Score:2)
Moreover, the DoAndIfThenElse extension merely extends the "do" syntax with if/then/else clauses; it is syntactic sugar. Empty data declarations are essentially union types unioned over no labels and therefore can have no values except for the bottom value.
References:
http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse [haskell.org]
http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls [haskell.org]
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
EmptyDataDeclarations allows for data types without a constructor... but to be perfectly honest I haven't quite figured out what practical benefit they have :). I'm sure there is a reason, but I don't think it's as trivial or obvious as you make out.
Consider the tag struct idiom in C++:
struct open_read_t {};
struct open_read_write_t {};
class File { // Open for reading. // Open for writing.
File(const string& name, open_read_t);
File(const string& name, open_read_write_t);
};
The tag structs are not used to carry data; their only purpose for existing is to disambiguate the two constructors.
Similarly, in the STL, tag structs are also used to mark iterator categories, to make sure that when you
Re:Concurrency? (Score:5, Funny)
Parent
Re:Concurrency? (Score:5, Insightful)
Well, pure functional languages are (potentially) good for concurrency in general. Because they have no mutable variables in the usual sense, it doesn't actually matter what order functions are evaluated in (other than the fact that callers cannot continue until their callees return). You can't do this in C or Java because it might be necessary for one function to see a variable modified by another. In a functional language, any dependencies are explicit call-return relationships (well, ish, they typically do have some non-functional constructs otherwise it's hard to do IO!), so in principle it's quite easy to split up a program's work across multiple CPUs (or machines) and not worry about whether they need to talk to each other.
Haskell, along with the ML family of languages, also has an amazing type checker that is waaay more sophisticated than most other languages. I think most people who've played around with these languages do start to feel that often "If it compiles, it's bug-free". Obviously that's not something you can rely on, since the compiler can't know what you meant to do. But it is true that the type system is *way* more useful at detecting bugs at compile-time than for any conventional language I've used.
Parent
Re:Concurrency? (Score:4, Interesting)
Well, pure functional languages are (potentially) good for concurrency in general. Because they have no mutable variables in the usual sense, it doesn't actually matter what order functions are evaluated in (other than the fact that callers cannot continue until their callees return).
Maybe you can help me get past one of my mental stumbling-blocks with Haskell, which seems like a really cool language, but which I clearly have no clue about because I don't get a very fundamental thing. As I understand it there are two fundamental claims about Haskell:
1) it is a "pure functional" language, which is therefore entirely and completely and "purely" side-effect-free. I appreciate the immense potential value of this for things like program verification, and I'd love to learn more about it.
2) there is a Haskell construct that is part of the Haskell language called a "monad" that can have side-effects.
I'm a deeply pedantic guy, and I'm unable to reconcile these two claims, and it puts me off looking more deeply into the language every time I read about it because there's clearly something I don't get. It seems to me that either:
a) Haskell is not actually purely functional: it is a purely functional core sub-language with extremely well controlled additional side-effect-producing parts
b) Monads are not actually considered "part" of the Haskell language, in the same way that pre-standardization STL was not "part" of the C++ language.
c) I'm completely missing something.
Enlightenment would be greatly appreciated.
Parent
purity, side-effects, and monads explained (Score:5, Interesting)
Let's see if I can explain this simply.
The Haskell language, like any other language, needed constructs like "read" and "write", but to implement them as simple functions would have broken the underlying assumptions of purity and lazy evaluation.
Haskell happened to have monads. A monad is essentially a typeclass for containers, that allow you to do certain things to combine containers of the same type, without having to worry about what kind of container it is. Most (all?) of the containers in the standard library are instances of Monad.
The Haskell language designers came up with (or perhaps borrowed) an idea. They would create a new container type, called IO, and make it an instance of Monad. However, unlike other containers, it would not have any accessor functions. You can pass around an object around of type IO in pure code all you want, but you can't ever examine the contents of the IO container from within "pure" code. The only thing you can do with it is combine it with other IO objects. Combining two IO objects is equivalent to evaluating the file operation or what have you inside one IO object and passing it's result to and executing whatever is inside the second IO object. The actions within an IO object, however, are free to invoke pure code if they like.
Every haskell program has a main() function, which is an IO action. This allows you do do any necessary file IO your program needs to do, and it can also call out to pure functions. Pure function cannot invoke IO actions. Most Haskell programmers try to keep the IO actions as simple as possible and rely on pure code for the bulk of the program.
As a concrete example, I wrote a ray tracer, which parsed a text file and generated an image. As I was writing it, I got to the part where I needed to write the file parser. I thought "oh, no, this whole thing has to execute within the IO monad and it'll be a big mess". However, it was not so. After scratching my head a bit, I ended up writing a pure function that takes a simple text string and converts it to my internal representation of a scene, ready to be ray traced. Within main (within the IO monad), I would read the text file in with a lazy function "hGetContents", which returns a string which is the contents of the file. I would pass that string to the parser, and then trace a grid of rays (one per pixel) against the parsed scene. The list of pixels with their calculated color values was returned to the IO monad, where I used OpenGL to plot them to the screen.
The interesting bit about this is that hGetContents is lazy. In a strict (i.e. non-lazy) implementation, the whole string would be read at once. This is inefficient, and may cause problems for text files that won't fit in memory. Due to laziness, however, the string is passed into the parser without being fully evaluated. As the parser needs more data, the run-time system will cause hGetContents to read another block. So, here we have an example of a pure function that's indirectly triggering IO, and it's doing it all without violating the constraints of the type system.
Parent
hGetContents is only *technically* typesafe (Score:3, Informative)
Actually hGetContents cheats by using unsafeInterleaveIO. It's a cool hack, but lazy IO is an inherently risk business. For instance, if your program later wrote back changes to your scene file, the result is undefined. There's no guarantee of when the progra
Re: (Score:2)
Yeah the revisions are really tiny (well except for FFI, which also doesn't relate to concurrency). I think the Slashdot poster was trying to say that Haskell in general is nice for concurrency, not these revisions specifically.
With the exception of FFI, these revisions are dreadfully boring. It would be like if a new C standard came out that allowed you to write "floating" instead of just "float". That's about on par with the magnitude of the changes Haskell 2010 brings in :P
Re: (Score:2)