Dear Xbox and Playstation fans. It is cute when you fight, but before you think about trying to drag Nintendo into your pissing contest please take a moment to remember why Nintendo doesn’t even acknowledge you as their competition, much less their rivals.
ooooooooooooooOOOOOOOOHHHHHHHHHHHH
wwwoooooooooowww
hahaha ouch.
(that being said i have no idea where this information is from and if it is valid)
My language project is being dubbed K++. My first initial is K, and I like C++. So, K++ it is! We’ll see how long that lasts.
Classes and structs have different uses and technical meanings in different languages. Since C++ is the language I am seeking to improve upon, I will focus on its particular flavor of classes and structs. C introduced the struct, and it had no concept of private member variables. It was simply a way to group multiple variables together into a single block of memory. Along came C++, and suddenly, data could be locked down. By marking stuff private, the class can hide data details from the programmer and only expose a proper interface for handling the object as a whole.
In C++, classes and structs are identical. Classes default to private, and structs default to public, but those can be easily overridden. Both support constructors, destructors, operators, etc. So, for many C++ programs, a class is generally meant to indicate a black box data type with a carefully crafted public interface, and a struct is generally meant to indicate a white box data type serving as a dumb container for multiple variables. This is the only way to really keep both keywords useful.
I think C++ was onto something by having classes default to private variable access. It obviously wanted to encourage encapsulation, but it left the option open to have public data as needed too. However, as I have grown as a programmer, I have found that all my excuses for having public data have washed away. All my data is private 100% of the time. I do not even use protected member variables anymore. If I want to allow class extension, I still wrap the relevant data in properties (actual or otherwise depending on whether I’m working in C#).
So, my first executive decision for K++ is this: there will be no public, protected, or private keywords for (non-static) member variables. All class member variables shall be private. Conceptually, a class should commit to that black box approach. The programmer has to responsibly expose a proper interface. If that means building setters/getters for certain variables, so be it. I’ll be more than happy to supply simplified property syntax (similar to C#’s shorthand property syntax), but it still needs to be an explicit decision.
I’ve looked through C++, C#, and Java code at my job for examples, and I feel really good about this decision. I suspect there might be arguments made for allowing at least protected member variables, but I think the simplicity and consistence outweigh convenience in this case. The point is that any programmer should have 100% confidence in being able to alter the private implementation of a class. The instant you see a public or protected variable, you know it’s gonna be a long day refactoring as you track down where it’s being used.
So, where does that leave structs? I think structs should be the exact opposite: all member variables are all public all the time. A struct’s purpose is simply to tie a few variables together. I would rather not complicate the process on either side by exposing the temptation to developers to make data structures that are half private and half public. I have to present a strong philosophy in the language design, or people will just go back to C++ and never look back. I cannot try to be everything; I’ll simply lose the war to C.
On that note, why did we call it a struct anyway? I understand that C was invented a long time ago, but would it really kill us to put 3 more letters onto it? I think ‘structure’ looks so much nicer than ‘struct’. Ironically, for what it represents in K++, I’m not even sure I like that word at all. To me, a better term would be like ‘group’ or something. I haven’t hammered down this aspect yet. I’ll come back to it later.
The longer I work on my cross-platform game development framework, the more I just want to incorporate all my ideas into a new language. Particularly recently, I’ve had a flood of inspiration for this hypothetical new language. The temptation to work on this language is spiraling out of control the more I learn about LLVM.
As I started to spec out my ideas, I finally had to confront the question: am I seeking to replace C or C++? What problems am I really trying to solve? The longer I thought about it, the more I realized that I really have nothing to offer C. It grants absolute control over everything. All memory is completely malleable to the code. There are no wonky high level concepts like exceptions muckin’ up the works. If someone is working in C, they probably know what they are doing. C is heralded as a “systems language”, and based on my experience, I find that to be spot on.
C++ is the language that needs serious help. It introduced all these concepts/extensions/libraries to help developers be more productive in C, but in the end, it left them caught in the void between worlds. The really good C++ programmers generally sit in one of two camps. The first camp (where I live) creates engines. They generally program in highly efficient C and only dip into C++ features as necessary. (Things like templates are extremely powerful and do not hinder performance whatsoever.) The second camp embraces all of C++ and distances itself from C as much as possible. This camp uses high level objects and frameworks to reduce cognitive load. Developers here ban arrays and “naked pointers” in favor of safe wrappers and handlers.
The problem is that C++ is its own worst enemy. It is such a huge language that people have strongly varying perceptions of the language and its users. People in the C camp (like Linus Torvalds) end up hating how stupid C++ programmers are and just go back to C. People in the high level camp end up hating how unsafe the code is and migrate off to Java, C#, Python, etc.
Everyone loses. Everyone talks about C++ as the language they “have to use”. They are either maintaining legacy code or working with low level drivers. No one wants to author new systems in C++. It’s too much of a joke to write a kernel in, and it’s too dangerous to write a user application in. How do we fix this?
This is why I am working on a new language. I feel a proper balance can be struck between the two camps. As I said above, I have no interest in disturbing the C community. The language is simple and powerful and does not really need improvements. However, I really feel for the guys who pick up C++ to gain a few features but constantly have to dodge bullets from the high level camp telling them to abandon their quest to stay close to the metal. What a low level programmer craves is the ability to express themselves in a clear, concise manner without forfeiting speed. Meanwhile, the only reason any of the high level C++ programmers stick around is that speed. C# and Java are way easier to work in; obviously something about C++ kept them there.
The high level programmers demand a more sane standard library. STL is a joke. Benchmarks aside, C++ keywords and STL combine to make painfully cluttered code. cout? std? const? ptr? The API alone is more than half the reason I put up with C# at work. “Console.Write” is abundantly clearer than “cout «”. (Sadly, Java squandered this opportunity and made an equally disgusting library.)
I’ll go into more specifics in future posts. I hope this all made sense. I think the world is hungry for a language that compiles straight to machine code. There is no reason a low level language cannot be elegant and expressive. Oh, and it can be “safe” too.
