Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The D Programming Language, Version 1.0

kdawson posted more than 6 years ago | from the coming-of-age dept.

Programming 570

penguinblotter writes in a journal article: "Soon, Walter Bright is scheduled to release version 1.0 of the D Programming Language. D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. D has appeared on Slashdot a few times before, and Walter has continued to add more and more features. Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives. It has been here over the past seven years where extremely gifted and experienced programmers hashed out discussions and arrived at excellent implementations of all the ideas discussed." Read on for the rest of penguinblotter's writeup.
For those with a C/C++ background, D offers:

  • native code speed
  • extremely fast compilation times
  • garbage collection (although you can manage your own memory if you want)
  • OOP - by reference only, easy initialization, always virtual
  • cleaner template metaprogramming syntax, more powerful templates, as well
  • built-in dynamic and associative arrays, array slicing
  • versioning (no preprocessor madness)
  • link-compatibility with C
  • nested functions
  • class delegates / function pointers
  • module system
For those with a C#/Java background (a shorter list, but one with big wins):
  • similar syntax
  • No virtual machine or interpreter
  • built-in unit testing and design-by-contract
These two comparison sheets can go into more depth on how D stacks up against other languages.

From D's creator:
For me, it's hard to pinpoint any particular feature or two. It's the combination of features that makes the cake, not the sugar, flour or baking powder. So,
  1. My programs come together faster and have fewer bugs.
  2. Once written, the programs are easier to modify.
  3. I can do (1) and (2) without giving up performance.
Get your compilers and start hacking D!
  • DMD (Digital Mars reference compiler, Windows & Linux, x86)
  • GDC (GCC front-end)

Sorry! There are no comments related to the filter you selected.

This won't work... (5, Funny)

