www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vala could replace C ...

reply kris <foo bar.com> writes:
http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-programming-with-less-fat

"Vala is still a work in progress, but support for the language is 
growing rapidly. Close GObject integration makes Vala an ideal choice 
for GNOME development, and the requisite library support is steadily 
falling into place. Vala's biggest deficiency right now is the lack of 
documentation. In time, Vala could replace C as the principle language 
of the GNOME platform."
Sep 02 2007
next sibling parent reply Reiner Pope <some address.com> writes:
kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 
 
 
 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

Most of the listed features, D has too: - Interfaces - Properties - Signals (why is this a language feature?) - Foreach - Lambda expressions - Type inference for local variables - Generics - Non-null types - Assisted memory management - Exception handling - Type modules (Plugins) I'm not sure how type modules work, but I do know about non-null types, and they would sure be nice in D. -- Reiner
Sep 02 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Reiner Pope wrote:
 kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 


 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

Most of the listed features, D has too: - Interfaces - Properties - Signals (why is this a language feature?)

For object destruction notification with weak pointers, some runtime support is required, which one could argue imposes language requirements.
 - Foreach
 - Lambda expressions
 - Type inference for local variables
 - Generics

Generics or templates? Big difference.
 - Non-null types
 - Assisted memory management
 - Exception handling
 - Type modules (Plugins)
 
 I'm not sure how type modules work, but I do know about non-null types, 
 and they would sure be nice in D.

Plugin support in D would be great. There is DDL... Sean
Sep 03 2007
parent BLS <nanali nospam-wanadoo.fr> writes:
Sean Kelly schrieb:
 - Type modules (Plugins)

 I'm not sure how type modules work, but I do know about non-null 
 types, and they would sure be nice in D.

Plugin support in D would be great. There is DDL...

Meanwhile I am quit pessimistic regarding DDL Bjoern
 
 Sean

Sep 03 2007
prev sibling parent reply renoX <renosky free.fr> writes:
Reiner Pope Wrote:
 kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 
 
 
 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

Most of the listed features, D has too: - Interfaces - Properties - Signals (why is this a language feature?)

Maybe to have a better syntax?
 - Foreach
 - Lambda expressions
 - Type inference for local variables
 - Generics
 - Non-null types

Are you sure that D has the 'non-null types' feature? What I understand by 'non-null types' is like in Nice: having a syntax to declare nullable types, and by default types are not nullable i.e Type foo = null; is an error (if possible a compile-time error). Type? foo = null; is ok. This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you. AFAIK D doesn't have this. renoX
 - Assisted memory management
 - Exception handling
 - Type modules (Plugins)
 
 I'm not sure how type modules work, but I do know about non-null types, 
 and they would sure be nice in D.
 
 
    -- Reiner

Sep 04 2007
parent reply Reiner Pope <some address.com> writes:
renoX wrote:
 Reiner Pope Wrote:
 kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 


 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

- Interfaces - Properties - Signals (why is this a language feature?)

Maybe to have a better syntax?
 - Foreach
 - Lambda expressions
 - Type inference for local variables
 - Generics
 - Non-null types

Are you sure that D has the 'non-null types' feature? What I understand by 'non-null types' is like in Nice: having a syntax to declare nullable types, and by default types are not nullable i.e Type foo = null; is an error (if possible a compile-time error). Type? foo = null; is ok. This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you. AFAIK D doesn't have this.

You should have read what you quoted afterwards :-)
 I'm not sure how type modules work, but I do know about non-null types, 
 and they would sure be nice in D.


    -- Reiner


D doesn't have it, but I think they would be nice. -- Reiner
Sep 04 2007
parent reply renoX <renosky free.fr> writes:
Reiner Pope Wrote:

 renoX wrote:
 Reiner Pope Wrote:
 kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 


 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

- Interfaces - Properties - Signals (why is this a language feature?)

Maybe to have a better syntax?
 - Foreach
 - Lambda expressions
 - Type inference for local variables
 - Generics
 - Non-null types

Are you sure that D has the 'non-null types' feature? What I understand by 'non-null types' is like in Nice: having a syntax to declare nullable types, and by default types are not nullable i.e Type foo = null; is an error (if possible a compile-time error). Type? foo = null; is ok. This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you. AFAIK D doesn't have this.

You should have read what you quoted afterwards :-)
 I'm not sure how type modules work, but I do know about non-null types, 
 and they would sure be nice in D.


    -- Reiner


D doesn't have it, but I think they would be nice.

