"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7blsj$2f54$1@digitaldaemon.com...
> Now that is a *nice* idea. Instead of us all fighting over which particular variant library is best it'll just be in the language. It'd be nice if it

covered COM's VARIANT as well, although only if it doesn't require _too_ much shoehorning.

> Maybe the last pre-1.0 feature (along with mixins, of course)?!
>
>
> "Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c7bldu$2efl$1@digitaldaemon.com...
> >
> > "Mark T" <Mark_member@pathlink.com> wrote in message news:c7bfq3$25nd$1@digitaldaemon.com...
> > > >Let's assume for a moment that Bruce is correct in that runtime type checking is just as robust, and enables faster program development. Why, then, is D a statically typed language? It is for performance reasons.
> > When
> > > >the compiler knows exactly what type something is, it can customize the
> > code
> > > >for that type.
> > >
> > > bingo - choose the right tool for the problem at hand, I can't understand
> > why
> > > people can't see the need for both types of languages or they try to force Walter to go "dynamic", there are plenty of dynamic languages to choose
> > from now
> > >
> > >
> >
> > Or D could have a 'variant' type which accounts for any type and it is used exactly like a dynamic type (D does not need to be solely dynamic or static; it could be static, or dynamic when using the 'variant' type).
> >
> > It will also solve the problem of safe variable argument lists.
> >
> >
> >
>
>

Matthew wrote:

> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
> news:c7blsj$2f54$1@digitaldaemon.com...
> 
>>Now that is a *nice* idea. Instead of us all fighting over which particular
>>variant library is best it'll just be in the language. It'd be nice if it
> 
> 
> covered COM's VARIANT as well, although only if it doesn't require _too_ much
> shoehorning.
> 
> 
>>Maybe the last pre-1.0 feature (along with mixins, of course)?!

A built-in variant! That'd be great! The real way to do variable arguments.

>>
>>
>>"Achilleas Margaritis" <axilmar@in.gr> wrote in message
>>news:c7bldu$2efl$1@digitaldaemon.com...
>>
>>>"Mark T" <Mark_member@pathlink.com> wrote in message
>>>news:c7bfq3$25nd$1@digitaldaemon.com...
>>>
>>>>>Let's assume for a moment that Bruce is correct in that runtime type
>>>>>checking is just as robust, and enables faster program development. Why,
>>>>>then, is D a statically typed language? It is for performance reasons.
>>>
>>>When
>>>
>>>>>the compiler knows exactly what type something is, it can customize the
>>>
>>>code
>>>
>>>>>for that type.
>>>>
>>>>bingo - choose the right tool for the problem at hand, I can't understand
>>>
>>>why
>>>
>>>>people can't see the need for both types of languages or they try to force
>>>>Walter to go "dynamic", there are plenty of dynamic languages to choose
>>>
>>>from now
>>>
>>>>
>>>Or D could have a 'variant' type which accounts for any type and it is used
>>>exactly like a dynamic type (D does not need to be solely dynamic or static;
>>>it could be static, or dynamic when using the 'variant' type).
>>>
>>>It will also solve the problem of safe variable argument lists.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

On Wed, 5 May 2004 10:24:25 -0700, "Walter" <newshound@digitalmars.com> wrote:

>
>"Drew McCormack" <drewmccormack@mac.com> wrote in message news:c7a70n$5n9$1@digitaldaemon.com...
>> Anyway, these sorts of arguments tend to end up being religious discussions, so I'll leave it here. I would like to leave off though with a reference to a nice weblog by a well-known C++ proponent, Bruce Eckel, on this very topic:
>>
>> http://www.mindview.net/WebLog/log-0025
>
>One of the great things about Bruce Eckel is his willingness to fundamentally change his opinions when faced with contrary evidence, unlike most people who will construct elaborate rationalizations in order to avoid having to confront being wrong.
>
>Let's assume for a moment that Bruce is correct in that runtime type checking is just as robust, and enables faster program development. Why, then, is D a statically typed language? It is for performance reasons. When the compiler knows exactly what type something is, it can customize the code for that type.

I remember my dad (a biochemist) wanted to give up Basic and learn C because he had heard it was "the language". Well as soon as I started telling him that in C he had to declare his variables before using them he was shocked and decided it wasn't worth it. He's been happily using Basic ever since. :-)

