[haiku-development] Re: Wishlist item: user-friendly programming languages

  • From: Ryan Leavengood <leavengood@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 28 Jan 2011 11:51:33 -0500

On Fri, Jan 28, 2011 at 6:02 AM, Alex Marinko <alxmrnk@xxxxxxxxx> wrote:
> I would like to call the attention of Haiku developers towards the
> importance of having user-friendly programming languages available on
> Haiku.

I definitely agree with you, and for the record my vote (and developer
time) will go toward making Ruby a first-class citizen on Haiku (and
I've been doing some work in that direction lately by helping port the
Rubinius implementation to Haiku.)

I think Stephan properly expressed the dangerous road in trying to
turn this into a committee vote. In the end we will get other
languages because someone puts the work in getting a particular
language working in Haiku and making the Haiku API available from that
language. The former part of that is not so hard (many languages
already work in Haiku) but the latter is where the challenge is.

But fortunately we have Jon doing some great work in that area. Most
any language can interface with C, whereas C++ is quite a bit harder.
So Jon has made this much easier for the rest of us because of his
libcharlemagne which provides a very generic C API wrapper around the
Haiku C++ API. Using SWIG or other Foreign Function Interface support
in another language one can interface with the Haiku API through
libcharlemagne. In addition Jon is building a GUI interface designer
(his main motivation for making libcharlemagne originally) which I
think could also be made available to other language "IDEs" to make it
even easier to create Haiku applications in any language.

So in the end because Jon chose to do something flexible, reusable and
open source, the rest of us have much less work to do. On that note
the best we could probably do now is try to make use of libcharlemagne
from various languages and see what is missing, and then either
provide very clear bug reports or patches to fix those problems.

Lastly in previous discussions we have talked about making a generic
Haiku API description in an easily parsable format would could also
ease creation of API wrappers in other languages. It could also be
used for some automated testing and could form the base of
documentation for a new Haiku Book. Once a format is decided for this
(again someone could be a pioneer here and work on this) then we could
use a divide and conquer approach to manually create all the
descriptions for various parts of the API. These could then be used by
all the various languages. A header parsing tool could generate most
of the boilerplate which could then be filled in with more detail.


Other related posts: