Vala could replace C ...

[Charles D Hixson]

Walter Bright wrote:
> Charles D Hixson wrote:
>> But D is here now, and if the libraries aren't all that one could 
>> wish, they show promise of growing over time, and not being 
>> arbitrarily broken.
> 
> Also D has very easy compatibility with C, and it goes both ways.

Even building a D library isn't "easy".  Were I to attempt it, 
I'd use GDC (which currently means limiting myself to a subset 
of D's features).

It's also not clear (to me) how to call a D routine from a 
program whose main routine is written in another language. 
This is a significant limitation...especially when more than 
one language makes it difficult.

Now I will readily grant that I'm not the best programmer 
using Linux...especially when one gets down to linking 
routines.  I haven't debugged from an octal dump since the CDC 
7600, and I've never used a hex dump since the Apple ][. 
Before I started using D my favorite languages were Ruby and 
Python (Ruby for elegance, Python for speed).  As such, if the 
documentation doesn't specify how to include and link in the 
correct libraries, and how to initialize anything that needs 
initialization, I'm pretty much lost.  And I don't alway know 
where to look in the documentation, or what terms to use.  (I 
learned in Python to rely heavily on code examples...as well 
as documentation indexes.  This doesn't work as well in D, as 
there usually aren't any simple examples to do what I 
want...or if there are, I don't know where to find them.)

FWIW, D's compatibility with C is better than that of most 
languages.  This doesn't make it good.  I understand the 
problem caused by macros in header files...but they are a 
severe impediment to "very easy compatibility".  "Very easy 
compatibility" (my definition) means that I take of chunk of C 
code in multiple separate files linked by header files, and 
replace on of the files with a chunk of D code that performs 
an equivalent function.  This isn't possible, and probably 
isn't going to be possible.  At any rate, not until 
interpretation of C header files is handled.

I'm more or less in awe of the manipulations that can be done 
with templates...but I'm never going to be interested in using 
them at more than a very basic level.  I am more interested in 
run-time flexibility rather than in compile time flexibility. 
  Importing C header files, though, would immediately move D 
up to "The Single Most Superior Language" in my books.  (OK. 
I read the comments a few years ago, and you were advised that 
this was a can of worms and should be avoided.  It's probably 
right.  But it would be *SO* convenient.)

Another thing that would be useful is a specific and well 
documented entry point in the libraries (probably std.compiler 
or std.object) that could be called to do all necessary 
initializations if the main routine were, e.g., C.


OTOH, you notice that I'm posting here.  D appears a better 
language for me to use than any other.  Just not perfect.  So 
for the moment I'm doing etudes in C that I'll eventually link 
to D routines.  This will let me call C object files and 
libraries from D with only a lot of extra work and 
indirection.  Ugly and inconvenient, but better than the 
obvious alternatives.