Back in 1980 or so, I bought a Heathkit H11 which was a repackaged PDP-11. It had dual 8" floppy drives. I wanted it to implement my Empire game on it, which I did, and distributed a few copies of the binary. When I later got an IBM PC with 5.25" drives, I backed up the Empire source files from the H11 by writing them out to a serial port, and using a program I wrote for the PC that read from the serial port and wrote to a floppy. So far, so good. Eventually, I put all the PDP-11 version of the source code up on my website http://www.classicempire.com./ This year, a person who had a PDP-11 emulator tried to recompile Empire from those sources, and discovered one of the files was missing! Arggh. I had long ago copied all my 5.25 floppies to CD-ROMs, but the file wasn't there, either. I had obviously overlooked backing that one up when transferring the files to the PC. I had thrown out all my paper listings, and just had some handwritten code on notepaper (I use to write code that way, later typing it in). I gave away my H11 in the 80's, but the person I gave it to had thrown it in the trash (too bad, they are valuable collector's items now). But I did have the old 8" floppies. If only I could read them, and if only they were even readable after 27 years. I emailed my old friend from college, Shal Farley, who now runs Cheshire Engineering. He said he had an old 11 in the back room, it had an 8" drive and an ftp server on it, but he hadn't fired it up in years. I sent him the floppies, and wouldn't ya know, it worked perfectly and he imaged the floppies (about 8 of them). Every single byte read without error! I was amazed. He was kind enough to email me the contents, and I added it to the web site. I'm grateful to Shal for rescuing my data! When I backed up my 5.25" floppies to CD about 12 years ago, about 90% copied without errors. The ones before 1985 were nearly all thoroughly unreadable, though, which is why I figured the older 8" ones would be quite useless.

When I started out, nobody was interested in interviewing or hiring me, either. After starting my own business writing software, however, this ceased to be a problem.

Is C# on the Mac?

Doing that would mean that, for example, all the #defines for constants in the C header file would have to be accessed via a C function. While this would make it much easier to port the D runtime library, it would have a significant deleterious effect on performance, as such could not be constant folded or optimized. This is unacceptable for a high performance systems language.

D does not attempt to use FreeBSD header files on Linux. It does not use C header files at all. The point is, for each system, the C header files have to be translated to D import files. The C header files are different on each system, and so the D import files have to be different to match. If the D import files are correctly ported, the D user won't see any difference any more than the C user would. Any D program can use either read/write or stdio, as D has direct access to any C functions. The D I/O functions try to layer on top of stdio functions so that the programmer can mix and match using D and stdio as he pleases, including interfacing with C routines that use C stdio.

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.

D does have multiple inheritance for interfaces. Given that, template mixins, and the strong aggregation support, it's pretty hard to see what's left that might benefit from MI. But if you really, really must have MI, then C++ is for you.

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'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.

D supports mixins which does allow you to aggregate behavior without needing multiple inheritance.

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.

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.

So you want to be a programmer? lists several courses and their value for a programming career. Foreign language comes at or near the bottom.