Why Objective-C is Hard • Hacker News Board

Re: Why Objective-C is Hard

#111

Post by jimbokun » Wed, Mar 07, 2012, 12:06 AM UTC

dkarl wrote: post #99

zoul wrote: post #42

People fret over language syntax too much. In most sane languages including Objective-C you simply forget about the syntax after a few months. What’s much more important is the conceptual complexity: the number of language features and the way they fit together. A second important thing is the standard library. Objective-C is a pleasant language by both these metrics, since there are just a few language constructs ab…

I couldn't disagree more. Objective-C is a product of the 1980s, when it kind of made sense that your program would crash if you did this: [NSArray arrayWithObjects:@"Hello", @"World"]; Of course it crashes! You have to add a nil sentinel value to the end of your list of objects, silly. And of course it compiles with only a warning, just like when you leave out the @ that makes the difference between a C string liter…

Best I can tell, all of the problems you cite are fixed by MacRuby. It shows how surprising well Ruby semantics maps onto the message passing semantics of Objective C. They also found ways to wrap up the C stuff without making you manage your own memory.

Not sure why Apple hasn't been more aggressive in pushing it for Cocoa development. Maybe because they don't trust it to perform well, yet, on iOS devices and don't want to promote it until it can be used anywhere as a replacement for Objective C.

Re: Why Objective-C is Hard

#112

Post by josephcooney » Wed, Mar 07, 2012, 12:07 AM UTC

unicron wrote: post #91

RandallBrown wrote: post #79

Earlier quoted context omitted.

and visual studio... It has a WPF frontend anyway. I'm sure it drops into native code pretty quickly. Evernote actually did a great post about switching from C#/WPF back to a C++ app and how it actually let them move faster. Pretty interesting read. http://blog.evernote.com/2010/10/26/evernote-4-for-windows-i...

That's down to WPF which is a total pile of shit to be honest (having spent the last 3 years with it). It's nothing to do with the language.

I'm kind of fond of WPF. Lots of aspects of it (data binding, styles, templates, the layout system etc) seem very elegant to me. It is not without issues. How do you justify the 'total pile of shit' call?

Re: Why Objective-C is Hard

#113

Post by _delirium » Wed, Mar 07, 2012, 12:08 AM UTC

tmgrhm wrote: post #100

_delirium wrote: post #90

Earlier quoted context omitted.

There's also Minecraft, one of the best-selling videogames of 2011. :)

Minecraft isn't as popular as it is because it's the result of brilliantly-written Java; it sells so well because it's a brilliant concept.

That's true, but I'd guess that's true of much desktop software. People don't use Microsoft Word because of its efficient C++ code; they use it because it's semi-standard, has lots of features, and overall is good enough. I would bet giant piles of legacy code are a bigger reason for not moving to C# than anything language-specific is.

Re: Why Objective-C is Hard

#114

Post by cageface » Wed, Mar 07, 2012, 12:13 AM UTC

unicron wrote: post #94

zoul wrote: post #42

People fret over language syntax too much. In most sane languages including Objective-C you simply forget about the syntax after a few months. What’s much more important is the conceptual complexity: the number of language features and the way they fit together. A second important thing is the standard library. Objective-C is a pleasant language by both these metrics, since there are just a few language constructs ab…

