Slashdot Mirror
Walter Bright Ports D To the Mac
jonniee writes "D is a programming language created by Walter Bright of C++ fame. D's focus is on combining the power and high performance of C/C++ with the programmer productivity of modern languages like Ruby and Python. And now he's ported it to the Macintosh. Quoting: '[Building a runtime library] exposed a lot of conditional compilation issues that had no case for OS X. I found that Linux has a bunch of API functions that are missing in OS X, like getline and getdelim, so some of the library functionality had to revert to more generic code for OS X. I had to be careful, because although many system macros had the same functionality and spelling, they had different expansions. Getting these wrong would cause some mysterious behavior, indeed.'"
http://www.digitalmars.com/d/1.0/memory.html#stackclass - Objects in D are not always allocated on the heap. Also, you've clearly never used templating in D if you think it is the C++ template system bolted on top ;)
The GC is the way to go for complex application. The reason is simple: the GC has a global overview over all memory usage of the application (minus special stuff like OpenGL textures). This means that the GC can reuse previously allocated memory blocks, defragment memory transparently, automatically detect and elimitate leaks etc.
Somewhat less obvious is that a GC allows for by-reference assigments being the default. In C++, by-value is default. a = b will always copy the contents of b to a. While this is OK for primitive stuff, it is certainly not OK for complex types such as classes. In 99.999% of all cases, you actually want a reference to an object, and not copy that object. But, as said, the default behavior of assignment is "copy value".
This is a big problem in practice. The existence of shared_ptr, reference counting pointers etc. are a consequence. We could redefine the default behavior as "pass a reference of b to a", but who will then take care of the lifetime of b? Using a GC, this last question is handled trivially; when the GC detects 0 references, b is discarded.
Now, once you have by-reference as default, things like closures get much easier to introduce. Neither D nor C++ have them at the moment, but C++0x requires considerably more efforts to introduce them. Functional languages all have a GC for a reason.
D did another thing right: it did not remove destructors, like Java did. Instead, when there are zero references to an object, the GC calls the destructor *immediately*, but deallocates the memory previously occupied by that object whenever it wishes (or it reuses that memory). This way RAII is possible in D, which is very useful for things like scoped thread locks.
They also simplified the syntax, which is one of the major problems of C++. Creating D parsers is not hard. Try creating a C++ parser.
Now, what they got wrong:
- operator overloading
- const correctness
- lvalue return values (which would solve most of the operator overload problems)
- no multiple inheritance (which does make sense when using generic programming and metaprogramming; just see policy-based design and the CRTP C++ technique for examples)
- crappy standard library called Phobos (getting better though)
- and ANOTHER de-facto standard library called Tango, which looks a lot like a Java API and makes little use of D's more interesting features like metaprogramming, functional and generic programming
This sig does not contain any SCO code.
Not all Linux software runs on the macOS either.
Yeh, there's a lot of Linux programmers who wouldn't know how to write portable code if the portable code fairy shat clue down their throats. Last decade it was SunOS programmers, the decade before that it was people who thought all the world was a VAX. The world is full of people like that.
For techies, there is no substitute for Linux or FreeBSD. (I prefer Linux, but I have friends who prefer FreeBSD.)
Ask your friends about porting Linux code from people who think portable means "it compiles on Red Hat and Suse... ship it!"
Oh, while we're on the subject, you do know that Jordan Hubbard works at Apple now, don't you?
OS X displaced the classic Mac OS in majority desktop usage sometime around 2002, so about 7 years out of a 25-year history.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Sadly macports and fink are pretty poor :( They don't have enough people and most of the packages are broken or out of date. I have simple patches for projects which I run which have been sitting in the macports tracker for more than six months and still have not been approved.
Debian/Ubuntu/etc. still have by far the best package repository and that's enough to make my mac almost useless and my linux laptop the place where I do most of my work. Plus OS X is rather slow, argh.
From what I've heard D can use libraries written in C.
but Mac hardware is crap
Have you ever used mac Hardware? Their laptops have been amazing for ever. Apple has long been a major innovator on the laptop front. And many of the things you expect in a laptop were made a standard feature first on the Mac. Things like target mode, gig ethernet, auto-crossover, built-in wifi, built-in bluetooth, Ac adapter standardization, integrated mic, integrated camera, external battery indicator, backlit keys (or any way to view the keys in the dark), DVD burners, and there are probably more that I just can't think of. Macs have great hardware.
Yes, they may not have every possible feature, but they have lots of good ones and really versatile. Computer snobs who turn up their noses at macs remind me of car snobs, except that a lot of the cars those people like aren't that useful, and break down a lot. I don't get that mentality and I probably never will.
Last time I looked at IRIX, it looked like System V to me.
Once you get used to real, traditional BSD, going into the OS X terminal is weird. Where's /etc/init.d and /hw? Why can't I boot -f dksc(1,5,8)sash64? No /usr/people?
Then you're in luck! http://code.google.com/p/qtd/ The bindings are fairly new, but they appear to be at a usable stage now.
D does not use a text preprocessor. Often what is a standard C interface relies on macros in the standard C header files, which is perfectly standard C conforming. The D interface to the standard library has to look at those macro expansions, and write them as equivalent D declarations. Since the macro expansion text is not specified by the C standard, these all have to be gone through for each port of the D standard library. And yes, they do differ in sometimes dramatic ways. The interface to the D standard library needs to be portable, but that doesn't mean the implementation of that library needs to be portable. Some speedups in the D I/O library are possible, for example, by taking advantage of some linux specific api functions.
The C header files for stdio on FreeBSD won't work on Linux, either, because implementations are free to innovate on that. Significant parts of implementation specific characteristics are exposed in the standard C header files, and these need to be modified for every platform.
Actually you are dead wrong here, I have seen so many developer starting to use Macs and most of them bother to use the command line seriously.
I think one of the biggest user group the mac nowadays has are developers, thanks to the NextStep underneath!
D supports mixins which does allow you to aggregate behavior without needing multiple inheritance.
I can't think of something with significant market share, but there is now an indie game on Steam written in D: Mayhem Intergalactic
Additionally, D is link-compatible with C. Using C libraries from D is as easy as porting the header files to D. There are a couple of tools for (mostly) automating this process, and quite a lot of the major C libraries have D bindings available.
Who the hell is Jordan Hubbard?
One of the founders of the FreeBSD project.
BTW, OS X uses a Mach kernel, not *BSD. OS X has much more in common with NEXTStep than FreeBSD.
Mac OS X uses a kernel that combines Mach code and *BSD code. It also has some userland "core OS" libraries (e.g., libSystem) that combine *BSD code with code developed at NeXT and/or Apple.
So, no, it's not as much like 386BSD as 386BSD's more direct *BSD descendants, but it's still closer to *BSD than to other flavors of UN*X.
D can directly call C functions. It is not necessary to go through thunks or some interface layer or build a DLL for the C calls. D 2.0 can also directly call global C++ functions and C++ member functions for classes that have single inheritance.