Ooops, sorry for having misread your post. And yes it would be nice but on one hand it's a "specialised" feature, it only works for non-null checks, I've read some article about Haskell which talks about 'type modifiers' where for example you could declare a function to return a type 'Maybe Foo' and the typesystem makes you checks whether there is an error or not before being able to use 'Maybe Foo' as 'Foo'.. So it's more generic, but of course having Type? is a more readable syntax than 'MaybeNull Type'. renoX
 
     -- Reiner

Sep 04 2007
parent Reiner Pope <some address.com> writes:
renoX wrote:
 Reiner Pope Wrote:
 
 renoX wrote:
 Reiner Pope Wrote:
 kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 


 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

- Interfaces - Properties - Signals (why is this a language feature?)

 - Foreach
 - Lambda expressions
 - Type inference for local variables
 - Generics
 - Non-null types

What I understand by 'non-null types' is like in Nice: having a syntax to declare nullable types, and by default types are not nullable i.e Type foo = null; is an error (if possible a compile-time error). Type? foo = null; is ok. This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you. AFAIK D doesn't have this.

 I'm not sure how type modules work, but I do know about non-null types, 
 and they would sure be nice in D.


    -- Reiner



Ooops, sorry for having misread your post. And yes it would be nice but on one hand it's a "specialised" feature, it only works for non-null checks, I've read some article about Haskell which talks about 'type modifiers' where for example you could declare a function to return a type 'Maybe Foo' and the typesystem makes you checks whether there is an error or not before being able to use 'Maybe Foo' as 'Foo'.. So it's more generic, but of course having Type? is a more readable syntax than 'MaybeNull Type'.

