www.digitalmars.com         C & C++   DMDScript  

D - D is gaining momentum

reply "Walter" <walter digitalmars.com> writes:
Downloads of D in June are averaging double what they were in May. (In fact,
it seems to double every month.) I'm seeing more and more interest in the
language on the internet, etc.

I think a lot of the success is due to you folks who write articles about D,
put up web pages on D, talk about D on the internet, and in general just
participate. Thank-you! The more people see mention of D in their normal
course of work, the more comfort they'll have in looking at it, adopting it,
and supporting it.

With all your interest and help we can establish D as a major language.

-Walter
Jun 08 2002
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
I bloody hope so! Am still (and probably always will be) a C++ die-hard, but
there are lots of applications where the investment in time and effort do
not make C++ an attractive proposition. We currently have Java as the
pre-eminent alternative, and C#/.NET nipping at its heels, but both these
languages/technologies have lots of disadvantages, including:

- need a runtime
- proprietary M$ == Sun, or if you prefer transitivity M$ == $$ == Sun
- Java does not have const
- do not have templates (D 1.1 or is that 2.0 will have them, as I think I
recall), so neither can claim to be object oriented (weakly typed, since all
containers store Object)
- Java does not have out parameters
- do not have deterministic destructors so cannot claim to be object
oriented (objects do not clear up after themselves, failing the "resource
acquisition is initialisation" idiom)
- .NET does not have Java's useful mandatory handling/declaration of (non
runtime) exceptions - typical M$ short-sighted
easier-to-code-harder-to-maintain rubbish. When is Visual C++ going to take
not of exception specifications?

Hopefully we are able - by dint of being able to bend Walter's ear
directly - to help mould a language that will blitz these two toy languages
out of the water, and in the process all learn a lot more.





"Walter" <walter digitalmars.com> wrote in message
news:adufkr$1t0s$1 digitaldaemon.com...
 Downloads of D in June are averaging double what they were in May. (In

 it seems to double every month.) I'm seeing more and more interest in the
 language on the internet, etc.

 I think a lot of the success is due to you folks who write articles about

 put up web pages on D, talk about D on the internet, and in general just
 participate. Thank-you! The more people see mention of D in their normal
 course of work, the more comfort they'll have in looking at it, adopting

 and supporting it.

 With all your interest and help we can establish D as a major language.

 -Walter

Jun 08 2002
parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:aduj3e$208p$1 digitaldaemon.com...
 I bloody hope so! Am still (and probably always will be) a C++ die-hard,

 there are lots of applications where the investment in time and effort do
 not make C++ an attractive proposition. We currently have Java as the

I hear ya.
 pre-eminent alternative, and C#/.NET nipping at its heels, but both these
 languages/technologies have lots of disadvantages, including:

 - need a runtime

You need a standard library anyway, just lop off the language specification near there. I want my compiler to make the transition from memory to file as seamless as possible. All JIT is a runtime cache to translate bytecode into native code. Kind of integrating the language with the file system if the language can morph bytes on disk into executable code then it can compile itself. I like the idea of builtin compression, but I'd think of it more in terms of "conversion to bytes" then "compress" step that goes on during a save onto a given resource. Many applications don't need a high-powered compression and almost any compression will do (some is better than nothing in many cases). But at least the language could guarantee that in the standard library there's a "compress bytes/uncompress bytes" function available. "encrypt/decrypt" too. (though I'd leave it open to debate as to whether the "standard" GPL one was secure enough <g>. And if you don't use it you don't pay for it eh)
 - proprietary M$ == Sun, or if you prefer transitivity M$ == $$ == Sun

yes
 - Java does not have const

Java has const doesn't it?
 - do not have templates (D 1.1 or is that 2.0 will have them, as I think I
 recall), so neither can claim to be object oriented (weakly typed, since

 containers store Object)

Just because you don't have templates you can't have typesafe container objects? Hmm..
 - Java does not have out parameters

