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

Comments

Re:What?

[Anonymous Coward]

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.

Re:What?

[avalys]

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.

High performance of C++ equal to D???

[master_p]

I don't think D will ever have the high performance of C++, because D objects are all allocated on the heap. The D 'auto' keyword is just a compiler hint (last time I checked) to help in escape analysis. D has structs, but one has to design upfront if a class has value or reference semantics, and that creates a major design headache. Avoiding the headache by making everything have reference semantics negates the advantages of struct.

D is a mix of C and Java, with the C++ template system bolted on top. It is no way C++. D is not what a veteran C++ programmer excepts as the next generation C++.

Re:High performance of C++ equal to D???

[Anonymous Coward]

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:High performance of C++ equal to D???

[ardor]

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

Re:High performance of C++ equal to D???

[ardor]

I'm sure you're thinking of Java or C.

Wrong. I am thinking of C++. Count the times you pass a reference or a pointer vs. the times you actually want to copy large, complex objects. The outcome is pretty clear. Hell, boost even contains a "noncopyable" class as a tool to disallow deep copies.

Deep copies are the exception. Shallow copies are the rule. This is totally obvious, and virtually all other languages do it this way. The only two reasons why C++ doesn't have it that way are the C legacy and the ownership problem (which is solved by the GC).

Yet another problem with by-value as default are move semantics. It basically boils down to the problem of extra copies in return values. C++0x sort of fixes it with the aforementioned move semantics. See http://www.codeguru.com/cpp/misc/misc/versioninfo/article.php/c14443 for more. Note that this issue is an artifact of the by-value-default design decision in C++.

So in 99.999% of cases, you don't want a to pass by reference or to copy the object - instead, you want to pass a copy of the pointer to some instance.

Wrong conclusion. Your example just shows that the assignment operator is ill-defined. Besides, this is possible in D, since you can overload the assignment operator.

And, how to do actual copies of the object? Since doing *deep* copies is rarely done on purpose, a clone() method is the way to go.

No multiple inheritance is pretty good from a readability & codability viewpoint, as long as there is some mechanism that allows you to more clearly express your concept (i.e. Java interfaces). Multiple inheritance creates confusion potentially - which parent am I inheriting function foo from if both of them declare it? What is the destructor order if parents have virtual destructors?

I take it you never did C++ metaprogramming then? Never implemented policies, CRTP and the like?

Not sure what your problems with operator overloading are. Presumably you think that the return value should be part of the method's signature. Not sure if this is a good or bad idea - maybe it creates issues for compiler writers & ambiguity in the error messages?

See this example:

    x[5] = 1;

How is this done in C++? x' index operator returns an lvalue (e.g. a non-const reference), whose type in turn defines the assigment operator. This is the right way, since retrieval and assignment are two orthogonal concepts. What if x is some sort of container class? If there were a "[]=" operator, the container class would have to define retrieval *and* assignment. But the latter is not the container's job.

D has an opIndexAssign operator, which is "[]=". Fortunately, there is progress; an opIndexLvalue operator has been accepted into D2. However, opIndex would be sufficient if it were possible to define the return value itself as an lvalue.

Re:High performance of C++ equal to D???

[baxissimo]

Maybe your [sic] right, I can't say.

I can. The gp is wrong on just about every count.

• I don't think D will ever have the high performance of C++, because D objects are all allocated on the heap.

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.

• The D 'auto' keyword is just a compiler hint (last time I checked) to help in escape analysis.

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.

• D has structs, but one has to design upfront if a class has value or reference semantics, and that creates a major design headache.

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.

• Avoiding the headache by making everything have reference semantics negates the advantages of struct.

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 is a mix of C and Java, with the C++ template system bolted on top. It is no way C++. D is not what a veteran C++ programmer excepts as the next generation C++.

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.

Re:High performance of C++ equal to D???

[Pinky's Brain]

Shallow copies are the rule, so we use smart pointers ...

The problem that for right or wrong a lot of people using C++ don't want a GC, creating a language you think will better suit their needs but which they won't use is not terribly useful.

Re:High performance of C++ equal to D???

[baxissimo]

D has an opIndexAssign operator, which is "[]=". Fortunately, there is progress; an opIndexLvalue operator has been accepted into D2. However, opIndex would be sufficient if it were possible to define the return value itself as an lvalue.

It is also possible to return by reference in D2.

But the redeeming value of the "[]=" operator is that it gives you a simple way to have array-like index assignment without breaking encapsulation. If you return a reference to element 5 then you have no way to control what the caller does with that reference after that. The caller can go on to change the value of it willy nilly as he pleases. This is very annoying if you want to perform some action as a reaction to the value of an element changing. It's exactly the same argument as for why it's generally better to getters and setters to provide member variable access, rather than just making the member public.

Re:High performance of C++ equal to D???

[oever]

In Java you'd need an assign(Object o) function to get the same functionality. Then you could write

void bar(String x)
{
            x.assign("cba");
}

There is, however, no assign(Object o). A workaround for the String case would be to use a StringBuilder:

StringBuilder foo = new StringBuilder("abc");
bar(foo);
System.out.println(foo);

void bar(StringBuilder x)
{
            x.setLength(0);
            x.append("cba");
}

Re:High performance of C++ equal to D???

[julesh]

http://www.digitalmars.com/d/1.0/memory.html#stackclass - Objects in D are not always allocated on the heap.

No, but making it an attribute of the class where they are allocated makes no sense at all. A general-purpose class cannot be defined to use stack allocation, and because D doesn't support multiple inheritance I can't mix the trait in without reimplementing it for each class I want to use that way.

Re:High performance of C++ equal to D???

[physicsnick]

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

First of all, Java does have destructors. It's called finalize().

Second of all, calling destructors on a modern GC are extremely costly. Sure, your example implementation of destructors seems simple, but it is only possible in a reference counted garbage collector, which is so primitive as to be nearly useless.

Modern Java GCs are generational copying collectors. They have a young heap, where objects are allocated, and an old heap, where objects are moved when they survive an allocation. Object retention is done by tree search from a root node.

This means you can do fun things like allocate a linked list, then drop the reference node. When a collection happens, anything living is rescued from the young heap, and then it's simply wiped clean. No computation is performed regardless of how large it is or how many links it has, because there's no such thing as deallocation on the young heap. When you drop that first link, it's like the VM doesn't even know it's there anymore; the whole list just gets overwritten on the next pass over the heap.

If, however, you write a destructor for your links (or in Java, finalize()), the destructor then needs to independantly keep track of all of your destructable objects. It needs to remember that they're there so it can call their destructor when they do not survive an allocation. Furthurmore, if you impose your hard requirement of calling the destructor immediately, then the implementation of such a collector is impossible for your language. Even a primitive mark sweep collector, or anything not reference counted is impossible.

This example is discussed in detail here:

http://www.ibm.com/developerworks/java/library/j-jtp01274.html

You should familiarize yourself with modern garbage collectors. I don't know much about D, but if D really is tied down to a reference-counting collector due to its destructor requirements, that makes it extremely unnatractive as a language. Here is more information on various collector implementations:

http://www.ibm.com/developerworks/java/library/j-jtp10283/

Re:High performance of C++ equal to D???

[WalterBright]

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

Re:High performance of C++ equal to D???

[WalterBright]

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.

Re:High performance of C++ equal to D???

[sentientbrendan]

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.

Yes... all you say is true, but it's what you are not saying that is what disqualifies a GC'd language for being a successor for C or C++.

C and C++ are used for:
1. Kernels.
2. Video codecs.
3. Video games.
4. Embedded programming.

I program in C++... and Python, and Java, and Javascript, etc, and I'm well aware of the benefits of GC. I also undertand how GC is implemented and the kinds of amortized performance benefits you can get. I'm also aware of it's drawbacks. The reason you can't use a GC'd language for any of these platforms is twofold.

1. GC must periodically halt all threads to compact the heap. Imagine if your kernel did this. The *whole computer would halt*. If anything displayign realtime graphics did this, such as a video game, you would get stutter.
2. GC is lazy about deallocation, so it chews up more heap space. Usually at least twice as much as the equivalent non-gc program. This isn't that big of a deal in most cases. but it means you can't use it for embedded devices where you might only a killobyte or two of ram. Yes, there are many of these devices, you probably use several.

Look, GC is great from a usability perspective. I would always prefer to use GC. HOWEVER, there are cases where GC will *just not work*, and I wish GC zealots would get that through their heads. The GC hammer is nice, but *sometimes* a more complicated and powerful tool is necessary for a more difficult job.

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.

Yes, destructors in C++ are very nice.

I'm actually kind of confused about this. Are you saying that D keeps a reference count *in addition* to doing GC, or are you saying that the destructor is called when the object moves out of scope like in C++?

- 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)

I could not agree with you more. I do not understand multiple-inheritance phobia. If you have a good grasp of how objects and classes work, then multiple inheritance is not only safe, but incredibly useful as a way of adding mixins to a class. This is doubly true in conjunction with meta-programming and templates.

Fear of multiple inheritance tends to stem from the diamond problem... but really if your class hierarchy is is 3 layers deep, that is your *real* problem, not multiple inheritance. You want to restrict the *depth* of the tree, not the *breadth*.

Re:High performance of C++ equal to D???

[master_p]

But the syntax is all wrong. It's easy to forget that an object is allocated as 'scope', because the syntax is the same as in heap allocation.

And the template system is D is exactly the same as in C++. The differences are superficial, only in syntax. D's templates is a Turing complete system, just like in C++.

Re:High performance of C++ equal to D???

[master_p]

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.

But with tripling memory usage, at least. Which does not help performance at all.

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

It depends on the object. I wouldn't say 99.999%. More like 50%-70%. Forcing all classes to be accessible by reference is silly, in my opinion.

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.

The non deterministic nature of finalization creates big problems though. At least with shared ptrs, objects are not held up alive until the gc says it's time to delete them. Which may be never.

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.

I disagree. The design of C++0x is retarded. They should have introduced closures by creating value objects which represents the closure.

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.

In order to now how many references are to an object, there are only two solutions: a) reference counting, b) object tree traversal. The first one has the problem of cycles, and so it is not used, and the second one is very costly and it is also not used. So, your comment is totally wrong. D has RAII, but it does not use reference counting or object scanning and marking.

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.

Indeed, but not relevant to this thread of the discussion (regarding performance).

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

And for these reasons and others, C++ is still preferable, in my book, than D.

Re:High performance of C++ equal to D???

[Lutger]

By default, destructors for objects are called when the GC collects them. This is not so useful, but with the use of 'scope' on allocation, lifetime can be restrained to the current scope. Additionally in the current version of D structs also have constructors and destructors.

Fear of multiple inheritance tends to stem from the diamond problem... but really if your class hierarchy is is 3 layers deep, that is your *real* problem, not multiple inheritance. You want to restrict the *depth* of the tree, not the *breadth*.

True, then again the sensible uses of MI boil down to mixin and interfaces, both of which are supported directly in D.

Re:High performance of C++ equal to D???

[master_p]

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.

But structs do not have the same treatment as classes.

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.

And a heck of lot difficult to spot. At least, in C++, it's obvious what is a pointer and what it is not.

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.

Why do all that? no thanks. C++ is much better in this regard.

D's template system has gone far beyond C++'s.

Nope. It hasn't.

It's even far beyond what C++0x is going to be.

Nope, it isn't.

Alias template parameters

C++ has typedef.

template mixins

Mixins are bad from a design standpoint.

static if

C++ can do it with templates.

a host of compile-time introspection facilities, the ability to run regular functions at compile-time

And introduce big complications in the code.

type tuples

Boost provides them.

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.

Nope. The C++ and D template type system are exactly the same. In fact, if you ask Walter, all the template tricks in D are done using the C++'s Turing complete template system.

Re:High performance of C++ equal to D???

[Lutger]

But structs do not have the same treatment as classes.

No, they are value types. This is not a problem, it is a feature ;)

Alias template parameters

C++ has typedef.

