hypernova-developer & Programming Languages

Thoughts on Programming Languages: A Unverified Manifesto

WARNING: The following paragraphs contain my personal architectural opinions and insights that have no official peer-reviewed proof. Just pure engineering instinct.

For me, compiled languages will always hold the crown over interpreted ones. Why? Because the source code undergoes compilation and translates directly into the CPU’s native language: binary! It doesn’t require a slow intermediate translator to execute its commands, unlike Python. Python's interpreter has to read the code, analyze it, and translate it into binary on the fly. This process takes a massive amount of valuable execution time.

On that note, I cannot bring myself to call Java a true compiled language either. Java’s development environments consume an absurd amount of space on a developer’s disk. Furthermore, it doesn't even run directly on the bare metal machine; it relies on its own virtual layer called the JVM (Java Virtual Machine). Java's historical promise was to let developers "write once, run everywhere." While that promise didn't technically turn out to be a lie, actually running it is absolute misery. I would genuinely prefer using raw C and typing #ifdef _WIN32 to manually handle cross-platform compatibility for computers. I say "even C" because my sweet spot lies in low-level languages that still offer abstraction—which is exactly why C++ is my absolute favorite. Plus, I demand manual control over memory.

I do think C is becoming a bit of an old-fashioned language. Sir Linus Torvalds openly states that he loves old-fashioned languages, and that is his respected philosophy—but in my mind, C++ remains the undisputed ruler.

The JavaScript Paradigm & The Garbage Collectors

When the topic shifts to JavaScript, I enter a completely different emotional state: I hate JavaScript more than almost anything else in tech. Yet, JavaScript is everywhere. People use it for front-end, back-end, web architectures, SQL, servers, APIs, chatbots, multi-platform mobile apps, and so much more. You simply cannot expect peak performance from a language that tries to be everywhere instead of mastering one specific domain. Honestly, I think I even prefer Java over JavaScript.

TypeScript is undoubtedly better than JavaScript. It introduces a strongly-typed paradigm and features a far superior syntax. But in the end, TypeScript just compiles down to JavaScript anyway. That is the exact point where the loop closes, and everything goes right back to where we started.

As for Kotlin, I think it's just... too simple. It shouldn't be this simplified, in my opinion. Things get modified just for the sake of being "easy." Take the keyword fun for example; func was way better, cleaner, and vastly easier to understand conceptually.

On the other hand, C# is a pretty fine language—significantly better than Java, if you ask me. While both rely on Garbage Collectors, C# doesn't suffer from massive memory leaks. Additionally, C# feels incredibly similar to C and C++, meaning I don't feel like a foreigner when reading it. (Fun Fact: I actually learned C++ after messing with C#, but the structural truth remains identical.)

Paradigm Shifts: OOP vs Functional

Unless a specific task absolutely demands it, I never prefer Object-Oriented Programming (OOP). Functional programming is fundamentally better in my view. This is another major issue I have with Java: absolutely everything is forced to be part of a class. So, no thanks. Conversely, C doesn't even support classes, which is also a negative point in its own right. Don't get me wrong—I didn't say I've never programmed using OOP skills; I just don't prefer it by choice.

I don't deeply know Rust yet, but from what I see, it behaves like an overprotective parent. It refuses to let you do anything raw—especially that strict rustc compiler.

But I actually like Fortran. Its syntax is incredibly close to English—arguably easier than Python—and it compiles straight down to machine code.

The Next Phase: Project Oxygen (.o2) & Hydrogen (.h2)

My upcoming blueprints are focused on Oxygen and Hydrogen. Both will be fully realized programming languages. I have already spun up the codebase for Oxygen, though Hydrogen is still waiting on the launchpad.

Oxygen has a unique capability: it can natively read and interpret C++ header files. I am writing the core libraries for Oxygen in C++, which grants it an elite feature: backward compatibility. Developers will be able to invoke cpp:: and type direct C++ commands inline. This is a game-changer for utilizing crucial functions that aren't natively implemented in Oxygen yet. Right from day one, developers can smoothly migrate and use it.

Architecture-wise, Oxygen will utilize a transpiler. It will translate Oxygen code directly into optimized C++ source code. The core transpiler engine, oxy, is being developed by me entirely in C++. My ultimate dream? To watch Oxygen seize the crown directly from Rust.

Meanwhile, Hydrogen is engineered to take the crown from TypeScript. Hydrogen will not be transpiled; it will be directly interpreted by a custom engine named hydro. To support this, I will release a dedicated Chrome extension on my GitHub. It will enable users to seamlessly execute websites that choose Hydrogen as their preferred scripting language.

• Oxygen files will sport the .o2 extension.
• Hydrogen files will use the .h2 extension.
• Their header files will be represented by the .h2o extension.

Fascinatingly, both languages will share the exact same file extension for their headers. The compiler will determine the target language by reading the very first line command: #target OXYGEN/HYDROGEN/ALL. Furthermore, in both ecosystems, lines starting with # will not represent standard preprocessor directives—they will be active compiler commands.

---

Check Out My Repositories You can follow my source codes, libraries, and daily commits on my GitHub Profile.

---

[SYS_LOG]: This log entry is concluded here. Thanks for stepping into the frequency. You can drop your unverified thoughts or optimization suggestions in the comment section below. Feel free to interact. See you in the next execution cycle!