Linux: still better for coding
antirez.com
antirez.com
Besides, if I would replace the OS with Linux anyway, what's the point of buying an Apple?
It's still lightyears above any Windows setup, of course. Especially for the common guy.
I'm not looking for an OS-fight, but why make silly claims like that? There are a lot of smart and highly productive people who choose Windows, and if you've been using Linux since 1996 you probably don't know much about modern windows dev setups.
Not exclusively.
API stability is a question of the framework, I suppose. Objective-C as a language isn't really in the same league as C as far as API stability, because it's fairly easy to deal with evolving parts in a semi-dynamic language. Perhaps that is why Apple is more careless when it comes to changing things.
Package management has a place in my heart, too, though. I have seen many attempts to do this that fall far short, and not just on Mac OS X. I suppose what I'd really like is something as powerful as apt-get, but merged with some kind of App Store; and I hope that Apple is working on such a thing.
Ubuntu is creating this. It's called the Ubuntu Software Center:
Works with OS X nowadays. Plus, Xcode has the benefit of Clang's Static Analysis being built right in. You really can't beat checking one box and having it automatically scan over your code when you build to point out a lot of mistakes (like leaks or logic that's never hit). True, different purposes. But, you can install Valgrind. And in the meantime, Clang will catch some things for you, before you have to find them with Valgrind.
// edit: Whoops, I was wrong: Valgrind doesn't work on Snow Leopard yet, like I initially thought.
Apt-get
If you're targeting another Mac system, do you really want to ship your own version of Tck/Tk? Do you really want to use a custom library for your own development and another for shipping? Or do you want to use the one the system provides? Hint: The latter allows for much smaller downloads. Lets the user start using your software much quicker.
API stability
Theres applications out there that work on PPC and 32/64bit Intel, on any OS from Jaguar on. 7 year old applications that still work perfectly fine, across OS's that have had major changes, seems to be pretty stable API-wise to me. Not to mention, there are API's that have been deprecated since 10.3, but can still be used (even though you really shouldn't use them) in 10.6.
/proc filesystem
See the `sysctl` command instead. Bonus: You can access all this information with a sysctl() call in code too!
Compiler
Given Xcode ships with gprof, I'd be highly surprised if it doesn't actually work. And theres always Shark, that can be run without having to add special profiling flags when compiling. Or Instruments (ie: DTrace).
As for -arch i386 not working? Thats just not true.
bash:~ Zach$ gcc -arch i386 foo.c -o foo
bash:~ Zach$ file foo
foo: Mach-O executable i386This is certainly what I try to do, as well. However, it is not for the faint of heart. For instance, I had to be extremely creative in order for my app to use the system Python, and yet work correctly (it was bound to C++) on Mac OS X 10.3.9 through 10.6.
10.3.9 was especially interesting because it doesn't support universal binaries either. :)
About -arch i386, sorry my English is poor, what I mean is, gprof is not working even with binaries compiled with -arch i386.
Edit: forgot to mention that there are things in Mac OS X that are missing on Linux and I like a lot. For instance dtrace and leaks. Leaks is really cool since it can check memory leaks at run-time with a standard executable, and works very well.
Thats still wrong:
247:~ Zach$ gcc -pg -arch i386 foo.c -o foo
247:~ Zach$ file foo
foo: Mach-O executable i386
247:~ Zach$ ./foo
hello
247:~ Zach$ gprof foo
call graph profile:
The sum of self and descendents is the major sort
for this listing.
function entries:
[rest of the output snipped, I can pastebin if you want.]
However, you are right about Valgrind not working on Snow Leopard yet. I had thought it was working by now. Whoops, on my part. I edited my first post.
Thanks for the hint about Shark, I'm playing with it and it seems cool indeed.
That's the story of OS X since from when it was first released. For example, you'd have some functionality advertised as being in the system libraries (like, oh, certain important pthread functions) so they'd pass the configure checks, but they would be in reality just stub functions that mean nothing. So your program would subtly fail.
That particular problem was fixed in 10.1, but it seems like every release has a few things like that: something from UNIX that looks like it's there, but actually amounts to no-ops. It's maddening.
* Shark
* Instruments
* dtrace
* leaks
* TextMate
* Spin Control
Boost's unit test library has memory leak detection built in, and Intel's performance analysis tools integrated into Visual Studio utterly trounce Valgrind. ICC embarrassingly outperforms GCC.
Linux development is still way the hell behind, and if the article's to be believed, apparently blissfully unaware.
Gotta figure someone was going to chime in with the Microsoft IDE love though.
Linux: still better for coding in C
[EDIT] To clarify, the article is specifically discussing issues with developing native programs on OSX which do not apply to developers in many other languages.
You wouldn't have mentioned it if you hadn't run into problems, so I would imagine there are probably some pretty rough edges around native libraries. As such, I considered that those comments must also be specific to native programming.
TextMate is considered the canonical rails editor for a reason.
Nowadays vim (or MacVim) seems to be the preferred editor, at least among the top rails blogging crowd. It's hard to beat tpope's rails.vim (http://rails.vim.tpope.net/).
Agreed on the preference of vim, but I wouldn't knock de facto standards. I bet most people use the idiomatic NULL=0 in conditionals [if(possiblyNullPtr)] just because K&R did it.
And if you dig a little, can't you find most of the stuff that is in /proc?
I suggest digging a little more.
About macports, I specifically mentioned find and homebrew, but just this are not the same quality of apt-get and many things are missing.
What the fuck are you smoking? Mac OS X has by far the most stable APIs of any modern development environment. They change existing APIs and add with every major release -- but they do so in a new SDK. Apps that were linked against the 10.4u SDK use the 10.4u libraries, even on 10.6. This is fucking amazing.
The only way Win32 stays as stable as it is is by just not changing anything or even adding new APIs.
For instance I compiled nmap yesterday for snow leopard, and guess what, it was not working, unable to open the interfaces. The compiled binary I downloaded from insecure.org worked against the loopback interface but not against the wifi one. The interface to capture raw frames from the airport extreme changed again with snow leopard, breaking valuable programs like Kismac. It's not an open platform so this changes are even worse.
Now you're effectively complaining about Kernel ABI compatibility!
What the hell are you talking about? Vista (and to a lesser extent Windows 7) have tons of new APIs.
Apple does not have a 64-bit version of Carbon. Name one Win32 API that is similarly broken.