Modern Mac Development?
CDarklock asks: "I'm getting seriously interested in setting a new Mac next to my Windows box (to replace the Mac SE, which should tell you about how long it's been). But on Linux and Windows, I'm accustomed to writing lots of custom apps in C++ to fill the gaps around the system, but I haven't written anything on a Mac for something like fifteen years. As a professional Windows developer, what sort of expense am I facing to outfit a new Mac with development tools comparable to Microsoft's Visual Studio .NET, and what sort of learning curve should I expect?"
a troll to get someone point at some free xcode or what?
As for the learning curve, it may take some time to get used to things being done differently in OS X, but moving from C++ to Java isn't too difficult if you choose to use Java Cocoa.
Objective C is generally a better bet for Cocoa development, but it will have a slightly steeper learning curve, since the syntax is significantly different.
Other than the change of language, the Cocoa frameworks might take a while to learn, but the documentation is very good.
Don't blame me; I'm never given mod points.
OS X comes with an x-code cd. it is all the developer tools you could ever want.
see http://www.apple.com/macosx/developertools/
I don't know about the learning curve, as I don't program at all, but with the regular installer for OS X, you get developer tools as well (a Mac Mini would probably fit in well with your setup, especially if you use a KVM switch).
You can also check out Apple's developer website (http://developer.apple.com/) for more details.
XCode is far too bulky for most projects (which means just about anything you're going to program alone.)
Your problem is managing to impede the Mac sufficiently to make it no better than .NET.
(Okay, so I am a recent convert.)
I don't know how well it measures up against Visual Studio, but I for one love X-Code. It's a nice IDE, useful but not over done. X-Code and a number of other development tools come with OS X (and are avaible at no charge from the Apple Developer Network website). X-Code uses gcc and gdb for compiling and debugging. You can use it to code C, C++, Objective C and others. As far as coding goes, it sounds like you'll really want to learn Cocoa. Cocoa is the core set of OS X frameworks (think MFC, only much, much better). There are Cocoa bindings Java and a few other langs, but ideally you'll want to use Objective C. Obj C is a great language, much easier to learn than C++, and in my opinion a joy to program. Good luck.
has any one experience with python development in OSX? these features of xcode, like getting undo for free. are/will they be available for python coders? I dont do any c++ or objective c, so I would not know. I guess those things would requires wrapers for python to deal with them , right?
About the only thing you should expect is to love xcode. :-)
/* oops I accidentally made a comment, sorry */
I used to be a C++ developer too. Then I moved on to Java. You may want to look into this for a number of reasons. For one, you can use eclipse on any platform, including OSX to develop your java apps. For two, apple really likes Java. They have done a lot of work on the jvm for OSX and it performs extremely well. They also provide a number of OSX specific Java interfaces to the underlying platform if you don't care about it being platform specific. Its truly worth a shot.
mp3's are only for those with bad memories
Apple ships OS X with a developer tools CD. That's where you will want to start. It will give you most of your basic gnu development tools, along with Xcode (a decent IDE which is getting better with every revision) and some mac-specific profiling tools.
The next step is to sign up for the Apple Developer Connection. It has many membership levels ranging from free (so you can download developer tool updates) to very expensive. Update your compiler and tools to the latest version using this service.
If you like Java, downloading Eclipse might be a good way to go. I haven't used Eclipse much, but have enjoyed all of my experiences with it on OS X.
You will also want to install either Darwin Ports or Fink. These are package management systems that are based on BSD Ports and apt (respectively). I'm partial to Darwin Ports, but both systems have their strengths and weaknesses.
If you want dead-tree documentation, the two books to start off with are "Cocoa Programming for Mac OS X" by Aaron Hillegass and "Core Mac OS X and Unix Programming" by Mark Dalrymple and Aaron Hillegass. These guides are thorough, and the authors have been part of the Objective-C/Cocoa community since the Next days, and give good tutorials on what is the Mac philosophy of software development.
Another option for an IDE, which has decent but dated interfaces to the OS X world is CodeWarrior. I know a bunch of developers who swear by the CodeWarrior development platform. I really couldn't get into it myself, but it seems to have a nice toolkit for cross-platform development.
Have fun!
The middle mind speaks!
If you have any costs (other than the hardware), they might be:
ADC membership (student membership is free, non-student cost is significant)
WWDC attendance
Other apple developer training/seminars
None of the above are required. ADC membership will get you access to pre-release hardware and software to test your apps; but you're not doing commercial work, right? Apple training and the WWDC gives you insight into the inner workings of the OS, but you can get much of this info on Apple's developer website
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
Why is it too bulky? It offers automated CVS/SVN support, greatly helps organize files without needlessly creating a thousand folders to store your files in, builds everything as you ask it to, and offers instant support at your fingertips. XCode is awesome if you know how to use it correctly.
But, if you are a C or Perl hacker who likes doing things from the command line, that's quite alright as well. If you're programming on the Mac, you're most likely making a GUI for something UNIXie already, so you're probably going to want to use XCode, if not for its instant support to Carbon documentation, than for source code highlighting and autocomplete (which isn't as good as Visual Studio's autocomplete, but it gets the job done).
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
Remappable Modifier Keys
e s.html
Remap modifiers such as control and caps lock to be super elite.
http://www.apple.com/macosx/newfeatures/newfeatur
On a related subject, if I wait until May to buy a Mac Mini, will it come with Tiger and X-code?
"Freedom means freedom for everybody" -- Dick Cheney
Cocoa Programming for Mac OS X by Aaron Hillegass is an excellent place to start learning how to use all the cool Mac-specific stuff.
Everyone has (and will continue) to discuss Xcode.
.NET web apps at work on XP but have a Mac at home. there are a good many differences:
.Net and it is way different developing .Net apps with the IDE in Visual Studio. I have developed php apps on the Mac and used TextEdit and BBedit (a great OS X only editor). IMHO, seasoned coders who really know their stuff will do well transitioning from VS.net, beginers will have a few less crutches to use.
I can give some insight into the question of learning curve.
I develop
- The mac is like Linux. Get used to the Linux command line. If you don't know basic commands like LS instead of DIR then the curve will be steap. If you have used a *nix system or are a quick study, I would pickup an O'reilly book and get up to speed with things like user permissions (CHMOD) and GREP and the Pipe "|" for automation. Also know than things like Chron jobs replace Windows Scheduler. Get a book adn take the few hours to skim it. It will be a great reference if nothing else.
- Perpare yourself for more text editor usage and less sophisticated Integrated Developer Environment (IDE). Okay, let the Apple Xcoders begin their flame. I really feel that MS got some things very very right with Visual Studio
- You're gonna need an office suite. MS Office.X is great, but for the money, I kinda like OO.o and use NeoOffice/J myself. A Mac alternative to Visio is OmniGraffle and is better IMHO.
- Get used to few, but higher quality choices. Okay, this one is touchy too but there are few fewer choices for software and websites to Google for a problem but the ones you do find for whatever the task might be are of better quality I think. Apple does a great many things right the first time so even if an article is written for Jaguar, it may very well work under Tiger, etc. I have found this very frustrating as I try to install something under IIS 6 with a document written for IIS 5 for example.
- Don't underestimate the hardware. Okay, your budget, your choice, but I would be more inclined to recommend to a serious developer buying a Power Mac (watch out, rumors of new updates in May so careful with the timing) over a Mac mini. The Mac mini is great for a home user wanting to check email, but if you are going to develop, compile, and potentially deploy Web Objects and such, don't underestimate the G5's supperiority to it's 32-bit father. At a minimum, follow all the recommendations and get 512mb ram (I have a Gig and use it).
Lastly, "Welcome".
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
Then install Mono. :)
I am pretty sure they have a Mac port.
As everyone else has said the development tools come with the mac. Kind of remindes me of the old AppleII days
Makes me wonder if Microsoft will start throwing in Visual Studio with Longhorn.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Is all you need to write the sort of apps that you were talking about.
Xcode, as every other post has said, is free.
Wrt books, I'd recommend "Cocoa Programming for Mac OS X, 2nd ed", by Aaron Hillegass. Aaron has a lot of experience teaching NextStep, WebObjects and OS X development, and his book reflect that experience. It is excellent - much better than the O'Reilly offerings I've seen. Big Nerd Ranch also has a book about programming the underpinnings of OS X called "Core Mac OS X and Unix Programming." Haven't seen this version book yet, but apparently it's the spiffed up, published version of BNR's student guide, so I'd bet it's pretty well done. You can get both together for $96.20 from Amazon.
There are other good references, tutorials, as well, some free on-line, and some for purchase. Do some Googling and mining on Amazon or B&N to find one that suits your purposes.
BTW, OS X has some very strong scripting capabilities built in that you might find useful for the kinds of apps you typically develop. And, as someone else noted, Ruby and other cool hacking languages come shipped with OS X and work well with XCode. Also, Eclipse, with all its goodness, runs nicely on OS X.
Lastly, if you want to put the limitations of "modern" programming languages behind you and get back to the future of software development, OS X has some of the best OSS Lisp implementations. SBCL or OpenMCL (if you want to do Cocoa apps), plus SLIME and Emacs is all a real programmer needs, and it's all free. *grynn*
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
I opted for the free online plan.l
See the chart here: http://developer.apple.com/membership/details.htm
-- Boycott Shell
My three main bookmarks for Cocoa help right now are:
o rum/. htm
http://rentzsch.com/
http://www.idevapps.com/f
http://www.zathras.de/angelweb/x2004-12-05b
The main challenges with Cocoa are learning how to navigate project builder so as to connect things up, and figuring out all the undocumented interdependencies between Cocoa objects.
One of the things that really screwed me up for a long time was not realizing that the UI objects aren't re-entrant, so if you call a UI object from a thread other than the main thread, you're likely to get random crashes.
The biggest thing for me though was figuring out project builder - figuring out how outlets and actions work. This is particularly a problem because there's no file you can edit to do outlets and connections - you have to do it with the GUI, and it's extremely counterintuitive. Once you figure it out it's easy, though. So it's good to just type your way through a couple of tutorials just to get the hang of it.
If you want to look at some example source code, I have something up on sourceforge that's (a) not trivial, but (b) not heinously complex, so it might be worth looking at. http://www.sourceforge.net/projects/gofer
OK, speaking from an amateur's seat, here's my take on it. Get started with XCode, as it is free, and would probably be a good introduction to your Mac. Start with Objective C if you want to start with a powerful intro, or start with Mono if you want a somewhat compatible intro.
If you were interested in Java, I assume you would have said so at the beginning.
Personally, what little proprietary programming I've done has gone out the Windows (sic) and I now like cross-platform stuff much, much better!
Thinkingman.com New Media
(Google Your Fscking Question.)
python xcode
..I think that XCode is awful. It's horribly unintuitive and enjoys separating you from your code. When you just want to build a damn executable it has you messing with build targets and all sorts of garbage that I will never care about. Even Apple calls XCode "A New Way to Work" (headline half way down the page). Sorry, but I liked my old way of working - you know, where I was productive and didn't have to learn the quirks of your stupid IDE. If I was ONLY developing for the Mac I might take the time to learn it.. but I'm not, so I will never waste my time on it.
Anyway, I found that I was most productive in OS X by treating it like Unix. I use Scons to build projects (no more Make for me), and I use Eclipse as an IDE (or occasionally Emacs as a straight editor when I'm doing something simple). Eclipse is originally a Java IDE (which is itself written in Java), but it has a C++ development extension available from their site and works nicely with standard tools like GCC and GDB.
So I use Eclipse to edit code, configured to call a custom Scons script (that I wrote and maintain to build the project) whenever I hit compile. The C++ Eclipse extensions understand how to parse error messages passed back from GCC, so while IDE integration isn't perfect, it works well enough to be productive. AND I still get command-line compilation if I don't feel like using an IDE that day.
Best of all: Eclipse and Scons are completely free and completely cross-platform (Scons runs whereever Python does). And I have an identical development environment on Windows (using the free MingW32 port of the GCC compiler), Mac and FreeBSD (although of course, my Scons script handles the multiplatform compilation issues internally, such as which system libraries to link with on different platforms).
(Disclaimer #1: I'm actually writing OpenGL applications via the SDL multimedia library - your milage may vary if you need a full UI, but I'd try wxWidgets if that were the case).
try
http://pyobjc.sourceforge.net
If you're serious about Mac OS X development and want to write applications which blend in well with the Mac environment (necessary if you expect Mac users to actually want to use your applications) then you must learn how Mac applications are supposed to look and behave and figure out how to apply the Human Interface Guidelines to your application. (Note that the HIG is not always 100% accurate .. there are places where you should deviate from it slightly in order to match what Apple's apps do.) This is important, as if you do anything unMaclike then your application will be bashed as a bad Windows port (even if you wrote it from scratch) and no Mac users will touch it.
.. it is much improved.) Carbon is straight C code, and the concepts involved are more similar to Windows or X11 than Cocoa's design. But it's big and complicated, and would take a long time to learn. Also, there's a lot more stuff that you have to do in Carbon to make your application behave properly.
... they no longer promote the use of Java in Cocoa.
... well, the Xcode IDE and all the GNU tools (gcc, gdb, etc.) come with Mac OS X, so you shouldn't need to buy anything.
You have two ways to go in terms of APIs. Cocoa and Carbon. Cocoa is a refined version of NeXT's OpenStep. Carbon is a cleaned up version of the old Classic Mac OS API (but with a huge number of changes
Cocoa gives you most of the behavior for free. You'll write less code, and you'll probably end up with a more Mac-like application. (It's entirely possible to write a a well-behaved Carbon app, but you'll have a lot more to learn in order to do it right, as fewer things are done for you automatically.)
With Cocoa you'll have to learn Objective C. This is not a big deal. If you know C, then you can learn the handful of additions which comprise Objective C in less than an hour. It's a very simple language.
Theoretically you can program Cocoa apps in Java, but I do not suggest that you attempt this. Java does not really fit into the Cocoa model very well (it's not nearly dynamic enough) and was shoehorned in as a way to attract developers who refused to learn ObjC. This was a mistake on Apple's part, and they seem to have realized it
I strongly recommend that you spend some time with Hillegass's book on Cocoa. Objective C an elegant language, and is certainly the fastest way to develop Mac applications.
If you are a diehard C++ fan, then you may be better off with Carbon, but there will probably be a bigger learning curve as the Carbon libraries are more complex. (Carbon has a long complicated history, from its Pascal roots and old Classic Mac OS constructs (resource forks, FSspecs, Gworlds, etc.) and repeated changes in design (GetNextEvent() replaced by WaitNextEvent() and then Carbon Events, QuickDraw replaced by Color QuickDraw and now by Quartz 2D) so it takes quite a while to figure it all out.
I'd give ObjC and Cocoa a chance first. You can always use Objective-C++ to combine an ObjC user interface with a C++ backend, if you need to port old code. Be sure to check out MacSTL as it provides some nifty stuff to treat some Core Foundation and Foundation objects in an STL manner.
As for tools
-- Tim Buchheim
The Apple Developer web site has a lot of documentation to help get you started. There are several paths you can use to develop Mac applications. Cocoa is the preferred way from Apple, and relies on an OO framework written in Objective C. They also offer Carbon, which is a procedural interface to a lot of the same functionality written in C.
I'd definitely recommend a copy of "Building Cocoa Applications" published by O'Reilly. It walks you through the basics of Cocoa, and also introduces interface builder, which is a very powerful tool for creating applications. It's possible to create fairly rich applications with no coding using IB.
XCode is a great code management tool. It has a decent editor, a good interface to CVS, and is much more intuitive than Visual Studio. (At least for me.)
It's good to use your head, but not as a battering ram.
If you're just looking to write little C++ apps to fill in the gaps (hey, that rhymed), then you should have no problem at all. gcc/++ runs from the terminal the same way it does in Linux. Everything is the same, libraries, commands, and all. I frequently work on C++ projects between a Fedora machine, FreeBSD machine, and OS X; and if you didn't tell me which platform I was on, I wouldn't be able to tell you. Xcode, on the other hand, is a whole other beast. I use it somewhat frequently, but if you're used to working with source files by hand and doing your own Makefiles, then don't even worry about Xcode.
Although Qt is not exactly a "complete" development environment, it has a lot of tools that enable rapid GUI development and provides you with a comprehensive C++ API that is source compatible on Windows/OSX/Linux. We have been using it for commercial development on Windows and Linux for 3-4 years now and have had our eyes on OSX for a while. The GNU compiler collection should be available for OSX. Looks like it should be an easy jump, but you would still need a source code editor or IDE to help tie the it all together.
Another previously shareware feature
-mkb
You are not limited to using XCode on Mac OS X. Once you have the developer tools installed you can use Make and Emacs (or VIM, or whatever) if you want. You could even install KDevelop and use that, if you wanted. You can develop with Qt and its tools as well, if you want to go that direction as well.
You also don't need to develop in Cocoa, if you feel up to learning the lower-level Carbon APIs and do not want to write code in Objective C.
I expect that someone has provided Cocoa bindings for Python, if you want to write "native" look apps with that. However, the existing Tk interfaces just work.
Xcode is mainly for programming Mac Apps, but Eclipse is an amazing IDE for JAVA that allows for code completion, automatic generation of classes (that extend classes), and has a multitude of plugins (UML, textToHtml, etc). If you want an environment that closely resembles .NET, you have to go with Eclipse.
The other cool thing is that Eclipse is available for Windows as well, so you can easily edit your code with either of your machines because Eclipse allows for CVS projects. Another option is Netbeans, but that is not really an option since Eclipse exists.
Susanna: NO! A si NO. Octavio: Pos...entonces como?
Whether or not it's comparable is debatable, but every copy of OSX includes XCode, which is a full suite of graphical and command line development tools: programs, libraries, examples, and copious documentation. And it's free.
So there's that.
Additionally, if you get a copy of Tiger -- which a Mac bought now should either include or be eligible for an upgrade to -- then you get Dashboard, which will let you develop small desktop applications using, as I understand it, Javascript as the development language.
So there's also that.
Additionally, if you get a copy of Tiger, you will get Automator, which is a kind of graphical scripting application that can do all kinds of things. From what I can tell, it is going to be great in all the ways that the appropriately-acronymed AppleScript Studio wasn't.
So there's that, too.
Plus, every version of OSX has supported the full range of Unix shells and scripting languages, so you can write command-line, X11, and sometimes Aqua-based graphical applications using languages such as Perl, Python, Ruby, the Bourne shell, etc.
So to top it all off, there's that.
And to drive the point home, you get all of this for free with every Mac. I've heard nice things about Visual Studio, and maybe there's a lot it can do that the Mac side doesn't have, but I strongly suspect that the full range of programming, scripting, and automation tools available on the Mac will run rings around it without costing you a dime more than the cost of the computer [and OS, if you're upgrading, which you won't be in this case].
DO NOT LEAVE IT IS NOT REAL
http://www.mono-project.com/Mono:OSX
>>XCode is far too bulky
As compared to Visual Studio?!? Woah.
Visit these sites:
CocoaBuilder for the Mac OS X and Cocoa developer list archives.
CocoaDev is a Cocoa developer Wiki.
I find that 99% of the questions I have can be answered by these two resources (especially newbie type questions -- which you're bound to have in a new development environment.)
-ch
Yes, I know you said 'apart from xcode', and I agree (though in my case I'm happy about it) that knowledge of unix is beneficial - I just think your comment over-emphasises the need to know unix... it's not necessary, it just helps the advanced/intermediate programmers.
No flames, just a difference of opinion.
Simon
Physicists get Hadrons!
If you buy a system today, you'll get Panther - and the ability to buy an inexpensive (~$10) upgrade to Tiger.
This doc is invaluable for Win32 programmers moving to Mac OS X.
Mac OS X has X11 if you choose to install it with the BSD subsystem. Terminal, yep. If you want to go IDE-less you can use GCC on the command line. Fink! Download Fink Commander for hundreds of 1-click compile and install OSS. BBEdit is a nice editor.
Personally I like XCode. I do most of my coding in it. I don't really like the SCM support, but svn on the command line works fine. C++ development is fine; you can use the Carbon API.
For my school Java projects I work in Eclipse. Which, incidentally, works just fine also.
---k--
</stupid>
Sure everyone else is telling you how great it is but if you're not going to do serious app development there's just no point in learning it.
The cross platform stuff works just fine. I've written apps for my Mac using Java, Tcl, Perl and Qt. If you don't mine X11 stuff you can use just about any X toolkit (eg. Gtk). I think WxWidgets works natively on the Mac too.
None of these is all that similar to MSVC.NET but at least they work on Windows and Unix too.
You don't have to drink the ADC cool-aid, you can just as easily drop to Terminal, set up fink or darwinports, and treat your OSX box like the fancy Unix workstation it wants to be.
You know.. to fill in 'all those gaps' in non-existent system software.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Apple has a free mini-book that intros Objective-C and gives a good feel for its capabilities:
ObjC.pdf
I highly recommend it to anyone coming from a C++ or Java background who is wondering what the big deal about Cocoa is.
And if this little PDF catches your Fancy, Aaron Hillegass has an excellant book: "Cocoa Programming for Mac OS X". Another good book is "Building Cocoa Applications" by Garfinkel and Mahoney.
There are 10 types of people in this world, those who can count in binary and those who can't.
To the third point - ObjC objects aren't toll-free bridged to the Carbon libraries, they are toll-free bridged to Core Foundation, a procedural C set of libraries that is secretly most of what Cocoa is. But the end result is still that, if you need to, you can treat your Objective-C objects as C structs with no extra work.
(Stupid me. I tend to (wrongly) think "C == Carbon" when I think about the OS X libraries.)
I was you 2 years ago.... so listen up!
Coming from Windows, you will immediately be immersed in a new environment that is sometimes very different from what you are used to. Coding on Windows (as I do, I'm a C# developer at my day job) is a whole lot different than coding for the Mac.
I whole heartedly suggest that you buy a new Mac and dive right in -- but first you must learn how it works. The first thing you'll say to yourself is "everything is on the wrong side!". The icons are on the right, the window buttons on the left. If you think the differences end there, are you in for a surprise!
So first, use the Mac, become very familiar with it, and know it. Read books, visit forums, learn how it works "underneath".
And then start trying to find something to create.
So here are the steps:
1) Learn it
2) Know it
3) Code it
Good luck!
-Steven
"To make a mistake is only human; to persist in a mistake is idiotic." Cicero
Just wrote these today, coincidentally... 10. All the blue-coloured widgets and background images are good for the soul. 9. You can keep a Terminal.app window open and pretend to be a Unix hacker. 8. Crappy enterprise data access support means no horrible database programming. 7. People will think you're some kind of artist or writer or something else less socially leper-ous than being a programmer. 6. Interface Builder's NeXTStep heritage will force you into a Model-View-Controller architecture so strongly that even design-as-you-go nitwits like me will be saved from their own poor planning. 5. No matter what you do, Wired will eventually write a feature story about you. 4. All the built-in eye candy and automatic alignment guides will make you look like you know something about UI design. 3. The development tools don't cost more than what your stupid shareware program will probably earn you. 2. The Indian programmer who stole your Windows coding job can't afford to buy a Mac. 1. Chicks dig iBooks.
___
Cogito cogito, ergo cogito sum.
I have an old copy of Symantec C++ that I'd be willing to sell you. You can program console apps in C++ using SIOUX.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
If you want help programming, plenty of people have given links. If you want help with the interface end of things, try using some of the best Apple applications and see how things "work"--iTunes, The Omni Group, Bare Bones Software, Lemkesoft's Graphic Converter, Rancho's NetNewsWire. There are many others, but trying these on should give you a feel for what makes a great Mac App. Also, it is a commonly-perceived problem that there is no great mac Word-processing software. There are acceptable entries, including MS Office, and several others, but this is one area where OS X is gravely deficient (if you want to write the best Mac WP ever, feel free! I'd even buy a copy).
Lots of people (i.e., Windows & Linux Fanpersons) will deride many interface trends as "fluff"; do not make this mistake. Apple is pretty careful about what stuff they include, and while there might be a few things in there for no real reason (animated screensavers as you desktop background?), most of the "fluff" has a damn good reason to be there.
This is actually a great time to discuss this with Xcode 2 on the horizon. Xcode 2 is the newest version of Apple's free IDE that comes with their developer tools and can also be downloaded from Apple Developer Connection [Free Registration Required].
Along with GCC4.0 and new UML-graphing utilities, this next revision that'll be available on the 29th looks like it's really packing some enhacements.
I've been using Xcode 1.5 (the current iteration) to work with Cocoa Objective-C (see above for tons of info on the language) and coming from a platform neutral C++ and PHP background have found it very intuitive, and if coded correctly Objective-C is a pleasure to use. I can say that Aaron Hillegass' book Cocoa Programming For Mac OS X is a great utility, along with CocoaDev and Cocoa Dev Central.
Good luck!
I know they still make a compiler/IDE for mac and windows development, and they used to be THE solution for classic mac apps.
I know that XCode is free and quality, but from what I remember of using CodeWarrior it seemed much more advanced from an IDE standpoint. Of course, that was years ago as a novice programmer.
Still, if you're expecting something to replace VS.NET (which is what, a $500 product) CodeWarrior is definitely comparable.
Anyone with a little more knowledge on this want to chip in?
People who loved/used NeXTstep
- John Carmack
- Tim Berners-Lee
- Andrew Stone
Companies successful w/ NeXTstep (other than the afore-mentioned Omni):
- Lighthouse Design (bought out by Sun to do Java development)
- Stone Corp.
- the company MCI hired to create the database which made ``Friends and Family'' work --- they liked it so much, they bought the company
Programs w/ a heavy NeXT heritage:
- Doom
- WorldWideWeb.app
- TeXshop (Alan Hoenig's book, _TeX Unbound_ is basically a paean to to glories of Display PostScript w/ TeX)
- FreeHand (FreeHand 4 ~= Altsys Virtuoso 2 - bugs and w/o Services, DPS, &c.)
- Softmagic's Project M (their sole competitor gave up on trying to code an equivalent in Windows and licensed their product instead)
Oh yeah, and there's this little project called GNUstep....
William
Sphinx of black quartz, judge my vow.
Dashboard will be pretty spiffy.
putfwd.com - 1GB Free file storage with a twist
Further, if memory serves, it's actually syntactic sugar for objc_msgSend( object, "methodcall:", parameter );
Of course, if you actually use it that way outside the debugger, I hear Steve Jobs personally flies to your house and takes your Mac away from you.
YLFIOne god, one market, one truth, one consumer.
Since there's a free native Qt for Mac, you should consider that as one of your options. A lot of Mac purists will discredit this option out of hand, simply because it's not a Mac-first framework. Don't listen to them, and make up your own mind. One of the chief objections is that it doesn't force you into Apple's interface guidelines. But at the same time, there's nothing stopping you from voluntarily following them, so I don't consider this a valid objection.
If you're writing a bunch of small custom apps, and they don't need to be proprietary closed source, then Qt is free. Otherwise you do have to pay (gasp) for Qt. It's hard to tell from your description what you need, but I'm guessing you can get away with the free GPL version.
I haven't played with the Apple frameworks, but compared to Microsoft's that you're used to, Qt will be a breath of fresh air!
Don't blame me, I didn't vote for either of them!
An IDE should not be designed with 'casual users' in mind; it's a very different beast from iPhoto. I wouldn't make excuses for the lack of thought which went into xCode project preferences. They are a crude and confused interface to the command line switches. Preferences are stored in two places at once :
Build Styles
Target Info
and it's not clear which to choose when editing a particular preference (until you know the program), unlike most other IDEs which just use targets. Choosing a different build style will require a 'clean target' to actually recompile the sources with the correct options, and this makes the distinction entirely pointless.
I use xCode every day, and there are times when I curse the poor interface. The plethora of menus is most unmac-like as well, all those options need to be organised in sub-menus, or placed in a cleaned up preferences dialog and project prefs/info. There are 14 main menus and 29 submenus hanging off them. The contextual menu for individual items in the Groups and Files list is a hodge-podge of different commands, many of which have nothing to do with the file being clicked on (General Preferences??!?)
Simple things like choosing to edit in an external editor is under 'File Types' in the prefs (took me a little while to find this), and if you choose to use an external editor you have to use 'Open As' in a contextual menu when you want to open in the xCode editor to set breakpoints. (Perhaps I've missed an option here).
The program seems to be me like it does an inadequate job of hiding its inheritance from PB and use of command line tools. Contrary to your assertion, important options are hidden/in two places at once and obscure options are left easily visible. It's also not particularly stable. However it's free and they are improving it and listening to feedback.
WHICH GODDAMN GUI CODER IS GOING TO CODE IN FUCKING BBEDIT????? I have quickly skimmed through a number of replies here, and it seems that platform zealotry is once again out in force, with anyone mentioning Xcode being modded to +5 immediately and the same happening to anyone mentioning VS.Net. But the kicker is, and I think this is especially true in the parent's case, is that a fucking web application is not the same as GUI application.
The reason I think the parent is a web coder is because he mentions TexTEdit and BBedit for coding. WHICH GODDAMN GUI CODER IS GOING TO CODE IN FUCKING BBEDIT?????
Comparing a php app written in BBedit and an asp+ app written in VS.Net is less than fair and pure trollbait, since I cam write a php app in notepad on Windows as well, but I would need to be seriously dumb to do that wouldn't I?
I've used Runtime Revolutions' DreamCard for the PC and it's Mac OS X version seems just as competent. It's a holdover from the HyperCard days apparently, but the IDE is OK. The scripting language seems Basic like but the syntax can be a little odd. Might be worth looking at though.
/.'ers will probably sneer at these tools since they aren't C and possibly aren't enterprise level solutions. But for a quick tactical level program, they might make for a good solution.
If Basic is not to much the turn off, then perhaps RealBasic might be worth a look. The IDE and language remind me of a combination of the VS6 and PowerBasic products combined for OS X.
Again, most
Probably worth less then $0.02, but I thought I'd add some RAD into the conversation.
Isaiah 43:19 (NCV)
Look at the new thing I am going to do. It is already happening. Don't you see it?
An alternative C, C++, and Obj-C environment (IDE) hosted on Mac OS X for development of C, C++, and Objective-C applications for Mac OS X as well as Mac OS 9 (a.k.a. Classic) platforms:
n tosh/Default.htm
http://www.metrowerks.com/MW/Develop/Desktop/Maci
It's $499.00 in Metrowerks' online shop.
Someone actually changes their mind on Slashdot, in response to logical arguments and facts? That's gotta be a first!
Someone tell Taco to get out the record books!
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
``babbage'' had said:
>On OSX, the platform -- not counting the Unix foundation -- is young
How can this be the case if it was possible for Andrew Stone of Stone Design to ``port'' Create.app from NeXTstep to Mac OS X merely by recompiling in Mac OS X?
Or are you saying that everything which Create.app makes use of was available for Unix starting back in 1989 and is a part of the ``Unix foundation''?
NeXTstep was _a_ Unix, but it included a lot of stuff which is only now becoming available for other systems, and Mac OS X has a much more mature implementation of these things (Cocoa, nee Rhapsody, nee Yellow Box, nee OPENSTEP) than anything else, an implementation which goes back to 1989 or so (if I were home I'd check the copyright date on Create.app on my NeXT Cube).
William
Sphinx of black quartz, judge my vow.
Just my $.02:
..
- While XCode is free, even for miniature projects it can be dead slow. Commercial alternatives like Codewarrior offer better C++ standards compliance and compile speed but thanks to Apples "We integrate documentation access hardwired into XCode and don't open it up" have a - erm - productivity gap when you need to read up documentation, which you will - as a newbie - probably do a lot.
- For the "Do your Mac stuff in Cocoa" recommendation:
be aware it is not a good idea to mix C++ and Objective-C exceptions, and spend extra time at the beginning to understand the memory management (wrt function name semantics) concept.
- I tend to disagree Cocoa documentation is superior. If you do standard stuff, you get a lot for free and it seems easy. OTOH, sone not so standard things can get rather nasty and extremly underdocumented.
Carbon had a lot of extremly good documentation that is not available any more, so if you start now and without that background it is rather hard to get into old and "legacy" based APIs.. If you dig into Carbon, there are often useful additional comments not in the official docs but the header files.
- Some folks recommended mono for CLI applications. Last time I checked debugging is not extremely advanced, and the compiler error messages are pretty useless. Far better in error diagnosis are provided with the MS sscli compiliers, while the sscli CLI implementation has extremely poor performance compared to mono. Mix and match, the CLIs are pretty compatible... And of course, as with most MS technologies, not every syntactic sugar documented on MSDN ist also in the C# standard and implemented in sscli or mono.
- For an editor besides XCode, try BBEdit from
For Java in an enterprise setting you have:
- eclipse - very good IDE
- oracle 9i database on OS X
- JBoss j2EE App Server ('Like' MSFT Transaction Server)
- Ant - build utility
Java Server Pages work but I don't know of a good screen builder.
Java code developed using the above is portable across MSFT and Unixes.
Those are good points regarding Build Styles and Target Info.
I stand corrected.
As so many others have pointed out, Xcode won't cost you a cent beyond whatever you decide to spend on a Mac (which could be anywhere from $500 to $3000, depending on you). And there are lots of free resources for learning about Mac programming, and lots of books.
.
If you want to get a taste of the cutting edge of Mac development, however, go to developer.apple.com and buy yourself a ticket to Apple's Worldwide Developer Conference, a.k.a. WWDC. Depending on where you live, you may also need a plane ticket and a plane ticket and a hotel room or a pal in San Francisco that you can crash with. Anyway, at WWDC you'll meet a few thousand Mac developers and attend sessions given mostly by Apple engineers on
Attending WWDC is definitely not something you _need_ to do, particularly if you're just starting out. But it's a lot of fun, and you might just see stuff there that will make you decide to sell your PC.
If you decide to do it, do it soon. You can get a WWDC ticket now for $1295, but prices go up to $1595 on April 22.
Actually, that's an optimization strategy in Objective-C programs. If you're sending a message many times in a tight loop, obtain a pointer to the C function and call it directly. That cuts out the (small but non-zero) overhead of the Objective-C runtime message dispatching.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
All I have to say is that Apple documentation is very bad and mostly unhelpful. Learning Cocoa/Objective-C from oreilly is near useless. In fact I did 2 examples from it following its directions and havent used it since. Learning Objective-c and Cocoa to the point where an advanced reference is what you need is borderline trivial. I suggest not bothering with introductory texts and simply grab some examples work through them, muck around with adding a few controls to them and you will be all set.
Really, if you know C you will have no problem moving to Objective-C, and Cocoa is in my opinion very very intuitive making MFC look like a bastard child.
I use it daily and have for years. Honestly, this is one of those cases where a new version (VS .net) offers little over old versions (VS 6), but has gotten unstable and twice as slow in the process. VS 6 was kinda clunky, but it got the job done without any serious drawbacks. VS .net, though...I've switched to using external tools as much as possible.
No, that's not an optimization strategy.
The function objc_msgSend(object, messageSelector) implements Objective-C's dynamic (runtime) binding. It looks up the method (a plain C function) that object associates with messageSelector, and then calls that method.
An objective-C message expression is nothing more than syntactic sugar for calling that function, so calling the function isn't any kind of an optimization.
However, if you're going to be sending the same message to the same object over and over again in a tight loop, and that loop is proving to be a bottleneck, you can get a pointer to the appropriate function outside the loop, eg
IMP functionPointer = [object methodForSelector: messageSelector];
and then call the function (through the pointer) inside the body of the loop, completely bypassing the overhead of Objective-C's dynamic binding.
(I mention loops because that's the only scenario in which I've ever needed to bother with this technique, and even then, it's rarely been an issue. But the API is available to use anywhere you want in your code.)
That's the optimization you had in mind.
PS: I know you know. But others might not.
Thanks.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Cocoa Bindings and Core Data.
Objective-C is nice. XCode and Interface Builder are nice. But this stuff quite literally does for desktop apps what Ruby on Rails does for web apps.
OK, I'm late to this thread, and no doubt you have a clear picture already. But I'm a long-standing Mac developer steeped in C++ who also recently bit the bullet and changed the way I program on the Mac (from Carbon/C++ to Cocoa/Objective-C). OK you may say, but that's not as big a leap as Windows to Mac... well, I think it is. There are very few overlapping APIs, unless you want to use Carbon within Cocoa, which so far I have found very little need for except a bit of bridging to QuickTime.
So: 1. XCode comes with the OS. It comprehensive, it's good. I'm still learning it, but the basics are easy to grasp and you can fill in the finer detail as you go along.
2. Objective-C is a VERY SMALL addition to C. You can learn it in half an hour especially if you know C++. The syntax might look odd at first glance but it works, it's consistent, and it's only syntax!
3. The framework (Cocoa) is huge, and takes longer to learn. However, again you can get going very quickly because XCode will build a fully functioning app for you with no coding at all, then you can use that as a base on which to experiment. Personally I'd suggest you do spend a bit of time experimenting without trying to build a huge new app first go, because there are different ways of doing things, some not as good as others. But gradually the picture becomes clear.
4. Get a book. I recommend Aaron Hillegass's tome - well written, easy to understand, the examples work, and it touches on a lot of useful areas of the framework though in some cases could do with a bit more depth. The O'Reilly book is not as good in my opinion, I found it only started to make good sense after I'd read Hillegass and actually tried out some coding.
5. Be prepared to be amazed at what Cocoa can do and how it works. After years of C++ grinding, Cocoa is a breath of fresh air to me. Objective C is so much to the point, but avoids all that syntactical cruft that C++ has. It makes me realise that half the code I've ever written was there just to keep the language happy, rather than contributing to my actual productivity. Objective C's method lookup is incredibly flexible and makes things possible that you wouldn't even think of in C++. In that respect a C++ background can be a liability - many things turn out to be much simpler to do te Objective-C way than what you might think of at first. For me this was one of the steepest aspects to the learning curve, but also one of the biggest revelations. For example, look at how Undo is handled - it's gobsmackingly easy. After a while you'll start to wonder why other platforms don't have anything like this. Cocoa is what Java could and should have been.
6. Enjoy yourself - it's fun to program in Cocoa. Once you get on top of it you may find, as I have, that your programming ambition suddenly increases enormously. With Cocoa I feel I COULD write a Photoshop killer, if I wanted to....
After you've installed XCode, go to
t or ial/objctutorial.pdf
Developer/Documentation/Cocoa/Conceptual/ObjCTu
It is short and sweet - really well done and helpful.
I went seriously overboard in that post of mine, and I apologise. I totally misread your post and assumed you were trolling. My mistake.
Now, on to the (real) comparison. While, obviously, for web apps, and I mean large scale web apps, VS.Net is much better than XCode, I think it would not really be fair to compare the two for that purpose. If someone were writing largescale web apps on the Mac, i.e. enterprise stuff, they would almost certainly be doing it in Java, and for that they would most probably be using some of the Java app server tools and large Java IDE's. If they were constrained to Apple's products, they would be using WebObjects, which, while it isn't free and is in fact quite expensive, does compare more or less with asp+ in VS.Net.
However, for common GUI code, XCode does compare quite well, especially with IB and Cocoa bindings, and above all, it is free and comes with every Mac, as you know.
Again, sorry about the flaming. If I could delete my post further up, I would.
I've read (though I can't personally confirm) that the objective-c message dispatching caches the function address after the first lookup anyway, so the optimisation won't end up saving you as many cycles as you'd expect.
This sig is false.
Everyone here has really done a very good job of talking about the pluses of Obj-C, Obj-C++, XCode, and so on. But nobody has yet (sorry if I missed someone on this) talked about the ease of use of Interface Builder, the GUI builder that comes along side XCode. And even more interesting for an application developer would be Cocoa Bindings.
For Application development, Cocoa bindings allows you to implement the model-view-controller paradigm without writing much, in some cases any, controller code because Apple has already done it. Check out Delicious Monster's app Delicious Library that was written largley (maybe totally, as I've also heard) using Cocoa Bindings.
Cocoa Bindings will be found in Interface Builder under the Bindings tab on the Inspector window. When you fire up a Cocoa app in XCode, you will have a NIB (NeXT Interface Builder) file, or two. Selecting and opening those files will take you where you need to go.
In Interface Builder 2.5, which is freely included in Tiger, they have enhanced Cocoa Bindings since bindings were introduced in Oct. 2003. And, if you don't like accessing bindings in the UI app Interface Builder, you can always code it in directly through the use of key-value-coding and key-value-observing.
If you're writing an app, one of the things that Cocoa Bindings does is get you head out of the code and into the Interface. I have found that, in making the interface first, I actually don't need some of the routines I thought I would need. Better yet, by not having to write and debug allot of controller code, my dev cycle time is allot shorter than it otherwise would be.
I don't program in Windows. But my Windows friends tell me that there is nothing like Cocoa Bindings on the Windows side. I think you'll like what you see.
Good luck! I think you'll have as much fun as I've had.
Let us go to the stars, dream new dreams, and renew the embers of hope that have long since grown cold.