 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> What's wrong with .NET?
>
Un-cross-compatibility. Get .Net 1.1 -software, .Net 2.0 -software and
.Net 3.0 -software, one for each. Something light, like a simple
card-game. Now, open them all up simultaniously and check the consumed
resources - while .Net -environments are not (fully, to some extent they
are) cross-compatible, you won't get off with just loading .Net 3.0, but
you'll have every one of them ripping theier (big) bits of memory.
AFAIK frameworks like .Net should ease up programming by providing basic
functions allready-coded and ease up resource-consuming as being
something like shared libraries. Need of multiple versions of the same
frameworks simultaniously just.. hmm.. breaks this illusion.
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethis zbxtnetinvalid
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> OOC, have you ever looked at C# yourself?
>
> Not really. From what I understand, it's a kind of "C++ with the same
> limitations as Java".
Not really. It's more like "this is what Java would be like if we threw
it away and started over from scratch, knowing what we learned from the
first Java."
> Just the reason for its existence repulses me: Since Microsoft had to
> abandon their own, standard-breaking version of Java
It didn't break the Java standard. It ran more acceptance tests
correctly than Sun's implementation did. It also offered a way to
access Microsoft functionality from within Java.
Which is not to say C# isn't designed as a Java killer, mind. :-)
--
Darren New / San Diego, CA, USA (PST)
On what day did God create the body thetans?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 wrote:
>> Me, I like the Common Lisp object system.
> Me, I dislike anything that says "Lisp" in it. :-S
You don't need to like LISP to appreciate the object system CLOS
provides. It really isn't much lisp-specific in concept.
> I gave up when the language libraries were so obviously stupid...
Well that too. I was just doing text in/out with it.
> That's a miracle. It's a pretty rare language...
I used Icon too, which is also a pretty cool language. :-)
> Didn't try it personally, no. But that's what the language spec says.
It has been an ongoing complaint that nobody actually implements the
hard parts of the language.
> Note that Eiffel Studio isn't the only implementation. There's Smart
> Eiffel (AKA Small Eiffel) that reguarly does quite well in the language
> shootout benchmarks... But either way, the libraries are very poor.
Unless you use Eiffel.NET. *That* is the power of the .NET stuff, in my
view.
> [E.g., Eiffel provides strong generics support with a whole heap of
> infrastructure to support writing really generic code. So they designed
> one class for character I/O, and a completely unrelated one for binary
> I/O. GAH! >_< Why?!]
Meyers was really desiging a language for designing data structures in.
The data structure libraries are really nicely thought out. A shame the
*useful* stuff isn't there.
--
Darren New / San Diego, CA, USA (PST)
On what day did God create the body thetans?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> you'll have every one of them ripping theier (big) bits of memory.
Yah, that's called "side-by-side execution". It's a selling point,
because you don't wind up with having to support old stuff in new
runtimes, and you can leave the old bugs buggy, avoiding "DLL Hell".
> AFAIK frameworks like .Net should ease up programming by providing basic
> functions allready-coded and ease up resource-consuming as being
> something like shared libraries.
They do.
> Need of multiple versions of the same
> frameworks simultaniously just.. hmm.. breaks this illusion.
Wow, I run Java and C# next to each other, and they both take up memory! :-)
One really has two choices: Run different versions of the runtime and
use up those resources, or have DLL hell where upgrading the runtime
breaks working programs. The "upgrade the runtime and maintain 100%
backward compatibility" eventually turns into a nightmare.
--
Darren New / San Diego, CA, USA (PST)
On what day did God create the body thetans?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> That's a miracle. It's a pretty rare language...
>
> I used Icon too, which is also a pretty cool language. :-)
OK then...
>> Didn't try it personally, no. But that's what the language spec says.
>
> It has been an ongoing complaint that nobody actually implements the
> hard parts of the language.
Heh. I never actually tried it, so I can't comment. I just assumed it
would work. ;-)
>> Note that Eiffel Studio isn't the only implementation. There's Smart
>> Eiffel (AKA Small Eiffel) that reguarly does quite well in the
>> language shootout benchmarks... But either way, the libraries are very
>> poor.
>
> Unless you use Eiffel.NET. *That* is the power of the .NET stuff, in my
> view.
Depends. How good are the .NET libraries? [I hope to God they're better
than the Java ones!]
>> [E.g., Eiffel provides strong generics support with a whole heap of
>> infrastructure to support writing really generic code. So they
>> designed one class for character I/O, and a completely unrelated one
>> for binary I/O. GAH! >_< Why?!]
>
> Meyers was really desiging a language for designing data structures in.
> The data structure libraries are really nicely thought out. A shame the
> *useful* stuff isn't there.
Yeah. Bloody type-I languages...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Why not disallow diamond inheritance?
> Technically, you can't, since there's a common base type for all objects
> in those languages.
No, there isn't: The so-called "interfaces" are not inherited from the
common base class. What would stop these interfaces from having member
variables and function implementations?
Besides, does this common base class have member variables? If not,
there is no problem with diamond inheritance.
And even if it had, since it's an automatic inheritance forced
by the compiler, it's perfectly possible for it to automatically do
the same thing as C++'s "virtual inheritance" does. That is, even if
you multiple-inherit, there's still only one base class part in the
resulting objects and everything referring to this base class uses
this unique instantiation.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> One really has two choices: Run different versions of the runtime and
> use up those resources, or have DLL hell where upgrading the runtime
> breaks working programs. The "upgrade the runtime and maintain 100%
> backward compatibility" eventually turns into a nightmare.
Third choice: Design the system so that you don't *have* to upgrade
ever. ;)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> It also offered a way to
> access Microsoft functionality from within Java.
Isn't that precisely breaking standards?
If Microsoft's version of Java didn't break any Java specifications,
how come Sun sued and won?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > ....so they implemented Java's flawed MI-but-not-MI model? How is that
> > fixing the flaws from other major programming languages?
> Probably fixing what they saw as flawed MI in C++. :-)
They "fixed the problems" by removing multiple inheritance completely?
Maybe MI in C++ has some problems. I has never stopped me from using
MI in C++ efficiently and for really useful stuff, though.
Ok, one small problem with C++'s multiple inheritance might be that
if you want to use virtual inheritance in a diamond inheritance situation,
you would have to have editing access to both base classes you are inheriting
from if they are not virtual-inheriting already. If these classes are eg.
in a library you don't have access to, tough luck.
Of course this is because of technical reasons. The only alternative
would be that classes are *always* virtually-inherited by default, which
would introduce overhead in the vast majority of situations where virtual
inheritance is not needed. (Once again, the possibility of precompiled
libraries and dynamically-loadable libraries makes it not possible to
perform some post-compilation optimizations. Having shared system-wide
dynamically-loadable libraries is too much of an advantage to simply drop
that feature.)
(Btw, I have always wondered: How are you supposed to build huge systems
with languages which do not support dynamically loadable shared libraries?
The advantage of these is that it reduces memory consumption a lot,
because libraries which are common to most programs are loaded into memory
only once, and all the programs use those one unique instantiations.
Without this possibility each program would have to be statically linked
with all the system libraries, and thus the same system libraries would be
loaded into memory multiple times. If there's eg. a huge library used by all
programs, it would be loaded to memory as many times as there are programs
running.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 <voi### [at] devnull> wrote:
> Me, I dislike anything that says "Lisp" in it. :-S
Says the person who is infatuated with functional languages such as
Haskell...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
