Slashdot Mirror

It doesn't do anything that other languages don't, probably better, its syntax is weird, and it uses "significant white space", which most programmers I know do not like.

Most programmers that I know don't like significant white space as it has been done in Python, for sure, but most programmers that I know don't know that Python's realisation isn't the only way it can be done. In almost 30 years of using David Turner family languages (of which Haskell is the only one that still exists), I've only ever seen one complaint (made many, many times!) about the indentation rules and it's been fixed.

I'm pretty sure that the supposed productivity improvements of using Python don't exist. You're either doing something extremely simple (which Python is admittedly good at) or you're not counting the time spent testing and debugging as part of the time spent developing.

In a language with a high-quality type system, a large class of bugs don't make it through the compiler. Fixing those bugs doesn't feel productive, but in my experience it takes less time overall than having to find the bugs yourself.

It's just a very verbose language, a very verbose style, and a very verbose library API.

The functions you linked to can be be fully understood with a few quick glances, and are almost trivial. Are you seriously that easily overwhelmed?

Get back to me when you have been coding for 40 years, and your code resembles something from the latest CS / category theory papers, giving you more in one line, than an entire of the linked functions. E.g. fun stuff, like this: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/lang.html

Maybe you should stay with your <100 lines Python scripts.

Every language is like this

... but not equally. Some are much worse than others. If you were starting a big new project, and expecting to write tens of thousands of lines of code, then Java or C++ would be reasonable choices. Haskell or some other FP language would not. Here is a list of Haskell programs. The list is short, is mostly small programs, and many of them are mathematical utilities, which is a narrow field were FP actually makes sense.

That's only partly true. Modern strongly typed languages make it very cheap to create a new compiler-checked type and free to use at run-time. This encourages the use of "strong typedefs" which a programmer can use to get the type checker to check other kinds of bugs.

So, for example, you can get the compiler to check physical units. If you divide a "distance" by a "time", you'd better assign it to a variable of type "velocity".

That's just bad functional code. What you are describing (though the notation is hard to follow) sounds like a fold. https://wiki.haskell.org/Fold
That has final and initial values.

The other thing is you don't want to be "doing stuff" and iterating. You want to be computing stuff and then "doing stuff" on the entire set of output. The system as it pulls output will drive the iteration on the computation. What you have above is sequenced. Getting rid of explicit sequencing is part of writing functional code.

Except in Haskell

Facebook, Google, Microsoft, Intel, see: Haskell in industry: https://wiki.haskell.org/Haske... I don't know when you were in school, but if it was in the 90s (like me); the FP landscape has changed quite a bit since then. I did the edX course FP101x Introduction to Functional Programming (98%), which I can highly recommend to get a feel for Haskell.

"So I agree with you, there is no reason for your opening post to be thought of as a troll."
Actually yes there is.
You see we have this thing called the internet and the internet has services one is called Google and another is called Wikipedia.
You see something you do not know about you have too options.
1. Look it up and find out what it is.
or
2. Dismiss it because it is outside your area of knowledge.

By dismissing it you are being a jerk. This is Slashdot so a cool programing language is still a cool programing language even it it is not super popular. Here are some systems written in Haskell
https://wiki.haskell.org/Haske...

In other words it is really dumb to take pride in what you do not know.

Haskell has a nice search engine for functions: https://www.haskell.org/hoogle...
Given that Haskell's type system is rather expressive, you can give the type of the function and expect to find what you are looking for.
A good example is https://www.haskell.org/hoogle...
It returns Sort and HeapSort as top results.

Haskell has a nice search engine for functions: https://www.haskell.org/hoogle...
Given that Haskell's type system is rather expressive, you can give the type of the function and expect to find what you are looking for.
A good example is https://www.haskell.org/hoogle...
It returns Sort and HeapSort as top results.

Look into strongly/statically typed languages with type inference (e.g.: Haskell, Idris, Agda, ML).
example

(* This is comment syntax in ML-derived languages, like Ur *)

/* This is comment syntax in C-derived languages, like C */

double 4 (* = 8 *)

Is Ur for

