Slashdot Mirror

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

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

If you want to see some Haskell code, I have some more concrete examples here:

• PXSL -- Parsimonious XML Shorthand Language, which is implemented in Haskell. (Haskell sources)
• A concurrent port scanner in one page of Haskell
• Cheating Hangman in Literate Haskell (and Perl)

I have written a lot of little projects in Haskell. You can find some of them in links from my user info page.

Also, one of the best resources on Haskell is the HaWiki: HaWiki.

Do give Haskell a try. It is an amazing programming language.

Check out these progressively more efficient implementations of the sieve in haskell (look in the mimencoded file attachment). --Kartik Agaram

qsort [] = []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
where
elts_lt_x = [y | y <- xs, y < x]
elts_greq_x = [y | y <- xs, y >= x]

qsort( a, lo, hi ) int a[], hi, lo;
{
int h, l, p, t;

if (lo < hi) {
l = lo;
h = hi;
p = a[hi];

do {
while ((l < h) && (a[l] <= p))
l = l+1;
while ((h > l) && (a[h] >= p))
h = h-1;
if (l < h) {
t = a[l];
a[l] = a[h];
a[h] = t;
}
} while (l < h);

t = a[l];
a[l] = a[hi];
a[hi] = t;

qsort( a, lo, l-1 );
qsort( a, l+1, hi );
}
}

Don't forget the wonders of lexical closures, something offered by any self respecting interpreted language.

And also offered by any self respecting compiled language. Just because C doesn't have 'em doesn't mean nobody else does, you know.

It's more accurate to say that programming languages are linear (or tend to be), because that's how computers work today. What a non-linear language would be is unclear

Something like Haskell, where order of your program doesn't matter due to it's lazy evaluator?

There are many other advantages to functional programming of course, but that's the only one that's relevant to this thread! ;-)

Haskell Lazy Functional Language

I'm not suggesting that we do away with basic arithmetic or variable assignment. You can't do that and still have a programming language.

...If programming is so complex, then why don't we try something new. You want a program without state? Try Haskell. You want to be able to prove something about your program? Try ML. But don't despair, I think the reason for crummy software is that it hasn't been around for that long. Civil engineers have had the hindsight of building roads, and aqueducts, and buildings for thousands of years. Software been around for what, 2 generations?

Get them started on Haskell!

To quote themselves, "Haskell is a general purpose, purely functional programming language".

The focus on the high-level "what" rather than the low-level "how" is the distinguishing characteristic of functional programming languages.

Of course, this sortof harks back to the recent debate on how all programmers should know assembly language. Guess what, they don't.

Actually, first implementations of generics come from the functionnal progrmming community, esp. Philip Wadler et al. So, the java genericity's genealogy would rather lead to Hindley/Milner type sytems, through Haskell

Then, with more and more languages, especially ones with VMs, you get further and further away from the hardware. The end result: you lose performance. It does more and more for you, but at the expense of real optimizations, the kind that only you can do.

Now the zealots will come out and say, "Language X is better than language Y, see!" To me this argument is boring. I tend to use the appropriate tool for the job. So:

• Python for scripts, prototypes, proofs of concept, or components where performance generally is not an issue.
• For desktop apps, Visual Basic (yep, most IT apps are in VB). There is no justifiable reason for an IT department group to write a sales force reporting system in C++! If you want C++, go get a job at a software company. Stop wasting money and time making yourself feel like a hotshot. [I'd consider Kylix here if it was based on Basic. Why? Because honestly, Pascal is just about dead, and Basic is the king of the simple app. Let's just live with it and move on. I do want a cross-platform VB . . . ]
• For web apps, well, I stick around PHP/ASP.NET. Why? Portability! And moreover, the sticking point in a web-based app is not the UI layer; it's usually the underlying data extraction and formatting. Don't waste your time with lower level languages there. IMHO it's just not worth it. JSP and Java stuff, yuck! Too much time for too little bang.
• Java/C# (also consider mono/LISP for most production apps. Why? Portability! I want no vendor holding me by the balls. I want platform independence on the back end, and these are the few ways to achieve it. I'd include Haskell/OCAML here when appropriate. Perl? I'm loathe to use Perl as production, considering most Perl code cannot be understood 2 weeks after it's written. I'd rather take the hit in performance and be able to pass the code to someone else later.
• C++/C for components--just components--where performance is at an absolute premium or there exists some critical library that only has this kind of interface. But this step has to be justified by the team, with considerable explanation why a different architecture could not suffice. Otherwise, the team could waste time checking for dangling pointers when instead it could be doing other things, like finishing up other projects.
• Assembly? Only when there is not a C complier around. Embedded stuff. Nowadays, you just do not have the time to play.

