just for reference, here's what it looks like: http://cl.ly/5rbn
doesn't look ugly to me. Looks clean actually...
AppCode: Objective-C IDE from JetBrains goes public
21–30 of 55 posts
Re: AppCode: Objective-C IDE from JetBrains goes public
#22I'm excited to see more additional development solutions for Objective C; but why are we taking a step backward with these awful Java like GUIs that have plagued Eclipse and NetBeans? Why in 2011, are people still building UI heavy applications with Java?
Most of the great IDEs are java. Jetbrains makes their money in the java market, so seems reasonable to leverage their existing code base. Also, java gives you cross platform. Not an issue for AppCode, but it's a biggie for all their other languages (ruby, python, php, java)
Re: AppCode: Objective-C IDE from JetBrains goes public
#23I'm excited to see more additional development solutions for Objective C; but why are we taking a step backward with these awful Java like GUIs that have plagued Eclipse and NetBeans? Why in 2011, are people still building UI heavy applications with Java?
Why are JetBrains doing it? So they can reuse code.
At least I hope that's why. If that team isn't sad about not being able to provide a proper Mac GUI then they're out of touch with what's good about the platform.
Re: AppCode: Objective-C IDE from JetBrains goes public
#24just for reference, here's what it looks like: http://cl.ly/5rbn doesn't look ugly to me. Looks clean actually...
Clean, perhaps, but absolutely non-native, which is generally considered an ugly quality on OS X.
Re: AppCode: Objective-C IDE from JetBrains goes public
#25I don't think most Xcode users know what they're missing. And unfortunately they still won't, just by looking at screenshots and perhaps firing this up and having a quick bash around.
Some really good screencasts are needed to show what's possible with appCode - fortunately JetBrains does excellent screencasts for their other products and I'm sure they'll do these as it gets closer to release.
As for me, I'm a long-time IntelliJ user. Xcode 3 has been incredibly painful to use - even after taking a lot of time and effort to learn the keyboard shortcuts.
Xcode 4 is a major step in the right direction and started to actually make iOS coding reasonably fun. But it still can't hold a candle to the features available in this early release of appCode - it's awesome.
Re: AppCode: Objective-C IDE from JetBrains goes public
#26At first I was excited that Xcode had some competition, so I downloaded this as soon as it was available. Unfortunately, it has a crappy Java-generic GUI. For an IDE for a platform that makes a big deal out of user experience, it really looks awful. (And it manages to be slower than Xcode 4!) I understand that tools don't have to be pretty to be functional, but I draw the line here.
I have a few disagreements with what you have said here. AppCode is in Beta - it's going to be slow and its going to crash. Even though you have stated that "tools don't have to be pretty to be functional" I think you have contradicted your point here by writing off AppCode on that basis entirely. As a software developer, fair criticism of a tool should never rely on its aesthetics but rather on its ability to solve…
I really did want to expand on the point you disagreed with, but I had to leave. Here's a bit more.
What I meant was that given the choice between two tools, one of which is pleasant to use (for whatever reason) and one of which is not, I will always choose the one that is more pleasant to use. So far, reading and testing, I have not seen any reason to prefer appCode to Xcode. If appCode had some sort of killer feature, then I would put less emphasis on the way it looks.
In addition, this sort of interface displays a fundamental misunderstanding of OS X and iOS by Jetbrains. Integrating with an OS is about more than getting your code to run and do stuff. I am a user as much as any iPhone owner is a user.
Re: AppCode: Objective-C IDE from JetBrains goes public
#27I am sure it will get polished before the final release. All IntelliJ IDEs can install a very functional VIM plugin - that itself is a big deal for me!
Re: AppCode: Objective-C IDE from JetBrains goes public
#28I don't think most Xcode users know what they're missing. And unfortunately they still won't, just by looking at screenshots and perhaps firing this up and having a quick bash around. Some really good screencasts are needed to show what's possible with appCode - fortunately JetBrains does excellent screencasts for their other products and I'm sure they'll do these as it gets closer to release. As for me, I'm a long-t…
Here is one small example of something that won't be apparent to someone without a demonstration.
Say I have a class called Foo and I realise, as I'm using it, that I want to add a method called doSomethingElse, I can just type the new method call and have appCode create the method for me. Ie:
Foo *foo = [[Foo alloc] init];
[foo doSomething];
[foo doSomethingElse]
doSomethingElse would be marked in red. I just have to hit command-enter, select 'Create method' and appCode creates the method signature in Foo.h, creates the method in Foo.m and puts the cursor in the body of the method ready to implement it.
This improves coding flow remarkably.
Re: AppCode: Objective-C IDE from JetBrains goes public
#29Earlier quoted context omitted.
In the worst case scenario you should keep it around for refactoring. The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around.
> The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around. Assuming AppCode's refactoring support ends up being even as good as Xcode 3's hit-or-miss heuristics, which remains to be seen. "AppCode is from JetBrains and ReSharper/IntelliJ IDEA have great refactoring, so AppCode will too" isn't a valid line of reasoning, because the limiting factor here isn't the aut…
How is AppCode going to get any better than that? Either they're going to go the heuristics route, like Xcode 3 and below, and have all kinds of cases where they fail miserably, or they're going to hook into LLVM, and have no real insights into the code that Xcode 4 wouldn't.
You can have symbols available to you from the compile that you're not interested in using. How do you filter them out smartly? There is plenty of room for improvement, even with a LLVM-based parser for determining possible autocompletions.
Also, Xcode 4 has a tendency to forget it has to show me any completions at all. At that point, Xcode 3's autocompletion is preferable to, well, nothing.
Re: AppCode: Objective-C IDE from JetBrains goes public
#30I don't think most Xcode users know what they're missing. And unfortunately they still won't, just by looking at screenshots and perhaps firing this up and having a quick bash around. Some really good screencasts are needed to show what's possible with appCode - fortunately JetBrains does excellent screencasts for their other products and I'm sure they'll do these as it gets closer to release. As for me, I'm a long-t…
Here is one small example of something that won't be apparent to someone without a demonstration. Say I have a class called Foo and I realise, as I'm using it, that I want to add a method called doSomethingElse, I can just type the new method call and have appCode create the method for me. Ie: Foo *foo = [[Foo alloc] init]; [foo doSomething]; [foo doSomethingElse] doSomethingElse would be marked in red. I just have t…
That strikes me as a good example of where the kinds of features JetBrains is known for don't really mesh with Objective-C.
If doSomethingElse is a method defined in a category I expect to be loaded at runtime, or something I expect to be caught by foo's forwardInvocation method, having it turn red and bug me to provide an implementation in Foo is exactly the wrong thing to do.
It's the kind of little feature that really only makes sense in the context of a static language like C#, where a method call without a corresponding method implementation can be known definitively to be an error.