Core Mac OS X and Unix Programming

Michael McCracken writes "Finally, a new OS X programming book that isn't just another introduction to Cocoa. This book adds a lot to the available references by covering the system as a flavor of Unix, presenting information on important topics like sockets, multithreading and pipes, which other OS X books leave out. It also includes coverage and sample code for some of the unfamiliar new technologies that have been introduced recently, such as the Keychain, Rendezvous (aka Zeroconf), and using the Security framework to authorize users." Read on for the rest of his review. Core Mac OS X and Unix Programming author Mark Dalrymple and Aaron Hillegass pages 541 publisher Big Nerd Ranch rating 9 reviewer Michael McCracken ISBN 0974078506 summary A developer's guide to the Unix foundations of Mac OS X, including coverage of recently added technologies. Includes complete source code and online companion material.

If you've been learning Mac OS X Cocoa programming, you might already know Aaron Hillegass through his excellent book Cocoa Programming for Mac OS X, which was one of the first good introductory books on the topic, and is still one of the best available. Information about this earlier book can be found at bignerdranch.com/Book/. Both Aaron and Mark are instructors at the Big Nerd Ranch, which offers courses in Mac OS X programming. More information about them and the courses can be found at http://www.bignerdranch.com/Company/Who.html. This book is based on the course with the same name at the Big Nerd Ranch. The book's website and a link to order it online can be found at borkware.com/corebook/ . Discussion and further information for both books can be found at cocoadev.com/index.pl?CocoaBooks.

Audience and Writing Style This book is not an introduction to programming on OS X. It doesn't explicitly cover how to use Apple's Project Builder or Interface Builder, or much of the Cocoa or Carbon APIs, except during discussion of code examples. So if you're entirely new to programming or to using Mac OS X, start with a different book such as Hillegass' earlier Cocoa Programming for Mac OS X to get up to speed with using the development environment. This book will leave you behind at times if you are unfamiliar with using the command line, however, the examples are complete enough to follow along by just typing in what's in the book.

Core Mac OS X and Unix Programming does have some very basic material in its first few chapters. They focus on the details of C programming, using the compiler, memory management, and debugging. These chapters will be mostly review for anyone who's developed in C on Unix before, but will be invaluable for programmers who learned to program using Java, for instance. They should also be required reading for programmers who started programming with Objective-C and Cocoa and are still unsure about using "plain" C. If you've ever complained about having to use a C API from CoreFoundation in your nice pure Cocoa application, don't avoid this book -- you need to read it even more.

The book is clearly written and easily understood. The writing is occasionally conversational, in keeping with its history as a course textbook. In the grand history of well-written technical books, it is also occasionally funny. The authors don't try to sell the technologies they discuss, instead giving practical advice that's useful to a programmer who is trying to actually build something. For example, the authors discuss bugs and inconsistencies in the system, clumsy API design and other problems that aren't great ad copy but you will need to know to develop robust applications.

I found this aspect of the book one of the most appealing, that it felt as though I was actually getting down to business. Gems of practical advice that can cut short frustrating problems appear throughout the book, so be sure to read carefully, don't just skim.

Hits Here I'll discuss a few examples of where I think this book really shines. First, the level of detail of the standard Unix APIs and the development tools is excellent -- I learned many immediately useful things in the first 13 chapters. For example, chapter 8, "Debugging With GDB," was not simply a repeat of the online help, but also contained useful tips about how to use GDB more effectively, from using Objective-C specific features to tracking subtle memory errors. Programmers who had only used Project Builder's interface to GDB will benefit greatly from this chapter.

Next, there is pervasive sample code. Each chapter had a complete sample program demonstrating the topic at hand. Much of this code is also available online: see "Online Supplements" below.

Finally, as I mentioned before, the text contains tips and reminders throughout about potential mistakes, tricky problems, and differences between Mac OS X, OS 9, and other Unix flavors. A particularly useful example of this is in chapter 24, "CVS." There is a small but important paragraph that discusses using CVS 1.11 (as used in Sourceforge) with Interface Builder .nib files that can really save some grief. In other chapters, they even include workarounds for system bugs in some of the sample code. This pragmatic approach is really appealing.

Misses In this section I'll mention a couple potential disappointments. You will have to be willing to learn by just reading code at times. Most of the code examples are not explained line-by-line as is the custom in tutorial books. Comments explain tricky code, and the text covers the areas most relevant to the chapter topic, but for other sections, understanding is up to you. I mentioned this because although I feel the code is clear and a fair trade-off was made to fit in a lot of information, the amount of explanation you like is a matter of personal preference, and so you should know what to expect.

Pointers to further reading is another problem. Aside from referring to man pages, there is little attempt to point to good external documentation on any of the more complicated topics. One chapter is not enough to completely cover BSD Sockets, for example, and so a reference to a Unix network programming book would be useful. In fact, every chapter could be improved by a references section, even if it only collected links to Apple online documentation or Unix community websites. With all the practical knowledge in this book, the lack of clues on where to look to answer your own questions was disappointing.

Finally, the cost of the book, at $97.95, is higher than you might expect. I admit that as a student, I would have to think twice about paying this price, although I am sure it would be easily justifiable for professional programmers. I believe that it is worth the price, however, because you would have to buy several other books to cover the same range of topics, and you still wouldn't get the Mac OS X specific information.

Online Supplements

The authors have set up a promising resource for the book at http://borkware.com/corebook/ . The site includes the sample code, errata, reader comments indexed by the chapter and topic they refer to, and a general discussion board. There are already some errors listed, and a few pointers to useful documentation and interesting external discussions on mailing lists. The sample code is not complete at the time of this review, but more is being added. This site looks like it will be a useful addition to the book, especially if many good chapter-indexed comments are added. The site could be kept open as a reading companion while going over a chapter in the book. This site's organization is, in my opinion, much more useful and usable than other books' companion websites, including the site for "Cocoa Progamming," which hid its information from you unless you knew which page number was relevant to your topic.

Conclusion Core Mac OS X and Unix Programming is a very useful book, and even if you've been developing on Unix systems for years, you can probably learn a few immediately useful things by reading it. I recommend it for any serious Mac OS X programmer who wants to know what to read next after all the tutorials that have come out in the last year or so. I suspect it'll become a canonical reference, and may even be in need of a clever nickname. Congratulations to Mark and Aaron on a job well done.

Michael McCracken is a grad student and Mac OS X developer; he says "I have not attended any Big Nerd Ranch courses, nor have I met either author, although I did see Aaron Hillegass in a crowd once." Update: 07/02 17:36 GMT by T : According to publisher AtlasBooks, bn.com won't actually be carrying this book, but you can get it right now from Atlas. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Whoa

[Anonymous Coward]

Be careful, you might actually teach them some good programming techniques.

Re:Whoa

[Anonymous Coward]

who the fuck is moding up this parent statement?

Re:Whoa

[Anonymous Coward]

That would be people with a sense of humor(or humour for our English friends). BTW, it's modding, not moding.

Microsoft port

[SolidGold]

It is interesting to note that Microsoft in a previous article said that they had no intention of porting Office to Linux right now, but being that they have ported it to OS X most of the work has already been done.

Re:Microsoft port

[Anonymous Coward]

Correct. They had an interest to go to Mac, but they don't have one for Linux.

Even if the work is done, they know it would be corporate suicide. Office is really the only thing that's holding them afloat. Once a truly viable alternative becomes available, then MS becomes irrelavant.

"But, but, but... What about [insert any of the OSS Office apps]?!" They're not "good enough." People want familiarity and the ability to interact with others w/o worrying about compatibility. Nothing else does that. Period.

Re:Microsoft port

[christurkel]

It would think its closer to a FreeBSD port with you port to Mac OS X. I could be wrong, however.

Re:Microsoft port

[Halo1]

MS Office is a Carbon app. There's no carbonlib for any *nix except Mac OS X out there. Porting it to Linux would mean either porting carbonlib (i.e. a cleaned up version of the legacy Mac OS api + extensions) to Linux, or rewriting it from the ground up (just like the Mac OS X version is almost a complete rewrite compared to the Windows version).

Re:Microsoft port

[Anonymous Coward]

Yeah exactly, because we all know that Linux has the same Carbon or Cocoa APIs available that Mac Office is undoubtedly built on... err... hmmm.... wait a minute. Well, so they'd have to redo the UI, but that's not a majority of the work they did in making an OS X version in the first place... er... hmmm... wait a minute.

Re:Microsoft port

[PhysicsExpert]