Yes, my teams use many languages, but they also put their effort to where they get the biggest bang for the buck. And in any business approach, that's the key goal. You don't see carpenters use saws to hammer in nails or drive screws. Wise up!

Monads are not a branch of Category Theory, really. They are a categorical construct, such as Adjoints. Monads are used in functional programming as a way to do nonfunctional things such as I/O, mutation, and interaction in a purely functional manner.

This allows Haskell to be a pure functional language, while at the same time a practical programming language... unlike ML languages which opted for adhoc hacks in order to make a functional programming language practical.

If the name for Microsoft's CLI means anything, then expect the commandline to be something like an interactive Haskell interpreter such as Hugs.

Why would Microsoft build such as CLI? Well, first it would have all of the power of Unix like CLIs, but it would also add strong static typing (and static type inference), which means allot as far as correctness and security go.

The resulting shell scripts would also have several useful properties typically only found in purely functional languages, such as referential transparency (WYSIWYG for programming languages), confluence (strong yet flexible determinancy), type safety (correctness, security), and more!

The question is, will such a thing become popular and commonplace in Microsoft's future operating systems? Ha! MS OS users are GUI addicts, and a purely functional CLI would freak them out more than impress them.

Linux could easily and rapidly make such a CLI by hacking an opensource Haskell interpreter such as Hugs. Note that these interpreters are interactive in the sense that you run the interpreter and are presented with a CLI that you use to interact with the interpreter. Interactive interpreters like Hugs are more like a combination between a Unix CLI and the CLI you have in sophisticated calculators.

Pretty cool stuff, if you ask me.

Monads are not a branch of Category Theory, really. They are a categorical construct, such as Adjoints. Monads are used in functional programming as a way to do nonfunctional things such as I/O, mutation, and interaction in a purely functional manner.

This allows Haskell to be a pure functional language, while at the same time a practical programming language... unlike ML languages which opted for adhoc hacks in order to make a functional programming language practical.

If the name for Microsoft's CLI means anything, then expect the commandline to be something like an interactive Haskell interpreter such as Hugs.

Why would Microsoft build such as CLI? Well, first it would have all of the power of Unix like CLIs, but it would also add strong static typing (and static type inference), which means allot as far as correctness and security go.

The resulting shell scripts would also have several useful properties typically only found in purely functional languages, such as referential transparency (WYSIWYG for programming languages), confluence (strong yet flexible determinancy), type safety (correctness, security), and more!

The question is, will such a thing become popular and commonplace in Microsoft's future operating systems? Ha! MS OS users are GUI addicts, and a purely functional CLI would freak them out more than impress them.

Linux could easily and rapidly make such a CLI by hacking an opensource Haskell interpreter such as Hugs. Note that these interpreters are interactive in the sense that you run the interpreter and are presented with a CLI that you use to interact with the interpreter. Interactive interpreters like Hugs are more like a combination between a Unix CLI and the CLI you have in sophisticated calculators.

Pretty cool stuff, if you ask me.

Monads are also a branch of category theory that are adopted by languages like Haskell (the prime developer of which works for Microsoft Research). By obeying a certain set of basic principles, programs structured with monads achieve high degrees of interoperability and consistency, while safely encapsulating data and keeping it from being destroyed by unwanted side effects.

Sure that's an apropos name for a Microsoft product?

Yeah, Chalmers is heavily into functional programming, specifically using Haskell

