Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AppCode: Objective-C IDE from JetBrains goes public

blog.jetbrains.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: AppCode: Objective-C IDE from JetBrains goes public

#31

Post by wtallis »

msbarnett wrote: post #24
ohhmaagawd wrote: post #21

just 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.

The disclosure triangles and combo box look native. The icons, scrollbars, tabs, toolbars, status bar, tip-of-the-day dialog (wtf?), and confirmation dialogs all are obviously non-native, some of them in ways that are trivially fixable (such as getting the button order right in the confirmation dialogs).

I understand that it's pre-beta, but if they consider the current GUI to be even a prototype instead of the placeholder that it is, they'll likely never get any traction outside of Java developers trying to cash in on Apple's App Stores.

Re: AppCode: Objective-C IDE from JetBrains goes public

#32

Post by nevster »

msbarnett wrote: post #30
nevster wrote: post #28

Earlier quoted context omitted.

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 re…

That's interesting but I'm confident in JetBrains getting this kind of detail right. I don't have appCode in front of me but I'm sure they'll implement something to handle it. They go to great lengths to understand your entire codebase including any libraries/sdks you might link with.

They've had to do similar things already with Javascript, Ruby, etc. Even Java has similar issues - for example you can use reflection to call methods. So it may mark a method as not being used in your project. But for 99% of cases it gets it right.

Re: AppCode: Objective-C IDE from JetBrains goes public

#33

Post by teaspoon »

msbarnett wrote: post #30
nevster wrote: post #28

Earlier quoted context omitted.

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 re…

GCC would give a warning if you tried to compile this, and Xcode 4 would highlight the offending line with a yellow bubble. appCode's behavior doesn't seem too inappropriate in this case.

Re: AppCode: Objective-C IDE from JetBrains goes public

#34

Post by jon914 »

callumjones wrote: post #15

I'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?

Our startup's main product uses Java for a UI heavy app because makes it cross platform out of the box and is relatively easy to develop a nice, native looking UI with if you know what you're after.

Our closest competitors locked themselves to one platform and have faced challenges trying to go cross platform.

Re: AppCode: Objective-C IDE from JetBrains goes public

#35

Post by masklinn »

i386 wrote: post #17
stevejohnson wrote: post #6

At 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…

It's not even in beta, it's in EAP.

Re: AppCode: Objective-C IDE from JetBrains goes public

#36

Post by masklinn »

wtallis wrote: post #31
msbarnett wrote: post #24

Earlier quoted context omitted.

Clean, perhaps, but absolutely non-native, which is generally considered an ugly quality on OS X.

The disclosure triangles and combo box look native. The icons, scrollbars, tabs, toolbars, status bar, tip-of-the-day dialog (wtf?), and confirmation dialogs all are obviously non-native, some of them in ways that are trivially fixable (such as getting the button order right in the confirmation dialogs). I understand that it's pre-beta, but if they consider the current GUI to be even a prototype instead of the placeh…

> but if they consider the current GUI to be even a prototype instead of the placeholder that it is

I doubt it is. It's not the first Jetbrains IDE on OSX. They may decide to go a very different graphical route for this one as it's pretty obviously OSX-only, but that's not really a given.

Re: AppCode: Objective-C IDE from JetBrains goes public

#37

Post by callumjones »

jon914 wrote: post #34
callumjones wrote: post #15

I'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?

Our startup's main product uses Java for a UI heavy app because makes it cross platform out of the box and is relatively easy to develop a nice, native looking UI with if you know what you're after. Our closest competitors locked themselves to one platform and have faced challenges trying to go cross platform.

Chrome and Firefox seem to do a good job of going cross platform.

Re: AppCode: Objective-C IDE from JetBrains goes public

#38

Post by nevster »

teaspoon wrote: post #33
msbarnett wrote: post #30

Earlier quoted context omitted.

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 re…

GCC would give a warning if you tried to compile this, and Xcode 4 would highlight the offending line with a yellow bubble. appCode's behavior doesn't seem too inappropriate in this case.

Now that you mention this, I think it's highlighted in a muted color as a warning, not as a glaring red error.

Re: AppCode: Objective-C IDE from JetBrains goes public

#39

Post by wriq »

h7brid wrote: post #27

I 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!

Having a vim plug-in for Xcode 4 would make my year. For longer coding sessions i've been editing in MacVim with cocoa.vim and clang_complete.

Re: AppCode: Objective-C IDE from JetBrains goes public

#40

Post by GeneralMaximus »

I noticed it has the new "vanishing" scrollbars. Looks a little ugly, but it's not that bad. I expect it will get better with time. I like the color-coded tabs and easy tab switching. The editor itself lags a bit.

Strangely enough, it didn't recognize my .mm files as Objective-C++ files.

Post reply on HN