On a more serious note JITs are getting more and more advanced and MATLAB's JIT will compile a given code chunk on the fly with whatever arguments are being used the most. If you call foo with doubles like crazy then foo-with-doubles gets JIT'ed. But there is overhead for keeping track of all that, for sure.

On 2004-05-05 19:24:25 +0200, "Walter" <newshound@digitalmars.com> said:

> 
> "Drew McCormack" <drewmccormack@mac.com> wrote in message
> news:c7a70n$5n9$1@digitaldaemon.com...
>> Anyway, these sorts of arguments tend to end up being religious
>> discussions, so I'll leave it here. I would like to leave off though
>> with a reference to a nice weblog by a well-known C++ proponent, Bruce
>> Eckel, on this very topic:
>> 
>> http://www.mindview.net/WebLog/log-0025
> 
> One of the great things about Bruce Eckel is his willingness to
> fundamentally change his opinions when faced with contrary evidence, unlike
> most people who will construct elaborate rationalizations in order to avoid
> having to confront being wrong.
> 
> Let's assume for a moment that Bruce is correct in that runtime type
> checking is just as robust, and enables faster program development. Why,
> then, is D a statically typed language? It is for performance reasons. When
> the compiler knows exactly what type something is, it can customize the code
> for that type.

Right. Why do you think I am using it? ;-) I need something for HPC. If I write a general purpose desktop app, I tend to use a dynamically-typed language like python or obj-c, not c++, and probably not D. But if performance is critical, l think D is about the best you can do in a statically-typed language.

Drew

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:jt9j90lr5mek4n1aj7js00b76tc145niju@4ax.com...
> On a more serious note JITs are getting more and more advanced and MATLAB's JIT will compile a given code chunk on the fly with whatever arguments are being used the most. If you call foo with doubles like crazy then foo-with-doubles gets JIT'ed. But there is overhead for keeping track of all that, for sure.

JITs are getting better and better. But is MATLAB itself written in a JITted language? is the Java vm written in Java? Is the Python vm written in Python?

That said, there is nothing preventing D code from being executed via a JIT rather than a static compiler.

> JITs are getting better and better. But is MATLAB itself written in a JITted
> language? is the Java vm written in Java? Is the Python vm written in
> Python?
> 
> That said, there is nothing preventing D code from being executed via a JIT
> rather than a static compiler.

I think as the language becomes more popular it is bound to happen. I bet within a year we'll see D in .NET CLR or as Java byte code. I am very excited about the possiblity. While I am blathering on, I'd also like to see a raw C or C++ backend for the D compiler. GCC as an option is really nice, but it really is not the fastest compiler around.

"Billy Zelsnack" <billy_zelsnack@yahoo.com> wrote in message news:c85p17$20km$1@digitaldaemon.com...
> I think as the language becomes more popular it is bound to happen. I bet within a year we'll see D in .NET CLR or as Java byte code. I am very excited about the possiblity. While I am blathering on, I'd also like to see a raw C or C++ backend for the D compiler. GCC as an option is really nice, but it really is not the fastest compiler around.

I've studied both Java bytecode and ILASM a little.  You won't see D in Java
bytecode, because it is very specific to allowing
only the necessary features that Java has.  In other words, you won't get
delegates or pointers, anything of the like.  You could implement DBC and
what not, but the things that make D appropriate as a systems level language
make it too feature-rich for the JVM.

ILASM, on the other hand, is pretty generic.  And it's easy to run many languages on top of it.  I was actually hoping that someone besides myself would start the D.NET project - but it would be great to have a 1.0 compiler to do testing.

