Earlier quoted context omitted.
I don't think many-cores compatibility is a little gain.
That's a compiler issue, not a language issue.
A language without purity / proper constness / powerful static checking will not be automatically parallelized.
The Case for D
41–48 of 48 posts
Re: The Case for D
#42Re: The Case for D
#43Okay, I'm totally going to bite on the "find something you don't like in 30 seconds" and it's the hello world example. void main() { writeln("about to do something important"); doSomethingImportant(); } is this really not going to run doSomethingImportant() if the writeln fails? I find that to be a poor default for a systems language. This may just be a personal preference, but I strongly want a systems language to d…
Uncaught exceptions are caught by the D runtime code, and the appropriate message is printed.
You can declare functions as "nothrow", in which case the compiler will complain about any uncaught exceptions in the function body.
Re: The Case for D
#44Earlier quoted context omitted.
It's not akin to C++/C++0x at all. C++03 is standardized and the current mainstream compilers do a good job of implementing that standard; the tools are rock-solid. C++0x is coming along nicely, with support from the big industry players. Concepts were dropped, but the rest of the features are still a massive improvement over C++03 and I can't wait to use them. On the other hand, reading that blog post about D has co…
There is an awful lot of problems with C++ though. - The tool are certaintly not rock solid. Parsing requires arbitrary look-ahead and semantic pass, order of headers inclusion matters, #if and dirty tricks are everywhere - compilation is slow - non standard extensions makes painful portable C++ across compilers and platform, because you need them and they can have incompatible syntax - C++ const is useless when it c…
> - compilation is slow
What I've learned is that people don't really care about full builds when doing large projects. The separation into header and source files means that when you change a source file, only this one has to be recompiled. You only do massive rebuilds when modifying headers.
In case of D, when you modify a module, the change can possibly propagate indefinitely. Even when you just change the body of a function and think the modification should be isolated, consider that the build tool must assume this function may potentially be used at compile-time to generate code for other modules. The changes propagate as far as they would with .h files (unless the build tool can do semantic analysis or make unsafe assumptions).
To this fact, add how DMD only outputs template instances into one object file when compiling multiple modules at the same time. If you're lucky, at the next incremental build it will output them into the same modules. If you're not, you end up with unresolved references. This template emission method is an optimization - the alternative is a lot of bloat that object files generated by C++ compilers suffer from. I agree with Walter's position that what DMD does should be the default. And it is possible to make a good build tool that deals with this issue. I've tried doing that for DMD-Win, but its case, such a build tool is currently infeasible due to toolchain issues.
Re: The Case for D
#45Earlier quoted context omitted.
There is an awful lot of problems with C++ though. - The tool are certaintly not rock solid. Parsing requires arbitrary look-ahead and semantic pass, order of headers inclusion matters, #if and dirty tricks are everywhere - compilation is slow - non standard extensions makes painful portable C++ across compilers and platform, because you need them and they can have incompatible syntax - C++ const is useless when it c…
> - compilation is slow What I've learned is that people don't really care about full builds when doing large projects. The separation into header and source files means that when you change a source file, only this one has to be recompiled. You only do massive rebuilds when modifying headers. In case of D, when you modify a module, the change can possibly propagate indefinitely. Even when you just change the body of…
You can do "header" files with D, too. They're called .di files and the compiler will even generate them automatically, or they can be built by hand.
The compile speed advantage D has over C/C++ is that in the latter the header files must be reparsed for every source file. In D, the header files only need to be reparsed once, and then it is looked at symbolically for the rest of the source modules.
D is also faster at compiling because the lexical grammar is designed to require little processing.
Re: The Case for D
#46`[...] the classic "hello, world" for other languages such as Java (code omitted due to space limitations [...]'
Re: The Case for D
#47Earlier quoted context omitted.
> you can read the online docs, but you don't really get it until you read a certain book. Isn't that expected and normal for anything that involves thinking about things a different way? D has language features that most programmers aren't familiar with, so to use the effectively involves a shift of thinking. Same with Grails.
It's not that books are bad, it's that there is only one book. If it's not in The Book, you essentially can't find it anywhere, unless your mailing list spelunking skills are particularly good.
I never read The Book, instead learning the language entirely by the spec. It's honestly not that hard.
Re: The Case for D
#48Earlier quoted context omitted.
> - compilation is slow What I've learned is that people don't really care about full builds when doing large projects. The separation into header and source files means that when you change a source file, only this one has to be recompiled. You only do massive rebuilds when modifying headers. In case of D, when you modify a module, the change can possibly propagate indefinitely. Even when you just change the body of…
You can do "header" files with D, too. They're called .di files and the compiler will even generate them automatically, or they can be built by hand. The compile speed advantage D has over C/C++ is that in the latter the header files must be reparsed for every source file. In D, the header files only need to be reparsed once, and then it is looked at symbolically for the rest of the source modules. D is also faster a…
That latter advantage is true, but D's "header" files are currently impractical. Creating them by hand is a major source of pain, greater than with C/C++. The automatic generation on the other hand is troublesome for at least two reasons:
1) It's very sensitive to the contents of .d files. For instance, It leaves the bodies of inline-able functions in, thus if you modify such a function in the .d file, it will again mean a change spill to the .di and modules importing it (directly and indirectly). Similarly if you just reorder the functions in a module or change a private constant. This could partially be mitigated by a sufficiently smart build tool that tracks symbol importing, aliasing and usage in order to infer the modules that need to be recompiled. Sadly, this is quite complex and no current tool does it at the moment.
2) It assumes none of the functions will be used at compile-time (by stripping away function bodies depending on whether they may be inlined), which forces you to stuff them all into compile-time-only modules.