[haiku-development] Re: Voting aftermath
- From: "Donn Cave" <donn@xxxxxxxxxxx>
- To: <haiku-development@xxxxxxxxxxxxx>
- Date: Sun, 28 Sep 2008 23:50:32 -0700 (PDT)
Quoth "Michael Phipps" <michael.phipps@xxxxxxxxxxx>:
...
| I believe that having a second development environment for Haiku is a
| good thing. C++ is, honestly, too hard. Yes, I can do it as can a lot
| of other people, but it is really hard. I wouldn't try to develop
| Wonderbrush in Python, but a lot of applications could be written
| a lot faster and in less code in Python. Easier and less code means,
| I believe, more apps. And, unlike VB (for example), Python doesn't
| make you write bad code. Making those apps more easily deployable is
| a good thing.
I can sure agree with a lot of that, of course - there's a lot to be
said for writing in a language with modern conveniences like automatic
memory allocation, no pointers, routine use of exception handling, etc.
What would be even better, though, is something that helps with *threads*.
We don't need to be thread-phobic to notice that there are a few things
that can go wrong in multi-threaded programs. I don't really have any
answer for that, but I think there are some clues.
For example - some years back I had some sample BeOS API programs running
on "stackless" Python, which at the time supported "continuations".
That was some weird stuff, but it allowed me to write code that "called"
functions in another thread strictly by posting and receiving BMessages,
*while* the looper continued to handle other messages. Today's Stackless
doesn't support the exact same stuff, as far as I know, but the basis for
it - multithread-like out-of-order execution within a single OS thread -
is still there.
I think even ordinary Python may help a little, just by rounding off a
little of the concurrency. The interpreter itself serializes multithreaded
computation, so while the application is still multithreaded because of the
parts that are external to the interpreter, in places it might be possible
to neglect locking and get away with it. I haven't thought real hard about
that, and sure wouldn't recommend any practices based on it.
Haskell, my favorite language lately, also has some interesting virtues
for concurrency, but it will be a while before any kind of BeOS API
support.
Donn Cave, donn@xxxxxxxxxxx
Other related posts:
