I recently got started with Haiku and I was sold within 30 minutes of installing and playing with.
So, as a software developer with some years of experience I started looking at my options to develop
software for Haiku. So far C++ looks like the best choice. But C++ is not an inviting language to my opinion anymore. I would like to have something more high-level that can compile to native code. Perhaps GoLang, or C#, even JS. From what I could find on the community lists, it all come down to the language-bindings to the native Haiku API and it looks like there is not much expect for experimentation for python.
Go, C# both unsupported on Haiku so you need to port them first (but there is an unfinished mono port if you interested). Hopefully somebody else can give some hints about the other ways.
I have OCaml working to some extent with the API. I like it, it’s modern though in a conservative way (sad that “modern” in computer programming languages goes back so far.)
But it’s an uncomfortable relationship, as it is bound to be. Modern languages need a “runtime” to support those features, and it’s always going to be a little hairy to make that work with a language like C++ without them, in a heavily multi-threaded environment like Haiku GUI programs. The API isn’t rigorously documented on the things we need to know, like object lifetime/ownership. The problems aren’t the same in each language.
So while I continue to amuse myself with this kind of thing, if you want to write software, good old uninviting C++ is the best bet. Haiku’s C++ is mostly from the '90s and fairly straightforward, and there’s a good debugger.
Yes, as @donn said, best option is C++. As @waddlesplash pointed out, there are API bindings for Python though I had some issues trying to use some parts of them, though overall, they look fine. Might need an update?. Then there is the PyBind11 approach pointed out by @aarroyochere .
And then there is the integration with the OS. I’m trying to learn how to do that (C++ wrapper around Python) before going down to actually write a Python code software for Haiku, because, for now, a C++ wrapper will be needed for a Python software to integrate with the system, AFAIK. Though C++ scares the hell out of me… all those pointers, mallocs…
Well, if you aren’t totally stuck on Python, you might look at OCaml. It isn’t the most beautiful language ever, but it’s very “functional.” There’s a rather elegant OOP side too, that hardly anyone uses, but I’m sure some do.
And it compiles, on Haiku. On x86_64, only compiles to byte code, but unlike Python that’s good enough to apply icons and so forth, for the full native experience. (Given that, native code compilation is not important for typical Haiku applications, but that is supported on 32 bits, and eventually may be on 64. I don’t think I’m up for trying to make that happen - you’d think it would be easy, given that it’s supported on other platforms like MacOS, but Haiku’s x86_64 has relocation issues that don’t come up elsewhere, apparently because we link with -shared - but no doubt it will happen if really needed.)
Actually, to be honest, the decision to use Python and not other was taken thanks to Haiku. When I started with Game Dev, I used Unity3D and C#. Then, thanks to Haiku I met Godot Engine, which is what I’m using right now. C# on Haiku is rather nonexistent at the moment so, in my “wishful thinking ahead”, I decided to go with GDScript, that resembles Python, therefore, “no need” to learn two different languages. Then, as when Godot ends up working fine on Haiku I would have to use GDScript, I will have half way already traveled. It seemed the best option, as my free time is limited, therefore it’s like optimizing resources using GDScript in Godot, and Python for software (not that I have much time to do both, though). Everything goes slooooooooooooooow…
Of course, it’s quite fast to develop Python flatpak software with GnomeBuilder and Glade, and quite straightforward. On Haiku it’s a different story… … yet.
Not really stuck on Python. I haven’t heard of Ocaml before but Ocam’s Razor in Philosophy classes back then. If situation would be different, I could try Ocaml for sure. In my actual situation, well… though you never know…
Stay with C++ (98) and develop whatever application you want with the Haiku API knowing that developing applications this way is not going to be easy. You have to deal with the low level stuff on top of your application logic. (e.g. memory C++ management)
Go with a language that has bindings to the Haiku API. Python (needs some work) Ocaml (I don’t know this language). Knowing that the bindings may or may not work and you still have to do C++ style of programming to use those bindings.
Go with .NET. This does not work at the moment since the Mono implementation for Haiku is not working/finished due a very low level problem that has not been fixed (perhaps it was too difficult).
Implement a binding for GoLang. We have GoLang 1.4.x for Haiku. The are many examples of bridging C++ from Go. This requires experimentation and good design so working with the new bindings would feel natural in a GoLang ecosystem.
Go with Yab. This is a BASIC programming environment for Haiku. I gave it a try. it is nice. But I don’t want to give in just yet. (I am a software developer, why do things easy when I can make it difficult for myself?)
Go with JAVA. You will be able to develop your apps right away. I don’t want to give in just jet for the reason mentioned above.
Implement React Native for Haiku API and develop in JavaScript/Typescript. This might actually work (I think). We have NodeJS on Haiku and React Native internals are not that complex to understand. For this you will need C++11 knowledge.
Go with NodeJS and create Haiku bindings using N-API (NodeJS native API). This will require the same amount of effort as the React Native path.
Go with Webkit and build hybrid apps. I have not tested this possibility yet. It might work if we can make/port an Electron style wrapper for the version of WebKit on Haiku. Hybrid apps will not look and feel like native Haiku apps.
Go crazy. Bring a new language to Haiku, for example Rust and while you are working on that also create the bindings to talk to the Haiku GUI API from Rust.
Go insane. Implement you own compiler for Haiku for an existing language. Pick an ANTLR 4 grammar. (I prefer VB6, seriously). For this you would need to build a LLVM frontend and a runtime for your language and have knowledge of compiler design. Not an impossible task and if/when you succeed you will be a celebrity.
(As a side note, I still need to figure out how to find resources (time/finances) should I decide to go with any of the above. As you might know, you won’t be able to do this type of work seriously by programming in your spare time/weekends/and such. It will never get finished and you might lose interest eventually).
So far playing and experimenting on Haiku has been very pleasant. Respect to the team putting the time an effort making all this possible.
I will come with a new update on my findings soon. So stay tuned
Modern C++ is available if use command setarch x86.
You can use owning pointers (ObjectDeleter, BReference) to avoid manual memory management. Also most Haiku API objects like BView own child objects, so manual deleting is not needed.
Basic for BeOS/Haiku is already exists, it is called Yab and available at HaikuDepot.
OCaml has a newer syntax called ReasonML which makes it look a bit more like JavaScript. There is currently a project by a few people to create a new cross-platform editor called Onivim 2 based on their own GUI framework called Revery, which is sort of like ReactNative. I worked on a few features for Onivim 2 and found it quite pleasant to work on ReasonML and this Revery framework. It might be nice to get this stuff ported to Haiku as another decent option for modern application development. They still would not be fully native but I think that is okay. Having Onivim 2 on Haiku would be awesome. It is sort of like a hybrid between vim and VSCode, but much faster than VSCode due to the OCaml native code for the GUI.
But further on that general topic I think Haiku could benefit from a more declarative style of GUI construction, like Revery or ReactNative or XAML in Windows. Theoretically if there was a library which covered the GUI construction there could be bindings in various languages, all backed by the standard BeOS/Haiku GUI classes.
This has been a topic I have been thinking about for a while but have not had a chance to maybe explore some prototyping.
Also some people might be interested in libcharlemagne from former Haiku developer DarkWyrm, this provides a C API wrapper around the Haiku API which would make it easier to make bindings to other languages. I don’t think it is complete but at the same time I don’t think there is much work left. It was part of a project of his to create a graphical GUI designer for Haiku as part of his Paladin project. Paladin has been taken over by other people but PDesigner was abandoned: https://github.com/HaikuArchives/PDesigner
For me, C++ is not, per se, the main barrier to alternative language bindings. For sure, you can’t call directly to C++, but you’ll likely need some kind of layer anyway that converts data types between the two languages, and since that can be in C++, that problem is solved. Declare the entry points extern “C”, and it’s like calling C.
The big problems are serious mismatches in features. Object ownership and lifetime is a big deal for most languages, and that’s not much documented for the API. Many languages don’t have anything like C++ function name overloading, so if you want to support two different calling conventions for SendMessage, one of them needs a new name. Most languages will be able to get along with the heavily multi-threaded GUI design, but there will be some headaches.
I may be lacking in vision, but I can’t picture a library that is going to solve these problems for multiple languages. That energy could be better spent - if that’s the goal - on a comprehensive dictionary of Haiku classes and entry points, with all their assumptions documented in machine readable form. I’ll still have to figure out how to implement the bindings for whatever language, but once I have done that, the whole API is in reach. (Well, maybe not the whole API - some languages may not work with shelves, there may be no sane way to deal with template heavy code like the new layout stuff, etc. But the key parts.)
I can describe how to write a Yab to C++ transpiler using a pass-and-a-half compilation strategy if you have time to implement it. It will need a separate thread to discuss it though.
This binding use Haiku modules directly without C wrappers, it use name mangling, vtable declarations and minimal C++ RTTI support. Binding is targeting 32 bit x86 GCC4+ ABI. I managed to get simple application with window that draw simple graphics. While making this I identified and fixed problems with stack alignment ([ccall16]) and mixed stdcall/ccall calling convention for functions that returns classes by value.
I was going to propose that named parameters could serve to sort of simulate overloading - for your example there, a wrapper function could look for parameters “command” and “message” and decide which overloaded function to call. But that wouldn’t support compile time typing - what if neither of them is present? And OCaml presents another problem that’s a little more obscure if you aren’t used to functional languages – a function applied to some of its (leftmost) arguments is a “partial” application that can later be applied to the rest of them; there’s no way to distinguish partial application from absence of optional arguments unless a non-optional parameter occurs after them. As would often not be the case with the API, like your PostMessage example.