I've put together a few things with Objective C over the years dating back to OSX 10.1 (yuck PB sucked then) to iOS. Most ended up being ported to Java or C#. The syntax IS absolutely horrible if you ask me as it results in crazily verbose ways of expressing stuff. Everything is "too meta" and there are very few first class parts of the language. It still FEELS like it's hacked together with C macros (which was what…

Also the lack of any decent threading abstraction - ick.

What? Grand Central Dispatch is a lot easier to work with than most explicit threading mechanisms and with the new block support is a lot less verbose than the typical Java thread-based approach.

Re: Why Objective-C is Hard

#115

Post by cageface » Wed, Mar 07, 2012, 12:16 AM UTC

dgallagher wrote: post #98

It's best to think of Obj-C method call syntax as a sentence, written in english, which happens to also be computer code. If you name your methods and variables succinctly and explicitly, the language is extremely readable and documents itself (assuming you know english). Obj-C was the first language I learned after Python. I remember the 2nd month in, it went from being difficult to read, to extremely easy. Obj-C co…

If you use the new AppCode Obj-C IDE, you can get formatting like the latter for free.

Re: Why Objective-C is Hard

#116

Post by cageface » Wed, Mar 07, 2012, 12:25 AM UTC

Really the only thing that makes Obj-C the language hard is that the C layer pokes through often enough that you really do need to understand C as well and C presents a lot of pitfalls to a new programmer.

Re: Why Objective-C is Hard

#117

Post by s73v3r » Wed, Mar 07, 2012, 12:36 AM UTC

scott_s wrote: post #76

donmcc wrote: post #73

Earlier quoted context omitted.

True, "verbose" isn't really the correct term, "explicit" better describes Objective-C. Here's an example where I think Objective-C's explicitness is helpful. The Windows API CreateWindow() function call in C: HWND hwnd = CreateWindow("MainWClass", "Sample", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, (HWND) NULL, (HMENU) NULL, hinstance, (LPVOID) NULL); And here's a long method c…

I agree the second example is more understandable, but I think most of that benefit comes from named parameters (a language feature), not the naming convention itself. That is, were the naming up to me, I would prefer: NSString *filtered = [unfiltered replace:@"verbose" with:@"explicit" options:CaseInsensitive range:Range(0, [unfiltered length])]; Of course, I'm making assumptions about what those parameters mean. Bu…

When you use the word "replace", to most people, that signals that you would be changing the current object in place, not returning a new object based on the given one.

On the second line, you didn't mention at all what is passed in.

For the last two, removing the NS prefix would work if Objective-C had some kind of namespacing support. Currently it doesn't, so the NS prefix is kinda needed.

Re: Why Objective-C is Hard

#118

Post by prodigal_erik » Wed, Mar 07, 2012, 12:48 AM UTC

andr3w321 wrote: post #107

For me the most annoying thing about learning xcode/objective-c is apple tries to force you into buying a Mac.

That's a deficiency of the iOS platform, not the ObjC language. It's just that ObjC is brittle and tricky enough that there's no longer much reason to learn it unless you're working on iOS (or possibly MacOS, if you think that'll stay relevant), though GNUstep is portable if you really want to.

Re: Why Objective-C is Hard

#119

Post by groovy2shoes » Wed, Mar 07, 2012, 12:55 AM UTC

jimbokun wrote: post #111

dkarl wrote: post #99

Earlier quoted context omitted.

I couldn't disagree more. Objective-C is a product of the 1980s, when it kind of made sense that your program would crash if you did this: [NSArray arrayWithObjects:@"Hello", @"World"]; Of course it crashes! You have to add a nil sentinel value to the end of your list of objects, silly. And of course it compiles with only a warning, just like when you leave out the @ that makes the difference between a C string liter…

Best I can tell, all of the problems you cite are fixed by MacRuby. It shows how surprising well Ruby semantics maps onto the message passing semantics of Objective C. They also found ways to wrap up the C stuff without making you manage your own memory. Not sure why Apple hasn't been more aggressive in pushing it for Cocoa development. Maybe because they don't trust it to perform well, yet, on iOS devices and don't…

> It shows how surprising well Ruby semantics maps onto the message passing semantics of Objective C.

This is not surprising given that both Ruby and Objective-C xeroxed their object models from Smalltalk.

Re: Why Objective-C is Hard

#120

Post by xsmasher » Wed, Mar 07, 2012, 1:02 AM UTC

tmcw wrote: post #4

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

It's a technical requirement. Parameter types are not part of the method signature, so you CAN NOT define both [string append:string] and [string append:int] methods. You must give them different names, like [string appendString:string] and [strig appendInt:int] , in order to give them different signatures.