Slashdot Mirror
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.
...it's just another version race. D may have won for now, but someone out there is already working on the E programming language. ;-)
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.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
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.
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 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.
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.
LOAD "SIG",8,1
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?
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
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/. There are some interesting projects such as Derelict (collection of C game bindings) and Bud (make and SCons replacement).
This slashdot-related signature is a stub. You can help kihjin by expanding it.
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.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
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 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...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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?
You have tried to support your argument with faulty reasoning! Go directly to jail; do not pass Go, do not collect $200!
LOAD "SIG",8,1
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.)
If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared. S. Augustine
Garbage collection has no requirement for using a virtual machine. They usually show up together, but there's no technical requirement.
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, 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):
In .NET it's called a Common Runtime Library, running MSLI code. (That sentence is analogous to "the Java Virtual Machine runs Bytecode"
.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).
The big win in
Horns are really just a broken halo.
... actually going to use this? I think I'll wait for D++
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.
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.
My Karma: ran over your Dogma
StrawberryFrog
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...
I am TheRaven on Soylent News
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) you can't just up and erase that... without emulating all the stuff that was supposed to be alive in that environment. Taking a look at the gcj's to-do list and all the stuff that isn't yet supported should be enough to show you not only that this is not a trivial task, but to suggest that perhaps it's not a useful task, and I say that knowing that people have worked very hard on the project.
Maybe it makes sense for some resource-constrained settings like embedded systems, but there i've used Java straight up, satisfactorily. Granted, these are not life-critical systems I've built, but rather than compiling Java - or trying to - the better answer is to use a more appropriate language in those circumstances.
Bloody hell.Good designers make things both simpler and more powerful. They improve the product as much through subtraction as addition. Instead we get this...
BCPL was one of the sources of inspiration for the programming language 'B', and its successor 'C'. Next in the series ought to be 'P'.
I mean, like, I try to write this program, and like, the language does ONLY what I tell it to, not what I really want. That really sucks.
Can't someone write up some stuff that understands proper english? Geez.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
It might be possible to write OS in those loanguages. MS is trying to do it in C#. The project name is Singularity. But I agree that OS in not the target domain :)
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.
Open Source Alternatives
Hey hey, calm down. Are you sitting now? Ok, read:
Programming languages are to intended to be used by humans.
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
Wait...C++ without the bullshit? That takes away all of C++!
Haec merda tauri est. Ceterum censeo Carthaginem esse delendam.
Shoehorning his adjectives doesn't change the facts: .NET is damn fast. Perhaps not "I need to raytrace downtown Manhattan." fast, but certainly fast for web services, desktop applications, mobile apps, and Windows PowerShell. Heck, it even beat out a C++ app where low-level usually succeeds--lifting big data structures--until Raymond Chen wrote his own allocator.
0 158.aspx
http://blogs.msdn.com/ricom/archive/2005/05/19/42
Pelé!
Here is something that I found about this. Not very good news for conservative garbage collection, I say...
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
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.
malloc (and friends) don't run in bounded time, either.
For a lot of uses, particularly in user space, this is not a problem, but if you were to kick of GC in an interrupt handler or trap handler, or a number of other places, this would make it impossible for you to implement code that was guaranteed to take at most a maximum number of CPU cycles.
You cannot use malloc or new in those circumstances either. The correct way to do it is to preallocate all data needed for the interrupt service routine or real time critical section.
The upshot of this is that so long as it's possible for someone to write a driver that ends up running in your kernel, and which depends on GC functionality to not leak memory, it will be impossible for an OS written in that language to support hard real time.
Hard real time programming uses preallocated or static allocated data, not malloc or new (or GC).
I have to say that GC is marginally useful for systems work only if you can run it on a system that doesn't need GC -- so that you can get a read out of where and how you are leaking memory, fix the problem, and then disable GC before you ship. In other words, it's a great diagnostic, but only if you can run both GC and non-GC at the same time, and only if you explicitly scope your allocations (i.e. act like you are not running in a GC'e lanuage in the first place).
I used to think that, too, until I was forced into working with a GC. I've changed my mind.
In other words, the intent of GC is to make programmers not have to know where their scope boundaries are, and you _must_ know this for systems programming tasks. So it doesn't deliver on its promise in a systems context, though it could be a helpful diagnostic for developers.
All I can suggest is try using a GC for a project. My jawboning won't change your mind, but experience might.
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?
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.
Support my political activism on Patreon.
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.
Sodding lot of good that does if the vendor of the VM is only going to build for Windows.
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
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 anyway, so can't we use a grammar that is easy to parse effectively, and then have tools from syntax highlighters to source code navigation to refactoring working quickly and reliably for a change?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
In theory yes, but in practice not very much; conservative gc works very well in most cases. The main drawbacks are:
While Hans Boehm has written an excellent GC, it has no relationship with D's GC. The complete source to D's GC (which is written 100% in D) comes with D, and you can check it out for yourself.
While D strings are mostly implemented as character arrays, it works quite differently than C. Here are some notable differences:
- 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 called) to a dchar (which is a 32 bit character) for you. ubyte and byte are used for plain-old-data, instead of the unfortunate C char.
- Garbage collection frees you from worrying about where the strings go. No accidental memory leaks here.
There is also a nice alternative to the plain old strings called dstring, which gives you even more benefits of d's arrays like indexing and slicing (you can safely leave foreach alone with it). http://www.dprogramming.com/dstring.php
I've used both D strings and C strings, and D's strings just felt so much better.
D is garbage collected, has no vm, enables access to assembly language, access to direct memory management, and has trivial access to C libraries.
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.
This Wiki Feeds You TV and Anime - vidwiki.org
Actually MySpace runs on .NET - Handling 1.5 Billion Page Views Per Day Using ASP.NET 2.0
Apparently the move to ASP.NET went quite well with CPU usage dropping from 85% to 27% according to that post.
would be popular in Japan, I'm sure.
Especially among teenagers and otaku. (And geeks who think that otaku is equivalent to geek.)
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.
Clickety Click
Deciding how to allocate an object you create would better be left to the compiler. It's not a hard analysis to do to make sure the reference to an object never escapes a particular (possibly recursive) function call, and in that case the object can be allocated on the stack. Leaving this decision to the compiler makes sure that if someone changes the code you're calling so it suddenly starts to keep references to the objects that you've allocated on the stack and are passing in, it won't break. In big C/C++ programs, this kind of error is quite common since it takes a lot of time to track down all callers to a function you're modifying and understand their allocation patterns. Tracking down errors like this can be extremely time consuming and programming languages that allow these errors are in my opinion wasting valuable programmer time that could be spent optimising code instead.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
Let me help you with this :
Dad?
Meh, karma to burn...