On Tuesday, Oct 14, 2003, at 14:38 America/New_York, Drew McCormack
wrote:
>> Along the same lines, ObjC doesn't have a short way to say anything
>> (no operators). Probably my favorite feature of Python are strings,
>> lists and dicts, with all the great __setitem__/__getitem__ stuff to
>> go with it. In ObjC, a+b never means anything useful, unless a and b
>> are primitive C types.. that's obnoxious, because you'd have to say
>> a.add_(b) or something like that... Imagine writing an equation like
>> that.
> Well, I have a different view of operator overloading. I think it is
> generally unnecessary, and can even have negative effects. The problem
> is, a lot of people don't know what is happening behind the scenes. If
> you have a matrix expression in C++ like this
>> a = b * c + d
>> you are creating two temporary objects. This has lead to the dismal
> performance of C++ in number crunching in the past.
> At least in Objective-C, it is explicit:
Yes, for doing math using custom types and creating temporary objects
is kind of stupid. What you really want for that kind of math is to
describe an operation and then apply the operation to a set of objects
in such a way that doesn't create a bunch of useless temporary sludge.
I'm sure there's some languages out there that do stuff like this
(implicitly or explicitly) but I've never seen one that's mainstream.
What I really meant were things like descriptors, sequences, slices,
dicts, callable objects, etc. These are all generally very elegant in
Python (once you get over __this__).
>> Sure, in ObjC you can use int, long, float, double.. but what about
>> equivalents to Python's long or complex?
> ??
> typedef struct _Complex {
> double real, imag;
> } Complex;
<math.h>'s abs() can't take a _Complex. It's just not treated as
nicely as the my-processor-understands-these-natively number types by
the standard library. You can't add two _Complex with a + either.
> Where I prefer Obj-C/Cocoa:
> Possibility of static typing (makes large programs more readable, and
> catches a few bugs at compile time)
> Design of libraries. Cocoa is beautifully designed and stable. I have
> the feeling python's libs have evolved in a less stable way. With each
> new release of python, things get replaced, indicating they weren't
> that well done the first time round.
Explicit static typing is ok, sometimes, I just don't like to have to
do it and I don't like to explicitly cast things all the time. Usually
the only time I want to do it is for performance reasons (static typing
of non-objects). What *really* bugs me about static typing in
languages like C# is that you have to explicitly cast things from
object to another type, even though it's an absolutely worthless
convention for catching legitimately mismatched types at compile time.
This sort of thing happens ALL the time when you're working with data
structures like hash tables. Ideally static typing should be more like
it is in ML.
Cocoa is well designed and stable, but it's a GUI framework. Python
doesn't really have one of those that doesn't inherit the warts from
whichever underlying C/C++ library it's talking to. The exception, of
course, is PyObjC which talks to Cocoa and doesn't come standard with
very many warts.
Apple has made good frameworks and bad frameworks (or at least, they
release incomplete ones that a lot of people are using). The
Authorization framework for example is a chore to use (in the way that
they show you how to use it, at least) and allows for a few
opportunities to hijack a file that's about to be given suid root,
although they are difficult to pull off. Their installation framework
kinda sucks, and often gives /Library g+w admin, which means that you
can put arbitrary will-run-as-root-next-time-you-boot code in
/Library/StartupItems as an administrator... This is a pretty big
(read: almost Microsoft-like) security hole and will require changes to
the frameworks (both implementation and interface) that they just
haven't done yet. Personally, I think /Library/StartupItems scripts
should be run as whichever user owns the bundle, which would solve that
problem even if /Library had junked permissions, but would break a lot
of existing software that needs startup items. A workaround for this
is pretty easy though, on startup it could warn the user that "Warning:
The following startup items wish to be run with full permissions but
have not yet been granted access. If one of these startup items has
malicious code, and you run it, you're screwed. Click this button if
you would like to authorize any of them. Note that authorization
requires an administrator login and password."
That said, Apple code probably gets more eyes on it and more stringent
review Python code. A lot of Python code I've seen in the wild looks
like first-thing-that-worked prototypes, and this includes code in the
standard library. I generally try and look at the source for Python
libraries before I try and use them for anything. If the
implementation or interface sucks, I'll probably find another one that
does the same thing, try and help fix it, or write my own (either full
replacement, or subset of it that's designed to do what I need). I
can't do that with (some) Apple frameworks, although in many cases I'd
like to.
-bob