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 ;)
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.
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.
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 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. 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.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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?
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.
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...
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
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
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