I am getting lost a bit here. I think politics and engineering should stay as far apart as possible.
I don’t want to give up engineering though.
@PulkoMandy
Why do you continue to confuse the issues of application development with operating system development. I’m not talking so much about operating system development because the 20+ years have already been spent on using C++ to develop Haiku. My goal is to see that the interactions of new software doesn’t take another 20 years to write. If we stick with C++ it likely will take another 20 years to get established. That is a non-goal.
Re:Transpilers That Target C++
At a big C++ standards conference, the author of CppFront wrote his transpiler to be a simplification of C++ in that it generates C++20 and skips all the earlier versions’ kludges that were maintained only for backward compatibility. No object code or headers are dealt with in “C++ v2”, just modules as C++20 uses. His goal was to simplify the language so that new developers wouldn’t have to deal with 30 years of Bjorne Stroussup’s technical debt by maintaining backward compatibility to early versions of C++. If it were finished, I’d be using it already.
When I started writing Yab2Cpp, my goal was not only to translate BASIC to C++, but to learn the new standards and get familiarized with smart pointers from C++11. What a disaster that learning experience was! C++ grows new appendages every 3 years and you are just expected to know that the old code needs refreshing to use them! To update it to modern C++ would be a total rewrite now!
Takeaways
The C++ that Haiku was written in will not go away overnight. It will need to be debugged the rest of the way but that’s the nature of technical debt. I was wrong to trust Bjorne Stroussup back in the 90’s. If I knew C++ would turn into a largely different language in 2011 and again in 2020, I would have used it as a backend language to a transpiler back then too. (Actually, I tried to do that then too.)
For the applications side things are a bit different. Native apps will probably always need to interface with the Be API in one way or another, this is very tied to C++ and also very central to Haiku, and I don’t think that’s going to change.
So, if you want to write apps in other languages you have several solutions:
- Find a way to bind to the C++ API
- Ignore all of libbe and reimplement it (communicate directly with app_server, etc) - expect a lot of breakage since most of the interfaces you will be using are considered private (a requirement to allow us to change them, as long as we keep the “surface” APIs stable)
- Find something that already does bindings for you. This could be using Xlibe, using Wayland, using SDL2 which has binding to pretty much any other language, etc.
The third way is the least native but the easiest. The first way remains so close to C++ that it will be hard to fit into another language, we know this from the experience of Bethon that did this for Python, and from similar projects for Perl (I forgot its name). The bindings essentially result in writing C++ translated into another language.
Rust bindings as well following a similar approach, you can find that here: haiku - Rust but work on the interface kit has not yet started.
So, what now? Should we wait for these thigns to be completed? Until then I will be writing my apps in C++…
CppFront and D are already able to link with C++ code. The first uses C++20 as a transpiler and then D uses the same name-mangling scheme as C++ uses. I think D is looking more promising than doing app development in Rust now because of the difficulty that Rust has binding to name-mangled C++. You’re right that C++ isn’t going to go away but that doesn’t mean that we have to be shackled to the helm of the sinking ship.
I’ll look at implementing the Phobos runtime for D. Don’t expect full Digital Mars D compiler overnight but I’ll see what I can do. Maybe we can use the GCC version.
If application development, you might look into NCDPs.
I started referring to a hunt the wumpus strategy through deduction.
As you mentioned, some issues relate to OS integration (like MediaKit or POSIX compliance). Another is application maintenance and management (like HaikuArchives and HaikuPorts).
If you are seeking to refine the wheel, are the spokes damaged or wheel warped beyond repair (i.e. define the damages , then, is the current PL
(i.e C++) ineffective to resolve issue efficiently).
Through NCDPs, visualize, model, and create app dev solution(s) first per requirements defined.
There are thoughts on the existing applications and how modernized refreshed versions can exist.
I know some of these words.
Network Clock Distribution Protocols?
No-code development program. Some people know them as programs used for writing other programs (or code).
Redesign software and export to chosen PL (i.e C++, etc).
Don’t initially focus on building a mousetrap by its individual parts versus the mouse you’re capturing. You might discover the mouse is a possum…
Alright! I started writing a reduced code graphical editor using wxFrameBuilder at one point. Maybe I could restart development on that for native Haiku! The plan was to use an XML syntax for text-based version control like Git and locale support to limit the English dependencies of menu items and requesters.
One problem I ran into with my design was that modal requesters tended to spawn additional modal requesters until you had many layers of requesters open at the same time. I don’t think I can stack-and-tile my way out of that one. Maybe there’s a way to make them share a window.
I’ll start another thread on that one.
C might be the default but you can also set it to generate C++. The Wikipedia page on so-called source to source compilers includes a table that shows Nim amongst only a few that output this language, although I suspect the list is not exhaustive.
re:Visual Code Editor
After looking at the syntax of D, it seems to more closely match what I was looking for with my graphical language. First things first. Let me look at the D runtimes.
D looks very nice. Unfortunatly it only has managed memory AFAIK.
From what I gathered, your transpiler generates C++ source files for GCC/LLVM compilation.
- C++ Supportable:
- C++98 (BeOS R5, optional)
- C++11 (default)
Goals:
- WxFormBuilder-like visual code editor
- Convert YABASIC 2.90-compat source files to C++11.
- XML sytax for text-based version control
- International language support (English, default)
Correct as needed.
Now application developers can develop native Haiku applications and device drivers in YABASIC and get C++ performance - without knowing C++…
Many years ago, I saw certain very high-level ‘rapid’ application development programs that basically used pseudocode (like XML) for project development and could import/export C/C++ files.
Sidenote:
As for the structured BASIC programming discussion, Pascal was force fed on many pupils learning data structures and database programming. You’d get the Pascal compiler for academia settings. In comparison, BASIC implementations in academia were almost never with the BASIC compiler component (usually only in the certain well-funded schools and some colleges/universities). Home computers usually never had BASIC compilers included due to extra license costs. Historically, most distributors provided cut-down versions or variants of their BASIC implementation (so you’d buy the compiler and/or a full-featured version (kinda, might miss the matrix support and other things)). Those were the days of the $500 smart typewriters…
So academia taught from the BASIC->PASCAL model. Modula-2 wasn’t as popular in most academia circles (funding and training costs). College/university and scientific work-wise, you’d get on-the-job trained and access to the VAX-11/Cray/other machines using C (or you’d learn those ‘business’ and ‘report generation’ programming languages). C++ didn’t exist or was still in its compiler implementation infancy so not heavily used or taught back then for any cross-platform kernel/app development.
And maybe support for newer C++ versions?
I find it hard to think of “academia” as a single body in this case. It’s like saying “industry” picked one single language. If we take the 90s that wasn’t the case at all for industry: UNIX had C, BeOS had C++, NeXT had objective-C, and MacOS had a bit of everything but maybe a bit more Pascal. And then each app could possibly be written in a different language.
Likewise in academia, and in previous times too. One of my teachers had learnt and used Simula-67 (one of the first object oriented languages, and the one that defined the object model used in C++ 20 years later), and that was one of the many options. Likewise Pascal is just one of the many derivatives of the ALGOL family (in fact, it is a kind of fork of ALGOL after failing to get enhancements included in the original). And besides the ALGOL school (which is where a lot of modern languages indirectly draw inspiration from) there are also COBOL and FORTRAN and Lisp.
ALGOL is also notable for inventing the “design by committee” method, and specifying a language so complex that no one would actually implement it for several years. Several people hated it and the committee specifying it had a part publishing a “minority report” explaining how bad they thought the language was. Yet, it was an inspiration for both Pascal and C, and then, these two were an inspiration for a lot of modern languages.
-
C++ Manual:
- ISO/IEC 14882:2020 (Edition 6, 2020-12)
-
GCC 11.2.0:
- C++17 (GNU++17, default)
- C++20
- C++23
-
LLVM 16.0.5:
- C++17 (GNU++17, default)
- C++20
- C++23
You’re mixing the capabilities of separate but potentially intertwined projects. The YAB2C++ transpiler could be recoded as a 2-pass translator to XML, the XML transpiler/exporter could target D or C++ (separate transpilers), the GUI based editor and all the necessary locales for that (plus a few extras).
The extra locales mentioned above can replace technical jargon with more descriptive terminology. A loop repeats code so the simplified version could call it a repeater instead, for example. The goal is to lower the barrier to entering the art of programming.
I remember only an XML wrapper for Java. Were they open source? I can check my bookmarks too.
edit:
Was it http://www.o-xml.org/ by chance?
Please reply on the “XML Code format” thread
Looks like your sidenote pretty much describes the situation in my school days. I remember our modula 2 compiler had many faults for instance which for me meant I only used it minimally. Also I remember a VAX PDP 11 mainframe with discrete CPU’s in it that was never able to fully boot anymore. But I loved how they were able to build a computer that way with all these low integrated circuits, transistors and magnetic core memory…
We also did Motorola assembly along with a very detailed description in lessons of how that CPU was designed. After a year when I finally grasped the thing it became my first love… (6802, later on 6809 and a bit 68000)
Sorry for the sidenote extension in the thread…