And D has alias (C++'s typedef) and strong typedefs, but this is something completely different than alias template parameters.

Re:High performance of C++ equal to D???

[loufoque]

D's template system has gone far beyond C++'s. It's even far beyond what C++0x is going to be

C++0x is mostly syntactic sugar. Nothing is really new.
The most important new feature being rvalue references, to which D has no equivalent AFAIK.

Alias template parameters

You mean taking symbols as template parameters? You can do that in C++.

template mixins

You do them in C++ with templated inheritance.

a host of compile-time introspection facilities

C++0x concepts, which are really syntactic sugar for things that were already available in C++03, allow compile-time reflection, albeit in a limited way (you can check if something exist, but you cannot list everything that does exist).

type tuples

Unlike D, C++ does not add that kind of facility in the language, since it is doable as a library.

static if,

the ability to run regular functions at compile-time

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.

That is overstating it. In C++, meta-programming is done using a functional programming style manipulating types, which are fully immutable, as values. In D, it's done just like regular programming, fuzzing the line between the two, except you have to make sure you add the keywords "static", "template" and the "!" operator in the right places.
I personally prefer the C++ way.
All in all, the D way of doing things at compile-time really looks like you have to write it as you were doing it at runtime and rely on the optimizer to work it out at compile-time. Look at variable arguments for example, they look more like C varargs than C++0x variadic templates.

On an unrelated note, any good C++ programmer I know finds that D has little to do with C++. It is closer to C, and closer to Java as well. Which are ironically the two worst ways to code in C++.

Re:High performance of C++ equal to D???

[loufoque]

A garbage collector is no silver bullet. It will protect you against hard leaks, but not logical leaks within your program.

You'd better design your resource management in terms of ownership from the start.

Somewhat less obvious is that a GC allows for by-reference assigments being the default.

You certainly do not need a GC to do that, assuming your functions are called synchronously.
The reason pass-by-value is the default is mostly historic. Pass-by-const-reference is the recommended idiom.

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?

b is guaranteed to outlive the reference we give to a, since a is called before b is destructed.
Note this is not the case for asynchronous function calls, however.

Neither D nor C++ have them at the moment

They're doable as a DSEL.
See FC++, Boost.Lambda, Boost.Phoenix, Boost.Phoenix v2...

but C++0x requires considerably more efforts to introduce them

Not considerably more effort, no.
You just have to specify if you take your context by value, or take it by reference (and in that latter case, you have to ensure the referenced context outlives the closure).

Re:High performance of C++ equal to D???

[FoboldFKY]

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.

But structs do not have the same treatment as classes.

Your point is... what, exactly? They're for completely different purposes; of course they're treated differently. Otherwise, we'd only have classes or structs, not both.

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.

And a heck of lot difficult to spot. At least, in C++, it's obvious what is a pointer and what it is not.

This is a valid concern, but I can't see what this has to do with the particular quoted part of the gp's post. He's pointing out that scope is useful, and you're complaining about not being able to tell if an arbitrary identifier has value or reference semantics. Huh?

That said, just because something doesn't have a star out the front in C++ doesn't mean it's a value type; I've seen some truly terrifying abuses of operator overloading. At least in D, it's trivial to find out: stick in a pragma(msg, whatIs!(x)) and bob's your uncle (note: whatIs is not in the standard library, but I've written similar templates before without much trouble.)

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.

Why do all that? no thanks. C++ is much better in this regard.

Yeah, why bother designing your program before you write it? After all, maybe you want to make your 16-byte vectors into classes, or turn GUI widgets into value structs!

Honestly, I'm amazed every time I see this argument. Let's try it from the other direction: Java seems to do pretty well without "plain old data" structs; clearly, you don't need structs to write a program. If you really don't want to have to engage your brain, just pretend structs don't exist.

D's template system has gone far beyond C++'s.

Nope. It hasn't.

It's even far beyond what C++0x is going to be.

Nope, it isn't.

Alias template parameters

C++ has typedef.

Yeah, so this combined with the 'auto' comment before lead me to believe you don't actually know what you're talking about.

Tell me, how do you typedef a function in C++? Or a string value?

template mixins

Mixins are bad from a design standpoint.

I personally think you're wrong, but that's an opinion and not a valid argument. :)

Re:High performance of C++ equal to D???

[FoboldFKY]

But the syntax is all wrong. It's easy to forget that an object is allocated as 'scope', because the syntax is the same as in heap allocation.

And the template system is D is exactly the same as in C++. The differences are superficial, only in syntax. D's templates is a Turing complete system, just like in C++.

I guess that means the differences between C++ and assembler are superficial, only in syntax. After all, anything you can compute in C++ you can compute in assembler.

Ease of use is definitely overrated.

Re:High performance of C++ equal to D???

[Midnight Thunder]

Yes... all you say is true, but it's what you are not saying that is what disqualifies a GC'd language for being a successor for C or C++.

C and C++ are used for:
1. Kernels.
2. Video codecs.
3. Video games.
4. Embedded programming.

I will go with and say definitely, and this goes to show that there isn't one solution for everything. For me C++ is the assembly language of today, where we need something that compiles tightly and has the highest performance possible. The examples you illustrated also tend to have predictable data paths, and hence it is much simpler to decide when an object should be freed. These examples are also the 20% of code that gets executed 80% of the time, so optimisation is crucial. As we get further from the core we are reaching the point where there is more varied user interaction, so it is not always clear what the life-cyle of object really is, and therefore who is really responsible for its deletion, and when.

At the same time, even with a high level application there are ways of making the GC's life simpler. For example allocating stuff on the stack and setting references to null where you know they aren't being used. In order for a GC to perform well it really needs to be presented with less fuzzy scenarios.

Re:High performance of C++ equal to D???

[baxissimo]

But the syntax is all wrong. It's easy to forget that an object is allocated as 'scope', because the syntax is the same as in heap allocation.

Wow. Such a non-issue. That's even a feature, I'd say. In D you can change from heap allocation to stack allocation by inserting one word, and everything else you've written will pretty much be good to go as-is.

And the template system is D is exactly the same as in C++. The differences are superficial, only in syntax. D's templates is a Turing complete system, just like in C++.

Oh come on. When was the last time you programmed using a Turing machine? Turing completeness is only a very very VERY basic prerequisite for a programming language. For that matter, you could also say the additions of C++ over C are basically superficial syntax changes too. And those of C over ASM. Syntax does matter. Pretending it doesn't is ... superficial.

Re:High performance of C++ equal to D???

[Midnight Thunder]

A garbage collector is no silver bullet. It will protect you against hard leaks, but not logical leaks within your program.

You'd better design your resource management in terms of ownership from the start.

I real life equivalent to this would be a tidy house and a house which is a mess. You employ a cleaner to throw out the rubbish, and (s)he will spend much less effort in the tidy house, than the messy one, after all who is decide what is rubbish and what isn't?

Re:High performance of C++ equal to D???

[FoboldFKY]

http://www.digitalmars.com/d/1.0/memory.html#stackclass - Objects in D are not always allocated on the heap.

No, but making it an attribute of the class where they are allocated makes no sense at all. A general-purpose class cannot be defined to use stack allocation, and because D doesn't support multiple inheritance I can't mix the trait in without reimplementing it for each class I want to use that way.

In fact, you can force a class to be scope allocated by putting "scope" at the front of the class declaration. This doesn't remove the requirement for 'scope' at the allocating statement; merely makes it mandatory.

Note that you cannot use this to give a class value semantics; if you could, you would open the door to the slicing problem. By making it a property of the allocating context, you avoid that.

Re:High performance of C++ equal to D???

[baxissimo]

You seem pretty happy with C++, so that's great. Just keep at it. I spent 14 years working primarily in C++, and was also skeptical about D, too. But about 2 years ago I just got fed up with C++ and thought I'd try something else. I gave D a shot and I haven't regretted it. We could argue about minutiae till the cows come home, but the fact is that programming in D has made my last 2 years of programming work much more enjoyable than the 2 years that preceded it. I think anyone who tries it with an open mind will probably find the same. They may come to the conclusion that it's not for them, but it won't be because of any of the things you're bringing up here. More likely it will be because they find themselves too deeply entrenched in the C++ ecosystem for anything to get them out. D's not backwards-compatible with C++. That's the biggest weakness of D, but it's also the thing that allows it to move forward.

Re:High performance of C++ equal to D???

[Estanislao Mart�nez]

Funny you would glorify one of the most retarded things about java. The sane thing to do is to have the assignment operator do the same thing whatever the type. Either always by value, or always by reference. DO NOT make me have to find out if the types of a and b are primitive or not each time I see a = b.

Java's primitive-vs-object distinction is indeed annoying, but it really doesn't matter in Java. It behaves exactly as it would behave if each primitive variable was a reference to an interned, immutable object. In fact, a better implementation of Java that eliminated the primitive/object distinction from the language semantics would be best served by stipulating that the objects of the primitive type are always immutable, and that any two objects of primitive type that are equal by content are always also equal by reference. Then the compiler could transparently remove the reference indirection.

Re:High performance of C++ equal to D???

[Wolfier]

> 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:High performance of C++ equal to D???

[overbored]

See C#'s `using`.

http://msdn.microsoft.com/en-us/library/yh598w02(VS.80).aspx

Re:High performance of C++ equal to D???

[complexmath]

Second of all, calling destructors on a modern GC are extremely costly. Sure, your example implementation of destructors seems simple, but it is only possible in a reference counted garbage collector, which is so primitive as to be nearly useless.

This may be true if you want deterministic finalization, but not if you want dtor support in general. The D garbage collector is a typical mark & sweep GC and incurs no overhead for finalizing objects before the memory is freed.

It's another issue entirely whether dtor support is desirable in a GCed language. First of all, there's the weird restriction of not being able to use any references to GCed memory, because that data may already have been collected by the GC. Then there's the issue that collection is not deterministic. Some have suggested that dtors should only be allowed for "scope" objects, so RAII is supported without the false sense of security that dtors might provide for GCed data, but I think a fair argument could be made either way. Personally, I find dtors to be useful in a GCed language, if only as an insurance policy.

By the way, I believe that C++/CLI (ie. C++ for .NET) will call the dtor of managed C++ objects when they are finalized. And I believe that C# has some kind of dtor feature as well. So D isn't the only language to do this.

Re:High performance of C++ equal to D???

[owlstead]

OK, but IF a class has a finalize method, I would very much like the VM to take heed to it. This would seriously make resource de-allocation easier. Why not make it so that instances that contain finalize methods are kept track of? Of course, this is more expensive, but currently none of my classes have finalize() methods because I should not use them. Maybe they should create a tagging interface that indicates to the VM that it should do reference counting *for that instance*.

Of course, the finalize method may still not be called if the VM crashes, but most resources are closed down in that case anyway. At many times people seem to have to make choices when they don't have to. In this case both reference counting and sweeping may have their place.

Re:High performance of C++ equal to D???

[sentientbrendan]

>Why do you think that GC must pause all threads?

Because it must compact the heap periodically, and the heap is a shared mutable resource.

I'm not really up to date on the best GC algorithms out there, but my understanding is that though modern ones have various ways of *minimizing* the number of full compactions necessary (such as generational GC) there's no way to get rid of it entirely.

Re:High performance of C++ equal to D???

[sentientbrendan]

True, then again the sensible uses of MI boil down to mixin and interfaces, both of which are supported directly in D.

Actually, if you have interface inheritance and mixins, I'm not sure you need need even single inheritance in the traditional sense.

Really though, if you want to get minimalistic, you don't even need interfaces if you use structual typing like templates do at compile time, and like python does at runtime.

So you could boil your type system down to just mixins and implicit/duck typing.

Re:High performance of C++ equal to D???

[Wolfier]

The GP was talking about Java. Language-wise, C# is much better designed.

Re:High performance of C++ equal to D???

[angel'o'sphere]

First of all, Java does have destructors. It's called finalize().
First of all: destructors and finalizers are two completely different things.
E.g. look for managed C++ under .NET. And you will realize managed C++ has BOTH.
The purpose of a destructor and of a finalizer are completely different.

angel'o'sphere

Re:High performance of C++ equal to D???

[angel'o'sphere]

1. GC must periodically halt all threads to compact the heap.
That is not correct. tehre are as well concurrent GC implementations as modern JVMs e.g. have.

2. GC is lazy about deallocation
That is also not correct, you can do any way of allocation/deallocation schema you like in your GC implementation.

So bottom line your conclusions like: HOWEVER, there are cases where GC will *just not work*, and I wish GC zealots would get that through their heads ... are not correct either.

E.G. World of Warcraft is a garbage collected game. I dont think you "see" that.

I do not understand multiple-inheritance phobia. If you have a good grasp of how objects and classes work, then multiple inheritance is not only safe, but incredibly useful as a way of adding mixins to a class.

The point is if you have mixins you dont need MI. And on the other hand: MI is not the same as a mixin. E.g. in C++ mix ins are done via combination of inheritance and templates. Without templates C++ had no mixins.

Regarding your question about reference counting. I think most people don't realize that reference counting is something completely different than having a GC ;D

angel'o'sphere

Re:What?

[Ihmhi]

So basically, Mac IS Linux on the desktop?

I think I've just given Linux fans nightmares for months.

digital mars c++

[drac667]

From what I've understood his D implementation and Digital Mars C++ share some code. Would he bring Dital Mars C++ to MAC also? Or to Linux for that matter?

Re:digital mars c++

[WalterBright]

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.

Re:digital mars c++

[drac667]

Continuing the same line of thought, D has implemented some of C++0x features, will be C++0x support added to Digital Mars C++?
I guess it depends on the customers asking for it. But without any tempting offers like cross platform support, C++0x support, 64bit support, there will be no demand from customers.

Re:What?

[dkf]

Real developers actually use the Mac?

Of course. The MacBook and MacBook Pro are nice laptops for on the move, and it runs ssh, gcc, vi, emacs and X11 perfectly.

Re:What?

[Cillian]

I'm not going to club you into oblivion for that post, but I'd like to quiz you on basically every linux/unix app running. I'm not disagreeing, I'm curious. Are we talking the level of support that wine gives on linux? Or are we talking eeeeverything?

Re:semi

[Anonymous Coward]

I think you need to study some more C, C++, Java or C# code and you'll notice not every end of line terminates a command..

Re:What?

[kanweg]

I'm a Mac head since I bought an LC. My company is run with Macs only. However, I have A Lot To Complain About (TM). Sound goes missing after switching accounts (can be switched back on by changing source). Initiating iChat communications fail half the time. E-mail accounts don't stick in Mail. The cursor makes sudden sweeps across the screen. When you want to fax and type a number, it starts to assume some person from the address book, but when it is not that person, you end up with a mess that is Very Hard To Edit (TM) in the fax number field. Oh, and lots more. Well, OK, no viruses, so in that respect I'm still a happy camper.

Bert

Re:semi

[Anonymous Coward]

Oh yeah the semicolon is a MAJOR obstacle for every programmer...

Re:semi

[theurge14]

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:What?

[evil_aar0n]

Yes. At work, they've given me a kick-ass Dell - serious high-end piece of machinery - and I almost never touch it. Instead, aside from e-mail, all my efforts are through my personal MacBook Pro. Even if I'm VNC'ing over to my Solaris session, I still use the Mac.

Re:semi

[Inf0phreak]

There are very good reasons why we have stuck with the ; as statement terminator instead of newline. Not the least of which being that systems simply don't agree on what bytes constitute a newline. Windows thinks it's \r\n, UNIX-ish systems that it's \n and (pre OS-X? Haven't ever owned one myself) Macs think that it should be \r. And then you have things like "logical newline" e.g. std::endl That is not to say that putting some more work into compiler error messages wouldn't be a good idea. I assume most C++ programmers have tried receiving a _huge_ amount of garbage template crap as an error message instead of "missing semicolon" when trying to output text with std::cout.

Re:What?

[iggymanz]

hahaha. Now I have two Macs in the house, wife and kids love them. but OSX doesn't run on 1/100 the hardware that Linux will, you mean it has better hardware and software support for Apple's somewhat overpriced hardware (unless you buy four+ years old used on eBay like me). And what do you mean spend $100 more, more like a thousand or two more for new. The pile of available open source apps is bigger for Linux (or certain BSD too) than OSX, though the mac porting projects are doing well as they catch up. As far as productivity, it's the same on either platform for anything I do. Your argument about spending time resolving hardware issues, I had to look up how to make my laptop's volume thumbwheel work in Linux, that took 2 minutes. Everything else on all my boxes just work. Oh, and I have an Asterisk VOIP box with zaptel cards under Debian, how well is that going to work in OSX?

Re:What?

[psergiu]

Sound: multiple sound cards - eh ?
iChat: your router or ISP sucks. It works ok for everybody else.
e-mail: Clean your caches. This also works ok for everybody else.
Mouse cursor: either don't let direct daylight shine on the mighty mouse or throw that junk away and get a real mouse with a opaque body
Fax: ... well ... add them all to the address book :)

Re:What?

[rhombic]

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.

D, E, F,... where will it all end?

[Tiger4]

Now he's done it. Kicked off the alpabetical arms race. He himself averted it once by the Operator Gambit of + and ++. The crisis was defused.

It was stumped again this decade by what came to be called the Jungle of Earthly Delights Diversions (Python, Ruby, et al). But now he's broken the dam to the last redoubt, the alphabet. There are only so many letters! It is a limited supply! We've feared this since the mid-nineties. Who will save us now?

Re:D, E, F,... where will it all end?

[Larryish]

There are only so many letters! It is a limited supply! We've feared this since the mid-nineties. Who will save us now?

We'll start using ABCv6.

Re:D, E, F,... where will it all end?

[InfiniteLoopCounter]

*imagined response from a new programming language writer*

