Hacker News Reader

Comment by richcollins | Hacker News Reader

We don't need "modern" UI frameworks we need well designed UI frameworks. HTML isn't designed for stateful UIs. I'm hoping that Cocoa will eventually move away from Objective-C and towards a more dynamic (expressive) language (Javascript would be great).

View on HN

A major problem with web-based UIs is the lack of sane defaults. The default for HTML is a document with basic formatting. You need somebody with good design skills to create an App that doesn't look awful.

On the other hand, frameworks such as UIKit provide all you need for a nice-looking UI. Developers just need to worry about the application code, and worry about UI design much later in the process.

By "dynamic" do you mean "interpreted"? Because Objective-C is a pretty dynamic and flexible language, otherwise.

Objective-C does have performSelector, but its awkward to use. It lacks the ability to easily add slots to objects and you often have to work with C types.

Perhaps "expressive" would be a better distinction. Javascript is a much more expressive language, meaning that I have to do a lot less work to accomplish the same end.

> Objective-C does have performSelector, but its awkward to use. It lacks the ability to easily add slots to objects and you often have to work with C types.

-performSelector: takes a selector string, and its variants allow you to pass objects as arguments. I'm not sure why you think it involves C types or why you cite it as the feature that makes Objective-C dynamic (there's considerably more to it than that).

I was talking about Objective-C not performSelector, although performSelector does illustrate some problems with C types. You can't return a value with perform selector precisely because of C types (unless you wanted performSelectorReturningInt ... etc)

Have you looked at this?

http://cappuccino.org/

It's basically Cocoa on javascript using Objective-J

I like cappuccino the framework but not Objective-J the language. It mostly takes the bad parts of Objective-C and puts them on top of Javascript (with the exception of "forward")

Objective-C is already a dynamic language. Its ability to drop to low-level C at will makes it too flexible and powerful to abandon for something slow and cumbersome like Javascript.

Which is more cumbersome?

    //Objective-C
    
    #import <Foundation/Foundation.h>
    
    @interface Order : NSObject {
    	NSString *id;
    	Customer *customer;
    	NSDate *timestamp;
    	NSString *productId;
    }
    
    @property (nonatomic, retain) NSString *id;
    @property (nonatomic, retain) Customer *customer;
    @property (nonatomic, retain) NSDate *timestamp;
    @property (nonatomic, retain) NSString *productId;
    
    @end
    
    #import "Order.h"
    
    @implementation Article
    
    @synthesize id;
    @synthesize customer;
    @synthesize timestamp;
    @synthesize productId;
    
    - (void)dealloc
    {
    	[self setId:nil];
    	[self setCustomer:nil];
    	[self setTimestamp:nil];
    	[self setProductId:nil];
    	[super dealloc];
    }
    
    //Javascript
    
    Order = Proto.clone().newSlots("id", "customer", "timestamp", "productId");

Objective-C is always going to win the contest for Smalltalk-esque verbosity, but I would hardly consider the code you wrote to be cumbersome. In the modern Objective-C runtime using garbage collection, you can write this:

    // Order.h
    #import <Foundation/Foundation.h>
    
    @interface Order : NSObject
    @property (copy) NSString *id;
    @property (retain) Customer *customer;
    @property (copy) NSDate *timestamp;
    @property (copy) NSString *productId;
    @end
    

    // Order.m
    #import "Order.h"
    
    @implementation Article
    @synthesize id;
    @synthesize customer;
    @synthesize timestamp;
    @synthesize productId;
    @end

Apple engineers have confirmed that they're working on making @synthesize the default behavior for properties, so eventually you won't have to write that either. A real-world app would be using Core Data for its model objects, negating the need to write this class at all while adding automatic faulting, data integrity, and undo/redo:

    Order *order = [NSEntityDescription insertNewObjectForEntityForName:@"Order"
                    inManagedObjectContext:self.managedObjectContext];

Thank you for further solidifying my point.

I fully agree. I used to be a big fan of Objective-C and saw no need for a more expressive language.

Then I started coding in PyQt (a Python, Qt bridge). Now I know: Objective-C is not a high level language, even though it has some high level aspects. Also, coding in a high level language can improve productivity by a huge margin, even if you are coding against a low level framework.

On the desktop, this is a more than worthwhile tradeoff. Mobile devices still benefit from the performance advantage of Objective-C as opposed to, say, MacRuby.

Verbosity also promotes to poor design decisions. I often skip creating additional classes that would result in better factored code because it's too much work.

"Because it's too much work" tends to be a bad excuse, though.

If creating a new class took an hour would it be a bad excuse? How about a day?

Getting rid of "Too much work" is the point of software.

Reply on news.ycombinator.com