Most of the other unis tend to focus on algorithms and numerical analysis, notably The Royal Institute of Technology and Uppsala University. In general all the unis are more into computer engineering type research rather than comp sci.

Code Generation is for people who don't understand or are too lazy for abstraction ...

Code generation is a practical, efficient tool for solving many problems where OO-style abstraction need not enter the picture. One such class of problems is building interfaces and glue code from external specifications.

A few years ago, I wrote a simple code generator that reads the SQL DDL for a large database and generates an object-based interface to the database. Client coders could then use the object-based interface to access the database. The advantages of this approach proved to be numerous:

• Single, authoritative reference specification. The object interface was always in sync with the reference, which for this project was the database schema.
• Richer compile-time error detection. The projection of the schema into the object interface was fully available to the type system so that many kinds of client errors could be caught at compile time, not run time.
• Reduced opportunity for errors between subsystem boundaries. Because the object-based interface was generated by machine from the actual database -- and not derived from some programmer's understanding of the database -- there were fewer opportunities for impedance mismatch across the boundaries of the application code and the database. (Studies of errors in complex projects have shown that errors are more common between subsystem boundaries, and so this benefit is important.)

But I cannot think of any case in an object-oriented language where it would be both less work and more maintainable to write a code generator than to just abstract away the parts that would be auto-generated.

• When the number of variables affecting the desired code characteristics is large enough to make hand-coding (at any level of abstraction) impractical. E.g., FFTW: "FFTW uses a code generator to produce highly-optimized routines for computing small transforms."
• When your code must conform to an external reference specification that changes rapidly enough to make hand coding (at any level of abstraction) impractical. (See my example above.)
• When the requirement for correctness is so stringent as to make hand-coding methods impractical, mandating code generation from a formal specification.
• When you must target an output language whose native abstraction capabilities are too crude to capture directly the degree of abstraction that is merited. Believe it or not, most popular OO languages fall into this category for many commonly occuring problems. Hence the popularity of design patterns. (Compare, e.g., with the abstraction capabilities of modern functional programming languages like Haskell and O'Caml.)

Haskell also casts integers to floats automatically. This is common in most languages.

This is not a typecast. Both Integer and Float are members of the Num type class, and (+) is an operation defined over the Num type class. This is much closer to what really happens in mathematics, where addition is understood to apply to reals (which include integers). For more information, see the Haskell Standard Prelude.

The short version is that there isn't one (+) :: Integer -> Integer -> Integer and one (+) :: Float -> Float -> Float, but rather a single (+) :: Num a => a -> a -> a. It is manifestly never possible to have a type error in this situation, so Haskell is still strongly typed.

Actually, that (taken from "A gentle introduction to Haskell"; cite those sources) is how I remember the basic algorithm.

And I find the four line version found on http://www.haskell.org/tutorial/goodies.html much more readable myself, but I tend to prefer short lines.

Actually, that (taken from "A gentle introduction to Haskell"; cite those sources) is how I remember the basic algorithm.

And I find the four line version found on http://www.haskell.org/tutorial/goodies.html much more readable myself, but I tend to prefer short lines.

> sieve (p:xs) = p:(sieve (filter (\x -> (x `mod` p /= 0)) xs))
> primes = sieve [2..]

I think we ought to harness those resources. We ought to use them to teach children those languages that are immensely powerful yet, judged by our standards, too inefficient to be practical. In particular, I'm referring to functional programming languages like Scheme and Haskell.

Now, hear me out.

Why functional programming languages? Because they lend themselves to extremely powerful, mathematical ways of thinking about and solving problems. Learning these ways of thinking when young will benefit our children for the rest of their lives. For example, take a look at the The TeachScheme! Project. I wish something like that was available when I was in High School.

Let us not teach our children the technologies of today but of tomorrow. More and more, I am convinced that functional programming, once considered too computationally inefficient for industry work, will be tomorrow's dominant programming paradigm. No other way of programming so readily lends itself to the formalism that is necessary to manage the ever-increasing complexity of modern software projects.

So, let us give our children the tools they will need to solve the problems of their day. Teach them functional programming.

Indeed, the most widely-used Haskell Compiler, GHC, is developed mainly at Microsoft Research and distributed as open source (BSD-licensed).

While I like ML (whole family) so much more than any imperative legacy (Java, C++, C, Perl), I see the main problem that any ML has with for modern RAD and with scripting is its static typing. And that's why I like (more than ML) Haskell [haskell.org] - it's dynamically typed and thus it's much more appropriate both for operating scripting and for big app RAD.

This sounded a little fishy to me based on my knowledge of programming language relationships. So I did five minutes of Google research. Here's what I turned up. "Haskell's static type system defines the formal relationship between types and values (4.1.4). The static type system ensures that Haskell programs are type safe; that is, that the programmer has not mismatched types in some way. For example, we cannot generally add together two characters, so the expression 'a'+'b' is ill-typed. The main advantage of statically typed languages is well-known: All type errors are detected at compile-time."

The biggest difference between Haskell and ML is that Haskell strongly separates the functional and imperative parts of the language. Look into "monads". "The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds."

Functional Programming is a Very Good Thing to learn.

After being interested in functional programming languages for a while I had the opportunity to spend some time reviewing a textbook using ML. I figured that was the time to learn the language. Got frustrated quickly, I got several ML systems (including the one mentioned in the book) and no two worked alike. Hell, the syntax varies enough that there are ML dialects that look like completely different languages.

A while later I decided that perhaps it was time to spend some energy seriously learning Haskell. I got and installed Hugs (Haskell.org is a wonderful resource with several Haskell systems listed, tutorials, documentation, libraries and so on). Hugs implemented pretty much all of the Haskell described in the manual I found and the tutorials. (Today, I'd probably use the interactive GHC.)

It took a while, some dedication and a lot of grumbling to figure out how things worked and I'm still learning bits and pieces of the language and associated libraries and stuff.

Now Haskell is one of my favorite languages and I want to use functional tools (higher order functions, laziness, and so on) in every language I use. I'd say that Haskell changed my ideas about programming, my approach to problems, and my toolset both deeply and widely - and for the better. Probably as deep a shift in technology and technique for me as OOP (I started programming in Fortran, APL, Algol...) - but then OOP just always seemed Right to me.

Part of what made the learning process so effective was that Haskell makes it very hard to have side effects - so where in ML the books/tutorials often introduce mechanisms for building variable that work more or less like those in C - in Haskell this is very difficult.

So, while F# may be an interesting language, if you want to learn a new language, try Haskell. You may have to be obstinate. And if it works with you as it did me, it will drive you crazy until it clicks (and I remember exactly the problem that did it) and then you'll just kind do one of those quiet awestruck "wow"s and watch your view of programming change.

Haskell isn't the right language for everything. I also use Java, C and Python (and a few others) often - but for lots of problems, for doing a quick model of something to try it out, for just helping your mind think about a problem a bit differently ... Haskell is great.

But remember - you may well have to be stubborn about persisting till it clicks.

And on a related note...
Does anyone know if anything ever came out of the development of the functional scripting language "Sheep" for the amiga?

Until today, both ML and Haskell had a common problem: a lack of commercial and real world interest in it and therefore a lack of real-world libraries and supporting frameworks. But now things are going to be changed.

First Ericson came with Erlang, an excelent essence of FP, LP, scripting and networking. Now M$ (I know - evil, but anyway) came with F# bringing OCaml to the real world saving from being forgotten somewhere in Inria.

What next? I think that would be Haskell, the language even more suprior to ML, with already OOP, Parallel and Cuncurrent extensions. Also I like its Functional-Logical dialect - Curry. But who will bring it to the real world? IBM?

Haskell does, sort of, using its strict type system. In very many cases, you can guess the meaning of a function simply by looking at the types of its arguments.

Sebastian

however, what is most curious to me is the usage of haskell (a functional language) as the language of choice for the compiler. perhaps the author wants to fool us?

The Glasgow Haskell Compiler may be found here. It's currently at 5.04.3. I used this one to compile the sources. Haskell is not an easy language to learn so better look not into the source if you want to have a happy day! ;)

regards

however, what is most curious to me is the usage of haskell (a functional language) as the language of choice for the compiler. perhaps the author wants to fool us?

The Glasgow Haskell Compiler may be found here. It's currently at 5.04.3. I used this one to compile the sources. Haskell is not an easy language to learn so better look not into the source if you want to have a happy day! ;)

regards

kinda of like the switch you made when going from functional programming to object oriented programming...

You almost certainly don't mean Functional Programming...;)

Haskell an implementation of Church's lambda calculus, a form of mathematical logic. There are compilers, which generate code comparable (within 20-50%) with c and a large number of mathematics packages. compare
Check it out!

First, you mix strongly typed languages with statically typed languages. Perl is stronlgy, but dynamically typed language, while C++ is weakly, but statically typed language. But even assuming you meant statically typed languages, your reasoning is flawed.

Well, that's close, but usual terminology is slightly different:

Strongly/weakly typed has to do with what types we consider equivalent. Strongly typed means that the type has to stem from the same definition, weakly typed that they have to be "compatible" e.g. have the same structure. Hence two new types that both derive from are not equivalent in a strongly typed language, while they are equivalent in a weakly typed language. Ada is the prototypical strongly typed language here. Also surprisingly C is also strongly typed, but only because of the twist that 'typedef' doesn't introduce a new type, but only a new name for an old type.

Static/dynamic is as you use it, i.e. has to do with whether the type of the program can be determined statically (at compile time) or dynamically (at runtime).

Now, what you call strong/weak is really type safe/type unsafe. I.e. can the execution of the program ignore the types or not. C.f. C where you even though you have strong static typing, it's also type unsafe, i.e. the running of the program can result in a silent type error, whereas in Scheme for example it cannot, all type errors will be found.

Speaking of types, myself I prefer languages that statically typed, and type safe (with polymorphism). The static types aren't really a problem if you use a language with a Hindley-Milner (like) typesystem, since it will automatically infer the types of all your expressions, meaning that you don't have to annotate the source with types unless you really want to. Such langages as Haskell and O'Caml meet these criteria.

Try looking here and here. The second link gives the perfect examples:

int a = 5;
float b = a;

typedef int Date;
Date c = 12345;
int d = c;

C and C++ cannot be called strongly typed. Try Haskell instead

Ah, but when are you dealing exclusively with top-notch programmers who know the application area in and out, and who know already have all the relevant APIs installed?

It is relatively easy to come up with a problem which can take a moderately skilled perl programmer one day but take a similarly skilled C programmer a week or two.

People need to realize that when discussing languages in practical application, you're not going to be dealing with the ideal, perfect programmer doing the ideal, perfect job of implementation in the language under question. This means you have to ask things like: "what does this language encourage a moderately skilled programmer to do in accomplishing task x?", not "what does an uber-YOUR_LANGUAGE_HERE hacker do to accomplish task x?"

As an example, I've never ever seen anyone implement a bubble sort on a singly linked list in perl. (Oh sure, you could, but it doesn't happen in nature) In C, however, programmers sometimes consider it more trouble to convert from this list they made singly linked for ease of insertion (or whatever reason stuck them at the time) so that they can use the qsort() standard library function, and so end up rolling their own sorting routine. Oftentimes, the path of least resistance is seen to be a bubble sort.

(As an aside, the quicksort algorithm isn't really that complicated to remember; just remember the Haskell version - I don't understand why it isn't more common even among quick-and-dirty programmers)

Face it - a great deal of the practical utility of a language comes down to how it will be used by the average programmer, and the average programmer is not as good as everyone would like him to be.

C is a low level language that nearly nobody understands....Java is a good high-level language.

When will the myth ever die? Java is not a high-level language. Neither is C nor C++. They are all categorized as low-level languages. Being high or low-level has nothing to do with how "good" a language is or how much hype or popularity or evangelism it has. Go study the theory of programming languages.

The level of a language has to do with the expressiveness of the paradigms (concepts) you can use directly in the language. In this regard it can be easily argued that C++ is of a higher-level than Java because it supports the programing paradigm of generics, whereas Java in it's current form does not. But then look at something like Python and it's many higher-level features such as dictionaries (associative arrays), generators, or even built-in infinite-precision numbers and imaginary numbers. In those cases the language allows you to directly express those complex concepts that you have to "program" yourself (or use libraries) using lower level languages. And then you can progress up to languages like Haskell and so forth which are higher-level still.

As another example, it should be obvious that within it's intended problem domain even a language like SQL is of a higher-level than Java, and SQL is still just of some intermediate level. Even some generally unpopular old languages have some high-level features not found in Java/C/C++ like Scheme's continuations or COBOL's PIC formatting or Fortran's matrix arithmetic. I know you can program those in Java, but those high-level concepts are not directly provided by Java.

In the big picture of all the languages out there Java is decidedly pretty far over on the scale of being low-level. Again level is not a scale of goodness, so don't fall into that misconception and use that term as such.

Lisp has one of the best object-oriented paradigm implementation, Meta-Object Protocol among languages with both scripting and bytecompiling capabilities.

Scheme has been proved as a good language for GUI and configuration: GIMP, Sawfish, TeXmacs.

OCaml has all the power as Lips, just in syntax conviniect for many Java/C-poisoned brains to read faster. No wonder there are many real-world applications on it.

Haskell... I just love how it demonstrates that OOP is not everything (and even not enough) :)

Sun works for telecom industry - why not consider Erlang?

And don't ignore Mozart - it's multi-paradigm pradigm might be just what we all will thing as the best in 3-5 years.

The list is not complete, of course. And it's inspired by Functional Programming.

My main point here is: each of above languages, would it be in hands of Sun marketed instead of Java (with all that money invested to), would have quality of implementation much better than Java.

In fact, I am impressed how such poorly designed language as Java succeed so far on the market. It wouldn't without so much money behind. And without so many classes written by Sun to compensate the poor design of the core language itself.

Would Sun invest so much efforts and money to FP language then the result would be much better. Because quality is why FP matters.

That, and the fact that I found it on the Haskell Humor page sort of tipped me off...

Interestingly enough, Simon Peyton Jones does seem to work for Microsoft.

This press release from 1998 talks about Microsoft adopting Haskell (a purely functional language with lazy evaluation).

and it's still one of only a few compilable languages (excepting gcj == java) that have a gc.

There is nothing special about a "compilable language" (whatever that means) using GC. Lisp has been doing it for decades (and yes, most Lisp systems are native code compilers, such as CMUCL, Allegro, CormanLisp, SBCL, etc). Oberon-2 compilers use GC, including the open source OOC and Oberon System3 from ETH. Ada was designed such that GC could be implemented, but it rarely is. Many FP languages use GC, such as Haskell. Haskell compilers, such as GHC, NHC, and HBC all use GC.

If you haven't gotten the point yet, there is nothing special about implementing languages using garbage collection, and furthermore, there was nothing innovative when Meyer decided to use it for Eiffel.

and it's still one of only a few compilable languages (excepting gcj == java) that have a gc.

There is nothing special about a "compilable language" (whatever that means) using GC. Lisp has been doing it for decades (and yes, most Lisp systems are native code compilers, such as CMUCL, Allegro, CormanLisp, SBCL, etc). Oberon-2 compilers use GC, including the open source OOC and Oberon System3 from ETH. Ada was designed such that GC could be implemented, but it rarely is. Many FP languages use GC, such as Haskell. Haskell compilers, such as GHC, NHC, and HBC all use GC.

If you haven't gotten the point yet, there is nothing special about implementing languages using garbage collection, and furthermore, there was nothing innovative when Meyer decided to use it for Eiffel.

For interactive symbolic manipulation, Maxima is an excellent open-source alternative. For numerical applications, Numerical Python and its associated packages beat both Matlab and Mathematica in my opinion. For 3D visualization, you can get VTK, which also has Python bindings.

Maxima is also used occasionally as a rapid prototyping language, but it's proprietary and it has a lot of rough edges. You are probably better off using one of a number of open languages with similar features, like Scheme, OCAML, SML, Prolog, or Haskell.

Don't forget about C++, however. In many ways, C++ nowadays allows you to write numerical code more naturally than any of these other languages (yes, better than Matlab and Mathematica), it has by far the best libraries available for it, and it gives you excellent performance. And you can even do symbolic mathematics in C++, with the right libraries (though it's not interactive, of course).

Hmm, okay, I may have been mistaken. Thanks for the correction!

I was actually thinking of Haskell last night, but forgot the name.

Jouster

The downloadable test server appears to be written in Haskell and compiled with GHC:

> strings Simulator | grep GHC
...
The GHC User's Guide has full details.
RTS options may also be specified using the GHCRTS environment variable.
...

What's wrong with Haskell and is it related here?

I assume we talk about the same language

Try Haskell instead. Or, perhaps, SML/O'CAML.

I don't post much so my Karma is fairly hard won but I'm going to troll anyway.

There is so much stupid shit being said in response to this article that I have to offer some advice to those without a clue:

1) For God's sake go learn a language (like C/C++ or assembly) where you can do some real damage. I'm conviced nobody truely "gets" software until they've spent three sleepless nights in a row tracking down a fandango on core.

2) Really grok a language that changes your way of thinking -- Haskell is a pretty good bet.

3) Dig up old hardware take it apart, put it back together. Get it to work again.

4) Use a hardware assisted debugger or in circuit emulator.

5) Go build and a small 8051 embedded system project just for fun but make sure you include an LCD display in the project -- and not just one of the easy serial type.

6) Buy a cheap scope -- Before you go insane from step 5.

7) Learn what happens under to the covers.

8) Say "Fuck the Wizard and the IDE you rode in on too."

