Hacker News Reader

Comment by morenoh149 | Hacker News Reader

the other discussion mentions D as a better C.

Anyone ever try to build "C the good parts"?

They did. Many times.

First they made "C the good parts" by gathering all the various C bits then in use to make something portable and called it C89.

Then they made "C the good parts" by removing all the parts that made C slow to write and called it Perl.

Then they made "C the good parts" by making C easier but still fast and called it Java.

In the meantime, we've gotten Objective-C and C++, which were attempts to make C better while preserving backwards compatibility. C++ has gone on to spawn its own legacy of "No actually, these are the good parts" with D, Clay, Rust, and various half-steps along the way that want some of the features of C++ but not all of the features of C++.

I don't think they'll stop, because as it turns out, people use tools for different reasons and it's very rare that a general purpose tool solves your very specific problem perfectly. I'm inherently skeptical of any "X the good parts" because the "good parts" are domain specific.

I agree. If you take the tool perspective, it is easy to understand that different tools are needed for different tasks. Don't use hammer for sawing. No single language scales to all corners of programming problems.

Actually I really don't get this endless "silver bullet" discussion. C has its place and for very good reasons. Also the author makes really good points about the integration aspects of C.

I read this thought quite often here on hacker news but it is a bit alien to me. To me the charm of programming is the ability to---at least in theory---write anything. This is also embodied in the idea of Turing completeness.

There is a continuum between the possibilities of a programming language and the possibilities of a configuration file. As soon as one says that a programming language is suitable for a particular purpose one has moved a few steps towards the configuration file end of this continuum.

This is, of course, a personal preference but I very much prefer to enjoy the power of programming language as opposed to the lack thereof of configuration files. Therefore, I like programming languages that attempt to be useful for any purpose. My favorite language is still C++ and if I were to switch to something else I would be inclined towards Rust.

A bit of rope is charming because you can build practically anything out of rope. For example, you can build skyscrapers out of bamboo and rope. But if you want that skyscraper to be useful, durable, safe, etc it may be better to use the rope for what rope is best at, and use other materials and tools for what they're best at.

Somehow I was expecting Lisp instead of C++ after all you've said. Any specific reason why you're not using Lisp?

Well, the ability to program anything includes the possibility to do tasks that require high performance. Also, I do like the fact that the compiler guards the type correctness of the program.

If your requirements are only high performance and improved type checking, then you are all set. The only language you need is C++. But the criteria above does not define all programming problems.

C++ is too complicated. "Nobody" writes C++, but a subset of it. Select your subset.

Dynamic typing in Lisp (and the like) is really nice for quick prototyping where program correctness is not key. You are exploring what you want to achieve with the program, be it algorithm level or architecture. C++ is not well suited for that, since type checking and memory worries are slowing you down, too many details to drag along. Hence no "silver bullet".

Sure, C++ is complicated. And the way templates are compiled is positively weird, which in turn sometimes leads to long compilation times. The 'select your subset' thing is often repeated, but I do not see much of that. I am a bit worried, though, that C++ seems to keep growing to the point where it really might get to big and complicated.

Quick prototyping is not something that I do. Nor am I very much interested in it. At my place of work I have seen it done around me after which it was my task to turn the python prototype into C++. The most surprising thing there was how far the prototype turned out to be from what was actually needed, to the point where I very much question whether the prototyping exercise was useful at all. YMMV regarding this, of course.

A python prototype is useful for specifying the correct program behavior. It's useful as a guide for later implementors. Better than a spec in a word document.

Being the language to write UNIX clones, that is all about it.

So by your definition the windows kernel is unix?

Compared to the architecture of an OS targeting, say, hardware with native capability handling, Windows and Unix are virtually indistinguishable. They're both just "that ugly bag of compromises you make to abstract over a register machine that can peek and poke at an unprotected address space, with the OS managing an MMU through CPU-interrupt-triggered context switches to enable a kind of multitasking where each task perceives itself as living on a single core and is unaware of being pre-empted unless it checks for it after the fact."

There are examples of OSes that don't work like that, despite targeting x86. For example, bare-metal Forth.

No, because Windows has plenty of C++ on it and Microsoft Security Team advocates using C#, Rust and constrained C++ (Core Guidelines) as the future of systems programming on Windows.

https://github.com/Microsoft/MSRC-Security-Research/blob/mas...

