[MUD-Dev] [TECH] [ObjC] : programming languages - Obj-C as opposed to Java

[Brian Hook]

At 04:01 PM 8/16/01 -0600, Kwon Ekstrom wrote:

> I've never used objC so I can't say anything about how things are
> handled with it, but it sounds like you're java code suffered from
> poor design rather than language problems.

This is often the argument used to defend C++, but usually stated in
the form "If you're having problems, it's probably because you don't
know what you're doing".  Which is often true, however "knowing what
you're doing" is a rather moving target, even with C++.  If you read
a book like Meyer or Coplien or D&E by Stroustrup and walk away
thinking that C++ is even remotely conducive to writing robust, easy
to maintain code, I'll be surprised.

For me, C++'s primary problem is that it's greatest strength -- a
nearly agnostic view on language/framework design and implementation
idioms -- undermines its ability to be used by large teams.  Take 10
class hierarchies written by 10 different programmers, and you will
see 10 radically different ways of doing the same things.  This can
become a mess, especially with large collaborative projects where
various team members may not particularly enjoy the idioms
established for that team, project or company.

> I try to define constants on interfaces, and attempt to use more
> or less unique naming of constants (because of multiply interface
> inheritance).  You can then modify the interfaces for a pretty
> similar affect to modifying constants in header files.

I'm a bit confused about the above -- can you rephrase that or
provide an example?

> As for other things such as methods and fields, I prefer the fact
> that java objects are stored in a single place.

That's my point, and maybe your earlier statement which I didn't
quite grok clarifies this.  In Java, your interface and
implementation are equally "exposed" to the public, so performing a
"make" will possibly force a fairly significant rebuild even if
you're only changing an implementation, not an interface.

Physically separating interface and implementation into separate
files seems, to me, to be a very good thing.

> As for exception handling, it's one of the features of java I find
> most useful.

Exception handling can be helpful.  Actually, Java's nicest feature
(to me) is garbage collection.  Very handy, and once you get used to
it it's real tough to go back to doing things "the old way".  I've
seen numerous smart pointer hacks on top of C++ that attempt to do
GC, but they invariably suffer from major implementation problems or
more subtle (but equally destructive) issues like address space/heap
fragmentation.

> For the rest, I'm sure it's just a matter of preference, I prefer
> strongly typed programing languages over weakly typed ones.

Agreed on the first, and on the second, Obj-C provides strong or
weak typing, depending on your needs.

> admit that I still have issues with java's garbage collector, it
> feels wrong to forget about objects... but that's my desire for
> control.

Heh, I find that particularly amusing, since one of the very few
things I like about Java

I will say that Java is a much better language than C++, and my
complaints with it are VERY minor compared to those with C++.  Most
of Java's problems stem from the fact that it's trying to be enough
like C++ to appeal to C++ users (although I found it amusing when I
was in a bookstore today that there was a book called "C++ for Java
Programmers") and that it's trying to stay on the cutting edge and
thus is constantly evolving at a pace that may not be conducive to
stability or well thought out design (which is a problem that
DirectX also suffers from).  Rapid architectural/design changes to
languages and APIs can mean either prompt evolution/improvement or
poorly thought out initial attempts, unfortunately it's usually
both, weighted towards the latter.

I'm going to allocate some time to get my Obj-C/Cocoa kung-fu up to
snuff.  I'm really looking forward to messing with Cocoa/IB on OS X.
The fact that I can build a window that has an NSOpenGLView or
NSQuicktimeView widget is just amazingly cool. =)

If I spend some time doing my GMUD-In-A-Box, it will likely rely on
a plethora of tools developed using Obj-C/Cocoa on OS X.  High
quality tools are the key to fast and effective content generation,
and I would argue that proper tools and technology can radically
affect a game's design philosophy.  For example, if you can whip up
a new "zone" in a week, that changes how you can view your game's
life cycle vs. requiring 6 months to release a new zone.

Brian

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev