>> So what do you think Haskell solves inelegantly?
>
> Does it do hierarchies of types (like windows) nicely, where you don't
> have to go back and fix every use of an object when you add another one
> to the hierarchy?

Yeah, you can do this.

> Does it interface well to low-level stuff without having to write wrappers?

Does /any/ high-level language do this?

Haskell lets you talk to low-level stuff fairly easily. It's not 
trivial, but it's reasonably painless. (Depending on the complexity of 
the thing you're trying to access.)

> Does it handle threads running on various address spaces (i.e.,
> distributed processing) well?

The language itself does not include this feature. You would have to use 
some kind of library.

> How is it on the code generation part? Can you write programs that emit
> code that it then loads back in?

None of the extant implementations let you do this.

[Or rather, GHC is /supposed/ to support this, but I couldn't actually 
get it to work.]

> Can you write programs that notice your
> SQL schema has changed and modifies the running program to account for
> that?

Since it's not possible to receive notifications for schema changes in 
the first place, I don't see how this is feasible.

> Can you compile and distribute Haskell code, let other people use it,
> and then release new object code that is compatible with the existing
> code people already wrote and compiled without breaking things?

No.

Haskell is usually distributed in source form. Partly that's because the 
community is small, and nobody has the resources to compile their code 
for every target platform. Partly it's because most Haskell code is 
open-source anyway. But partly it's because the extant Haskell 
implementations have very poor object code compatibility.

> How elegantly does it interface to dynamic languages like javascript?

What do you mean by "interface"?

> How elegantly does it handle the types in SQL tables? Stuff like
> nullable big decimals? Strings in various locales?

Depends on which SQL library you use.

> How easy is it to parse and compile, such that you could do so on a
> keystroke by keystroke basis? When you make a mistake, is it easy for
> the compiler to pinpoint where you made the mistake? Is it easy for the
> IDE to know when it's safe to recompile the code or whether you're still
> typing?

The Leksah IDE compiles as you type, and highlights compilation errors 
in near-realtime. (Like, there's a delay of a couple of seconds.)

Haskell's type inference can make pinpointing the actual error location 
kinds tricky; you can counter this by adding more explicit type 
signatures to your code. (This is arguably good practise anyway.)



More to the point, most of the questions above aren't about the language 
itself, they're about all the supporting infrastructure that goes with a 
language to make it useful. While these are obviously important things, 
they aren't part of the core language.

For example, GHC has laughable binary compatibility. Every minor 
point-release of the compiler generates incompatible object code. This 
has nothing to do with language design, however. It's entirely possible 
that some day somebody will write a rival compiler which has excellent 
binary compatibility. The language itself does not make this impossible 
or even difficult. It's just that with everybody distributing code in 
source form, there's no real incentive for people to work towards this goal.

Similar remarks go for most of your points. There are languages like 
Erlang where support for distributed processing is built-in. Haskell is 
not such a language. On the other hand, we already have a library for 
shared-memory synchronisation and communication between threads; it's 
not inconceivable that some day somebody will extend it to work across 
node boundaries. But whether this happens or not is not a property of 
the language. The fact that the language is powerful enough for this to 
support this is a property of the language.

In summary: If you're saying that C# has better tools and better 
libraries for doing real-world stuff, then I have no argument. If you're 
saying that the C# language design is superior, then I must disagree.

Post a reply to this message