Sure, they've already used A, B, C, D, E, F, and assorted appendages (A+, B++, C#, C--, C++). However, mark my words, G will leave a different legacy. G (for generic) will be the be all and end all language.

G will be able to compile for binary, trinary, and anything ending in -nary with the change of a single number.

It will have solved the problems of security in that no buffer overflows will be possible, no memory management will be done by hand, and the computer even correct code for transactions. Any program which is insecure will be fixed automatically based on the logical structure and purpose of the program.

Mathematical equations merely will need to be entered in and automatically solved.

G will be faster on parallel architectures and will even do your dirty laundry!

Now you see why G needs to be made. A, B, C, D, E, F, and assorted appendages just can't do it exactly right.

*A few years later a new guy steps onto the scene*

G is so outdated and full of holes. It doesn't do X, Y, and Z. It doesn't deal well with the new data storage equipment. It's security started off good, but after they found those few gaping flaws became a joke.

What we really need is a new language. Let's call it the H programming language.

Re:Shouldn't it be called P?

[psergiu]

Nope. We have B, we have C and the one language to rule them all has source files ending in .PL

Re:D sucks

[rhombic]

Visual Basic sucks. BASIC rules. Long live GOTO!

Re:What?

[Oswald]

In general, I've learned not to argue with Mac fans (if you value reasoned discourse, that might give you pause -- I've been clubbed into apathetic, eye-rolling silence), but I must point out that the (obviously trolling) grandparent to your post asked if actual developers used the Mac. Your reply that academics and students sure use hell out of it is pretty damn funny.

Re:What?

[Hognoxious]

A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.

Apart from if you want to run the most popular scripting language.

I really don't see the problem with this

[localroger]

Simply treat both cr and lf as endlines; a compiler isn't formatting output and ignores a blank line so treating \r\n as two endlines doesn't matter. Use a visible character like the _ in vb to indicate that the next nonblank line is a continuation. I have to agree with parent that ignoring whitespace is one of the dumbest ideas ever. How often do you really needa 140 character line, versus the frequency of lazy programmers writing unreadable code because the language doesn't require even minimal formatting?

Re:I really don't see the problem with this

[zippthorne]

If you can end a sentence with a period, you can end a statement with a semicolon.

Go back to Fortran pre-90, you luddite. Whitespace should be used to make your code readable. Which it manifestly does *not* when it's part of the syntax.

Re:I really don't see the problem with this

[spitzak]

A better solution than yours is to treat \n as a newline, and \r as ignorable whitespace (even Python does not care about whitespace on the end of a line).

The character '\' at the end of a line to indicate continuation is a pretty well-established standard, and a bit easier to see than '_' (which also is a legal character in an identifier, so you could not end a line with such an identifier?)

Re:What?

[itsdapead]

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.

I partly agree, but in defense of Linux, you seem to be comparing a shrink-wrapped Mac (hand built by dusky maidens from only the finest OS X-compatible components) with slapping a standard Ubuntu CD on your old Dell. If you bought a purpose-built Linux workstation you'd expect it to, likewise, have been made out of Linux-supported components and be properly configured out of the box.

You'd probably have similar driver nightmares with OS X if, rather than buy a nice shrink-wrapped system from Apple, you tried to turn an existing PC into a Hackintosh.

Re:What?

[SSCGWLB]

OK, whats with this unix love? Yes it is a unix workstation, but so is HPUX. HPUX is ...different. You will understand if you have ever used it. Being Unix compliant does not mean a OS is good, reliable, or stable OS. Don't get me wrong, I have used OSX and like it fine. I think it can stand on its own as a OS, as apposed to relying on 'but it's Unix!'. I would rather have the free (as in beer) linux with the freedom to do what I want on my hardware/software. I much prefer the gentoo EULA to the apple EULA.

This hardware statement is a out and out lie. OSX does NOT work on a wider range of hardware, nor does it have support for more hardware. OSX will work on the laptops Apple sells. Which does not surprise me. If I am paying a premium for a laptop I do expect the OS it _comes_ with to work.