They are also very clear that C is done on Windows, and compatibility is only to the extent required by ISO C++ and a couple of key FOSS projects.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

UNIX is C's platform, there is hardly any reason to use it outside of non-UNIX OSes.

Plenty other languages offer system programming features, with better type safety and equal portability.

> Then they made "C the good parts" by making C easier but still fast and called it Java.

That one doesn't feel right. More like "figure out how to nudge the C++ crowd into the general direction of Smalltalk without them noticing".

Is java really smalltalk under the hood? Ruby certainly is. I always got the feeling that java was c++ with a bit more religion about OO, a well defined and platform independent standard library, and no multiple inheritance.

> I always got the feeling that java was c++ with a bit more religion about OO

No way. C++ was always much more into the functional programming paradigm. (See the STL, for example.)

The connection between C++ and OOP is because OOP was the insane hype at the time when C++ was being invented. The OOP lipservice was mandatory in order to be taken seriously by the fashion-driven programming industry, but real C++ programmers always looked down on OOP and considered it a code smell and crutch.

> The connection between C++ and OOP is because OOP was the insane hype at the time when C++ was being invented.

Not really, the C++ OOP features were directly modeled after very similar features in Simula. C++ was specifically designed as a way of bringing these sorts of features to C, although it did include other improvements to the language as well. Templates and the STL as we know it were a relatively late addition to the language.

It's also worth mentioning that there's only a handful of things about OOP that could be genuinely considered "a code smell"; in fact you could restrict that concern to one feature, viz. implementation inheritance. Object-based programming which follows the "composition over inheritance" guideline can still broadly tap into the improved-modularity benefits that 'objects' are generally known for.

> C++ was always much more into the functional programming paradigm. (See the STL, for example.)

Always? The STL was a last-minute addition to the standard library before C++98. Just a few years before, template implementations in compilers were buggy. There's a reason Qt has its own containers: because it's that old.

> The connection between C++ and OOP is because OOP was the insane hype at the time when C++ was being invented

No, it was because Bjarne wanted features from Simula whilst still generating fast code.

> real C++ programmers always looked down on OOP and considered it a code smell and crutch.

Absolutely not. Again, look at Qt. Look at CERN's ROOT. Java looks a lot like it does because that's how C++ code was written at the time. Even in the early 2000s I was getting funny looks from people when I told them to default to putting variables on the stack.

> The STL was a last-minute addition to the standard library before C++98.

C++ without a standard C++ library is not really C++.

> No, it was because Bjarne wanted features from Simula whilst still generating fast code.

Yeah, but Simula is somewhat its own thing, before the OOP madness.

> Again, look at Qt. Look at CERN's ROOT. Java looks a lot like it does because that's how C++ code was written at the time.

Only because C++ was the only thing available at the time, so people twisted it into 'OOP', despite the fact that C++ was very a poor fit for 'OOP'.

>> The STL was a last-minute addition to the standard library before C++98.

> C++ without a standard C++ library is not really C++.

You seem to be missing the point, which is that there was a time (two decades!) when the C++ standard library existed, but didn't include the STL.

> Only because C++ was the only thing available at the time, so people twisted it into 'OOP', despite the fact that C++ was very a poor fit for 'OOP'.

You are completely mistaken on your history here. C++ was intended to be "C with classes" from day one.

"OOP" is not "X with classes".

"Classes" is a low-level thing that you'd need for implementing many language features. Including things like 'abstract data types' of the ML kind.

Good C++ style has always viewed "OOP" as something highly suspect and hacky.

(This didn't apply to "classes" in the C++ vein, which are mostly about pre/post-conditions and RAII.)

Java is sneaky. It's a Smalltalk-y (ish) engine covered in a C++-y (ish) frontend language. This great talk (the first 20 minutes, really) describes how the original design was conceived: https://youtu.be/Dq2WQuWVrgQ

Is it really the case that calling a method in Java is the equivalent of passing a message under the hood? (I don't know how the VM is structured)

I am not sure how these two philosophical views differ, but the JVM is typed, so calling a non-existent method will result in an error when the class of the callee is loaded.

> It's a Smalltalk-y (ish) engine covered in a C++-y (ish) frontend language.

That sums it up quite well.

I'm skeptical about X the good parts, but hey "JavaScript the good parts" is really a thing in my experience.

I actually meant like a book like JavaScript: The Good Parts by Douglas Crockford. But thanks for your insight!

Reply on news.ycombinator.com