Slashdot Mirror
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?"
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?
You can use Xcode to program in almost any language you choose Cocoa, C, Java, Ruby....
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
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.
Different, yes, but also very simple, so don't overestimate the level of effort required, assuming you know C.
Objective-C is an object-oriented extension to C, like C++, but it took a very different approach than C++. While C++ is large and complex, Objective-C is small and simple. The syntax is deliberately based on Smalltalk syntax, so if you know Smalltalk you'll have even less to learn. If you don't know Smalltalk, though, keep in mind that Smalltalk is a language whose syntax and rules you can literally master in an afternoon. Objective-C has added some new ideas, such as "categories" that Smalltalk didn't have, and there are some interactions between the Smalltalkish syntax and the underlying C syntax, so Objective-C takes a day for a C programmer to fully understand, rather than an afternoon (C++, of course, takes months).
For C++ and Java programmers who've never seen Smalltalk or another completely dynamically-typed language, I caution you to go slowly at first and take some time to understand the Smalltalk/Objective-C idea of what an "object" is. Or a "class". It's tempting to just dive right into the syntax, figuring that you know the "OO stuff", but the OO stuff in question is just different enough that you'll tie yourself in knots if you don't take a few minutes to understand what the differences are.
For experienced C++ programmers there's another interesting goody waiting... Objective-C++. The Objective-C and C++ extensions to C are orthogonal, so you can actually mix Objective-C and C++ code at will. Objective-C methods can take C++ objects as parameters and vice versa, and they can store pointers to each other.
The result is a very powerful language that lets you choose between the flat-out on-the-metal efficiency of good C++ code and the extreme flexibility of late-bound Objective-C code. And with C++'s polymorphism and Objective-C's categories (which provide limited compile-time typechecking) you even have a couple of steps in between. Be very, very, careful though. It's easy to create an unmaintainable mess when you start mixing things.
BTW, I should make a disclaimer here: I have looked at but never written code for Mac OS X. Everything I know about Objective-C comes from when I used to own a NeXT machine, so there may be a few differences. Based on the OS X code I've read, though, I don't think there are very many or that they're very large.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I don't know if I would call it awful, but it's definitely not all it's cracked up to be. Everyone here seems to be chanting, "Xcode, Xcode..." but I wonder how many of them have actually used Xcode on a project or if they are just echoing the conventional wisdom. ("It's free! And it's from Apple!")
Now, I haven't tried Xcode 2.0 in Tiger, but I have certainly made some sincere efforts to use Xcode 1.5 for my C++ and Java projects, and each time I've given up and gone back to a plain old programmer's editor and the command line. Although I loved the debugger, trying to set Xcode's compiler options and other parameters is a nightmare. Everything seems buried in different places for no apparent reason, special buttons have to be clicked in order to switch to a certain mode that will uncover hidden settings, etc. It's just not very easy to use, and it takes quite a bit of getting used to. It's definitely not a shining example of usability, especially given Apple's reputation.
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
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.
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!
But most of all, my impression is that if you're using the Cocoa libraries and the Java language, you have more or less given up all the benefits of the Java platform (such as the ability to write platform-independent apps)
Depends on how you code things. We have a fairly large app written in Cocoa/Java and if you work to abstract things out a bit you can cut the amount of OS X specific code down quite a bit. For example, we have a GUI that runs under Cocoa and Swing. By factoring the code properly (Model-View-Controller) the Cocoa specific part is about 10% of the GUI code.
If you're not planning to run on anything other than OS X, though, I'd say that the pain of trying to use Java is about equal to the pain of using Objective-C.
The reason I think the parent is a web coder is because he mentions TexTEdit and BBedit for coding.
.NET web apps at work on XP but have a Mac at home. [/]
Wow, you're a real detective!
[from the parent "troll" I authored] I develop
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?
This comment is completely inaccurate. First of all, to write ASP or ASPX pages, one does not need VS.net, all they need is a text editor (one could even use "copy con foo.asp" from the command line if they wish!) The same holds for php, HTML, css, perl, etc on all platforms, Mac or Windows.
What using an editor like BBEdit gets you is a customized environment to provide contextual command support for the language of choice (php, asp, perl, coldfusion, etc). What Integrated Development Environments (IDEs) like VS.net and XCode get you (besides a compiler) is the ability to harness the power of object oriented coding right in the editor so you get the power of an editor + compiler + object access right in the code.
BTW, your Caps Lock key is sticking.
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
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
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.
You know Model-View-Controller? Interface Builder is a tool to build the view, and tie it to the classes of your application. Before Cocoa Bindings and Core Data, you would create a custom controller class or two, and connect them up. This button fires this action, which calls this method of MyAppController. MyAppController updates the model, then does some updates to the view. Grueling, thankless glue code.
Cocoa Bindings are a set of generic controllers, coupled with some tools in the IDE, that let you bind the view to the model in various complex ways while writing no boilerplate glue code. Say you have an array of objects in your data model. Cocoa Bindings lets you use an NSArrayController and a couple of straightforward bindings to say, "Fill this combobox with the 'name' field of each object in this array, and when a selection is made, populate these other fields with their other properties."
Core Data, though you didn't ask, is a set of generic tools that take care of the model, and gives you things like data persistence, undo, etc. for free. With Core Data and Cocoa Bindings together, you can go so far as to build UI scaffolding -- you literally drag one of the entities from your data model into a blank window in interface builder, and it builds a prototype interface for you. Not one you'd want to actually use, of course, but it gets you going and makes for a nice demo (see: Ruby on Rails hoopla).
As you might imagine, these tools take care of a lot of the grunt work of building graphical applications.