I think that's just a feature of pattern matching with algebraic data types. (Well, when I say just, I don't mean to demean it, though.) They are very interesting, but they can mostly be already emulated in D through meta-programming (I've been playing with doing this and it is over-all quite promising. For many of the problems I encounter, I think "this will be fixed with hygienic macros"). The problem is that it is easy, given a never-null type to make a maybe-null type -- you just make an algebraic datatype data MaybeNull a = Null | Some a whereas the situation is much harder the other way around: how do you create a never-null type based on a maybe-null type? We can try to emulate this in future D using static parameters: struct NeverNull(T) { T impl; void opAssign(static T t) { static assert(t !is null, "Can't assign null to a never-null"); impl = t; } T implicitCastTo() { return impl; } } This would catch any attempt to write NeverNull!(int*) = null; at compile-time (since null is a compile-time constant). However, the fundamental problem is that the type system loses information in constructors: the result of a constructor is guaranteed to be non-null (am I right? or are there GC issues?), yet it is typed as a nullable type. So the following *should* be guaranteed to work NeverNull!(int*) = new int; yet assigning a nullable to a never-null doesn't typecheck in the general case, as it could allow int* i = null; NeverNull!(int*) = i; Without never-null types, I don't think the type system can distinguish those two cases. -- Reiner
Sep 04 2007
prev sibling next sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 
 
 
 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

Looks like the GNOME folks wanted to write their own language specifically for GNOME stuff. That said, 'Vala /might/ replace C for the GNOME team.' I don't think many outside the GNOME team would be very interested. ~ Clay
Sep 03 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Clay Smith wrote:
 kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 


 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

Looks like the GNOME folks wanted to write their own language specifically for GNOME stuff. That said, 'Vala /might/ replace C for the GNOME team.' I don't think many outside the GNOME team would be very interested.

It sounds to me like they're trying to make something like ObjC but based on glib. --bb
Sep 03 2007
prev sibling parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 
 
 
 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

I think you've been oversold. Note that it's at version 0.13. Read how it does memory management. Search the site for documentation. (Documentation is one of the main reasons that I've avoided gcj. I NEED to be able to call C libraries...and gcj will let me, but won't describe how. [Well, *I* haven't found where it's described.] I could use Fortran or Ada, but they don't have garbage collection. Eiffel, another possibility, is still recovering from it's most recent schism...and it provokes them so often that it's never been able to standardize it's libraries. [E.g., gobo works with SmartEiffel 1.0, but not with 1.2, and the compiler writers are disdainful of any suggestion that they should consider that a problem. "To us SmartEiffel is a research project.") Vala is interesting, especially because it looks to have easy support for GTK, and easy linkage to C. (Both ways? It's not clear. Could you call a Vala routine from a program started in C?) And as usual the problem is with C++ libraries. Nobody but C++ appears able to talk to them directly. At some point I really MUST learn to use swig. 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.
Sep 03 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Sep 03 2007
parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
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.
Sep 03 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Charles D Hixson wrote:
 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).

Building a library is as easy as building the obj's, then putting them into a library with lib or ar. Granted, dmd could build the library itself like it does the link itself.
 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.

If you give the D routine C linkage, with extern (C), you can call it directly from any language that supports C (including, of course, C!).
 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.

The h2d.exe program will convert C headers to D import files. It isn't perfect, but it does a pretty good job of it.
 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.

That's ok. The advanced stuff is there for the folks who need it, for bread & butter programmers it can be ignored. But, I also intend to make it so easy to do templates, you won't even notice you're using them!
 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.

That's a good suggestion.
 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.

Sep 03 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

 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.

The h2d.exe program will convert C headers to D import files. It isn't perfect, but it does a pretty good job of it.

While it is possible to run h2d.exe using Wine, there are also some open source and free software like the h2d.pl hack or the bcd.gen program... http://www.algonet.se/~afb/d/h2d.pl (GD, GL, AL, SDL, Tk, etc. etc.) http://www.dsource.org/projects/bcd (fltk2, gtk+, libxml2, etc. etc.) It's nowhere as convenient as with C-compatible languages like C++ or Objective-C where you can do a #include, but it usually does the trick. (and once the initial D import module has been created, it normally only needs minor patches to keep up with version updates from the C header) The real issue is C++ headers, where it is needed to generate one C++ file with extern "C" and one D wrapper that calls these function stubs. Or with system headers that aren't distributable, or other secret stuff where everyone has to re-generate their own bindings instead of sharing. For instance with libraries like wxWidgets, you run into both of these. --anders
Sep 03 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
Charles D Hixson wrote:
 
 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.

In Tango, these are: extern (C) void rt_init( void delegate(Exception) dg = null ); extern (C) void rt_term( void delegate(Exception) dg = null ); Sean
Sep 04 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Charles D Hixson wrote:
 kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 


 "Vala is still a work in progress, but support for the language is 
 growing rapidly. Close GObject integration makes Vala an ideal choice 
 for GNOME development, and the requisite library support is steadily 
 falling into place. Vala's biggest deficiency right now is the lack of 
 documentation. In time, Vala could replace C as the principle language 
 of the GNOME platform."

I think you've been oversold.

Who? Me? I'm just the messenger boy. Thought ppl might be interested?
Sep 03 2007
parent Charles D Hixson <charleshixsn earthlink.net> writes:
kris wrote:
 Charles D Hixson wrote:
 kris wrote:
 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 
...


Who? Me? I'm just the messenger boy. Thought ppl might be interested?

And I quote " Vala could replace C ...". (It *is* interesting.)
Sep 03 2007
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Charles D Hixson wrote:

 Vala is interesting, especially because it looks to have easy support 
 for GTK, and easy linkage to C.  (Both ways?  It's not clear.  Could you 
 call a Vala routine from a program started in C?)

Seeing as how "valac" generates C source code, I don't see why not... e.g. http://www.algonet.se/~afb/d/sample1.vala => http://www.algonet.se/~afb/d/sample1.h http://www.algonet.se/~afb/d/sample1.c "Vala is a modification of C# to better match the GObject type system." I'm sure it could generate D source code instead, if it made any sense.
 And as usual the problem is with C++ libraries.  Nobody but C++ appears 
 able to talk to them directly.  At some point I really MUST learn to use 
 swig.

Nobody, *including* C++ itself, is able to talk with C++ libraries :-) --anders
Sep 04 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Bj÷rklund wrote:
 Nobody, *including* C++ itself, is able to talk with C++ libraries :-)

It's true. And getting two C++ libraries from different vendors to coexist peacefully is yet another major problem. After all, what if each invents their own custom string class? Override operator new? etc.
Sep 04 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Anders F Bj÷rklund wrote:
 Nobody, *including* C++ itself, is able to talk with C++ libraries :-)

It's true. And getting two C++ libraries from different vendors to coexist peacefully is yet another major problem. After all, what if each invents their own custom string class? Override operator new? etc.

Getting two C++ libraries from the SAME vendor to work together is a problem! <bangs head on keyboard after struggling all day with MSVC7 vs MSVC8 library incompatibilities> --bb
Sep 04 2007
prev sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Anders F Bj÷rklund wrote:
 "Vala is a modification of C# to better match the GObject type system."
 I'm sure it could generate D source code instead, if it made any sense.

It does to me. I think the difference in compilation speed of GCC vs DMD justifies just that.
Sep 04 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Julio CÚsar Carrascal Urquijo wrote:

 "Vala is a modification of C# to better match the GObject type system."
 I'm sure it could generate D source code instead, if it made any sense.

It does to me. I think the difference in compilation speed of GCC vs DMD justifies just that.

It doesn't to me, since I normally use GCC to compile my D code too. (gdc is a lot faster than g++, but that's because of the languages) --anders
Sep 04 2007