double(4); /* == 8 */

Your comment (pun intended) is an example of Wadler's Law

Haskell is the only language with code specifically designed to launch (or prevent the unintended side-effect of launching) missiles.

You might have meant:
http://blog.sigfpe.com/2006/08...
http://www.haskell.org/haskell...

1) Why distinguish client from server?

2) Server technology is advancing.

3) Client technology isn't that fragmented.

GP's "best match based on the parameters at run-time"

Perhaps should have been said as "... the environment at run-time", rather than the parameters given to the function itself.

However, dispatch can certainly be done on the parameters given to the function itself without engaging in anything but the strictest of static typing. Generic programming selecting on types is a reasonably common pattern in Haskell, which is about as far from your sense of "duck typing" as you can get.

http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/generic-programming.html

What bad habits? Logic of whatever type you want to implement is inherently sequential.

No, it is not. Logic is inherently reflexive and transitive. It's a major failing in math education, that people think it is about performing algorithms in sequence. Most people never learn the relations that allow you to rearrange the equations and create new algorithms.

In programming, the idea of sequential programming has problems. CPython guarantees that only one bytecode is executing at one time, and therefore they find it extremely difficult to remove the Global Interpreter Lock. C guarantees sequence only between sequence points, and makes liberal use of undefined behavior. Even Javascript, with its relatively simple model, has variable hoisting that catches beginners by surprise. Locking limits scalability, and shared-memory multi-threading is so difficult that it's believed that almost nobody knows how to do it properly. I think it was Crockford who said that the programmers who understand multi-threading should be captured and compelled to do systems programming, but I'm not sure.

Declarative and functional programming don't require execution in a particular sequence. The canonical example of this is Haskell, with its lazy evaluation, but logic programming is based on this idea, and even event-driven programming is like programming inside-out for a sequential programmer.

ispc, OpenCL, and LLVM on the way. Failing that, you could of course use C++ and AVX intrinsics (which would be a good choice if you already have a load of SSE4/AVX optimised code lying about).

There actually is a Haskell FPS. State manipulation is a little awkward in some ways, in part because there isn't a universally agreed-on way to do it, but the tools are getting better. With lenses on top of a State monad, things start to look pretty similar to an imperative language, except that you get the benefits of functional programming as well (for instance, error handling is a lot easier when you don't have to back out a bunch of changes because you still have your original state lying around).

Yeah, and here are some applications that run in demanding environments, that were not written in C++, and that you would probably be hard-pressed to write in C++ (at least with the same results):

https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool

https://en.wikipedia.org/wiki/FFTW

http://www.haskell.org/haskellwiki/Haskell_in_industry

Hm, that's interesting -- demanding environments, high stakes, and no C++. This might be a clue; it is the experience of a team working in another demanding environment, that used some C++ code but mostly Lisp, who were not terribly impressed by what they saw with C++ (it seems like it was more of a chore for them):

http://www.paulgraham.com/carl.html

Of course, that was ten years ago. Times have changed; now C++ has r-value references and smart pointers!

The words 'error' and 'exception' do not have fixed interpretations. Indeed, they can be the exact opposite of your usage: http://www.haskell.org/haskellwiki/Error_vs._Exception.

It is important to remember that while a naive approach to functional programming (that is, using the same data structures and idioms as for imperative languages), will indeed be inefficient due to enforced persistence, much of the loss can be mitigated by using better data structures. For instance, Data.Sequence of Haskell supports access and modification time logrithmic in the closest distance to one end of the sequence, and does so in a thread safe (as always) way.

Even in the case where we demand mutable data structures because nothing else is acceptable, we can control the access in a purely functional way using monads (a very cool concept which arent as scary as they first might seem). See for instance, the haskell State monad and mutable data structures.

Microsoft R&D has been around for more than a decade and I am still waiting for that fabled amazing product done with fundamental research!

.NET is one example of that - a lot about the VM and the type system (esp. generics) came straight out of MSR. More recently, F# is a commercialized product that originated directly from MSR. And then GHC, while a community FOSS project, is developed to a large extent by MSR employees.

