• Walter (10/10) Jun 08 2002 Downloads of D in June are averaging double what they were in May. (In f...
• Matthew Wilson (27/37) Jun 08 2002 I bloody hope so! Am still (and probably always will be) a C++ die-hard,...
• Sean L. Palmer (128/150) Jun 09 2002 but

"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

"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

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

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

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

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

I hear ya.


 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

all
 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

take
 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

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

No shit.  :)