Any wheels that need to be redesigned?

Development
#1

After having pursued the WASI standard of WebAssembly for some time, I’m looking at ways to develop software that need a novel refresh. In the past I’ve seen how older programming languages shove too much load onto the developer to simply not create bugs.

What’s Been Done up to Now

Newer languages like Rust and some of its spin-offs help this by improving the strictness of the parser to disallow the most vile offenders as far as data races and other nasty bugs from even compiling in the first place. It’s even progressing in ways that machines can automate some of their own development. Intellisense helped the development community by auto-generating common names to stop typographical errors.

C++ has been added onto so much in the past 20 years that it’s almost a legacy code in its own right but there are other languages being written that use C++20 or newer as a backend language to avoid all the old things that are deprecated such as CppFront, a 2.0 version of C++ syntax. Carbon is a C++ replacement that uses much of the same infrastructure as Clang.

Are there other novel things that can be done?

Haiku’s Place in the Industry

Stack and Tile are useful ways to avoid having to reinvent common tabbed-editor and IDE styles for dealing with user-interface issues. This is a good start. Many complex things can be reduced to simple things with this type of novelty.

Metadata in the filesystem with database queries are also a good novelty. My first Mac Mini ran MacOS alright but the search indexing auto-generated by its filesystem caused my boot drive to be a tight squeeze on an 80 GB hard drive at the time (over a decade ago now) but I seldom needed to use spotlight to find things on that drive! My external hard drive with all of my documents on it was NTFS formatted and never did fill up. It wasn’t indexed for searching but I found my stuff fine as it was. When I got sick of software not working on Snow Leopard any more I installed Linux rather than Lion (the highest support level for my hardware) and found my 80 GB hard drive worked just fine without the indexed filesystem and was less than half-full after a complete Linux install. MacOS didn’t have the same type of novelty that I was looking for.

Both of these two features are novel but not insurmountably so. This ultimately leads me to my title question: Are there any wheels that need to be redesigned differently to be more useful?

1 Like
#2

Replying to my original post:

Complexity to Simplicity!

As I started thinking of different media-related editors I’ve used throughout the years, I started thinking of how they are almost always monolithic:

Renoise is the music editor I use on Linux. It is a tracker-style editor built up into a full digital audio workstation. The track structure is a time-based editor all its own with its own text-based commands and there is a separate track for each instrumental part. The instruments have their own editor parts with separate tabs for sample editing, filters applied according to time sequence within the note, automation within the scale structure to allow drum-kits to use a different instrument for each note and so on. There is also a separate editor for applying filters to the tracks themselves and modulating tracks with other track filters. There’s complexity on top of complexity and the editors (as truly they are many editors in one) are all an amalgamation of many simpler principles.

HivelyTracker is a chip-tune editor I’ve used for years. It’s another tracker-style editor that lacks some of the features of Renoise but is a free and open-source editor. It has a custom user-interface that is not flexible enough to show more than six tracks on the screen at once even though it supports as many as 16 per block. The instrument editor allows only the waveforms that a Commodore 64’s SID chip could use but filters are available also. The instruments on HivelyTracker are scripted with an interface that advance in a timeline similar to the way that the tracks within the block are also a timeline.

In contrast, Medo is seen by some as being a potential killer app for Haiku. It was supposed to fit into a single floppy disk by using the existing media features of Haiku. Of course there are many bugs to work out of Haiku itself, particularly MediaKit, but this simplicity is a good idea for a start!

Refactoring C++ Code

Object-oriented languages are designed with encapsulation in mind to keep code-bases sane and simple implementations reusable. Some code editors have automated refactoring tools to aid in the breaking down and combining of classes and objects into simpler abstractions or combining them into less-abstract forms when code reuse is not needed.

Going back to the concept of the music editors like Renoise and HivelyTracker, the abstract simplest common denominator of all of the media editors is that they have events triggered from a timeline. Some timelines can be reused like the way that a block is made up of multiple tracks stacked horizontally on the screen. Reusing the same style editor for ANY timeline based on the cron-style (recurring) and at-style (single-shot) timer events would be a start. Even calendar and planners could use such a common gadget. Medo uses such a gadget to coordinate events on a master timeline.