Yes but have you ever used MS office on OSX, it is slow and incredibly buggy (jokes about microsoft aside office on XP is rock solid) and that's with standard hardware and a fast RISC processor to work on, imagine what it would be like under Linux with all sorts of random hardware thrown in there. The real reason they won't port office to Linux however, isn't about speed or reliability but simply because Office on Linux just wouldn't sell. Most Linux users realise that there are good free alternatives like star office and open office which are just as good as Microsoft without needing you pay extortionate prices. Office on Linux would be a commercial nightmare.

Re:Microsoft port

[Anonymous Coward]

I you'd know what you are talking about... Most of Office is Carbon, so technically, no work has been done to port Office to Unix. None.

Re:Microsoft port

[Dashmon]

Ehm. Native OS X (Cocoa) apps really aren't very close to Linux apps. First of all, they're written in Objective-C, and that'd make it *harder* to properly integrate stuff in GNOME or KDE, I think. But most importantly, the Office ports for OS X use the whole NS (NextStep) framework Apple developers use. There is no way you'll get that ported to GNU/Linux (closed source), which means you either have to use a replacement that hardly works correctly, like GNUStep, or you'll have to build your own libraries. In other words:

It's faster to start with the Windows code than to start with the OS X code.

Same applies to porting MS Office to BSD, or whatever.

Fortunatly... we don't even WANT Office. Do we? :P

Re:Microsoft port

[Gherald]

M$ doesn't have a whole lot to fear from Mac OS X because it *only* runs on PPC.

But if they developed Office for x86 Linux, Linux popularity on the destkop would rise enough to hurt Windows sales.

Re:Microsoft port

[Dashmon]

Just read Office for X is a Carbon app, not a Cocoa one. Sorry, but I've never used Office for Mac (thank God). Same still goes, only for Carbon, though.

Re:Microsoft port

[Graff]

Microsoft in a previous article said that they had no intention of porting Office to Linux right now, but being that they have ported it to OS X most of the work has already been done.

Actually that's not quite true. Microsoft programmed Office for the Mac using the Carbon API and libraries which are part of MacOS. This is a set of APIs which are completely proprietary to MacOS and which bring a program no closer to Linux than a program which uses the Windows API program does.

The only way in which doing a MacOS port of a program brings it closer to doing a Linux port is most programmers doing a port tend to separate out the parts of the program which rely on a particular operating system from the parts that are platform-agnostic. Thus you will most likely end up with a large chunk of the code which can be re-used to add a front end for any particular system type. This is not a requirement for a port however, it is just smart programming. In fact, it is even smarter programming to do this in the first place. Microsoft may or may not have done this, but I'm doubting that they did. From what I understand they basically program the Mac versions of their programs from nearly the ground up.

In programming the Myth series of games, it was often said by the developers at Bungie that the platform-agnostic parts of the games took up about 90% of the code, while each port took up 10% more. So for a 10% investment in additional coding you could sell the game to a another platform. This requires a bit of planning but it is a much better way to program than to do one version for one platform and then have to completely redo you work to get it to run on another. Finally, there is another great advantage to doing multi-platform programming. Often a bug which doesn't show on one platform will show up on another, allowing you to clean up any possible problems before they get you into trouble later on.

Re:Microsoft port

[Coward the Anonymous]

"The real reason they won't port office to Linux however, isn't about speed or reliability but simply because Office on Linux just wouldn't sell."

It would sell more than you think. For companies that want to move the corporate desktop over to GNU/Linux but feel that OpenOffice and the other alternatives aren't fit, it would sell like hotcakes.

Re:Microsoft port

[cant_get_a_good_nick]

PCODE on Linux, YAYYY!!!

Jokes aside, how much PCODE is still left in Mickeysoft products?

Re:Microsoft port

[Anonymous Coward]

I would think that porting Office to Linux would validate the platform, it would be a message from Microsoft that they believe enough in Linux to support it. Porting Office would allow even more people to switch FROM Windows; and that would be the start of Micrsoft loosing control.

Re:Microsoft port

[ipjohnson]

actually I have office for OS X and it actually seems to run fine ... very well if you consider I have 466 G3 ibook.

Re:Microsoft port

[jeremyp]

I use it every day. With the current patch level (10.1.3) it's not slow (any more so than any other OS X app) and it's not buggy - well I've not seen any.

Re:Microsoft port

[Mr. Show]

The real reason they won't port office to Linux however, isn't about speed or reliability but simply because Office on Linux just wouldn't sell.

Microsoft has an effective monopoly in two areas: operating systems and office software. They are also the only two divisions within Microsoft that are profitable, and support all of their other ventures into PDAs, game consoles, set top boxes, smartphones, and on and on. Office on Linux might not sell to college kid hackers running Linux on their Alienware machines, but Office on Linux would be a powerful incentive for corporate customers to seriously consider rolling out Linux desktops in the enterprise. Therefore, Microsoft will never port Office to Linux.

Re:Microsoft port

[mashx]

Slow and buggy?

Office 2001 yes (via Classic), Office v.X no. And it is so much nicer to use than on XP, even if that is (I agree) solid.

Re:Microsoft port

[VAXGeek]

When you start with "Ehm", make sure to actually be right or else you look pretty foolish.

Re:Microsoft port

[larry bagina]

how the fuck do these "it runs on MacOSX so it could run on linux" posts get moderated up?

Last time I checked, MS Office, QuickTime, PhotoShop, et alia were not command-line only, posix-only applications.

Anyhow, shouldn't you be spouting that gimp, open office, and mozilla are better applications?

Re:Microsoft port

[BigBir3d]

Ah yes, but everyone wants to pay OOo prices don't they ;-)

Most equate open aource to being free of charge. To quote other /. posters; "Joe Sixpack just wouldn't understand."

Re:Microsoft port

[Anonymous Coward]

Worse than just a Carbon app. MS Office for Mac is written using WLM (Windows Compatibility Layer for Mac - pronounced "will am"). This was Microsoft's idea for single sourcing office for Mac and Windows back in the early 90s.

They have long since given up the single source idea. The Mac BU has their own copy of Office Source. However, it is still written using bastardized Windows API on top of a Carbonized WLM.

The whole thing is a mess. There is basically a zero chance that they are going to pick that up and port it to Linux. If they decided they wanted to port it to Linux, they would be better off buying something like ThinkFree Office to be the basis of the port (for several reasons). In fact, *if* they were going to port to Linux, they'd probably do just that.

I used to be a Mac developer there.

Re:Microsoft port

[_fuzz_]

This is a set of APIs which are completely proprietary to MacOS and which bring a program no closer to Linux than a program which uses the Windows API program does.

Actually, a program using Windows APIs is much closer to Linux because of winelib.

Re:Microsoft port

[EelBait]

Oracle has already "validated" the platform, as has Sybase, etc. MS will move to Linux kicking and screaming the same way they were brought to the Internet. Heh, I wonder if when that happens MS will claim to have invented Linux the same way they did the Internet.

Re:Microsoft port

[Read Icculus]

Does that also apply to "Um", and "Huh"?

Re:Microsoft port

[Flywheel]

Quite right, Windows is CONTROL - it is the base on which everything else floats.

But if hell really does freeze over, then Redmond will go the .NOT way ... they will not port the applications to Linux, they will port their proprietary .NOT framwork - that will allow them to keep most of the control.

keychain

[el stevo]

keychain has been a part of the mac os since OS 8, albeit not it it's current unix-ized form

Re:keychain

[scrod]

albeit not it it's current unix-ized form

So how did the keychain suddenly become "unixized"? It's still a part of the Carbon API.

Does

OSStatus KCFindAppleSharePassword (
AFPServerSignature * serverSignature,
StringPtr serverAddress,
StringPtr serverName,
StringPtr volumeName,
StringPtr accountName,
UInt32 maxLength,
void * passwordData,
UInt32 * actualLength,
KCItemRef * item
);

look unixized to you?

Re:keychain

[pudge]

Actually, it was 7.5. Keychain was a part of PowerTalk, and died with it, to be resurrected later on its own.

Re:keychain

[Creepy Crawler]

You forgot:

#include

Re:keychain

[Creepy Crawler]

Dammit SLASHDOT.

#include <make_it_look_like_unix.h>

Re:keychain

[markd]

The Keychain API shown in the book is the Security Framework version (SecKeychain*)

Re:keychain

[el stevo]

a little bit, yeah ;-)

Re:keychain

[Anonymous Coward]