Lets take for example me Dell m1730. I installed Redhat and gentoo on it, _everything_ works. No, everything didn't just work right away, but it wasn't difficult. Good luck trying to install OSX on it. Besides violating the EULA(http://www.apple.com/legal/sla/), it doesn't 'just work'. I googled it to make sure.

I can (and have) install linux on a 486, the crappy PIII in my closet, the dual quad xeon at work. And it works. Even my odd video card and its friend the ancient soundblaster. Good luck with OSX, I am sure you can get most things working, eventually.

I have a 4 year old dell laptop that came with windows XP. Wireless works great, it suspends and hibernates great. Everything worked great out of the box. Never had a ounce of problems with it, use it every day. This does not make it a good OS. So I installed linux on it. Which works great also.

One addition point, you can pay a lot more then 100$ for a comparable laptop.

I know you love your mac, but please don't share the kool-aid.

Re:semi

[WillKemp]

I agree. I can't get my head around the insanity of python's system of indentation delimiting block structure...

What's wrong with lines terminating with semi-colons anyway? It encourages much tidier and more readable code, i reckon.

Duh.

[Anonymous Coward]

getline() and getdelim() are GNU extensions. Apple doesn't particularly like GNU. The FSF doesn't particularly like Apple (for good reasons). So, duh.

D -- wha?

[ansak]

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

Re:D -- wha?

[xenocide2]

I choose to think it shows what the software community thinks of the Mac.

Re:D -- wha?

[Anonymous Coward]

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.

Or what they think of Macs.

Or what they think of hanging out on Slashdot on Sunday mornings.

Re:D -- wha?

[Makarakalax]

Be fair. When C++ was 2 years old, hardly anyone gave a shit about it.

why all the hate?

[Bobtree]

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.

Re:What?

[Zero__Kelvin]

"A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux."

ROTFLMAO! I just learned something new! I was unaware that OS X runs on ALPHA, ARM, and the other 19 processor platforms that Linux supports.

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

What you say is, of course, patently absurd. You are comparing a system already set up, with a bare bones system. None of MY customers worry about those things either, since they compare their already set up Linux system to an already set up Mac.

"Hell, if you ever spend two hours fighting with some weird issue on your Linux box, it's no longer saved you any money. "

Perhaps the most absurd statement you make, and that is saying a lot .

Re:What?

[Ihmhi]

Okay. I'll amend my previous statement.

So basically, Mac IS FreeBSD on the desktop?

I think I've just given FreeBSD fans nightmares for months.

Mac is UNIX on the desktop

[argent]

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:

'[Building a runtime library] exposed a lot of conditional compilation issues that had no case for OSX. I found that Linux has a bunch of API functions that are missing in OSX, like getline and getdelim, so some of the library functionality had to revert to more generic code for OSX. 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.'

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?

Re:Mac is UNIX on the desktop

[RedK]

The opengroup would disagree about Linux being Unix. Someone still has to have it certified and it still wouldn't pass the certification because there are still missing features. Linux is compatible to most of the Unix specification, it is not Unix.

Re:Mac is UNIX on the desktop

[ThePhilips]

True. Linux is not UNIX'03 certified.

Someone still has to have it certified and it still wouldn't pass the certification because there are still missing features.

List of missing features in studio, please.

I'm working on bunch of *nix systems, and frankly Linux always stroke me - software developer - as most compatible *nix clone. Essentially bunch of stuff (written after SUSv3) simply works on Linux while on e.g. Solaris some stuff is either buggy or simply missing or in different "UNIX traditional" header.

Shortly, looking into SUSv3 and programming on Linux works. But it doesn't on true-UNIX Solaris and *BSD.

I'm kind of also happy that Linux is not *nix. Having worked on FreeBSD for some short time, it's simply impossible to be as efficient with their antique true-UNIX text/file tools as one can be with GNU text/file tools. Needless to mention that on *BSD /bin/bash isn't default shell, line editing isn't always there, no usable pager and no decent text editor is installed by default. On fresh Linux install one can start working already. On fresh *BSD setup - you have to start compiling ports. Feel the difference.

If one tried to treat Mac OS X as *BSD, than it makes the *BSD misery even more apparent: minority of Mac OS X users ever bother to use the command line. Had it been something useful, I bet more people would have used it. On Linux, e.g. on Ubuntu you rarely (if ever with recent version) have to go to command line. Yet people use it - because it is usable and useful.

Re:Mac is UNIX on the desktop

[Anonymous Coward]

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?

It's not Linux-only: it's Linux and Win32. Hence the conditional compilation.

The author was hoping that his Linux-specific code would work on OSX, but it doesn't.

Re:Mac is UNIX on the desktop

[mwlewis]

D also runs on Windows, which is probably the source of the original conditional compilation.

Re:Mac is UNIX on the desktop

[argent]

The author was hoping that his Linux-specific code would work on OSX, but it doesn't.

Thanks for the clarification.

It sounds like he needs some more porting experience, so he knows how to avoid the Linux dependency tarpit.

Re:Mac is UNIX on the desktop

[Anonymous Coward]

Right... because apart from Linux, all Unices are exactly the same. They all have exactly the same API and ABI; POSIX never happened, as it was never necessary in the first place, and vendors never quarrelled and purposefully tried to extend THEIR version of Unix to do more than competitors' versions.

Really, you're right. Linux is a fragmented mess of incompatibility where you have to rewrite and adapt your program to each individual distro because none does things quite the same way as any other; but if you write a program that works on, say, Solaris, you can be absolutely sure it will also work out of the box on *BSD, AIX, HP-UX, Xenix, Sinix, and whatever else have you.

Yes, you're entirely right.

Re:Mac is UNIX on the desktop

[Anonymous Coward]

I'm an IRIX user, and I can tell you that we have all kinds of problems porting FOSS stuff. Little problems usually, but getting big things like Mono, Firefox 3, or OOo is a sisyphean task.

Also, as I type this on my Mac, no, OS X is _not_ UNIX. Neither is Linux, they are both UNIX-like. Linux much more so, it's gone from being a pretender to the throne to the future of UNIX. But OS X is Mach with BSD extensions, and is really a NextStep-like OS, which was in turn UNIX-like.

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? Whyyyy?

Of course, I am an anonymous coward who posts, like, once a month, so this'll stay modded 0 and no one will ever care...

Re:Mac is UNIX on the desktop

[argent]

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?

peter@enclave 103 % uname -a
FreeBSD enclave.in.taronga.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
peter@enclave 104 % ls /hw
ls: /hw: No such file or directory
peter@enclave 105 % ls /etc/init.d
ls: /etc/init.d: No such file or directory
peter@enclave 106 % ls /usr/people
ls: /usr/people: No such file or directory

Re:Mac is UNIX on the desktop

[RedK]

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.

Re:Mac is UNIX on the desktop

[WalterBright]

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.

Re:Mac is UNIX on the desktop

[WalterBright]

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.

Re:Mac is UNIX on the desktop

[MemoryDragon]

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:Mac is UNIX on the desktop

[John Betonschaar]

Compared to *NIX development on Solaris, even *NIX development on Windows is more pleasant, so I wouldn't take that as a benchmark 'how *NIX' Linux actually is from a developer viewpoint.

I've been doing *NIX development on a lot of different OS's and versions for the pas few years, including FreeBSD, OpenBSD, SunOS, Solaris, Linux (from RH 7/RHEL 4 to Ubuntu 8.10), OS X and HPUX. About any flavour of *NIX you will encounter as a software engineer nowadays.

My experiences where that BSD is indeed the best base-line platform for *NIX development. If it compiles on BSD, it will most likely also compile on Linux, OS X and Solaris (unless you have an older Sun Studio release or didn't install one of the gazillion optional packages for proper userland tools and libraries). This is not true the other way around: stuff that works great on any Linux system might not work at all on BSD or OS X. Initially it frustrated me, in an 'always those damn BSD boxes' kind of way, but eventually I started to appreciate it more and more. Turned out I wasn't that much of a *NIX expert after all, only having worked with Linux. The code I write now is much better and although I still use Linux as my primary development platform, my code generally works out of the box on all other *NIX systems.

On a side note: Solaris is simply terrible for software development. Every Solaris system is different, some do have this and that libraries, others don't. Some have GNU userland, some have crippled, incomplete userland tools with totally idiotic command-line interfaces. Some have compiler versions that kind of work, some can't even compile boost::shared_ptr. Some have GCC, some have Sun CC. Some have only STLPORT4 standard C++ libraries, some have only libCstd, some others have both but if you mix them your program might or might not link, but it definitely won't work. If you want to link in 3rd party binary stuff that's only available linked with libCstd you're basically screwed: forget about using Boost or any other development libraries that rely heavily on templates because libCstd is nonstandard, incomplete garbage that breaks perfectly valid C++ code.

It's a complete nightmare, a complete disaster, and if you'd ask me Sun should just kill Solaris alltogether and just release their own Linux distro (which they're more or less doing with OpenSolaris already, except it's not Linux)

Re:Mac is UNIX on the desktop

[Plaid Phantom]

It sounds like he's getting that experience right now.

Re:Mac is UNIX on the desktop

[beelsebob]

Also, as I type this on my Mac, no, OS X is _not_ UNIX.
Yes, yes it is â" it's certified UNIX 03.

You just don't have much experience with different unicies. Of random note â" the lack of /etc/init.d is to do with OS X improving significantly on how booting works â" launchd doesn't rely on scripts, but instead, dependancy trees, and because of this can deal with starting dependancies in the most efficient order (or in parallel).

Re:Mac is UNIX on the desktop

[mfnickster]

> But OS X is Mach with BSD extensions, and is really a NextStep-like OS, which was in turn UNIX-like.

Actually, the NeXT cube was released in 1988, when BSD still required a license from AT&T. So it was in fact Unix, even if they moved to an unencumbered BSD-licensed version later on.

Re:Mac is UNIX on the desktop

[Lars T.]

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?

It's not Linux-only: it's Linux and Win32.

Well, he speaks Cockney and Swahili, so other English speakers should have no problem understanding him.

Re:Mac is UNIX on the desktop

[RCL]

On fresh Linux install one can start working already. On fresh *BSD setup - you have to start compiling ports. Feel the difference.

That's true for user-oriented Linux distros (e.g. Ubuntu) only. With developer-oriented Linux distros (e.g. Gentoo) you also start compiling ports.

Re:Mac is UNIX on the desktop

[jrothwell97]

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:Mac is UNIX on the desktop

[ThePhilips]

On Gentoo you by definition start compiling. It's source oriented distro where recompile of everything norm of life.

What I actually spoken about in gp were normal system tools used to do usual daily *nix routine (find, grep, vim, etc).

Re:Mac is UNIX on the desktop

[roystgnr]

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?

Huh? C++ has even fragmented that much. If you use an old enough STL, you at least have binary trees available in std::map. If you're using a current standard library, you have hash tables in std::unordered_map. If you want to use hash tables whenever possible on any of the compilers in between, you have a mess like this:

#if defined(LIBMESH_HAVE_UNORDERED_MAP)
# include <unordered_map>
#elif defined(LIBMESH_HAVE_TR1_UNORDERED_MAP)
# include <tr1/unordered_map>
#elif defined(LIBMESH_HAVE_HASH_MAP)
# include <hash_map>
#elif defined(LIBMESH_HAVE_EXT_HASH_MAP)
# include <ext/hash_map>
#else
# include <map>
#endif

Plus autoconf macros or some such to get the defines right.

Re:Mac is UNIX on the desktop

[JasterBobaMereel]

Linux is not Unix (it's not certified)
OSX is not Unix either (it's not certified)

Because of the naming X.Org/GNU/Linux or whatever people insist it is called .. as an operating system means that OSX should be OSX/Darwin/XNU(Mach-4.3BSD)??

Re:Mac is UNIX on the desktop

[Dog-Cow]

OS X 10.5 is certified.

Re:Mac is UNIX on the desktop

[Dr. Smoove]

UHMMM you're contradicting yourself dude. "Most compatible Nix clone" with what, itself? That's not compatibility. That's Microsoft-style compatibility. And yea if you write something on Linux it probably shits itself on Solaris, that's because Linux and GNU in general hold your hand and make your life easier. People take simple stuff like grep -q for granted... I choose Linux specifically for this reason, and yes I love it too dude but try writing your shit on Solaris or FreeBSD, THEN moving it to Linux. Chances are it will work flawlessly. I don't just mean some sh-glue, I'm talking even freaking C code. I've personally witnessed Linux (well really gnu libs) let off-by-one errors happen in run time without segfaulting, Solaris totally says 'fuck you' immediately, and you get to fix your code so that it is actually right. Luckily, I don't worry about mixed environments anymore and I am that asshole that uses tons of bashisms and gnu-specific stuff everywhere.

Re:Mac is UNIX on the desktop

[ThePhilips]

UHMMM you're contradicting yourself dude. "Most compatible Nix clone" with what, itself? That's not compatibility. That's Microsoft-style compatibility.

Uhm... next time you should have tried to read the whole thread.

"Compatibility" I have talked about was in context of UNIX'03 certification and Linux's lack of it.

P.S. I also do not like when people write off something as bashism/gnu-specific stuff. If improvements do really help everyday's work, why the heck the *BSD nuts religiously refuse to add them?? How many decades it took them to add '-r' to grep? '-iname' to find??? I glad that they added them now. But force people to wait a decade for no good reason? And "burning at stakes" those "GNU/FSF heretics" who wanted to improve things?.. That's plain retarded.

Though overall *BSDs sport superior development environment, yet seeing that the environment yields so little of end results is really appalling. GNOME/KDE/X.org/etc use Linux as their native platform for the reason.

Re:Mac is UNIX on the desktop

[Dr. Smoove]

I read the whole thread, and realized that sounded far too douchebaggish the way I opened up. I think the spirit of the whole thread is in accordance: start on BSD and it will probably work everywhere, will take longer (devel time) and might look like shit due to 'standard' gnu functionality missing, but start on Linux and it will be a lot easier, quicker (devel time), and read better, but might shit itself on something more unixy... I award myself one internet for the greatest run-on sentence on all of slashdot that isn't a troll.

Re:Mac is UNIX on the desktop

[tyrione]

Never used NeXTStep or Openstep I see?

Re:Mac is UNIX on the desktop

[krischik]

Linux is also UNIX on the desktop.

Nope - UNIX is a Trademark. In order to use that Trademark for your Product you have to pass a test. OS X passed that test and Linux did not. See:

http://en.wikipedia.org/wiki/Single_UNIX_Specification

And the "Non-registered Unix-like systems" chapter is just a cheat of desperate system advocates trying the push there non compliant system onto the Wikipage. If they could pass then someone (i.E. Red-Had, SuSE) would pay the fee - at least for there "Enterprise-Server-Edition".

Re:What?

[leamanc]

Yes, eeeeverything that can be run on Linux/Unix can be run on a Mac. A lot of things are already there, or downloadable in binary form. For most everything else, there's MacPorts or Fink. If it's not covered there, there's always downloading source code and compiling. This sometimes is a lot of extra work.

It all depends on how much extra work you want to put into it, and how familiar you are with *nix environments.

ZZ99++

[itsdapead]

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

Re:ZZ99++

[Eli Gottlieb]

There's actually already a language named Alef. Now we just named Bet, Gimel, Gimel++, etc.

UNIX is UNIX is UNIX

[argent]

I think I've just given FreeBSD fans nightmares for months.

You don't understand FreeBSD fans, then. Most of the FreeBSD users I know have Mac desktops. Jordan Hubbard works at Apple now.

Mac on the desktop, FreeBSD in the back office, it's a sweet environment and everything "just works".

Re:UNIX is UNIX is UNIX

[Guy Harris]

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.

Re:UNIX is UNIX is UNIX

[argent]

Who the hell is Jordan Hubbard?

Lead of the FreeBSD core team for most of the project's life.

BTW, OS X uses a Mach kernel, not *BSD.

Mach is not a kernel. Mach provides a set of services that a kernel requires, but it's a long way from a complete kernel. It's been described as a microkernel, but I don't think that's entirely accurate either. In any case, the only complete operating system I'm aware of using the Mach kernel that isn't based on BSD is GNU Hurd. If not for Hurd, Mach might as well be called "MachBSD". :)

Many BSD variants have used Mach's scheduler, memory manager, and other components, including FreeBSD and Digital UNIX. Incidentally, when I asked Kirk McKusick about it, he said Digital UNIX was the closest commercial UNIX to the final BSD release, since it was based on 4.3 Reno, the last full 4.3 release before 4.4 Lite.

OS X has much more in common with NEXTStep than FreeBSD.

NeXTStep is another BSD derivative, based on 4.3BSD. NeXTStep, and the original versions of what became OS X, used more Mach facilities than OS X does... OS X has largely eliminated Mach messaging, for example.

As far as I have been able to tell, the last NeXTSTep-derived version that still used the NeXTSTep/4.3BSD code base was Rhapsody DR2. OS X 10.0 was released with a completely new BSD code base, using the FreeBSD source tree. OS X 10.3 refreshed that code from the latest FreeBSD source tree. The Cocoa GUI API is still based on the NeXT code, of course, but Darwin is a typical BSD mongrel.

Re:UNIX is UNIX is UNIX

[Guy Harris]

OS X has largely eliminated Mach messaging, for example.

O RLY? Fire up Activity Monitor, select some busy process, and watch the count of Mach messages sent and received. Perhaps the NeXTStEP developer documentation touted Mach messaging more than the Apple developer documentation does, but at least some higher-level APIs use Mach messaging.

Re:UNIX is UNIX is UNIX

[argent]

Interesting. I was referring to several posts I'd read some years back about the performance overhead of Mach messages and how Apple was eliminating them. My google-fu is inadequate to bring that back up, and possibly it referred only to certain kinds of messages where the overhead was a problem.

Re:UNIX is UNIX is UNIX

[Anonymous Coward]

Eliminating message passing overhead != eliminating message passing...

Where we go from here

[ChrisMaple]

Dr Suess will save us! http://www.amazon.com/Beyond-Zebra-Classic-Seuss/dp/0394800842/ref=sr_1_1?ie=UTF8&s=books&qid=1235319102&sr=1-1?

Re:What?

[argent]

I was unaware that OS X runs on ALPHA, ARM, and the other 19 processor platforms that Linux supports.

You spelled that wrong. It's "BSD runs on Alpha, ARM, ...". Mac OS X just happens to be the best BSD version for the desktop... and it's a much better desktop than any Linux desktop.

depends on the Mac people

[Trepidity]

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.

Re:depends on the Mac people

[pohl]

"fairly recent!?" Dude, that was a decade ago. I became a Mac user when Rhapsody first came out (it was the NeXT lineage that brought be onboard) and a lot of time has passed since. This reminds me of growing up in Podunk, Nebraska, in that after living their for 10 years the old ladies at the Methodist church were still referring to my mother as "the new girl in town".

Re:depends on the Mac people

[Trepidity]

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:depends on the Mac people

[FishWithAHammer]

I would say that most Mac users don't do that, though. A higher proportion of developers do, of course, but I know a couple of pretty heavy developers who use Macs and are outright hostile to the idea of using a command line. Which is funny, because one of them has been writing code on the Mac since System 7, using MPW (which had a command line!).

Mac^H^H^H people are weird.

Re:depends on the Mac people

[Malevolyn]

They're there in their room.

Sorry, Slashdot. I so rarely get a chance to use that.

Re:depends on the Mac people

[osu-neko]

"fairly recent!?" Dude, that was a decade ago.

That's fairly recent...

...

I just realized I've been a professional programmer for over a quarter of a century now...

damn kids...

Re:depends on the Mac people

[mdwh2]

It doesn't matter about time. The point is that classic MacOS was ditched, and they shifted to a new platform OS X. Trying to say the workflow of classic MacOS applies to a new platform 7 years later makes no more sense than saying that the AmigaOS workflow applies. Sure, some people might have been classic Mac users and then became OS X users, but plenty of OS X users were previously using other platforms. In fact, given how OS X seems to be a lot more popular than classic Mac OS was, I'd say this is true for most of them.

Re:depends on the Mac people

[gtall]

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

Re:What?

[mlwmohawk]

A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.

It has *better* software support from major ISVs, I will grant you that, but it does not have better software support generally and Linux supports far more hardware than MacOS. Not all Linux software runs on the macOS either.

My wife and son have macs, and I tell you, I'll take Linux every time.

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.

I have a couple printers that don't work on my wife's, son's or mom's mac.

I have an AMD noname and a Dell desktop as well as an HP pavilion laptop, and I don't have any real problems. I have to use the unsupported nVidia driver, but that isn't too hard to install. Things like Skype just work.

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.

That is a fairly subjective statement of a dubious conclusion. Most of the guys that I have worked with use macs at work because the "organization" in which they work requires MSOffice which is not supported on Linux. They would rather use Linux or FreeBSD.

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.

I am less productive on Mac, and I've spent my time fixing macs as well. I have a standing free bottle of Wine from an upscale wine shop because I was able to get their printer working on their mac. They had been trying for months.

When it comes to productivity, 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.

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.

Its funny, EVERY SYSTEM has issues. People who claim they do not are lying. Like I said, my wife, mom, and son have macs. I've developed software on macs periodically for about 15 years. OS/X does have its issues. There are hardware issues on macs.

For average users I recommend mac because it has far fewer problems than Windows. For techies, there is no substitute for Linux or FreeBSD. (I prefer Linux, but I have friends who prefer FreeBSD.)

Re:semi

[ejtttje]

I wonder: do use spaces for indentation?
I use tabs, and the indentation-equals-block makes a lot of sense to me.

Re:What?

[Comatose51]

The damn things ship with developer tools (Python, Ruby, etc.) and SDKs out of the box. Not sure if you're from the Bay Area or Silicon Valley but those things are really popular among software developers here. I switched to a Mac from Windows because I was sick of my tools getting in the way of my work. Not sure if things have improved much since Windows Vista (heard otherwise) or Windows 7 (heard good things) but I'm quite happy with Mac OSX that it would take a lot to make me give it up.

What "being UNIX" means...

[argent]

OK, whats with this unix love? Yes it is a unix workstation, but so is HPUX. HPUX is ...different. You will understand if you have ever used it.

Don't talk to me about HPUX, I'm still bitter about Alpha.

Being Unix compliant does not mean a OS is good, reliable, or stable OS.

Not being UNIX would mean that it doesn't matter how good, reliable, or stable it is... it wouldn't matter, I wouldn't be using it. I've done my time in the trenches dealing with VMS, TOPS, RSX, RTE-IV, MS-DOS, CP/M, Windows, AmigaDOS, Exec/1100, many of which were by all kinds of measures good, reliable, or stable. But dealing with different operating systems sucks rotting frog innards through used oil filters, and I'm too old for that kind of manure.

Being UNIX means that, if it also happens to be good, reliable, or stable (which it does), it's worth using. If OS X was based on Copland or even BeOS I'd still be running free UNIX on my desktop.

Are you insane?

[gbutler69]

You are not going to seriously suggest that Mac OSX supports more hardware than Linux are you?

I have a System76 Laptop running Ubuntu Linux 8.10. I have ZERO problems with hardware support of ANY KIND!

• Wi-Fi - CHECK!
• LAN - CHECK!
• 3-D Desktop with BEAUTIFUL effects - CHECK!
• Games - CHECK!
• Productivity Software - CHECK!
• Music Software - CHECK!
• Video Software - CHECK!
• 3-D Modeling Software - CHECK!
• Imaging Software - CHECK!
• Vector Graphics Software - CHECK!
• Programming Environments and IDE's - CHECK!
• Wireless 3-G Broadband with Verizon - CHECK!
• Anything else I can imagine - CHECK!

Your entire post is a complete puddle of steaming ass-goo for anyone who actually is in the know about GNU/Linux/Ubuntu. It truly is laughable!

Re:Are you insane?

[tyrione]

• My Debian system says you're generic list is as superfluous as the parent poster's commentary. CHECK!

Can we get back to the f'n point of this thread? D-Programming.

Re:Shouldn't it be called P?

[SecondaryOak]

Prolog?

No one cares about D

[Kuciwalker]

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.

Re:No one cares about D

[harry666t]

From what I've heard D can use libraries written in C.

Re:No one cares about D

[MightyMooquack]

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.

Re:No one cares about D

[noidentity]

From what I've heard D can use libraries written in C.

Care to name a language that can't use libraries written in C?

Re:No one cares about D

[SanityInAnarchy]

Library support is about 10000% more important than actual language design.

Perhaps. But most languages, including D, don't have a real problem with library support.

That is: Most languages will let you bind to C libraries. A highly productive language likely means that I will save far more time writing and maintaining the program itself than I might lose having to write C bindings.

Re:No one cares about D

[WalterBright]

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.

Re:No one cares about D

[loufoque]

C++ doesn't have many good libraries.
Qt is quite bad C++, for example, but will be for many the most beautiful C++ they ever see.

Re:No one cares about D

[overbored]

But language design dictates how libraries are written and how they are used. The language design decisions directly and deeply influence the flexibility, safety, and ease with which one can interface with a library, compose libraries, and so on.

Besides, we're already living in a world of C/Worse Is Better. D is a welcome exploration into improving the state of *systems programming*.

Re:No one cares about D

[JasterBobaMereel]

D has 3 disadvantages
    Lack of available libraries
    Lack of support in Linux or MS-Windows
    Lack of the letter "C"

The last one is serious, any language without this is not taken seriously by programmers and no matter how wrong, badly designed etc. C/C++/C# is, any other language no matter how correct/easy/powerful cannot compete ....

Re:No one cares about D

[baxissimo]

LOL. You're rigth! It's the lack of a "C". Walter should have called it c| instead. ... (little c + a vertical bar -- if the font is right that should kinda sorta look like a "d" :-)

c| -- C-Pipe a.k.a. d

Re:What?

[jonaskoelker]

you should realize that spending an extra $100

I think you forgot a zero. Prices may be different in my-vs-your neck of the worlds, though.

and has much better software and hardware support than Linux.

I think Linux has much wider hardware support (it works on non-apple hardware too), whereas OS X has full support for a much smaller set of hardware. What's better depends on personal preferences.

I can run basically every Linux/Unix application on my Mac

Really? Didn't the summary just say that some of the system calls are missing on OS X and some macros are different? Or did you mean running the binaries (in which case, there's still the system calls)? Or do you cheat by running Linux on your Mac? ;-)

You love your Mac, and that's great for you (really, I mean that). But I think you might be overselling it just a little. Bullshit detector went from green to yellowish green ;-)

I like Macs, but they're not easy to administer

[Trepidity]

OS X is easier to operate, and is set up to work well with Apple hardware. Those are nice features, and the reason I have an OS X laptop. But it surely isn't easy to administer. It's indeed quite terrible, since there's no package management to speak of.

Ever tried to walk through a classroom of mac-using high-school students how to get pygame installed and working on their OS? Including the proper version of python if their OS X has an old version, PyObjC, and so on? On Debian or Ubuntu, this requires double-clicking "python-pygame" in Synaptic, and all dependencies/upgrades/paths/etc. are handled automatically. In OS X it's a giant pile of manual bullshit.

And god help you if you have to resort to some mish-mash of .dmg installers, fink, and macports.

Re:I like Macs, but they're not easy to administer

[argent]

Ever tried to walk through a classroom of mac-using high-school students how to get [some non-portable piece of Linux-only code that was written with the assumption that it would only ever be run on Linux]

That's not a "package management" problem. FreeBSD has had better package management than Linux since before Linux HAD any package management system, and getting random "all the world's Red Hat" (or "all the world's Ubuntu") code running can be a pain and a half. That's a problem caused by writing code with billions of unnecessary dependencies.

Dependencies are a problem. Any sensible project manager will identify all dependencies and eliminate as many of them as they can. But "sensible project management" and Linux just don't belong in the same sentence.

I've run into the same problem on Linux, I spent a week once trying to get a set of packages and scripts working so I could package up some software to ship to customers, on Red Hat, and I ended up having to use the FreeBSD port of the package to figure out what all the dependencies were. I couldn't depend on them being able to use "yum" to pull it all together, because this was for an install that had to work on an offline system. Telling electric power utilities they had to connect their offline control system to the internet to do an upgrade was NOT an option.

Package management systems of the complexity of the ones Linux uses are a result of years of bad project management.

Re:I like Macs, but they're not easy to administer

[Draek]

So essentially, OSX runs every Linux application except for the ones it doesn't run. Really informative, isn't it? I'll borrow a phrase from the Windows fans they use with Wine: the end user doesn't care who's fault it is, only that it doesn't work. And as long as that is true, you'd better not claim OSX can run *every* Linux app.

Re:I like Macs, but they're not easy to administer

[argent]

So essentially, OSX runs every Linux application except for the ones it doesn't run.

OSX runs essentially every UNIX application. Linux applications that depend on Linux-specific features aren't UNIX applications. Do those Linux-only applications run on FreeBSD, Solaris, or AIX?

you'd better not claim OSX can run *every* Linux app.

Good thing I never made that claim.

Re:I like Macs, but they're not easy to administer

[Draek]

From your original post:

I can run basically every Linux/Unix application on my Mac

And for what is worth, I've yet to see a Linux app that can't run on FreeBSD, though I think some binary-only games had a bit of trouble with the Linux Binary Compatibility add-on but then again, that's to be expected from closed-source.

Re:semi

[WillKemp]

I use tabs for indentation. But i don't use python.

Maybe i'm wrong, but using an invisible character (which could be a/some tab(s) or a/some space(s)) seems like it could make the code very hard to read and prone to errors.

All the world's a VAX.

[argent]

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:All the world's a VAX.

[mlwmohawk]

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.

Yup, and that makes it easier for people like me to get jobs.

Ask your friends about porting Linux code from people who think portable means "it compiles on Red Hat and Suse... ship it!"

Well, I will grant that embedding system level and environment level calls in common code is a bad idea, but it has been my experience that porting from Linux to something is easier than porting from something like "Windows" or "Mac" to Linux.

Oh, while we're on the subject, you do know that Jordan Hubbard works at Apple now, don't you?

And?

Re:All the world's a VAX.

[argent]

Well, I will grant that embedding system level and environment level calls in common code is a bad idea, but it has been my experience that porting from Linux to something is easier than porting from something like "Windows" or "Mac" to Linux.

If people are writing to Apple's GUI APIs, yeh, you're not going to have much fun getting that working with GNUstep. It's a shame that GNUstep never took off. But that's not UNIX code... UNIX doesn't have a GUI.

But if you're looking for portable code, you're more likely to get FreeBSD code working on J. Random *NIX than Linux code. And an awful lot of those FreeBSD developers have Mac desktops these days.

Re:All the world's a VAX.

[Kazoo the Clown]

Oh, while we're on the subject, you do know that Jordan Hubbard works at Apple now, don't you?

Hmm... Jordan Hubbard.... Argent... That explains a lot. The Reality Distortion Field is working overtime here trying to convince us that OSX == BSD.

Well, maybe it is.

But maybe many of us don't even care.

So you, and, er., he, drank the kool-aid. You've made that clear. And yes, software is always more stable when it's written to run on a restricted set of hardware. Yes, we all know that. Too bad significant compatibility and flexibility has been lost in the process. Once you get beyond the world of the unsophisticated "black-box" user, flexibility of the hardware often becomes a critical feature. With OSX, all your hardware has to come from Apple or has to be approved by Apple, and that leaves out a lot. Consequently, OSX will always be an anomaly in the Unix-ish environment.

The thing is, it's just not about Unix anymore. Once upon a time, Linux was measured against how Unix compatible it was. Times have changed however. Unices are now measured against how Linux compatible they are. Look at what IBM has been doing with AIX. Look at what Sun is doing with Solaris. SCO was mismanaged into oblivion, there's absolutely nothing going on there. Unix is so, 20th century. And look what launched all of this-- "GNU's Not Unix," it's PROUDLY not Unix. Could it be any more obvious?

Re:What?

[jcupitt65]

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.

So fucking what!

[FlyingGuy]

Fabulous, he ported a language to the MAC. Ok groovey...

The bit about having to make adjustments to the library code is news why?

Not all OS's support everything in the world, that is just the way it is. If you implement a certain function or macro one way on one platform does not in any way mean that you will be able to implement exactly the same on another platform.

Re:So fucking what!

[godrik]

Have you read the linked article ?
It constains interesting informations about how to align memory or how 80bit floatant are stored. This article seemed interesting to me.
If I were a Mac user, I will interested in knowing that there is now a functional D compiler for my OS...

Re:So fucking what!

[FlyingGuy]

Yes it is interesting.. So lets chalk this one up to really bad editing from the /. "editors"

Perhaps the article should have been titled, "Interesting adjustments on the OSX platorm while porting D".

Re:So fucking what!

[Makarakalax]

I hope you're not proud of you inane and boring tripe.

Re:So fucking what!

[jrothwell97]

It's not just any language—it's an improvement on C and C++, which are like the Latin and French of programming languages.

And by the way, it's Mac or Macintosh, not MAC. MAC is Media Access Control, entirely unrelated to Macintoshes (apart from the fact that Macintoshes use them to connect to networks, as do all other modern network devices.)

Re:So fucking what!

[FlyingGuy]

Ok so you are nit picking asshat but I digress...

I really doubt it will be an improvement on C. Assembler is pretty much the ultimate programming language followed by C and Pascal, in that order for general purpose programming. Everything else is simply a derivation of those, most of them not worth the time it took to write them.

Re:semi

[ejtttje]

To me, it enforces that the code *is* easy to read, by ensuring the visual indentation matches the semantic intention.
There's never a mismatch between what you intuitively see and what it actually executes. Which is probably why they let you mix tabs and spaces as long as it's consistent visually. Although personally I think it should be a syntax error to mix them (or better yet, an error to use spaces for indentation in general ;-p)

Re:semi

[Just Some Guy]

Maybe i'm wrong

You're wrong. In the last 6 years of our company using Python for business logic development, we've never had a single bug that was traced back to indentation or an end-of-line problem.

Re:What?

[argent]

Didn't the summary just say that some of the system calls are missing on OS X and some macros are different?

No, the summary said that the code was written with unnecessary dependencies on obscure libraries that didn't happen to be shipped on OS X, and that it was so buggy it depended on the expansion of macros being identical on different operating systems.

I can pretty much guarantee that any program with those kinds of dependencies would have just as much of a problem porting to any other UNIX system. It wasn't a "Linux/Unix" program, it was a "Linux-only" program.

Re:What?

[geoff2]

A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.

Apart from if you want to run the most popular scripting language.

The lesson, which any Mac developer with a clue has known for years, is that if you want to work with your own customized perl installation, install your own Perl, don't extent the preinstalled version which Apple might change in a future update. Since installing perl on a Mac involves, basically a) downloading the software; b) typing "sh Configure -de"; c) typing "make"; d) typing "make install." Not too tough, really.

Re:What?

[pohl]

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.

Re:What?

[sammyF70]

hmm . excuse me, but : better hardware support?
Since when? Can I just take, let's say, some non-apple graphic adapter I've got lying around, plug it in, and it will work? Or go out and buy some random wireless adapter?

Better sofware support is arguable, but better hardware support, I think not

Re:semi

[WillKemp]

Yeah, maybe so. It seems a bit ideologically driven to me - a language that forces a particular coding style on you.

I invariably indent blocks - but i do it because it's good practice, and i don't think i'd like it if the languages i wrote in forced it on me.

Now if a language forced you to intersperse code blocks with verbose comments, i might think it was a good idea! ;-)