PurifyYourMind (776223) | more than 6 years ago | (#17424762)

...it's just another version race. D may have won for now, but someone out there is already working on the E programming language. ;-)

Re:This won't work... (3, Funny)

0racle (667029) | more than 6 years ago | (#17424824)

Now, after F do we get G or 10?

Re:This won't work... (1)

cmeans (81143) | more than 6 years ago | (#17425642)

The language naming started at A, not 0.

Re:This won't work... (4, Informative)

TERdON (862570) | more than 6 years ago | (#17425762)

Now, after F do we get G or 10?


Either it'll be called 10, or H. G, has already been taken, not only once [wikipedia.org] , but twice [wikipedia.org] .

For your reference (kudos goes to Wikipedia [wikipedia.org] ), the following single letter (sometimes including some additional nonalphabetic characters) have also been implemented:

A+ [wikipedia.org] A++ [wikipedia.org] B [wikipedia.org] C [wikipedia.org] C-- [wikipedia.org] C++ [wikipedia.org] C# [wikipedia.org] D [wikipedia.org] E [wikipedia.org] F [wikipedia.org] F# [wikipedia.org] G (now known as Deesel) [wikipedia.org] G [wikipedia.org] J [wikipedia.org] J# [wikipedia.org] J++ [wikipedia.org] K [wikipedia.org] L [wikipedia.org] M4 [wikipedia.org] Q [wikipedia.org] R [wikipedia.org] S [wikipedia.org] S2 [wikipedia.org] T [wikipedia.org] X10 [wikipedia.org]

So - that only leaves you the letters H, I, N, O, P (sic!), U, V, W, Y and Z if you don't want to have a name clash with another programming language. Technically, M and X are followed by numbers in the previous examples, so you could argue for them as well, and even A (as it has a plus behind the letter)

I'm mostly surprised that noone has thought of a (P)rogramming language. :)

Re:This won't work... (1)

Anonymous Brave Guy (457657) | more than 6 years ago | (#17425852)

I'm mostly surprised that noone has thought of a (P)rogramming language. :)

Sorry, someone's already been there and done that [wikipedia.org] . :-)

Re:This won't work... (1)

doctormetal (62102) | more than 6 years ago | (#17424838)

Someone Did that [wikipedia.org] years ago.
Bu seriously: Why do we need yet another programming language?

Re:This won't work... (1)

Nasarius (593729) | more than 6 years ago | (#17424944)

Why do we need yet another programming language?
Because C and C++ suck in many ways. The number of useful languages that can be compiled to native code is very small. I'm not sure about D, though. I'm looking through the tutorials, and it seems like strings are implemented as C-style character arrays. That seems incredibly stupid and Unicode-hostile.

Re:This won't work... (0, Flamebait)

spitzak (4019) | more than 6 years ago | (#17425260)

You are apparently totally ignorant of modern design if you think storing strings as bytes preculdes Unicode. There is something called UTF-8. Look it up sometimes. You might need to hit yourself with the cluestick a few times to remove the delusion that there is some advantage in having all the glyphs take the same number of bits and/or that there is any solution out there where the glyphs do all take the same number of bits. Hints: 1.Text is made of WORDS, sentences, paragraphs, lines, and many many other structures that are variable length. 2.There are things called "surrogate pairs" in utf-16. 3.There are "combining characters".

The fact that D jettisoned a whole lot of crap for "wide characters" is one of the best indications that they get it and know what they are doing!

Re:This won't work... (1)

tcopeland (32225) | more than 6 years ago | (#17425300)

> You might need to hit yourself with the cluestick
> a few times to remove the delusion that there is some advantage
> in having all the glyphs take the same number of bits and/or that
> there is any solution out there where the glyphs do all take the same number of bits.

Hm, doesn't UTF-32 do just that? Quite a bit of wasted space... but you can certainly index into it quickly.

Re:This won't work... (1)

jyoull (512280) | more than 6 years ago | (#17425610)

wow. that was unnecessarily harsh. Your words would have meant a lot more without all the invectives.

Re:This won't work... (1)

Sterling Christensen (694675) | more than 6 years ago | (#17425268)

If you use a dchar when you foreach over a char array it will parse UTF8 for you. Most of the string functions support unicode.

Re:This won't work... (4, Insightful)

jlarocco (851450) | more than 6 years ago | (#17424994)

Why do we need yet another programming language?

Exactly. There's already Fortran and COBOL, everything else is superfluous.

Seriously though, why don't we need another programming language? It's not like we only get a finite number of them. We're not going to run out of space or anything.

If it doesn't interest you, don't use it.

Re:This won't work... (2, Insightful)

0racle (667029) | more than 6 years ago | (#17425024)

Did you say the same thing when Python or Ruby were created? People do things in different ways, different languages end up with their strengths and weaknesses that way. So until there is a perfect language that is all things to everyone, yes there is always a need for another language.

Because the ones we have suck? (1, Insightful)

Dion (10186) | more than 6 years ago | (#17425170)

C/C++ are primitive languages barely above the level of Assembler macros.

Java is a bit nicer than C++ but it just can't perform at the level of C (how many OS'es are written in Java?)

perl/ruby/python are closer to being good languages, but they still don't perform like a compiled language.

I don't know if D gives the features of Perl with the speed of C, but it's certainly a step in the right direction.

Re:Because the ones we have suck? (1)

jyoull (512280) | more than 6 years ago | (#17425686)

Java is a bit nicer than C++ but it just can't perform at the level of C (how many OS'es are written in Java?)

What with Java being an interpreted language and all, how would ya write an OS in Java? I guess you've have to have an OS-OS that runs the interpreter and provides all the low-level stuff that... what? oh. Yeah. turtles all the way down, isn't it? I guess if ya had that, we could write a Java OS and then find out.

Anyway just suggestin' that performance doesn't necessarily explain the "why isn't the OS written in java" question. A doesn't follow B. Socrates is not mortal, etc.

Re:Because the ones we have suck? (1)

StrawberryFrog (67065) | more than 6 years ago | (#17425804)

how many OS'es are written in Java?

How many OS'es are written in Python?
Neither Java, ruby, perl nor python attempt be appropriate languages for writing OS'es. This doesn't make them good or bad. Other factors might.

I don't know if D gives the features of Perl with the speed of C

Hell, I hope not. Perl might collapse into a black hole if any more features are piled into it

Re:This won't work... (1)

butlerdi (705651) | more than 6 years ago | (#17424848)

Been around a long time already ... http://erights.org/ [erights.org] and very good it is as well

Re:This won't work... (1)

creimer (824291) | more than 6 years ago | (#17424874)

Yes, but don't forget the conspiracy by publishers to charge huge amount for doorstoppers... I mean reference books... that comes out every year whether the information is old or updated.

Re:This won't work... (0, Flamebait)

Master of Transhuman (597628) | more than 6 years ago | (#17425082)


Do what I do - download the books as ebooks from some illegal ebook site. If there's any interest in a book at all, somebody's made an ebook out of it already. Might be harder to find than a popular song, but it's probably out there somewhere.

The same thing is happening to publishers as is happening to other media - they just don't realize it yet, but physical books are obsolete. Their business model is going to have to change just like the music industry - except I suspect they're going to find it a lot harder to accept that than even the music business has.

Re:This won't work... (0, Offtopic)

jb.hl.com (782137) | more than 6 years ago | (#17425140)

The same thing is happening to publishers as is happening to other media - they just don't realize it yet, but physical books are obsolete. Their business model is going to have to change just like the music industry - except I suspect they're going to find it a lot harder to accept that than even the music business has.

Their business model must change to cope with freeloaders like you. Presumably, the new business model will be "give everything you invest money in away for free", as the "new business model" mooted for the music industry is.

*sigh*

Re:This won't work... (0, Offtopic)

tcopeland (32225) | more than 6 years ago | (#17425212)

> Do what I do - download the books as ebooks from some illegal ebook site.

Fortunately, enough people feel this is wrong to keep book publishers in business, even for niche markets [pmdapplied.com] . Also, ebooks are still a pain. I'm not sure which is the more significant factor...

E's taken! (1)

headkase (533448) | more than 6 years ago | (#17424990)

Hold your horses, E [fov120.com] is already used in a quite good Amiga Language.

D is surprisingly good. (3, Informative)

FishWithAHammer (957772) | more than 6 years ago | (#17424800)

I'm looking at using it via GDC for my next project. For people who use C/C++ regularly, this is something you ought to look into.

It's not a toy language. If you're a C++ programmer, you'll be almost immediately functional in the language. And you can call C and C++ libraries seamlessly. It's pretty sweet.

Re:D is surprisingly good. (5, Informative)

matrixise (643691) | more than 6 years ago | (#17425016)

from http://digitalmars.com/d/interfaceToC.html [digitalmars.com]

D does not provide an interface to C++. Since D, however, interfaces directly to C, it can interface directly to C++ code if it is declared as having C linkage.

D class objects are incompatible with C++ class objects.

Re:D is surprisingly good. (2, Informative)

Brandybuck (704397) | more than 6 years ago | (#17425072)

And you can call C and C++ libraries seamlessly.

Really? Not according to their FAQ. C yes. C++ no. Otherwise I would be in the process of switching over as we speak.

Re:D is surprisingly good. (0)

Anonymous Coward | more than 6 years ago | (#17425238)

Perhaps the most powerful part of C++ was the development of the STL. That is what changed C++ from just being C with fully defined classes to being a very powerful language. I wonder if there is anything in D that would break the simplicity of STL (yeah, yeah, I know I'm going to get flamed by some for this statement). If D can use a ported STL as simply, I would change over in a minute.

Of course I am very annoyed that the author used the name "D Programming Language." I thought everyone had already decided that it was going to be the "P Programming Language" followed by next iteration called the "L Programming Language." Well C++ sort of broke that rule, but I am still annoyed!

Re:D is surprisingly good. (1)

canuck57 (662392) | more than 6 years ago | (#17425466)

I'm looking at using it via GDC for my next project. For people who use C/C++ regularly, this is something you ought to look into.

This is a (repeat) commercial plug for a language that has tried before and never got accepted. If you want a more modern language, write Java, if you want machine performance speeds then C/C++. If you don't know pointers, then you don't know how the machine works. I would never use a doctor that didn't know how my body worked.

See also: C, Objective-C, C++... D! Future Or failure? [slashdot.org]

This seems to crop every few years for the last few decades...

Re:D is surprisingly good. (2, Insightful)

Geoffreyerffoeg (729040) | more than 6 years ago | (#17425562)

If you don't know pointers, then you don't know how the machine works. I would never use a doctor that didn't know how my body worked.

Yes, but last time I went to the doctor he didn't grab a hand pump and start pushing my blood around.

And when was the last time C let you manually push items onto the stack?

Work, play. Pick either one. (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#17424830)

All these languages. So little time.

My goodness. (0, Offtopic)

Lord Kano (13027) | more than 6 years ago | (#17424888)

Someone is making sweet love to the bandwidth. I'm downloading at less than 6KBps.

Erm how is this better.. (-1, Flamebait)

Dark_MadMax666 (907288) | more than 6 years ago | (#17424946)

"No Virtual machine"... -that is a HUUGE downside not upside .Net is fairly well performing for example ,and is language independent (for language freaks there is boo# which is basically dynamically typed .net language ) .I fail to see how this one is better. Virtual machine gives so many advantages , the only disadvantage is theortiecla performance issues ,but .net in this aspect is top notch and often performs better than its pure c++ counterparts.

Re:Erm how is this better.. (2, Insightful)

Nasarius (593729) | more than 6 years ago | (#17424998)

Try using .NET for systems programming. Or projects (I've made several thousand dollars from one so far) that must be portable to NT4, 2K/XP without requiring your clients to install extra junk on every computer, etc. Contrary to what Microsoft may want you to believe, .NET is not the solution to all the world's problems.

Re:Erm how is this better.. (-1, Troll)

Anonymous Coward | more than 6 years ago | (#17425152)

you're a fkin moron. God damned people like you need to drown in the ocean.

Re:Erm how is this better.. (2, Informative)

TheGavster (774657) | more than 6 years ago | (#17425154)

What, exactly, is the benefit of the .Net VM? There is only one full implementation of .Net (the MS one), and it runs on a single platform (Windows on x86). You might as well build native x86 code linked against Windows libraries for all the portability you have. And even if you're going to bother implementing the VM across a bunch of platforms, why not implement a standard library across a bunch of platforms and link native executables against that?

Re:Erm how is this better.. (1)

tcopeland (32225) | more than 6 years ago | (#17425272)

> You might as well build native x86 code linked against
> Windows libraries for all the portability you have.

That's a good point. Still, the VM does serve as an insulating layer against OS changes. But Microsoft is pretty good about not breaking backwards compatibility, so that's not a great advantage. Any idea if there's a C# to native compiler out there? Googling around, I came up with this thing [remotesoft.com] .

The app I work on uses Ruby and Flash [getindi.com] to be crossplatform; working out pretty well so far...

Re:Erm how is this better.. (0)

Anonymous Coward | more than 6 years ago | (#17425434)

At least two platforms, X86 32 bit and X86 64 bit, and I think, Itanium (not so sure).

The reason why not shared library is the whole 'machine code generation' being different for different platforms. Sure, MacOS has universal binaries, but it does mean double the exe size and can't cope with new platforms coming out, or processor specific optimisations. (I belive the .Net framework will use MMX registers sometimes if they're available, for example.)

Re:Erm how is this better.. (1)

pdbaby (609052) | more than 6 years ago | (#17425506)

You might as well build native x86 code linked against Windows libraries for all the portability you have

I don't think that portability's a feature of .NET... I think that its great runtime safety checks & logical std library are the major thing it brings to the table.

The portability thanks to Mono's just an added benefit for some of us

Re:Erm how is this better.. (1)

Curate (783077) | more than 6 years ago | (#17425714)

There is only one full implementation of .Net (the MS one), and it runs on a single platform (Windows on x86).


Not quite correct. The .NET runtime is available for all Windows architectures: x86, x64, and ia64.

Re:Erm how is this better.. (2, Informative)

Heembo (916647) | more than 6 years ago | (#17425716)

In .NET it's called a Common Runtime Library, running MSLI code. (That sentence is analogous to "the Java Virtual Machine runs Bytecode"

The big win in .NET is that there is built-in administrator controllable security (even pub/priv key security) between the CRL (or vm to you) and the internal .NET framework. In fact, there are several administrative controllable hooks built into the .NET framework that we just do not see in Java and Ruby and the others. This is the feature that separates .NET from the rest, and the rest of these frameworks are working to catch up. All modern languages are or should be moving into this direction. I predict that in 5 years the ONLY way you will be able to code to the WinOS is via the secure API that is .NET. (Assuming your programmers and admin teams understand .NET very well!)

.NET is horrible at scaling (less you got a big hardware budget), so I see .NET all over the DoD and internal sites, but not so much for full-in internet sites where Java is winning in the top 10 (example, MySpace is a Java app).

Re:Erm how is this better.. (0, Flamebait)

spitzak (4019) | more than 6 years ago | (#17425290)

What language is the VM written in?

Re:Erm how is this better.. (0)

Anonymous Coward | more than 6 years ago | (#17425426)

Your kidding right?

Right?

It's right there in your post (1)

Weaselmancer (533834) | more than 6 years ago | (#17425556)

"No Virtual machine"... -that is a HUUGE downside not upside .Net is fairly well performing for example

"Fairly well". Me, I'd rather have good. Or exceptional. What you're describing there is "marginal", and that's an excellent reason to steer clear of .NET.

Weird writeup: (3, Insightful)

Per Abrahamsen (1397) | more than 6 years ago | (#17424952)

From the compared to C/C++ list:

        * native code speed

As opposed to C/C++.

        * extremely fast compilation times

Point granted (compared with most C++ compilers).

        * garbage collection (although you can manage your own memory if you want)

Point granted, even though C and C++ arguably have optional garbage collection as well (if you link to the right library).

        * OOP - by reference only, easy initialization, always virtual

Only value semantic? Meyer had to accept that value semantic was useful, and add it to Eiffel eventually, and C# added it over Java.

And no way to specify that a function will always be the one specific. Good luck doing any kind of reasoning there.

Bragging about missing features, that are essential to many tasks.

        * cleaner template metaprogramming syntax, more powerful templates, as well

*More* powerful templates? The usual complaint is that C++ templates are too powerful (a Turing-equivalent compile time language).

        * built-in dynamic and associative arrays, array slicing

Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.

        * versioning (no preprocessor madness)

I'm guessing he meant variants here, the preprocessor is often used for variants, rarely for versioning.

        * link-compatibility with C

Which C and C++ of course lacks?

        * nested functions

Point.

        * class delegates / function pointers

Obviously both C and C++ have function pointers.

        * module system

More preprecessor replacement here.

The C#/Java list:

        * similar syntax

But totally different from C++?

        * No virtual machine or interpreter

You can compile Java and C# to native code as well, so this is just another case of bragging about a missing feature.

        * built-in unit testing and design-by-contract

I'm a C++ programmer, and this is by far the most interesting aspect of the D language (and of Eiffel before that). Don't know why it should be in the Java/C# list.

Re:Weird writeup: (3, Informative)

91degrees (207121) | more than 6 years ago | (#17425034)

Couple of points:

* native code speed

I think this is a response to criticisms from C programmers about most modern languages, rather than a benefit over C.

Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.

Some of this is useful enough to be built in. stl and the like are pretty handy but sometimes it feels a bit of a kludge. Plus, built-in allows better optimistations for specific cases.

Obviously both C and C++ have function pointers.

Yes, and the syntax is horrible. D makes this a lot nicer.

Re:Weird writeup: (0)

Anonymous Coward | more than 6 years ago | (#17425342)

*More* powerful templates? The usual complaint is that C++ templates are too powerful (a Turing-equivalent compile time language).

The usual complaint that I hear is that C++ templates are unwieldy, clumsy, and produce incomprehensible compiler or linker error messages. If they can provide a meta-programing facility without the confusing mess of C++ templates then I'm all for it.

Re:Weird writeup: (1, Interesting)

Anonymous Coward | more than 6 years ago | (#17425420)

* nested functions

Point.
Why do so many people care about nested functions [wikipedia.org] ? I really don't see the use except for people who want to write Pascal-like girly-man code. It isn't as if your stack doesn't treat non-nested functions as nested functions in some implementations (as in you'll return to the instruction one after where you started). Is this about people who want to share data between functions but are afraid to use classes, references, or pointers; people who don't want to share information between parts of a function; or people are afraid of the normal forms of polymorphism (all options depending upon the implementation of course)? The answer: use references, write your functions shorter, overload your functions, and stop crying like a baby.

Re:Weird writeup: (1)

Mike McTernan (260224) | more than 6 years ago | (#17425430)

> >* versioning (no preprocessor madness)
>
> I'm guessing he meant variants here, the preprocessor is often
> used for variants, rarely for versioning.

I does look like variants to me, but appears to be called versioning - check this:

http://www.digitalmars.com/d/version.html [digitalmars.com]

Re:Weird writeup: (0)

Anonymous Coward | more than 6 years ago | (#17425440)

The most important change wasn't mentioned in the writeup. From the comparison chart [prowiki.org] , D has built in array bounds checking. The lack of automatic bounds checking in C and C++ single-handedly accounts for more than 50% of all security holes. If everyone dropped C and C++ and switched to something with automatic bounds checking our software would be far, far more secure.

Re:Weird writeup: (0)

Anonymous Coward | more than 6 years ago | (#17425508)

A lot of bounds checking can be added by the compiler. So it's not so much about dropping the language, as improving the tools. I've seen various gcc patches for C array checking and the backend already looks to have the capabilities in there:

http://www.lrde.epita.fr/~akim/compil/doc/bounds-c hecking.html [epita.fr]

Borland CodeGuard also did array bounds checking for C a long time ago.

Re:Weird writeup: (0)

Anonymous Coward | more than 6 years ago | (#17425588)

It was already solved in the early 90s by the STL. Additionally, it is easier to use for things like text input (which crackers use to break in). In fact, with the ways that STL has been optimized, the programmer would probably have about the same speed with the STL constructs as with most functions they use with standard arrays. Programmers who still use arrays directly had better be doing loops or high speed systems programming. If not, then they should be prepared to be beaten without remorse.

Re:Weird writeup: (1)

IamTheRealMike (537420) | more than 6 years ago | (#17425472)

The Win32 API makes heavy use of macros for versioning, so I do not believe you can classify it as "rare". Maybe it's rare on UNIX but that's a failing, not a strength.

Re:Weird writeup: (1, Funny)

Anonymous Coward | more than 6 years ago | (#17425490)

the core language apparently is so weak that these can't be put into libraries...

LMAO! And, as expected, we see your true colors. C++ FANBOY OFFENDED. FILM AT 11:00!

Re:Weird writeup: (1)

Sterling Christensen (694675) | more than 6 years ago | (#17425598)

* built-in dynamic and associative arrays, array slicing

Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.
Show me a C implementation and I'm show you a D inplementation - the syntax is almost identical sans preprocessor. It certainly wasn't done that way for any core language weakness.

* versioning (no preprocessor madness)

I'm guessing he meant variants here, the preprocessor is often used for variants, rarely for versioning.
Nope, no variants. There's actually a version keyword, for "versioning" (conditional compilation).

Re:Weird writeup: (0)

Anonymous Coward | more than 6 years ago | (#17425648)

I haven't even looked at D yet, but...

*More* powerful templates? The usual complaint is that C++ templates are too powerful (a Turing-equivalent compile time language).
Sure they are supposedly "Turing-equivalent", but leveraging that is a nightmare. The complaint about C++ templates isn't that they are expressive, it is the hoops you have to jump through to take advantage of this and how error prone and obscure it is.

* built-in dynamic and associative arrays, array slicing

Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.
This implies that you think the C/C++ handle of arrays is good?!

java native code compilation (2, Informative)

Nutty_Irishman (729030) | more than 6 years ago | (#17424956)

All other considerations aside, runtime speed really should be a justification as a bonus to Java. Java isn't that much slower if you actually take the time to compile it to native code first. Using something like a JIT compiler http://en.wikipedia.org/wiki/Just-in-time_compilat ion [wikipedia.org] can greatly increase the speed of your code and put it close in line with C++. I would certainly consider D if both 1 and 2 were better than Java.

Re:java native code compilation (4, Informative)

Decaff (42676) | more than 6 years ago | (#17425230)

Java isn't that much slower if you actually take the time to compile it to native code first. Using something like a JIT compiler http://en.wikipedia.org/wiki/Just-in-time_compilat [wikipedia.org] ion can greatly increase the speed of your code and put it close in line with C++.

This is a bit of an old myth. Almost all Java is run as native code these days, even on VMs, and is mostly pretty close to C++ speed. Benchmarks that show Java as significantly slower than C++ usually result from not allowing the VM enough time to perform native code translation of time-critical code. Java has moved away from JIT compilation (as against the later optimisation of HotSpot) because it led to long start-up times - you had to wait for code to be compiled to native before it ran. Now Java usually starts up as interpreted, with the translation to native code happening later on, in the background.

Where C, C++ and D win out over Java in terms of performance is when you need programs that have to start up fast, run fast, but only for short periods (a few seconds).

Cheers for D! (1)

RAMMS+EIN (578166) | more than 6 years ago | (#17425042)

Cheers for D, and happy new year to Walter and all the rest! As much as the D community is often derided for their sometimes aggressive marketing, D is actually a programming language that can run with the best of them.

GUI for D language (1)

twkrimm (802775) | more than 6 years ago | (#17425046)

I am hoping that D is or soon will be a good alternative to C#.net and Mono. What is the preferred GUI environment for D? I was watching the D forums during the first half of 2006 but I could never post any questions to the D forums so I gave up. It looks like I gave up too soon. Does anybody know why I could not post to the D forums?

Re:GUI for D language (1)

kihjin (866070) | more than 6 years ago | (#17425240)

Here are some options:

  • DUI [sf.net] - GTK+ bindings
  • DWT [dsource.org] - Port of the Standard Widget Toolkit


D can access routines in a C library, so any C GUI toolkit can be used from within D.

Re:GUI for D language (1)

Skylinux (942824) | more than 6 years ago | (#17425318)

Looks like it's called DUI and it works on Linux and Windows.

DUI is D GUI [sourceforge.net]

I give it a "F" (0)

Anonymous Coward | more than 6 years ago | (#17425128)

I don't see D as an advancement in programming languages. I give it a "F"

Another 'Toy' Programming Language (-1, Troll)

Anonymous Coward | more than 6 years ago | (#17425150)

Yay, yet another 'toy' programming language, joining the likes of Java, Ruby, Python, and the reset of the bunch.

Suitable I should think, for "I.T" projects, cobbled together by cable-pullers, thinking they are actually programmers.

I'll stick to languages that have at least a professional following, in use by real software engineers (that is, engineers who can legally call themselves engineers), not the run of the mill code monkeys.

Re:Another 'Toy' Programming Language (0)

Anonymous Coward | more than 6 years ago | (#17425178)


I'll stick to languages that have at least a professional following, in use by real software engineers (that is, engineers who can legally call themselves engineers), not the run of the mill code monkeys.

Me too, PHP is da bomb!

Re:Another 'Toy' Programming Language (4, Funny)

nacturation (646836) | more than 6 years ago | (#17425216)

I'll stick to languages that have at least a professional following, in use by real software engineers (that is, engineers who can legally call themselves engineers), not the run of the mill code monkeys.
I'm dying to know... do you mean Fortran or Lisp?
 

Re:Another 'Toy' Programming Language (1)

eneville (745111) | more than 6 years ago | (#17425820)

Yay, yet another 'toy' programming language, joining the likes of Java, Ruby, Python, and the reset of the bunch.

Suitable I should think, for "I.T" projects, cobbled together by cable-pullers, thinking they are actually programmers.

I'll stick to languages that have at least a professional following, in use by real software engineers (that is, engineers who can legally call themselves engineers), not the run of the mill code monkeys.
what do you mean toy programming languages? java is almost identical to c#, give or take some rather small things. would you classify visual basic as a toy, i certainly do? or even pascal, but look a little deeper and pascal executes and compiles faster than c. how can you call a language a toy, it's a tool. if you cant work out what tool is best for a job then you probably do not have good enough experience with that job to know.

Slashdot doesn't read full archives (1)

LostCluster (625375) | more than 6 years ago | (#17425164)

Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives

You must be new here.

Re:Slashdot doesn't read full archives (1)

JamesTRexx (675890) | more than 6 years ago | (#17425646)

Actually, that means he isn't new here. :-P

Currently learning D (5, Informative)

kihjin (866070) | more than 6 years ago | (#17425188)

Note: I've been programming in C/C++ for four years.

I took it upon myself to learn D not more than a few weeks ago. A classmate introduced me to the language last spring.

While I'm still learning D, it has some notable features:

  • auto keyword for inferred type declaration
  • lazy keyword for evaluation
  • delegates are like function pointers, but cooler. Literal statements can be passed as variables, and aren't evaluated until the delegate is called.
  • scope(exit|failure|success), specify a block of exit code
  • in/out/inout function keywords, offer readable code for determining what a parameter in a function is designed for.
  • get/set methods automatically become a property (accessed like a public variable)
  • foreach, foreach_reverse, container iteration
  • with statement, C++'s using on a object-level

Of course one may argue that none of this is necessary and could be made independent of the language itself. My belief is that would increase the complexity of coding in D.

If you're interested in D you should visit http://www.dsource.org/ [dsource.org] . There are some interesting projects such as Derelict [dsource.org] (collection of C game bindings) and Bud [dsource.org] (make and SCons replacement).

Re:Currently learning D (1)

iluvcapra (782887) | more than 6 years ago | (#17425594)

Intersting. How are public interfaces to private implementations declared, and how are mixins written?

On dsource.org I can't find any examples of public headers into libraries.

It looks like a step down (4, Funny)

Anonymous Coward | more than 6 years ago | (#17425196)

After working so hard to get from C to C++, I don't see why I would settle for D. My next programming language is going to be B- or better.

More old junk repackaged to look new (0)

Anonymous Coward | more than 6 years ago | (#17425202)

This language is simply not worth noting. It's a simple evolutionary step over c/c++ but still suffers in many ways from their flaws.

Seriously, how is a language like this newsworthy? It does nothing for taking us forward in the world of development languages. There are numerous languages already far more sophisticated and closer to the future that D could ever hope to be. D is simply a sad attempt at holding onto the past.

*snore*

Do we really need another D infomercial? (3, Insightful)

Anonymous Brave Guy (457657) | more than 6 years ago | (#17425262)

I'm sure D is a lovely language, but it just seems like another incremental change over C++, like Java and C# before it, and like both of those languages what it's lost and the opportunities it misses are as telling as the little tweaks it makes to improve things.

No-one has yet been successful, IMHO, in developing a really good industrial programming language. Those that make it tend to be pragmatic, practical tools like C and Perl and FORTRAN and COBOL. To be sure, each of these has many widely-acknowledged weaknesses, but the overall balance between those weaknesses and what you could get done using the language was right.

I can increasingly see why some well-known programming language designers shy away from feature comparison ticklists. I think it's because as soon as you go down this route, you bias the comparison so much that it's meaningless. For example, consider the first checklist [prowiki.org] cited in the Slashdot write-up. (I note in passing that this is a wiki, and may change before you read this.) Here are some of the "yes or no" (almost) categories:

Templates or executable macros
No difference in expressive power is acknowledged between LISP macros and C++ templates.
Thread synchronization primitives
With no reference to how expressive they are, and how powerful the idioms supported by them? This one is really telling, IMHO, because I don't believe the future lies in classical thread sync and locking primitives. The whole approach is just too prone to deadlocks and race conditions to withstand the heavily parallel future that multicore chips are starting to bring into the mainstream. When you have ideas like pure function programming languages, operating in a world without side-effects where explicit locking isn't necessary, or interesting ideas for inter-thread communication such as those in Erlang, another variation on built-in pthreads just isn't worth much.
Enumeration
So again, we acknowledge no difference between simple and low-level enumerations such as those in C, and concepts such as disjunctive types and pattern-matching that are very powerful, remarkably elegant, and mainstream in certain families of programming language. Again, this is just papering over a gap, where other languages operate on an entirely different level.
Long double floating point (80bit)
This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches.
Lexical Closures
Another telling omission: the power of all those neat functional programming features is dramatically reduced when you can't construct functions on-the-fly.

On top of all of this, the feature lists invariably gloss over some less concrete things that are nevertheless very important to systems programming languages. How portable is D? How many production-quality implementations are available? Is the language standardised or under the control of a single, commercial body? How much backing is there behind the language in the commercial development space; do others write libraries specifically for this language, or is it reduced to using C-style interfaces at the lowest levels anyway, and what impact does this have on the usefulness of features like DBC, exceptions, and so on? Does the language have an active hobbyist/volunteer community supporting it?

I could go on, but I don't want this post to disappear into the oblivion any more than it already will. Although I'm deliberately focussing on criticising in this post, as I often do with D, I keep an open mind and will happily engage in debate with others, or even be proved wrong by people who have found D to have compelling advantages. So go ahead, D advocates, start your counter-arguments here...

Re:Do we really need another D infomercial? (0)

Anonymous Coward | more than 6 years ago | (#17425730)

some of my reasons for considering d are:
-d is the first powerful language i could learn.
-after i learned d i could learn c usage as well, but not before.
-i've done a text processing program in d in a matter of minutes (well, probably 1h+, whatever) compared to 2-3 nights without sleep (and the corresponding days) in c. it is true that the latter was a 3d OBJ importer, but only i know how hard and messy it was.
-i don't have to fight against pointers anymore;
-i don't like c++, nor java (though i love curly brackets :P).
i think you might give d a try, also check these differences, if you didn't already:
http://digitalmars.com/d/cpptod.html [digitalmars.com]
http://digitalmars.com/d/ctod.html [digitalmars.com]
the readability and logic gives speed to developing.
thanx

Re:Do we really need another D infomercial? (2, Insightful)

stevenj (9583) | more than 6 years ago | (#17425860)

Long double floating point (80bit) — This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches.

Um, considering that the vast majority of the world's floating-point hardware is x86 and supports extended precision, saying that it lacks "true support from almost every mainstream architecture" is comical.

(I agree that relatively few numerical applications need extended precision on a regular basis, but it is awfully useful on occasion. A very simple use is to assess the impact of roundoff error on a double-precision program: by far the easiest way is to increase the precision and see how much the answer changes, but this requires a floating-point type with greater than double precision. Yes, you could drop in an arbitrary-precision type, but this may be too slow in a large computation.)

In any case, D's claim to this feature is a bit odd, since every x86 C/C++ compiler worth its salt already compiles long double to extended precision.

Cargo cult programming (0)

Anonymous Coward | more than 6 years ago | (#17425284)

"Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python."

This may be half of it, but I would say a core part of its focus is something with enough curly-braces to be palatable to stubborn C and C++ programmers.

I really hate banging this drum, but Lisp (the language that everybody who doesn't know loves to hate) has had for many years the high performance of C and C++ (through optimizing native compilers and profilers), and at least as much power and productivity as Ruby and Python (through even higher-level features, not the least of which are macros).

I'm not saying this to be disrespectful to D. Apparently that's a big feature. A powerful homoiconic language that uses parentheses is a hard sell, because people will associate it with things they think are true about other languages that look like that. For example, they might think that it's interpreted (even though I've never seen a Common Lisp that wasn't compiled, and only one that doesn't compile to native code). OTOH, when they see braces, they might associate it with C/C++.

It's 2007, and cargo cults are alive and well.

Re:Cargo cult programming (0)

Anonymous Coward | more than 6 years ago | (#17425596)

There's a lot more to being "C-Like" than curly braces. The big thing is that the assembly is right under the hood. Thats a good thing (easy linkage, easy debugging), and a bad thing because the stack as scope control, variable storage, and communication link is terribly fragile.

Plus there is some value to the syntax. Clever tricks aside, the simple statement nature of c-likes makes transition easier for everyone who knows such a language already.

I think the cult of lisp is at least as guilty as the cult of c of the sin of making syntax into a holy sacrement.

Re:Cargo cult programming (1)

Marsell (16980) | more than 6 years ago | (#17425644)

It's 2007, and cargo cults are alive and well.

Yes, Common Lisp and its myriad dialects^Wvendors just never die.

It would be nice if the Lisp community would finally stop with their tomfoolery and come up with one decent variant that is used and supported by everyone. Common things like threads, sockets, threads, connecting to databases, calling foreign functions... a less elistist and knee-jerk defensive community would help too.

You'd think the Lisp world would have figured this out by watching Perl, Python, and now Ruby; garden-variety Lispers pride themselves on their brilliance after all.

Lazy Questions (2, Informative)

Quantam (870027) | more than 6 years ago | (#17425468)

Looking at the comparison lists, D looks pretty nice. It has a lot of features that I'd consider switching languages for (from C++), but any such language would have to have a few particular properties (due to the kinds of things I program):
1. Must be able to disable garbage collection and manage allocation explicitly
2. Must be able to allocate classes on the stack
3. Must minimize use of exceptions in the standard library (in other words, exceptions must only be used for exceptional cases)

Java fails all of them, if I recall correctly (I don't know that much about Java, actually). C# fails 2 and 3. It looks like you can disable garbage collection in D, but in the comparison list I didn't see mention of 2 or 3. Does anybody know, off the top of their head?

Re:Lazy Questions (1)

kihjin (866070) | more than 6 years ago | (#17425928)

These may satisfy your curiosity:
1. You can disable GC entirely, on a per class or per instance basis.
2. Yes, stack classes [digitalmars.com] are easy.
3. I haven't used Phobos in great detail yet, but I haven't encountered anything like Java's exception library.

Hope this helps,

KG

GC, No Vm or performance hit (1, Insightful)

StrawberryFrog (67065) | more than 6 years ago | (#17425486)

garbage collection ... No virtual machine

How do they square that particular circle?

native code speed

Just In Time Compilation in C# or Java has "Native code speed", in fact it goes one better - since the compilation happens at a later time, more processor or other specific optimisations can be made. That's not the slow part. GC has a lot to do with the perceived slowness. Isn't it disingenuous to tout both "native code speed" and "garbage collection"?

Re:GC, No Vm or performance hit (3, Informative)

Nasarius (593729) | more than 6 years ago | (#17425564)

garbage collection ... No virtual machine How do they square that particular circle?
It's really not that difficult. Hans Boehm wrote a garbage collector [hp.com] for C/C++ years ago, which happens to be the same one that the Digital Mars implementation of D uses.

Re:GC, No Vm or performance hit (2, Interesting)

StrawberryFrog (67065) | more than 6 years ago | (#17425924)

If I read that FAQ right, it is possible that "integer or other random data be misinterpreted as a pointer by the collector" since given the nature of C - no VM, the difference between a pointer and an int is at best a gentleman's agreement - anything in memory *could* be a pointer. Well, I suppose it works if he says so. But it certainly isn't pretty.

Re:GC, No Vm or performance hit (0)

Anonymous Coward | more than 6 years ago | (#17425602)

GC has a lot to do with the perceived slowness.

So like, it's not _really_ slow, we just "perceive" that it's slow -- when actually it's, like, really really fast, right?

Re:GC, No Vm or performance hit (1)

StrawberryFrog (67065) | more than 6 years ago | (#17425656)

Every time someone posts on here that they perceive java as slow, they get jumped on. I wouldn't know the reality, It's been a while since I used some java, but the perception is real.

Re:GC, No Vm or performance hit (1)

Nasarius (593729) | more than 6 years ago | (#17425806)

The perception is quite valid if you use a Java GUI app. Eclipse and Azureus are really cool, but their interfaces are incredibly sluggish. Compare this to, say, wxPython or Tcl/Tk (interpreted languages using a native C or C++ library), which run GUIs just fine.

Re:GC, No Vm or performance hit (4, Informative)

Anonymous Brave Guy (457657) | more than 6 years ago | (#17425606)

garbage collection ... No virtual machine ... How do they square that particular circle?

The same way as countless other programming languages have in the past, I imagine. Why do you think garbage collection requires running your code under a VM?

Just In Time Compilation in C# or Java has "Native code speed", in fact it goes one better - since the compilation happens at a later time, more processor or other specific optimisations can be made.

Of course, you're overlooking all the overhead of monitoring the code long enough to determine which on-the-fly optimisations are worth performing, and of compiling the code itself, neither of which is trivial.

GC has a lot to do with the perceived slowness.

True, though of course it's not without overheads. Almost all of the Big Claims(TM) made by GC advocates in these discussions come with a catch: state-of-the-art GC method number 17 has a lower amortised cost of memory recovery than explicitly freeing it C-style!*

* But only if your system contains 10x as much memory as the program will ever need anyway.

This is traditionally followed by a wisecrack about how memory is cheap, followed by three enlightened posters pointing out the stupidity of that argument for multiple reasons. :-)

Isn't it disingenuous to tout both "native code speed" and "garbage collection"?

That depends a lot on context. If you really have a system where the overheads of GC are trivial but all the advantages are present, it seems a fair claim. It's just not likely to be universally true, and representing it as such would indeed be disingenuous.

Re:GC, No Vm or performance hit (1)

StrawberryFrog (67065) | more than 6 years ago | (#17425724)

The same way as countless other programming languages have in the past, I imagine. Why do you think garbage collection requires running your code under a VM?

Because in a non-vm language like C with its use of pointers for everything, it is very hard if not impossible to tell if an object on the heap is in fact still in use and can not be automatically reclaimed. Sure you could have a Vm with pointers, but one of the main advantages of the Java or .net VM is that it can better track memory use.

Re:GC, No Vm or performance hit (2, Informative)

scoonbutt (1022589) | more than 6 years ago | (#17425668)

Garbage collection has no requirement for using a virtual machine. They usually show up together, but there's no technical requirement.

What about DTraces' D Language (1)

otomo_1001 (22925) | more than 6 years ago | (#17425518)

I thought for sure that the D language was at least 25 years old and built way back when. Then about 2 years ago Solaris 10 came out with dtrace and all of the "scripts" have .d extensions. Yeah I know it is unix and the extensions are meaningless.

Dtrace user guide [sun.com]

But the disambiguation page [wikipedia.org] on wikipedia seems to bear out that calling a programming language D will only be interesting. Anyone know if it is trademarked yet?

No decent XML parser (0)

Anonymous Coward | more than 6 years ago | (#17425536)

I really like D, but it has a one huge shortcoming: no decent XML parser or generator library. Nowadays parsing and generating XML is a very commong task. It makes hard for D to compete against Java or #C.

The feature-checklist school of software design... (4, Insightful)

stevenj (9583) | more than 6 years ago | (#17425654)

...is obviously the birthplace of D. Heavens, it's the union of C++ (already a nightmarishly huge language), C99, and C#, along with dozens of other features halfway borrowed from functional languages and other inspirations. More features must be better, never mind that the language becomes insanely complicated! (Next they'll be throwing in the Fortran 2000 standard.)

My feeling is that languages shouldn't try to satisfy all possible needs. Rather, we should have small and clean languages, use the right tool for each job, and combine code libraries from different languages when needed. (I regularly use 3-6 languages in a single project and my life is much happier for it.)

(Legacy support is critically important too, but it is vastly better to provide legacy support by providing ways to call older languages, especially the lingua franca of C, rather than demanding that the new language be a superset of the old. I still call numerical libraries written in pre-1970 Fortran, but that doesn't mean I have to write my code in a Fortran derivative.)

Python and D (4, Interesting)

MightyMooquack (241719) | more than 6 years ago | (#17425706)

One area I see D being useful in is integration with Python. Writing to the raw Python/C API is cumbersome. (Managing reference counts is tedious.) Boost.Python is difficult to build and slow to compile. I've written a library for D called Pyd [dsource.org] , whose purpose is not entirely unlike Boost.Python's.

Pyd is easy to use. It provides its own extension to Python's distutils. Usually, you just need to make sure the D compiler is on your PATH, write a setup.py file, and run python setup.py build.

"Hello world" in Pyd looks something like this (and I apologize for the lack of indentation):

import pyd.pyd;
import std.stdio;

void hello_func() {
writefln("Hello, world!");
}

extern (C) void PydMain() {
def!(hello_func);
module_init();
}

Re:Python and D (1)

Nasarius (593729) | more than 6 years ago | (#17425884)

Good stuff. Alas, I see you inherit the necessity for FooWrap classes for polymorphism from Boost.Python. Is there any way of doing this automatically, or am I doomed to wrestling with SWIG?

Is anyone ... (2, Funny)

compandsci (1045690) | more than 6 years ago | (#17425738)

... actually going to use this? I think I'll wait for D++

IDE D's Language Features (2, Funny)

trimbo (127919) | more than 6 years ago | (#17425758)

I just can't see why I'd want to switch to a language that has no IDE support and is evolutionary to C# or C++. I hardly have to look at documentation for APIs anymore because I can just use Visual Studio's autocompletion to figure things out.

What Is The Point? (0)

Anonymous Coward | more than 6 years ago | (#17425818)

Am I really the only one who has yet to find a good reason to switch from Algol?

Lies about productivity (1)

Cafe Alpha (891670) | more than 6 years ago | (#17425916)

You can't claim the productivity of dynamic languages without being one. "with the programmer productivity of modern languages like Ruby and Python."

This is a lie.

The productivity of those languages come from:

1. Duck typing, ie no time spent (by the programmer) coming up with class and type hierchies that will support all future behavior of the product. You can make it up as you go along without ever hitting an, oops it isn't possible-and-I-have-to-refactor wall.

2. Dynamic meta-programming - at least in Ruby (I'm not familiar with Python), you can change classes, add/change function etc. at run time.

Some things more complete dynamic languages have, (but I'm not sure about current versions of the mentioned ones) is dynamic debugging where you can change the code (completely - including class definitions) while debugging, save the state of the whole program to continue from later (or debug from later), etc. etc. - advance debugging that C like languages don't have. Related advances, persistant data and the ability to make processes persistant (not just data).

Re:Lies about productivity (1)

Cafe Alpha (891670) | more than 6 years ago | (#17425968)

By the way, there is a push to make a fast dynamic language (this is done by an inlining JIT that takes type statistics at run time and adapts the code while its running).

See: http://www.strongtalk.org/ [strongtalk.org]

It's the libraries, stupid (1)

istartedi (132515) | more than 6 years ago | (#17425950)

I skimmed it, and some of this stuff is a PiTA. For example, they make a lot of good points about the pre-processor, but I can't justify re-working all my code into D just from that alone. Some of this stuff is bells and whistles--e.g., the built in unit testing? You don't need a language construct for that. If your programmers are so lazy or stupid that they can't write unit tests in C or C++, having the language give them a little hand-holding, standard way of doing that is probably not going to help.

If I need classes (and usually I don't), I'd reach for C++

The real reason C and C++ are becoming less the language of choice? It's the libraries, stupid. Most of the new languages have extensive "standard libraries" that keep up with the modern world. C gives you the choice of linking anything, and I think the standard bodies refuse to endorse a wider ranging standard library because they don't want people to get the idea that you can only use a particular set of libs. The other reason of course is that they have better sandboxing and/or exception handling (Java still crashes, but it throws an exception instead of just dumping core or doing something else that's compiler dependant).

While D makes some valid points, they might be better off adding these features to C++ and C compilers, and ultimately converging the two standards. It'd take a long time, but it was 9 years between the revisions of C (the last major one being C99). These language standards move at a glacial pace, and we like it that way!

Something like D seems to offer neither the RAD approach of PHP, Ruby, etc. It doesn't seem to offer the backwards compatable standards track offered by a revision to the C or C++ standards either. It doesn't satisfy the "roll a script fast" crowd, or the "write code that will still be used 30 years from now" crowd, in any particular way. It looks lost in the middle. Unless it gets endorsed by a huge corporation, and I end up working for that corporation, or until it gains industry traction, I don't see any compelling reason to pay the early-adopter price and use it.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?