I'm not a programmer, so I would have to say it looks very much like Unix to me: ie. "That's greek to me" "May as well be chinese" "It's savage gobbledegook"

Re:keychain

[The_DOD_player]

... it looks quite Microsofty to me...
Huge,and ugly structs and argument lists..

Re:keychain

[scrod]

... it looks quite Microsofty to me...

Where do you think the inspiration for the MFC came from, anyway? The Mac toolbox (which has since evolved into Carbon) had this awful, awful style long before Microsoft adopted it for their Win32 APIs.

Re:keychain

[Anonymous Coward]

Keychain dates back to System 7 Pro from 10 years ago. A little ahead of its time, eh?

Re:keychain

[fiftyvolts]

Perhaps, but when one used these APIs you got all the "neato bells and whistles" from apple for free. For example if one were to take a well coded (i.e. using the afore mentioned APIs) mac app written for system 7 before the many enhancement to the menu and scrolling system and run it on OS 9 it would basically get the updated UI for free. Apple was (and still is, in my opinion) the king of abstracting the API and the underlying framework.

Very much unlike the win32 API counterpart where sometimes the APIs change so drastically without warning even developers at MS can't keep up. (I've been told by a friend I have that works with Microsoft that by far this is the most prevalent reason for their bugs.)

Re:keychain

[fdobbie]

Actually, this is a wrapper around the lower-level keychain implementation in Security.framework, for example:

OSStatus SecKeychainAddInternetPassword(SecKeychainRef keychain, UInt32 serverNameLength, const char *serverName, UInt32 securityDomainLength, const char *securityDomain, UInt32 accountNameLength, const char *accountName, UInt32 pathLength, const char *path, UInt16 port, SecProtocolType protocol, SecAuthenticationType authenticationType, UInt32 passwordLength, const void *passwordData, SecKeychainItemRef *itemRef);

Which is opensource (well, I haven't actually checked, but the rest of Security is) and could therefore in theory be ported to other *nix flavours.

Re:Paragraph Intros

[Anonymous Coward]

I suppose you are correct, but who really cares? It really doesn't say much about your reading skills that you can't skim through bad writing, get the gist of things, and leave it at that.

Re:Paragraph Intros

[sporty]

No, we won't mod you down. We'll tell you. You are nit picking. All it says about his writing qualitiy is, that he was nice enough to review the book. This is slashdot. It's relaxed and depends on contributions from people.. a lot.

Unless you have something nice to say, say nothign at all. And unless he made a flagrant error, I suggest just commenting on the book. /trogdor

C'mon!

[Anonymous Coward]

You can't be "unfamiliar with the command line" and a programmer. Pick one.

Re:C'mon!

[Anonymous Coward]

Sure you can. Mac people haven't needed a "command line." Converts from Windows don't need one either. I'm a professional Windows programmer, and I don't use the command line.

Re:C'mon!

[GoofyBoy]

Its about Macs and their own universe.

These people are both "GUI users" and are "unfamiliar with a second mouse button".

How wacky is that?

Re:C'mon!

[Anonymous Coward]

Ah.. a Professional Windows "programmer".

Re:C'mon!

[Anonymous Coward]

Yes, a "programmer." This is my first Windows job. Previously, I've written apps for HP-UX, Solaris, Linux, FreeBSD, BSDi, NT, and SGI.

After being laid off twice in a year, this was the only gig available.

Re:C'mon!

[bladernr]

I have found the command-line essential, even when programming Windows. Even though the Mac (a system I have never been a developer on, but may learn) has a terrific UI, leaving out the command-line would be a mistake, and the author was right to include that content.

When programmers are beginning, it is easy to avoid the command-line altogether, since their projects are probably simpler. I imagine that the author's previous books on introductory topics focused on the GUI.

I am a software professional as well, and specialize in large distributed systems and massive-parallel (I can never spell that word) processing. No matter how good the tools, you can never escape from the command-line for complex systems.

Its been a long time since I've developed single-tier, single-user apps, so perhaps my knowledge of tools in those areas is dated, and you can develop those without command-line usage. Someone else will have to educate me on that.

Re:C'mon!

[Anonymous Coward]

Why the hell do people keep saying that about most Mac users? The simple fact is, most Mac users will replace their mouse with something more suited for their function - be it 2 button, 2+wheel, track, etc.

Re:C'mon!

[Anonymous Coward]

Actually, I'm writing Delphi apps. Very fun stuff. Interfacing to an AS/400 DB2 core w/ Interbase and SQL Server. Writing business web apps.

Most fun I've (legally) had at a job.

Re:C'mon!

[Anonymous Coward]

So you do know how to use a command line then?

I think you just drove my point home.

Re:C'mon!

[Anonymous Coward]

I drove the point home in the fact that if you are using Windows or a Mac, then you don't have to use the command line.

Yes, I know how to use it. I've used Linux since Slackware 0.99.13 (very early 90's). Took 40 3.5" disks to download.

Re:C'mon!

[Anonymous Coward]

You're so full of shit.

1. Knowing how to use the command line is a simple matter of memorizing commands. It doesn't mean you're any smarter than someone who doesn't use the command line on a regular basis.

2. Give me one example of when you would be required to use the command line because the GUI didn't have same capability. Chances are if you can think of a reason, then you're using a shitty development environment.

If anything, people who don't use a command line are smarter than you because they're cutting down on keystrokes, thus improving their productivity.

Re:C'mon!

[Anonymous Coward]

If you've worked with NT before, you've worked with Windows - unless you meant to say you're working on Windows 95-ME (and they share a lot of common APIs with NT). XP and win2k are based on what used to be known as NT. Even when programming for windows, I've occasionally needed to use the command line.

Re:C'mon!

[GoofyBoy]

The simple fact is, most Mac users will replace their mouse

If most of them do change, how brilliant/functional is the one-button mouse?

Re:C'mon!

[bladernr]

Well, I've been using Linux since 0.96c+ (hey, if you want to start that war...)

Anyway, you're the AC doing the Delphi to AS/400, right? That's great stuff. AS/400 is one of my favorite systems, and I'm real handy with RPG, systems programming, etc. Alas, these days, 99% of what I work on is UNIX.

Getting back on topic, that is what I always perceived as Mac's weakness: integrating with other systems. Granted, that is an outsiders point of view since, as I said, I've never worked on Mac as a programmer.

That is why I liked their move to UNIX for OS X. I think that could really open up their platform and put them on a better competative foot in the corporate environment. In their traditional market (academia, publishing), back-end integration wasn't so important, but in the enterprise market, it is vital.

I wish I had a crystal ball. I eye a new G4 or G5 all the time, I just haven't quite committed yet. I understand that it can work with my Nec MultiSync 90 monitor now, is that right? I mean, as opposed to the "old days", when I had to have a special Apple monitor (taking up more real-estate on my crowded desk).

Re:C'mon!

[Anonymous Coward]

But that wasn't my objection; my objection was that you cannot be a programmer and not know how to use a commandline.

Re:C'mon!

[Anonymous Coward]

YHBT. The key is - you CAN use a Mac with a 1-button mouse, and with a 2-button mouse, and with a 3-button mouse, and with a scroll mouse. You can use either Windows or most Linuxes with a 2-button, 3-button, or scroll mouse. But could you use Windows with a 1 button mouse?

Re:C'mon!

[Anonymous Coward]

Sure you could, you could even use windows without a mouse.

Re:C'mon!

[KillerHamster]

You can't be "unfamiliar with the command line" and a programmer. Pick one.

Well, I suppose you could write VB code, but calling that programming is quite a stretch.

Re:C'mon!

[demon]

Sure you can, if you're a VB coder or something. (Yeah, I know, contradiction in terms...)

Re:C'mon!

[bladernr]

I am sorry you feel that way. I never said that I was any smarter than anyone else. Making that claim would be presumptiuous of me. I was only saying that in my work in large, distributed systems, I often required the command-line, and anyone who works on those systems would have a similiar experience.

There are many examples. For instance, I once had a program bug that actually rolled the last access times of many, many files in many, many directories forward, causing a serious amount of grief for the OS. I know of no developer GUI tool to fix that, but a quickie little command-line script fixed hundreds of times in a couple (2) minutes of work.

In database programming, people spend a lot of time at the database command-line (isql, sqlplus). Even the GUI for those is just a command-line with an output window. There is no substitute often for hand-crafted database commands.