Re:Shouldn't it be called P?

[berend botje]

Now that's the truth!

THIS IS SLASHDOT!

[argent]

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.

Re:THIS IS SLASHDOT!

[argent]

Oh yeh, this is slashdot alright. "When someone suggests you might be wrong, tell them they're a troll. Everyone hates trolls and accusing someone else of being a troll is the best possible way to divert attention from your own trolling".

No, I'm not playing, sorry.

Re:THIS IS SLASHDOT!

[Zero__Kelvin]

I suggest you look up et al.

No, asking for research to be done is not trolling; claiming that OS X is *BSD when you openly admit you knew it wasn't is trolling.

"You can check out the kernel code for many of the BSD variants out there, including Darwin, and let us know just how far OS X is from 4.4-Lite compared to the rest."

You may also need to look up the word variant. So in an argument where I say it is not the same and you claim it is, you want me to assess how different it is? So basically, it is the same and if I don't believe that I should measure the difference . WOW! I didn't think you could find a way to appear more absurd, but you pulled it off!

Re:THIS IS SLASHDOT!

[argent]

No, asking for research to be done is not trolling; claiming that OS X is *BSD when you openly admit you knew it wasn't is trolling.

A straw man argument is an informal fallacy based on misrepresentation of an opponent's position. To "set up a straw man," one describes a position that superficially resembles an opponent's actual view, yet is easier to refute. Then, one attributes that position to the opponent. -- Your beloved Wikipedia

Re:THIS IS SLASHDOT!

[argent]

I am well aware that your initial post was a strawman attack.

Let's see. Someone claimed that OS X supports the hardware it runs on better than Linux does. You responded by talking about the variety of platforms that Linux runs on. That's a perfect example of a straw man. The guy you were responding to doesn't care if OS X runs on an Alpha or Integrity server, or that old Indy you have in the back room to show how cool you are.

My response was that it doesn't matter, if you want to run on oddball hardware, you could run pretty much the same OS on all the same oddball hardware. For someone who actually uses BSD variants on a regular basis, it doesn't matter whether whether one is running FreeBSD, OS X, OpenBSD, Tru64, NetBSD, and so on... they are largely fungible, just as Ubuntu, YDL, and Gentoo are. Which is why I run FreeBSD servers and Mac desktops, and develop software on both.

I didn't complain that you can't boot a Ubuntu install CD on a Powermac, and need to get a Yellow Dog image instead. Now that WOULD be a straw man.

OSX is BSD, just as much as OpenBSD is. Yes, you have to use Apple's hardware to run OS X. That's the cost you pay to get the best UNIX desktop. I wish I could run OS X on a Thinkpad instead of my Macbook, but OS X is enough better than any Linux desktop that I've found that I'm willing to put up with it.

But that doesn't make OSX "not BSD" any more than the fact that YDL won't boot on your Thinkpad makes YDL "Not Linux".

Re:THIS IS SLASHDOT!

[argent]

The OP did NOT offer the caveat you are now conveniently inserting.

There's this thing in English called "context". Ignoring context is a really effective way to set up a straw man.

Re:THIS IS SLASHDOT!

[MrHanky]

One would assume you were trolling from the blatant dishonesty of your post. OS X isn't a particularly good BSD for the desktop; the only thing that makes it decent is the proprietary non-BSD stuff running on top of Darwin. As a BSD, Darwin is pretty damn poor, in almost all respects. There's a reason why no one uses it except as part of OS X, you know.

And insofar as other BSDs support a bunch of other platforms, that has nothing to do with the fact that Linux has far superior hardware support compared to OS X. Basically, you argue like a delusional fanboy. and when that doesn't work you try an appeal to authority. Well, you may be an authority, but you're also a liar.

Re:THIS IS SLASHDOT!

[argent]

Indeed, he said "a Mac", not "OS X".

OS X has better support for Mac hardware than Linux does for any hardware I've tried it on.

Re:THIS IS SLASHDOT!

[Zero__Kelvin]

I'll defer to your mastery of the technique.

Re:THIS IS SLASHDOT!

[tres]

This is a ridiculous assertion based upon an interpretation of an overly abstract -- if not inaccurate sentence -- out of context; however the context for the statement does clarify the original meaning of the sentence.

Let's look at the sentence being argued:

A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.

And it doesn't take much to find one sentence later this clarification:

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.

So having some silly pseudo philosophical argument about the meaning of "hardware support" in the original post and calling people liars if their argument doesn't conform to your viewpoint is not productive, nor does it take into account the original post.

Re:THIS IS SLASHDOT!

[MrHanky]

You're doing it again. I cut a bit of his comment for brevity, which was "is a genuine Unix workstation", implying OS X; in fact all of the comment implied OS X. Besides, if he really did mean that the Mac hardware had better hardware support than Linux (see how absurd this gets?), it would still be wrong.

You're deliberately trying to confuse the debate.

Re:THIS IS SLASHDOT!

[argent]

