This will be pretty quick and easy to add as hey knows a Haiku app’s semantics.
Something I also want to do for Paladin is add a plugin capability to segment out things like language support, compiler error message parsing, and so on. It will make the code neater and allow others to contribute plugins separate from the main runtime.
As part of that plugin work I was going to try and ensure the plugin could be written in any language, including Python, by generating bindings in other languages. Whether we like it or not, Python is the dominant application scripting language.
Also, I’m not sure about outside the UK, but literally every school kid the last 5 years has been taught Python at age 13-15. So even non hardcore programmers in the UK will know how to do basic scripting in Python. A useful user base to have. I work with a youth group in my spare time and ran the first programming project lesson the other day, and the majority of them could code ok.
Actually I have a fair start at a Haskell binding, enough to use for my IMAP email application. TextView, ScrollView, columnar drawing in ListView. The only thing I’d be worried about if it needed to be really ready for general use is memory leaks. As a way to do the API, it’s inferior to C++, just as all the other non-C++ alternatives will be, but at least Haskell has enough going for it as a programming language to make it interesting.
I’m using GHC 8.2.2, which seems to run fine on Haiku until you use it to build itself, whereupon it occasionally crashes - not a serious obstacle unless you depend on automated builds, as Haiku distribution does.
Personally, I think that being able to create basic applications in JS/CSS/XML/HTML, maybe with support for additional libraries and languages, is definitely something that would help Haiku in the modern age. A lot of modern application/high-level developers are approaching things from this angle, and it would help get more applications into Haiku.
I know that there’s an argument for all system-native applications, and I agree that they add a beautiful consistency that all the other DEs sorely lack. It’s literally the closest thing one can get to the Mac or Palm in terms of everything being very clean and similar throughout the UI, but maybe what Haiku needs is a set of human interface guidelines (HIG) for third-party applications and not just for native programs. It’d extend the range of Haiku and allow it to gain more share with both the dev base and userbase, or at least, in my humble opinion.
FWIW HaikuPorts has (pre-emptively) banned applications that ship a statically linked web browsing core. They can use ones that have their own package, but not a bundled one, which rules out most Electron apps automatically (they could theoretically make a single “libelectron” package and use that, but that goes against how Electron is presently designed.)
I think advanced users and developers on all operating systems have a love/hate relationship with Electron apps. They can be quite beautiful, and are at least consistent across different operating systems, but of course do not really obey much of the standards and design of each OS they run on. They are incredible resource hogs, using potentially GBs of RAM.
I think the concept of Electron (cross-platform web-like GUI apps) can be redone with maybe WebAssembly and a React-style GUI framework, providing much of the benefits with less of the drawbacks. Some work has already begun on things like this, but this will take a while to get to the level of Electron.
I am still on the fence as whether cross-platform development systems like this are good or bad for a small OS like Haiku. They can possibly provide more applications for Haiku, but then the same applications can run on other operating systems which means Haiku is nothing special for those apps.
So in the long term probably what is better for Haiku is to take some inspiration from these newer frameworks and provide a Haiku-specific version which can leverage some of the benefits and unique features of Haiku. Of course a big part of this would be various language options besides C++, as we are discussing in this thread. My main concern would be slower languages which can impact the perceived performance and low latency of Haiku apps. But lowering the barrier of entry is also good, so more people can make small apps to solve their own problems. Like many things, it is a fine balance…
I love to mess around with programming languages, but if I wouldn’t expect enough benefit from providing alternatives to C++, to pay for the costs. People will do it, and it’s sure possible that something great will come of it, but it’s a long shot.
If people working on Haiku core wanted to help with that, I’ve mentioned this before (in fact I’ve been suggesting this since BeOS was just a couple years old), the API could be provided with full machine readable documentation. Not just the C++ type signatures, but for example storage issues that the types don’t tell you about, like whether this function stores its (BMessage *) parameter so the caller may not delete it, and so forth. From there, getting the API binding for your favorite language could be fairly easy, you just need a program that reads the documentation and produces the interface for each function and type. I’d make that comments in the source, to be extracted during builds. The documentation could also provide standard “semi-mangled” names for overloaded functions, since C++ overloading isn’t a universal programming language feature.
Regarding ‘bloat’ and Electron (and the non-available concept of a shared libElectron), and HTML/CSS/Javascript Apps, the Chrome browser, as of Version 73 is trying to solve this issue with the ability to install PSA (Progressive Web Apps) like ordinary ‘native’ apps… I think this could be a pretty good start to solving the Electron ‘bloat’ issue…but Haiku would have to get Chrome ported or create a similar framework for it’s WebPositive browser.
Starting in Chrome 73, Desktop Progressive Web Apps are now supported on all desktop platforms , including Chrome OS, Linux, Mac, and Windows.
The HIG does not care about the technology you use to make things work. If you are writing apps for Haiku, you should follow the HIG, otherwise users will throw tomatoes at you because your app is badly integrated.
Wether you write it in yab or C++ is irrelevant, for example. Both are using the native widgets. You may get far but not-quite-there with Qt, too (I hope that will improve further). And you may do as well with other languages.
We are not going to relax the HIG because your app is portable or uses a different programming language.
The technology does not matter, if someone makes an Electron app with a stylesheet that makes it blend with the rest of the OS, makes it start in milliseconds just like native apps, and does not use gigabytes of memory for no good reason, that’s all fine.
I don’t agree with a ban based on the technology at Haikuports. I will not hesitate to give 1-star rating to apps that cause me problems on HaikuDepot, however.
It would be great to have Swift 5.5 for Haiku, it brings so much more to the language. What’s great is, bindings might not be needed anymore (needs confirmation), since cxx interoperability has come a long way as well.