In the distributed environment, I am often working over slow network-links, and GUIs are just unusable over slow links (try XWindows over a modem sometime). So I write my code in VI (if the link is even fast enough for that... sometimes, I write it locally and FTP it), then I compile and debug using all command-line tools on a remote system.

Then there is my work on the AS/400. There simply isn't good GUI tools there as far as I'm concerned. However, I am just as productive with what is provided. IBM did a good job of development environment on that platform.

As I said in my posting, I work in highly-distributed environments, where, sometimes, even if a tool existed, a GUI is not available.

As a matter of productivity, I've never seen anyone who could work as fast in their GUI editor as I do in VI. For instance, I make use of many of the copy/paste buffers so I can copy several seperate things from one file, switch files, then paste in at different places, with only one "file switch". I routinly set markers around the file so I can jump between them with just 2 buttons. That is more personal accomplishment, I guess, since few people ever learn enough about VI to be quite that productive, but VI and EMACS can be amazingly productive if you learn them.

The same is true with any tool, including GUI tools. After all, tools are only as good as the people using them.

Re:C'mon!

[Just Some Guy]

If anything, people who don't use a command line are smarter than you because they're cutting down on keystrokes, thus improving their productivity.

Oh, they're so cute when they're first learning!

Seriously, if your idea of "productive" is "uses fewer keystrokes", then your teacher needs to boot you in the butt. Grow, learn, expand your mind.

Re:C'mon!

[Just Some Guy]

AS/400... Interbase... SQL Server... Most fun I've had...

Dear God, I hope you were being sarcastic.

Re:C'mon!

[redtoade]

"If anything, people who don't use a command line are smarter than you because they're cutting down on keystrokes, thus improving their productivity."

As a new emacs user I'd disagree.

GUIs have their place... sure. For example, it is much easier to do simple "drag and drop" style data mangement in MSAccess, than it is to write UPDATE queries in straight SQL.

But, emacs has tons of shortcut features that puts it on the same playing field as "point and click." Tab completion, lisp routines bound to Ctrl keys, split windows/mulitple buffers, etc...

You'll find that you actually save time by your fingers never leaving the keyboard than you will with the standard move mouse, type keys, move mouse, type keys...

And you can run a shell (command line) within emacs. In fact I think my RH 8/bash install uses emacs as it's default shell editor. So most of these features are available on the command line.

You can run bash in OSX right? So I would think that all of these features would also be available to Mac users now.

In fact it's not just emacs... MSWindows has shortcuts in all of it's Office programs. They may not be used as frequently as the pull down menus, but they exist for those people who have gained a familiarity with the program. I've been using them for years in Excel and Word, frankly because it's easier to Ctrl+F to open the search dialog than it is to pull it down with the mouse.

I would have agreed with your point (although not with your tone) a few months ago, but now that I've had some experience with keyboard only shortcuts... I can see why the alpha geeks view "point and click" as too damn slow.

Re:C'mon!

[Anonymous Coward]

My bad...I thought you were coming off as a prententious jerk, but now I see your point.

I still disagree with you on the productivity aspect, though. I mean, MS Office comes with an easy to use copy buffer as well. I think it all depends on the person's mindset...different strokes for different folks, I suppose.

Re:C'mon!

[Anonymous Coward]

Funny, here I thought that using Squeak, or VA Smalltalk, or Allegro Common Lisp was programming. I guess actually getting work done counts less than struggling against the absurdly primitive Unix tools? make? C? vi? cut? col? gdb? perl?

Unix is the cause of more suffering than anything short of tripsanosomiasis. Possibly even more than Neal Stephenson, or Mountain Dew. Or Star Trek.

Re:C'mon!

[Anonymous Coward]

My idea of productivity is making the most of my time. If I can get something done quicker with a mouse click, I'll use the mouse.

Maybe you're just a spaz and you can't use a mouse properly. Back in high school (over 10 years ago), I was in a program where we taught the elderly how to use computers. The first week was spent getting used to the mouse by playing Solitaire. Maybe you should practice playing Solitaire a little more, chief.

Newsflash: using the command line does not make you elite, but thinking so proves to me that you're a clueless halfwit.

Re:C'mon!

[GoofyBoy]

I tried this a few days ago. You can, just use the menu system alot.

Re:C'mon!

[Anonymous Coward]

But, emacs has tons of shortcut features that puts it on the same playing field as "point and click." Tab completion, lisp routines bound to Ctrl keys, split windows/mulitple buffers, etc...

Yeah, but you can do the same thing in any decent GUI-based dev environ for Windows or Mac.

I think my point was not so much that you should always use the mouse, but that people who immediately assume that any one developing under a GUI is any less of a skilled programmer are assholes. This whole thread stinks of that. I've seen some pretty shitty programmers who use emacs or vi and I've seen some amazing programmers who use Visual Studio (and vice versa). The tool does not make the man, and anyone who thinks otherwise is full of shit.

Re:C'mon!

[MisterFancypants]

As a long-time UNIX (many flavors) programmer who has worked professionally as a Windows programmer for the past 4 years, I agree with the anonymous, to a degree.

IMO it is more correct to say that you cannot be a competent programmer and not be able to figure out, if needed, how to use a command-line.

