The D Programming Language, Version 1.0 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
- 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.
This won't work... (Score:5, Funny)
Re:This won't work... (Score:4, Funny)
Re: (Score:2)
Re: (Score:2, Informative)
Re:This won't work... (Score:5, Informative)
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: (Score:2)
Sorry, someone's already been there and done that [wikipedia.org]. :-)
Re: (Score:2)
Re:This won't work... (Score:5, Funny)
I hope someone creates an "O" language. That way, interface bindings for it could be called "O-interfaces", or "O-faces" for short. So when you create a nifty library for the language, publishing it could be known as "showing the world your O-face".
Re: (Score:3, Informative)
Objective-C [wikipedia.org] and the best programming language in existence, C-Intercal [wikipedia.org] (yeah, yeah - you whitespace [dur.ac.uk] lovers can bite me).
I can't believe you don't know this - it's common knowledge that the letter 'P' was skipped because back in the early 80s Wordstar would use control-P to purge your document with no confirmation screen as opposed to Wordperfect's print, so there was an extreme hatred for the letter from
Re: (Score:2)
Bu seriously: Why do we need yet another programming language?
Re: (Score:2)
Re:This won't work... D Strings (Score:3, Informative)
- D arrays are bounds checked. No accidental buffer overflows here.
- D arrays are dynamic, you can resize them and concatenate them together.
- D strings are D arrays, so they get the above bonuses.
- D has distinct 'char', 'byte', and 'ubyte' types. char[] != ubyte[]. When you use foreach to iterate over a char[]/string, it will expand each codepoint (or whatever they are calle
Re: (Score:2)
> 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... (Score:4, Interesting)
Re: (Score:3, Informative)
searching for a character just requires you to compare each 32-bit value to the target, without having to check it isn't a special character that is the first in an escape sequence
UTF-8 was designed so that no complete set of bytes representing a character occurs as a substring of any other. This makes the search problem into a simple search for a string inside another string. The searching routine doesn't even need to know whether or not it's a UTF-8 string or not, just as long as it doesn't mangle the last bit.
Re: (Score:3, Insightful)
I'm not sure which ones you are referring to, except of course English.
Swedish has ÅÄÖ. Norwegian has ÅÆØ, and so does Danish. Finnish has Ä and Ö. German has ÄÖÜ and ß. French has even more weird characters, including Ç. Spanish has Ñ, Ü and accents, and the list goes on. For really weird characters, check Polish.
Re: (Score:2)
Re:This won't work... (Score:5, Insightful)
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: (Score:3, Interesting)
Re: (Score:3, Insightful)
Re: (Score:2)
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
Re:Because the ones we have suck? (Score:4, Informative)
The Squeak runtime for Smalltalk is written in Smalltalk. There is a smallish subset of Smalltalk used to write the basic functionality, which is compiled to native code. This then supports the whole language. The same model is, I believe, used for JNode, an operating system written in Java...
Re: (Score:3, Interesting)
Are you really well acquainted with gcj? I'm sorry, but I don't get how the end result or even the stuff going into it (and the required inputs, like making some explicit calls that would never be required in Java) can be called Java anymore.
the point I didn't make well was that when a language has been designed to execute inside a containing environment (the JRE or whatever facsimile thereof) yo
Re: (Score:3, Informative)
Those techniques are definitely good if they work for what you are doing, and believe me I have wanted them to work for me, but the reality is that D enables things that those approaches don't have while retaining the ability to work and not worry about the language getting in your way.
Re: (Score:2)
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:Because the ones we have suck? (Score:5, Funny)
E's taken! (Score:2)
D is surprisingly good. (Score:3, Informative)
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. (Score:5, Informative)
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. (Score:4, Informative)
Re: (Score:3, Informative)
Really? Not according to their FAQ. C yes. C++ no. Otherwise I would be in the process of switching over as we speak.
Re: (Score:2)
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 [slashdot.org]
Re: (Score:3, Insightful)
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?
Weird writeup: (Score:4, Insightful)
* 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: (Score:3, Informative)
* 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 pointe
Re: (Score:2)
>
> 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: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
java native code compilation (Score:3, Informative)
Re:java native code compilation (Score:5, Informative)
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! (Score:2)
Slashdot doesn't read full archives (Score:2)
You must be new here.
Re: (Score:2)
Currently learning D (Score:5, Informative)
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:
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: (Score:2)
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 (Score:4, Funny)
Re: (Score:3, Funny)
After working so hard to get from C to C++, I don't see why I would settle for D
I'd gladly have my girlfriend to go from C to D, but I admit there's nothing I would love more than DD.
Edit : yeah I know, quit telling me that I must be a liar, I don't have a girlfriend, WHO CARES?!?
Edit #2 : What? You can't edit your comments on Slashdot? So how am I doing that, jerk?
Do we really need another D infomercial? (Score:4, Insightful)
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:
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: (Score:3, Insightful)
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 mains
Re: (Score:3, Interesting)
Not really. Take a look at the performance, addressing modes, and so on. The support for 80-bit on Intel boxes is not the same as the support for 64-bit, at least in practical terms.
Also, while the vast majority of the world's FP hardware may indeed run on x86 (I don't know), I would suggest that a
Re: (Score:3, Interesting)
Ironically, I consider most of the C++ to D examples there to be flaws in D.
Supplying predefined comparison operators is all very well, but what if a class doesn't support the concept of equality? Alternatively, suppose it supports only equality and not ordering, or vice versa? How do I do that in a natural way, with a single comparison function to define?
The whole concept of relying on scoped variables completely misses a major advantage of RAII, which is that in the common usage, you can't forget anyt
Re:Do we really need another D infomercial? (Score:4, Interesting)
What do you think a programming language should do when I try to compare two things that can't be compared for equality?
Lazy Questions (Score:3, Informative)
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: (Score:2)
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
Re: (Score:3)
2. Must be able to allocate classes on the stack
This is a really, really strange requirement. Why would you need to be able to do this in a language? In a high-level language, memory allocation is abstracted away from you so you don't need to worry about it. A decent JVM, for example, creates pools for frequently allocated and de-allocated objects so that they have a much lower cost than heap-allocation of C++ objects.
Objective-C, for another example, follows the Smalltalk model of putting as little in the language and as much in the libraries as
Stack allocation (Score:3, Informative)
GC, No Vm or performance hit (Score:2, Insightful)
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 (Score:4, Informative)
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
In theory yes, but in practice not very much; conservative gc works very well in most cases. The main drawbacks are:
Re:GC, No Vm or performance hit (Score:5, Informative)
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?
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.
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. :-)
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: (Score:2)
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
Re: (Score:3, Funny)
Let me help you with this :
Dad?
Meh, karma to burn...
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
1) VM start-up time.
2) Over-architecting objects. OO languages tend to encourage you to make everything into an poorly-designed object. If you are doing numerical work and you end up creating millions of objects, your doing something wrong.
3) Crappy GUI libraries. Makes the UI miserable for many people (it is getting better, but slowly). If this is your interaction with Java, I understand your dislike for it.
If you apply the language
What about DTraces' D Language (Score:2)
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?
The feature-checklist school of software design... (Score:5, Insightful)
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.)
Keeping It Simple (Score:3, Insightful)
So where is the word simplicity in all of this? Anybody that has learned to use C++ really well has, to my mind, earned the equivalent of a Master's degree. This makes C++ a brilliant failure. So to learn D will we require the equivalent of a PhD?
Good designers make things both simpler and more powerful. They improve the product as much through s
Re: (Score:3, Interesting)
Perhaps accidentally, you've just hit on one feature of programming language designs that I think does justify a new compiler front-end: ease of parsing for use with tools. Parsing the current monsters like C++ and Perl is so awkward and error-prone that few tools even get simple things like syntax highlighting 100% right (and the performance of those that do is... less than stellar). I imagine most of us are more interested in the underlying semantics of programming languages than in the specific syntax an
Python and D (Score:4, Interesting)
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):
Re: (Score:2)
Is anyone ... (Score:2, Funny)
IDE D's Language Features (Score:2, Funny)
It's the libraries, stupid (Score:2)
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.
EVERY Language Sucks (Score:3, Funny)
Can't someone write up some stuff that understands proper english? Geez.
Re: (Score:3, Funny)
object oriented (Score:3, Insightful)
Why do they always insist on this bad syntax? Why can't they write
CmdLin cl = CmdLin.new(argc, argv);
This way you can think of CmdLin as an object, new is just a method that returns a new instance. Voila, one keyword removed, and much cleaner syntax. This would not even offend the Java people because they can have the same syntax with a static method.
Comparison to Objective-C? (Score:5, Interesting)
I noticed that a comparison to Objective-C is quite conspicuously absent from the list of languages compared to D. Why is it missing? Granted D seems to be a much greater change to C than Objective-C is but I can't help but thinking that one of the main attractions to D seems to be its heap-based garbage-collected object system. You can already get the object runtime with Objective-C. If you use GNU you can even have Boehm GC (which is apparently the GC that D uses). If you use Apple you will have to wait for Leopard to get GC. Another new Objective-C feature is the ability to use full C++ objects as instance variables in your Objective-C classes and do the right thing with initializing (calling the default no-argument constructor upon alloc).
On top of that, Objective-C actually includes tons of reflection information. Although Objective-C has protocols which are roughly equivalent to Java/C# interfaces they are almost completely unnecessary. In Objective-C one can query at runtime whether a method is implemented or not and if so call it. So whereas in Java you'd do this:
in Objective-C you can do this:
The difference being that in the Java case you have to declare MyInterface as containing the one doSomething() method and inform java that your object extends MyInterface whereas in Objective-C you merely need to provide a doSomething method on your object.
Basically that means that in Objective-C every single method effectively becomes an interface. You would not believe how useful this is once you realize it. Note that at runtime there is ZERO difference. In both the Java and Objective-C cases the object is being checked to see if it implements something. Same with C++ if you use dynamic_cast<>()
Granted every language has its niche and I'm sure D will find its. Objective-C's niche is definitely GUI programming. The ample reflection information allows for easy implementations of archiving (serialization) and most importantly key-value coding and the related action methods pattern. It's a pretty damn cool thing when your RAD tool simply outputs archived objects that refer to methods to be called upon certain actions simply by name.
Missing the point (Score:5, Insightful)
0XA1_2_C35_4_5_6_5P6_Li
Give up? Why, it's an imaginary real. Yes, you read that right. Oh, and I specified it in hexadecimal, just to prove I can. And I threw in some underscores because you're allowed to do that too. Have you guessed what an imaginary real is yet? This is supposed to be the "simpler C/C++ replacement."
A good language strives to find a few constructs that solve multiple problems. A bad language takes the kitchen sink approach. C and C++ are not good languages, but wide deployment and support make them useful anyways. D does not have that, but the designers do have the luxury of learning from the mistakes of the past. So what the hell is their excuse?
Re: (Score:3, Insightful)
D does this. You are looking past the dozens of examples where D has cleaned up problems that have been plaguing programmers for years to grasp at a chance to make a piece of code as messy as possible. Maybe you are comfortable working with C/C++ and don't want to deal with another language. I am not comfortable dealing with all the fucked up C and C++ out there. I have worked with D and it is exciting and refreshing. It is mu
OOP languages are slow (Score:3, Interesting)
CPUs put a lot of stock in branch prediction; due to the nature of OOP languages like C++, Objective-C (I like this one), and D, this doesn't work. The way virtuals and class inheritence works, functions are necessarily dealt with as pointers; the function is pointed to by pointing to a master class object, basically. Here's a C reconstruction:
struct myClass_members { // constructor // destructor // member function
// Data // Pointer to a list of members as above // an integer value
struct myClass_members *(*alloc)();
void (*destroy)(struct myClass *);
int (*my_member)();
};
struct myClass {
struct myClass_members *call;
int my_value;
};
What you do is initialize a constant myClass_members (called myClass_Object here) with a bunch of pointers to static functions in one source file; then call myClass_Object->alloc to create a new one (we'll call it my_inst). Then do my_inst->call->my_member() to call the member, and similarly my_inst->call->destroy(my_inst) to deallocate the class.
Basically, OOP languages like C++ and Java use this methodology, but it's obscured through friendly syntax. What we can expose from the above is:
The whole "native execution speed" thing is bunk. Script languages are executed on a native bytecode interpreter, or JIT'd to native. The amount of work that goes into the execution is what you care about; as well as the utilization of the CPU's most powerful facilities. You can only justify OOP languages by saying that either A) the majority of the work doesn't involve making calls to other class members, and thus won't be hurt by this; or B) CPU speed doesn't matter. I hate argument (B); (A) I can accept, barely enough to tip my hat to you for having good software engineering sense.
GDC source is not 64-bit clean (Score:3, Informative)
I've been messing around for a couple hours now trying to compile gdc against gcc-4.0.3 in Gentoo amd64 and it's just not happening. I ran into an issue where it had a int and size_t mismatch, an undefined cpu symbols macro, and after hacking these the build died complaining it thought that I was cross-compiling gcc.
I've given up for now. Maybe if D hits the 1.0 magic number somebody will fix it for 64-bit systems and add it to portage. Oh well, I would have liked to start playing with D but I guess I'll just have to wait.
Re: (Score:3, Interesting)
See http://dsource.org/projects/gentoo/wiki/LaymanSet u [dsource.org] p for a portage overlay that includes DMD-bin. You have to edit the layman configuration and disable warnings about missing fields, but it works fine after that.
I tried it, and it added the package, but it is masked by missing keyword. Besides, I don't want to install dmd, which is the 32bit compiler from digital mars, I'd rather have the gcc addon gdc built into my existing 64bit compiler system. I currently don't have the 32bit emulation libs insta
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Re: (Score:2)
> 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: (Score:2)
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: (Score:3, Informative)
The big win in
Re: (Score:2)
And for the record:
Re: (Score:3, Insightful)
It's right there in your post (Score:2)
"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.
Re:Another 'Toy' Programming Language (Score:5, Funny)
Re: (Score:2)
D can access routines in a C library, so any C GUI toolkit can be used from within D.
Re: (Score:2)
with one decent variant that is used and supported by everyone. Common things like threads, sockets, threads, connecting to databases, calling foreign functions...
Real threads are in SBCL, Allegro, and (I think) ECL. Multiprocessing ala mcclim tends to work everywhere else. The Common Lisp Cookbook should have code for sockets, databases is generally CLSQL, and foreign functions is generally CFFI (the evolved
Re: (Score:2)
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.
While I agree with you in that D is not worth noting, I don't believe any language is per say deficient. It is the user of the language who is deficient or needs to make the evolutionary step. The languages are driven by logic and overhead, not yet mastered by the carbon unit who instructs it. The silicon unit has it dead right, logically. I don't see this argument going
Re: (Score:3, Insightful)
Programming languages are to intended to be used by humans.
Re:I have a problem with GC in a systems language. (Score:4, Interesting)
I wasn't happy about that either. Garbage collection in a language with destructors leads to wierd semantics, which is why Microsoft's "Managed C++" is a nightmare. I corresponded a bit with Walter Bright in the early days of D, but didn't press the issue.
What seems to work in practice is reference counting. GC gets most of the academic attention, but Perl and Python are both basically reference counted, and the result seems to be that programmers in those languages can ignore memory allocation. Java programmers have to pay a bit more attention, worrying about when GC will run and when finalizers will be called. Reference counting is deterministic; the same thing will happen every time, so timing is repeatable. That's not true of GC.
There are two basic problems with reference counts - overhead and cycles. Overhead can be dealt with by hoisting reference count updates out of loops at compile time, so that you're not frantically updating reference counts within an inner loop. Hoisting (along with common subexpression elimination), by the way, is also the answer to subscript checking overhead.
Cycles are a more serious problem. Conceptually, the answer is strong and weak pointers (in the Perl sense, not the Java sense), which allows the programmer to express things like trees. (Links towards the leaves should be strong pointers; back pointers towards the head should be weak pointers.)
In practice, cycles aren't a serious problem, because they're generated by design errors and tend to happen in normal program operation, so they show up early in testing as memory leaks. Dangling pointers, on the other hand, tend to show up in error cases, which is why they survive testing to become delivered bugs.
Ideally, you'd like to detect cycles at the moment they're created, at least for debug purposes. This is quite possible, although there's substantial overhead.
Attempts to retrofit reference counting to C++ via templates have been made, but they are never airtight. To get anything done, raw pointers have to leak out, which makes the reference counting scheme very brittle.