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

I guess combining characters are The Real WTF...

(No, wait - that's the BOM.)

Post a reply to this message

Am 15.08.2012 12:36, schrieb Invisible:
>>> 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.)

Neither does it solve every problem of core application logic in a 
/practical/ manner. At least that's the impression I get from your 
occasional rants. So for those things you'll need libraries, too.

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

I believe that writing a sufficient bunch of libraries to care for all 
needs would make the /combo/ non-elegant in various places.

That said, if the core language was /that/ simple, elegant and 
cover-all, how come nobody has managed to put an easy-to-use cover-all 
library for X yet? (X := any feature already implemented in multiple 
libraries but with different severe limitations to each of them. Dunno 
which example it was you did your rant over - mutable lists or some such?)

Post a reply to this message

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

I guess I'm used to using a programming language where a Char is... 
well... any valid Unicode code-point, and once you set the encoding of a 
file handle, the library does all necessary encoding and decoding, 
whether it's UTF-8, UTF-16, Latin-1 or whatever.

Still, I suppose it's better than char = unsigned byte. :-P

Post a reply to this message

>>> 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.)
>
> Neither does it solve every problem of core application logic in a
> /practical/ manner. At least that's the impression I get from your
> occasional rants. So for those things you'll need libraries, too.

So what application logic problems aren't solved by Haskell then?

>> You somehow believe that writing a bunch of libraries would make the
>> language no longer elegant?
>
> I believe that writing a sufficient bunch of libraries to care for all
> needs would make the /combo/ non-elegant in various places.

And I believe you're wrong.

The purpose of a library is to make stuff easy, after all...

> That said, if the core language was /that/ simple, elegant and
> cover-all, how come nobody has managed to put an easy-to-use cover-all
> library for X yet? (X := any feature already implemented in multiple
> libraries but with different severe limitations to each of them. Dunno
> which example it was you did your rant over - mutable lists or some such?)

If C is so great for writing operating systems, where are there so many 
different, incompatible operating systems? :-P

Post a reply to this message

Am 15.08.2012 12:48, schrieb Invisible:
> 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*

Erm... did you actually /try/ this??

Trying to assing an int to an enum variable, I get a "Cannot implicitly 
convert [...]" error for any integer value other than 0. (Don't ask me 
why they did allow it for 0 though.)

Post a reply to this message

>> 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*
>
> Erm... did you actually /try/ this??

Quoting Microsoft's C# language specification:

   "Each enum type has a corresponding integral type called the 
underlying type of the enum type. [...] The set of values that an enum 
type can take on is not limited by its enum members. In particular, any 
value of the underlying type of an enum can be cast to the enum type and 
is a distinct valid value of that enum type."

> Trying to assing an int to an enum variable, I get a "Cannot implicitly
> convert [...]" error for any integer value other than 0. (Don't ask me
> why they did allow it for 0 though.)

Perhaps you can't /implicitly/ convert, but try writing an /explicit/ 
cast. According to the spec, that's supposed to work.

Post a reply to this message

Am 15.08.2012 13:06, 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
>
> I guess combining characters are The Real WTF...

Nope. You just can't do without them for plenty of purposes, because 
coding each conceivable combo as a single character would have the 
Unicode code space explode (and make comprehensive Unicode fonts even 
more scarce). You'd be surprised how many diacritics some languages 
stack even on one single character, or how many different diacritics 
there are for the IPA phonetic notation.

