>> Perhaps actual /strings/ allow storing all possible Unicode code-points.
>> However, char, the type of a single character, apparently covers the BMP
>> only. If you're going to go to all the trouble of actually supporting
>> Unicode, why not support the whole thing?
>
> Do you have any idea what "the whole thing" means in case of Unicode?
>
> Hint: There's more to Unicode than just ~1 million code points with
> glyphs mapped to some of them.

Sure. But if you can't even /write down/ those code-points, that's kinda 
limiting.

(It also strikes me that if the String type /can/ hold them all and Char 
/can't/, that has interesting implications for trying to iterate over a 
String one Char at a time...)

>> Pop quiz: if x is a string and y is a delegate, does it do delegate
>> concatenation or string concatenation?
>
> Provided it doesn't raise an error, obviously you'll get string
> concatenation,

Yes.

> because you can't convert strings to delegates.

No.

 From what I can tell, it never tries to convert a string to anything 
else, but it /does/ try to convert anything else to a string.

Post a reply to this message

>> Right. So you're saying the fact that nobody has sat down and written a
>> comprehensive set of libraries makes the language "non-elegant" and
>> "poorly designed"?
>
> I did not say THAT.
>
> What I did say is that if nobody has sat down and written a
> comprehensive set of libraries, this prevents the lange from being a
> language that "solves everything" - and, consequentially, from
> qualifying as "a simpler, more elegant design that solves everything".

Haskell is an elegant, beautiful language. In the vast majority of 
cases, it lets you write your application logic in a very concise, 
reliable and maintainable way.

For a language to be /useful/, you need more than just the language. You 
need libraries. You need a build system. You need packaging and 
distribution. You need profiling and debugging tools. You need 
documentation systems. And probably a number of other things too.

For the most part, Haskell lacks these. This does not change the fact 
that the Haskell /language/ is elegant and beautiful.

I don't doubt that C# almost certainly has /far/ more plentiful 
libraries. (As does Java, C++, C, Python, Ruby, or really /any/ 
programming language that mainstream programmers use.) That doesn't mean 
that the design of the C# /language/ is clean or beautiful.

> What I also did imply is that if anybody would indeed sit down and write
> a comprehensive cover-all set of libraries, there would likely be quite
> a number of them that would be non-elegant to use

And why would that be the case?

> Right. But it has something to do with whether the language "solves
> everything" [for practical purposes].

I was referring only to the design of the language itself, not the 
libraries that go with it, nor any of the various other tools required 
to make a language generally useful. It's no secret that Haskell fails 
spectacularly on that count.

> Can you easily model a state machine in Haskell? If not, then it doesn't
> solve everything.

This is trivial.

> Can you easily write a GUI in Haskell? If not, then it doesn't solve
> everything.

This could be made trivial, but currently it isn't supported 
particularly well.

(E.g., writing a GTK application is fairly simple. Getting the GTK 
libraries to work in the first place is not simple.)

> Can you easily write an OS kernel in Haskell? If not, then it doesn't
> solve everything.

This has been done at least once before.

Note also that there is now a project that lets you run the Haskell 
runtime on bare metal (or rather, on the Xen virtualisation platform) 
without an OS. Apparently this was developed as part of a commercial 
system, so somebody is using it for real.

> As soon as you have libraries (or other language extensions) for all
> conceivable purposes, we'll talk again - about elegancy then.

Right, because how elegant a language is depends on how many libraries 
it has. Oh, wait - no it doesn't.

Post a reply to this message

On 14/08/2012 03:42 PM, Invisible wrote:

> - The "char" type works with Unicode. Well done. Oh, but wait... It only
> stores 16 bits, and yet Unicode actually requires 24 bits to represent a
> single code-point. So this "Unicode character" only actually covers the
> Basic Multilingual Plane. FAIL!

Oh great. Apparently "char" doesn't store a code-point at all, it stores 
a code-unit.

For anything in the BMP, these are effectively the same thing. For 
anything outside that range, *you* must manually write the code to 
decode UTF-16 into actual code-points (which then do not fit into a "char").

Well done. :-P

Post a reply to this message

On 13/08/2012 01:08 PM, Invisible wrote:
> I think perhaps my biggest criticism of C# is that there doesn't seem to
> be an introduction anywhere. I can read about isolated features of the
> language on MSDN, but nowhere can I seem to find a coherent introduction...

