Am 14.08.2012 14:25, schrieb Invisible:

>>> According to the Great Language Shootout, C# Mono is 3x slower than C.
>>> (Then again, Haskell is 2x slower...)
>>
>> A factor of 3x compared to what is probably the fastest
>> more-or-less-high level language doesn't sound that bad to me, given how
>> much easier it is to program anything serious in it. (You don't want to
>> write a GUI program in C, do you?! You'd at least want C++)
>
> My point is, adding a low-level feature to shave off 0.02% runtime
> overheard in a language which already has 200% overhead seems... odd.

I wouldn't be surprised if your estimate of 0.02% is a good deal off the 
mark.

Post a reply to this message

> The C# design /is/ pretty solid for a modern language. Much more solid
> at least than the current Java language.

"More elegant than Java" is a bit like saying "cooler than the surface 
of the Sun". :-P

> Oh, and don't bother to mention Haskell in this context; you've done a
> fair share of ranting about that language already to disqualify it for
> the position of "an elegant design that solves everything [without
> accumulating non-elegant layers of additional features]".

So what do you think Haskell solves inelegantly?

It's no secret that the libraries lack vast swathes of important 
functionality, or that some of the build tools leave a lot to be 
desired. But the core language itself? It isn't perfect, but it's a 
damn-site more elegant than any other programming language I've ever 
laid eyes on.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> Valid point. But in a commercial setting, pretty irrelevant.
> >
> > It will become relevant when Microsoft inevitably stops supporting XP.
> >
> > It might not happen next month, or even next year, but the clock is
> > ticking.

> What do you mean "when"? This has already happened.

> http://en.wikipedia.org/wiki/Windows_XP

> "Mainstream support ended 14 April 2009."

It still gets security patches, doesn't it?

-- 
                                                          - Warp

Post a reply to this message

Am 14.08.2012 14:57, schrieb Invisible:

>> Oh, and don't bother to mention Haskell in this context; you've done a
>> fair share of ranting about that language already to disqualify it for
>> the position of "an elegant design that solves everything [without
>> accumulating non-elegant layers of additional features]".
>
> So what do you think Haskell solves inelegantly?
>
> It's no secret that the libraries lack vast swathes of important
> functionality, or that some of the build tools leave a lot to be
> desired. But the core language itself? It isn't perfect, but it's a
> damn-site more elegant than any other programming language I've ever
> laid eyes on.

That may well be true, and I actually believe it, but as soon as you 
want to do some serious programming you'll /need/ more than that elegant 
core; you'll need those libraries of which /you/ yourself said that 
various of them suck for this and that reason and none of them gives you 
exactly what you need.

An elegant core language may be nice to have, but if as a consequence it 
takes you ages to get the job done, unless you make use of plenty 
non-elegant language extensions or libraries, it doesn't /really/ 
qualify as "a simpler, more elegant design that solves everything".

Post a reply to this message

>> So what do you think Haskell solves inelegantly?
>>
>> It's no secret that the libraries lack vast swathes of important
>> functionality, or that some of the build tools leave a lot to be
>> desired. But the core language itself? It isn't perfect, but it's a
>> damn-site more elegant than any other programming language I've ever
>> laid eyes on.
>
> That may well be true, and I actually believe it, but as soon as you
> want to do some serious programming you'll /need/ more than that elegant
> core; you'll need those libraries of which /you/ yourself said that
> various of them suck for this and that reason and none of them gives you
> exactly what you need.
>
> An elegant core language may be nice to have, but if as a consequence it
> takes you ages to get the job done, unless you make use of plenty
> non-elegant language extensions or libraries, it doesn't /really/
> qualify as "a simpler, more elegant design that solves everything".

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

Seriously, what?

Haskell does not have the rich set of libraries that C# has because it 
wasn't developed by a multi-billion dollar global mega corporation. It 
was developed by three beardy guys in a shed on day. If it ever becomes 
popular, we'll see more libraries being developed for it. If (as seems 
more likely) it never becomes really popular, then we won't. But either 
way, this has nothing to do with whether the language is well-designed 
or not.

Post a reply to this message

>>>> Valid point. But in a commercial setting, pretty irrelevant.
>>>
>>> It will become relevant when Microsoft inevitably stops supporting XP.
>
>> What do you mean "when"? This has already happened.
>
>> "Mainstream support ended 14 April 2009."
>
> It still gets security patches, doesn't it?

Er... I'm not sure, actually. Perhaps so.

Post a reply to this message

Le 2012-08-14 04:31, Invisible a écrit :
> On 14/08/2012 02:01 AM, Darren New wrote:
>
>> 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.

Correct me if I'm wrong, but apart from showing that the standard 
seemingly allows it, how would you use that in a real world scenario?

By exporting foobar, you intend to use it somewhere else in your code, 
right? Which means there's another piece of code somewhere that expects 
to receive something of type bar, without knowing what type bar actually is!

How does that work?


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 14/08/2012 13:11, Warp a écrit :
>> IIRC, C++ does not duplicates the class function members (not even
>> > pointers to them) in each instance. Only the actual class (as 1 pointer)
>> > is stored within each instance. The virtual function is just an index.
>> > The first virtual/inheritance cost a pointer in the class. The next are
>> > free.(in fact, with RTTI, even without inheritance, you might already
>> > have that pointer: so no additional cost)
> But if your class were eg. the size of one pointer, then adding any virtual
> functions would double its size.


Tetracapilli... if you compile with RTTI (default for most, including
gnu), an instance of an empty class is already the size of a pointer: to
the class description.

Adding any virtual function in such case would not increase the size of
the instance.

Also, remember that even if the root class is size of a pointer, its
children can only get the same size or larger. If every layer adds a
pointer, the second layer is already the size of two: one proper, one
from parent field (and a third for RTTI)

Removing RTTI <==> no dynamic_cast<>,... might break some code, yet it's
possible (for tight embedded system, including the Embedded C++ spec,
which are just PITA and was made for very low memory system).
In Embedded C++, there is no multiple inheritance, no C++ cast (neither
down or up), no mutable attribut, no namespace, no exception, no
templates and no stdio.
Usage of EC++ is low, but that's might already be too much. It's kind of
C on very fascist mode.

Post a reply to this message

>> 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
>
> Correct me if I'm wrong, but apart from showing that the standard
> seemingly allows it, how would you use that in a real world scenario?
>
> By exporting foobar, you intend to use it somewhere else in your code,
> right? Which means there's another piece of code somewhere that expects
> to receive something of type bar, without knowing what type bar actually
> is!
>
> How does that work?

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.

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.

Post a reply to this message

As with any language, my WTF list:

- Unsigned integers have names prefixed with "u", and signed integers 
have no prefix. Except byte, which is the other way around: "byte" and 
"sbyte". WTF?

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

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

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

- "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!)

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

- Anonymous delegates /and/ lambda functions?

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

- Extension methods. Just... what??

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

Post a reply to this message