> (No, wait - that's the BOM.)

Nope, the BOM is quite sane.

First, it is a legal Unicode codepoint, indicating a zero-width 
non-breaking space. While this may sound weird to have, it does allow 
you to suppress kerning, as well as lots of other stuff that might 
happen to pairs of characters (just think of properly implemented arabic 
script, where a character's glyph depends not only on the character 
itself, but also on its neighbors).

Second, it is suggested to prepend this Unicode character (which by 
definition doesn't do any harm) to any text stream that leaves a 
program's boundaries.

Why not mandate a canonical byte ordering? Simple: As long as the next 
program to pick up the data runs on the same machine (and hence uses the 
same byte ordering), re-ordering would just add unnecessary overhead.

Post a reply to this message

Am 15.08.2012 13:37, schrieb Invisible:
>>> 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*
>>
>> Erm... did you actually /try/ this??
>
> Quoting Microsoft's C# language specification:
>
>    "Each enum type has a corresponding integral type called the
> underlying type of the enum type. [...] The set of values that an enum
> type can take on is not limited by its enum members. In particular, any
> value of the underlying type of an enum can be cast to the enum type and
> is a distinct valid value of that enum type."
>
>> Trying to assing an int to an enum variable, I get a "Cannot implicitly
>> convert [...]" error for any integer value other than 0. (Don't ask me
>> why they did allow it for 0 though.)
>
> Perhaps you can't /implicitly/ convert, but try writing an /explicit/
> cast. According to the spec, that's supposed to work.

You're right there. I guess it's to provide support for bitfield-style 
use of enums.

Note that one of the design goals of C#, AFAIK, was to provide a 
comparatively easy migration path from C/C++.

Post a reply to this message

Am 15.08.2012 13:10, schrieb Invisible:
>>>> 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.)
>>
>> Neither does it solve every problem of core application logic in a
>> /practical/ manner. At least that's the impression I get from your
>> occasional rants. So for those things you'll need libraries, too.
>
> So what application logic problems aren't solved by Haskell then?

Operating on mutable lists (or whatever it was you tried back then, and 
ran into a set of libraries that all did it in a different way 
unsuitable for your needs so you resorted to a rant), for instance?


>>> You somehow believe that writing a bunch of libraries would make the
>>> language no longer elegant?
>>
>> I believe that writing a sufficient bunch of libraries to care for all
>> needs would make the /combo/ non-elegant in various places.
>
> And I believe you're wrong.
>
> The purpose of a library is to make stuff easy, after all...

Still, not every library succeeds in that job to a degree that it can be 
called "simple and elegant". And sometimes that's not due to design 
flaws in the library, but due to the underlying language standing in the 
way.


>> That said, if the core language was /that/ simple, elegant and
>> cover-all, how come nobody has managed to put an easy-to-use cover-all
>> library for X yet? (X := any feature already implemented in multiple
>> libraries but with different severe limitations to each of them. Dunno
>> which example it was you did your rant over - mutable lists or some
>> such?)
>
> If C is so great for writing operating systems, where are there so many
> different, incompatible operating systems? :-P

Because there's no such thing as a simple, elegant cover-it-all, maybe?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Trying to assing an int to an enum variable, I get a "Cannot implicitly 
> convert [...]" error for any integer value other than 0. (Don't ask me 
> why they did allow it for 0 though.)

If it works like C++ enums, then enumerated constants will implicitly cast
to integrals, though (and integrals can be cast explicitly to enums).

While this is useful oftentimes (there are many, many situations where
an enumerated list of names is much handier than writing integral constants),
there are othertimes where strongly-typed enums would be more desirable.

C++11 added strongly-typed enums to the language (in addition to the existing
weakly-typed ones). If an enumerated type is not intended to be used as
an integral, then you can now say so. (You can also specify its underlying
type if you want.)

-- 
                                                          - Warp

Post a reply to this message

>> So what application logic problems aren't solved by Haskell then?
>
> Operating on mutable lists (or whatever it was you tried back then, and
> ran into a set of libraries that all did it in a different way
> unsuitable for your needs so you resorted to a rant), for instance?

Haskell's library support for mutable arrays is a mess. But we're still 
talking about bad library design, not bad language design.

>> The purpose of a library is to make stuff easy, after all...
>
> Still, not every library succeeds in that job to a degree that it can be
> called "simple and elegant". And sometimes that's not due to design
> flaws in the library, but due to the underlying language standing in the
> way.

Sure. And my argument is that if a language is designed well, you can 
use it to write powerful libraries which are simple and easy to use. 
(And if a language is designed poorly, you often can't do that.) Hence 
why good language design is so important.

>> If C is so great for writing operating systems, where are there so many
>> different, incompatible operating systems? :-P
>
> Because there's no such thing as a simple, elegant cover-it-all, maybe?

Most of this stuff is due to social, organisational, economic and other 
reasons, not language design.



Your core argument appears to be that a useful programming language 
necessarily has to be badly designed. I reject that. The fact that all 
of the widely used languages are badly designed doesn't mean that bad 
design is a necessary attribute.

Post a reply to this message

On 8/14/2012 1:06, Invisible wrote:
> My point being that everybody acts like "oh, of /course/ you can't possibly
> do that", when in fact you can.

You can't possibly do it in a language where you are actually declaring your 
types. You *can* return types that are private or anonymous. You just can't 
declare a function that returns a private type.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 3:17, clipka wrote:
> If you want to give such guarantees, you can't handle variables of types for
> which you have no declaration, because obviously you can't tell whether they
> can do A, B, C and D or not.

To be fair, I suspect Haskell just treats that declaration as if you're 
returning Object in C#. In other words, haskell I suspect doesn't let you 
return a value whose type you can't see, but instead of making that illegal, 
it essentially inserts a cast for you to an opaque supertype. (So to speak, 
of course, since Haskell isn't OO.)

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 3:46, Invisible wrote:
> ...and yet, in my Haskell snippet, a type is not exported, yet still you can
> convert it to a string, because that interface is implemented.

Then you've exported the interface, not the type. C# can already do that.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 5:57, Invisible wrote:
> 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?

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

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

How is it on the code generation part? Can you write programs that emit code 
that it then loads back in? Can you write programs that notice your SQL 
schema has changed and modifies the running program to account for that?

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? If John writes 
code and releases the object code, then Mary subclasses that, and you're 
using Mary's object code in your program, does John releasing new object 
code require you to get Mary to help you use John's new code?

How elegantly does it interface to dynamic languages like javascript?

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

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?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

Am 16.08.2012 01:00, schrieb Darren New:
> On 8/14/2012 1:06, Invisible wrote:
>> My point being that everybody acts like "oh, of /course/ you can't
>> possibly
>> do that", when in fact you can.
>
> You can't possibly do it in a language where you are actually declaring
> your types. You *can* return types that are private or anonymous. You
> just can't declare a function that returns a private type.

Or, more precisely, you can't declare a /non-private/ function that 
returns a private type.

Post a reply to this message

On 8/14/2012 1:31, Invisible wrote:
> So what happens if you say "override" on a method that isn't virtual?

I suspect it's a compile-time error.

> Heh. And I thought Haskell was the only language stupid enough to claim that
> the reading the formal language specification is a good way to learn how to
> program with it...

Most languages lack a formal spec. C# gets close. Hermes actually generates 
the compiler based on the formal spec, so yeah.

>> Sure. When you load the subclass, it just re-JITs the superclass.
> It actually does that?

It would have to, if it noticed the call isn't actually virtual. Some JITs 
do it, some don't.

>> Basically, subclasses or anything compiled at the same time as this class.
> I guess it makes sense once you realise it means OR, not AND.

Yep.

>>>> Yes. Well, what would you expect? A public method that returns a value
>>>> of a type you can't see the declaration of?
>>>
>>> Haskell lets you do exactly that, yes.
>>
>> No it doesn't.
>
> O RLY?

So show me a function that returns a value of a type I can't see.

>
>> It probably lets you return an opaque reference to
>> something you can't see the type of, but I doubt it lets you return a
>> type that you can't see.
>
> module Foobar (Foo (..), foobar) where
>
> data Foo = Foo Int deriving Show
> data Bar = Bar Int deriving Show
>
> foobar :: Foo -> Bar
> foobar (Foo x) = Bar x
>
> Notice how Bar is not exported, yet foobar is exported, and its return type
> is Bar.

So you declare foobar returning an interface that support Show, which is 
what you've done.

> Remember, Haskell functions deal with known types ALL THE TIME. Any time you
> call id :: x -> x, it takes a value of unknown type, and returns it
> unchanged. So for Haskell, having some data of a type that you can't "see"
> is no big deal at all. (With the minor detail that you now can't declare
> anything as returning Bar as its result, because that name is not in scope.)
>
Well, I'm not sure how this differs from C#. Declare it returning Object, 
and you're done. That's basically what you're doing. You're saying "here's 
something, I don't know what it is, so you don't get to use it as that type, 
but as some more abstract type.

>>> I guess I'm just spoiled. In Haskell, there are precisely 2 sorts of
>>> type;
>>> everything is either an algebraic data type or a function type. C# has
>>> 5 of
>>> fundamentally different sorts of type, all with different semantics.
>>
>> Well, actually, everything's an object.
>
> Except that no, no it isn't. Apparently only values of reference types are
> considered "objects". :-P

Uhhhh, no. Everything is an object. Really. Some classes are value classes, 
and some classes are reference classes, but every value is an object.

>
> You could /almost/ say "everything's a class", except that no, we have enums
> and stuff which aren't considered "classes".

Of course they're classes. If you want, you can even look up what their 
superclass is. For example, 23 is of class System.Integer32 or some such.

>>> I especially love how enumerations are a different type but no, not
>>> really, because obviously they're actually just integers...
>>
>> No they aren't. Especially not the way Haskell defined "type". :-)
>
> Right. So enumerations aren't integers, and that's why you define the
> corresponding integer value of each case right there in the definition? :-P

They correspond to integers. They aren't integers.  I *do* think Java did 
that one much better.

> If you have real enumerations, why do you need a special-case for bool?

Because you have syntax in the language that uses specific types, like "if" 
statements. Having bool being a special enumeration is no more odd than 
having a function that accepts one specific enumeration type as an argument 
and not any generic enumeration.

> (The same argument applies to Haskell: Why the HELL did they special-case
> the list type, when you can trivially define it manually? What there they
> thinking??)

They were thinking you needed special syntax.

Hermes, for example, does not have a string type. But if you have an enum 
where each name is one character long, you can make an array of that value 
by sticking it inside quotes. Which I thought was kind of cute.

> OK, whatever. I haven't really explored it all that much yet, but it doesn't
> appear to compare well to Eiffel.


What doesn't, C#?  There are various things Eiffel does theoretically 
better, if they're actually implemented.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 4:19, clipka wrote:
> That's quite a stupid thing to do, because you then can't tell at
> compile-time whether some other function expecting a parameter of type "Bar"
> actually gets passed such a type when using (in C++ style pseudocode):

I think the problem is more that Haskell is functional rather than OO, so 
the stuff people do by having private classes in OO languages is stuff 
Haskell does by having opaque types. So instead of
    f.x()
accessing the private values inside f, in Haskell you write
    x(f)
at which point you want to be able to pass around an "f" without being able 
to look inside f.

So it's Andrew's category error, mapping the wrong concepts onto what he 
already knows.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 7:16, Invisible wrote:
> Well, you're right in that you cannot write any code which explicitly
> expects Bar. You can pass the result to any function that works with /all/
> types, or any function that works with any showable type. If the module
> exported some functions that expect Bar as input, you can pass the result to
> them. But you can't write that in a type signature, which... yeah, is a bit
> silly.

That's what I was saying. You can't return type Bar if you haven't made it 
exposed. You can declare that foo returns a Bar, but you can't actually use 
Bar. It gets the equivalent of being upcast to "object" or to whatever 
interface you've defined it to be. So the fact that you can't return an 
opaque Bar is no hinderance - declare foo to return the appropriate 
interface or Object.

> My point wasn't so much that this is a something anybody is likely to want
> to do. My point was a counter-example to the "that's obviously impossible"
> argument. It's /not/ impossible at all.

By that reasoning, it's possible to do it in C#:

return (Object) Bar;

return (Showable) Bar;

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 1:32, Invisible wrote:
> On 14/08/2012 02:01 AM, Darren New wrote:
>> It's an excellent OO language that expects to have runtime and OS
>> support around.
>
> ...and yet, they claim it can be used for embedded systems, which don't even
> /have/ an OS?

You can use Sing#, which is apparently just like C# except with extra stuff.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 4:52, clipka wrote:
> I guess you've heard of code re-use through delegation, no?

Then every type of screen item has to delegate that call to something else, 
and every time the superclass adds a function, then all subclasses have to 
write code to delegate it properly.

If you automate that process, guess what you just invented?

> I do agree that at least inheritance among interfaces would be nice to have,

I don't know of any language that implements inheritance and interfaces that 
doesn't allow interfaces to inherit. Quite honestly, that would make almost 
no sense.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 4:15, Warp wrote:
> clipka<ano### [at] anonymousorg>  wrote:
>> As current widespread belief is that virtually all multiple inheritance
>> use cases can be covered with the interface approach, it seems to make
>> sense to avoid this extra overhead.
>
> Only if you don't mind the need for code repetition with interfaces.

I might have asked this before, but do you have any good (hopefully generic) 
examples of where MI really helps out?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 1:40, Invisible wrote:
> So if a class tries to implement both interfaces, it can't provide different
> implementations for these two distinct methods merely because their names
> clash?

That depends on your language. Java? I don't think so. C#? Definitely. But 
then you can't invoke the interface call without specifying which one you 
mean, so there's no ambiguity.

> According to the Great Language Shootout, C# Mono is 3x slower than C. (Then
> again, Haskell is 2x slower...)

So, an open source clone is slow, thus the version Microsoft uses that 
compiles down to optimized native code must be also?

>>> Arguably you could have the compiler detect where dynamic binding is
>>> and is
>>> not needed. That requires whole-program analysis, however.
>>
>> That's what Eiffel does.
>
> Sure. Because Eiffel doesn't support dynamic linking.

Yep. That's what (for example) Sing# does too.

>> Sure there is, because you recompile the code while it's running.
> That sounds remarkably hard to get right...

No harder than compiling it in the first place while it's running. Why is it 
harder to re-JIT than to JIT?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 4:20, Warp wrote:
> Does Object contain member variables? If not, then I don't see the problem.

Good point. I don't know.

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

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 7:42, Invisible wrote:
> - "As of C# 2.0, it is also possible to have an array in a structure." (Erm,
> why the HELL would it not be possible to do that before??)

Because structs are fixed size determined by the compiler (and stored in the 
stack generally speaking), and arrays are variable sized and stored in the 
heap. You can share references to arrays but not to structs, so what happens 
when you pass a reference to the array inside a struct and then discard the 
variable holding the struct?

> - "x & y" performs a Boolean-OR if the arguments are Bools, and a bitwise-OR
> if they are integers. The same goes for all the other logical operators.
> Except NOT, which has "!x" for Bools and "~x" for integers. WTF?

Makes sense if you think about where those symbols came from, namely C.

> - "x + y" performs addition. Unless either argument is a string, in which
> case the other is converted to a string as well (if not a string already)
> and the strings are concatenated. Unless both arguments are delegates, in
> which case they are concatenated. (I guess there's a /reason/ the Java guys
> claim that operator overloading is evil!)

If you don't know what types you're adding together, you're already in trouble.

> - Goto? Seriously? Well, I suppose /technically/ that's not actually a WTF...

Useful for generated code like state machines.

> - Anonymous delegates /and/ lambda functions?

Yes?

> - A delegate is a thing which is called when an event is fired, but an event
> /is/ a delegate?? (In fairness, this is probably a Wikibooks WTF rather than
> anything to do with the design of C#.)

A delegate is basically a function pointer you can invoke. An event is 
basically a delegate with only certain operators (+= and -=) exposed outside 
the class that declares the delegate. So think of "event" like "restricted 
interface to a delegate".

"firing an event" is exactly the same thing as "invoking a delegate."

> - Extension methods. Just... what??

Useful for LINQ. Useful in general for readability.

> - A non-generic queue is called Queue, and a generic queue is called
> Queue<T>. And yet, for the other container types, the generic and
> non-generic versions have completely different, unrelated names. (I guess
> that's backwards compatibility for you... oh, wait.)

Yep. Generics didn't show up until V3 or so, I think.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/14/2012 14:06, Orchid Win7 v1 wrote:
> 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?

You do know that unicode has evolved too, right?

> Yeah, sounds like more the sort of thing you'd expect in a scripting language.

No. It's perfectly reasonable rules based on static types.

> OTOH, it appears that it's the only autoconversion that can happen.

Not at all. Indeed, you can declare your own implicit conversions for your 
own types.

> Pop quiz: if x is a string and y is a delegate, does it do delegate
> concatenation or string concatenation?

It fails to compile, because there's no implicit conversion between the two.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

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.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/15/2012 4:52, clipka wrote:
> You're right there. I guess it's to provide support for bitfield-style use
> of enums.

That too. They're just conveniently-named integers.

I far prefer Java's enums, which are basically a full-blown class (with 
member variables and static and instance functions and everything), but with 
all valid instances of the class being declared in the enum at program 
start-up time. So, basically, a full class plus a bunch of "static BLAH = 
new ..." sorts of operations.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

Am 16.08.2012 01:40, schrieb Darren New:
> On 8/14/2012 4:52, clipka wrote:
>> I guess you've heard of code re-use through delegation, no?
>
> Then every type of screen item has to delegate that call to something
> else, and every time the superclass adds a function, then all subclasses
> have to write code to delegate it properly.

You're presuming here that GUI item superclasses keep growing new 
functions. That's not a necessary prerequisite for a GUI library though.


>> I do agree that at least inheritance among interfaces would be nice to
>> have,
>
> I don't know of any language that implements inheritance and interfaces
> that doesn't allow interfaces to inherit. Quite honestly, that would
> make almost no sense.

I totally agree that it's a good choice to not design a language that 
way. But still, even with such a language you /could/ write a GUI library.

Post a reply to this message

Am 16.08.2012 01:58, schrieb Darren New:

> I far prefer Java's enums, which are basically a full-blown class (with
> member variables and static and instance functions and everything), but
> with all valid instances of the class being declared in the enum at
> program start-up time. So, basically, a full class plus a bunch of
> "static BLAH = new ..." sorts of operations.

Strangely enough, I imagined to remember that it was C# that did enums 
that way. Don't know where and when I mixed that up.

Yeah, I really do like that approach as well.

Post a reply to this message

On 16/08/2012 12:02 AM, Darren New wrote:
> On 8/14/2012 3:17, clipka wrote:
>> If you want to give such guarantees, you can't handle variables of
>> types for
>> which you have no declaration, because obviously you can't tell
>> whether they
>> can do A, B, C and D or not.
>
> To be fair, I suspect Haskell just treats that declaration as if you're
> returning Object in C#. In other words, haskell I suspect doesn't let
> you return a value whose type you can't see, but instead of making that
> illegal, it essentially inserts a cast for you to an opaque supertype.
> (So to speak, of course, since Haskell isn't OO.)

You're probably write. (Depending on how you want to argue about the 
semantics.) My point was just that "oh, it's /obviously/ impossible" 
isn't actually so obvious.

Post a reply to this message

>> Heh. And I thought Haskell was the only language stupid enough to
>> claim that
>> the reading the formal language specification is a good way to learn
>> how to
>> program with it...
>
> Most languages lack a formal spec. C# gets close. Hermes actually
> generates the compiler based on the formal spec, so yeah.

C# is supposedly an ISO standard, so there must be a published 
specification for it. However, while the spec is the thing you want to 
read if you're building a new implementation (e.g., Mono), it's usually 
an utterly lousy way to learn how to actually /use/ a programming language.

(Although, as I discovered, the C# "spec" actually reads more like a 
tutorial, so...)

> So show me a function that returns a value of a type I can't see.

>> module Foobar (Foo (..), foobar) where
>>
>> data Foo = Foo Int deriving Show
>> data Bar = Bar Int deriving Show
>>
>> foobar :: Foo -> Bar
>> foobar (Foo x) = Bar x
>>
>> Notice how Bar is not exported, yet foobar is exported, and its return
>> type
>> is Bar.
>
> So you declare foobar returning an interface that support Show, which is
> what you've done.

It still works if you take Show out. (Although in that case it becomes 
even more pointless.)

My point isn't that this is a useful thing to do. It's just that it 
doesn't necessarily /have/ to be impossible. C# /chose/ to make it 
impossible - a not unreasonable choice, but not the /only/ choice.

>>> Well, actually, everything's an object.
>>
>> Except that no, no it isn't. Apparently only values of reference types
>> are considered "objects". :-P
>
> Uhhhh, no. Everything is an object.
>
>> You could /almost/ say "everything's a class", except that no, we have
>> enums and stuff which aren't considered "classes".
>
> Of course they're classes. If you want, you can even look up what their
> superclass is. For example, 23 is of class System.Integer32 or some such.

According to the spec document, any value of a value type is not 
formally referred to as an "object"; that term is reserved for values of 
reference type. Similarly, the term "class" is reserved to refer to 
types declared with the "class" keyword.

Of course, with the C# unified type system, all types /behave/ as 
classes in the usual OO sense (which is the point you're making). It's 
just that the C# language spec does not /call/ then classes.

>> Right. So enumerations aren't integers, and that's why you define the
>> corresponding integer value of each case right there in the
>> definition? :-P
>
> They correspond to integers. They aren't integers. I *do* think Java did
> that one much better.

What, by not having enumerations at all?

>> If you have real enumerations, why do you need a special-case for bool?
>
> Because you have syntax in the language that uses specific types, like
> "if" statements.

Haskell has special if syntax, and yet Bool is defined in library code.

>> (The same argument applies to Haskell: Why the HELL did they special-case
>> the list type, when you can trivially define it manually? What there they
>> thinking??)
>
> They were thinking you needed special syntax.

You need special syntax for integers, and yet anybody that wants to can 
define a new integer type. (E.g., I wrote a library that lets you deal 
with "half integers" - numbers which are integers when multiplied by 2.)

What they /should/ have done is let you use what is now "list literal 
syntax" for /any/ suitable container type. Unfortunately, they didn't.

And what's with [Int], anyway? Would List Int just be too readable?

> Hermes, for example, does not have a string type. But if you have an
> enum where each name is one character long, you can make an array of
> that value by sticking it inside quotes. Which I thought was kind of cute.

Nice. :-S

>> OK, whatever. I haven't really explored it all that much yet, but it
>> doesn't appear to compare well to Eiffel.
>
> What doesn't, C#? There are various things Eiffel does theoretically
> better, if they're actually implemented.

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

(I'm guessing C# took off because it's explicitly designed to look like 
one of the other badly-designed languages which is already wildly 
popular...)

Post a reply to this message

>> So if a class tries to implement both interfaces, it can't provide
>> different
>> implementations for these two distinct methods merely because their names
>> clash?
>
> That depends on your language. Java? I don't think so. C#? Definitely.
> But then you can't invoke the interface call without specifying which
> one you mean, so there's no ambiguity.

 From what I've seen, you can't just use the fully-qualified method 
name, you have to actually cast the entire object to the type of the 
interface first. Which seems rather necessarily long-winded...

>> According to the Great Language Shootout, C# Mono is 3x slower than C.
>
> So, an open source clone is slow, thus the version Microsoft uses that
> compiles down to optimized native code must be also?

According to Wikipedia, Mono /also/ does JIT compilation to native code. 
(Although I agree it would be better if there were published benchmark 
results for .NET itself.)

>>> Sure there is, because you recompile the code while it's running.
>> That sounds remarkably hard to get right...
>
> No harder than compiling it in the first place while it's running. Why
> is it harder to re-JIT than to JIT?

Because you have to make sure it actually happens, and uses up-to-date 
information. It looks remarkably easy for this step to get missed under 
sufficiently unusual conditions.

Post a reply to this message

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

On 8/16/2012 4:13, Invisible wrote:
> Does /any/ high-level language do this?

Depends what you mean by "high level", but yes. Ada, C#, FORTH, a few others 
here and there.

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

I guess being functional has some advantages here.

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

You are allowed to poll. ;-)

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

See, that's exactly the target market for C#. Or rather for .NET. C# is a 
component-oriented language that happens to be OO. F# is a 
component-oriented language that happens to be (somewhat) functional. Etc.

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

And that's the sort of thing I'm talking about. :-)

