Peter Meyer wrote:
> I'd expect that C++ would be a better tool (no experience
> myself), but I suspect the development tool would be driven also by
> what body of experience the contributors have. Certainly there are
> more C++ programmers out there.
Probably an important first step for this project would be to
somehow get at least a rough inventory of who the initial
contributors will be, their programming skills and experience
levels, their existing hardware and software resources, and
their realistic estimates of the amount of time they can commit
to this project.
> [Peter]: A real consideration [of the programming language choice]
> should also be what will yield the best product.
Yes. But (sigh) the word "best" has many interpretations. For
example, here are some possible metrics and languages they suggest:
* Most reliable product (fewest bugs/crashes)
--> Suggests a "safe" language: type-safe, easy to read, debug,
and maintain, automatic memory management
* Fastest-developed product
--> Suggests a rapid prototyping language whose implementation is
fast and powerful enough for the final product, too
* Fastest-running product
--> Suggests a compiled language; interpreted languages like Java
would probably be too slow, especially since OpenTalk will
likely be an interpreted language itself, adding another
level of slowdown.
* Product is most-compatible or extendible with add-ons written
in other programming or scripting languages
--> Suggests a language that makes standard plug-ins or hooks
easy (something OSA? I'm shooting in the dark here; I'm
not familiar with OSA.)
* Product is easy to develop because its implementation language
is similar to OpenTalk itself, feature-wise (not necessarily
similar in syntax, although that wouldn't hurt).
--> Suggests an xTalk-like language, something strong in
string manipulation. (Write OpenCard using MetaCard?
Sleep with the enemy? ;^) What about RealBasic?
* Product easy to integrate with MacOS and keep up with future
MacOS revs
--> Suggests whatever language Apple developers are now using
or plan to be using in the near future
Also, the ideal programming language and development environment
would be low-cost, high-quality, easy to obtain (preferably free),
and have good debugging and configuration management tools
(version control, automated build or script integration tools, etc.)
Cross-platform wouldn't hurt.
Of course, something that met all those criteria would probably
command a price of $10K a seat.
Here's my take on some of the more obvious language candidates.
Feel free to disagree, clarify, etc. I've been away from
programming for a while, so my knowledge is a bit rusty.
Let's clear the air and eliminate COBOL and FORTRAN up front. ;)
C++ is sort of the "Windows 95" of programming languages: nobody
thinks it's pretty, and it's often painful to use, but everybody
uses it -- because everybody uses it. So like Windows 95, it's
the obvious FUD-safe choice. There's lots of existing C++ code
out there to look at and use, the free GNU stuff is available,
and the bookshelves are full of C++ books. But look out, here
come the memory leaks.
A well-designed, type-safe language like Pascal or Ada would
probably make this project more accessible to students, not
just professionals. Students are (by definition) inexperienced
and make lots of mistakes, but they are also high-energy, they
can have good ideas, and might be able to afford big blocks
of programming time at zero pay.
Ada seems pretty far afield from the Mac. (But hey -- if we
got OpenCard up and running on military computers, ain't
NOBODY gonna shoot that baby down! :^)
Pascal is probably doable. I haven't used CodeWarrior Pascal
yet; the last Pascal I used was Think Pascal (my age is showing).
Pascal seems to be the "Mac" of programming languages --
it works just fine, and it can do whatever you need it to, but
like the Mac, it gets dissed because it's perceived as
"too easy", generally in comparison to C++.
Easy = wimpy; complicated = macho. We all know that, right?
Right. :^o
RealBasic is itself still in development, although apparently
usable. It might be a nice compromise between an overly ugly
C++ and a don't-get-no-respect Pascal. It's object-oriented
and intentionally similar to Visual Basic, so there's the
obvious cross-platform link. Hmmmmm. I have a copy, but
haven't opened it yet, so I can't say more. But it seems
similar in spirit to HyperCard -- it's supposedly a RAD tool.
Is there anyone here who has used RB? What's been your
experience?
If MacOS 10 is being done in Objective C and NextStep (neither
of which I'm familiar with) that would seem to be a smart
direction to go in terms of creating a product that will play
well with upcoming MacOS releases. My ignorance is vast here.
I don't know what the availability and cross-platform
implications of using Objective C are, for example. (But wasn't
there an OpenStep? Is OpenStep an open-source Objective
C environment, or what?) Someone please step in and fill
in the gaps here, too. NextStep is supposedly wonderful.
I'm not familiar with PERL, so I can't speak to that. I'm
guessing many of the other contributors won't be familiar
with it, but I really don't know. If so, and if it's the
chosen language, some of us would be in "learning it" mode
for a while before becoming productive. Likewise for other
non-mainstream-but-probably-worthy languages, like Python,
Icon, Scheme, name-your-favorite-language-here.
WAAAY out on a limb would be a language that maps well to
multiple processors -- whatever THAT would be. (Prograph?)
Upcoming generations of Macs may be MP, yes? I wonder
if an OpenCard that took advantage of multiple CPUs would
overcome the slowdown of interpreted OpenTalk.
Just my 2 centavo's worth.
-- Tony
