 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 10:40, schrieb Invisible:
>> Diamond inheritance isn't a problem if you don't have implementations.
>>
>> OK, so Thread declares void run(), and DistressedDamsel declares void
>> run(). Why would those declarations conflict?
>
> 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?
Depends on the language. You could, for instance, have a syntax to
define a Thread::run() and a separate DistressedDamsel::run(); don't
know whether C# can do that though. Maybe, maybe not. I'd just make a
guess that Java can't do it.
> 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++)
>> Sure there is, because you recompile the code while it's running.
>
> That sounds remarkably hard to get right...
Ever heard of JIT-compilers?
All you need to do is mark the corresponding classes as not-yet-compiled
again.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> OK, so Thread declares void run(), and DistressedDamsel declares void
>>> run(). Why would those declarations conflict?
>>
>> 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?
>
> Depends on the language. You could, for instance, have a syntax to
> define a Thread::run() and a separate DistressedDamsel::run(); don't
> know whether C# can do that though. Maybe, maybe not. I'd just make a
> guess that Java can't do it.
Is there /anything/ Java does right? ;-)
>> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 13:59, schrieb Invisible:
> On 14/08/2012 12:33 PM, clipka wrote:
>> C# was never meant to win a design contest. It was meant to be a decent
>> everyday programming language.
>
> And surely starting with a solid design is the best way to do that.
The C# design /is/ pretty solid for a modern language. Much more solid
at least than the current Java language (which has added tons of kludgy
stuff because they found their initial elegang solution wasn't that
elegant after all for plenty of use cases), or the newest C++
incarnation (which has added badly needed stuff - like smart pointers,
to name just one example - via templates, leading to a somewhat
cumbersome syntax for everyday stuff).
The reason for C# being pretty solid is precisely that they did /not/
aim for an elegant core language to add the other features on top, but
rather designed a language that provides all the features out of the
box, with a somewhat consistent syntax and all.
>> Besides, there's no such thing as as an elegant design that solves
>> everything [with reasonable effort for the language user].
>
> I disagree.
You're free to do that. Still, do you happen to know any counterexample?
(And if so, why aren't you using that language?)
>> Many tasks
>> require certain common design patterns you don't want to re-implement
>> over and over again, so one way or another you'd end up adding layers on
>> top of that elegant design, which - because the elegant design doesn't
>> provide them out of the box - will often be far from elegant to use.
>
> Again, I do not agree.
Again, a few counterexamples might give your disagreement a /bit/ more
weight.
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]".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] dev null> 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
|
|
| |
| |
|
|
|
|
| |
|
|
