Swift has no future beyond the Mac. Just like Objective-C.
Python native API bindings make the most sense.
As much as I dislike Python but I have to agree with you.
“… make the most sense”, out of which alternatives, with what objective in mind?
In my experience with Python native API bindings … kind of complicated for casual use, and kind of limited for serious applications. Python itself sure has some advantages over C++, but it isn’t the ultimate in software engineering either (I lost a lot of enthusiasm for it over the years.) I wouldn’t say Haskell is perfect either, but if I could pick the set of alternatives and the objective, I could make a case that a Haskell native API makes the most sense. Someone else could probably argue that an Objective CAML native API makes the most sense.
We have a Node.js build on Haiku. Bindings for that shouldn’t be too hard. ES6/JavaScript is one of the world’s most popular languages and may open us up to a lot more developers.
2 Likes
I think Swift or Kotlin would make sense. If we were closer to support Mono, C# would make sense.
1 Like
Hi…what is the status of the Node.js build - is it completely working? what version? available for public consumption yet? if so where to get it?
https://discuss.haiku-os.org/t/finished-porting-experimentally-core-node-js-to-haiku/7468/13
Javascript, oh no 
! Say goodbye to speed and efficiency of applications… Say hello to completely insane language semantics…
1 Like
I would definitely take a hard look at swift. I already know C++ very well, but I haven’t had a chance to do much with swift. It would be interesting to give it a shot.
Not seeing Haskell nor Curry being used as an API caller here(probably not even a functional language either). Specially when haskell support is not-ready on haiku itself (old GHC), and good luck trying to migrate a current GHC here.
I migrated that to be “ok, could be done if we cut here, put some placeholder here… voilà, node in Haiku”, not an usable version right now. It was 11.0PRE (iirc), and you could get from the thread links itself and build it (hours of compile time?) . I would wait for someone (other person or myself) to port a LTS version in a saner way before using it for … anything.
Also, creating native calls were not that easy, back in mammuts era when I read about that in Node, despite agreeing on popular languages attracting peeps.
V8 execution of javascript isnt slow, it’s all the browser blobs of code that go above what make it go bloatware. I have a discord bot 24/7 running on node and works very well (speed & very low mem usage). regarding language semantics, clearly agree 
Wish we can achieve Kotlin (JVM) and migrate/port/adapt Kotlin Native on Haiku. Regarding C#, and knowing all the LLVM nightmares it would bring, i wouldnt migrate Mono but .NetCore, as that’s the future for now on (and would allow ASP/MVC web development).
I would “master” the language before making an API itself. Dont even dare to create a full official one in Python, despite coding most of the time in it since years (at work / home).
Probably, I don’t know. I just see things like, the only possible number type is floating point, and that it uses run time type inference with type coercion like someone read a python handbook backwards, and then look at the memory footprints of a few electron apps, and think… this is probably not the most efficient way to do things.
Hi,
I see a lot of fighting over which language would be better, and little work done.
Bindings for any language are welcome. Pick your favorite one, start hacking and see where you can get. You will learn about both Haiku and your language 
There is also opportunity for collaboration, trying to share some of the effort between different languages. SWIG may be used, or specifically for Haiku, there is/was a libcharlemagne which also made this possible.
So, you have all the needed resources, now someone has to do the work. No need to argue over which language to pick here, just start hacking and see how far you can get.
3 Likes
Lol, sorry. I don’t want want to discourage even JS ports. Though I reserve the right to moan about them…
I have a TODO in Paladin to add hey support. https://github.com/adamfowleruk/Paladin/issues/237
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.
2 Likes
that is a privilege from being in UK, here english is mandatory only from the fifth school year onwards…
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.
I gotta disagree. The entire browser-based idea of software is what turned Mac/Windows/Android into the bloated, homogenized hell that they are today.
My 2 cents: Haiku should avoid those things like the plague.
1 Like
It also gave us Slack, Spotify, VS Code, Atom, etc. While it’s bloated as hell, it does serve a purpose.
I do agree Haiku shouldn’t go near the Electrons of the world and stick with QT and native UI controls.
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.)
4 Likes
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…
4 Likes