51–54 of 54 posts
Earlier quoted context omitted.
You can always make use of APL if you don't like typing.
You could always make use of enterprise Java if you like verbosity. The extremes are probably not the place to be.
Why do you think verbose languages are so loved by big enterprise companies?
It is a total different scale of development.
Earlier quoted context omitted.
With autocomplete you don't get much extra exercise anyway. It helps to strain your brain less however when reading the code.
I don't think "arrayByAddingObjectsFromArray:" is particularly clearer than "concat" or "+" unless you're just totally unfamiliar with the language. In fact, for many selectors I find the shorter names easier to read because my brain sees them as a single token while I have to mentally parse Cocoa's behemoths every time I run across them. There is some benefit to clarity, but very often Objective-C's glut of informat…
Where I see ObjC fall down is more in terms of command verbosity. For example in Ruby,
File.open("readfile.rb", "r") do |infile|
while (line = infile.gets)
puts "#{line}"
end
end
Apple chose to give you a couple ways to read a file. The easy way is `stringWithContentsOfFile:encoding:error:error`, but the next level of control is way to low level. Dave DeLong's solution to reading a file line by line exposes an api that looks like this:
DDFileReader * reader = [[DDFileReader alloc] initWithFilePath:pathToMyFile];
[reader enumerateLinesUsingBlock:^(NSString * line, BOOL * stop) {
NSLog(@"%@", line);
}];
Earlier quoted context omitted.
Well any way you slice it you're still going to have to interface with the Cocoa frameworks that make up the OS. Anything that masks the interface too much just causes friction. e.g. you can't look stuff up in the docs anymore. MacRuby does a bit better job at first glance than this does, but you can't get past the way the framework you're using works. In Objective-C: Person *person = [Person new]; [person name]; [pe…
current method role is tentative. I'll do more improvement.
alert = UIAlertView._alloc \
._initWithTitle _S("Hello"),
:message, _S("I'm MobiRuby"),
:delegate, nil,
:cancelButtonTitle, _S("I know!"),
:otherButtonTitles, nil
alert._show
alert = UIAlertView.alloc().initWithTitle(:title => 'Hello',
:message => "I'm MobiRuby",
:delegate => nil,
:cancelButtonTitle => "I know!",
:otherButtonTitles => nil).show()
Or would that not work for some reason? I understand why you need to keep the method names (for automatic translation), but perhaps the syntax could be a little friendlier and more in line with expectation for Ruby code? I would love to write code for iOS in Ruby (have already written some, but it wouldn't get on the app store due to restrictions), but interfacing with views etc is not too painful in ObjC currently, so if it was more painful in something like this it would put me off.
Having looked at your pages further, I see the possibilities of a cross-platform Ruby framework for iOS and Android or WinMo, but if you tie it so tightly to UIKit, how did you plan handling cross-platform issues elegantly? Would that be down to the developers (it is a huge task of course)?