The enterprise software world is slowly noticing D, and with unit testing and DBC built in, you can expect some MAJOR attention if you get it running on .NET or in the JVM (although I don't see the latter happening.)

As an aside, I don't suppose there is anyone interested in starting an ILASM compiler for D with me?

"Greg Vanore" <dazden@at.dazden.dot.org> wrote in message news:c8arf7$atu$2@digitaldaemon.com...
> "Billy Zelsnack" <billy_zelsnack@yahoo.com> wrote in message news:c85p17$20km$1@digitaldaemon.com...
> > I think as the language becomes more popular it is bound to happen. I bet within a year we'll see D in .NET CLR or as Java byte code. I am very excited about the possiblity. While I am blathering on, I'd also like to see a raw C or C++ backend for the D compiler. GCC as an option is really nice, but it really is not the fastest compiler around.
>
> I've studied both Java bytecode and ILASM a little.  You won't see D in
Java
> bytecode, because it is very specific to allowing
> only the necessary features that Java has.  In other words, you won't get
> delegates or pointers, anything of the like.  You could implement DBC and
> what not, but the things that make D appropriate as a systems level
language
> make it too feature-rich for the JVM.
>
> ILASM, on the other hand, is pretty generic.  And it's easy to run many languages on top of it.  I was actually hoping that someone besides myself would start the D.NET project - but it would be great to have a 1.0
compiler
> to do testing.
>
> The enterprise software world is slowly noticing D, and with unit testing and DBC built in, you can expect some MAJOR attention if you get it
running
> on .NET or in the JVM (although I don't see the latter happening.)
>
> As an aside, I don't suppose there is anyone interested in starting an
ILASM
> compiler for D with me?
>
>
>
>

Well, if D gets ported to .NET, there goes the neighbourhood! the other half of Earth (i.e. the Unix world) will probably ignore it, since the .NET libraries (WinForms etc, not the compiler!!!) is Microsoft proprietary code and it is never gonna be open source.

I hoped D would be an uber-cross-platform language, not ride the Microsoft board (i.e. something to write the code ONCE, compiled it for on as many platforms as the D compiler is available, and then happily run it ever after).

> Well, if D gets ported to .NET, there goes the neighbourhood! the other half
> of Earth (i.e. the Unix world) will probably ignore it, since the .NET
> libraries (WinForms etc, not the compiler!!!) is Microsoft proprietary code
> and it is never gonna be open source.
> 
> I hoped D would be an uber-cross-platform language, not ride the Microsoft
> board (i.e. something to write the code ONCE, compiled it for on as many
> platforms as the D compiler is available, and then happily run it ever
> after).

If someone writes code to be run natively, they won't use the Microsoft libraries. Because of that, the code would be cross-platform.

My reason for wanting a .net version is to support safe game-mod development on the windows/mono platform (in any .net supported language too). I can still native compile for a console, but I would have the option of providing a safe .net version.

"Achilleas Margaritis" <axilmar@b-online.gr> wrote in message news:c8dqaa$235p$1@digitaldaemon.com...
> Well, if D gets ported to .NET, there goes the neighbourhood! the other
half
> of Earth (i.e. the Unix world) will probably ignore it, since the .NET
> libraries (WinForms etc, not the compiler!!!) is Microsoft proprietary
code
> and it is never gonna be open source.

Very true.  If someone decide to use Windows Forms in D, then that person's code wouldn't be cross platform unless an emulation library existed.  But there are already cross-platform GUI libraries for .NET, thanks mostly due to the work on Mono. If one used those, you could write a cross-platform GUI in D easily - more easily than going straight to native.

Like I said, the optimal scenario is targeting the JVM.  But it doesn't
support delegates, and probably other language features of D (although as of
1.5, it supports generics (templating)).

I mean, I feel the same kind of regret.  One thing that attracted me to D is its Java-like simplicity, yet systems-level power.  That is in some ways bypassed when you talk about targeting .NET or the JVM.  On the other hand, my day job is enterprise software where features like unit testing and DBC could be used heavily to make better software.  There are tools like AspectJ, Barter, XDoclet, JUnit, and other that make this possible - but they are tools built on top of the language, not a part of it.

You may think this good enough, but in that scenario, you have to make a business case.  Management is skeptical to rely 3rd party tools for anything we deliver to a client.  Yet if it is built into the language, it easily opens doors to use it.

Of course, we use Java at my office and not .NET so it's mostly moot, but still, more exposure for the language will ultimately be a good thing.  If we can achieve a transparent D ILASM compiler, then it ultimately doesn't matter.  You can recompile all your D libs to .NET and still use them there, and your D code can be native or .NET.

> I hoped D would be an uber-cross-platform language, not ride the Microsoft board (i.e. something to write the code ONCE, compiled it for on as many platforms as the D compiler is available, and then happily run it ever after).

I'm assuming you mean uber-cross-platform-which-compiles-natively, otherwise I'll just suggest Java.