Why Objective-C is Hard • Hacker News Board

Re: Why Objective-C is Hard

#141

Post by unicron » Wed, Mar 07, 2012, 11:03 AM UTC

josephcooney wrote: post #112

unicron wrote: post #91

Earlier quoted context omitted.

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?

Doesn't scale up as well as win32/GDI. Requires much faster kit with graphic hardware acceleration to run (we had to bin about 200 Matrox Parhelia cards and replace with hefty NVidia cards to make use of hardware acceleration where GDI was fine on Matrox). Can't ILmerge thanks to XAML loader problems. Editor sucks. 5-million casts required in your code. BUGS! Hard to do trivial things. Virtually impossible to produce a scalable composite application. Grinds an 16 core Xeon to a halt inside VS2010. Learning curve from hell (this hurts on a 20 man team).

It's not good progress - it's just a deeper abstraction.

Re: Why Objective-C is Hard

#142

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

unicron wrote: post #141

josephcooney wrote: post #112

Earlier quoted context omitted.

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?

Doesn't scale up as well as win32/GDI. Requires much faster kit with graphic hardware acceleration to run (we had to bin about 200 Matrox Parhelia cards and replace with hefty NVidia cards to make use of hardware acceleration where GDI was fine on Matrox). Can't ILmerge thanks to XAML loader problems. Editor sucks. 5-million casts required in your code. BUGS! Hard to do trivial things. Virtually impossible to produce…

I can't argue with most of those. The designer sucks, and I blame that for lots of the VS slowness. I never open XAML files in the designer. Not sure about 'scaling up' relative to GDI - I guess if you're a gun GDI programmer you can probably make it do pretty much anything, but I felt more productive doing graphics stuff in WPF - seemed to let you do quite a few cool things pretty easily. ILMerge thing is a pain, but not a major one (unless you've gone out and built thousands of assemblies and are getting slammed by load times, in which case you kind of painted yourself into a corner there). When you say "Virtually impossible to produce a scalable composite application." do you mean scaling development, or run-time scalability?

I can't help but feel if MS had paid more attention to perf (maybe re-platform it on top of Direct2D in the .NET 4 timeframe, instead of going all in on WinRT) things would be a lot better.

Anyway, thanks for sharing those pain points.

Re: Why Objective-C is Hard

#143

Post by lucian1900 » Wed, Mar 07, 2012, 12:25 PM UTC

2muchcoffeeman wrote: post #121

guelo wrote: post #96

Earlier quoted context omitted.

Uhhh, Android?

Does Android count? http://en.wikipedia.org/wiki/Dalvik_(software) "Then they are converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed." And don't games use the Android NDK?

It's still garbage collected.

Dalvik does fix the startup issue with better class files, yes.

Re: Why Objective-C is Hard

#144

Post by ExpiredLink » Wed, Mar 07, 2012, 1:17 PM 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…

> In C++ it's called RAII, and it's the saving grace of C++ that almost completely makes up for C++'s other warts.

Great! The best C++ compliment I've ever read.

Re: Why Objective-C is Hard

#145

Post by unicron » Wed, Mar 07, 2012, 1:26 PM UTC

josephcooney wrote: post #142

unicron wrote: post #141

Earlier quoted context omitted.

Doesn't scale up as well as win32/GDI. Requires much faster kit with graphic hardware acceleration to run (we had to bin about 200 Matrox Parhelia cards and replace with hefty NVidia cards to make use of hardware acceleration where GDI was fine on Matrox). Can't ILmerge thanks to XAML loader problems. Editor sucks. 5-million casts required in your code. BUGS! Hard to do trivial things. Virtually impossible to produce…

I can't argue with most of those. The designer sucks, and I blame that for lots of the VS slowness. I never open XAML files in the designer. Not sure about 'scaling up' relative to GDI - I guess if you're a gun GDI programmer you can probably make it do pretty much anything, but I felt more productive doing graphics stuff in WPF - seemed to let you do quite a few cool things pretty easily. ILMerge thing is a pain, bu…

WRT scalability - it's scaling UI components over time. I build large complicated metadata driven applications and it's quite hard to compose an application on the fly.

Agree with performance. I hope WinRT is better. I have little faith based on my experience with Win8 so far but it's not RTM so I shouldn't comment on it yet.

Re: Why Objective-C is Hard

#146

Post by cageface » Wed, Mar 07, 2012, 2:00 PM UTC

unicron wrote: post #139

cageface wrote: post #114

Earlier quoted context omitted.

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.

It's just a fancy thread pool/task queue with a fugly syntax extension not some magic unicorn that poops rainbows. Java/C# don't need a language extension - the functionality exists outside the semantic boundary of the language. Another cludge in Objective-C. C# (ThreadPool/async framework/Windows workflow) and Java (ExecutorService/lots of 3rd party frameworks) have had them for years with well-known communication,…

Your "fugly syntax extension" is your old friend the closure. The syntax is as good as its going to get in an Algol derivative. I'll take it over plain java any day of the week. If Kotlin takes off on Android then we'll have a real contest.

Re: Why Objective-C is Hard

#147

Post by astrange » Wed, Mar 07, 2012, 2:56 PM UTC

imaginaryunit wrote: post #92

Minor point that has always bugged me: why doesn't Cocoa have native implementations of tree data structures?

http://ridiculousfish.com/blog/posts/array.html

Re: Why Objective-C is Hard

#148

Post by dkarl » Wed, Mar 07, 2012, 3:02 PM UTC

batista wrote: post #137

dkarl wrote: post #130

Earlier quoted context omitted.

Avoiding GC doesn't equate to "manual memory management." Objective-C uses reference counting, which is only manual in Objective-C for historical reasons, and they're trying to overcome that with ARC. I'm pretty sure most popular scripting languages use reference counting instead of garbage collection. C++ with pervasive use of shared pointers shouldn't be characterized as "manual" either. Also, as of a few years ago…

Also, as of a few years ago, the only performance-related reason why the JVM wasn't a popular language for desktop GUI apps was startup time. I don't think so. Besides startup time, Swing was always slow --an over-engineered mess. For some Java people it was always "fast enough in the latest version" (like for some Linux people it was always "the year Linux wins over the Desktop"), but even the best Swing UI had perc…

If we judge Java by Eclipse, can we judge C by iTunes? :-) They both tend to become unresponsive at odd times, but it's caused by clumsy background processing, not language performance.

