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.'"
As little as possible. From the article:
I then figured out how to remotely connect to the Mac over the LAN, and (the Mac people will hate me for this) put the Mac in the basement and operate it remotely with a text window.
A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.
I can run basically every Linux/Unix application on my Mac, both command-line and GUI, while not having to worry about wireless networking drivers, printer support, power management / sleep support on my laptop, getting accelerated 3D drivers working, or any of the other minor hassles that are involved with setting up and maintaining a Linux install.
If you walk into the computer science department at MIT, basically all the faculty have a Mac, and fully half the students do. These people are not buying Macs because they saw a cool ad on the bus - they're buying them because a Mac is the best tool available.
The argument that Macs are just expensive, "designer" PCs that look pretty and sell well because Apple has marketed them well doesn't hold water. Yes, they have nice hardware, and a clean, polished, slick UI, and that does make them more pleasant to work with than some blob of Dell plastic running Vista - but they have the functionality to back up their appearance, as well.
Yeah, they're more expensive. If you value your time at all, you should realize that spending an extra $100 on a Mac is well worth it if it improves your productivity. Hell, if you ever spend two hours fighting with some weird issue on your Linux box, it's no longer saved you any money. You know how long I've spent fighting with the OS to get my wireless working, or hibernate working, or whatever, in Mac OS X, in the five years I've been using a Mac? Zero. I'm not exaggerating. It lives up to the hype. It "just works". It gets out of my way and lets me get things done.
This space intentionally left blank.
So basically, Mac IS Linux on the desktop?
I think I've just given Linux fans nightmares for months.
Random Thoughts From A Diseased Mind (Not For Dummies)
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.
Why would Mac people hate somebody for that? I ssh into my macs all the time. I pretty much always have terminal windows open. A lot of the molecular biology software I use (the open EMBOSS set of programs ROCK) are command line only, take files as input & write files as output. It's a BSD box with pretty paint. Sure, it's nice to have the pretty screens & be able to run things like iphoto & etc, but at the end of the day the most useful stuff still runs from the > prompt.
1984 was supposed to be a warning, not an instruction manual.
Nope. We have B, we have C and the one language to rule them all has source files ending in .PL
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
I think the fact that this post has been up for almost an hour and has only 33 follow-ons shows what the software community thinks of D.
One has to acknowledge that Back in The Day, Walter Bright did all of us a great service in producing the first PC-based C++ compiler (Zortech) which effectively forced Borland and Microsoft to take the language seriously.
Unfortunately, for all of us, he seems to be better at invention than collaboration but that doesn't devalue the contribution he made (structurally) to get us to where we are.
cheers...ank
Still hoping for Gentle Treatment...
The griping and misinformation here is so atrocious that I'm simply embarrassed to be reading Slashdot today.
Digital Mars D is a wonderfully designed language and I'm in the process of giving up a lifetime of C++ for it.
I'm not here to defend D or enumerate it's growing pains or evangelize it, but if you don't take it upon yourselves to be well informed, please don't repeat your biased gibberish to the rest of us.
Linux is also UNIX on the desktop. It's just an oddball version of UNIX, with a whole bunch of extra APIs that people using Linux get used to and come to depend on, so they think writing portable code means "it runs on Red Hat and Suse" (or Debian and Ubuntu, if you're on the Left Hand path), and then when they go to port to a more standard version of UNIX, they write stuff like this:
If you're writing code that depends on the expansion of system macros, or if you're depending on obscure Linux-only functions, you're writing unportable code. What really bothers me is the idea that someone writing a Linux-only program would already have run into situations where they had to conditionally compile code. Has Linux really fragmented that much?
...or there's always Greek, Hebrew, Klingon* and, hey, Chinese (that should keep us going for a while)!
Why do you think they invented Unicode?
(*Fatal Error at line 16349: statement has no honour)
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
People who have been Mac people for a long time generally don't have that workflow, as the importing of the BSD backend is a fairly recent addition to the Mac world, whereas many of the GUI conventions have been around much longer.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Prolog?
Seriously, name me a piece of commercial or open-source software with significant market share written in D. Library support is about 10000% more important than actual language design.
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?
I was at Berkeley when 4.2BSD was being pulled together, and did some work for the 4.1C release. I was one of the guys who got 386BSD to compile clean in the first place. I had a NeXTstation on my desk for several years. I was the FreeBSD handbook guy for a while. I worked with Tru64 back when it was the only fully 64-bit UNIX. I know what "BSD" and "Mach" are, better than you and better than most of the people who contributed to that Wikipedia page.
you should be aware that this is Slashdot
Yeh, I'm keeping that in mind. Thats why I'm not going to even TRY and explain just how badly you're misreading that Wikipedia page.
Maybe your [sic] right, I can't say.
I can. The gp is wrong on just about every count.
As you already say, if you are very concerned about performance in a situation with lots of small objects you can use structs. Simply ignoring structs because you are too lazy to use them does not make D slow. With a bit of experience and a few rules of thumb it's not hard to choose.
I think maybe you're talking about what is called "scope" now. It allocates the memory for the class on the stack. Yeh, it doesn't cover every possible use case of by-value classes, but it can be a nice optimization.
Yes you use structs when you want an efficient aggregate value type. Classes and structs have different semantics in D. It's pretty easy to choose once you get the hang of it. If you are likely to want to put virtual functions on the thing, make it a class. If you want to pass lots of them around by value, make it a struct. If you can count on your fingers how many instances you will have, make it a class -- the hit from allocation won't matter. There is some gray area in-between, granted, but in practice it's usually pretty clear, and the benefit is that you do completely eliminate the slicing problem by going this route. If you really can't decide you can also write the guts as a mixin and them mix them into both a class and a struct wrapper. Or just write it primarily as a struct, and aggregate that struct inside a class. The use cases that are left after all that are pretty insignificant.
Yeh, well don't try to avoid it, then. It's not as much of a headache as you make it out to be.
D's template system has gone far beyond C++'s. It's even far beyond what C++0x is going to be. Alias template parameters, template mixins, static if, a host of compile-time introspection facilities, the ability to run regular functions at compile-time, type tuples, variadic template parameters. Of these, I believe C++0x is only getting the last one. D metaprogramming is to C++ metaprogramming as C++ OOP is to OOP in C. It takes a technique that the previous language begrudgingly permitted and turns it into one that is actually supported by the language.
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.
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.
Programming in D is nice, but the situation is a bit annoying.
1. Tango vs Phobos. Phobos is the official standard library, but it seems most use Tango. Phobos is also pretty low level compared to Tango.
2. The reference compiler dmd is 32bit only, gdc is outdated and abandoned, and ldc is still alpha status and has missing features. Ldc is quite promising though.
3. D2 is maybe the biggest issue. It has very useful features, such as partial C++ compatibility, but D2 is a moving target and practically no library supports it. It's also unknown when or if ever D2 will become stable. I haven't seen much discussion about it in the newsgroup either.
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.