Slashdot Mirror

There are real problems and objections to "code behind" a.k.a. click to code. In short, code behind encourages violation of "separation of concerns" and promotes placing application logic in the user interface. Cocoa uses the Model View Controller design by default, and Interface Builder reflects that.

http://dotnetaddict.dotnetdevelopersjournal.com/exploring_the_mvc_pattern_in_wpf.htm
http://dotnetaddict.dotnetdevelopersjournal.com/ide_greenerpastures.htm
http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa
http://dotnetaddict.dotnetdevelopersjournal.com/iphone_sdk_negative_response.htm

There are real problems and objections to "code behind" a.k.a. click to code. In short, code behind encourages violation of "separation of concerns" and promotes placing application logic in the user interface. Cocoa uses the Model View Controller design by default, and Interface Builder reflects that.

http://dotnetaddict.dotnetdevelopersjournal.com/exploring_the_mvc_pattern_in_wpf.htm
http://dotnetaddict.dotnetdevelopersjournal.com/ide_greenerpastures.htm
http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa
http://dotnetaddict.dotnetdevelopersjournal.com/iphone_sdk_negative_response.htm

There are real problems and objections to "code behind" a.k.a. click to code. In short, code behind encourages violation of "separation of concerns" and promotes placing application logic in the user interface. Cocoa uses the Model View Controller design by default, and Interface Builder reflects that.

http://dotnetaddict.dotnetdevelopersjournal.com/exploring_the_mvc_pattern_in_wpf.htm
http://dotnetaddict.dotnetdevelopersjournal.com/ide_greenerpastures.htm
http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa
http://dotnetaddict.dotnetdevelopersjournal.com/iphone_sdk_negative_response.htm

There are real problems and objections to "code behind" a.k.a. click to code. In short, code behind encourages violation of "separation of concerns" and promotes placing application logic in the user interface. Cocoa uses the Model View Controller design by default, and Interface Builder reflects that.

http://dotnetaddict.dotnetdevelopersjournal.com/exploring_the_mvc_pattern_in_wpf.htm
http://dotnetaddict.dotnetdevelopersjournal.com/ide_greenerpastures.htm
http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa
http://dotnetaddict.dotnetdevelopersjournal.com/iphone_sdk_negative_response.htm

Debugging JS with an alert window is a horrible experience.

Which is why you use a Javascript Debugger. Even if you're developing some IE specific abomination, Microsoft has the tools you need.

.NET is a great sandbox for rapidly developing web and windows apps. ... Plus ASP as a web framework was sorely lacking just as PHP was emerging. .NET I felt was a great thing to release; Certainly better than the Cocoa or Objective-C efforts on Mac

I'd personally hate it if they gave up the beautiful elegance that is ObjC and forced Apple developers to move to Java or .NET.

I've said it before, and I'll say it again now: Objective C is exactly at the sweet spot for a computer language - it has all the power of C (it's a formal superset), the nice features of a true object-orientated language (OOP, garbage collection, protocols, etc.), adds in dynamic dispatch (thus removing the need for generics), and does it all by adding about a dozen commands to the C language. The only thing against it is the unfamiliar (to C/C++ programmers) syntax. Really, though, how hard is it to make the mental leap to [myObject insertObject:xxx atPosition:yyy] from myObject->insertObjectAtPosition(xxx,yyy) ? And which is the more readable ?

Plus, the class library is *very* well designed. It makes easy things easy, and hard things possible. A lot of hard things are pretty easy too... There's a site that often compares .NET and ObjC/Cocoa. It frequently (despite the obvious potential bias given the name of the site) argues that the ObjC method for doing something is better thought out, more elegant, or simply more capable than the corresponding .NET approach.

Objective C is a classic example of how a simple clear approach can reap huge rewards in terms of usability and flexibility. It's not the over-designed bloat-fest that is C++ (template metaprogramming ? Really ?), and it's not the raw pedal-to-the-metal-hear-the-engine-scream-in-protest of plain old C. I've never yet met anyone give it a fair try (ie: write a real program in it) and not end up loving the language.

Simon

(As much as I love working and programming on the Mac, seeing how nice .NET is really gives me concern for the long-term future of Apple's platform.)

I've written about this before, but I think the best argument I can make is to point to the dot-net addict site, and point out that wherever he compares .NET to ObjC, it's almost a guarantee he'll prefer ObjC. He's authored several (a dozen ?) books on .NET, and is a self-confessed addict, I'm guessing he's a better advocate than I.

Most people come late to Objective C, it's only really used on the Mac, and the [method syntax] throws people off (though I don't think it's any worse than a C programmer seeing all those :: signs everywhere when he sees a C++ program). It's far simpler than C++ (and provides a full object-orientated system), it's much better designed than .Net, it's faster than Java for most things (those byte-code compilers win over everything sometimes :).

The only real drawback in modern times was the [retain]/[release] memory management, and even that is pretty simple - it even works with the built-in distributed objects across applications. With Leopard, we get managed memory, while still keeping the ability to link with any C library - did I mention it's a formal superset of C ? So *any* C program will compile under ObjC. And then you get to the real crux of it's strength - the dynamic nature of the language. Messaging an object ([myObject doSomething]) is not the same as calling a method (myObject->doSomething()), and you get a lot of power from that.

And, of course, it comes with a very powerful, elegant class-library. It's *hard* to write a non-MVC application in Cocoa - you have to really try. I think you only start to appreciate the subtlety of the class-library design after you've used it for a while. Easy things are easy. A lot of hard things are easy, and pretty much anything is possible. I've had a few "so that's why" moments over the past few years, and another cog slots into place.

Simon.

I think you do not understand what an iphone is. It is like not understanding what an ipod is when you compare it to other mp3 players that may have more features like a fm radio for example. Look for example here. http://dotnetaddict.dotnetdevelopersjournal.com/ip hone_competitors.htm

For example, this page describes a new developer walking through one of Apple's sample projects. The program is very simple: it takes two numbers from different text boxes, multiplies them, and puts the result in a third text box. And yet he had to write two methods to do it. Is there a better way than the one he used?

Whoops, sorry, fixed link: ...this series of blog entries...

You might be interested in this series of blog entries by a longtime .NET developer whose recent adventures in Cocoa have opened his eyes to just how, well, shitty the whole VS.NET approach to development really is. Here's an entry on "double-click and code syndrome". Here's another on how flexibility need not be sacrificed for ease of development; that's a fallacy perpetuated by Microsoft's habitually thoughtless design.

You might be interested in this series of blog entries by a longtime .NET developer whose recent adventures in Cocoa have opened his eyes to just how, well, shitty the whole VS.NET approach to development really is. Here's an entry on "double-click and code syndrome". Here's another on how flexibility need not be sacrificed for ease of development; that's a fallacy perpetuated by Microsoft's habitually thoughtless design.

See:
http://jdixon.dotnetdevelopersjournal.com/paging_r esultsets_in_sql_2000_and_sql_2005.htm
which has a good comparison between the two techniques: one for sqlserver 2000 and one for sqlserver 2005. You'll notice the 'with' statement and row_number, which are used together as a common table expression (CTE) which is an in-scope temp table without needing the temptable. It's incredibly powerful.