[openbeos] Re: Innovation: Design and Programming
- From: Lunar <lunar@xxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 1 May 2003 01:44:30 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
<lurker-mode-off />
On mercredi, avr 30, 2003, at 01:32 Europe/Paris, Michael Phipps wrote:
Be did very little to make BeOS accesible to other languages. Their
answer was "write the interpreter/run time environment in C++ and
access our code that way". And that is a fairly reasonable answer,
from the POV that the OS was still rapidly mutating. But, looking
forward, it is not impossible to see a future where some of the pieces
are slow to change their API. There are only so many ways that you can
skin a screensaver API, for example. So what sort of ways can we make
some allowance for other languages?
Most interesting example recently is Mac OS X.
This operating system is based on NeXTSTEP which API is entirely
written in Objective-C. Because of the Posix compliance (and Darwin for
Mac OS X), the low level API are in plain C.
But, because of Mac OS Clasic legacy, Carbon API is C++. And Mac OS X
did a lot emphasis on Java programming.
Java is really a nice _usable_[1] language right now. I think that Mac
OS X JVM implementation is the best available at this time. It's fast,
and there's a native look and feel for graphical applications.
Unfortunately, Apple should now maintain 3 different API for 1
operating system. And this is an hard work. Even a big company like
Apple is actually frustrating developers. For example, there's no Java
binding for accessing the Rendezvous API in Java. And be aware that a
Java<->Objective-C bridge seems not really difficult to make (you can
look at JIGS in the GNUStep project).
BeOS isn't really C++. Important (IMHO) language features like
exceptions and templates are not used. This ease language agnotism, but
when doing bindings for a language such as Java, where exceptions are
really common with a pretty syntax you have to write a lot more code to
have a nicely integrated API. This is even harder when you want a nice
API for a really different[1] language.
I would prefer being forced to use C++ with a clean, used, maintained,
integrated API than using bad bindings.
Lunar.
[1] I'm found of functional programming language as Objective Caml or
Haskell. Theses languages are what I usually call nice. But for daily
applications, their API are not mature enough. But it's coming, look at
mldonkey for example.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE+sF/hd1rcjNWgdWQRArjzAJ4oPGljMLEck7DqfLu1Ie2z9r9UugCfcgg8
1oOLVLH/DylzaMtY0XrwAB0=
=FmZH
-----END PGP SIGNATURE-----
Other related posts:
