Live data from Hacker News

Objective-C, Ruby and Python for Cocoa

theocacao.com

21–26 of 26 posts

Re: Objective-C, Ruby and Python for Cocoa

#21
post #14

Earlier quoted context omitted.

It's relative, and it's a distinction that changes as we make progress. Objective-C is a higher-level language than C, but as you noted, it's not interpreted, and I don't think it would be very pleasant to use as an interpreted language. It is verbose and repetitive (for example, to add a property to an Objective-C class requires you to add three lines of code in three separate places in your source code). And apart…

I don't think being interpreted matters. It may make your immediate development cycle faster, but that says nothing about long term development. I imagine the Scala guys would argue heavily that being compiled is a huge advantage to the power of that language, and would also strongly disagree that it isn't a high level language. Objective-C properties are poorly done in my opinion, though you can add one in two lines…

Hi Ross, little things add up, and they are easy to fix in higher level languages (with macros). I consider programming to be a process of building abstractions, and I think the best high-level abstractions are concise.

I like to quote Peter Norvig on the subject of interpreted languages. But in his quote, he uses "interactive." Maybe that's a better word:

"Which way would you rather learn to play the piano: the normal, interactive way, in which you hear each note as soon as you hit a key, or "batch" mode, in which you only hear the notes after you finish a whole song? Clearly, interactive mode makes learning easier for the piano, and also for programming. Insist on a language with an interactive mode and use it." - Peter Norvig, Teach Yourself Programming in Ten Years.

I've seen Objective-J and generally have good feelings about Javascript. But it's not particularly strong on one other criteria that I like to apply, which is that it should be easy to mix code written at different language levels.

Re: Objective-C, Ruby and Python for Cocoa

#22
post #18
post #15

Earlier quoted context omitted.

That's easy. High level languages have data types other than "things that fit inside registers", structures, and objects. Objective C doesn't. High level languages do automatic memory management. Objective C didn't until 10.5. Lots of high level languages don't have closures. Most of them have first-class string types. NSMutableString is a library.

So you're saying that C# is high level and Objective-C isn't?

Absolutely, I am.

Re: Objective-C, Ruby and Python for Cocoa

#23
post #14

Earlier quoted context omitted.

I don't think being interpreted matters. It may make your immediate development cycle faster, but that says nothing about long term development. I imagine the Scala guys would argue heavily that being compiled is a huge advantage to the power of that language, and would also strongly disagree that it isn't a high level language. Objective-C properties are poorly done in my opinion, though you can add one in two lines…

Hi Ross, little things add up, and they are easy to fix in higher level languages (with macros). I consider programming to be a process of building abstractions, and I think the best high-level abstractions are concise. I like to quote Peter Norvig on the subject of interpreted languages. But in his quote, he uses "interactive." Maybe that's a better word: "Which way would you rather learn to play the piano: the norm…

I see the value in being "interactive", but it isn't enough to rule out any other factor in choosing a language.

Re: Objective-C, Ruby and Python for Cocoa

#24
post #17

Earlier quoted context omitted.

To be fair, it depends on the application. You might not have to write them, but there are still plenty of applications where memory and speed are issues, and C gives you some really good tools to deal with them, but you're right -- C is not a high level language and shouldn't be used as one. I would go a step further and say that Objective-C also is not a high level language. Most people here would agree, but lots o…

Obviously, you know this stuff better than I do (I've been following you for awhile), but for what it's worth, here are my initial reactions to your post: (1) Ruby and ObjC have inconsistent syntax, which among other things is the reason we have that crappy snake-case encoding. This is true, but like I said, Cocoa's nomenclature is already so bad that wrapping everything in Ruby idiom was a win for me (2) Ruby/Cocoa…

Yes, I agree with you on a lot of that, especially if you can write your entire app in Ruby. That hasn't been true for me though. Either I have to go to C for performance or there's some library that I want to use that's easier to use directly from C.

You'll probably want to switch to MacRuby. By this summer there should be lots of sample code.

Re: Objective-C, Ruby and Python for Cocoa

#25
post #9

My biggest problem with Ruby for Cocoa work is that I enjoy the Smalltalk message passing syntax (keyword) more than the C++ syntax (object.name). The hacks to make it work right in Ruby do not look quite right. Objective-C fills the place C++ or C# fill in the .NET platform world. It would be interesting to see a language built for Cocoa that fills the VB role.

I had the same reaction, but ObjC's method names are so bad that I just wound up writing my own Ruby wrappers anyhow, so most of my code is written in Ruby idiom. ObjC does not fill the role C# fills in .NET. ObjC is still C code. C# doesn't have pointers. It doesn't segfault. Every object has reflection. There aren't aliasing problems. ObjC fills the place C++ fills in Win32; we still need a C# replacement.

Well, I was going with the C++/C# is the "do more" option and VB is quicker / easier.

Just a note: ObjC has reflection.

Re: Objective-C, Ruby and Python for Cocoa

#26
post #9

Earlier quoted context omitted.

I had the same reaction, but ObjC's method names are so bad that I just wound up writing my own Ruby wrappers anyhow, so most of my code is written in Ruby idiom. ObjC does not fill the role C# fills in .NET. ObjC is still C code. C# doesn't have pointers. It doesn't segfault. Every object has reflection. There aren't aliasing problems. ObjC fills the place C++ fills in Win32; we still need a C# replacement.

Well, I was going with the C++/C# is the "do more" option and VB is quicker / easier. Just a note: ObjC has reflection.

For ObjC objects.
Post reply on HN