I rarely have to worry about using the command-line for programming (though it is there), but when I do have to worry about it (for example -- in Visual C++ 6.0, some compiler and linker options weren't available directly from the UI, one would have to specify them as command-line options to the compiler/linker), I could. Knowing how to use command-lines also allows you to set up nice pre/post build scripts in Visual Studio that can really simplify things (copying DLLs to a shared location after being built, or whatever).

Though I'm generally against the silly minimalist approach many UNIX zealots take with regards to computer use and programming (for example, those who think anyone who uses an IDE is inferior, or whatever), given the choice I'd always prefer to work with programmers who are at least somewhat comfortable using command-lines. Anyone who has no clue in that area has probably not built a serious application. Even on the classic Mac, someone who has created a large application has probably done some scripting in MPW which is a form of command-line.

Re:C'mon!

[computerme]

most don't. period. some do. but its not "most" by any stretch.

Re:C'mon!

[holt]

Apple has been using standard monitors for years. Actually, you'd be using the same graphics cards you can use on other platforms. Most of the hardware in a Mac is industry standard (or will be soon).

Re:C'mon!

[PunchMonkey]

If most of them do change, how brilliant/functional is the one-button mouse?

I recently switched to a Powerbook and don't miss it much at all. Doing a Command+Click isn't that big a deal, and it's not often needed. What I *DO* miss is a scroll wheel. Of course, many other laptops don't have scrollwheels/scrollpads either.

Re:C'mon!

[Anonymous Coward]

Using the various DBs is part of the job. No biggie. It's all just a bunch of SQL statements to me. I don't deal w/ the admin side of it - that's someone else's job.

The fun part comes in tying the data together to generate the HTML on-the-fly. I'm having a great time (and actually working only 40 hours a week! can you believe that!?)

Re:C'mon!

[Anonymous Coward]

Hell you can use Windows just like a Mac (1 button mouse) if you have a Windows keyboard. Just use that little menu button near the Right Ctrl to pop open context menus.

Re:C'mon!

[c13v3rm0nk3y]

No matter how good the tools, you can never escape from the command-line for complex systems.

Agreed.

I work for a company that makes "enterprise" client-server apps, and out customers demand we have a complete command-line interface, along with a standard GUI and an API interface. All interfaces are actually running the same client commands, so we have some kind of interface parity. (No, our GUI is not a wrapper around the CLI! The "client" is abstract, and can only be accessed via your choice of interface.)

Customers always seem to want a scriptable and fast interface, even if it is ugly and outmoded. Everyone knows command-lines (by and large) suck. Everyone also knows we need 'em, at least for some apps and some users.

For now, anyway. Maybe when all the old-timers die (hmm, I wonder if this means me, as well), the CLI will die.

Re:C'mon!

[Snocone]

You can't be "unfamiliar with the command line" and a programmer.

Then what do you call those things that ran on Mac OS X and the people who wrote them, if they weren't "programs" and "programmers" respectively? Took me 16 years of shipping commercial software products before I had to use a command line at all, personally.

Re:C'mon!

[Maserati]

Adaptors have been available to use PC monitors on Macs since 1991. Current Mac desktops have two digital video ports, including a DVI port. they also come with a DVI-SVGA adaptor. This isn't changing on the G5s. The other connector is an ADC port, which is basically DVI+USB+Power; only Apple LCD screens use that one.

Re:C'mon!

[Anonymous Coward]

I don't see what's so hard about typing 'make'.

Re:C'mon!

[Anonymous Coward]

My touchpad software senses drags up and down the left edge of the pad (configurable) and scrolls the focused control. Very handy.

It does it for the bottom, too, but I don't find myself scrolling left and right much.

Re:C'mon!

[laserjet]

For now, anyway. Maybe when all the old-timers die (hmm, I wonder if this means me, as well), the CLI will die.

I don't think this will be the case. I, while not an old-timer @ 23 years, love the CLI. I continue to see a need for both. I use both, and use them when they should be used. The CLI is great for scripting and such, and can be indispensable when speed is important. Sure, the CLI has a steeper learning curve, but once you get to know the commands, options, etc., most people favor the command line for certain work (typically computer-savvy people like myself).

I think the command line will be around for a long time, as it is another tool we have in our toolbox that can help us achieve some tasks better. It's about always using the right tool for the job, and sometimes the CLI is that tool.

Re:C'mon!

[MochaMan]

Newsflash: using the command line does not make you elite, but thinking so proves to me that you're a clueless halfwit.

Try doing a global find and replace through over 80 sub-projects in Visual Studio, and you'll find that the command line and sed are your two new best friends.

I try to use the command line as rarely as possible, but I refuse to avoid it if it's the best/fastest solution to a problem. I don't think that makes me "elite", but I do think you'd have to be pretty stubborn to expressly avoid the command line... sometimes it *is* the best tool for the job.

I doubt the parent poster to your comment thought he was "elite" for being able to use a command line, and I doubt he's an ignorant halfwit.

Re:C'mon!

[Brand X]

You can't be "unfamiliar with the command line" and a programmer.

Then what do you call those things that ran on Mac OS X and the people who wrote them, if they weren't "programs" and "programmers" respectively? Took me 16 years of shipping commercial software products before I had to use a command line at all, personally.

</QUOTED TEXT>

Hmm. 16 years. Commercial software. Let's see, that would (assuming the first time was five minutes before your post) put you at 1987, not using a command line, writing commercial software.

In 1987, assuming you were a DOS programmer, (couldn't have been Unix) you would have been using a command line for everything. Windows was still in its infancy - Windows 2.0 - See This, and on the Mac, your choices were - Mac Pascal or MPW. MPW was a programmer's shell - a command line. Mac Pascal was a graphical programming tool, except - you guessed it - someone had to write (essentially command line) scripts for the version available in 1987, or you couldn't get a basic "hello world" compiled.

Please don't tell me you wrote Basic apps on the Mac in 1987 and sold them commercially...

Re:C'mon!

[WatertonMan]

Saying that the CLI would die when the old timers die because of the GUI is like saying books will disappear when those folks from before TVs die off. Each has their place.

Now I think that in some ways Apple is still a little too dependent upon the CLI in OSX. Lots of things don't have a GUI that should. But that doesn't mean the CLI isn't welcome. After Sys9, having a full sophisticated CLI is a dream. Further with Applescript integrating the two is possible in a way not dreamt of in Windows or Linux. (Although VB for Applications helps on the Windows platform)

Regarding gdb though, Apple's interface to it is weak. Further there are so many problems with Apple's visual debugger that it isn't even funny. I'm not surprised that some drop down to the more CLI version of gdb.

The problem is that while that is fine for certain kinds of debugging, many people need nice persistent watch variables. Unfortunately those who've use Xcode say that this hasn't been improved.

Re:C'mon!

[Snocone]

put you at 1987,

'85, actually.

assuming you were a DOS programmer

Nope, just Mac.

on the Mac, your choices were - Mac Pascal or MPW

Au contraire!

Started out in MacFORTH, then Consulair C, then THINK (later Symantec) Pascal and C, then CodeWarrior. Never touched Mac Pascal ever, and only extremely rarely had anything to do with MPW -- certainly not enough to be any reasonable definition of "familiar" with it.

Heck, I wouldn't even call myself "familiar" with the OS X command line yet ... a 'power user' perhaps. At most.

Re:C'mon!

[laredo]

If anything, people who don't use a
command line are smarter than you because they're cutting down on
keystrokes, thus improving their
productivity.

Wow, I have to disagree. Coming from a background of using the
gooey goodness of the Mac OS since system 7, I have been all about GUI
GUI and more chewy gooey goodness, BUT everyone I have ever taught how
to use the Mac OS in its previous incarnations, I always showed them
how to get almost anything done by way of using the keyboard, the Mac
OS ( same with windows ) had/has an amazing amount of keyboard
shortcuts and if used , a person could do about 99% of their work with
out ever touching a mouse. This seriously enhanced their productivity,
those that took to the keyboard shortcuts got gobs of work done in
record time compared to those that did not.

As for using the command line instead of a GUI , my first reaction to
OS X was

" damm years of Mac OS knowledge in the dustbin, I was elite dammit!" (
he said with a tinge of sarcasm and sadness ) While I really have had
to reinvent my troubleshooting skills, almost all my beloved keyboard
shortcuts are still there, AND I get to use this newfangled thing
called a CLI, and I tell you it is an order of magnitude faster to move
around on remote servers using the terminal than a GUI, an order of
magnitude faster to edit lots of html/plain text documents using the
terminal, and I have really just scratched the surface. Now on my local
HD , I know I can get to
places way faster in the GUI than using the CLI, But I certainly do NOT
use my mouse to get that speed, but the keyboard and only the keyboard.
One thing I do use the mouse for a lot is placing the insertion point
in certain places, seems faster than the keyboard sometimes, but only
sometimes.

The thing that sort of makes this thread on topic is that I hope that
programmers that use this book will add tons of keyboard shortcuts to
their GUI programs, so we can be chewey and gooey yet not use a mouse.

Re:C'mon!

[Anonymous Coward]

Yes, I know how to use it. I've used Linux since Slackware 0.99.13 (very early 90's). Took 40 3.5" disks to download.

I'd just like to correct you on one small point there. Generally in networking, 3.5" disks are not required to transfer files from one host to another (to 'download' the files, as you put it). Rather, a communications device, such as a modem, or network adapter is required. Perhaps you could consider re-writing your sentence as: ...Took a 2400bps modem to download

Thank you.

Re:C'mon!

[Creepy]

Second button is control-click, usually, but I'm quibbling :)

I was happy to see that replacing the hockey puck mouse on my G3 with a $15 3 button + wheel optical mouse worked flawlessly in MacOSX, even way back at X.0. I needed to install drivers for both Linux and macOS 9 (both had non-functional wheel although 9 in emulation mode worked).

Re:C'mon!

[Snocone]

...how brilliant/functional is the one-button mouse?

First, add the necessary qualifier here "to the complete novice who thinks of a computer as no more important to them than a screwdriver and they figure should be as easy to use -- which is Apple's default target for a new buyer." (As anyone who isn't in that category can go pick themselves up a Logitech MX700 and get eight buttons, like I did.)

Next, if this clarification still leaves you in any doubt that one is the proper number of buttons for a default shipping mouse, talk to anyone who's spent time manning the support lines for a Windows-serving ISP. I very sincerely doubt you will be able to find a single one of those who would not agree that their job would be immensely simplified if Windows had followed Apple's lead on the number of buttons thing. For that matter, many of them probably would be skeptical of the "double-click" concept as well. I think people like you really don't comprehend that two buttons honest to god(s) really IS quite confusing to the vast majority of the population...

Re:C'mon!

[GoofyBoy]

1. Apple ships the one-mouse button on all of its models. Including the ones for advanced users. Its not the point that you can go out and get a new mouse, but the fact that you had to because the one included was not satifactory.
2. Tech support jobs would also be simplified if keyboards had one button. Not very useful is it?

$97.95?!

[yumyum]

That'd put a major dent in my crack usage...

Re:$97.95?!

[Anonymous Coward]

I totally to agree. The one aspect that I'm interested in is the ZeroConf/Rendezvous info (albeit four pages according to their table of contents PDF).

They really should've considered three different books here: the main book that's already available and two other books (the main book split into two volumes). I'd actually buy a volume that's geared toward networking and threading even if I'm paying for unwanted info (I can let it slide to a degree). Instead, I'll likely skim the Rendezvous section without purchasing anything at all, which is a shame but sorry...I'm not *that* charitable.

Maybe I'm using iTunes too much, but I'm a bit tired of paying for unused extras in programming books.

Re:$97.95?!

[Anonymous Coward]

It's a course book. You could publish it as three books... but for a one week course?

Grand History?

[VP]

In the grand history of well-written technical books, it is also occasionally funny.

I hope the reviewer meant "grand tradition," although I don't see how this cliche fits here...

Aaron Hillegass as an instructor

[blakespot]

I am approaching the end of Aaron's previous book, Cocoa Programming for Mac OS X, and can say that throughout, it's as though he is sitting there beside you, casually instructing you as you move through the work. An excellent introduction to Cocoa, it has given me a fairly solid graps of the concepts that make up Cocoa development (which began in the late 80's with NeXT) and I have made some real strides on my own, veering from the courework in the book. Goes far beyond some of Apple's cryptic guides I've encountered.

Oh...and do yourself a FAVOR and download Cocoa Browser before you even lay down a single line of Objective-C. The ONLY way to access the frameworks references.

blakespot

Re:Aaron Hillegass as an instructor

[Anonymous Coward]

Actually, AppKiDo is a better Cocoa browser. I would recommend it instead.

Re:Aaron Hillegass as an instructor

[Anonymous Coward]

Hey look! A post that's actually on-topic.

Re:Aaron Hillegass as an instructor

[Greedo]

Heisenberg may have slept here

That's the funniest sig I've seen in a long time!

Just wondering...

[rampant mac]

Those WWDC people who have access to Apple's upcoming OS, Panther...

How relevant will this information be with Panther merging to BSD 5.0 userland and the new Xoode environment?

I can't seem to justify the price for this book ... yet.

Re:Just wondering...

[markd]

From what I saw at WWDC, only a couple minor points here and there will need to be updated (like the new exception mechanism in objective-C replacing the setjmp/longjmp one that currently exists). The tech addressed by this book is more at the plumbing level which doesn't change a whole lot release to release. We don't dwell a lot on the IDE, figuring that folks will know what they're doing in their IDE of choice. (I personally use emacs for my day-to-day work)

Re:Just wondering...

[Anonymous Coward]

I bought it anyway. Sure, Panther will change things, but there is still a lot of stuff in there. I'm still using Aaron's Cocoa book despite many changes to Project Builder that can sometimes make it difficult to follow the examples. I expect the same of Xcode. Much of the book is good reference for things that I've seen before as a Unix C programmer, but forget because I don't look at them every day.

It's expensive. Very expensive. With my current budget situation, I had to figure out what else I wasn't going to be buying before I could get it. But cheaper than going to the classes, for which I've gotten several unsolicited glowing recommendations merely for walking around WWDC with a copy of the book.

The authors are great guys, they know what they are talking about and are not stuffy at all. I hung out at their booth a while looking at the book before I bought it and later they both cheerfully signed it for me.

Re:Just wondering...

[Anonymous Coward]

I looked the book over at their booth at WWDC. Too much of it seemed like review to justify the price.

And yes the book is still just as valuable given that Panther is coming out.

Re:Paragraph Intros

[Creepy Crawler]

If you can "read" a EULA, I'm sure this is cake.

I understood is point, I didn't say "huh", nor did I otherwise get confused. Sheesh. Even the "Hacker Exploit Papers" have jokes and innuendos spiced about. And they're considered 'professional'.

ah, no

[SweetAndSourJesus]

It's not a port. It's a completely different product. They tried a direct port with Word 6, and it failed miserably. Mac users don't want Windows ports.

Most of the work is most certainly not done. It's not like we run /usr/bin/word. It's a Cocoa app, not a UNIX app.

Re:ah, no

[tbien]

Actually all Microsoft Office apps on the Mac are Carbon apps (C++) not Cocoa (Objective-C)

Confused

[Anonymous Coward]

I see Unix in the title but there is no mention of SCO. Just what in the hell is going on around here?

Re:Confused

[Anonymous Coward]

SCO? Bah!

Re:Confused

[nacturation]

I see Unix in the title but there is no mention of SCO. Just what in the hell is going on around here?

SCO was too busy imagining a beowolf cluster of these.

Mod Parent down

[Anonymous Coward]

What on earth does that have to do with this book review? Nothing about Microsoft, Office, or Linux.

OFFTOPIC!!!!

Re:Mod Parent down

[Anonymous Coward]

Noo noo noo!!!! Mod the grandparent up! The more off topic and trollish posts that appear on Slashdot, the more unusable it becomes! Please continue to RUIN Slashdot. It's time that someone took responsibility and destroyed Slashdot.

OK. I'm just kidding. But boy was that fun. Now let's watch the fur fly.

Re:weird

[dema]

This got a funny mod? Um, flamebit?

When you buy an Apple you get what you pay for, so that's a bad example anyway.

Who mods this stuff?

Re:weird

[carpe_noctem]

For example, chapter 8, "Debugging With GDB," was not simply a repeat of the online help...

Wow, so we didn't even RTFS (summary), did we? ;)

Re:Paragraph Intros

[Anonymous Coward]

Wow... you're my hero. You can nitpick without any effort at all. Do you think you could teach me how to do that? I'd also love it if you could teach me how to be an arrogant and pompous asshole since you seem so good at it.

This is Slashdot, not English class.

Good News...

[DoctorPepper]

... If you have a Barnes & Nobel reader's advantage card:

List Price: $97.95
Our Price: $78.36
You Save: $19.59 (20%)

Readers' Advantage Price: $74.44

(OUCH!) This looks to be one book I'm going to have to skip. Bummer.

Re:Good News...

[masterhackman]

It's Barnes & Noble actually...

Better than list price here:
http://www.atlasbooks.com/marktplc/00981.htm
---
Drink Longjing Tea!

http://research.microsoft.com/~zhang/calib/TeaBox/ TeaBox1.gif

Re:Good News...

[DoctorPepper]

Sorry, oh great master linguist in the sky, I forgot to run the patented Slashdot spell checker prior to posting. Can you ever forgive me?

Please, please, please...?

Re:Good News...

[amanpatelhotmail.com]

You can get it at half.com at $88.74 (shipped).

My experience with half.com sellers has been wonderfull till now.

man Pages

[The Jonas]

On a side note, I have wanting to see a program developed for the *nix desktop that allows a user to select from all available "man" pages and display them in the active window. This would minimize some time I spend on the command line - not that I mind the command line, but for document viewing, editing, and note-making I would rather have a graphical interface. Let's call it "RTFM" ;) . This may be able to be done through another program and I may just be unfamiliar with its operation. Anyone???

Re:man Pages

[carpe_noctem]

apropos *

Re:man Pages

[krray]

You mean something like: ManOpen

Re:man Pages

[The Jonas]

Yes, thank you, just like that. Your linked page states that I must be running OS X. I'm running Mandrake 9.1 - is there a port or something similar - IIRC OS X is BSD based - will it install on my machine with its ".dmg" extension?

Re:man Pages

[BenjyD]

I think xman would do what you want. It's a pretty damn ugly x app though

Re:man Pages

[fuckeverything]

xman should be pretty much what youre looking for.
comes with pretty much any distro i know.

Re:man Pages

[The Jonas]

thanks - going to check it out now.

Re:man Pages

[Anonymous Coward]

Do you mean something like this?

Of course, if you are using another OS, you might be SOL.

Re:man Pages

[larry bagina]

KDE version 1 or so had a help application that could display html help, gnu tex-info, and man pages, although, IIRC, searching was broken. I haven't tried using konq. to view a man page lately.

Re:man Pages

[Anonymous Coward]

Ah, you mean like a set of scripts that would invoke man2html on the man pages and automatically generate indexes of them, so that you can use any normal web browser to read your (Cross referenced) man pages?

Yeah I thought that would be cool too, so I did it. Not on Linux though.

Re:man Pages

[Raffaello]

OS X is Mach with a BSD "personality," i.e., it has a BSD layer, but Mac OS X GUI software, like ManOpen, is not required to, not likely to, rely entirely on the BSD layer. This means that Mac OS X GUI software will rarely, if ever, "just run" on some other *nix, or *bsd. The only exceptions are Mac OS X applications that are intended to run under a Mac OS X X Window server.

From the ReadMe that comes with ManOpen:
"ManOpen should run on MacOS X 10.x, MacOS X Server 1.2, and OPENSTEP/Mach machines. Source code is available."

So you could try porting it to the X Window system on you favorite *nix if you like.

Re:man Pages

[Anonymous Coward]

in kde use man:// in konq

Wrong URL to Buy the Book

[BigNerdChris]

You can't (currently) get the book at bn.com. Use this web page to buy the book: http://www.atlasbooks.com/marktplc/00981.htm

Re:Wrong URL to Buy the Book

[FooGoo]

I ordered mine from Atlas Books a few days ago for $102.95 with shipping. At that time I could not find it at Amazon. The price is a bit steep but it's less than the $3500 for the class.

Re:Paragraph Intros

[fobbman]

I don't understand. Are you expecting that the book reviewers be held to a higher standard than the editors of /.?

Re:weird

[Surak]

Uh, did you even read the summary?

First off, glibc doesn't have a man page. The book isn't $60, it's like $98 and even discounted it's going to be around $75-$80. Secondly, the guy specifically states that the GDB stuff isn't a regurgitation of the man page, which I assume would hold true for other pieces of the book as well.

Secondly, although I have publically stated my fundamental disagreements with Apple about their policies on patents and their general disregard for some of the fundamental concepts behind open source software, Apple makes *great* hardware -- it's *much* better stuff than you can find in value-priced x86 machines. A little overpriced, yes, but you expect that from a strong brand like Apple.

ah, yes

[SweetAndSourJesus]

You're right. Don't know what I was thinking.

That makes them even less portable.

Yet another ...

[spiritraveller]

How long till SCO sues the author for leaking trade secrets?

...SCO lawyers start your engines...

[the_webmaestro]

will they sue these guys for having Unix as part of the Book title?

Truly Impeachable: +100,000 Hyper-Patriotic

[Anonymous Coward]

Read about 43's daring statement here

Cheers,
W00t

sockets? on OSX? wow!!!!

[kill_the_sexplayer]

Why don't the other books on OSX cover topics like sockets, and pipes? Well because its all been done before. Did Apple add new functionality to the sockets API? I dont think so. Its pointless.

Haha! Nice Try!

[Greyfox]

Thought you could pass yourself off as an Apple user did you? We all KNOW that Apple users are pot smoking hippies, not crack smoking executives! Go back to your windows desktop, poser!

Re:Haha! Nice Try!

[qengho]

We all KNOW that Apple users are pot smoking hippies

Don't forget that the company itself is so constrained by the political views of its corporate leadership and board, which now includes Al Gore, that it's accepting lower sales. Commie mutant traitors!

Re:Haha! Nice Try!

[Anonymous Coward]

Limbaugh is a rabid Mac fan. That was an endorsement for those of you that can't tell.

(Regardless of your opinion of him, you need to realize that 99% of what he says is pure sarcasm whose sole intent is to piss people off.)

the price

[Anonymous Coward]

I plan on buying this book when I get the cash, but from talking to Aaron last week at WWDC, the price is that high is because it's basically the course material for the classes they have at the Big Nerd Ranch. Of course...I can't afford the classes, so I'm going to get the book.

price is $104 -- am I making a mistake?

[marhar]

Am I reading it correctly that the price is $US97 plus shipping?
Also, is it showing up on Amazon? I looked and didn't see it.
Clues gratefully accepted...

Re:Paragraph Intros

[Anonymous Coward]

Hi Welcome to slashdot. I see from your comment that you are new here.

This is Slashdot. It isn't relaxed here. You must always spell and grammar check everything you post. If not, it will be picked to death by the spelling and grammar nazis. If you have something nice to say, keep it to yourself. This site is about discussion. Disagreement makes for better discussion.

Nice KeyChain Obj-C wrapper

[kwerle]

I stole a nice Obj-C wrapper for keychain and tweaked it a little. You can get it here

No

[Anonymous Coward]

You are thinking of Mr Rogers.

Re:Hahaha, there's a simple answer to this one...

[Anonymous Coward]

His marriage is an economic one. His wife is one of the richest people on the planet and employee 10 at MS.

Re:mac problem

[Anonymous Coward]

Dude, you've posted this exact same comment, verbatim, at least a dozen times before. If you insist on being a troll, can't you at least be a creative one...

Why Would MS Encourage Migration to Linux?

[reallocate]

Why would MS port Office to a platform they see as competition for Windows? Apple isn't competition; Office on the Mac doesn't take away potential sales of Windows and other MS products. Selling Office for Linux, on the other hand, would just encourage migration from Windows to Linux.

Re:Why Would MS Encourage Migration to Linux?

[Coward the Anonymous]

I never said Microsoft would do it, that would be market suicide for them. I merely said that if they did, it would sell.

heh i saw Debugging with GWB

[waspleg]

there has to be *some* way to cleanse us of all that ashcroft hath wrought

amazing

[Anonymous Coward]

how a post that would have gotten -100,000 flamebait is suddenly informative/insightful now that Apple is the toast of /. instead of one of the whipping posts

it's shocking what a few years and a pretty UNIX GUI can buy you in terms of publicity and acceptance in such a fickle self-absorbed market as this one

Re:amazing

[DaddyExcellent]

It's also amazing how many posts say the exact same thing as you. It's funnier when the number of 'watch all the Mac zealots defend their ghey computers' outweigh the zealot posts by 10 to 1. Sppeak for yourself, fuckwads.
Much though you would love to think /. had its nose in Job's crack, it isn't actually true. Now fuck of back to your basement you pasty faced fat fuck

Re:amazing

[Surak]

Know what? I'm not a Mac zealot. I don't have a single piece of Apple hardware or software (well, except the Quicktime plugin on a Windows box I happen to have, but that hardly counts for anything).

But I will tell you -- I have used Macs in the past for desktop publishing work, and I have used a colleague's G4 machine before, and I've taken a close look at the hardware and software of modern Macs while considering whether or not to purchase one.

I decided that for my own needs, a Mac wasn't going to cut it and I didn't find it necessary to add yet another machine to my ever-growing little LAN at home.

That being said, they *do* make nice hardware. I agree with you that Apple's main goals behind OS X were to gain acceptance in the open source hacker community that was in some ways (believe it or not) responsible for the success and popularity of Windows, and that Apple's only goals in *appearing* to support that community (IBM has done wayyyy more for open source than Apple ever *thought* of doing) is to sell them a product.

But don't go around totally knocking Apple's stuff because they *do* have some good points, and they *have* been helpful to the community. If people show them enough appreciation, maybe they'll wisen up and begin to truly support the community by loosening up their stance on software patents and open sourcing the rest of their OS. But if when going into the open source community they encounter bitter sounding people like you, they won't do shit. And I wouldn't blame them.

Re:amazing

[Blimey85]

and that Apple's only goals in *appearing* to support that community (IBM has done wayyyy more for open source than Apple ever *thought* of doing) is to sell them a product

I'm not so sure about this. I don't think that Apple is trying to deceive anyone in this matter. I think it simply boils down to not having the resources to do what they really want to do. You compare what IBM has done to what Apple has done... look at the difference in size between the two companies. Of course IBM can afford to have a few programmers working on side projects or maybe a few hundred whereas Apple may need more programmers than it can afford. Think of all of the problems Apple has had over the years. They don't have an endless supply of cash to spend however they want. Most things are do or die with Apple just like the G5. They had to innovate quickly or their machines would have been so far behind the rest of the pack that not even the most loyal could have used their products anymore.

Secondly, I don't think their main goal in OS X was to gain acceptance. I think they wanted something rock solid that was very extensible and powerful that they could easily and effectivley leverage for quite some time. Why start from nothing if you can start from something that is already 90% complete, slap a fancy GUI on it and then spend your time improving something that is already great? It seems to me that their decision to start with FreeBSD and build from that was a great decision. It's sad that they haven't given more back to the FreeBSD team but maybe with time that will change.

Re:amazing

[Surak]

Answer these questions:

1. Why doesn't Apple open source more of their software, like QuickTime?

2. Why doesn't Apple open source more of OS X than just Darwin? An OSS version of the GUI would be a big boon to the community.

3. Why does Apple cling so tightly to its patents? Why does it STILL apply for software patents (i.e., Expose). If they truly support OSS, surely they would see that software patents harm the OSS community.

Answer those three questions and you'll most likely arrive at the same conclusion I did.

Re:amazing

[hayne]

Answer those three questions and you'll most likely arrive at the same conclusion I did.

What - that Apple is a company and that at least one of the goals of the company is to make a profit? I think there are very good reasons why they have not open-sourced what they consider to be a competitive advantage - the GUI parts of OS X.

I also wish they would release the source of more of OS X. But I don't particularly care if they make it open source - I would be happy to have the source for the GUI even if I couldn't do anything other than look at it. It would be very useful for troubleshooting.

AppKiDo

[hayne]

do yourself a FAVOR and download Cocoa Browser before you even lay down a single line of Objective-C. The ONLY way to access the frameworks references.

I much prefer AppKiDo since it allows searching and it shows you a list of all methods of a class (including those from super classes) as well as a list of just those provided by the class itself.

Re:Proprietary/Design flaws

[Anonymous Coward]

Heaven forbid!

Villagers need jo2y.

[jo2y]

The book lacks sufficient references to 'jo2y',
I could only find about 3 or 4.

Re:Villagers need jo2y.

[evand]

I'm sure "evand" and "esd" are scattered throughout it; the letters just aren't necessarily consecutive.

Re:Villagers need jo2y.

[Anonymous Coward]

U r T3h M0by St4N/\/ArD

Re:Villagers need jo2y.

[mdz0]

I'm sure this grievous oversight will be correcte d in the next edition.
-mdz

beside me? uh oh ...

[Heisenbug]

"It's as though he is sitting there beside you, casually instructing you as you move through the work."

That's gonna make it harder to code in the nude ...

Re:important question:

[Anonymous Coward]

it says in the Acknowedgements:
"...All layout for this book was done using OpenJade, TeX, and Norm Walsh's DSSSL stylesheets for the DocBook DTD."

Re:mac problem

[Anonymous Coward]

And why would anyone buy a Model T when you could get a horse for cheaper and it works on more roads!

Be very quiet or you will never be able to catch a clue.

In other words....

[SPYvSPY]

What I consider critical improvements, you consider "proprietary/design flaws compared to just Unix".

Weird Times

[SomeOtherGuy]

I know OS X is all unix central nowadays...Yet to see a book about core Unix programming on a Mac still has me to a doubletake the same if I saw a book called "A vegetarians guide to cooking steak."

$100 book to explain a for( ) loop?

[Anonymous Coward]

It always annoys me when I see a supposedly "advanced" programming book start out with newbie C programming, and unfortunately this book falls into that trap (spending nearly 100 pages on C basics). I don't know what possesses authors to do this, as it is a waste for any programmer with even a little bit of experience, and it won't be a suitable first book for someone who doesn't know what an if statement is.

With Panther and XCode just around the corner, other information in the book will soon be out of date, reducing the relevant page count even more.

I also think the price is obscene, and won't buy the book because I don't want to validate the decision to price it so high (and I own just about every OS X programming book released so far). It appears the price was the result of discussions along the lines of "this is the info you'd get if you paid $3500 to come to the class, so $100 is a bargain!", but book pricing should be done in the context of the publishing business, not the training business. If the book were priced competitively with similar programming books it might be worth a look; at $100 I suspect many people will pass it by.

Re:important question:

[markd]

Indeed it is. We also used CVS to collaborate on the sgml files and the makefiles to drive the DocBook->PDF toolchain. I used emacs for my chapters, and Aaron used an in-house tool called DocBooker. The early version of DocBooker is presented in Aaron's Cocoa Programming for Mac OS X book. Many illustrations where done with OmniGraffle.

Does Cocoa (and this book) relate to GNUStep?

[Rinikusu]

I know that GNUStep is implemented in Obj-C, but would this book be useful for learning Obj-C and the GNUStep interface? Would there be any advantages for doing so (would I gain any cross-platform Linux-Mac OS X benefits)?

Re:Does Cocoa (and this book) relate to GNUStep?

[Art Tatum]

I know that GNUStep is implemented in Obj-C, but would this book be useful for learning Obj-C and the GNUStep interface?

I haven't read it but judging from the title and review, I don't think it will do you much good right now. It appears to be talking about some of Apple's own custom frameworks and lower level UNIX stuff. Somebody on the GNUstep list mentioned recently that they're interested in cloning Rendezvous but it's still just vapor.

Now, Aaron Hillegass' previous book, Cocoa Programming for Mac OS X, is VERY good and will mostly stand you in good stead with GNUstep. It's a great introduction to OpenStep/Cocoa/GNUstep concepts. Combined with the documentation on the GNUstep site, the docs over at Apple and asking questions on the GNUstep mailing lists, you'll be fine.

would I gain any cross-platform Linux-Mac OS X benefits

the GNUstep frameworks and Apple's Cocoa are both based on the OpenStep API, so they're mostly source-compatible. There are some pitfalls and considerations that you'll need to know about before you start on any ambitious programs, however. I'd suggest just becoming familiar with Cocoa and/or GNUstep first, then try writing a simple little app and porting it. There's a very cool project underway called Renaissance that will make portable UI design much easier. I can say that it's easier to design/build on Linux/GNUstep and then move to OS X rather than the other way around.

GNUmail is an example of a great portable OS X/Linux/BSD success story. Nice app.

Hope this helps. Drop on by the GNUstep discussion list some time and say hi. Always nice to know who's interested in the project.

Re:Does Cocoa (and this book) relate to GNUStep?

[markd]

Probably not. The actual cocoa / objective C stuff handled tends to be OS X specific (the rendezvous classes, AppKit stuff like threads and drawing, CFRunloop). The lower-level unix stuff (files, threads, sockets, libraries, CVS, gdb, etc) are useful across unix variants.

ManOpen? Could they think of a GAYER name?!

[Anonymous Coward]

Open Carbon?

[Trurl's Machine]

MS Office is a Carbon app. There's no carbonlib for any *nix except Mac OS X out there. Porting it to Linux would mean either porting carbonlib (i.e. a cleaned up version of the legacy Mac OS api + extensions) to Linux,

Wait a minute - if I had my modpoints now, I'd surely give you an "insightful" just for this. Are there any attempts to create something like free carbonlib compatibility environment? This could bring much more than just MS Office to Linux and other free OS'es. After all, majority of games for MacOS X is actually written in carbon - and they run natively in OpenGL, so there is no further need for the DirectX compatibility. Would this be worth the effort?

Re:Open Carbon?

[Halo1]

Just porting carbonlib wouldn't cut it in most cases. Almost all Mac apps also use Quicktime. For sound, they sometimes use CoreAudio under Mac OS X. Most games use the HID Manager for input... So I'm not sure whether just carbonlib would help a lot.

Re:Hmmm I smell trouble brewin'...

[fiftyvolts]

All that talk about the wonders of emacs.... when is someone going to resuscitate the ole' vi verses emacs debate in this thread. (heh, guess right now, huh?)

Honestly, I spent an hour lecture debating this. I claimed emacs was better, while he was die hard vi. I kid you not; it happened this past May. We beat that horse so dead that by the end of the hour the contention was that vi was more productive because it had no bundled games built in to it to kill you productivity.

... I said that emacs provides you built-in entertainment for ones lunch break.

Re:weird

[Anonymous Coward]

Yes, and he wasn't the king either.

Boromir: "We have no need of kings."

xman, damn you.

[theTerribleRobbo]

It's only several years old...

Silly person.

Re:mac problem

[otuz]

Yeah, I suppose you are running LocalTalk over a 56k modem or something and running a broken System 7 installation?

Try to copy the 17 Meg file with your fancy 486 running Windows 95 if that suits you better, but please stop whining.

Carbon or Cocoa?

[maclar]

What should one use? I've heard that Cocoa is the way to go, but that involves learning Objective-C.. Would Carbon be supported in the future and would we be able to use all the cool features of OS X with Carbon (like Quartz)?

Aaron is an exceptional Instructor since at NeXT..

[tyrione]

But no fucking Programming book is worthy of nearly $100 no matter the author(s).

The pass the R&D efforts of teaching Consultants how to program cost onto a potential tens of thousands of general programmer audience is the same asinine attitude some folks felt and I disagreed with while at NeXT.

Miraculously Steve thought $50k for WebObjects was steep and dropped it to $699. Amazingly, the product still exists.

Drop the price guys, get a better publisher to distribute and cover your costs so you can give us this sure to be excellent resource.

Hell, W. Richard Stevens, Advanced Programming in the UNI* Environment is definitely cheaper than this worthy book and it already has a place in history.

Good book. Good review

[honestpuck]

This is indeed a useful book. As someone who is a long time Unix programmer and just starting out with Objective C and Cocoa I found it mostly above my head but a book I know I will grow into and find useful for a long time.

I agree with the reviewer about the lack of pointers for further info. I hope that the authors might fix this at the excellent site for the book.

For close to $100 this is an expensive book, but if you want to learn to write professional Mac apps then it's probably worth the price. These guys know their stuff and the book is a lot less than the $3500 they charge for the course.

Tony Williams

Re:Hmmm I smell trouble brewin'...

[Anonymous Coward]

Ed, ed, ED, ED!