I'm sorry, I honestly can't read his comment as meaning what you are describing. He was clearly talking about the fact that the hardware and software are all produced by the same company, so that the operating support for Apple's hardware is better than the support available in Linux for a generic PC. I'm not sure that this is true in every case, and it's not true for every class of hardware (Apple's support for SCSI tape is effectively nonexistent), but for most classes of hardware (video cards being the poster boy here) the best Linux support has been unfortunately problematic for me.

Re:THIS IS SLASHDOT!

[argent]

I didn't suggest that Darwin by itself was a particularly good BSD for the desktop. I said that OS X is. Yes, that involves a bunch of stuff that isn't part of BSD, but that's true regardless of whether you're running Cocoa, NeXTstep, Gnome, KDE, or code written for raw Xlib:

peter@enclave 112 % uname -a
FreeBSD enclave.in.taronga.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
peter@enclave 113 % cd /usr/src
peter@enclave 114 % find . -name '*xterm*'
peter@enclave 115 %

And "broad hardware support" isn't the same as "superior hardware support". Linux is a jack-of-all-trades, it provides acceptable performance and consistent behavior on a variety of platforms, but Jack of all trades is master of none. For the hardware that OS X runs on, it provides better hardware support than Linux. That's true for just about any UNIX workstation vendor... they are simply able to focus their resources better. Which is the whole point of saying, as the OP did, that the Mac is a UNIX workstation.

Re:THIS IS SLASHDOT!

[srussell]

My response was that it doesn't matter, if you want to run on oddball hardware, you could run pretty much the same OS on all the same oddball hardware.

I'm taking you out of context, but I want what you say to be true so badly that I need to respond.

Sadly, not all OSes are fungible. In fact, that's the exception rather than the rule. BSD, Windows, and Linux might be fungible, but Minix, Mac OSX, and OpenSolaris aren't. I don't run Minix on my laptop only because it would render half of the hardware features unusable (sleep mode, touch screen, etc.); this is the same situation with most of the other non-mainstream OSes out there. I can't run OSX mostly because of the Apple hardware department's death-grip on Apple's (the company) testicles. In fact, even within Linux, I've had varying degrees of success with hardware support with different distributions.

In my experience, the fungability of which you speak is a myth.

--- SER

Re:semi

[Zero__Kelvin]

No, nor should we. Your mistake is in assuming that pressing the enter key indicates an intent to end the language statement. C and C++ both ignore whitespace and line feeds. There are lines of code that are very long, and it becomes unreadable if it must all live on the same line. So yes we must, and will, promote the excellent well thought out design forward.

Qt bindings

[SwedishPenguin]

I really like D, and would give up C++ for it, but the one thing I feel is really missing is bindings for Qt. :(

Re:Qt bindings

[yumyum]

Same here. The language looks fairly nice, but right now with ACE, Boost and Qt in my C++ toolbox, I'm doing alright. And I already develop, test, and deploy code that runs on MacOSX, Linux, Solaris, and supposedly Windows -- I have not actually tried there, but ACE, Boost, and Qt have abstractions that attempt to isolate developers from the OS. I'm curious if my Qt OpenGL stuff would work. I love using my Apple laptop for development. I'm more of an GNU Emacs fanboy than Apple (though I did buy a chunk of Apple back at $18 pre-split), so I do everything there, including having multiple shells open in it for command-line use. I even have a Platypus script that I can drag files onto and edit in GNU Emacs. I just take my GNU Emacs customization files to other platforms so I always have the same editing environment.

Re:Qt bindings

[mrmonday1]

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.

Re:Qt bindings

[JJJK]

Someone's already working on it: http://code.google.com/p/qtd/

Re:Qt bindings

[Hangeron]

http://code.google.com/p/qtd/

Re:Qt bindings

[SwedishPenguin]

Very nice, thanks. I'll have to consider it for my next project.

THIS IS SLASHDOT!

[argent]

I suggest, while you're out there, you look up Lites, Tru64, DragonFlyBSD, and some of the other BSD variants. You can check out the kernel code for many of the BSD variants out there, including Darwin, and let us know just how far OS X is from 4.4-Lite compared to the rest.

Oh, right, this is slashdot. Asking people to do actual research is trolling.

GNU libc isn't oddball

[Pinky's Brain]

From a pragmatist point of view it is the standard.

Re:What?

[pdbaby]

I think it means that the beautiful design of the machine is hidden away in the basement :)

Re:semi

[harry666t]

Go to Google code search, type lang:python, hit enter, read some code. Python is VERY readable. So far I think it is the most readable programming language I've ever used.

Who cares what the open group says?

[argent]

Bunch of kids with a trademark in their pocket.

UNIX is a family of operating systems with a native API and system call interface based on the UNIX programmer's manual, published by Bell Labs (usually the 7th edition).

That's a *useful* definition for UNIX.

Re:What?

[Egdiroh]

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.

this isn't school-owned hardware

[Trepidity]

This was a voluntary program in which students brought their own laptops, some of which were OS X. In general, the Linux and Windows laptops presented no problems; the OS X laptops presented difficulties due to lack of a standard user-friendly installation process.

Re:semi

[jeremyp]

Actually, the default condition for most languages is that the end of line is just another white space and that's the way I like it. I like my source code text to fit into 80 columns. Long thin columns of text are easier for the human eye to scan than short wide ones. This is the same reason why newspapers do not print single lines across the whole page, but divide it into narrow columns.

My personal opinion is that any language where white space (i.e. characters you can't see) does anything more significant than separate the tokens is the spawn of Satan.

Yes, including Python.

Re:Holy design problem, Batman!

[baxissimo]

Ugh, yeh, this article referenced is just Walter's brain-dump writeup of what it took to get the mac port working for anyone who is interested. I don't think it was really meant to be a profound and insightful piece on software development. I think there he's referring to a bunch of code he wrote back in the 80's when he was primarily a Fortran & ASM programmer.

Also don't get your hopes up. The mac port is just barely working -- this is like the pre-pre-alpha release of it. Walter releases new snapshots about every month, and what's available now is just the first snapshot to ever have Mac support. So expect things to be broken.

Re:What?

[mlwmohawk]

You can't seriously be suggesting that X11 is unavailable

Not at all, but it is not *the* display system it a legacy add-on for applications designed for other systems. It is certain your iTunes application will not run in this way. On Linux, virtually all the applications will run this way. X11 on mac is a kludge.

So, I can run:

ssh -X root@host gnome-control-center

How would you do that on Mac? VNC? What a kludge.

Abandoning X11 was a mistake.

hardly linux-only

[Trepidity]

Windows worked perfectly fine, because it goes the other route, and lets users just run installers for anything they want (oh, and it has installers, not .dmg bullshit); only OS X presented problems. OS X can't decide if it wants users to install and upgrade things, or it wants that to be managed centrally, so you have a mish-mash of both. OS X-installed Python, of one version, user-installed Python, at a different path, of a different version. Neither Windows nor Linux require you to mess with crap like that.

Re:hardly linux-only

[argent]

I'm kind of confused about just what you're talking about.

Whether a package is distributed as a disk image or a zip file (or a tarball, or a RAR) seems quite irrelevant to me. Are you talking about the difference between packages and bundles?

Windows doesn't even include python. If you're packaging software for Windows, and you want to use python, you can't depend on your users having any version of python, so you have to include one. And Windows library management is both primitive and highly complex. I've just submitted the final version of a Windows/Linux distribution to QA and I had a hell of a time making sure I had compatible configurations for Qt and python for everything from Windows 2000 through Windows Server 2008, and the Linux side wasn't significantly easier... we had a last minute delay because of a conflict between packages for two different Red Hat versions.

Re:hardly linux-only

[Trepidity]

Re: the distribution method, it's mostly that distributing disk images that users have to mount and then manually drag things out of is a bit primitive. Windows typically has .exe or .msi installers that do that part for you. The OS X approach is so unintuitive to most users that many apps distributed as a .dmg have resorted to including symlinks to where you're supposed to drag the thing (usually the Application folder) within the .dmg itself, along with a bit "DRAG THIS HERE" arrow. If that kind of hack isn't a marker of broken design, I don't know what is.

I agree that Windows has some flaws due to lack of dependency management also; it'd be ideal if you could just say "hey this depends on python >= 2.5, make sure that's installed", without the user having to intervene, or every app including its own version of the runtime (I must have 12 copies of Java installed, which is kind of ridiculous). But at least it doesn't pretend to come with things but then fail to keep them managed reasonably: you can depend on Windows not coming with a specially ancient Microsoft Python, so if you want to have a non-bundled option, you can just tell your users, "go download the Python installer from python.org, run it first, then run our installer". On OS X, you can't even do that, because OS X comes with python but doesn't keep it updated, so you have to explain to your users how to install a second copy of python, in a different path, and then point your app to that one.

Re:hardly linux-only

[argent]

Re: the distribution method, it's mostly that distributing disk images that users have to mount and then manually drag things out of is a bit primitive.

It's no different than distributing ZIP files that users have to unzip and then manually drag things out of.

If your packages are Cocoa-based, it doesn't matter where they're installed. They should be able to run right out of the disk image, or where you unzipped them, and all the hooks other applications and services need to locate them "just work". OS X will even re-mount the disk image if need be, when you open a file that needs that application.

It's a completely different approach than the traditional Linux one, but it's hardly unsophisticated. I take advantage of it regularly to keep my installed apps under /Local/Applications/Internet (or whatever) instead of mixed up with Apple's packages in /Applications. And I really hate people who try and subvert that, including the ones who include those stupid "drag here" links.

When I was in the NeXT world I had kind of hoped that GNUstep would take off, so that the tyranny of /usr would get broken in the rest of the UNIX world. But no use crying over spilled milk.

Now if anyone's installing packages that DO depend on where they're installed as app bundles instead of installers (and, yes, Apple DOES provide an installer framework for that use case... and it works fine for non-Cocoa-based packages), then that's an error. But I can't honestly say I have ever run into that.. usually it's the opposite situation, and I have to go in and use PAX to unpackage the installer bundle so I can get the app installed where I want it.

On OS X, you can't even do that, because OS X comes with python but doesn't keep it updated, so you have to explain to your users how to install a second copy of python, in a different path, and then point your app to that one.

I've had to do that on Linux, too. When you're dealing with industrial customers, you MUST NOT update their working systems. They may have software that depends on workarounds for bugs in old packages that get broken on newer ones. I've had to have two versions of GNOME libraries and two versions of Java installed for one system, on more than one occasion.

But I never asked my users to do it. Once I figured out the problem, I built an installer to install it all outside the default prefix, and included that in the package.

Re:What?

[risinganger]

I have to agree with this. I had a huge amount of hassle installing and compiling gnucash. I had to download libraries not found within macports, locate and compile packages from alternative sources due to broken copies in macports and so on.

That was the case where I was lucky enough to get it to work in the end. I've lost days on others before writing it off as a waste of time. It's bad enough that it would be better if macports didn't exist.

Re:What?

[pohl]

...but it is not *the* display system

Yes, I see you've chosen #1 as your remaining complaint. Like I said, most users are thankful for this, and with good reason.

Regardless, all you wanted was to see a Mac do what you suggested, which it can. Now you're demanding that this be the case for all applications...you're trying to score by moving the goalposts.

Re:What?

[mlwmohawk]

Yes, I see you've chosen #1 as your remaining complaint. Like I said, most users are thankful for this, and with good reason

And what would that "good reason" be?

The limited capability?

Regardless, all you wanted was to see a Mac do what you suggested, which it can. Now you're demanding that this be the case for all applications...you're trying to score by moving the goalposts.

Not at all. It is a very important feature.

Of course, this is slashdot.

[argent]

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:

A straw man argument is an informal fallacy based on misrepresentation of an opponent's position.[1] To "set up a straw man," one describes a position that superficially resembles an opponent's actual view, yet is easier to refute. Then, one attributes that position to the opponent. -- Wikipedia

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:semi

[Tiger4]

No, fewer lines means tighter code. If the logic is good, fine. Else, it means worse bugs to figure out and debug/expand. end

Re:What?

[smallfries]

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:semi

[A12m0v]

http://uncyclopedia.wikia.com/wiki/Semicolon_Cancer

Re:What?

[MightyYar]

I'm a Mac fan - I've had several. But this system is my second in a row with a wonky Firewire bus. If I try to use built-in Firewire with certain devices, I get kernel panics. The solution both times has been a $20 third-party card, but it's still annoying. If it happened on my laptop, I'd be SOL.

Re:What?

[ktappe]

I think it means that the beautiful design of the machine is hidden away in the basement :)

The "beautiful design" of the Mac Mini was hidden away in the design studio in Cupertino in the interest of producing a low-cost unit. MacBooks and iMacs are beautiful. Mac Mini's...not so much.

Computer languages != human languages

[localroger]

Computer programs are lists of instructions to be executed in sequence. Since roughly the invention of writing lists have been organized on a one item per line basis. I can see the argument for allowing ; as well as EOL in order to fold short loops into a single line, but not defaulting EOL to end-of-statement makes no sense and just makes obfuscation contests possible. And comparing this to FORTRAN's requirement that you start everything in column X is a total straw man.

Re:What?

[pohl]

And what would that "good reason" be?

Because of the experience and features that their applications provide. What they do not know, and cannot be expected to know, is that these things stem from deliberate tradeoffs made by the developers of the underlying frameworks.

As any programmer worth his salt knows, any design decision comes with a set of tradeoffs. This is an inescapable fact, and only goes unrecognized by the ignorant (whether their ignorance be innocent or willful.) The fine art of balancing a set of tradeoffs is very difficult, and an inherent aspect of it is that you can't please everybody 100% of the time.

In this case, you are one of the unfortunate few that Apple deliberately chose to devalue in their design priorities, since one of the items high on your wish-list is ubiquitous remote displayability via the X11 protocol.

But, bringing our minds back to the subject of tradeoffs, what did they win by giving you the finger? (*) This is an easy exercise for those skilled in software architecture. The first thing that one needs to ask is what sort of restrictions does conformance to X11 bring with it? X11 is a set of abstractions that end up leaking into many different layers of your software stack. While I love X11, a lot of those abstractions were invented a very long time ago before anyone thought they might like different abstractions, like a hardware-accellerated Quartz display server - or CoreImage, CoreVideo, CoreAnimation.

This choice has given them the freedom they need to make architectural advancements faster, and now they're in a leadership position. If you are a programmer and you still think they could have delivered their current product in the same timeframe after having volunteered to be hamstrung by obedience to X11, then you might want to consider a career change.

Nothing comes without a cost. There is a long history of UNIX vendors who tried for years to bring a good GUI environment to X11 and the best they could come up with was CDE. (WTF.)

(*) one footnote here: it wasn't Apple that gave you the finger. This decision was made in the late 80s at NeXT when they opted against X11 so that they could get the WYSIWYG properties afforded by the Display Postscript system. After Apple acquired them, they kept the imaging model but replaced the Postscript interpreter with Display PDF. (PDF is, more or less, the PostScript imaging model without the full force of the Postscript programming language.)

Re:What?

[mlwmohawk]

Its funny, the only thing I saw in your post that even looked like a reason was this:

If you are a programmer and you still think they could have delivered their current product in the same timeframe after having volunteered to be hamstrung by obedience to X11, then you might want to consider a career change.

As a more or less lifelong software engineer. I've been employed in the industry for over 25 years, I don't agree.

Take a look at Gnome or KDE and ask what Mac couldn't do.

D is nice, but...

[Hangeron]

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.

Re:D is nice, but...

[FoboldFKY]

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.

This is somewhat alleviated in D2 via a shared core runtime. The problem is more or less that which library you use is based on the task at hand, and personal choice. There have been numerous attempts to merge them, or kill one off, and they've never succeeded because people don't want to give up the library they (legitimately, for their circumstances) see as better.

For D1, your best bet is probably to give Tango + Tangobos (which is Phobos implemented on top of Tango) a shot. For D2, there are efforts to fix the situation.

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.

Yeah; I think LDC is the future of D. We'll just have to be patient. :)

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.

That's because it's not finished. You can't complain that an experimental version that changes on a regular basis doesn't have library support.

As for when D2 will be finished, I deeply suspect it will be like it was with D1: Walter and the community will get fed up with it as a moving target, draw a line in the sand and *boom* finished; let's start on D3.

Re:What?

[pohl]

You must have missed this, or the importance thereof:

Because of the experience and features that their applications provide. What they do not know, and cannot be expected to know, is that these things stem from deliberate tradeoffs

As much as I like how far Gnome and KDE have come along, they are trailing, and serve only as evidence that NeXT made the right tradeoff 20 years ago.

Runtime design

[argent]

Interesting. It wouldn't have occurred to me that they would expose the contents of the C include files as part of the D runtime, and translate the actual include files into D. Wouldn't it be better to implement the runtime exposed to the D application in a mixture of C and D, with C wrappers around the actual library calls? It would certainly make a port significantly easier!

Re:Runtime design

[FoboldFKY]

If I had to guess, I'd say it's because that would involve introducing another function call between D and C. Currently, a lot of the C library functions exposed in D are just extern(C) declarations, so code is calling them directly. Placing a C wrapper around those calls would slow things down (and Walter doesn't like slow.)

Incidentally, there's a tool Walter wrote called htod which actually runs a C or C++ header through the C++ compiler and then converts the internal AST into a D header. Sadly, it runs it through the DigitalMars compiler, and DMC doesn't run on mac. :P

Re:Runtime design

[argent]

Ah, performance vs portability, a common tradeoff.

Still, a portable runtime for the first pass (like the first stage gcc build) would seem to be a reasonable path, particularly on the Mac where Apple has been known to make significant changes in include files across versions.

No multiple inheritance

[wealthychef]

Look at the chart in the article, and you'll see it has no multiple inheritance. Might be pretty important to some. :-)

Re:No multiple inheritance

[WalterBright]

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.

Re:No multiple inheritance

[HiThere]

Well....or possibly Eiffel, if you want garbage collection.

Wrong Bright Evil!

[fm6]

Hate to spoil a perfectly good joke, but Bright did not invent or name C++. Credit for that belongs to Bjarne Stroustrup.

Bright did create some widely used C++ compilers. But to me he will always be the author of that notorious time sink, Empire. If you count derived games like Civilization (which is just Empire with a complicated resource model) Bright has single-handedly destroyed more productivity than Pac Man and Warcraft combined!

And of course a D implementation is available!

Re:Wrong Bright Evil!

[fava]

But to me he will always be the author of that notorious time sink, Empire

Now I know who to blame.

I spent many many hours playing empire when I should have been doing something usefull. For the sake of my current productivity, please reassure me that there is no linux version.

Re:Wrong Bright Evil!

[fm6]

Well, the good news is that Bright doesn't seem very interested in Linux development. The had news is that he'll sell you the source for $10!

Re:What?

[MemoryDragon]

Well MacOS is how Linux should be on the desktop!
I also switched to OSX from Linux a while ago and I know many people did. Linux guys should really get slowly nightmares, unless they finally can put on a system which does a normal hibernate by closing the and does well all codecs and wifi, OSX erodes the Linux market share among developers. Hell I even know a load of people who switched from Windows due to the Unix nature of the System. From all people I know people developing on Windows either are a minority or are forced by their companies, most at least have privately fully switched, only keeping the Windows machine around for gaming!

Both Microsoft and Linux have a serious problem there! Linux even more than Microsoft!

Re:Shouldn't it be called P?

[rrohbeck]

Nope. We have B, we have C and the one language to rule them all has source files ending in .PL

Amen.
>with the programmer productivity of modern languages like Ruby and Python.

Now if there had been Perl in that sentence I might be interested.

true

[toby]

Things are much easier (and more current) on Gentoo and even the binary packaged Linux distributions.

So I use my Linux box for my "day job" development, and the Mac for "everything else" - but I can certainly develop on the Mac at a pinch.

Re:What?

[Guy Harris]

Abandoning X11 was a mistake.

"Abandoning" implies that they used to use it and stopped. NeXTStEP never used X11 as its underlying window system (its window system was Display Postscript-based), and Mac OS X never did, either.

Whether it was a mistake or not depends on your goals. It was a mistake if being able to run individual GUI applications "over the wire" is important. It wasn't a mistake if it allowed them to get a given level of graphics performance and capabilities faster.

Re:What?

[Guy Harris]

Not at all. It is a very important feature.

To some users, yes. To other users, no. If it's important to you, then Mac OS X might not be the OS for you, especially if what Mac OS X does offer, such as the ability to run Mac applications, isn't as important to you.

Re:What?

[osu-neko]

Bad example. I had pretty much the same experience trying to install and run gnucash on Debian. For a very long time, it was impossible to do without downloading and reinstalling custom compiled versions of some of Debian's standard library (on which hundreds of other Debian packages depended on).

Re:What?

[osu-neko]

No no, if developers do something stupid under Linux and an update from the package manager breaks it, it's the developers' fault. But if developers do something stupid under OS X and it breaks, that's Apple's fault.

wasnt it already there?

[mehemiah]

does anyone else remember this already being on mac? I specifically remember downloading a D compiler plugin for XCode. It had a package and everything. I just never did anything with it. Also, it is what many Doshin shooters are written in. Epecially the ones written with BulletML. Many of these are crossplatform http://www.asahi-net.or.jp/~cs8k-cyu/

Re:wasnt it already there?

[mehemiah]

there's an english link but for the lazy. http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html

Re:What?

[DustCollector]

ssh wasn't it. Walter was referring to hiding a beautiful Mac in the basement. Macs are meant to be seen as well as used.

Re:What?

[WillKemp]

Cool. That was modded "-1 Disagree" too! The mod morons are out in force today!

Re:Another programming thread.

[gpuk]

Well said. If I had points left, I'd mod you up.

Re:What?

[jelle]

"No, the summary said that the code was written with unnecessary dependencies on obscure libraries"

I hate it too when people use libraries unnecessarily. However, in many cases using a library prevents re-inventing the wheel.

"that didn't happen to be shipped on OS X"

If OS X doesn't have a library, then that's not a fault of Linux, now, is it? Nor is it unfixable; port the library, you probably got it with the full source.

"it depended on the expansion of macros being identical on different operating systems."

Expansions of macros differ between operating systems? Surely you must have meant compilers.

Programs tend to end up depending on compilers and libraries. That's not something that just happens with linux programs, it happens just as much for macs and windows programs...

You sound like a mac user/developer who wanted (had to) port/use a cool linux program on the mac, and discovered that osx is not linux, and now tries to blame linux, forgetting that you would have encountered the same issues porting the other way around, actually worse because apple doesn't give us the source to their obscure libraries...

Re:What?

[cervo]

you should realize that spending an extra $100 on a Mac is well worth it

Ah my good friend, alas but if it was only an extra $100 then I might consider it. But a good mac computer is way more than $100 more than an equivalent PC with the same hardware. That is my first gripe with Macs, that their hardware is the same as that of a normal PC but they charge you like it is caviar or something.

My second gripe with MACS is that for a lot of the software you have to keep going back to Steve Jobs and that is kind of expensive. Windows has way more freeware/shareware than a MAC. Although now the situation is improved due to the BSD kernel. Nevertheless there are a fair share of apps that don't work on a Mac. An example of this is in the article, the D programming language. The article mentions that porting D wasn't trivial, the guy had to do more than just run make on the BSD box. Plus as has been mentioned Linux is often incompatible with other UNIXlike operating systems as well. So just because your favorite app works in linux is no guarantee of mac compatibility.

Anyway all said I'd love to buy a MAC to experiment around. But everytime I look at a MAC and I think oh that's not that much more expensive than a PC, I realize that the MAC and the PC often are on a different level of Hardware with the PC having more RAM/Better Video Card/Faster Processor. I see that and figure I'll just go with the cheaper PC.

Re:What?

[RedK]

It is certain your iTunes application will not run in this way.

Have you tried tunneling Amarok in the way you suggest ? Unfortunatly for you, sound isn't part of the X11 specification, so unless you're using something like a sound daemon (a la esound) and have forwarded that also, the result might not be what you're expecting. I don't see why not being able to remotely display iTunes' GUI would be a problem.

Re:What?

[HiThere]

Every *system* has issues, but not everyone who uses every system encounters those issues.

I've got a MSWind95 system that's been running without a hitch for 4-5 years now. I'm not claiming the system doesn't have issues, but it's not being asked to do anything that would activate those issues.

So don't presume that someone is lying if they tell you they don't have issues with some particular system. Just presume that they are limited in what they ask that system to do.

Re:What?

[Johnny Mnemonic]

ssh -X hostaddr application

I've done that, and it works. Why wouldn't it? OS X has X11, just like other Unixes.

Re:What?

[cryptoluddite]

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. ... Yeah, they're more expensive.

Pretty sure if you're going to pay $50k per year on your education then the 'best tool available' is a butler of some kind. If having somebody carry your books and supplies around saves you even a couple hours it's well worth it. Also, they can drop rose petals in front of you... can you Mac do that?

Re:What?

[kamochan]

When it comes to productivity, 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.

WTF are you talking about? You have to do some special trickery to a) get the app to launch on a remote screen, and b) in WHOLE screen mode. When I launch remote commands using ssh from my macbook, I get the X app window on the macbook screen, as one would expect (with DISPLAY=:0) - just like on any sane unix box in existence.

