I would go further. What I have always wanted is simple: a compiler. I believe that the only way to get one on a Mac is from Apple itself, though I would be happy to take a compiler from a third-party. I don't want to be a Mac dev or an iPhone dev. I don't want their IDE. I want a compiler.
So far as I know, the only way to get gcc (or any other compiler) initially onto a Mac is by accepting the entire Xcode package. I'm posting this here because you mentioned the 3GB download, which always makes me cringe. I'm curious to see if anyone knows a better way. (I've had this conversation online in a number of places in the last few years, but never received an alternative.)
I'm not sure why you linked to the darwinports web site, it’s a domain squatting site, not at all linked to the original darwinports project, and I believe one of the reasons they changed the name. Even without this, darwinports, not macports, have ever (really) supported binary installs, which means you need a compiler (namely gcc) to get this LLVM package installed.
I've always had good experiences with the MacPorts gcc and nowadays they even have clang. Download MacPorts, run "sudo port install gcc", and go get coffee. Altogether much less than 3 GB. The only caveat with MacPorts is that you should make sure that the package you're downloading is fairly recent since some maintainers neglect them.
You don't have to actually install the full xcode IDE. You can do a minimal install of XCode from the installation CD, enough to get the required dependencies, and then install gcc from macports.
This is not a bad thought, but it runs afoul of Apple's strange choices. If you view the "Custom" install of Xcode, there are five parts:
1. Essentials (1.75GB)
2. System tools (56.8MB)
3. UNIX Dev Support (563.7MB)
4. Documentation (Zero KB - sic! More seriously, it's a download at next boot, hence zero KB of stuff is installed immediately from the disc. Why they don't report the size of the later download, I don't know.)
5. Mac OS X 10.4 Support (Zero KB - again, sic!)
By default, 1-4 are selected and 5 is deselected. But here's where it gets interesting: you can only deselect 2-5 manually. 1 is a must. Care to guess where Xcode lives?
Here's how Apple describes "Essentials":
> Installs Xcode, Interface Builder, Instruments, Dashcode, Quartz Composer, GCC 4.0.1, GCC 4.2.1, llvm-gcc 4.2.1, GDB, and other developer tools. Also installs the Mac OS X 10.5 and Mac OS X 10.6 SDKs. All content is placed inside a location chosen by the user (default is /Developer on the boot volume).
I feel like John Belushi in the old "All I wanted was a pony, but nooooooooo" skit.
But you can re-direct the location for the installation of Essentials. It has "Other". Point it at an external drive (USB, whatever) and then wipe it. Make sure you install UNIX Dev Support - it will go onto the boot volume (and the gcc compilers come too.) And make sure to de-select "Documentation" if you don't like surprises later.
Deploying a major release as a diff to a complex development environment is far from effortless. They probably figured the effort vs. payoff ratio didn't work out, compared to making improvements to the product itself.
I remember having to upgrade VS 2005 to VS 2005 SP1. It took 2 hours to apply the changes.
And it was difficult to tell if the updating application froze or was still working. So while patching is nice, it is a huge effort to get it done cleanly.
Source control applications don't generally worry about dependencies, and they also generally aren't concerned with multiple projects.
Using .NET as an example, the SDK patches would include:
Drivers
DirectX
XNA
WPF
BackOffice
SQL Server (or Express or Lite or whatever they call it)
System libraries
ASP.NET
C#
F#
ILR
C++ .NET
VB.NET
And the list goes on.
Apple's developer kit has a similarly vast suite of libraries and services, I just don't know all of their names. Each one in isolation wouldn't be all that big a deal, but combine them and you have the option of massive downloads or a nightmarish dependency management problem.
With Visual Studio for example, it's not only about merging files, but installing various DLLs (for the runtime - vcredist*.exe), COM objects, .NET stuff, etc. Also creating (if possible) proper uninstalls.
VS2008 runs some SQLserver, PDBserver, and who knows what else (run ProcExp and see)
They manage it for typically-small changes. Try computing a patch for the differences between major revisions of a Linux project, and watch how long it takes. Then try to apply it.
I use XCode in "Condensed Mode": One source/header combo, one Window. And I like it a lot.
I've never been a fan of single-window IDEs, going all the way back to Visual C++ 6, and I don't think XCode 4 is going to be the one to change my mind. And god damn it, all the keyboard shortcuts have changed! This is going to be painful.
It's clear they've put a lot of work into it. It looks slick, and the organization of the menu and commands is much more thoughtful. The biggest problem with current version of XCode is that it's very difficult for newcomers to learn, and this new version will go a long way to correct that.
But none of that matters to me. I can't touch this software until I'm forced to use it, because when that happens I'm going to have to un-learn everything I currently know, start from scratch, learn all new habits, etc. Can't say I'm looking forward to it.
There's a WWDC session on Xcode 4 - free on iTunes U for registered developers. It might be worth a watch, as they will probably outline the most significant changes, as well as indoctrinate you with the belief that these changes are major improvements over the old way of doing things.
Oh man been waiting for this since WWDC. IB integration took way too long.
I do have a question for the compiler geeks, though: how was LLVM able to so quickly surpass GCC in both compiling source and binary performance, considering gcc had a two decade head start?
Having been at WWDC and played with it for a few weeks, I'm not sure I'd call LLVM a hands-down winner.
While there's a lot of win in terms of code readibility and the great interfaces it exposes if you're going to write an IDE that understands the code, I'm not convinced it's there yet in terms of binary performance.
My apps run around 5%-15% slower, on average, than the GCC -march= setting.
Probably because the GCC architecture itself no longer allowed for more optimization. Or to put it another way, it had been optimized as much as economically possible. Trying to optimize it further would get us to the realm of diminishing returns. At this point it is easier and more cost effective to simply re-design the whole architecture which will inherently improve the performance. LLVM was designed from scratch with performance being a top priority.
It has 20 years less baggage and 20 years of lessons learned of what not to do. And 20 years of CPU development, remember that when GCC was started there were no superscalar CPUs.
GCC isn't a particularly high bar to hit ICC and MSVC have been killing it for years.
It's largely the same reason that the ZFS codebase is drastically smaller than the UFS codebase. You don't think of the fastest / shortest way to do X the first time.
Not all the code works with LLVM, for example if you use LLVM to compile the linux kernel it won't boot.
Linux and GCC(GNU) have had a special relationship for a long time. It might be a while until LLVM can handle that task.
FreeBSD however will actually compile and boot. http://wiki.freebsd.org/BuildingFreeBSDWithClang . It's not completely foolproof yet. I think the BSD community has welcomed LLVM a little more warmly than GNU/Linux.
The OpenBSD folks have been searching for a replacement for quite some time now. IIRC, they even got their kernel building with the ancient PCC compiler, which is also BSD licensed.
Apple wants to use the actual compiler code in XCode and that wouldn't be possible with GPL and their current license. That is also why clang is structured as libraries.
It's one of the main ones, but two additional ones, depending on the person, are: 1) some people don't like GNU and/or Stallman having influence on their OS, either for political reasons or due to personality clashes; and 2) some people don't like GCC's design as a technical matter.
Thats what I was implying in my earlier comment. Though I wouldn't say its the only reason, in my view as an advocate of the BSD License, it's a major reason.
It actually hasn't. LLVM is consistently slower in most benchmarks. Not by a large amount, but it doesn't beat GCC for speed.
The thing is that most compilers these days are limited by the performance of the CPU itself, as they're getting within a few percent of the best you can do.
I can't imagine anyone actualy using IB, at last for anything but the most basic app. It just frustrates me no end, and I am pretty sure most people just create all the elements programmatically.
Since Cocoa programming on the Mac, sometimes in the cocoa-dev list the question "how do I design interfaces in code instead of using IB?" popped up, and the general consensus was always: "why do you want to do that? You are fighting against the environment. Use IB".
I've tried designing UIs without IB. I went thorough years of mailing list archives, several questions on StackOverflow and I don't know how many blog posts. Trust me, writing an app without IB is a stupid, stupid idea. IB is central to Cocoa development.
Not seeing the problem with IB here. I use it extensively for generic UI elements, with custom views and windows, use it to target the FirstResponder, use it to hook up actions, connect controllers, and to bind objects together - all of things IB (and now Xcode 4) were made to handle.
- It's incredibly brittle. Good luck if you need to make significant changes to your hierarchy, or change that NSOutlineView of yours to an NSTableView. You'll have to rebuild and re-hook up all of the connections on an object. With no warnings or errors if anything is wrong. In HTML, you can just copy and paste, change some tags, and make some adjustments. Now HTML isn't ideal for application layout - but another markup language could be (MXML isn't bad).
- Doesn't play well with source control. Only one user can work on a .nib at once. Just yesterday another programmer and I both made changes to UI. Of course, it was completely unmergeable by machine or by hand - what do you expect when you have GUI generating a 7000-line file for relatively simple UI. So one of us had to re-do several hours of work. This isn't a problem with, say, HTML.
- Most significantly, it only solves a small part of the problem. It completely falls down when you're dealing with dynamic / variable UI - you'll have to resort to code anyway. And a lot of the layout you need to do is actually inside cells - say, trying to build a source list like iTunes, or a table view with icons inside of it. IB can't help here at all. Then, you end up laying out the actual UI in code. And what code it is:
Are you serious? This is 2010. You should not need to be manually calculating the positions of UI elements. There should be a layout language. HTML, MXML, whatever.
IB encourages you to use a very low level of abstraction. There's a lot of repetition, and the closed nature of the tool means it's very difficult to build up higher levels of abstraction. But then again, I guess Objective-C loves loves making programmers repeat themselves.
There's a reason most professionals don't use dreamweaver to make websites, either. And they are much the same.
I'm pretty new to Mac OS X programming (coming from a very hobbyist cmdline/web app python background) so using an IDE has been pretty weird for me. I found the disconnect between IB and XCode the most difficult thing about it, it's like there was another layer of programming you couldn't see immediately (the connections) which made it harder to slip back into a project if you hadn't touched it for a while. Not to mention the fact that every time I picked up this project (it's an after hours thing that I don't get a lot of time to play around on) I would almost have to re-read a tutorial to remember how all the connections, etc. worked in IB. I think the main problem really was the disconnect though, so I'm looking forward to actually having everything there.
It sounds to me like you don't have a very good understanding of your software's design.
That's understandable. Most other IDEs handle GUI development by simply mashing the view and the controller together into a single unit. That is fine if you just have a simple window with some buttons and text fields, but this approach quickly falls apart when applied to larger, more sophisticated software.
The Cocoa approach is different in that it completely separates the view (the NIB or XIB) from the controller(s). You're free to design your views, controllers, models as you see fit, and Interface Builder is there to help you realize that design.
But you actually have to design your software; XCode is not going to hold your hand and shoehorn you into a specific design, like most other IDEs.
A NIB is still a NIB. That's not going to change just because XCode and IB are now a single application. You will still have to design your software, and you will have to understand that design.
But software design is hard, so don't be discouraged. It will come with experience.
This is completely true! I'm very much learning as I go -- back at university when we did user interfaces it was all done in-code: I learned Java and TCL/TK without IDEs, then went on to do web programming and commandline stuff that didn't really need an IDE. So to actually start learning how to use an IDE I not only have to learn about design via IDE but also how the IDE works (also Obj-C, but that's another story) :)
And this is why I am still soldiering on with my little app (which is really just a learning opportunity for me rather than anything I plan on capitalising on, so it's okay for me to make mistakes :). I'd like to learn how to do it better, and you're right, that comes with experience. That said, I think the new XCode will help people like me a bit more because it will probably be easier to see the links between the UI and the code. :)
I find the mechanism of connecting UI elements to outlets by dragging around to be gimicky and pointless.
Why can't the runtime auto-bind them by matching names? Doesn't ruby work this way?
The whole point of having the action/outlet system is that it provides a layer of indirection and lets you write less code. There's no need to write an event handler for a button to make it print a view. You just drag an action from your NSButton to your view, and set its selector to print:. The same goes for outlets.
I'm not sure what you mean by "auto-binding by matching names". The only way I could see that working, is if you gave the control and the target names, then inputted the action as (control name, target name, action). IMO this would be a lot more work than the current UI.
I'm not sure what you mean by "auto-binding by matching names". The only way I could see that working, is if you gave the control and the target names, then inputted the action as (control name, target name, action). IMO this would be a lot more work than the current UI.
Well, I was referring more to linking IBOutlets as opposed to IBActions.
I think Visual Studio's way is superior - ie, from the UI Designer, you can autogenerate and link the action for a button as well as having the option to link an existing action.
Well, I was referring more to linking IBOutlets as opposed to IBActions.
You still have the problem of selecting the object owns the outlet. You may want to connect a text field to an outlet on a view nested down a few levels. You'd have to give both the text field and the view names, which again takes time and effort.
I think Visual Studio's way is superior - ie, from the UI Designer, you can autogenerate and link the action for a button as well as having the option to link an existing action.
I haven't used VS for quite a while. IIRC there is always a user class associated with the UI. This is not the case in Cocoa. It's common for file's owner to be, say, a plain NSWindowController, and there to be no user classes in the nib at all.
It's tempting to think of an "action" in Cocoa as being synonymous with a method. But this isn't the case. When you click a button, it doesn't directly call it's action on its target. The actual process is more complex, and provides a lot of room changing where the action message is sent. This is what makes insane magic that is first responders work.
It sounds to me like you've grown accustomed to a difficult, obtuse tool and don't like to hear that it is difficult and obtuse. That's understandable, you put in all that work to become proficient at a needlessly complex tool and it bothers you to see how simple interface design can be with a better tool. It makes you feel superior because you trudged through a hopelessly befuddled design and now that you've mastered it you can feel smug as you look down your nose at anyone who might dare suggest there could be a better way.
But software design is ever improving, so don't be discouraged when the world passes you by because you've stuck with your antiquated ways.
And 'visual tools' like IB quickly fall apart when trying to do dynamic layouts, or anything slightly out of the ordinary (in IB's case, you can't even do layout inside subclassed cells, necessary for almost any project).
This is a totally independent issue from view/controller separation. The right way to do UI development is through a layout language, like HTML/MXML, not through a GUI tool. The web world learned this a long time ago.
This thing has saved me hours of aggravation. You highlight a line in the struct part of the Obj-C class definition, and it generates the @property, the @synthesize, and a line in dealloc. You can also highlight multiple lines, and it will generate multiple properties. It is even smart enough to know that ints are assign, NSStrings are copy, and other objects are retain.
Or just LLVM 1.5 or LLVM 2.0, as there are C flags you can pass in that will make it so you no longer have to add ivars to your header and make @synthesize the implicit default.
Although I don't use XCode, I'm not sure how I feel about it suggesting minor fixes such as the == example. I enjoy writing a line seeing an issue and then solving it, or at least having to scan it with my eyes.
While I'm sure it's not an issue for most, I've always wondered whether that sort of thing breeds dependency. What happens when you don't have the IDE? Do you forget how to scan and fix minor issues? I've seen much worse... I've seen "professional developers" not know how to code or run projects without their all knowing IDE. Although I don't want to point any particular group out, many users of Visual Studio suffer from this issue.
I couldn't disagree more with this. I use what is IMO the gold standard for IDEs now - IntelliJ. One of its most undersold features is online static analysis. I've spent a lot of time working with Java and I actually study the language to a pretty deep level, but it still catches many, many bugs from stupid (== instead of equals) to very subtle (errors in initialisation order in the presence of overloading, synchronisation issues etc). I've actually learnt a lot about the language by using the tool.
I also can't speak highly enough about quickfixes. The ide presents me with a problem, and then makes it very easy to fix without having to think about all the crappy mechanics of doing so. If it's a common issue I can fix it all through my file, or all through my project. What is really amazing about this (as well as all the syntax-aware editing functionality) is that once you're good at it, you're no longer editing text, you're directly manipulating the AST at a very semantic level - and not just of a single file, but of your whole project. At the risk of gushing a little, this raised level of editing really contributes to my joy of programming because I'm actually directly manipulating turning my mental design into code. I would like to humbly suggest that people who say that you only need this functionality with crippled languages really don't know what they're missing out on.
Has this removed my ability to program Java in, say, Textmate or vi? No, although I'd have to re-learn so many basic, low level manipulation tasks that there's no way I could stand it. It doesn't remove my ability to develop using these editors, it removes my desire to.
Since the introduction of automatic transmissions many people haven't been learning how to shift a manual transmission. These people aren't necessarily worse drivers.
They are in the sense that they need to be picky about the cars they drive.
I've been using a manual transmission ever since I took my driver's license 10 years ago. At first I also drove a shitty car ... gears wouldn't shift unless you knew how to touch the gearstick :)
Now I can drive just about anything, with no accommodations necessary. Changing gears is also in my reflex and it doesn't bother me ... I just don't think about it. I can also eat a sandwich or talk to the phone with no hands-free while driving, although that's considered a bad practice that's also illegal :)
Well, I think the difference is even less than that.
People who never drove a stick-shift may have no idea how to operate one. Whereas someone switching from an IDE to a text editor would still be able to work - just less productive.
Apt metaphor! Sometimes driving a manual transmission can be fun (think wide open road), On the other hand, have you ever driven a manual in congested rush-hour traffic? It sucks! It requires a lot more work, concentration and sometimes it's literally painful (aching leg from working the clutch).
What you're talking about is a subset of technology itself.
With any (good) technology it becomes easier to do things and we gradually forget how to do the old, more complex way. I remember power going out at a big box (forgot which one) store once. None of the checkers had any idea how to figure out how much the items would cost by hand so the store was forced to simply not do business until power was restored. Was that embarrassing? Perhaps, but who cares? They can serve vastly more customers with the systems they have now than they ever could have with the old manual way.
With a big IDE you can manage vastly bigger projects quickly than you could with a text editor and a make file. You might point to the Linux kernel but most people who work on that just touch one area at a time [1]. With my big fancy IDE I can work on projects of at least that size and make big sweeping refactorings in seconds with complete confidence that nothing got missed.
[1] With the possible exception of Linus but if you're going to require that each of your devs be a Linus (or even that you have one for that matter) then you're probably not going to go far.
You'll notice that it's always bloatiest languages that have the most powerful IDEs. Look at Java/Eclipse. Now back to Ruby/TextMate. Most of the Haskell/Lisp developers I know just use Vi or Notepad.
The problem is, C is a language where = vs == is actually something you have to think about. It's natural that IDEs arise to address this.
XCode is fixing what is really a problem at the language level. So it's the wrong place to fix the problem. At the same time, trying to fix the problem at the programmer level (by forcing programmers to check = vs ==) is equally the wrong place to fix it.
It's a language issue, and that's the place it really should be addressed. But it will never be addressed there, because it would break backwards compatibility since decades.
"Most of the Haskell/Lisp developers I know just use Vi or Notepad."
Uhh, what? In Lisp's case, most people use emacs and coding Lisp in Notepad is mostly IMPOSSIBLE because trying to balance parentheses and navigate and indent s-expressions manually (and correctly) is idiotic.
In Python you can't have "if x = 3:" ... that's a syntax error. And Python also uses "==" for equality comparison.
There, problem solved.
I would solve the problem in Obj-C by introducing a directive on the file-level for the newer syntax, like how they did it in F# with the "#light" directive. And when a file is compiled with that directive, the compiler could trigger compile-time errors for those obviously dangerous constructs.
The '=' vs. '==' example actually nicely demonstrates the limits of automatic bug hunting. The variable 'rig' is NULL when it is being dereferenced, thus the program will segfault regardless of '=' or '==' being used. The "fix-it" tip is highly misleading.
(This is probably a side effect of PR people preparing the website; there is no reason why LLVM should not be able to detect this particular kind of NULL-dereference.)
I remember reading about how LLVM would be better able to interface with IDEs than gcc because it was library based rather than a giant monolithic system. It's interesting to see how this has been applied.
Today, Xcode 4 developer preview 2 has been made available for download.
No official release date for the final release is known, but judging from Apple's history with developer previews you can expect it to be out within 6 weeks.
Xcode 4 preview 2 is now available to Mac and iPhone Developer Program members (only the ones with paid subscription).
PLEASE NOTE: Xcode 4 is beta software --> Continue to use Xcode 3.2.x for production development.
And make sure to review the Xcode 4 WWDC sessions before you dive in!
I can't wait for Single Window, the multi-window design was possibly the worst interface for an IDE I've seen. I was actually very surprised how bad the UX for XCode was compared to the rest of OS X.
XCode already has a single-window mode. And as far as navigating multiple documents is concerned, it seems to work exactly the same as it does in XCode 4.
It looks from the screenshots that they are integrating interface builder into XCode and possibly (I'm hoping) the simulator as well? Even in "single-window" mode, you have to switch through multiple windows/applications in order to do development. The "build window", for instance, is unnecessary as it displays a lot of redundant information. A single window for layout, coding and debugging sounds useful to me.
The single window way to work in xcode worked very well in my opinion but I agree that the multi way that interface builder had and xcode had by default was the worst.
Bitching about calling it "visiting" files is like saying that OS X sucks because the close button is on the left side instead of the right side. What?
And saying "It's called Emacs" is a valid argument then?
By your reasoning every new scalable/clustered database or filesystem or server etc. is pathetic because, you know, "VAX had this 30 years ago". "What?" indeed.
As someone who primarily writes code in Windows and occasionally in Xcode on the Mac, I'm grateful for the fact that I use Vim - which doesn't require using any of the modifier keys to move around and edit.
Every time I'm sitting in the Xcode editor I'm constantly hitting the wrong modifier key or forgetting the key combination for delete-word-backwords or whatever.
Emacs has M-x compile, which also does debugger integration. You can edit the build file(s) directly, it's not that hard. I'm sure vim has the same thing.
Yes. With cocoa.vim, you can invoke Xcode's "build" and "build and run" right from MacVim. I haven't checked, but I suspect this feature uses AppleScript behind the scenes.
Is the convention of beginning a reply with "This." a Reddit meme? I'm beginning to see this more and more and it always irks me for some reason. Isn't an up-vote on the comment the correct way to say "This."?
FWIW I don't think this originated on reddit, I've seen it on fark and metafilter also (although it's pretty derided on metafilter if not followed by some sort of substantive response).
Gibberish. Not your comment, I just figured I would preface my reply with a single meaningless word that added nothing to what I was about to say, and if that's the convention, then it may as well be a word which actually means 'meaningless'. Over. (New convention, we'll end every reply with the word 'Over'.)
I liked that entire project — including targets and build steps — was in the tree view on the left.
Now tree view has been limited to be a file browser. Targets and build steps are now hidden deeper in settings windows and tabs.
To me old way was simpler and felt more elegant.
I'm not fond of "mystery meat navigation" — tabs have icons instead of text labels. I'm sure I'll learn that quickly, but it makes learning curve higher and on first impression UI looks more overwhelming.
Looks like very good improvement on the performance and to assist developer while development like fixing error stuff.. Till date I am not able to make any IDE whether xcode, eclipse or netbeans as my default editor bcoz IDE are damn slow... if I want to write program it should be open instantly... may be with new MacbookPro and xcode I can feel that way... then I can consider :) but definitely looks good...
What does it support for Ruby dev? I mean, I like TextMate well enough, but it doesn't even show suggested completions without hitting Esc, which doesn't jive for me at all.
Can you bind shell scripts to the run button? Code folding?
It's incredible to me that they can bring out major version 4 of Xcode and still not fix the most fundamental thing in a modern IDE - navigation. Until I can control-click on a symbol and jump to it, search for related objects (find my interface, find implementations of an interface, what overrides this etc etc) in my opinion it's just broken.
What do you mean? If I command-click a symbol in XCode, it jumps directly to the definition, and with alt-click it displays the documentation. I've been doing it for a long time, it's not new. What feature do you miss?
That's possible, I apologise if so - it's been a while since I tried to use XCode but a colleague told me they hadn't really improved the navigation recently. If command-click works that's a big step forwards.
I'd also expect navigation based on the semantics:
1. Find classes that implement an interface.
2. From a method in an interface find implementations of that method.
3. From a class easy navigation to the interfaces it implements.
4. Find usages of a particular method, either from the concrete instance or the interface equivalent that it implements.
I'm not very familiar with Objective-C but I'm sure that there's tons of related navigation that could make use of Posing and Categories, for example.
For 1. and 4. I use the "Find in Project -> as symbol" option. Not the best way of doing it, but decent. 2. is not available AFAIK. 3. is present, but only for inheritance and for header files inclusion, not for interfaces (called protocols in objective-c).
The LLVM website doesn't seem to have deprecated the clang name. Clang 1.1 is included with the LLVM 2.7 release. So what exactly is at 2.0, and has this thing been released?
Do not tell me that Dalvik VM is the same as VM from JRE.
How could I run, as declared by marketers - "Code once run everywhere!" a typical Spring + Hibernate + 100 another dependencies poorly designed crap on Dalvik VM?