A second part would be having a master instrument editor that would be able to be used by MIDI sequencers and trackers alike. This would split up trackers and piano-rolls and grand-staff notations into one editor and instrument-related stuff into a separate entity. If that much could be simplified into modular parts, any media editor could likewise be made simpler as well!

Do any of you see any other simplifications that could be made into a macro-beast using stack-and-tile to combine them?

#3

With respect to programming languages, recently I’ve taken a good look at D and have been very impressed. As a long time C/C++ developer I’ve known of it’s existence for a long time, but overlooked it totally. It’s a really nice modern language and in my opinion comes out ahead of C and C++ and even more modern languages in many ways. Recommend you take a close look if you aren’t already familiar with it.

3 Likes
#4

If there is one thing that needs to be changed about Haiku, it’s definitely C++.

I’m guilty of overlooking D as well. How does D compare to other languages like Rust?

1 Like
#5

I don’t know about changed, but added to would probably be nice. I often wonder how many people look at Haiku and are interested, but already deeply ingrained in C# or Swift or Rust and don’t feel like getting up to speed in C++. Those people, though, would probably be the best candidates for bringing those languages over.

#6

I think that is probably not a practical thing to change, but proper integration of other languages would be nice. D can integrate with C++ very well, the main quirk is that it does not support multiple inheritance. You can access C++ classes that do not use multiple inheritance quite easily from D, they just require a short wrapper declaration. I don’t know how common multiple inheritance is in Haiku code.

It does not provide the same guarantees of memory safety if you turn off bounds checking (but it has built in bounds checking). In my opinion it is much easier to parse, understand and write and the syntax is far more sane than C++ or Rust. There is a memory safe subset called SafeD that utilises a system where functions with an @safe annotation are bounds checked and cannot use unsafe features. Safe and unsafe code can be mixed, though @safe functions can call unsafe functions only if the unsafe function is marked @trusted, which indicates that the function can be trusted even though its safety cannot be proved.

There is also a subset called “Better C” which forbids accessing D features that are outside of the C runtime, which essentially means you don’t get the runtime performance implications of things like RTTI and garbage collection but still get a lot of nice high level language features.

Those two language subsets are very useful for writing systems and embedded code (though I’ve found the support for embedded development in terms of e.g. pre-compiled toolchains for MCUs is limited at present).

I have been really pleasantly surprised by D. Equally surprising is how little known and used it is. It seems the main thing it is missing is the momentum that would be created by a somewhat larger user base… it’s not unlike Haiku in that respect.

4 Likes
#7

I think this is an interesting topic to consider. I am very pedestrian in my coding, really only up to the occasional QMK keymap. Nonetheless it may be possible to look at this point what we would want from a different programming language, and pick one that suits:

I understand C++ has a ferocious reputation which will put many off. Whilst most of us know better than to place much stock in the more strident comments of IT influencers like Linus Torvalds, they nonetheless do wider harm to Haiku’s efforts to sell C++ as something the everyman or everywoman can learn. D was, according to Wikipedia, expressly designed to address that.

Writing an OS in C++ would have been fairly unique when Be was launched but now plenty of other operating systems are written in C++. It would be good to keep moving, and appraise the current state of the art.

Rust is becoming popular for other OS due to its perception of creating secure and fast software to reward a steep learning curve. That might work for them but Haiku, as an unashamed enthusiast OS, may do well to put more weight on a language easier to read and write than such “traditional” systems programming languages. This may especially help us attract novice coders who are less set in their ways.

“D”, or a language based on it, appears to have merit in all of these areas.

1 Like
#8

What do we do with the people on the team that only and exclusively know C++, like me? Do we retire them from the project? And what do we do with the existing codebase, 20+ years of code written in C++, do we throw it away? Rewrite it piece by piece?

If we were starting a new project, we could afford to ask the question of what language it should be written in. We don’t have this luxury right now, or at least, there is a lot to lose by deciding to switch to another language.

I have no problem with other languages being made available to write 3rd party apps in, but for Haiku main repository, I don’t think a switch to another language would be realistic. Of course, if a team of Rust enthusiasts think I’m wrong, they can create their own project to show that, and if it succeeds, very well, I don’t have to keep maintaining the OS and I can do more interesting things :slight_smile:

4 Likes
#9

Since we’re on the programming language kick, there’s a new one being worked on called Vale. Its “generational references” should address the uncacheability problems associated with reference counting. Rust and C++11 and newer are heavy users of reference counting. Maybe Vale is onto something. It’s still early in the design cycle. Any thoughts?

2 Likes
#10

I’ve pointed out TheseusOS before. It seems to simplify the operating system kernel design by using safe Rust in the place of memory protection.

It’s trying to make traction in the embedded space but running into trouble with drivers being written in unsafe C. The only way to import C into Theseus is using WebAssembly at the moment. At least that allows safety to inject managed code into the bytecode representations.

#11

That’s how Linux and Windows are adopting Rust code into their kernels, piece by piece. Firefox also is replacing unmanagable sections of C++ piece by piece using Rust.

The Servo browser was an attempt at reinventing the Firefox browser in Rust all at once. It failed because browser technology has grown needlessly complex and because Mozilla didn’t have the resources to pull it off. It is now part of the RedHat Linux ecosystem because Mozilla couldn’t afford to host it. Let this be a lesson in biting off more than we can chew when reinventing stuff.

C++ vs. Safe Code

The OOP model of programming is designed for modularity. Traditional object-oriented inheritance has been demonstrated to overuse dynamic dispatch and C++ has fallen into that trap. It is also non-trivial to devirtualize the use of dynamic dispatch in the compiler.

For this and other reasons, Rust uses a trait-based inheritance model instead of the traditional OO forms of single- and multiple-inheritance. This brings the cost of safety to paletteable measures but introduces less paletteable learning-curve problems with the rest of the language and framework of crates.

Conclusions

  • Rewriting everything from scratch is too expensive.
  • Shifting complexity from the compiler to the language is not always a bargain.
  • Safe languages do make debugging easier if implemented properly.
2 Likes
#12

The attraction of D as a language for use with haiku (in any capacity) is that it is quite easily compatible with C++ in both directions: It shares an ABI so simply links with C/C++ objects, and accessing D classes from C++ or C++ classes from D is quite straight-forward.

I don’t know if re-writing any of haiku itself into any other language really makes any sense but it would be nice to see some good bindings for other languages.

4 Likes
#13

As I understand it, writing software is not just a hobby for you, but a career, and so with that in mind I’d recommend learning some more languages. Of course I’m biased, but I think even the big C++ Proponents would agree that:

  • C++ is not always the right choice of language to solve a problem, but of course if you know only C++ what choice do you have ?

  • Other languages can give you a fresh perspective on how to solve problems, even if you end up applying that perspective to your C++ programs rather than using a new language.

As to what you should learn, that really depends, especially if you prefer to learn skills you’ll have an immediate use for or which would go on a CV or something. Incomplete, research or obsolete languages are probably bad second language choices because they tend to reinforce the idea that C++ is what really matters, so that rules out something like Zig, or WUFFS, or APL. These are fascinating languages, but without context their flaws seem to just mean you were right to choose C++. But whether you should learn say - Python, Rust, Typescript, C#, any or all of them seems like a reasonable choice to expand your horizons.

#14

I am not here to get career advice, especially misguided career advice that is based on one forum post on one of the many hobby projects I contribute to…

11 Likes
#15

Of course, there’s no reason you should take career advice from strangers, though I wouldn’t really think of this as “career advice” so much as just advice for anybody who has somehow gone many years knowing “only and exclusively” C++.

3 Likes
#16

The question remains if the code that exists and works should be rewritten in language X. (Insert your dream language here.) Anyone is free to do so. But I doubt anybody will.

#17

That makes sense imho. People can already do this, right? (Assuming you are right about the compatible ABI.) Shouldn’t do anyone harm

#18

I havent tried it, I think you would need to build a version of gcc with the D front end (gdc) and then away you go.

#19

And someone would have to produce D and C++ header files for every “module”. So maybe it is not as easy as it seems.

#20

Correct. The Phobos runtimes are documented here. Not to mention that many of the DUB packages may be system-specific.