It sounds like what you want is a window manager and not a GUI. Excellent Window managers are Linux's strength. For example you want keyboard bindings: http://www.haskell.org/wikiupload/b/b8/Xmbindings.png and these are all changeable easily.

You obviously haven't heard of functional reactive programming, which greatly simplifies writing interactive apps. You don't wind up needing state monads for everything.

I agree that it isn't the right tool for this situation, but the main problem is the state of the GUI libraries. Getting GTK installed is not easy (but getting easier). Not something I have desperately wanted to do though. Though it certainly can be done, it would be tremendous effort, and since the OP is asking here for a recommendation he probably isn't swift enough with Haskell that it wouldn't be a huge effort on top of doing his GUI experimentation. Learning Haskell is hard, and it will be an impediment.

My three favourites languages for programming that include an integrated garbage collector and are on top level of CPU performance are:

1. 1. ex-Sun's 32-bit JDK 1.3.1 hacked by myself for providing two statements label/goto in this ancient language old Java.
2. 2. Glasgow Haskell Compiler (GHC 7.5 devel) as in http://www.haskell.org/ghc/dist/current/dist/ghc-7.5.20120214-x86_64-unknown-linux.tar.bz2
3. 3. The coming OCaml-3.13.0 that will provide its new feature GADT that did exist in GHC.

Successful stories: Apache's Hadoop over JVM, Plasma compiled by OCaml, Agda type assistant, etc.

JCPM: and what about slower programming languages? I won't use them much unless stupid code around there (e.g. bash for commands, html for layout, etc).

Although generality is good, we might ask what the "ideal" abstraction for a particular application is. In my opinion, it is a programming language that is designed precisely for that application: one in which a person can quickly and effectively develop a complete software system. It is not general at all; it should capture precisely the semantics of the application domain - no more and no less. In my opinion, a domain-specific language is the "ultimate abstraction".

One approach is not to directly program the GPU, but to use library provided (domain-specific) high-level parallel primitives (map,fold,reduce,..) to describe the computation. The library in question then compiles the final low-level code. These libraries are often implemented as domain-specific embedded languages. Topic is a subject for active research, but some more or less mature implementations already exist, some of which are:

• thrust provides STL-like algorithms for C++ while targeting CUDA and OpenMP as backends.
• ArBB implements a parallel array programming library for C++ built on a general purpose virtual machine targeting SSE, AVX and possibly MIC in the future.
• accelerate is an embedded language for array computations in Haskell and at the moment implements backends for CUDA and ArBB.

Lua does intern all strings, which has many, many nice benefits.

However, if you are dealing with hundreds of megabytes of strings that are being mutated a lot, then this interning process may be a performance problem. However, there are usually good solutions to these kinds of problems. Hop on over to the Lua mailing list or Lua SubReddit and ask for advice. Many other languages often need high-perfomance byte string implementations that for some situations.

2 unintentional puns that I somehow dug out of this:

Math surrounds us and binds us all together

how's that for an incomprehensible mourning hours post?

2 unintentional puns that I somehow dug out of this:

Math surrounds us and binds us all together

how's that for an incomprehensible mourning hours post?

If only Haskell had some decent tutorials.

I have read a couple, and while reading the second one, I have seen something interesting and I wanted to code it and see how it runs. It was only then I realized that I have read 1.5 Haskell tutorials and I yet can't write/run even Hello World in it. Because none of them even bothered to define what the hell a Haskell program is.

$ ghci
GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> putStrLn "Hello world!"
Hello world!
Prelude> 1+1
2
Prelude> map (\x -> x*x) [1..10]
[1,4,9,16,25,36,49,64,81,100]
Prelude> foldl1 (+) [1..10]
55
Prelude> :t map
map :: (a -> b) -> [a] -> [b]
Prelude> :t 1
1 :: (Num t) => t
Prelude> :t [1..10]
[1..10] :: (Num t, Enum t) => [t]
Prelude> :t \x->x*x
\x->x*x :: (Num a) => a -> a