>> How elegantly does it interface to dynamic languages like javascript?
>
> What do you mean by "interface"?

Can you invoke a javascript library as if it were written in Haskell? I.e., 
is it as easy to invoke something like javascript as it is to invoke 
something like C?

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

Not bad.

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

Well, if your language can't handle dynamic loading or can't handle 
object-code distribution, then these are inherent in the language. I.e., if 
type inference is such that you have to do whole-program compilation for it 
to work, then you can't link in new code at runtime.

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

Not superior. Superior at various tasks.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/16/2012 4:13, Invisible wrote:
> 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 that's not all it takes to make it do what Erlang does. Erlang isn't 
just "distributed processing." It's "reliable processing." Which means you 
need to be able to (for example) start a new version of the code running 
while not actually throwing away the stack of call frames that got you 
there. You have to be able to have A call B call C call D, and have D say 
"Oh, by the way, next time C returns, B should be calling the new version of 
C, but only in those threads where C has actually returned. Oh, and don't 
screw up B's local variables."  That's the sort of thing that's really, 
really hard to do in a library, unless you're running something like FORTH 
that actually has access to the executing code.

How would you write a Haskell library that says "once each call to X 
returns, replace that thread's version of X with new executable code, 
without otherwise disturbing the thread that's running there"?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/16/2012 1:27, Invisible wrote:
> You're probably write. (Depending on how you want to argue about the
> semantics.) My point was just that "oh, it's /obviously/ impossible" isn't
> actually so obvious.

