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!

cancel ×

173 comments

Is it just me ? (3, Insightful)

ls671 (1122017) | more than 4 years ago | (#30219458)

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

Anonymous Coward | more than 4 years ago | (#30219702)

No, you're not the only one, but the vast majority of those people just don't know and have never written anything serious in a functional language. Playing at the REPL doesn't count, you have to write a real program like darcs or yi or xmonad or something.

I spend my days writing interactive GUI apps in haskell, some concurrent, some not, and it's a joy. Writing with locks and heavyweight threads and mutating objects everywhere sounds like a nightmare to me. Except things which are mostly library glue, I can't think of many jobs haskell doesn't suit.

Except compiling quickly. ghc is not so great there...

Re:Is it just me ? (1)

oldhack (1037484) | more than 4 years ago | (#30219884)

"Writing with locks and heavyweight threads and mutating objects everywhere sounds like a nightmare to me."

Past the simplest trivial scenario, it is a nightmare. But asynchronous message-passing scheme works reasonably well.

I don't know of any widely used multi-threaded GUI kit.

Re:Is it just me ? (4, Insightful)

rjh (40933) | more than 4 years ago | (#30219722)

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.

Re:Is it just me ? (5, Informative)

EMG at MU (1194965) | more than 4 years ago | (#30220422)

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.

Re:Is it just me ? (1)

SparafucileMan (544171) | more than 4 years ago | (#30221568)

This is also known as the No Free Lunch Theorem and traces right back to Godel, Turing, and the foundations of all mathematics. You are right, it certainly isn't going anywhere.

Re:Is it just me ? (2, Informative)

jensend (71114) | more than 4 years ago | (#30221818)

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:Is it just me ? (1)

rjh (40933) | more than 4 years ago | (#30221828)

You're correct when you say that if you parallelize 50% of your algorithm, you still have to deal with the other 50%. However, new theoretical discoveries are made all the time in algorithm design; new theoretical advances may result in an equivalent algorithm that's 90% parallelizable.

Amdahl's Law is a strong mathematical constraint on the maximum improvement in performance for a particular algorithm. In order to get past Amdahl's Law, use a different algorithm.

I freely confess to having used "get past Amdahl's Law" in a pretty loose and informal sense, though, so as to avoid that digression. :)

Re:Is it just me ? (2, Insightful)

bertok (226922) | more than 4 years ago | (#30221992)

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, take a look at computer games, where you'd just do "higher resolution", or "bigger textures", or "more complex shaders". You do more, while the sequential stuff stays much the same.

I can't stand it when people trot out Amhdal's law like it's some sort of reason that parallelization is futile or something. It's missing the point completely!

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30220462)

Renaissance implies a certain significance or magnitude. There is no need to call it enormous too.

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30220826)

Logging onto a message board implies a certain amount of not being a dick. There is no need to be such an enormous one.

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30221126)

What a great opportunity for a pizza analogy!

I'll take mine deep-style, with a whole load of extra dick!

Pizza analogy FTW!

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30221068)

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.

Recursion basically does the same thing, albeit through function calls and argument passing. The difference is that it is "cleaner" because it's incredibly simple, and because there are no state changes. In Lisp languages you can just build your own looping constructs that use recursion under the hood, and get the best of both worlds.

Of course the Lisp languages don't rigidly enforce a purely functional style like Haskell does, but if you want to program in a purely functional way, they certainly have the tools to do that. Actually, if you wanted to make your own parallel "Haskell" in Lisp, that would be possible since it excels at constructing metalanguages, and can make very quick foreign function calls to C/C++ libraries for multiprocessing or threading.

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30221120)

This is comment is not +5 insightful its incorrect. You don't understand Ahmdal's Law. Any algorithm that is fundamentally iterative, in that in relies on the results of the last iteration, will quickly reach an upper limit of improvement by making it more multithreaded and adding more processors. Many, many algorithms are like this. Don't believe me? Just try parallelizing Dijkstras...

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30221686)

Then why aren't the FP shops kicking as and taking names? They should be leading in every segment of the market if what you wrote is true. It isn't. This is because FP isn't this magical pixie dust that so many claim it to be. That the compilers produce extremely slow code doesn't help matters. It really doesn't matter if your code runs on 8 processors if the C version is 10x faster on a single core.

Re:Is it just me ? (1)

abigor (540274) | more than 4 years ago | (#30221840)

Actually, it's because functional programming is hard and not typically taught well in school. People learn imperative languages first, and tend to end up thinking that way. Lots of functional languages such as O'Caml compile to very fast runtimes.

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30222212)

Functional languages do support iteration. It is just implemented as internal vs. external iteration. Both are valid forms and not unique to functional languages (e.g. Smalltalk used them). Side-effects are always necessary and must be handled and pure OO doesn't have anything inherently incompatible, just that the OO implementations that we use are far from pure.

You never get "past" Amdahl's Law, no matter how loosely you want to state it. A change in algorithms doesn't work around it, it just changes the variable values. Instead of fighting Amdahl's law head-on you must change your perspective to focus on Gustafson's law instead.

Re:Is it just me ? (1)

lorenlal (164133) | more than 4 years ago | (#30219740)

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

arevos (659374) | more than 4 years ago | (#30219832)

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.

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30219958)

Except neither Scala nor Erlang are functional languages ....

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30220146)

How are they not?

Re:Is it just me ? (3, Informative)

j1m+5n0w (749199) | more than 4 years ago | (#30220260)

That's not true unless you are using a different definition of "functional" than I am. I can't comment on Scala since I haven't used it, but Erlang is indeed a functional language. It is not a _pure_ functional language, as Erlang does have some mechanisms for manipulating mutable, global state and message passing, but it's at least as functional as a lot of other language that are widely regarded as "functional programming languages" such as Lisp and ML.

Re:Is it just me ? (-1)

Anonymous Coward | more than 4 years ago | (#30221034)

So if we allow "non pure" functional languages to be "functional languages" then the whole notion of being functional becomes irrelevant. Java can be considered a non-pure functional language.

To me "functional" means referentially transparent, and neither Scala nor Erlang are referentially transparent.

The whole point here is that the original poster was talking about concurrency and being "functional", and then discussed Erlang and Scala. But in both languages concurrency is done in totally non functional way with threads/processes whose state changes. Thats the very definition of non-functional.

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30221188)

Nobody cares what you think.

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30221202)

To you "functional" means . . . who the fuck are you?
Every other functional language out there has to call itself "mostly functional" nowadays because the Haskell guys have been such shits about claiming the term "pure functional" for themselves.
It's bad enough without double-shits like you just making up your own definitions.

Re:Is it just me ? (1)

DragonWriter (970822) | more than 4 years ago | (#30221320)

So if we allow "non pure" functional languages to be "functional languages" then the whole notion of being functional becomes irrelevant.

Not really. In fact, I think its much more useful to discuss the value of functional languages in terms of the benefits of specific features and differences of degree or, rather than just a binary categorization.

Java can be considered a non-pure functional language.

Sure, in the same sense that a pit of mud can be considered a non-pure body of water. Likewise, one can meaningfully differentiate between the non-pure functional status of Java, the non-pure functional status of Scheme, and the non-pure functional status of Erlang, and the effects of those on their utility for various programming applications, just as one can meaningfully differentiate between the non-pure water of the aforementioned mud pit, that of a somewhat silty river, and that of a fairly clear mountain lake, and the effects of those differences on their utility as a source of drinking water.

Re:Is it just me ? (1, Funny)

Anonymous Coward | more than 4 years ago | (#30221590)

Car analogies are simpler.

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30222156)

think it over for a minute retard. There is no "pure functional" programming because it would be optimized back to a single, constant value, which is thrown away. To be anything more than math masturbation, you need input and output, which are non functional.

Re:Is it just me ? (4, Informative)

DragonWriter (970822) | more than 4 years ago | (#30220532)

Except neither Scala nor Erlang are functional languages ....

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.

Re:Is it just me ? (1)

Pseudonym (62607) | more than 4 years ago | (#30221374)

Exactly.

Erlang actually owes more to Linda and Prolog than to languages that we usually think of as "functional" (like the Lisp/Scheme family and the ISWIM family). But still, Erlang is functional in the same way that Java is object-oriented and C++ is generic.

If you've ever programmed in a "true" object-oriented language, like Smalltalk or Eiffel, Java seems clunky. If you've ever used a programming language with "true" parametric polymorphism, like ML or Haskell, C++ seems clunky. (Actually, they seem clunky even if you haven't, but that's another story.)

It makes sense to say that Java supports object-oriented programming and C++ supports parametric polymorphism. Erlang supports functional programming in the same way.

Re:Is it just me ? (3, Informative)

ls671 (1122017) | more than 4 years ago | (#30220086)

> 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" ).

Re:Is it just me ? (1)

arevos (659374) | more than 4 years ago | (#30220246)

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

DragonWriter (970822) | more than 4 years ago | (#30220390)

Well, all functional programming languages use recursion

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.

Re:Is it just me ? (4, Informative)

j1m+5n0w (749199) | more than 4 years ago | (#30220698)

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.

Re:Is it just me ? (1)

DragonWriter (970822) | more than 4 years ago | (#30221134)

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).

Yeah, I'd agree that first-class functions are a requirement.

* Support for a points-free programming style in which things can be passed from one function to another without naming them.

I don't think this is a requirement for a language to be a functional programming language, though its certainly nice to have.

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.

I'm not sure I'd put "local function definitions" in the nice-to-have category rather than the definitional; if functions are first class values, it would be, at a minimum, very odd not to be able to define them locally. Generally, though, I agree.

Closures are probably really necessary. (1)

Estanislao Martnez (203477) | more than 4 years ago | (#30221408)

Closures are a mechanism that allows you to efficiently write a function that can produce infinitely many different functions as its output. Functional programming without closures would either be a big pain, or would involve compiling new functions at runtime all the time. There might even be things that you provably can't do without closures; in the lambda calculus, beta-substitution can substitute free variables inside a lambda abstraction with values from outside its scope, so it comes down to whether certain restrictions on substitution impair Turing completeness.

And once you have closures, you need garbage collection.

Re:Is it just me ? (1)

shutdown -p now (807394) | more than 4 years ago | (#30222222)

First of all, for a language to be called "functional", you need first-class functions (duh). What this means is that a function is "just another value" - it can be passed around in function arguments and returned, assigned/bound to a variable, and so on. But this also generally means first-class "function literals" - anonymous functions, lambdas, and so on - and for that you need closures. Furthermore, once you get closures and function-typed return values, you have to have some form of automatic memory management - how else will you know when to release the variables captured by a particular closure when it is released itself (and keep in mind that closures and their captures can form circular references)?

Partial application can then be considered syntactic sugar for anonymous functions, and so can local function definitions (treat them as function values bound to local variables).

Re:Is it just me ? (1)

arevos (659374) | more than 4 years ago | (#30221140)

Yes, I realise all that. I was just pointing out that all functional languages use "recursive style", as ls671 puts it.

Re:Is it just me ? (1)

ls671 (1122017) | more than 4 years ago | (#30220432)

Almost all programming languages support recursion so recursion is recursively redundant ! ;-))

Re:Is it just me ? (2, Insightful)

harry666t (1062422) | more than 4 years ago | (#30220332)

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

Captain Segfault (686912) | more than 4 years ago | (#30221108)

Well, yes, quicksort is slow in the worst case, which in the most naive implementations includes a sorted input. That isn't Haskell's fault, and you don't need iteration to implement something like median-of-3 which would fix the problem.

on haskell quicksort (1)

j1m+5n0w (749199) | more than 4 years ago | (#30221244)

I agree it's not always the best example, but there are four reasons why "qsort [1..10000]" is slow, and you can address three of them without writing something that's "100 times less readable than C".

The first problem is that naive quicksort on an already-sorted list/array is O(N^2). The fix is to grab an element out of the middle and use that as your pivot. That alone will make qsort far faster. (I tried it.*) The resulting code is, of course, a bit messier.

Secondly, the qsort function has no type signature, so it will default to the most polymorphic implementation, which is something like qsort :: Num a -> [a] -> [a]. Typing "qsort [1..10000] probably (though I'm not sure, it's a ghci-specific thing) defaults to using Integer, which is less efficient than a machine Int. If you constrain the type signature the code will be faster.

Thirdly, you're using ghci. Code compiled with "ghc -O2" is far faster. (Be sure not forget that -O2, it make the code about 10x faster.)

The fourth reason is that C is doing in-place array swaps. (You can do the same thing in Haskell using the ST monad if you really want to. I don't think the result will be "100 times less readable", but it will be fairly ugly compared to the pure version. There are a couple such implementation here [haskell.org] .) Whether doing quicksort with lists is good enough really depends on what you're doing.

* Quicksort modified with a swap, then mangled by slashdot:

module Qsort where qsort [] = [] qsort xs = let n = length xs in if n > 100 then let split = n `div` 2 (a,b) = splitAt split xs in _qsort $ (xs!!split) : (a ++ (tail b)) else _qsort xs _qsort [] = [] _qsort (x:xs) = qsort (filter (= x) xs)

Re:on haskell quicksort (1)

Pseudonym (62607) | more than 4 years ago | (#30221632)

Right, quicksort is almost always the wrong answer if you're sorting linked lists, as you are here.

But consider a more complex algorithm, such as bottom-up polyphase merge sort. (WARNING: Untested code follows.)


sort = mergePhase . generateRuns

generateRuns [] = []
generateRuns (x:xs) = split xs x x (x:)
        where
                split [] _ _ _ k = k []
                split (x:xs) minx maxx k
                    | x >= maxx = split xs minx x (k . (x:))
                    | x < minx = split xs x maxx ((x:) . k)
                    | otherwise = k [] : split xs x x (x:)

mergePhase [] = []
mergePhase [xs] = xs
mergePhase xss = mergePhase (mergePass xss)
        where
                mergePass (xs1 : xs2 : xss) = merge xs1 xs2 : mergePass xss
                mergePass xss = xss

merge [] ys = ys
merge xs [] = xs
merge (x:xs) (y:ys)
        | x <= y = x : merge xs (y:ys)
        | otherwise = y : merge (x:xs) ys

It's a bit longer, but it's surprisingly fast and robust considering how little code is here. Especially interesting is the way that lazy evaluation works here; what looks like multiple passes are interleaved to preserve locality in a way that would require a lot more code in a conventional language. Also note the use of difference lists in the run generation phase; many languages would require extra reference/pointer hackery to achieve this.

Re:Is it just me ? (5, Funny)

ascari (1400977) | more than 4 years ago | (#30221082)

"recursive style" Definition: Curse. And then curse again.

Re:Is it just me ? (1)

oldhack (1037484) | more than 4 years ago | (#30221328)

I'm lost. And then what?

Re:Is it just me ? (2, Funny)

unitron (5733) | more than 4 years ago | (#30222488)

See: Recursive

Re:Is it just me ? (1)

DragonWriter (970822) | more than 4 years ago | (#30220256)

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.

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 concurrent applications are one of its main strengths.

Re:Is it just me ? (1)

ls671 (1122017) | more than 4 years ago | (#30220996)

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:Is it just me ? (1)

j1m+5n0w (749199) | more than 4 years ago | (#30220584)

I wrote some code in that category but I never envisioned a functional programming language would suit the job. Am I the only one ? ;-))

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 message passing or traditional locking, then using Chan and/or Mvar in the IO monad might be the right thing.

I'd recommend looking at Real World Haskell [realworldhaskell.org] chapters 24 and 28.

Re:Is it just me ? (3, Interesting)

Hurricane78 (562437) | more than 4 years ago | (#30220672)

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!
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, ...I just have no words for it...

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*

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30221350)

Except of course when you add "par" and "seq" to Haskell you fundamentally change it's semantics. Haskell semantics are non-strict, but "par" changes that as you may evaluate expressions that you don't use -- i.e. it's no longer non-strict ..

Re:Is it just me ? (0)

Anonymous Coward | more than 4 years ago | (#30222008)

You won’t expect to sit in a spaceship and drive it like your car too, would you?

Why not?

As the pilot, my wishes are simple: I want to move up and down and backward and forward. Why shouldn't the system abstract complex functionality to allow me to do this easily?

Assembly code is much more difficult than Haskell. Are you suggesting it should be otherwise?

Re:Is it just me ? (1)

microbox (704317) | more than 4 years ago | (#30222040)

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.

This is not true in high-performance computing. If you don't want your CPU spinning its wheels on locks and cache misses, then you need to go quite low level -- and really think about the data structures you're using, and how to parallise tasks with next to no interthread communication.

Amazing day... (4, Funny)

AnotherShep (599837) | more than 4 years ago | (#30219482)

And all three of its users are overjoyed.

Re:Amazing day... (0)

Anonymous Coward | more than 4 years ago | (#30219950)

You mean there are *that* many?!!!

Re:Amazing day... (1)

acheron12 (1268924) | more than 4 years ago | (#30220074)

It's surprisingly popular on Project Euler.

Re:Amazing day... (0)

Anonymous Coward | more than 4 years ago | (#30220252)

No it has three users but they register a thousand handles each on popular sites and spend their time telling normal people that they would be so much happier if they embraced the Haskell.

Re:Amazing day... (0)

Anonymous Coward | more than 4 years ago | (#30220354)

ever been to reddit? proggit is full of haskellers

Re:Amazing day... (0)

Anonymous Coward | more than 4 years ago | (#30221516)

ever been to reddit? proggit is full of haskellers

"proggit" is also full of brainless high school kids and college students who can't program their way out of a paper bag.

The popularity of Haskell on proggit has more to do with the aforementioned group wanting to be trendy than it does with the actual use of Haskell for anything non-trivial.

Re:Amazing day... (0)

Anonymous Coward | more than 4 years ago | (#30220566)

You're absolutly right. Who needs anything besides BASIC.

Re:Amazing day... (1)

Mr.Z of the LotFC (880939) | more than 4 years ago | (#30222428)

I once wrote a lambda-calculus evaluator in QBASIC (before I heard of Scheme & later Haskell), so I guess so. :)

Re:Amazing day... (1)

Hurricane78 (562437) | more than 4 years ago | (#30220700)

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

Re:Amazing day... (0)

Anonymous Coward | more than 4 years ago | (#30222276)

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

I hear this all the time on slashdot and really think it is misinformed. Honestly, how many pieces of medical equipment have their software written in Haskel or any of of the similar language? These devices more often than not use an embedded OS (or more and more Linux these days) with C or C++ applications.

Perhaps there is some researchers using these languages or the rare piece of gear, but in industry the old standby system languages are still king. Don't agree...take a look at the Jobs boards for Phillips, Siemens, Nihon Koden, GE Healthcare, Welch Allen, and other healthcare equipment manufacturers and see the skills they are looking for. I'm talking about patient monitors, diagnostic cardiology equipment, CT, MR, digital x-ray, Anesthesia machines, ventilators, invasive cardiology suites, bone densitometers.

Not to sound like an ass, but... (1)

XPeter (1429763) | more than 4 years ago | (#30219540)

What the hell have these guys been doing for the past four years? Only now they are implementing DoAndIfThenElse/EmptyDataDeclarations

Is this the Slackware of the programming world?

Re:Not to sound like an ass, but... (1)

xZgf6xHx2uhoAj9D (1160707) | more than 4 years ago | (#30219656)

Those things were implemented many years ago. The new standard only standardizes features which have been stable in multiple implementations for years. That's how standards are supposed to work.

Re:Not to sound like an ass, but... (1)

Ann Coulter (614889) | more than 4 years ago | (#30219754)

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:Not to sound like an ass, but... (3, Insightful)

ascari (1400977) | more than 4 years ago | (#30221130)

The fact that union types can have no values explains a lot about Jimmy Hoffa.

Re:Not to sound like an ass, but... (0)

Anonymous Coward | more than 4 years ago | (#30219938)

DoAndIfThenElse isn't a new feature; it just addresses some unintuitive syntax when using multiline "if-then-else" forms in a "do" block.

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.

Re:Not to sound like an ass, but... (2, Interesting)

Pseudonym (62607) | more than 4 years ago | (#30221712)

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 {
        File(const string& name, open_read_t); // Open for reading.
        File(const string& name, open_read_write_t); // Open for writing.
};

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 could use more than one algorithm for a container, the most appropriate one is selected.

This is essentially what empty data declarations are for in Haskell, except that by having no constructors, you can guarantee that they will never be instantiated. The most common use is in conjunction with phantom types [haskell.org] .

Reminds me of Life of Brian... (2, Funny)

migla (1099771) | more than 4 years ago | (#30219556)

"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... (3, Funny)

schon (31600) | more than 4 years ago | (#30219894)

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 :)

Re:Reminds me of Life of Brian... (5, Funny)

acheron12 (1268924) | more than 4 years ago | (#30220052)

Welcome to the programming language department. Bruce here teaches Python, the object oriented dynamically typed language. Bruce teaches Python the lazy functional language, while Bruce teaches postfix Python. And then there's Bruce who teaches s-expression Python and is in charge of the snake dip.

Re:Reminds me of Life of Brian... (2, Funny)

Pseudonym (62607) | more than 4 years ago | (#30221740)

Well that's one way to ensure that Python retains lambdas, map and filter.

But I'm lazy... (5, Funny)

nweaver (113078) | more than 4 years ago | (#30219560)

So I don't think I'll look at the article until I actually need to program in Haskel....

Re:But I'm lazy... (1, Redundant)

AlgorithMan (937244) | more than 4 years ago | (#30219730)

you could do a lazy evaluation of TFA...

Re:But I'm lazy... (4, Insightful)

Ma8thew (861741) | more than 4 years ago | (#30219946)

That might be the joke.

Re:But I'm lazy... (1)

AlgorithMan (937244) | more than 4 years ago | (#30220348)

dang, you're right *selfpwned*

Re:But I'm lazy... (0)

Anonymous Coward | more than 4 years ago | (#30221530)

Sorry, I only read jokes when there's someone to listen to me laugh

Re:But I'm lazy... (1)

Hurricane78 (562437) | more than 4 years ago | (#30220780)

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 color mixing machines, or a sales system, to earn enough to live, then go ahead, continue doing C++/Java/Delphi. :)

Concurrency? (1)

qmaqdk (522323) | more than 4 years ago | (#30219580)

I skimmed through the revisions, and I don't see how they relate to concurrency (caveat I'm a Haskell newbie). Maybe someone can enlighten me.

Re:Concurrency? (4, Funny)

AnotherShep (599837) | more than 4 years ago | (#30219764)

They figure if they make it good enough, more than one person will code in it at a time.

Re:Concurrency? (0)

Anonymous Coward | more than 4 years ago | (#30220356)

Ha! Sadly, I wasted my last mod points on some jibberish about graphics cards.

Re:Concurrency? (4, Insightful)

Lemming Mark (849014) | more than 4 years ago | (#30220100)

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.

Re:Concurrency? (3, Interesting)

radtea (464814) | more than 4 years ago | (#30221682)

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.

Re:Concurrency? (1)

Lemming Mark (849014) | more than 4 years ago | (#30221814)

Heh, to be honest I'm mostly in the same boat as you - how can Haskell do side-effect stuff whilst still being purely functional. And what on earth is a Monad!?

A programmer friend of mine used to say that using monads to emulate state would be a bit like the following: imagine you want to emulate state but you're programming functionally. You want variables but you can't have them. Instead you have a big tuple of values representing the contents of all the "variables" and you pass this tuple to every function call and get back a new version with the variables updated. You're still programming purely functionally but you've got this emulation of mutable state.

But I mentioned this to another friend who has a PhD in compsci, specialising in compiler design and he looked at me like I was insane - so apparently that's not a good representation of how they behave. Still, it at least gets you a feel for how you could have imperative constructs like variables without breaking the rules of pure functional programming. Maybe that makes the idea of monads seem a little less impossible, even if it doesn't help explain how they work?

Other "functional" languages actually have an imperative subset (e.g. ML has variables, loop constructs, etc). Haskell is distinguished from those partly by being purely functional, so I presume that it really *is* purely functional by some definition, including the monads. But I can't say I understand how.

I had to study the type system of ML as an undergrad and it had this property of looking really opaque to me until I'd stared at it for hours and hours, then suddenly I went "Ooooh, I see!". Monads have a similar feel to me but I've never taken the time to stare them down. That said I imagine that, like the ML type system, they're much easier to use than to fully understand.

Re:Concurrency? (0)

Anonymous Coward | more than 4 years ago | (#30221900)

The IO monad is implemented as

type IO a = World -> (a,World)

so that

print :: String -> IO ()

is implemented as

print str world = world { stdout = stdout++str }

i.e. print takes the world and returns the modified world.

Maybe that's the way it's defined, but if an implementation doesn't do it exactly that way it's just an optimisation.

Re:Concurrency? (0)

Anonymous Coward | more than 4 years ago | (#30221928)

Well, none of a b or c are quite right, though "a" is closest. "c" is not right because you're only *somewhat* missing something :)

Monads in haskell are pure. The IO monad lets you paste together IO values in a way that they remain opaque.

Where the magic happens is that the 'main' function has type 'IO ()', which is probably actually a bunch of actions pasted together as above. Now, the *runtime* is the one that calls main. It gets the 'IO ()' back and executes it. The runtime is *not* functional, in fact GHC's runtime is written in C. And it's not haskell either, so haskell is actually pure.

One practical result is that actions in haskell are values like any other. This is incredibly useful. For instance, just one thing, is that you can write your own control structures. But you can do a lot of other things once you can pass actions around.

Re:Concurrency? (1)

radtea (464814) | more than 4 years ago | (#30222270)

Monads in haskell are pure. The IO monad lets you paste together IO values in a way that they remain opaque.

After staring at this explanation for fifteen minutes I feel deep sympathy for the people on /. who try to understand my comments on physics, because I imagine they make as little sense to them as this does to me :-D

I think I kind of understand what you're saying: a monad is created on-the-fly by the (non-Haskell) runtime as an immutable object.

I'm still tempted to quibble at the difference between "opaque" and "side effect free". Hidden side effects are still side effects, although I guess so long as they truly are opaque then the formal constraints on the language are still enforceable, and one gets the power of pure functional programming out of it.

That's what I really wasn't understanding: Haskell does let you create side effects. But it is still a "pure functional" language in the sense that the side effects are implemented in such a way that you can still analyze Haskell programs as pure functional programs, because the side effects that Haskell lets you create are entirely hidden from the universe that Haskell knows about.

So, to pay you back with an obscure comment from my own area of expertise: it's a bit like our universe being strictly causal under SR, but QM still being able to have acausal spooky actions at a distance. That's an analogy I can get behind.

Re:Concurrency? (1)

Mr.Z of the LotFC (880939) | more than 4 years ago | (#30222490)

A monad is a construction that hides all the tuple-passing so that the program is more readable. E.g. code using the IO monad passes an object of type World from one line to the next without having to explicitly write it as an argument. It looks like procedural code (such as do x <- getLine ; putStrLn ("Greetings, " ++ x)), but instead of messing with the world in the background the world gets passed around as just another value.

Speaking of physics...too bad we cannot make copies of the world, do computations in each, & then combine the different instances in various ways, or we could program time travel (among other things).

Re:Concurrency? (1)

shutdown -p now (807394) | more than 4 years ago | (#30222312)

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.

Actually, I dare say that Haskell type system is in fact a much bigger deal than its purity or laziness. Type classes are an awesome generalization of OO interfaces that let one define virtually arbitrary operators in a generic way, and then define generic algorithms using those operators, in an entirely type-safe way (and not using the C++ template model of "macros with a quick sanity check at declaration point and horrible error messages if anything goes wrong later"). They can be used to fully emulate conventional OO in fact. Then there are higher-order types [wikipedia.org] , which let you reuse operations on types just as you use functions to reuse operations on values.

Not to forget GHC extensions to Haskell, which let you control how exactly types are generalized - to consider what this means, try defining a generic function in C++, Java or C# that takes a collection of objects, which must all be instances of any class C implementing interface I - but they must all be instances of that same class (and not, say, some instances of C1 and some instances of C2, both implementing I).

Re:Concurrency? (1)

xZgf6xHx2uhoAj9D (1160707) | more than 4 years ago | (#30220176)

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

j1m+5n0w (749199) | more than 4 years ago | (#30220374)

The announcement is perhaps a bit less interesting than the summary would have you believe... The most recent Haskell standard was Haskell 98, eleven years ago. A new committee was formed to bring the standard up to date with current implementations. Most of the changes listed have been in GHC and other implementations for some time now, and none of them appear to have anything to do with concurrency directly. (Which isn't to say that interesting stuff hasn't been happening in the Haskell world in that area, it just doesn't directly affect the core language.)

Oh, be still my heart.... (2, Funny)

gestalt_n_pepper (991155) | more than 4 years ago | (#30219586)

Haskell! Haskell! Every geek's favorite mental masturbation toy!

Re:Oh, be still my heart.... (0)

Red Flayer (890720) | more than 4 years ago | (#30219728)

Haskell! Haskell! Every geek's favorite mental masturbation toy!

Speak for yourself. My favorite mental masturbation toy is slashdot. Where else can I get my mental rocks off by emulating Yakov?

In Soviet Russia, Haskell masturbates to you!

Re:Oh, be still my heart.... (0)

Anonymous Coward | more than 4 years ago | (#30222080)

Masturbation can be fun.

meh (1)

AlgorithMan (937244) | more than 4 years ago | (#30219844)

Haskell can't compete with my implementation of the pure lambda calculus!
screw all that syntactic sugar, lambda expressions ftw!

Gee (0)

Anonymous Coward | more than 4 years ago | (#30221640)

How many languages does it take to tell Mrs. Cleaver how lovely she looks today?

Ward, don't be too hard on the Beaver (1)

unitron (5733) | more than 4 years ago | (#30222518)

The revision to which I look forward is the hack that causes it to make very impolite comments to Mrs. Cleaver.

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...