Haskell might be nice, but judging a language by type of articles about it, both Lisp and Erlang are light years ahead. They explain how to solve problems at hand - and waste much much less pages signing odes how beautiful and concise the syntax is.

Have you tried Learn You a Haskell for Great Good! ?

Returning to Haskell. I haven't found a single decent explanation of what the hell monad is. Most concise to date is "a monad is a monoid in the category of endofunctors". But neither that has advanced my understanding of Haskell or monads any further.

That's very funny stuff! As for category theory, you don't have to
know it to use monads effectively, so I hope the link will be helpful.

Glascow Haskell Compiler:

GHC compiles Haskell code either directly to native code or using LLVM as a back-end. GHC can also generate C code as an intermediate target for porting to new platforms. The interactive environment compiles Haskell to bytecode, and supports execution of mixed bytecode/compiled programs.

This is nothing new.

A good database engines already has type checking, and so as long as your query language is type-safe and respects the types built-in to the database engine, then your query language will also be type safe. So all you need to do is write a library that can execute queries in a language like Haskell or Scala which makes use of static type checking, and you have got statically type-checked database queries.

Haskell has had its own database query library for years now, which works with several back-end databases including SQLite and MySQL.

Or go the other way - toward Church instead of Turing - check out Erlang or Haskell or Ocaml. In fact I recommend learning at least one of the above (I personally like Erlang, but that's just me) just to get a different perspective on computation than any of the 'classic' imperative, memory-location-oriented languages.

I think TFS got "worried" mixed up with "hope". :)

Anyway. Who cares about .NET. Itâ(TM)s like a Java... without the "runs everywhere" selling point of Java. Which is silly. Silly, silly, silly. ^^

Then again, if one has seen the light, I doubt anyone could even stand going back to Java too.

And C/C++ and its mutant fellowship of sister languages... oh come on, they're not even worth mentioning. You could as well program in the Handmade Assembler version of MS Clippyâ(TM)s Visual Basic for Children. ;)

(Yeah, I know the C hordes will probably mod me down to hell for attacking their entire belief system. Well, if you survived 18 cruel years with a mother whose belief systems got her thrown out of cults that are usually known to brainwash and captivate people... and I'm not talking about Apple here... you just stop fearing anything. I'd run smilingly into a blade saw. So bring it on!)

We could look them up with Hoogle or Hayoo API searches.

*And* you'd have a huge bank of open source software coming available as they expired.

Bullshit, son. This hippy is going to be playing with the 2011 release of the Haskell platform, which is bringing the Glorious Glasgow Haskell Compiler up to version 7 and compiles, by default, to the Haskell 2010 spec.

You mother-bitches can take your iPads and give yourselves a nice shiny colonoscopy!

Bullshit, son. This hippy is going to be playing with the 2011 release of the Haskell platform, which is bringing the Glorious Glasgow Haskell Compiler up to version 7 and compiles, by default, to the Haskell 2010 spec.

You mother-bitches can take your iPads and give yourselves a nice shiny colonoscopy!

Bullshit, son. This hippy is going to be playing with the 2011 release of the Haskell platform, which is bringing the Glorious Glasgow Haskell Compiler up to version 7 and compiles, by default, to the Haskell 2010 spec.

You mother-bitches can take your iPads and give yourselves a nice shiny colonoscopy!

I dunno, do you consider Haskell innovative?

Haskell? I don't recall ever hearing of it... Is it another programming language? If that's what you meant, the Wiki article Haskell (programming language) doesn't mention Microsoft once. A brief introduction to Haskell doesn't mention Microsoft either. Well maybe it's something else... If so I don't know what it is.

Falcon

but it will teach you things that will be relevant in other languages

Like, for example, putting up with ridiculously bad error messages:

http://hackage.haskell.org/trac/ghc/ticket/589

Unicode has the entire gamut of Greek letters, mathematical and technical symbols, brackets, brockets, sprockets, and weird and wonderful glyphs such as "Dentistry symbol light down and horizontal with wave" (0x23c7). Why do we still have to name variables OmegaZero when our computers now know how to render 0x03a9+0x2080 properly?