FWIW, I prefer my Linux (and Solaris) in a VM in the mac. No hassle with external screen resolutions, WLAN roaming, switching between wired and wireless, etc.

Re:What?

[kamochan]

And don't forget the VM support. I've never had Windows, Linux, or Solaris be so nicely behaved than in a VM on top of OS X, when the underlying OS handles all the screen resolution switching, WLAN roaming, hw virtualization, etc nasty stuff.

Re:Shouldn't it be called P?

[Anonymous Coward]

Perl is the worst language anybody ever invented, next to mindfuck. It looks like somebody ate C++ and two days later took a huge dump. Why anybody would want to use this abomination of a programming language is beyond me.

Re:Man, you guys have some piss poor excuses...

[mdwh2]

Yeah, because obviously the only alternative to Macs is running Linux!

Some of us value having a nice GUI to back up a solid set of internals without having to waste time and energy on fixing broken drivers and sticking patches on everything so that we can have a computer that does the things we ask of it without making exceptions for this, exceptions for that, patches for this, workaround for that. It's not 1993 and there's more to life than a command line.

So of us had a command line and a GUI way before 1993. Macs didn't even have a command line in 1993, or for years after. Is that the best that can be said of OS X - it has a command line and a GUI? Welcome to 1985.

Re:What?

[GrahamCox]

Well, duh. Yes, they do. I do. With good reason. And so do many others, e.g.: X-plane's secret

A couple of things on Macs. Then D.

[Anonymous Coward]

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:What?

[loufoque]

A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.

My girlfriend owns a mac laptop. From time to time, I use it, since I do not own a laptop but only a desktop computer.
I just find it unusable, even to do the simplest of things. And I've actually spent time to read up on how Finder, Apps, the dock, and all those weird things work.
Really, the only usable way to use a Mac I found is to connect to it with ssh. And it seems it's the case for a lot of other people, too, including Walter Bright.

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.

Or rather, the laptop world is so riddled with crap it is the less bad option.
Basically, there are four choices:
- IBM/Lenovo
- Dell
- Sony
- Mac

Sony is usually not very competitive in terms of quality over price. IBM/Lenovo are the most reliable laptops out there, but they're too expensive. So it's down to Dell vs Mac.

Dell isn't that reliable for a linux setup. They do sell laptops with linux, but they're more expensive, have lower specs, and plainly suck.
Plus Macs comes with one extra: you can run Mac OS X, which can be fairly difficult to do (and also quite illegal) with non-Apple hardware.

So at the end of the day, people choose Mac, especially students since they get good discounts.

Re:What?

[gyrogeerloose]

It is a refreshing change to find that windows doesn't even make the minimum grade for people to bother attacking it.

Windows sucks!

Sorry, but someone had to do it...

Re:What?

[mfnickster]

I just find it [the Mac] unusable, even to do the simplest of things. And I've actually spent time to read up on how Finder, Apps, the dock, and all those weird things work.

I'm curious to know what kinds of tasks you're talking about, because unless you're doing a lot of command-line type stuff, piping things around, there's nothing too difficult about the Mac interface.

Can you give us two or three examples?

Re:What?

[mlwmohawk]

You have to do some special trickery to a) get the app to launch on a remote screen

Nope, it works as done. The ssh system ensures proper X port forwarding.

Re:What?

[jeremyp]

Let's be clear. The limited capability here is the fact that you have to use a kludge like VNC or Apple Remote Desktop to access your computer remotely. Apple (and Microsoft) have ditched this "important feature" in favour of improving the UI experience for the user when they are sitting in front of the computer. And guess what, only a few people ever complain about the lack of this "important feature", the reason being that most of us do not lock our computers in server rooms and access them with X terminals.

It's clear that Apple (and Microsoft) have made the right decision because more than 99% of personal computers run one or other of those operating systems. Your "important feature" seems to be totally irrelevant to 99 and a bit percent of all computer users.

Re:What?

[mlwmohawk]

As much as I like how far Gnome and KDE have come along, they are trailing, and serve only as evidence that NeXT made the right tradeoff 20 years ago.

Besides the fact this nothing more than nonsense, I was talking more about the X layer and how it is exploited by these environments.

Re:What?

[Lars T.]

A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.

Apart from if you want to run the most popular scripting language.

Yeah, you would never have such problems using HP UX or Solaris. Okay, but you won't have problems runnig RedHat

Re:What?

[pohl]