It obviously *is* impossible, if your definition of "type" is "collection of 
values and the operators that transform them into other values."

If you return a private stack, it's not a stack unless I can call push and 
pop on it. It's some other type that's just wrapping up a stack until you 
unwrap it again.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/16/2012 1:38, Invisible wrote:
> It still works if you take Show out. (Although in that case it becomes even
> more pointless.)

As it does in C#. You return Object.

> My point isn't that this is a useful thing to do. It's just that it doesn't
> necessarily /have/ to be impossible. C# /chose/ to make it impossible - a
> not unreasonable choice, but not the /only/ choice.

You're just arguing syntax at this point. If I return a value and there's 
nothing you can do with that value that you can't do with every other value 
of every other type, then you've returned Object. You haven't returned a 
value of a private type - you've cast it to a value that has no operations 
defined except assignment.

> According to the spec document, any value of a value type is not formally
> referred to as an "object"; that term is reserved for values of reference
> type. Similarly, the term "class" is reserved to refer to types declared
> with the "class" keyword.

Not you're picking nits.

> Of course, with the C# unified type system, all types /behave/ as classes in
> the usual OO sense (which is the point you're making). It's just that the C#
> language spec does not /call/ then classes.

Are they all subclasses of Object? How can you have a subclass of Object 
that isn't in turn an object? :-)

>> They correspond to integers. They aren't integers. I *do* think Java did
>> that one much better.
>
> What, by not having enumerations at all?

No. Java has actual useful enums, which are basically classes with a finite 
collection of named static instances created at compile-time.

>>> If you have real enumerations, why do you need a special-case for bool?
>>
>> Because you have syntax in the language that uses specific types, like
>> "if" statements.
>
> Haskell has special if syntax, and yet Bool is defined in library code.

So? bool is defined in library code too. System.Boolean in mscorlib.dll

>> Hermes, for example, does not have a string type. But if you have an
>> enum where each name is one character long, you can make an array of
>> that value by sticking it inside quotes. Which I thought was kind of cute.
>
> Nice. :-S

And then there's ACT.1, where a number like 534 is actually a big long 
expression that is ((5 * 10 + 3) * 10) + 4. I.e., similarly to the way 
Hermes does strings, ACT.1 does every literal including integers and floats. 
"Int" is actually a source code library.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/15/2012 17:13, clipka wrote:
> You're presuming here that GUI item superclasses keep growing new functions.
> That's not a necessary prerequisite for a GUI library though.

No. It's just that *that* is one of the use cases that OO was intended to 
solve. Of course if you're sure you're never going to have new superclass 
methods, or that you're willing to update every subclass every time you add 
one to the superclass, then you don't need inheritance. But having that 
break between superclass and subclass, and between sibling subclasses (so 
you can add a new subclass without changing every reference to a superclass 
method to include a new case for that new subclass) is exactly the point of 
dynamic dispatch.

>> I don't know of any language that implements inheritance and interfaces
>> that doesn't allow interfaces to inherit. Quite honestly, that would
>> make almost no sense.
>
> I totally agree that it's a good choice to not design a language that way.
> But still, even with such a language you /could/ write a GUI library.

I can write a GUI library in assembler. Or in C, faking OO. Or in C, not 
faking OO. That doesn't mean it's easy.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/16/2012 7:33, Warp wrote:
> 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).

