Walter Bright Ports D To the Mac 404
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.'"
What? (Score:0, Informative)
Real developers actually use the Mac?
Re:High performance of C++ equal to D??? (Score:5, Informative)
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 ;)
Re:semi (Score:3, Informative)
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.
Re:High performance of C++ equal to D??? (Score:5, Informative)
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
Duh. (Score:1, Informative)
getline() and getdelim() are GNU extensions. Apple doesn't particularly like GNU. The FSF doesn't particularly like Apple (for good reasons). So, duh.
All the world's a VAX. (Score:5, Informative)
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?
Re:depends on the Mac people (Score:4, Informative)
OS X displaced the classic Mac OS in majority desktop usage sometime around 2002, so about 7 years out of a 25-year history.
Re:What? (Score:4, Informative)
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.
Re:What? (Score:3, Informative)
lets see a Mac do this:
ssh -X hostaddr application
And have the GUI application pop up on a remote screen without the WHOLE screen like VNC.
You can't seriously be suggesting that X11 is unavailable [apple.com] for OSX. If you have an X11 application that you would like to run, you can certainly do what you're suggesting. No serious UNIX weenie should have any trouble building it [apple.com]. Your only possible room for complaint here is 1) that that not every application is an X11 application (something for which most users are thankful) or 2) that you want your mommy to have compiled the app for you already.
Re:No one cares about D (Score:5, Informative)
Re:What? (Score:5, Informative)
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.
Re:Mac is UNIX on the desktop (Score:5, Informative)
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?
Of course, this is slashdot. (Score:3, Informative)
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.
Re:What? (Score:3, Informative)
He actually said that academics in a computer science department use it. Don't you think that they count as developers? His anecdote isn't that uncommon, on the academic research projects that I've worked on Macs are used much more heavily than other systems. My current project may be a bit extreme but more than 90% of the participants use a mac. They are all developers - across a wide range from people who are optimising low-level assembly routines, people developing in C, through to some higher level domain specific languages.
My own work patterns haven't changed that much since I moved from a linux box. iTerm has a full-screen mode, and I've always written code in vi. There's a decent version of gcc, and the other languages that I need like python, perl, prolog and others are all available and quite stable.
I find it quite amusing that most people in this discussion are either mac-heads bashing linux users, or linux-users bashing mac heads. It is a refreshing change to find that windows doesn't even make the minimum grade for people to bother attacking it. I just like the combination of stable hardware support (especially given that I use a laptop and power-saving and hibernation are vital) with a unix interface. Maybe I missed the compulsory religious indoctrination session, so I probably don't count as a "proper" mac fan...
Re:Qt bindings (Score:4, Informative)
Re:Mac is UNIX on the desktop (Score:3, Informative)
Re:Mac is UNIX on the desktop (Score:3, Informative)
Re:Mac is UNIX on the desktop (Score:4, Informative)
Re:Mac is UNIX on the desktop (Score:5, Informative)
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!
Re:High performance of C++ equal to D??? (Score:3, Informative)
Re:High performance of C++ equal to D??? (Score:2, Informative)
Re:digital mars c++ (Score:2, Informative)
Re:No one cares about D (Score:3, Informative)
I can't think of something with significant market share, but there is now an indie game on Steam written in D: Mayhem Intergalactic [steampowered.com]
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.
Re:UNIX is UNIX is UNIX (Score:5, Informative)
Who the hell is Jordan Hubbard?
One of the founders of the FreeBSD project [freebsd.org].
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.
Re:No one cares about D (Score:5, Informative)
Re:wasnt it already there? (Score:2, Informative)
A couple of things on Macs. Then D. (Score:1, Informative)
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
Re:Mac is UNIX on the desktop (Score:3, Informative)
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.
Re:High performance of C++ equal to D??? (Score:3, Informative)
> 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.
Re:depends on the Mac people (Score:3, Informative)
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