I downloaded the C# "language specification". Rather than being an 
actual specification (which would usually be a dense, incomprehensible 
document supplying a rigorous mathematical definition of the language 
for use by compiler implementers), it seems that /this/ is the 
comprehensible introduction that actually explains stuff. Weird...

Post a reply to this message

Am 15.08.2012 10:11, schrieb Invisible:

>> Right. But it has something to do with whether the language "solves
>> everything" [for practical purposes].
>
> I was referring only to the design of the language itself, not the
> libraries that go with it, nor any of the various other tools required
> to make a language generally useful. It's no secret that Haskell fails
> spectacularly on that count.

I'm reiterating: I don't doubt that the Haskell /core language/ is 
simple and elegant. I doubt that it "solves everything".

As soon as you've dealt with the "solves everything" part, we'll talk 
again, and see if the "simple and elegant" also applies to that one. My 
claim is that the combo isn't possible.

THAT is the point I'm trying to get through to you.

Post a reply to this message

>> I was referring only to the design of the language itself, not the
>> libraries that go with it, nor any of the various other tools required
>> to make a language generally useful. It's no secret that Haskell fails
>> spectacularly on that count.
>
> I'm reiterating: I don't doubt that the Haskell /core language/ is
> simple and elegant. I doubt that it "solves everything".

It solves every problem of core application logic. It doesn't solve the 
problem of talking to the outside world. (That's the job of the 
libraries, and once they currently don't do so well.)

> As soon as you've dealt with the "solves everything" part, we'll talk
> again, and see if the "simple and elegant" also applies to that one. My
> claim is that the combo isn't possible.
>
> THAT is the point I'm trying to get through to you.

You somehow believe that writing a bunch of libraries would make the 
language no longer elegant?

Well, I guess since it's unlikely to ever happen, we'll never know...

Post a reply to this message

On 14/08/2012 03:42 PM, Invisible wrote:
> As with any language, my WTF list:

On the other hand, it seems they certainly did a fair few things right. 
It's messy in there, but it does have moments of hope.

Post a reply to this message

On 14/08/2012 03:42 PM, Invisible wrote:
> As with any language, my WTF list:

Enums. Urgh. An enumeration is supposed to be a type that can only take 
on the specified set of values. Except that in C#, an enumeration can 
take on /any/ integer value. It's just that some of these values also 
have friendly names. *sigh*

What, no bitfield type? :-P

Post a reply to this message

Am 15.08.2012 09:56, schrieb Invisible:

>> Hint: There's more to Unicode than just ~1 million code points with
>> glyphs mapped to some of them.
>
> Sure. But if you can't even /write down/ those code-points, that's kinda
> limiting.
>
> (It also strikes me that if the String type /can/ hold them all and Char
> /can't/, that has interesting implications for trying to iterate over a
> String one Char at a time...)

As soon as you think of combining diacritics, you'll see that this type 
of limitation is actually inevitable, even with a way to hold any 
code-point value in a char: You can, for instance, hold the canonical 
representation of Lowercase A + Acute Accent in a char (because it has a 
dedicated code point, U+00E1), but you can't do the same with the 
canonical representation of Lowercase A + Double Acute Accent (because 
that's the sequence U+0061 U+030B) - or with the non-canonical 
representation of A + Acute Accent, for that matter (U+0061 U+0301).


>>> Pop quiz: if x is a string and y is a delegate, does it do delegate
>>> concatenation or string concatenation?
>>
>> Provided it doesn't raise an error, obviously you'll get string
>> concatenation,
>
> Yes.
>
>> because you can't convert strings to delegates.
>
> No.
>
>  From what I can tell, it never tries to convert a string to anything
> else, but it /does/ try to convert anything else to a string.

Yes, exactly.

Post a reply to this message

Am 15.08.2012 11:46, schrieb Invisible:
> On 14/08/2012 03:42 PM, Invisible wrote:
>
>> - The "char" type works with Unicode. Well done. Oh, but wait... It only
>> stores 16 bits, and yet Unicode actually requires 24 bits to represent a
>> single code-point. So this "Unicode character" only actually covers the
>> Basic Multilingual Plane. FAIL!
>
> Oh great. Apparently "char" doesn't store a code-point at all, it stores
> a code-unit.
>
> For anything in the BMP, these are effectively the same thing. For
> anything outside that range, *you* must manually write the code to
> decode UTF-16 into actual code-points (which then do not fit into a
> "char").

Uh... why does this come as a surprise to you?

Post a reply to this message