The D Programming Language, Version 1.0
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:
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,
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
- similar syntax
- No virtual machine or interpreter
- built-in unit testing and design-by-contract
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,
- My programs come together faster and have fewer bugs.
- Once written, the programs are easier to modify.
- I can do (1) and (2) without giving up performance.
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.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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!
What language is the VM written in?
"But it does exist, unfortunately"
No, just because pompous dimwits (why are they always ruby users) make up new (stupid) names for old things, doesn't mean we have to play along and give them the attention they crave.
"It does only check if a method for a given signature exists while real strong typing, dynamic or not would also check if that method is inherited from the correct superclass or implemented from the correct interface."
You are confused about what strong typing means. You are talking about structural typing vs nominative typing, which is completely orthogonal to dynamic vs static and strong vs weak.
Both ruby and ocaml are strongly typed languages. You can't coerce one type to another, defeating the type system. Ocaml is static, it checks types at compile time, and thus forbids you from assigning a different type to the same variable. Ruby is dynamic, checking types at run time, so you are allowed to make x be a string here, and then a float there.
They are both structurally typed, meaning object types are considered equivilent if they have the same signature. Nominally typed languages require explicit inheritance to be considered equivilent. Just because java is static, strong and nominative, doesn't mean you have to be nominative to be strong. Or that being nominative makes you strong. You can have strong and structural, or weak and nominative.