Yeah, OK, fair enough. I can see that. It's sort of what the MVC pattern is 
designed to get around, in a way.

Just as an amusement, I've found a very funky failure of inheritance at work.

We have a system that contains what we'll call documents. The business logic 
loads a bunch of documents, and then the UI has a bunch of subclasses of 
document that format the documents appropriately. (And the business document 
instantiates the appropriate subclass by looking at flags in the data and 
using factories and such.)  All well and good. You have documents, and you 
have SpreadhseetDocuments, PdfDocuments, VideoDocuments, TextDocuments, 
etc., all of which make calls to the superclass to get the parameters and 
then display the content appropriately.

Now we're doing a mechanism to let you edit documents, so we'll have 
DraftDocuments. But we want SpreadsheetDocuments, VideoDocuments, etc to use 
the data in the draft documents (which is stored in other tables, in funky 
formats appropriate for editing, etc) for previews. But I can't instantiate 
a VideoDocument with either a (final) Document or DraftDocument as the 
superclass as appropriate, because it's Java.  So I have to figure out a way 
around that somehow.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/16/2012 3:14, Invisible wrote:
> According to Wikipedia, Mono /also/ does JIT compilation to native code.
> (Although I agree it would be better if there were published benchmark
> results for .NET itself.)

You almost have to. But the GC and the JIT for Mono both suck compared to 
the ones optimized by MS.

> Because you have to make sure it actually happens, and uses up-to-date
> information. It looks remarkably easy for this step to get missed under
> sufficiently unusual conditions.

At worst, every time you load new code, you throw away all the compiled code.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message