Hacker News Reader

Comment by dschobel | Hacker News Reader

I think C models how the computer works a lot more closely than C++ (and no one would argue that C isn't carrying water out in the engineering world even today). IMO C++'s issue is precisely that it layers all of these leaky abstractions on top of the strict procedural model of C.

For my money, developers are better off knowing two tools (c + some very high level language) rather than the spork which is C++.

View on HN

I remember 'cfront', when it first came out, and to this day I haven't really changed my mind on how I felt about it, it's a much too bloated language compared to the elegance of C.

If 'C' would have had a decent native string type I think C++ might not have happened ;)

Are you suggesting that std::string, or as my not-so-friendly c++ compiler likes to call it

    std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*,
    const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>,
    _Alloc = std::allocator<char>]

is an improvement? :-)

No, not at all. I was thinking of strings the way Dennis Ritchie would have done it.

I can see why they chose to omit it, but in retrospect I think it was a mistake. The problem they were faced with was that the language didn't include any 'runtime' at all the way they wrote it, a string package would have made it a must to have some runtime.

Everything that is 'runtime' in C is in libraries, and everything that is 'core' is in the compiler.

That's not what your compiler calls the string class. That's what it calls one particular constructor of the string class.

This constructor lets you customize the way the string class allocates memory. Now I would like to see the equivalent constructor in your favorite language :)

c + lisp, in my case. nice way to write DSLs.

The sad part is that there are a few good ideas in C++, so it is hard to throw out the baby with the bathwater. I use C++ like C with destructors, operator overloading, typed constants, and not much else.

Thus proving the author's point.

But C with vector, string, hash_map, const&, destructors and scoped_ptr is a pretty good language! It's certainly better than plain C. It's just not as aesthetically pleasing that it sits inside the larger monstrosity that is C++.

Thus proving the authors point even further.

It is funny how everybody really seems to have their own favorite subset of C++.

Most users also probably have their own favorite subset of Word.

You've nailed it right on the head there though, when offered a bloated solution, people will 'subset', when offered something small and powerful people will customize.

You missed my point. Most users each probably have a different subset of Word.

No, I got it all right, that's what I meant. Each user subsets word for themselves in to what they need/can handle.

No, that's still not my point. Each user has a different subset of Word. Hence, the only set that contains all of the features that all users use is Word itself. If everyone uses a different subset, it's not accurate to call it bloated, too large, or complain it has unnecessary features. All features are necessary for someone.

A feature can be simultaneously "bloat" and "used by someone".

Just as Lisp programmers add new syntax and vocabulary to build custom languages, C++ programmers do the same by taking them away.

Does anyone really use all of Common Lisp?

I'd say the justification for all of the large languages (like C++ and Common Lisp) is the same. You may not need all of it, but the features you do need will at least be standardized, compared to using a small language with ad-hoc extensions to achieve the same.

[ I here include the standard library as part of the language, for languages with extensive meta-programming support like C++ and Common Lisp, it makes little sense to distinguish. ]

assembly more closely models how the computer works than anything...

Reply on news.ycombinator.com