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

Darren New <dne### [at] sanrrcom> wrote:
> I might have asked this before, but do you have any good (hopefully generic) 
> examples of where MI really helps out?

It's not commonplace for sure, but I have had actual situations where
multiple inheritance has been useful (and also at least one situation
where multiple inheritance would have been useful but was not available
because the language, in this case Objective-C, didn't support it).
Coincidentally (or perhaps not) all the cases I remember have been related
to GUI programming.

These have been cases where I have had an object which should act as a
screen element (whatever the basic element may be called in a particular
GUI library) and also as another class, neither of which could have been
just an interface (because both base classes contained functionality of
their own).

(In the Objective-C case I had to get around the limitation by using
preprocessor macros which could be used to add the required member
variables and functions in all the classes that needed them. It was quite
ugly.)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > Even if it does, then the language could implicitly do with it what C++'s
> > virtual inheritance does. You can still forbid all other types of diamond
> > inheritance if you so wish.

> You could, but then it's getting weird.

What would be weird about it?

-- 
                                                          - Warp

Post a reply to this message

Am 16.08.2012 13:13, schrieb Invisible:

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

YES, EXACTLY! So much for the "solution to everything".

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

The point is, if it's the right tool for the right job, its design /is/ 
superior (for this job).

Design superiority isn't in elegant simplicity, but in how actually 
useful it is - for a given purpose.

Post a reply to this message

On 16/08/2012 12:56 AM, Darren New wrote:
> On 8/15/2012 4:08, Invisible wrote:
>> I guess I'm used to using a programming language where a Char is...
>> well...
>> any valid Unicode code-point,
>
> You mean, you only use languages invented after Unicode had more than
> 65536 code points defined.

And when was that? About 10 years ago? :-P

Post a reply to this message

Am 16.08.2012 10:38, schrieb Invisible:

> I doubt Eiffel has half as many libraries as C# though. Like most
> well-designed languages, it never really took off.

I'd dare say, "like most (if not all) languages with well-intended 
simple and elegant design" - and that it's /because/ of this design that 
they never really took off. Because its simplicity limits its usefulness 
for particular use cases, and the elegancy (of the whole smash) goes 
down the drain once you add extensions (including, but not limited to, 
libraries) to make it useful.

Post a reply to this message

On 16/08/2012 05:16 PM, clipka wrote:
> Am 16.08.2012 10:38, schrieb Invisible:
>
>> I doubt Eiffel has half as many libraries as C# though. Like most
>> well-designed languages, it never really took off.
>
> I'd dare say, "like most (if not all) languages with well-intended
> simple and elegant design" - and that it's /because/ of this design that
> they never really took off. Because its simplicity limits its usefulness
> for particular use cases, and the elegancy (of the whole smash) goes
> down the drain once you add extensions (including, but not limited to,
> libraries) to make it useful.

You keep saying this, and you keep being wrong. However, it is clear to 
me that nothing I say is going to convince you otherwise, so there we are.

Post a reply to this message

Am 16.08.2012 18:16, schrieb Orchid Win7 v1:

>> You mean, you only use languages invented after Unicode had more than
>> 65536 code points defined.
>
> And when was that? About 10 years ago? :-P

Sounds like a good estimate. Even a bit more, I'd guess.

Now that we have this sorted out, when was the last time someone 
invented a language that's well-known today?

Post a reply to this message

On 16/08/2012 05:27 PM, clipka wrote:
> Am 16.08.2012 18:16, schrieb Orchid Win7 v1:
>
>>> You mean, you only use languages invented after Unicode had more than
>>> 65536 code points defined.
>>
>> And when was that? About 10 years ago? :-P
>
> Sounds like a good estimate. Even a bit more, I'd guess.
>
> Now that we have this sorted out, when was the last time someone
> invented a language that's well-known today?

Well, the entire .NET platform is somewhat newer than 10 years, so 
presumably C# is about the same age.

Post a reply to this message

Am 16.08.2012 18:38, schrieb Orchid Win7 v1:
> On 16/08/2012 05:27 PM, clipka wrote:
>> Am 16.08.2012 18:16, schrieb Orchid Win7 v1:
>>
>>>> You mean, you only use languages invented after Unicode had more than
>>>> 65536 code points defined.
>>>
>>> And when was that? About 10 years ago? :-P
>>
>> Sounds like a good estimate. Even a bit more, I'd guess.
>>
>> Now that we have this sorted out, when was the last time someone
>> invented a language that's well-known today?
>
> Well, the entire .NET platform is somewhat newer than 10 years, so
> presumably C# is about the same age.

While the .NET platform was indeed initially released in 2002, the 
project had been officially announced as early as July 2000, so it is 
safe to assume that work on it had started somewhat before 2000.

As for C#, according to Wikipedia it "Appeared in 2001", and development 
had started as early as January 1999.

Post a reply to this message