OmegaZero is at least something everybody will recognize. And why would you name a variable like that anyway? It's programming, not math, use descriptive names.

But programs are still decisively vertical, to the point of being horizontally challenged. Why can't we pull minor scopes and subroutines out in that right-hand space and thus make them supportive to the understanding of the main body of code?

Because we're not using the same IDE?

And need I remind anybody that you cannot buy a monochrome screen anymore? Syntax-coloring editors are the default. Why not make color part of the syntax? Why not tell the compiler about protected code regions by putting them on a framed light gray background? Or provide hints about likely and unlikely code paths with a green or red background tint?

... what?

For some reason computer people are so conservative that we still find it more uncompromisingly important for our source code to be compatible with a Teletype ASR-33 terminal and its 1963-vintage ASCII table than it is for us to be able to express our intentions clearly.

... WHAT? If you don't express your intentions clearly in a program it won't work!

And, yes, me too: I wrote this in vi(1), which is why the article does not have all the fancy Unicode glyphs in the first place.

vim does Unicode just fine. And from the Wikipedia entry on the author (http://en.wikipedia.org/wiki/Poul-Henning_Kamp):

A post by Poul-Henning is responsible for the widespread use of the term bikeshed colour to describe contentious but otherwise meaningless technical debates over trivialities in open source projects.

Irony? Why does this guy come off as an idiot who got annoyed by VB in this article when he clearly should know better?

We Haskellers already use STM since a long time.

In a similar vein, if you look at the list of contributors to Glasgow Haskell Compiler, you'll see Simon Peyton Jones and Simon Marlow there - both working on it full-time, and both from Microsoft Research. MSR also runs internships to enhance GHC.

In a similar vein, if you look at the list of contributors to Glasgow Haskell Compiler, you'll see Simon Peyton Jones and Simon Marlow there - both working on it full-time, and both from Microsoft Research. MSR also runs internships to enhance GHC.

Berp and Haskell go hand-in-hand. ;)

Go Haskell?

Irreducible complexity is irreducible.

Still, I'd like to stress that picking the right language for your task can greatly reduce problem complexity.

For instance, algorithms are much more compact and easier to understand using a functional programming language. E.g. compare quicksort in Haskell and C - see http://www.haskell.org/haskellwiki/Introduction.

Complex concurrent programs remains challenging even with an excellent (IMO) concurrency library like the one in Java 1.5+. But switch to Erlang, and you'd find many concurrency patterns are expressed more naturally.

programming can be taught with any language. problem solving can be taught with any language. it is better to teach these using a language they WILL use when they actually get into industry, than with stuff they may rarely come up against.

I disagree as it depends on what you're teaching. Concepts like recursion and algorithms are best taught with functional languages. E.g. quicksort is a lot shorter and easier to understand in Haskell than in C - see http://www.haskell.org/haskellwiki/Introduction.

We generally agree that you need to pick the right language for a given task - the task of teaching various computer science concepts is no different. Also, a good curriculum should impart students with the ability to pick the right language for a given task too.

If you're interested in pursuing a computer science degree at university, you might be better off without a background in a imperative/procedural language. Many students who knew C/Pascal seemed to have a tougher time grasping functional languages than those who didn't know anything at all.

• Simple use of par and seq . seq ties the evaluation of one term to another, to force a term to be evaluated immediately even if it isn't strictly needed yet. par creates a "spark" to evaluate a value. This spark may be executed by a different runtime thread than is currently running. Together, you can specify one value to be evaluated locally and another to be potentially evaluated by another CPU. This will work well if the values are reasonably expensive to evaluate (otherwise the overhead of creating the spark, while small, will be greater than the benefits) and independent. Can easily be used with e.g. evaluating all the elements in a list in parallel; runtime threads will pick up and execute the sparks as they are created.
• Parallel strategies. Create an evaluation strategy that mirrors the layout of your program, identifying the parts that can benefit from executing in parallel.
• Data parallel Haskell is an upcoming method that allows you to define parallel array structures that the compiler can see through to determine vectorized evaluation strategies.

In short, none of Haskell's methods of parallelization require you to be aware of threads or synchronization.