9) Learn VHDL and digital design just for the heck of it These folks have everything you need.

If you've done this, you've learned a lot. But after all that, think about the things you still don't know. Marvell at your stupidity -- admit it openly. Be humbled. You will be a better person for it.

In short, don't become just another button pushing pinhead. You don't have to live that way.

Oh, and if you're one of the few that have taken the time and effort to become aware of how much you don't know, thank you. You are a credit to the profession.

I know it's hard to believe, but some languages can actually enforce better code. There are at least three features which give developers this opportunity:

1. Strong Typing so more errors are caught at compile-time.
2. Exception Handling so those not caught at compile-time can still be dealt with properly.
3. No Side-Effects because this makes it much easier to prove program correctness; IOW: "enforce algorithms [and] understand design specs".

Haskell implements at least two of these features, however it is much slower than something like C#. For a company to change its devotion from cheap code to good code would do more than any mere language change. A dedication to good design would also alleviate some of the difficulties resulting in dynamic customers.

Sometime in the fourth week, our lecturer announced the eagerly anticipated first Assignment. I couldn't wait, because I expected to ace it, after all, I had years of programming experience, a huge advantage over my peers. Not so: We had to write an Optical Character Recognition (OCR) program. I was stunned. I had never done anything that complex in my life, in any language, and now I was being asked to do it in a functional language! However, many people achieved recognition rates over 80%, and some people rates as high as 98%, even though most students were first-time programmers. It just goes to show what people are capable of when pushed.

The same lecturer (Andrew Taylor) later came up with a whole series of Evil assignments -- his students tell stories about them to this day. For example, our second assignment in Comp 1A was to write an AI for the card game Hearts. To mark the assignment, he wrote a system that ran submissions in randomly chosen four-player games automatically, and ranked them by total score after some number of games. Half the marks were based on the performance of your AI! He even made the ranking software available beforehand so that students could test their algorithms against each other in mini-tournaments.

This is going to go down like a cup of cold sick, but...

If you do this sort of thing for a living, it would pay to look into alternative tools that make your life easier. For instance, check out the available Haskell web/CGI/HTML/XML libraries. Coding plain and interactive web interfaces that are rock solid is so much easier it's not funny. A whole raft of bug classes are simply impossible using these schemes.

By the way, before anybody says otherwise, Haskell is a serious, full-blown industrial strength language.