I think this is a cool D feature (one I haven't entirely gotten used to yet)
 - do not have deterministic destructors so cannot claim to be object
 oriented (objects do not clear up after themselves, failing the "resource
 acquisition is initialisation" idiom)

This is the one that I really am sad to be without. Constructors let you kind of make your own typecasting syntax, and deterministic destructors seem necessary if only because I don't want to have to delete something explicitly to make sure it's been shut down properly. But surely that's not enough reason to not be able to claim to be "object oriented" at all? A user could write code that tried to share a non-usable resource such as: class FileWindow { this(char[] name) { handle = file_open(name, READ_ONLY|LOCKED); } ~this() { file_close(handle); } byte get_byte_at_location(uint x) { fseek(handle,x); return fread_byte(); } private: File handle; } int accum; for (int i = ntries; i-- > 0; ) { FileWindow myfile("sysdat.junk"); accum += myfile.get_byte_at_location(7); // delete myfile; // necessary if it doesn't want to get an OS error below // as it tries to open the file again in the next loop iteration after it "forgot" // to clean up after the first loop iteration's "myfile" object. } That's an optimization the compiler should probably be doing anyway since who wants to keep memory around needing later "collection" when you can free it for sure at the end of a function or block? But that's exactly when the compiler should check for dtors that might need to be run. Garbage collection needs to realize that any resource must be collected and freed not just memory. I'd rather make the collection behavior implicit in the language so that the language writes in its own memory collection while compiling everything else. The compiler could insert extra hidden reference counts or maintain any statistics it needed to, form lists of resource holders and do all that kind of manual housekeeping, but it could do so optimally for each type of resource and possibly based on link-time statistics of how many other parts of the code work with this type of object or something. At very least the compiler could determine when no possibility existed for an address within an object had been taken in a given block and thus whether any of those pointers could have possibly been sent elsewhere during that function, it can assume when the block ends nothing else could possibly be referencing it and thus can safely allocate the object on the stack for instance which is a form of primitive memory allocation scheme and has its own built in garbage collection. I want the compiler to just magically "figure out" what parts of the code are referencing objects obtained from somewhere else, and when it manipulates them it notifies them they've been stored or copied or whatever so it can update usage statistics and reclaim the object eventually once no other code is using it anymore. And I want the compiler to write the code to check for it so optimally that I wouldn't be able to do a better job by hand if possible. The compiler could insert extra usage checks on any copy or address-of or store address operation that deals with any object, no matter what type. Hopefully the ability to integrate in "external" resources such as OS thread handles, file handles, network ports, or what have you by declaring "on_copy" or "on_address", or even so far as "on_persist_tobytes" etc. so objects could provide their own validation routines that we could wrap around native handles. Now *that* would be an easy language to use. And probably pretty efficient at runtime too. It could work for almost any resource usage scheme. The compiler would just insert little external reference counts on everything and then optimize them away whenever possible. I like how NT allows the machine to think of a file as an array in virtual memory. Really slow (on first access) memory, but otherwise identical in behavior to regular memory once you've set it up right (and the runtime would set it up right). That would be a good feature in a language, to be able to treat a file the same as an array. The standard D file system could be merely this feature. ;) I think it's doable if you can just simulate the way a cache works. Maps a set of pointers onto another set by hashing such that it knows if you try to access one of the several it's not holding and makes room (ejecting the one previously longest unused if possible). The compiler could generate code that does that, a kind of runtime "monitoring" what is going on during certain "marked" pointer accesses. At very least that would move the garbage collection problem to one of logistically determining within a system (the program) if any of these class of items is created, destroyed, copied, referenced, or dereferenced. Any code generated for this class will notify me if any of that happens and then build a manager for it. Language generate the age-old "Manager" class and you've got yourself a winner for sure.
 - .NET does not have Java's useful mandatory handling/declaration of (non
 runtime) exceptions - typical M$ short-sighted
 easier-to-code-harder-to-maintain rubbish. When is Visual C++ going to

 not of exception specifications?

There's two kinds of maintenance (ok maybe more than 2 kinds): rewriting and looking at the code for bugs and other general improvements of code, and having bugs created because changing one part of the code invalidates some part of an implicit contract between it and other parts of code. By this I mean like having a parallel enum and initialized record indexed by that enum, keeping the enum and record initialization synchronized requires adding a new entry to both places and if you forget to do it it creates a bug you likely won't notice til much later when everything is wacky (someone changing a record pointed to by a nonexistent "last" record whose enum had been added but no corresponding memory backing, so it in turn overwrites something else after the list that you don't find out about til way later type of thing). I like at very least to be able to write something that verifies for sure that it's done properly, that the user of a system is using it properly. D has this (Design By Contract). This kind of language construct is good for doing large-scale engineering efforts with code when you want to kind of globally ensure that something is a certain way and that if that is ever altered it needs to run this code here and notify it because we either need to make sure it's ok or keep track of it, or prohibit it (throw exception). Thanks, the management. That sort of thing might also be useful in programming neural type behavioral systems which are based on feedback.
 Hopefully we are able - by dint of being able to bend Walter's ear
 directly - to help mould a language that will blitz these two toy

 out of the water, and in the process all learn a lot more.

No shit. :)
Jun 09 2002