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.'"
Real developers actually use the Mac?
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 ;)
Because the compiler ignores whitespace it's probably not the best design decision to let a non-visible character be the end-of-line terminator.
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.
getline() and getdelim() are GNU extensions. Apple doesn't particularly like GNU. The FSF doesn't particularly like Apple (for good reasons). So, duh.
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
From what I've heard D can use libraries written in C.
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?
Right... because apart from Linux, all Unices are exactly the same
That's why writing portable code requires experience.
Linux is a fragmented mess of incompatibility
Good thing I still have this in my paste buffer:
If I thought Linux was "a fragmented mess of incompatibility" I wouldn't have been surprised that it required conditional compilation. As someone else noted, the conditional compilation was because it had been ported to Windows as well, not because it had to include distro-specific code.
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.
OS X 10.5 is Unix 03 certified as it ran the entire test suite. It is as much Unix as HP-UX or Solaris.
"Not to mention all the idiots who use words like boxen."
Anonymous Coward on Monday August 04, @06:49PM
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'm very curious what you think is wrong with D's const correctness and operator overloading. Reference (lvalue) returns were recently added to D 2.0.
Although bringing Digital Mars C++ to the Mac and Linux would offer several advantages (such as very fast compilation times) there probably wouldn't be enough customers to justify the expense.
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.
there's an english link but for the lazy. http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html
It is interesting that this thread has stirred up a considerable amount of comparison of Mac to Linux. As a long time Linux user and a MAC Book Pro user of a year I have to comment.
1.
There is by far less fiddling with MACs than with Linux. That comparing a Mac portable to generic desktop hardware. I'm not sure how a reasonable person can say otherwise.
2.
Mac OS is not trouble free. Those of us with the Mac Books with WiFi problems can atest to that. Driver problems are not unique to Linux or any other platform for that matter.
3.
Interestingly while I consider the Mac to be about the best platform for commercial apps I'm not at all thrilled about the stability and over all quality of Aqua apps. Apparently Apple isn't either as they have said that they want to address this in Snow Leopard.
4.
I'm not sure that Snow Leopard can address all the issues in Aqua as the very nature of that dynamic, loosely typed environment seems to be part of the problem. After a year I'm pretty much convinced that non trivial apps on the Mac seem to go bad. Maybe that is a reflection on me but Apple does have serious problems with some of it's software.
5.
It is trivial to download and keep up to date with respect to many of the Open Source utilities. However should we really have to? This is where the vast majority of Linux distros win hands down, you don't have to wait for security and other updates to the various components in the suite. Package management is one area that Apple needs to put a lot of effort into to assure that security fixes are timely and effectively address bugs and performance issues. Waiting for months for a bulk 10.5.fx release is not OK. As a side note I've found that the third party resources like Fink to be totally useless, it is less trouble to build your self and that is saying something.
6.
You can easily run Linux in a virtual machine on a Mac. This works very well in my mind. Since I use a free VM environment it isn't perfect but it is good enough and actually provides for a better development environment.
Now onto "D".
D on Mac could be very successful if portable graphics library could be developed. Frankly I'm not impressed with Aqua and it's lack of portability is a big negative. I'm actually waiting hopefully for Snow Leopard to see if they can effectively address Aquas performance and stability issues. If that doesn't happen D with an open widget set might be more useful, acceptable and maybe even desirable on a Mac.
I have not used D the language but do like some of what I hear. Objective C seems to be to little in the way of a modern language. Now I don't consider myself to be even a remotely good C++ programmer but the language and it's standard libraries has a lot more to offer than Objective C. If D can offer up the same general feature set in an environment that is easy to master for the novice then it has big potential. As has been mentioned bindings and libraries are everything, to be successful on a Mac D would need both high level, D like access and low level access to UNIX. I need to read up on D more but it really does seem like an ideal language for those apps where Python can't do the job.
Note the last line above, I see much more of the world going to Python like environments where absolute speed isn't the issue. What that means for D is that it has to produce fast code. Further the programmer needs to be productive in D far more than Objective C.
So D needs to be fast but it also has to overcome the fact that it is late to the party. It will need to be compelling to displace C/C++ with respect to lowlevel programming and need fluid libraries to address the higher level competition. Considering the sad state of ADA, Java, C# and other languages I think D will have a tough time against the Cs.
Dave
Linux on its own couldn't pass UNIX '03, because UNIX '03 is for the whole OS distribution, not the kernel.
GNU/Linux might pass with the GNU toolchain, the Bourne shell and a vi attached. Linux on its own can't pass, because it's not meant to.
Those using pirated Tinysoft signatures(TM) are a real threat to society and should all be thrown in jail.
> First of all, Java does have destructors. It's called finalize().
I'm sure you know their differences. Java's finalize does NOT make RAII possible, because it's not run deterministically.
RAII requires controlling the order of execution of destructors.
Not being able to perform RAII with it makes finalize() almost totally useless.
MPW had an interface called Commando. You could highlight a MPW text command and bring up Commando on it. It would present a dialog box formated for just that commmand; you could check boxes, radio buttons, pulldown menus, etc. and as you did, it would compose the resultant text command in a window. You could run the command from the dialog or you could copy and paste the command into (what amounted to) a terminal window and run it there. That meant you could save commonly used commands in the text of that (terminal) window and select them again and rerun them.
It was an excellent way to handle text commands and much better than is the unix vomit of a cli.
Gerry