So you're saying that there are zero design wins from not having based everything on X. Really.

Re:What?

[loufoque]

I was actually referring to basic graphical usage there.

The windowing system, where maximizing doesn't work, is just quite annoying, especially for browsing the Internet of stuff like that where fullscreen apps are better. Also the dock should really be set to auto-hide, because it feels very awkward otherwise with fullscreen apps. But then not always having the taskbar (or its equivalent) visible is also quite annoying to me, since I can't tell at a glance all the applications running.
The fact that apps don't stay closed when you close them is another annoyance.
The fact the menu is elsewhere is also quite annoying, since you have to be careful of focus and move the mouse across the screen.
There is also the issue of weird keyboard layout and keyboard shortcuts. Basically all Fx keys are disabled unless you press the Fn key, and everything you usually use Ctrl for you now need to use the Option key instead, which is less practical to press in my opinion due to being more to the right of the keyboard.

I simply find the classical layout, with normal windows and a real taskbar, more efficient to work with, even for simple things such as browsing the web, editing a few text files and sending a few emails.
Of course, I could tune Mac OS X to behave more like I would like to, but that's probably not worth the trouble since I scarcely use it.

Testing my little programs work from ssh is enough.

Re:Shouldn't it be called P?

[x2A]

Depends what you like... Perl's a favourite of mine, probably because of the things you hate about it. It has a very natural feel to it, as the way which it's evolved, like natural spoken languages, there's all kinds of often hidden subtleties, and there's nearly always more than one way to do anything, different ways efficient in different ways and so good for different purposes. Downside of course is it's multithreading support (or rather, lack of it).

I like it for server stuff, as it's real easy to get it to detect when the code on disk has changed, load 'n compile it into memory, and splice it into what's already running... without losing any data structures or anything, and if there's any errors in the code, throw an error, and go back to the previous working version of that module. Without need for any close/restarts.

Re:What?

[kiddygrinder]

Heh, i've had way more trouble getting macs to do usefull stuff than linux. Usually it's a case of "macs don't do that, buy this shareware software to fill the glaring gap in the OS functionality". But just buy whatever you want i guess.

Re:Shouldn't it be called P?

[LokiSnake]

No.

Re:semi

[k8to]

Yeah offtopic.. but..

Even windows thinks a newline is \n, it just stores them in files as \r\n but presents them to programs as \n.

Yes, it's psychotic.

This dicsussion was over some time ago.

Re:Shouldn't it be called P?

[FiloEleven]

I like it for server stuff, as it's real easy to get it to detect when the code on disk has changed, load 'n compile it into memory, and splice it into what's already running... without losing any data structures or anything, and if there's any errors in the code, throw an error, and go back to the previous working version of that module. Without need for any close/restarts.

That's kind of bad-ass. Years ago I took a very brief look at perl and it just didn't look friendly, know what I mean? I may have to give it a second chance one of these days.

Re:What?

[mfnickster]

I was actually referring to basic graphical usage there.

Okay, meaning you're used to something else, and expect the Mac to work the same way?

The windowing system, where maximizing doesn't work, is just quite annoying, especially for browsing the Internet of stuff like that where fullscreen apps are better.

The Mac doesn't have a "maximize" button - it has a "zoom" button, but this is a fair complaint because most apps don't handle it like they're supposed to. It's supposed to toggle between a user-selected state and an app-selected state. (Note to Apple: why doesn't it look like a toggle button?)

Me, I don't worry about it... I just set the window size to what I like, and it stays that way even when I quit and relaunch the browser.

The fact that apps don't stay closed when you close them is another annoyance.

A matter of taste - I hate when apps assume that I want to quit just because I closed the last window. Recent Apple apps behave this way, and it drives me nuts. What if I just want to open a new document? I can't close the existing window until after I've opened another?? Either way, it's not a show-stopper for usability. Is it that big a deal that the app stays open? How does that get in your way?

The fact the menu is elsewhere is also quite annoying, since you have to be careful of focus and move the mouse across the screen.

Again, a matter of taste. To me, the menus in Windows are "elsewhere", which is quite annoying. You still have to click in the window to use the embedded menu, so it's not that different from clicking a window to gain focus. Maybe one extra click if you don't know keyboard shortcuts or use contextual menus.

There is also the issue of weird keyboard layout and keyboard shortcuts. Basically all Fx keys are disabled unless you press the Fn key

That's a new one. It used to be function keys worked like function keys, until Apple decided that controls for volume, brightness, and Expose were more important than program functions.

and everything you usually use Ctrl for you now need to use the Option key instead, which is less practical to press in my opinion due to being more to the right of the keyboard.

Saying you "usually use Ctrl" is Windows-centric, but even so, on my keyboard the Option key is right next to the Ctrl key - not that big a leap.

I simply find the classical layout, with normal windows and a real taskbar, more efficient to work with

The "classical" layout is Mac style, it was Windows that took a different approach to the GUI. Basically all your gripes are minor things that annoy you because you learned something else first. That doesn't necessarily make the Mac way "wrong," it's just different than what you're used to. Trust me, to someone who learned on a Mac, these are not hindrances at all. If you learn some keyboard shortcuts (such as Command-Tab to see open apps and switch between them) you can be very efficient on a Mac.

Sorry if you don't enjoy using a Mac, but as someone who has to work with Windows, Mac, and X11 interfaces every day, and know what to expect on each, I just don't see this as a tough nut to crack.

Re:What?

[kamochan]

Ah, the classic X client-server confusion - my local (where I am sitting) means your remote :)

D vs C#

[bensch128]

i hate to troll but after looking at a comparison of C# syntax vs D syntax,
I get the feeling that they were both invented to be the "GC'ed, nicely templat'ed, clean syntax"
upscaling of C++, similar to what C++ was to C.

However, C# has the backing of M$ and D doesn't.
So in my mind, unless a miracle happens (like Qt turns out to be the primary GUI of choice for D and WPF turns out to be a REALLY bad idea)
D is dead in the water.

Disclaimer: I have tasted the white lines of C#+WPF and let me tell you, it is 100% pure coding goodness.
I dislike M$ as much as the next person but when it comes to getting the job done, C# delivers strongly.

Re:D vs C#

[WalterBright]

Is C# on the Mac?

Re:D vs C#

[Haeleth]

This article is about the language being ported to the Mac.

Remind me, when is the Mac port of WPF due out?

Re:D vs C#

[bensch128]

I've no idea.

WPF is a pretty good GUI system, very configurable.
I think there's a project to porting it (olive) but it looks like its moving verrrry slowly..

Runtime design considerations

[argent]

Why would you try to use the header files from FreeBSD on Linux? The point of standard headers is that code can be written to an abstract interface exposed by the header files. When you move from one platform to another, the code works, even though the expansion of the macros is different, because the code does not make assumptions about how those macros are expanded.

Someone else suggested that you're trying to avoid redundant calls from D to C, but I suspect that you would in the long run end up with a faster and cleaner system by bypassing the stdio overhead completely, and calling read(), write(), and so on directly. The C runtime has an awful lot of historical baggage that you shouldn't need to carry over to D.

What happens when someone wants to use D on a platform that uses a glibc alternative, like uClibc? Do they have to hand-hack a new runtime?

Re:Runtime design considerations

[complexmath]

Although D apps can call C functions, D code can't directly use C headers files. So relevant declarations much be replicated in D if you want to use C stdlib routines. And since D does not use the C preprocessor, the structure of these headers often needs to change from C to D. So to answer your question, the user doesn't have to hack a new runtime, but they may have to create headers properly declaring the stuff they intend to use.

This process is pretty straightforward and mechanical, but the C preprocessor is sufficiently evil that it would be difficult to automate without creating a full C compiler that outputs D code. And I don't think this is the best approach anyway, since a lot of what's in these C headers isn't even needed for someone intending to use the library. Much of it is there for the library implementation itself.

Re:Runtime design considerations

[argent]

OK, I think we're talking at cross purposes.

What I mean is that instead of converting the C header files to D header files, you would create a C wrapper for anything that's a macro that's called from D. That way the D code never has to deal with the results of the macro preprocessing. Yes, you'd have to have a set of declarations for the C code, but those should be based on the public API rather than the internals of the include file... and should be platform-independent.

I'm not saying that there wouldn't ever be any need to modify these D declarations, just that it seemed really odd to be in a situation where you care about the details of a macro expansion.

Re:Runtime design considerations

[WalterBright]

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.

Re:Runtime design considerations

[WalterBright]

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.

Re:Runtime design considerations

[argent]

Hmm, I see what you're getting at. When I've dealt with this in the past, I've written a C program that included the #include file and wrote out a file in the target language (in my case it was Forth). For example:

#include <sys/ioctl.h>
 
ioctl_dump()
{
    printf("const int SIOCADDRT = 0x%04X;\n", SIOCADDRT);
    printf("const int SIOCDELRT = 0x%04X;\n", SIOCDELRT);
    printf("const int SIOCRTMSG = 0x%04X;\n", SIOCRTMSG);
//...
}

Obviously you'd use automated initial generation of this table, but once it's done it would be portable, because you would be using a full C parser. :)

Re:Runtime design considerations

[argent]

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.

But the D import file can't directly include any of the complex C macros in any case, right? SO the translator could use the C compiler itself to perform the translation... I had to do something similar for mapping C header files to Forth source code some years back.

Re:What?

[pdbaby]

Even their low-cost machines like Macbooks and Mac Minis are pretty beautiful. Compare it to the design of a lot of other small PCs - there's too much going on. The mac mini design is so elegant and minimalist - like all Apple's stuff, as the AC beside me says, they spend a lot of time throwing away stuff you don't *need*. Boiling things down to their essence is a difficult job.

Re:Another programming thread.

[Eli Gottlieb]

3. Usually some college kid with a semester of CS pops by and writes several pages about how sad it is that everyone is using high level languages and wasting all the processing power of the computer. Also, how they're using Linux instead of Windows (because Linux is written in C) and how it is much faster. All this without realizing that the browser they're writing it in probably has significant portions written in Javascript.

See this one? This is you! You really think no systems language can ever best C?

Re:What?

[W2k]

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.

Either that, or the Windows users are busy actually getting work done while the mac/linux fanbois fight their pointless religious wars.

What's the point of "attacking" any OS to begin with? If you're content with what you use, good for you. I couldn't care less if you prefer Xenix or DR-DOS.

Re:What?

[Dog-Cow]

The behavior of the function keys is selectable in the Keyboard Preference pane. The default actually makes much more sense when you realize that most Mac software does not make heavy use of the function keys. I suppose software like Office might, as it comes from the Windows world, or maybe Photoshop, which may just need zillions of shortcut keys. I don't use either, so I wouldn't know.

Re:Shouldn't it be called P?

[immcintosh]

+1 Insightful

If anything ever deserved to be thrown into the pits of Mount Doom...

perhaps I know the wrong people

[Trepidity]

I know precisely zero people who use OS X as a Unix, though. Many of them were indeed classic Mac users, and most of the rest still use the classic-Mac all-GUI workflow, which is still the one Apple mostly promotes, especially on the desktop.

Re:perhaps I know the wrong people

[mdwh2]

I never said that OS X was Unix, I said it wasn't classic Mac OS. Sure, I'm sure there exist OS X users who were classic Mac users, just as there are OS X users who were Amiga users, or Windows users who were classic Mac users or whatever else. I don't see why this means OS X users should hate ssh-ing.

Although now that I think of it, yes, it does fit in with Apple's "it's better to treat the user like an idiot, and let's frown upon any other way of doing it, even if it might be better".

Re:What?

[RCL]

That's the problem with Mac software: it can't accept the fact that UI guidelines are now being written by Windows world. Not being compatible enough with Windows UI behavior means nowadays being unusable for 90% of people (those accustomed to Windows + those accustomed to Windows-like X desktop environments)

(And as a sidenote: having menus right at the window relieves you from scrolling to the top of the screen after you set focus to that window. Screens are quite large these days).

Re:What?

[mfnickster]

To quote Michael Bolton in Office Space:

"No way. Why should I change? He's the one who sucks!" :)

Re:What?

[RCL]

Well, I'm a (relatively) young man, but also have a worrying tendency to resist changes :)

Joel(onSoftware) has a nice article about what makes things usable and unusable (rule of least surprise IIRC). Too lazy to look it up now, but it could explain why Mac can be both usable (for you) and completely unusable for OP.

Re:What?

[mfnickster]

> Joel(onSoftware) has a nice article about what makes things usable and unusable (rule of least surprise IIRC).

Joel has some good insights, as did the original Mac OS designers. But forgive me for saying that if these little design differences are enough to make an OS "unusable" to him, perhaps computing isn't a good career choice for him!

D for complexity

[owlstead]

D is the language that tries to do it all. And - because of that - it fails for many projects out there. I would hate to take over a project from an experienced D application programmer; you are bound to have to learn an endless number of techniques. D will appeal to many former experienced C++ application programmers, but I would not recommend it for organizations. IMHO, C# and the .net framework is seriously trying to fall into the same trap. Java is one of the few languages that is still pretty clean, and even that now has generics put on top of it (without runtime support). With that respect, not many languages have learned much from C (and possibly Pascal).

If I would use it it would be as a C++ replacement for small projects, especially those that fit to its features.

copy vs reference

[krischik]

Consider:

String A := "Hello";
String B := A;

B.append (" World!");

What should A be and what should B be? Note the "should" and ":=" - I am not talking about any particular programming language. Say you see this code in an unknown programming language what would be the first expectation for A and B?

Mine certainly would be A is "Hello" and B is "Hello World!".

And String is a complex class and certainly is not used only 0.001% of all cases.

Martin

refrence counting

[krischik]

I have another one for you.

when the GC detects 0 references, b is discarded.

Actually a good GC will discard reference objects. Consider:

Some_Class_1 A;
Some_Class_2 B;
Some_Class_3 C;

A.My_B := B'Access;
B.My_C := C'Access;
C.My_A := A'Access;

What should happen when A, B and C go out of scope. A CG based purely of reference counting could not delete them as each of the elements still got a reference count of 1.

Advanced GCs of course will detect when a ring structure becomes an island and will deallocate the complete ring. But: finding a ring structure is a complex task which can not be done at every block closure.

OS/X is certified.

[krischik]

http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server

Re:semi

[azav]

Yes, but is normally the default condition that the end of line terminates the command? Is this the case most of the time?

Re:What?

[roc97007]

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

I agree wholeheartedly. And if it were only an extra $100, my house would be full of Macs. We have one Mac for the stuff that runs best on the Mac. (Anything by Adobe, Garage Band, etc.) We also own three laptops. I've never paid more than $500 for a laptop. The last laptop I bought (mid-February) was right around $350 new in box preloaded with Vista Home. And I'm here to tell you, the very moment Macbooks are in that price range, Microsoft can kiss my shiny metal ass. But until then, well, we have one Mac. For the stuff that runs best on the Mac.