The Eclipse framework itself is plenty fast, and UIs based on Eclipse RCP can be quite snappy. (Except for that damned startup time.) Swing's a mess, but if you're looking for the technical limitations of a language platform, it's the best performers that are relevant, not the worst performers. Otherwise, iTunes is evidence that even C is just too slow.

Re: Why Objective-C is Hard

#149

Post by atomicdog » Wed, Mar 07, 2012, 3:14 PM UTC

_delirium wrote: post #90

batista wrote: post #64

Earlier quoted context omitted.

But I'm reaching the point thinking: it's 2012, I'm an application developer, why am I spending half my time debugging memory leaks and concurrency issues? Because Objective-C targets everyday desktop apps and mobile apps. In that space, manual memory management still wins the day. For example, in Windows and Linux DESKTOP those kind of apps are ALSO made in C++ or C. Java and C# are for the web server and the CORPOR…

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

Don't look to Minecraft for an example of well written code, there are open source alternatives (Minetest in C++ springs to mind) that run rings around it. And Notch himself is well known for his inefficient magic-number and circular-reference ridden Java code. Although I can't attest to Jeb (who is now the lead dev)'s coding skill.

Re: Why Objective-C is Hard

#150

Post by unicron » Wed, Mar 07, 2012, 8:45 PM UTC

cageface wrote: post #146

unicron wrote: post #139

Earlier quoted context omitted.

It's just a fancy thread pool/task queue with a fugly syntax extension not some magic unicorn that poops rainbows. Java/C# don't need a language extension - the functionality exists outside the semantic boundary of the language. Another cludge in Objective-C. C# (ThreadPool/async framework/Windows workflow) and Java (ExecutorService/lots of 3rd party frameworks) have had them for years with well-known communication,…

Your "fugly syntax extension" is your old friend the closure. The syntax is as good as its going to get in an Algol derivative. I'll take it over plain java any day of the week. If Kotlin takes off on Android then we'll have a real contest.

Hm I bed to differ. Have you ever used C#?