I thought I was building a C replacement. I was wrong - C3 Programming Language
Initializing search
Language Overview<br>C to C3<br>Language Fundamentals<br>Language Common<br>Generic Programming<br>Build Your Project<br>Language Rules<br>Misc Advanced<br>Implementation Details<br>FAQ
Get Involved
Thank You
Single Page Docs<br>📖 Standard Library<br>Blog
I thought I was building a C replacement. I was wrong<br>I made a rather fundamental mistake when I started marketing C3.<br>I called it a C alternative.<br>That seemed completely obvious to me. I had been looking for a better C for years, I found C2 to contribute to, and from that C3 was eventually born. Of course C3 was a C alternative.<br>But I've gradually realized that the phrase "C alternative" means something very different today from what it meant to me.<br>And the reason is embarrassingly simple: I'm old enough to remember when C was an application language. So to understand what I got wrong, we have to go back to the 80s and 90s.<br>I started in BASIC, and for the longest time, assembly and BASIC were the main options. This was during the home computer "revolution" of the 80s. With the advent of 16-bit home computers, more languages suddenly became viable — mainly Pascal and C.<br>At that time, the most difficult thing was actually finding a compiler if you were young and had hardly any budget. I even ended up doing serious programming in QBasic of all things, simply because it was bundled with my install of DOS! And later I ... ehem ... "got hold" of a copy of Turbo Pascal...<br>My Pascal days were ultra productive. If I wanted to do something, it was just a matter of sitting down and writing it. Compared to writing things with labyrinthine BASIC goto/gosub, Pascal was super nice and easy to organize. This was easy without imposing structure or architecture up front – after all, it was procedural.<br>I did learn a smattering of C by getting hold of GCC, and later did some introductory C++ at university. And at this point, everything I wrote on my own was procedural in style. Then I had a summer course in Java. I think this might have been 1996 and the internet was all new.<br>And Java introduced OO as the core approach.<br>It was novel, it was interesting, and despite having written C++, I felt I hadn't really understood what OO was about until then. So that started my love affair with OO. Not that it was needed that much initially. Even getting a job in C++ later on gave me little room to do OO. But let's fast forward.<br>I ended up being exposed to Objective-C, and a job on Java game servers gave me a massive amount of practice writing Java quickly and well, but I still felt a nagging dissatisfaction. Because I never really got the raw development speed I had in my early days with Turbo Pascal, I was much better at programming, I was somehow slower – thinking much more about design than before for equivalent code. And this was something I didn't really reflect on that until I had a long-term contracting gig doing PHP.<br>The codebase was somewhat OO, but not overly so. And the interesting thing was that, at its core, it was basically:<br>"The user made a call, route it to running this function and present this result."
Even if bits and pieces inside were wrapped in OO classes, it was mostly procedural. And by god, development was ruthlessly efficient.<br>Step by step it dawned on me that the OO parts were superfluous: – the whole thing could have been C with an arena allocator + good dynamic arrays and strings. No OO needed.<br>And that got me thinking. Here it was: the development speed of Turbo Pascal, so why didn't OO give me that? I discovered an answer in OOPs requirement of up-front architecture.<br>In OOP, you need to think about architecture from the first — what objects own what objects, what objects know of what objects. And a big part of the "best practices" in OO, such as programming to interfaces, are really ways of trying to mitigate the problem if this deep coupling.<br>The methods are fundamentally linked to this problem. As soon as we write:<br>foo.do_something(bar)
we have created a hierarchy where the class of foo is more fundamental than bar.<br>In programming, we talk about exploring the problem space as we develop a program. As we gain a deeper understanding, we will usually restructure the program so that it more easily solves the problem.<br>The problem with OOP — or, if I may spread the net wider, "methods first" — is that the up-front architecture and the use of methods inhibit these changes. When we have placed B in A, reversing that relationship doesn't just mean moving the field: it also means rewriting all the methods that rely on it. This makes us reluctant to do such refactorings, which in turn means that bad decisions made up front tend to get locked in.<br>This is not just a problem for OO, but for anything that is "methods first" — that is, when you think:<br>game.run()
instead of:<br>run(&game)
The latter is procedural thinking. The former is "methods first".<br>As an aside, C3 has methods because they...