Re: why Obj-C
Re: why Obj-C
- Subject: Re: why Obj-C
- From: Michael Gersten <email@hidden>
- Date: Sun, 07 Apr 2002 23:12:40 -0700
>
> > Why are we forced to learn yet another syntax that is very alien to
>
> C++/Java. I absolutely love the interface builder its
Just a quick question: Why do you think the syntax is alien?
As someone else said
>
You do know that Objective-C is/was a preprocessor for C right ? Gcc
>
integrates the Objective-C parser into the C parser as an optimization.
Believe it or not, C++ started out as a preprocessor for C as well.
>
> How many languages do you know ? I say the more the better.
>
>
>
>
In order of learning (oldest to youngest):
>
FORTRAN,basic,Pascal,lisp,prolog,C++,C,X86 assembly,mc68000 assembly,Java
>
>
In order of preference:
>
C,C++,Java,FORTRAN,Pascal,basic,lisp,prolog,mc68000 assembly,X86 assembly
Hmm... what's missing on these lists?
Objective C isn't here yet.
But it looks like you say you learned C++ before you learned C. That's an odd one.
(Hey, another lisp and prolog person! Good. But why rate them so low on the preference order?)
>
I disagree, The more languages I have under my belt the less expert I become in the lot. Maybe I am getting old and
>
feeble but I seem to of reached a limit in which if I learn something new I forget something old ;)
Then forget FORTRAN [duck (<shoowsh> as a flame misses me)]
>
> > just excellent. But then you have to write the meat of the program and its
>
> been not a very pleasent experience for a
>
> > newbie to mac but I experienced C/C++ dude.
>
>
>
> Are you that hung up on syntax or were you unable to grasp the dynamic
>
> nature of Objective-C ?
>
>
Yes.
Yes what? Hung up on syntax? The dynamic nature?
>
Look syntax shouldn't be a issue. And its my own time constraint issues that is my major problem. I had a very small
>
oportunity to bring OSX development into our site and to impress the hard core UNIX programmers that I work with of how
>
easy it was going to be to write code for this sucker. They were blown away with how long it took me to build a GUI with
>
IB (about a hour and I had never picked up IB before (thanks apple)). But both them and I hated the syntax of Obj-C. And
>
two weeks later I am still battling with the syntax. I guess I expected it to be miraculously easy.
Nesting messages is annoying in ObjC -- I'm always going back and adding an early open bracket at the beginning, rather than just another method call at the end of where I'm at.
Many times, I'll pretend I'm using my old RPN calculators, and start my expression in the middle, with blank lines above and below me. As I go, I'll go up lines or down lines, adding brackets and keeping things indented. Shifting groups of lines left as needed, as I add more clauses to the expression. Finally, I'm done, with an expression that looks like a block of code, and (I consider) readable.
>
for me the "["'s suck. my kingdom for a makeObjCLikeC preprocessor ;)
>
>
I wish they made methods look like C functions. Less smalltalk more C.
You'd probably love a language called Actor. It was a Win 2.x O-O development environment. The language was a cross between pascal, and C++, and attempted to support the syntax of each (and did so remarkably well). You had two different ways to write most things, and it wasn't ambiguous. Both
message(obj, arg) and obj.message(arg) were permitted. [There were no plain functions, so this was non-ambiguous].
It looks like you want to treat
[object messageName:arg1 andDescription: arg2 whatItIs: arg3]
as object.messageNameAndDescriptionWhatItIs (arg1, arg2, arg3)
which looks remarkably like what the java bridge preprocessor does. [Look at the Java to Objc Bridge Spec, or .jobs files.]
>
> > I will never understand the IT worlds obsession with reinventing the wheel.
Simple. The IT world is dominated by people with ADD/ADHD.
New, exciting, different, just because it is new, exciting, different.
Give me one other good reason for saying "Hey, the UI rules we've used for 10-15 years are no longer any good -- now no two apps can look like each other" (windows), or "More visual distractions, more graphical power used, more powerful computers needed" (Cocoa).
>
Java is a buggy slow toy (duck) ok that was flame bait. But I don't like Java either. Its like C++ with all the good
>
bits taken out. pointers rock!!!
Keep in mind what Java was designed for.
Java was designed to solve one specific problem: How can I guarantee to you, that even if you do not trust me, and think I'm trying to steal data from you, that this program of mine can run on your machine and do no harm to you no matter what.
Unrestricted pointers made that impossible.
All of the restrictions/limits in Java come from that design goal.
Now, take that design restriction, and try to say "Ok, now I'm in a trusted environment, I want the full power of C/assembly with the convenience of objects/classes". Can you?
Java with JIT isn't slow.
As I mentioned once before, based on research reports I've read, in well optimized programs,
Java with JIT has about a 20% overhead from the JIT.
ObjC has about a 20% overhead from the messaging lookup.
(and, my own opinion)
C++ has about a 20% overhead from STL code bloat.
>
> I recommend that you learn Lisp, Smalltalk, Eiffel, Perl, and at least one
>
> assembly language. Broaden your horizons. Then come back and look at C
>
> derived languages with a different admiration and sense of limitations.
>
>
No thanks. I have work to do.
>
>
All the languages I have learnt (see above) the most flexible/powerful I know is C.
Not assembly? Odd.
The studies I've seen show that the lines of bug-free code, per day, is pretty constant for a programmer, regardless of language. For a language like Prolog, where you need to write very few lines, that means you get the program finished much faster.
Now, optimizing prolog is a pain. It's cheaper to get a better computer than to pay a programmer to optimize it.
(My wish list: a good way to interface prolog and ObjC/Appkit.)
>
This is why Obj-C has been a bit of
>
a dissappointment for me. I didn't expect to have to learn the language as well the programming methodology/Classes.
Odd. Every one of the languages you've learned so far, you've had to learn the syntax and the standard libraries. ObjC is no different.
The methodology of ObjC (when done right) is pure ADT-based object oriented programing. If you don't know what abstract data types are, _LEARN_.
ADT + inheritence, plus some syntactic sugar, is modern O-O.
I can understand not using ADT in fortran, and maybe Basic.
But by Pascal you should have had it.
You can write spagetti code in any language -- I've had to work at a place that did it in ObjC.
You can write structured code in any language -- I've done it in Basic.
Any language with pointers and structures can easily handle ADTs. You can roll your own virtual function table, such as
(forgive me if I get the syntax off here -- it's been a long time)
struct fileops
{
(*open(s, m) () ),
(*close(n) () ),
(*read(n, b) () ),
(*write(n, b) () ),
(*ioctl(n, a1, a2) () )
};
and define your own ADT, specifying that different things of type fileops have different open/close/read/write/ioctl calls, yet using the same code to call all of these different things, without any concern as to what the routines are.
All that C++'s virtual keyword does is hide this behind syntactic sugar. And, restrict your ability to inherit to those case where the compiler has a nobrainer to determine that the virtual tables are the same.
Objective C adds the tradeoff that instead of having numerical offsets (known at compile time) into the virtual table, it has a string lookup done at runtime instead.
Michael
--
I am a Cocoa/WOF/EOF developer, and it looks like I'll be availble for hire. Please contact me at michael-job @ stb.nccom.com if interested.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.