2 ms·

No I don't really think so. Otherwise python and ruby would trigger similar fears. And I work with Objective-C a lot. There is a downside to theExtremelyLong

by mahyarm 12y ago

No I don't really think so. Otherwise python and ruby would trigger similar fears. And I work with Objective-C a lot. There is a downside to theExtremelyLong:message passingStyle:functionNames You could say similar things about applescript too, yet I've never met anyone who actually uses it: http://alvinalexander.com/blog/post/mac-os-x/applescript-list-examples http://alvinalexander.com/blog/post/mac-os-x/applescript-lis... Smalltalk was good and it inspired a lot of future things but it didn't succeed because it had a bad $ price / performance ratio in the 80s and the image system created too much coupling compared to files.

protomyth 12y ago
"There is a downside to theExtremelyLong:message passingStyle:functionNames" I actually like the selector syntax. I have type ahead and don't have to constantly look at code to figure out what parameter number something is.
- SlipperySlope 12y ago
  Agreed. My college days Fortran IV only allowed 8 character upper case identifier names - ugh!
- mahyarm 12y ago
  It is nice in some cases, but for example, string manipulation is pretty hard to parse compared to python because frequent operations are huge sentences. Pulling out json data that is presented as NSArray's and NSDictionaries was especially painful. That large amount of text makes it slower to parse and and thus your less productive. As PG said, the consistent factor in bugs seems to be lines of code. The more verbose and boilerplat-ish a language is, the more likely your going to have slip ups that cause bugs for similar functionality. Ex: [NSString stringWithFormat:@"%d items", itemCount] vs. "%d items" % itemCount or json[@"keyA"][@"keyB"][0]; vs. [[[json objectForKey:@"keyA"] objectForKey:@"keyB"] objectAtIndex:0];
igouy 12y ago
>> … but it didn't succeed because … << By what definition of success? From 80's through '90s Smalltalk was used commercially in finance and manufacturing and … on large scale projects.
- mahyarm 12y ago
  Well yes there were commercial implementations, but people bemoan smalltalk 'dying'. Compared to C++, C or even Java for example.
  - igouy 12y ago
    Presumably because they now have to use C++, C or even Java.

by mahyarm 12y ago

protomyth 12y ago

"There is a downside to theExtremelyLong:message passingStyle:functionNames" I actually like the selector syntax. I have type ahead and don't have to constantly look at code to figure out what parameter number something is.

SlipperySlope 12y ago
Agreed. My college days Fortran IV only allowed 8 character upper case identifier names - ugh!
mahyarm 12y ago
It is nice in some cases, but for example, string manipulation is pretty hard to parse compared to python because frequent operations are huge sentences. Pulling out json data that is presented as NSArray's and NSDictionaries was especially painful. That large amount of text makes it slower to parse and and thus your less productive. As PG said, the consistent factor in bugs seems to be lines of code. The more verbose and boilerplat-ish a language is, the more likely your going to have slip ups that cause bugs for similar functionality. Ex: [NSString stringWithFormat:@"%d items", itemCount] vs. "%d items" % itemCount or json[@"keyA"][@"keyB"][0]; vs. [[[json objectForKey:@"keyA"] objectForKey:@"keyB"] objectAtIndex:0];

igouy 12y ago

>> … but it didn't succeed because … << By what definition of success? From 80's through '90s Smalltalk was used commercially in finance and manufacturing and … on large scale projects.

mahyarm 12y ago
Well yes there were commercial implementations, but people bemoan smalltalk 'dying'. Compared to C++, C or even Java for example.
- igouy 12y ago
  Presumably because they now have to use C++, C or even Java.