Is C++ a 'Really Terrible Language'? (gamesindustry.biz)

Long-time Slashdot reader slack_justyb writes, "Jonathan Blow, an independent video game developer, indicated to gamesindustry.biz that while working on a recent project he stopped and considered how miserable programming can be. After some reflection Blow came to the realization as to why. [C++ is a] 'really terrible, terrible language.'"

The main flaw with C++, in Blow's opinion, is that it's a fiendishly complex and layered ecosystem that has becoming increasingly convoluted in its effort to solve different problems; the more layers, the higher the stack, the more wobbly it becomes, and the harder it is to understand.
"Blow is the developer of two games so far -- Braid and The Witness -- and developed a new programming language known as Jai in hopes to help C++ game developers become more productive."

With Jai, Blow hopes to achieve three things: improve the quality of life for the programmer because "we shouldn't be miserable like many of us are"; simplify the systems; and increase expressive power by allowing programmers to build a large amount of functionality with a small amount of code.

Long-time Slashdot reader xx_chris calls C++ "the triumph of syntax over clarity," while in the interview Blow calls C++ 'a weird mess.' But the original submission ends with these questions. "Is Blow correct? Has C++ become a horrific mess that we should ultimately relegate to the bins of COBOL and Pascal? Are there redeeming qualities of C++ that justify the tangle it has become?

"And is Jai a solution or just yet another programming language?"

Comments

Yes

[Anonymous Coward]

Yeap.

Re:Yes

[Joce640k]

Nope.

People who don't understand C++ are doomed to recreate it, badly.

Re: Yes

[jean-guy69]

There are a lot of existing languages usable for gaming, why create a new one? Some even can be translated to C++ or javascript, like Haxe, already used succesfully for some commercial videogames..

Re:Yes

[Anonymous Coward]

I use lots of C++. I also ignore major portions of it. I do not need all of it. There is nothing saying you have to use every bit of it. It is good to know all the bits though and understand how the tool can help you get things done. Take for example Visual Basic 6. Not exactly a 'bad' language. But it sure let lots of bad things to be created. That is because it was an easy lang to pick up and make a mess of. Being good at what you do takes time. There are no shortcuts. Blaming C++ is kind of a fad. Because like all languages terrible things can be done in it. It will not stop you from doing that. It expresses what you want. If you are not good at what you do you will express bad things. I have seen monsters made in pretty much every language at this point. None of them are 'good' at stopping you from making crap code.

Re:Yes

[dyfet]

Hence, go

Re:Yes

[Narcocide]

Doesn't happen much, but this time I'm going to have to agree with Anonymous Coward. All that will be accomplished by making programming languages easier is fostering the proliferation of even less qualified jackasses flooding the market with dangerously insecure and buggy code.

Re:Yes

[Joce640k]

Yes. Even Bjarne said (something like): "Inside C++ is a smaller, cleaner language trying to get out".

The trick is to learn what to use and what not to use.

The main problems C++ has are:
a) It's hard to learn C++ by hacking away at it. Some things are counter-intuitive, a good C++ mentor can save you years.
b) It's not a platform. Casual programmers don't want a "language", they want a platform.

The bottom line is this though: C++ allows you to precisely express anything you want to do. You never hit a brick wall like you do in other languages.

Also: Garbage collection is a red herring. Nobody manages RAM in C++ because C++ understands RAII like no other language. All the garbage collected languages handle RAM OK but RAM is only one type of resource. You end up explicitly closing files, etc., when you finish with them. In practice, GC actually creates more work for you compared to C++.

Re: Yes

[phantomfive]

Yeah, Bjarne is right, but there is no agreement at all abOut which features should be used and not. Result is, if you work with a lot of people on a large project, you have to know it all. Except friend. No one uses that.

Re:Yes

[Joce640k]

The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained. Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.

- Bjarne S.

Re:Yes

[blackpaw]

Yes and no, I agree you can do clean, lean good code in C++, but its when you try to avoid reinventing the wheel by pulling in 3rd party libraries that it all goes wrong. Or even the std ones for that matter - the string template library is a classic example, a monster of templates and polymorphism gone insane. If I have to pull out the docs to remember how to convert a string to lowercase, there's a problem.

Re:Yes

[MichaelSmith]

There is nothing saying you have to use every bit of it.

Other than the guy you inherited the codebase from.

Re: Yes

[Joce640k]

Each job requires a slightly different subset, yes.

There's not much you could take out of C++ without harming it in some way, every feature is needed in some circumstance or other.

The only completely useless feature I con think of is C++ arrays - new[] and delete[] don't do anything that can't be done much better with std::vector.

(nb. Arrays were added before templates so that's why they're there)

There's also a bunch of small tweaks that could make it better, eg. require {} on all code blocks.

Re:Yes

[jellomizer]

C/C++ isn’t horrible especially with its more modern versions.
That said it isn’t the best language for a lot of needs.
My work I need to make a lot of small apps developed quickly. The C language including C, C++, Java, C# often require a lot of overhead for many of the small get it done jobs.
However if it a bigger development project where speed, and lower level access is needed as well needing a bigger development staff it becomes more useful over the scripting language like Python.

Re: Yes

[Anonymous Coward]

I'm convinced that you could design a language about a tenth of the size of C++ (whichever way you measure size) providing roughly what C++ does.

- Bjarne S.

Re:Yes

[Anonymous Coward]

Blaming C++ is kind of a fad. Because like all languages terrible things can be done in it. It will not stop you from doing that. It expresses what you want. If you are not good at what you do you will express bad things. I have seen monsters made in pretty much every language at this point. None of them are 'good' at stopping you from making crap code.

Adobe Photoshop or Gimp
Microsoft Office or Open Office
Windows, OSX or Linux
Chrome, Firefox or Internet Explorer

Closed source or open source, every major operating system, every major application, all written in C/C++

That tells you everything you need to know about how "terrible" C++ is.

Re:Yes

[K. S. Kyosuke]

Then why don't you make people program in Common Lisp? Not only do you get even higher expressiveness and power but you still get to keep undereducated people out.

Re:Yes

[K. S. Kyosuke]

All the garbage collected languages handle RAM OK but RAM is only one type of resource. You end up explicitly closing files, etc., when you finish with them.

...say people who never heard of unwind-protect.

Re:Yes

[K. S. Kyosuke]

I think that's a very flawed argument. You have no control group in the form of another universe where C++ didn't gain the same popularity and the same programs were developed in an alternative language. Only then could you assess whether C++ helped you write those programs or whether it hindered you. Just because network effects, for better or worse, made most people use it in our world says little of its technical merits.

Re:Yes

[Narcocide]

Try actually signing up for a Lisp class and you'll find out exactly why.

Re: Yes

[mikael]

I would believe that. There's about two dozen ways to iterate through an STL vector class; by integer index, by iterator begin/end, by auto iterator by value, by auto iterator by reference, these can be done backwards from end to start as well. Another combination is whether to pre-increment or post-increment. But only one method will actually be the fastest on any platform. Then you could use pthreads to parallelize things or maybe Intel TBB blocks. Depending on whether you are working with vector data, then the Intel/AMD AVX/AVX-256 and AVX-512 are another option.

In many companies, they would split this into multiple tasks. Get something simple working. Get someone else to investigate how to optimize the single core version. Now get someone else to investigate multi-threading. Then get the AVX optimization expert to have a go.

There are Youtube videos where the developers have managed to write a C++ compiler to generate 8-bit 6502 code. Just by using the const keyboard they could make a kilobyte of data and code just disappear.

Re: Yes

[Anonymous Brave Guy]

new[] and delete[] don't do anything that can't be done much better with std::vector.

Well, they can be used to implement std::vector.

Re: Yes

[Anonymous Coward]

>C# is no use and they're making a new version of it with no garbage collection or dynamic stuff.

Also known as unsafe mode in C#. You can instantiate unmanaged objects, use pointers, etc and do the heap yourself.

Re:Yes

[0100010001010011]

C++, compiled Perl.

Re:Yes

[K. S. Kyosuke]

Why would I sign up for a Lisp class? The Gigamonkeys book should be enough for everyone. Well, perhaps with On Lisp and the recent public release of PAIP.

Re:Yes

[careysub]

I hope you get modded way up! This is the fallacy of the "but only use a subset and you are good".

Real world programmers must maintain and modify code bases that have been written by people that no one currently at the company even knows.

Re:Yes

[Anonymous Brave Guy]

I have seen monsters made in pretty much every language at this point. None of them are 'good' at stopping you from making crap code.

Perhaps, but some of them are still better than others.

For example, there is no reason a language designed today would want nullable-by-default indirection, or a weird inside-to-out convention for writing types. C++ has these things due to a combination of historical accidents and such a strong need for backward compatibility that mistakes on that level are almost impossible to fix later.

There are plenty of other aspects of C++ that are at least debatable as well, including things as fundamental as its model of OOP, its limited type system, and the repeated attempts over the years to bolt on support for functional programming idioms that never quite hit the mark.

Re:Yes

[sjames]

That's fine if you're always writing your own software from scratch, but it's a whole different world when you inherit someone else's mess. That's where you start to curse the ability to redefine the world around a 'clever' function or two.

Re: Yes

[Dixie_Flatline]

Because the principle conceit of C++ is that you shouldnâ(TM)t pay for anything you donâ(TM)t use, you wind up with a language that has very little worth paying for.

Re:Yes

[dfghjk]

The discussion is moot when it involves inherited codebases. You are compelled to use the tools already selected whether you like them or not.

Re: Yes

[As_I_Please]

There are Youtube videos where the developers have managed to write a C++ compiler to generate 8-bit 6502 code. Just by using the const keyboard they could make a kilobyte of data and code just disappear.

Namely, "Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17"

timestamp 24:15 for setup for the const trick; 28:00 for punchline

Re:Yes

[fafalone]

That quote ignores a whole range of useful tasks people with a little training can do in those fields though. You don't need a plumber when it's just a plunge job; you don't need an accountant to do your taxes if they're simple. There's a whole spectrum of levels of knowledge, and general tools should be mostly accessible to those that know the basics. It's also a terrible idea to put barriers in against increasing your knowledge level.
Visual Basic, before .NET, was an excellent example of this. I'm by no means someone who could write an AAA game or contribute to the Linux kernel, but I've created quite a few useful utilities in VB. From the very simple, then as I got better over the years, all the way up to very complex utilities with multithreading, inline assembly, and the latest Windows APIs for line of business use. There's still nothing I've found that provides the simplicity to jump right in with the power to grow to professional level (nor create a Win32 GUI so quickly). That whole paragraph just reeks of elitism; programming isn't some inherently dangerous activity that only those who get special schooling should be able to approach it. It's like any other home utility concerning the workings of our everyday possessions.

Re:Yes

[geoskd]

Perhaps, but some of them are still better than others.

And some of them actively prevent you from writing good code.

Maintainability, while important, isn't the only measure of quality code. Performance is equally important and often overlooked. (I'm giving you the evil eye Java)

Re:Yes

[SoftwareArtist]

Inside C++ is a small(er), clean(er) language trying to get out, but it's still neither a small nor a clean language. It's still a verbose, inconsistent, badly designed language.

Why do you need to separately declare and then define every piece of your API? Because that's how C worked, and C did it that way because of the limitations of compilers in 1977. It's totally unnecessary in a modern language, and it makes your code way less clean. But that's how C++ works.

Why are templates designed in a way that makes you put the entire implementation in the header file? That was totally unnecessary, and it leads to clunky code. But that's how C++ works.

How come if a parent class doesn't mark its destructor as virtual, all subclasses will (silently) fail to get cleaned up correctly? This is just bad design. It's probably caused countless bugs over the years.

The language is full of inconsistencies because no one ever bothered to fix them. Why is "this" a pointer instead of a reference? Why does exception.what() return a char* instead of a string&? There are tons of minor points like this that could easily have been better if someone had bothered to think about consistency. But no one did.

You can avoid the worst parts of C++, but what remains is still a poor substitute for a well designed language.

Re:Yes

[nuntius]

UNWIND-PROTECT is very useful, but it is lexically scoped. Objects that need any protection require two entries, one at the allocation/initialization and one in the protection clause. This can be a source of errors (missing protection for a resource allocation) and a major pain with some macro environments. Objects with dynamic extent require careful tracking, just like manual memory management. Languages with automatic garbage collection have found it is extremely hard / costly to guarantee cleanup semantics, exacerbating the situation.

With RAII, C++'s support for dynamic resource extent really is much better. Stack-allocated objects run their destructors on scope exit, much like an implicit, low-cost unwind-protect. The destructor is a convenient place to update unwind semantics at all call sites... Smart pointers (shared, weak, unique, etc.) make it easy to add dynamic tracking discipline to many common data structures.

Rust is one of the few languages that may have an even better story for resource ownership.

Re:Yes

[phantomfive]

Most of those programs he mentioned are written in C++ because that was the language chose by Microsoft at the time. You had no choice. If Apple had become the primary platform, they probably would have been written in Pascal instead. Just like today frontend web code is written in Javascript. Not by choice.

Re:Yes

[S.Gleissner]

Why do you need to separately declare and then define every piece of your API? Because that's how C worked, and C did it that way because of the limitations of compilers in 1977. It's totally unnecessary in a modern language, and it makes your code way less clean. But that's how C++ works.

You don't have to. You can define all your code inside of the class, like in Java. It's up to the compiler/linker to store that mess somewhere. But for non-template code, it's more efficient (speed and memory) to have this separated, for both compiling and linking.

Why are templates designed in a way that makes you put the entire implementation in the header file? That was totally unnecessary, and it leads to clunky code. But that's how C++ works.

Because the compiling of the template is totally depending of the template arguments. Last time I've looked into Java, there were no templates (or even variadic templates), so this is really not comparable.

How come if a parent class doesn't mark its destructor as virtual, all subclasses will (silently) fail to get cleaned up correctly? This is just bad design. It's probably caused countless bugs over the years.

Only if the subclasses have virtual functions, then you should also make the destructor virtual. There are good reasons to have non-virtual destructors in parent classes. Why should I pay for a feature, if I don't need it? Here static code analysis helps.

The language is full of inconsistencies because no one ever bothered to fix them. Why is "this" a pointer instead of a reference?

Is this really an inconsitency? For me, pointers are no problem, they are an additional grade of freedom for expressing what I want. Yes, references are internally only pointers with the same speed and they normally don't have the value 0 (as long as you did not mess them up), but last is also true for 'this'. So it really doesn't matter.

Why does exception.what() return a char* instead of a string&?

Good question, but nearly irrelevant in well designed programs, that try to avoid exceptions during normal program flow. However, if you want to concatenate constant strings at compile time to get better error messages, there are tricks with variadic templates. With gcc, this even works with __PRETTY_FUNCTION__.

There are tons of minor points like this that could easily have been better if someone had bothered to think about consistency. But no one did. You can avoid the worst parts of C++, but what remains is still a poor substitute for a well designed language.

Perhaps. This language is for professionals. It is huge and there are pitfalls. But it gives you the neccessary freedom to express *exactly* what you want. C had been designed as a shortcut for Assembler and this is still true for C++; there is no virtual machine in between. If you write business applications, well, then use something else, but I do embedded development in the automotive sector and here C++ is exactly what I want.

Re:Yes

[Carewolf]

There is nothing saying you have to use every bit of it.

Other than the guy you inherited the codebase from.

Nah, he was only using the parts he knew, or thought he knew. Unless you are inheriting it from Google, then they USE EVERYTHING for no good reason, except exceptions, but they are the exceptions after all.

Re:Yes

[MichaelSmith]

I thought he was padding his resume to get a better job.

Re:Yes

[goose-incarnated]

I use lots of C++. I also ignore major portions of it. I do not need all of it. There is nothing saying you have to use every bit of it.

Sounds like you work solo. Most projects are teams. The problem with C++ is that includes all the pitfalls of C, and then adds a few dozen more of its own.

Some of the stuff in C++ that is fairly horrible has been there forever (i.e. not recently added). For example our code review recently missed a bug in snippet that basically had a "errorcode = function (value);" because value was passed by reference. At the point of the call there is no indication that function can change the value. Had this been written in C the call "errorcode = function (&value);" would have been a clear giveaway.

All these tiny fuckups mean that most C++ experts are great at reading code that they wrote, but not so great at reading code someone else wrote. Not to mention that almost no one knows the entire language anyway.

Re:Yes

[goose-incarnated]

Yes. Even Bjarne said (something like): "Inside C++ is a smaller, cleaner language trying to get out".

The trick is to learn what to use and what not to use.

Unless you're working solo on a tiny codebase, or one that is only a few years old, you can't use that "trick". The number of business that satisfy those criteria is vanishingly small.

Re:Yes

[boa]

We need a reasonably coherent language that can be used by âoeordinary programmersâ whose main concern is to ship great applications on time.

-- Bjarne S, Remember the Vasa (2018)

Re:Yes

[Anonymous Coward]

Not only do you get even higher expressiveness and power but you still get to keep undereducated people out.

OK about the first, not sure about the second. Because of its simple syntax, lisp is much easier to pick up than some similar languages (eg. javascript) with a lot a syntax tricks and traps. Something "obvious" like operator precedence is much more of a show stopper for the really "undereducated" than understanding scopes, closures and continuations. That's the problem with elitism -- you're wrongly assuming that eg. java trained monkeys are undereducated; they're actually OVEReducated -- every java programmer have to juggle with a lot of abstruse and useless OOP concepts that were cool 30 years ago; and it takes a lot of time and dedication to master that garbage.

But Lisp will never be an alternative to C++ because the hardware is geared towards the C model of a vm -- just to get the basics of Lisp/Scheme up you have to do some heavy lifting and pay a big price for things like garbage collection; is there some lightweight way to implement spaghetti stack & continuations on current hardware?

Re:Yes

[K. S. Kyosuke]

UNWIND-PROTECT is very useful, but it is lexically scoped. Objects that need any protection require two entries, one at the allocation/initialization and one in the protection clause. This can be a source of errors (missing protection for a resource allocation) and a major pain with some macro environments.

Could you elaborate on that? Perhaps with some more specific example.

Stack-allocated objects run their destructors on scope exit, much like an implicit, low-cost unwind-protect.

I'm not quite sure that unwind-protect is high cost, at least comparatively to your destructors. Aren't the principles of implementation the same? You need to cover both regular and exceptional exits in both languages, so I'm not sure there's a completely free lunch for C++ there.

The destructor is a convenient place to update unwind semantics at all call sites

So is a macro definition, though.

Re:Yes

[goose-incarnated]

Some of the stuff in C++ that is fairly horrible has been there forever (i.e. not recently added). For example our code review recently missed a bug in snippet that basically had a "errorcode = function (value);" because value was passed by reference. At the point of the call there is no indication that function can change the value.

const qualifier exists specifically to avoid exactly these types of problems. Why not use it instead of guessing?

Maybe because the reviewers didn't write the code, and the diff doesn't automatically show what the function declarations were in the header that wasn't modified. The local variable "value" wasn't declared const because it was changed in the local scope.

Had this been written in C the call "errorcode = function (&value);" would have been a clear giveaway.

Unless value was a pointer then it too would be function(value)

Except that then you could see that it was a pointer just by looking at the local scope. The way it was meant that the library headers had to be examined to check whether function() was capable of changing value or not.

It appears you don't know what you are talking about. Sorry.

Re: Yes

[Joce640k]

new[] and delete[] don't do anything that can't be done much better with std::vector.

Well, they can be used to implement std::vector.

So can malloc().

Re: Yes

[Joce640k]

I would believe that. There's about two dozen ways to iterate through an STL vector class; by integer index, by iterator begin/end, by auto iterator by value, by auto iterator by reference, these can be done backwards from end to start as well. Another combination is whether to pre-increment or post-increment

Yes, but these days we just type:

for (auto& i: mycontainer) {
}

And a lot of things you mention weren't ever supposed to be used for iterating. eg. Integer index is there for random access, not iterating. Integer index can't be removed from the language but if you use it for iterating then you're doing it wrong.

Re:Yes

[Anonymous Brave Guy]

I take your point, but I don't entirely agree with it. I think whether performance or maintainability matters more depends a lot on context. Both are valuable attributes, but both can reach a level that is good enough to get the job done, and improving them beyond that point offers a much lower return. Where that point is depends a great deal on both what you're doing now and what you might want to do later.

In any case, the days when writing in C or C++ was an effective guarantee of very good performance are behind us. With modern hardware designs, the only way to guarantee making the most of available CPU and other hardware resources is to drop to assembly level or the equivalent. Otherwise it's still a question of how good your compiler or VM is, and while C or C++ being "closer to the hardware" can offer some advantages there, their programming models also prevent some optimisations that might be valid because, for example they aren't safe due to aliasing possibilities.

Re:Yes

[Joce640k]

You need someone that can slap a contact form on a site without breaking anything else or creating a gaping security problem.

It only took you four lines of rant to implode your own argument.

Re: Yes

[PacoSuarez]

Iterating with indices is sometimes very useful. For instance you can do something different for the first element (if (index==0)...) or you may want to push new elements at the end of the vector as you go (which invalidates iterators).

Re: Yes

[serviscope_minor]

Yeah, Bjarne is right, but there is no agreement at all abOut which features should be used and not.

That's because anyone who has blanket rules about "don't use X" is, frankly, silly.

The point is to use the features where appropriate. Some features very rarely used because there are rarely appropriate times, but when those times happens, there's no substitute.

This is just like any tooling. I've seen ignorant and enthusiastic people try to do very stupid things on power tools because the power tools were there. I wouldn't propose either banning either circular saws or hobbling them so they can always be used safely where one might use tennon saw instead.

Not only that, but there are also some rarely used, expert only tools kicking aronud any good workshop. For some reason this ispires people to neither use them for absolutely everything nor get rid of them.

Re:Yes

[Anonymous Brave Guy]

It is certainly true that being on the ISO committee for a programming language standard doesn't necessarily make you an expert in all the ways that language is used. I once had a very frustrating discussion with a prominent member of one such committee, who stubbornly insisted that discussions about organising deeply nested loops were moot because no-one should ever need more than a level or two of nesting in good code anyway.

I asked how familiar he was with the subgraph isomorphism problem (finding subgraphs of a certain shape within a larger graph) and he didn't seem to have come across it. The thing is, that problem is provably NP-complete (that is, computationally extremely expensive to solve in the general case) and so in practice you might well approach it heuristically, building a deep set of nested loops and guard conditions.

I think a lot of programmers and a lot of people working on programming languages think of something like, say, quicksort as being a relatively complicated algorithm. By introductory textbook standards, maybe it is. However, when you're talking about programming languages used by millions of developers for numerous different applications, there are plenty of people trying to implement much more complicated algorithms. Different aspects of language design can become relevant at that scale even if they don't make much difference when you're implementing basic data structures and algorithms, but if no-one on the committee has any relevant experience, they don't even know what they don't know.

Re: Yes

[Anonymous Brave Guy]

Which returns a pointer that is only useful when interpreted as pointing to an array...

Re:Yes

[serviscope_minor]

because no one ever bothered to fix them.

That's because real engineers understand about compromise. Stroustrup could have made the cleanest most beautifully designed language and like everyone else who has done the same no one would have used it.

It's not a question of "not bothering"---that's just outright arrogance on your part---it's that breaking everyone's code regularly in pursuit of perfection will more or less guarantee at best a fragmented language and at worse an unused one.

Re: Yes

[serviscope_minor]

Yet it's mysteriously the language used for implementing an awful lot of the world's infrastructure.

The entertaining thing is even those who tout C are now reliant on C++ because it turns out that the problem of writing a quality optimising compiler is basically too hard to do in C and so all of the major compilers are now written in C++.

Re: Yes

[phantomfive]

So, you have to learn all of c++, which is a huge deterrent to new people picking up the language.

Re: Yes

[serviscope_minor]

So, you have to learn all of c++, which is a huge deterrent to new people picking up the language.

If you want to be able to do everything then you need to learn everything. Not very surprising, really.

A half way decent codebase won't have every feature occur in every source file, leaving plenty of room for junior devs. Frankly if it does you should polish your resume ASAP).

Re:Yes

[serviscope_minor]

Unless you're working solo on a tiny codebase, or one that is only a few years old, you can't use that "trick".

That's because it's a dumbass trick. The "trick" is to know what to use when, i.e. the trick is to have good taste. But that's the universal trick for all languages for not writing crap code.

Re:Yes

[q_e_t]

Yes. Even Bjarne said (something like): "Inside C++ is a smaller, cleaner language trying to get out".

Probably all the good bits of C++11 and later, without the legacy.

Re: Yes

[phantomfive]

Or just choose a different language. That's probably reasonable.

Re: Yes

[serviscope_minor]

Yep that's save you from having to learn the things you just can't do in whatever language you just choose.

Re:Yes

[Phylter]

I agree. I've programmed professionally in many languages professionally and I've seen bad code in them all, even Python. With much power comes much responsibility and in many languages the programmer is given a lot of power to hang himself. VB.net is a perfect example in this case. With the right options (strict and explicit) turned on the language actually becomes pretty good and will enforce a lot of rules that will keep the code readable. I started my current job with the understanding that most of the work would be in C# but some legacy VB apps did exist and would need to be maintained. I think I spend more time in VB.net than any other language now. The code I maintain starts out horrible but as soon as I turn those options on and fix the code to match modern patterns it's actually pretty nice.

Re:Yes

[thegarbz]

We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training.

Funny you should say that. Architecture is not what many people would consider a skilled job at all. Civil engineers spend a good portion of their lives telling architects that their silly ideas won't work.

Re:Yes

[SoftwareArtist]

It's not a question of "not bothering"---that's just outright arrogance on your part---it's that breaking everyone's code regularly in pursuit of perfection will more or less guarantee at best a fragmented language and at worse an unused one.

That's why you need to fix these problems while you're designing the language. For C++, the window of opportunity for fixing them was between 1979, when Stroustrup first started working on it, and 1985, when the first edition of the language spec was published. Once a language has been standardized you're stuck with its flaws. C++ is decades past the point where its flaws are fixable. But that doesn't make the flaws any less egregious.

Re:Yes

[thegarbz]

Why are templates designed in a way that makes you put the entire implementation in the header file?

Oh is that a thing? I am nothing more than a casual hacker at the language, more of a C person. The other day I saw my first template and was confused that the header seemed to do the heavy lifting.

I'm always amazed at the things I learn on Slashdot.

Re: Yes

[Zero__Kelvin]

No, it can't.

Re: Yes

[Colourspace]

Slightly related, reminded me that someone recently wrote a version of Snake in Z80 using LD instructions exclusively!

Re:Yes

[TetsuwanPenguin]

If you try hard enough, you can write convoluted, impossible to understand code that will compile and almost do what you wanted it to do, in ANY language, it's just easier to do in C++. As a basic object oriented language with light weight low level support, C++ is actually not bad. Some of the STD Lib stuff written for it is actually useful. But I will admit that I rarely use even HALF of the language and Libraries power. "for with great power comes great responsibility"

Re:Yes

[Spazmania]

If you use all its features, C++ is an atrocity. If you treat it as C plus objects and stay away from operator overloading, stick with char arrays instead of strings, etc. then it's really just modernized C with all the benefits and pitfalls thereof.

Re: Yes

[Miamicanes]

Bad example. An architect who designs mostly single-family homes, strip malls, and chain restaurants isn't going to design megastructures like the Burj Khalifa, EVEN IF the buildings they design are visually-spectacular works of art that are perfectly-tailored to their intended uses.

Ditto, for a thoroughly-competent & thorough (but mostly un-creative) structural engineer... you might sleep better at night knowing that he or she designed the bridge you could be driving on when an earthquake strikes, but a skyscraper designed by him or her would be pretty bland.

The buildings that combine both size and design come from the elite few who've mostly-mastered one realm, while becoming acceptably-competent in the other. Artistic vision in the architectural realm means little if it can't translate into something that can actually BE constructed, but buildings designed by ARTISANS (vs artists) end up being... well... mere steel-framed glass boxes, like most "modernist" skyscrapers. Modernists were artisans, not artists. They built what was technically-possible, and sprinkled on some frosting as an afterthought to make them look less bland (or proclaimed their very bland-ness as an artistic virtue).

The era between beaux-arts & postmodernism was when architects slowly began to broaden their knowledge into areas formerly of interest only to structural engineers.

Brutalism was their first baby steps, where they leveraged their knowledge about the stone-construction techniques of antiquity and extended it with knowledge about reinforced concrete to design structures that were big, but still tried to have artistic merit & express good design.

Today's postmodern skyscrapers are simply the next logical step... having reconciled stone-masonry of antiquities with reinforced-concrete engineering, they kept pushing the limits until they learned how to build skyscrapers with exteriors that were (or at least resembled) more aesthetically-pleasing materials... stone, brick, textured concrete, glass, and combinations of all four (though generally NOT wood... at least, not as an exterior or structural element).

"Brutalism" was a rebellion by architect-artists against uninspired blah modernism designed by committees of artisans. It didn't die... it just evolved into postmodernism as architects became increasingly competent at applying the principles of modern structural engineering to the aesthetics of creative artistry & saved us from BOTH bland, uninspired glass boxes AND hulking masses of gray concrete. Today, thanks to the increased fusion of those two domains, we get to have our cake & eat it too... inspired artistic vision that pushes the limits of building construction and expands the range of possibilities.

TL/DR: narrowly-competent artisans have their place, but multitalented renaissance men/women are what really move us forward.

Re:Yes

[careysub]

All codebases become inherited codebases if they remain in use.

Re:Yes

[angel'o'sphere]

The destructor is a convenient place to update unwind semantics at all call sites

So is a macro definition, though.
How does a Macro that you use at entry point of a function know that it need to do something when the function either returns or is rolled back by an exception?

Re:Yes

[Man On Pink Corner]

Why should I pay for a feature, if I don't need it

Because you won't know if you need it until much later, and it will be too late then.

Here static code analysis helps.

See above. In a language with a sane object model, inheritance (and reuse in general) doesn't require access to the source code.

Re:Yes

[angel'o'sphere]

The biggest mistakes of Java and C# are that they favoured generics over templates.

No idea why other people think otherwise. Template specialization, template meta programming: all not possible with generics.

Re:Yes

[angel'o'sphere]

If you treat it as C plus objects and stay away from operator overloading, stick with char arrays instead of strings, etc.
If you do that, you are an idiot. Or you lack an ANSI C compiler, which you should use instead.

"Stay away fro operator overloading" ... /me shakes head

Re:Yes

[superwiz]

I have never understood why the "foe" relationship is on slashdot. It always seemed like one would want to hear from those with whom they disagreed; if nothing else than just to see why. In the 20 years that I have used slashdot you are the 1st person to demonstrate it. Your posts and signature are as uninsightful as they are obnoxious. You have shown me something new today. Thank you.

Re: Yes

[AuMatar]

Or you're writing a loop where you need to do something like cout indexcontainer[index]. Then you need to iterate by index. Which isn't the most common case, but its a large percentage of the time.

Also, auto is horrible. I *WANT* to know the type of my variables at compile time by reading the code. I do not want to have to look it up elsewhere from another definition. That alone makes your code a fail.

Re: Yes

[AuMatar]

Of course slashcode. That's supposed to read

cout <<index<<container[index];

Re:Yes

[serviscope_minor]

Sweet, another freak!

I do frequently wonder why I have more fans than freaks but there you go.

Re: Yes

[serviscope_minor]

No, it can't.

You kind of can: if you use malloc() followed by placement new and then placement delete. Of course you can't get tid of placement new, and of all the features I've seen new and delete are among the least controversial.

Re:Yes

[serviscope_minor]

Oh is that a thing? I am nothing more than a casual hacker at the language, more of a C person. The other day I saw my first template and was confused that the header seemed to do the heavy lifting.

Yes: you won't go too far wrong if you think of templates as macros on steroids. The template code needs to be in the header file for the same reason macros (even really long ones) need to be in the header file.

Re:Yes

[RatchetDriver]

Nope.

People who don't understand C++ are doomed to recreate it, badly.

Oh I so wish I had mod points today. Most insightful thing anyone has said this century.

Re:Yes

[talldean]

Trying to read various other people's C++ is a specific version of hell.

it's... just not a great language for long-term-projects, unless you absolutely need something it does that more modern languages don't.

Like, you can pat yourself on the back for being a "real programmer" because you know C++. Go for it. But if you've gotta stick a team of people on something, it's the hardest language to recruit for, and if your goal isn't to push the bleeding edge of the hardware at all costs - literally! - you don't want C++.

Re:Yes

[K. S. Kyosuke]

The macro doesn't know it, the special operator does.

Re:Yes

[ChrisMaple]

Photoshop was developed for use on the Apple Macintosh.
Gimp was developed for Unix and Unix-like systems.
Open Office had its roots in CP/M.

Re:Yes

[thestallion]

This is not correct though surprisingly many programmers believe it. Sad that here on /. it appears to be everyone.

You CAN implement your template functions outside of the header file provided you include the necessary data types it will operate on, and you make sure to instantiate every possible version you want your other source files to be able to link with. It is very useful if you know which datatypes you plan to run through your templates. And if you don't know your datatypes up front, templates are probably not your best solution anyways.

Re:Yes

[thestallion]

Actually it's possible to write template functions which link with other code from one source file to another. Unlike macros, which absolutely do need to be in a header file.

Re: Yes

[phantomfive]

Really? Like what?

Re:Yes

[bingoUV]

With modern hardware designs, the only way to guarantee making the most of available CPU and other hardware resources is to drop to assembly level or the equivalent

Yes, this is largely the situation at the client side. On server side, don't you agree with the modern software+hardware design, the successful way to ensure best performance is to ensure parallelism ? Coding for parallelism is difficult - so all the help we can get from higher and higher level languages is welcome. Even if it comes at a performance penalty - because doubling the hardware is far cheaper than getting the same hardware twice as fast.

Re: Yes

[serviscope_minor]

Really? Like what?

Performance, scalability.

There aren't currently any other languages that have a track record of delivering large, high performance programs. C was the old king there but most are now C++, including all the C compilers. Rust may yet succeed there since it's (to steal someone elses description) like a codification of C++14 best practices with some modern thye theory to help it along.

But for now C++ is king of that partcular hill.

Re: Yes

[phantomfive]

After having a nice sleep, I remembered several programs written in C++ that I've seen that are really quite well written. The language still annoys me, but I respect it.

Re:Yes

[darth.hunterix]

True, as long as you know in advance all potential template arguments and put all permutations in source file.

Actually my fist usage of templates in production code was like that.

Re: Yes

[Bengie]

You seem to be stuck in some vacuum of an idea. "Just compare against v.begin()". Dear lord, the scaling! In my experience, most complex data structures enumerate in a way that is natural for a collection, which is not the most efficiency way for a data structure that is indexed. I've seen some thread safe datastructures lock itself for the duration of the iterator to preserve the contents for the operation. What if I don't care about that? What if I just want to get the list of keys, then loop over the datastructure and try to get the key. If the key is now missing, I really don't care.

I tend to see two types of programmers. Those who only program at the abstract level and those who program at the micro-level. Both ways are wrong. You need to program at both levels at the same time. Programming strictly at the abstract level is why you see code with unstable performance. Programming strictly at the micro level is why you see fast code that is unmaintainable. They're not exclusive approaches like nearly everyone treats them. You can have the best of both worlds.

"So, in short, using iterators is usually preferable because the data type can then be changed without rewriting code" This I agree with. Too bad your example of a kludgely work around is so horrible. Iterators are a tool to generally be used, not a tool that should be shoe-horned into every situation that needs to iterate over something.

In a concurrent situation v.begin() might not match any of the values.

Re:Yes

[MikeBabcock]

Tell me that again after doing it in Python.

with open(thisfile, 'r') as fd
        for line in fd:
                parse(line)

Re:Yes

[MikeBabcock]

This "C++ is for professionals" garbage is like trying to convince people to do all their cooking with a flame thrower and a fork; obviously anyone wanting their kitchen to have properly designed tools is an amateur.

Re:Yes

[Agripa]

I use lots of C++. I also ignore major portions of it. I do not need all of it.

The problem is when dealing with someone elses code.

Re:Yes

[Agripa]

Doesn't happen much, but this time I'm going to have to agree with Anonymous Coward. All that will be accomplished by making programming languages easier is fostering the proliferation of even less qualified jackasses flooding the market with dangerously insecure and buggy code.

I would settle for not creating false abstractions. JAVA is much worse but even C reflects an idealistic and false representation of how actual hardware works and proposed C replacements make the same mistake.

Re: Yes

[serviscope_minor]

After having a nice sleep, I remembered several programs written in C++ that I've seen that are really quite well written.

Cool.

The language still annoys me, but I respect it.

Holy fuck, yes!

I mean I actually like the language. I like the combination of being close to the metal (I can predict reasonably well what it will do even after optimisations) and a high degree of programmability in the language. and I like generics over non types. And so on.

It can be really annoying at times. I mean the backwards compatibility is really annoying since they can't fix all the flaws. On the other hand that shitty code I wrote in 2003 which has since been debugged to the point of being rock solid if rather unpleasant to read doesn't need to be rewritten and for that I am glad!

Re: Yes

[phantomfive]

On the other hand that shitty code I wrote in 2003 which has since been debugged to the point of being rock solid

Oh yeah, that reminds me of another unusual benefit of C++: it is a stable platform. You would have thought by now that wouldn't be unusual, but turns out it is.

Re:Yes

[Rockoon]

No idea why other people think otherwise. Template specialization, template meta programming: all not possible with generics.

Lots of things also werent possible without using goto.

Your argument is "the language doesnt need a for loop construct because it has if's and goto's. if's and goto's rule!"

Re:Yes

[angel'o'sphere]

Your argument is "the language doesnt need a for loop construct because it has if's and goto's. if's and goto's rule!"
This is not my argument, as gotos and templates have nothing really to do with each other. If you don't have a while/repeat/for loop and you only have goto, you come not around using it. No one is forcing you to use templates if you really think they are not worth it.

Re: Yes

[serviscope_minor]

Oh yeah, that reminds me of another unusual benefit of C++: it is a stable platform. You would have thought by now that wouldn't be unusual, but turns out it is.

Yeah it's the blessing and curse. I mean it more or less guarantees that the major flaws will never get fixed with a few minor exceptions: exception specifications for example.

OTHO in an industry where you're an old fart for using Angular (first released 2010) rather than React (first released 2013), it's kind of nice that stuff that works continues to work.

For infrstructural languages (of which python apparently qualifies), there's still the 2/3 split, and it's really annoying.

I generally prefer the stability though. I can learn and remember the warts once, rather than having to relearn them every few years as they change. Also, these days I do feel I have better things to do than rewrite working code very few years.

Re: Yes

[CSMoran]

The only completely useless feature I con think of is C++ arrays - new[] and delete[] don't do anything that can't be done much better with std::vector.

There are restrictions on elements that an std::vector can hold. You can't have a vector of const-qualified entities, for instance.

C++ is a terribly documented language.

[Futurepower(R)]

C++ is a terribly documented language. Powell's Bookstore in Portland, Oregon, one of the biggest bookstores in the world, had 16 books about C++. All of them were about the many tiny details of C++, with no attempts to show how the language should be used.

Powell's Books | The World's Largest Independent Bookstore

Re:C++ is a terribly documented language.

[Greyfox]

A large part of that is that the first round of C++ programmers were writing C in C++, and you did have all the problems that C had. Things started to get better with the advent of the boost libraries and the C++11 standard brought a lot of the ideas from those libraries over in the standard.

If you were just rewriting some moldy old C or C++ library (ffmpeg and gdal come to mind as particularly moldy,) in C++11, the library would probably be a lot easier to write because of the new stuff in C++11.

Of course, you'll get done rewriting that moldy old library and think "Wow, that was easy. I think I'll add threads!" and then you'll be right back to programming life sucking again.

Re:C++ is a terribly documented language.

[careysub]

Things started to get better with the advent of the boost libraries and the C++11 standard brought a lot of the ideas from those libraries over in the standard.

Boost only came out about the start of 2000, at which point C++ had been under development by Stroustrup for 21 years, and the release of C++ 2.0, arguably the first "modern" version of C++ was 11 year earlier. And C++11 was only approved on 12 August 2011.

That is a lot pain and suffering and legacy code before the "better" arrived.

Re:C++ is a terribly documented language.

[Z00L00K]

This highlights the problem with C++ - it's not the libraries that are the concern, it's the language and the problem isn't writing C using C++ - it's that C++ is using constructs that are so hard to penetrate and understand by anyone else but the person that wrote it that it's suffering code rot.

Re:C++ is a terribly documented language.

[AmiMoJo]

Probably because that's like expecting a book about how to solder telling you how to design electronics.

That illustrates the main difference between C/C++ and other higher level languages. Most languages are built around software development patterns and methods, which is good when you want to build apps. But C is designed to be the most powerful tool possible and it's up to you to apply it to some model.

Re:C++ is a terribly documented language.

[epine]

That is a lot pain and suffering and legacy code before the "better" arrived.

Have you forgotten how the poster children of the 1990s software development rectitude revolution were Visual Basic and PHP?

I haven't. Not by a long sight.

Use a subset

[Anonymous Coward]

And choose your libraries wisely.

Know what things to avoid.

[Anonymous Coward]

Part of the challenge of using a language is not just knowing all of the things you *can* do. It is also knowing which things are best to avoid, and what the pitfalls are.

Re:Know what things to avoid.

[Anonymous Coward]

No. There's a huge difference between learning the proper idioms of a language vs. needing to avoid dangerous, confusing, and hard to use aspects of a language. Good languages have very few of the latter, bad languages have many. Considering how often people talk about using subsets of C++, I'd say it's obvious which category it falls into.

Re:Know what things to avoid.

[Solandri]

I think that's actually part of the "problem" (if you can call it that) with C++ (and by extension, C). It's too flexible. You can use it to program at an extremely high abstraction level, relying on pre-built libraries to do all the heavy lifting for you. Or you can use it to drill down to do register- and memory address-level operations. Or anything in between. It's like giving someone a car, and all the wires, gears, switches, levers, nuts, and bolts are all exposed so you can tinker with them, but there's no easy way to distinguish which of those components are the basic controls (steering, shift, accelerator, brake).

More experienced people want the flexibility of being able to drill down and modify or recreate basic functions. Beginners will want a high level of abstraction so they can get the ball rolling with minimal effort. C++ can do both, but unfortunately it doesn't try to delineate between these abstraction levels. It's easy for a beginner to get tied up writing minutiae code and writing it badly because they're a beginner, not realizing that a function or library written by an expert already exists for what they're trying to do. And it's easy for an advanced programmer to use a pre-existing library because "the work has already been done", then get upset that the function in the library doesn't do exactly what they want to do or performs poorly.

String handling is a good example. If you use the string library, it "knows" that strings have a length, and provides protection against buffer overruns. But if you're a beginner and don't know about the library, it's easy to fall into the trap of handling strings yourself since they're just a pointer to a sequence of characters in memory. And the beginner doesn't know to keep track of the max string length, and ends up writing code vulnerable to a buffer overrun exploit. Maybe what C++ IDEs need is some sort of menu setting where you tell it your programming skill level, and it hides or exposes different functions based on that setting.

Re:Know what things to avoid.

[geoskd]

No. There's a huge difference between learning the proper idioms of a language vs. needing to avoid dangerous, confusing, and hard to use aspects of a language.

Contrary to popular belief, C++ does not have very many aspects that should be avoided. The simple fact is that C++ is a reflection of how complicated high performance computing really is. If you don't understand C++ than you damn sure don't understand writing performant code, and are more than likely a contributing factor to why a computer in 2017 feels no faster than a computer from 2005, in spite of having a processor that is at least 20x faster. Far too many programmers are willing to (or only capable of) write dog-slow code, and release it. If software engineering were held to the same standard as any other engineering discipline, 80% of the "software engineers" out there would be barred from practicing due to incompetence. In what world would we allow someone with a 2 month correspondence course to perform architectural engineering? How about electrical engineering? Or Civil engineering? Ok, maybe Civil Engineering...

Those who complain that C++ is too complicated, do not understand how computers actually work. If they did, they would know why C++ is the way it is, and would know how to use it. They would also know why most other languages should be considered inferior. Instead, they display their own ignorance.

Re:Know what things to avoid.

[Carewolf]

The word you want is "idioms".

Every language has a set of idioms that works and C++ is no exception.

There are just more of them in C++ and the language is designed to be able to handle new ones with ease. Still newbies shouldn't be doing that, which is one of the pitfalls of the language if you learn it feature by feature instead of idiom by idiom.

Re:Know what things to avoid.

[Joce640k]

Contrary to popular belief, C++ does not have very many aspects that should be avoided.

Most of the things to avoid come from C, eg. C memory management (especially C strings), uninitialized variables/memory, etc.

Those who complain that C++ is too complicated, do not understand how computers actually work. If they did, they would know why C++ is the way it is, and would know how to use it. They would also know why most other languages should be considered inferior. Instead, they display their own ignorance.

Yep. Computer languages are a means to an end - they let you turn ideas and algorithms into code.

C++ is king of that, there's no computing concept it can't express. Attacking it becasue of syntax (or whatever) is completely missing the point.

eg. Java didn't have operator overloading because it could be abused. Coding anything mathematical in Java was an exercise in frustration as a direct result of making Java "safe".

Re:Know what things to avoid.

[AmiMoJo]

Depends how you define "performant"... Which isn't a real word but the point is that if you want performance on say an MCU, C++ is mostly useless and you will end up writing code that is 90% C with a bit of OO for organisation.

Even on powerful systems the best performance is only available if you avoid using C++ features that cause memory allocation and the like, at which point you are mostly using it to make the code itself nicer.

On a related note I think this is one of the major reasons that driver code is often so terrible.

Re:Know what things to avoid.

[angel'o'sphere]

uninitialized variables/memory, etc.
C++ does not have uninitialized variables ...

Coding anything mathematical in Java was an exercise in frustration as a direct result of making Java "safe".
That is why we use Groovy and/or Scala.

Re:Know what things to avoid.

[ChrisMaple]

C++ does not have uninitialized variables ...

Citation please. I looked at about 8 C++ FAQ websites, and the prevailing advice was "undefined behavior" and "operating system dependent."

Initializing a large block of memory for an embedded system may be a waste of time.

Re:Know what things to avoid.

[angel'o'sphere]

A large block of memory is not a variable.

int a; <- that is a variable, and it is initialized to zero

To have uninitialized "variables" you need to define a struct/class that has no constructor.

An empty constructor initializes everything to 0 or 0.0.

Here is an interesting conversation about it: https://stackoverflow.com/ques...

No it's not.

[Anonymous Coward]

No C++ is not a terrible language.
It's still IMHO the best general purpose language there is, but it has grown a devilishly high threshold to master.

With "general purpose" I mean a language you can use in both user-mode and kernel-mode, that you can use to express and implement anything in.

It's like a toolchest with so many tools it'd baffle a newcomer, and probably not even half of them would be user by a master craftsman in a single project, but together they create the best toolchest there is - is looking only at a single language.

Perhaps that last point is what most miss - there is no silver bullet.

Re:No it's not.

[OneHundredAndTen]

It's a worthy conceptual child of PL/1.

Re:No it's not.

[NicknameUnavailable]

The issue is it's the best general purpose language with less than 100 keywords. That means a lot of shit has nuance to keep the vocabulary lightweight and in turn is extremely easy to fuck up. It's not as bad as whitespace, but it's in the same exact category. Things don't stick around in software because they are inherently better, in fact the overwhelming majority of software written more than a decade ago is absolutely irrefutably terrible by any modern assessment (in no small part because rather than being redesigned from the ground up, backwards compatibility and patching becomes a central design element of the thing itself, c++ is no different.) It's an archaic language which has widespread compiler support and absolutely nothing else going for it. It's around because it was the best at the time and a lot of stuff was written in it, which in turn created a situation where lots of stuff is still dependent upon it. The only reason to write a new program in c++ is because the platform you're targeting doesn't support better (mostly because c++ is "good enough" none of the many better languages made it there.)

Doctor, it hurts when I go like this

[Anonymous Coward]

If one uses every single feature of C++, then it's probably a really terrible language.

If one only uses features that make C++ better than C, then it's usually good enough.

Re:Doctor, it hurts when I go like this

[geoskd]

If one uses every single feature of C++, then it's probably a really terrible language.
If one only uses features that make C++ better than C, then it's usually good enough.

C is the original performant language, but it turned out to be only marginally easier to maintain than assembler.

C++ was originally intended to make the code easier to maintain, but like all efforts in that direction, the cost was in performance

Then in the early 2000s, it was discovered that there were some really performant things you could do with C++ that didn't hurt the maintainability, and now it is possible to write C++ that is both maintainable and highly performant. The problem is that the cost of this bargain is that there is a very high complexity to the task. Mediocre programmers can still manage to write performant code that is un-maintainable, or slow code that is easily maintainable, but an expert can achieve both.

C is no longer the performance king. A highly skilled C++ programmer can write c++ code that will outperform even the best C code. The cost of that performance is template meta-programming. It's a higher level of abstraction; its bitchy hard to understand; it's 100% necessary for performance; deal with it.

Modern programmers should be required to demonstrate proficiency with template meta programming as a prerequisite to being allowed to practice, much the way a course in lisp is included in virtually every accredited computer science degree.

Re:Doctor, it hurts when I go like this

[angel'o'sphere]

C++ was originally intended to make the code easier to maintain, but like all efforts in that direction, the cost was in performance
I doubt you find a convincing example where C++ code is less performant than C.
Perhaps you can find a compiler or linker that compiles or links the former slower than the later, but that would be it. /me facepalms

C is no longer the performance king.
It never was. C is a small VM abstracting away registers and actually memory.

Modern programmers should be required to demonstrate proficiency with template meta programming as a prerequisite to being allowed to practice that is IMHO to much to ask for. I actually only know about 10, perhaps only 5, programmers who actually used those features.

much the way a course in lisp is included in virtually every accredited computer science degree.
LISP is in my eyes a pain in the ass ... people who like it most likely never will really do C++, but on the other hand might grasp template meta programming instantly: because it is the same as lisp, with different syntax/result.

Re:Doctor, it hurts when I go like this

[geoskd]

You ivory tower types are all the same.

Ivory tower? My code is routinely profiled against C implementations, and my code routinely wins. I have to know where every cycle goes because I have hard limits on wall clock execution time, and thanks to having actual data security, throwing cloud based resources at the problems to make up for lack of programming skill is not an option.

Using TMP, I can beat even the tightest inner loops written in pure C. I get paid good money to shave milliseconds, and at every step of the way I have to prove conclusively that my solutions are better than what was already there. The kind of work I do is very lucrative, but it weeds out the incompetent at a frightening rate, and there is a damn good reason I am one of the survivors.

You are holding it wrong

[Nkwe]

C++ is not necessarily a horrible language, but it does allow you to write horrible code. You can also write easy to read well organized code that is "good" - it's entirely up to the developer. With great power comes great responsibility, yadda yadda.

You can write really good or really bad code in pretty much any language. Generally if your code ends up unreadable, you are doing it wrong.

That being said, if the semantics of a language tend to encourage people to write horrible code, does it make it a bad language? Good question. Discuss.

Re:You are holding it wrong

[iggymanz]

any language with a turing complete macro system is garbage

Re: You are holding it wrong

[Camarillo Brillo]

Excellent point! As a 30 year programmer, I made the transition from C to C++, and saw some horrible code written by what I csll "academic " programmers. That sort of approach would elegantly hide away all traces of the applications flow by using every type of tool the programmers used in writing their thesis. I learned a lot if ways NOT to write readable, maintainable code. Most if my C++, looks mostly like C language with classes (and solved the problem I was assigned). C++ can keep its polymorphism and templates and other obfuscations thank you just the same. There is an old, interesting blog post from Martin SÃstrik from 2012, about why he regretted writing Zero MQ socket comm library in C++ {http://250bpm.com/blog:4} which I found rather amusing then and still. Now, anyone up for s raging debate over the merits of C# vs. Java ? :-0

Re:You are holding it wrong

[david_bonn]

That being said, if the semantics of a language tend to encourage people to write horrible code, does it make it a bad language? Good question. Discuss.

My first observation about C++ is that the best examples of clean, well-written code in C++ tend to use a very constrained subset of the language.

My next observation is that over the years many of the features added to C++ seem to be very obscure and seem to address odd corner cases. I suspect this is because of some deep design flaw in the language.

C++ tends to reward a programmer who can design clean, graceful interfaces that can successfully evolve over their lifetimes. And C++ mercilessly punishes programmers who cannot do that. Unfortunately, the vast majority of programmers cannot design clean, graceful interfaces. And very few programmers can do so all the time.

So yes, in my opinion if a language makes it too easy to write horrible code and very challenging to write great code it is probably a horrible language.

Re: You are holding it wrong

[mikael]

When coding with assembly, programmers would use macros in the same way templates were used. You would define your macro with parameters defining the local name of each register storing that variable. Then if you wanted to reorder register usage, you just change the order of the parameters in the macro call.

Re: You are holding it wrong

[Anonymous Coward]

Excellent point! As a 30 year programmer, I made the transition from C to C++, and saw some horrible code written by what I csll "academic " programmers. That sort of approach would elegantly hide away all traces of the applications flow by using every type of tool the programmers used in writing their thesis. I learned a lot if ways NOT to write readable, maintainable code. Most if my C++, looks mostly like C language with classes (and solved the problem I was assigned). C++ can keep its polymorphism and templates and other obfuscations thank you just the same.

That's the right mindset. But then the time comes when template metaprogramming can save you from having to write and hand-optimize thousands of line, and lets you do elegantly and efficiently, in a few hundred loc, what would take you ages and a few tens of thousands of locs otherwise. And then you use template metaprogramming, and are thankful C++ has them.

Each tool has its use, the problem is when you give monkeys 10 different kinds of hammers, and they start banging everything with any one of them. All of them at once. Of course, the hammers are fine, it's the monkeys that shouldn't be using them.

Re:You are holding it wrong

[geoskd]

So yes, in my opinion if a language makes it too easy to write horrible code and very challenging to write great code it is probably a horrible language.

Think about it a little differently: There are a few primary goals when writing code. The first is speed of coding: how fast can the developers get the work done. The second is maintainability: How easy will it be to get new developers up to speed on the project, and how easy will it be for them to add new features. The Third is code performance.

Some languages address the first item very well. Python is a good example of a language that allows you to get something working very quickly. It can be maintainable or not depending largely on the quality of the code that is written and the presence (or lack) of comments. Python simply cannot be performant. It is an interpreted language, but even compiled, it cannot achieve high performance because it lacks the language constructs necessary to permit high performance computing.

Some languages address the second very well. Java was designed to be a language that follows a rigid pattern of development that should be very similar across projects. In theory this should allow a developer to come up to speed more quickly because there is only one way to do each thing that needs to be done. In practice, Java developers can write horrrendous code too, and for the similar reasons to Python, Java simply cannot be performant.

For the third, there are very limited options for raw performance. They really are: Assembler, C++ and C, in descending order of absolute performance (C++ might even edge out assembler now thanks to TMP. In theory you could implement the same thing in assembler, but good luck). Developers can write maintainable code in any of the three, or they can write junk. It really depends on the developer.

At the end of the day, the first two priorities can be had in any language depending on the skill of the developer, but the third priority can only be had in those three languages. It is due in no small part to those capabilities that C++ is as complicated as it is. It can do things that *no other language can do*.

In the end, if there is even the slightest possibility that performance will be a project priority, then you are limited to C, C++ or Assembler.

Re: You are holding it wrong

[geoskd]

When coding with assembly, programmers would use macros in the same way templates were used. You would define your macro with parameters defining the local name of each register storing that variable. Then if you wanted to reorder register usage, you just change the order of the parameters in the macro call.

I'm afraid you have not only missed the entire point of templates, but also their most powerful capabilities as well

Templates are for implementing the same function multiple times with variations between them, but without having to rewrite the whole function in every variation you want to implement. For example: (I apologize about the formatting)

template<tbool T_bRounded>
void foo()
{
//Do some stuff to find x
if( T_bRounded)
{
return( round(x));
}
else
{
return(x);
}
}

This simple function implements a call that either returns x, or rounds it first, and then returns it. The magic of the implementation is that the conditional on T_bRounded does not result in an actual jump instruction. Instead, the function is instantiated twice, once with the return in the if clause, and once with the return in the else clause. The correct function is called based on the template parameter that is used. For this simple example, it is not terribly useful, but imagine that foo has an inner loop where T_bRounded gates a particular behavior that is executed millions or billions of times. Not having that extra conditional jump in the assembled code will make a huge difference to the resulting compute time. That is a simple example of the real power of TMP. Imagine if you have a dozen such booleans that you want to gate out various behaviors from an inner loop. You could easily double or triple the speed of the inner loop. The only way to write competing code in C would be to write 4096 versions of the function with all possible combinations of the twelve flags, and call the correct one based on the flags using a jump table. What are the odds that you could write all 4096 without having a significant number of mistakes? With TMP, you write it once and the compiler spreads it out for you.

Re:You are holding it wrong

[antdude]

What about BASIC, Pascal, C, ASM, HTML, ASP, CF, etc.? :P

Re:You are holding it wrong

[phantomfive]

Unfortunately, the vast majority of programmers cannot design clean, graceful interfaces.

Most of them cannot because they don't even realize they are designing interfaces. If they realized that, suddenly the code around the world would see an immediate and gradual improvement.

Re: You are holding it wrong

[Rockoon]

The magic of the implementation is that the conditional on T_bRounded does not result in an actual jump instruction. Instead, the function is instantiated twice, once with the return in the if clause, and once with the return in the else clause.

You are relying on specific implementation details that are beyond the c++ standard with your argument.

Re:You are holding it wrong

[chthon]

any language with a turing complete macro system *that isn't Common Lisp* is garbage

Re:You are holding it wrong

[sorton9999]

I like to think of C++ like this: Just because a person plays a game that is difficult to master and loses all the time doesn't make it a bad game. It's that the player doesn't bother or is incapable to learn the finer points that will allow him/her to become better. Like a good game, C++ has layers to its strategy that takes time to discover and master but if you're just starting out with basic knowledge it is still "playable". The problem with C++ is that it is suffering from feature creep and bolted on fixes to the more broken aspects of the language all for the sake of backward compatibility. I've run across code from 2001 and it still compiles with the modern compilers and runs on the latest kernels of your favorite flavor of linux.

Re: You are holding it wrong

[geoskd]

How long an iteration of a loop takes to execute is irrelevant. What matters is the circumstances contributing to iteration count.

The number of iterations in many instances is fixed and cannot be improved. For example when processing the records in a database, you have to iterate over all of the records. Any reasonably sized database will have millions of records. The databases I deal with have trillions of records. Yuo certainly don't want to waste iterations, but thinking that the amount of processing in the record loop is irrelevant is ignorant.

Create C+++ Then - With A New Syntax

[dryriver]

Keep the compiler, keep all the powerful capabilities of C++, and add an alternative syntax - a friendlier one - that people who struggle with C++ can more easily learn and more easily manage. Back in the days of Flash, Actionscript first had one syntax, and then got a 2nd alternative syntax. You could use either one. The same can be done with C++. Create a new syntax for use in the 2020s and beyond. Don't destroy everything that makes C++ great in the process. There is your "new" language - C+++.

Re:Create C+++ Then - With A New Syntax

[Nkwe]

Keep the compiler, keep all the powerful capabilities of C++, and add an alternative syntax - a friendlier one [...] There is your "new" language - C+++.

Go one step farther and make it four pluses, arrange them in two rows of two and you have C#.

Re:Create C+++ Then - With A New Syntax

[Anonymous Coward]

You do remember that auto has been part of C since K&R?
Auto was a storage specifier meaning "put this on the stack."

I've been using c++ professionally since 1994, I'd hardly even call it the same language if you use the modern feature set. I still think most of the meta-programming stuff is crap and only makes most problems harder to solve instead of easier.

Re:Create C+++ Then - With A New Syntax

[ChoosyBeggar]

Fuck everything, we're doing five pluses. If two pluses is good, and three pluses better, obviously five pluses would make it the best fucking language that ever existed. Comprende?

C++ is great

[Actually, I do RTFA]

You can write really great code, short and powerful. You can also write really bad code. In this way it's similar to other languages. However, I've found it far easier to write multiperson, maintainable code in C++ than in JavaScript.

It does suffer some from things like iterators and safe pointers being added... 1/2 way through it's lifecycle. And therefore, they are less clear than they could be.

Re:C++ is great

[mykepredko]

Saying it's better than Javascript isn't a ringing endorsement.

Re:C++ is great

[djinn6]

However, I've found it far easier to write multiperson, maintainable code in C++ than in JavaScript.

Having worked with well-written projects in both languages (as well as several others), I must disagree. Javascript can be written with maintainability in mind and it doesn't take a genius to do so, only discipline. But C++ is difficult to work with even in the hands of an experienced developer. You end up spending half of your time wrestling with the language to get it to do what you want and the other half digging through core dumps. It's also extremely unforgiving of any mistake. If you're lucky, the entire program crashes. If you're not, it'll go on happily corrupting all of your data. And the fact that it's so difficult to write unit tests doesn't help either.

You can argue that an expert should not be making those mistakes, but in reality, no one is perfect 100% of the time. And even if you were, is it really worth spending that much effort on something a better language or runtime would just handle for you?

Re:C++ is great

[Actually, I do RTFA]

I'm confused. Why do you think it's easier to write JS code with maintainability and among multiple people? C++ allows for far better isolation in, e.g. compiler enforced interfaces. Granted, if you want to work with multiple threads, you can get timing errors, but that's just that feature. If you programmed a long time ago, you may not be away that the revisions (and templates before that) allowed things like auto-sizing arrays.

Re:C++ is great

[djinn6]

My previous post mainly focused on why it's hard to maintain in general. To answer your question, I think by far the biggest difference is readability, and JS being a higher-level language makes it much easier to understand what the code author intend it to do. It hides much of the details with weak typing and automatic memory management, so what a reader sees is just the logical flow.

Yes, the compiler can enforce certain rules, but it's not foolproof and there are lots of ways to misuse a class or function that the compiler cannot check. At some point, the person using the interface needs to understand how it works. While clear documentation is far more important than the code itself for that purpose, diving into the implementation to figure out some detail still happens quite often, as is looking at the unit tests.

The more recent changes to C++ significantly improved readability, but still not to the degree higher-level languages can accomplish. I still run into macro and template magic that takes far longer than it should for me to parse.

Re:C++ is great

[SpinyNorman]

Pre-2011 iterators were a bit clunky, but with the addition of "auto" and range-based for loops (where you don't even see the iterator), there's not much to compain about:

for (auto value : my_list) {
  std::cout << value << "\n";
}
 
Or, if you really want to see the iterator:
 
for (auto iter = my_list.begin(); iter != my_list.end(); ++iter) {
  auto value = *iter;
}

I don't see what's wrong with smart pointers either (assuming we're talking about the modern std::unique_ptr or std::shared_ptr). Of course, having both stack-based objects and pointers (smart or not) C++'s syntax is never going to be as clean as a language where everything is a proxy to a refererence counted heap-based object, but that's the price you pay for flexibility.

Re:C++ is great

[djinn6]

Suppose function A calls function B, and I want to test A in isolation. How do I do this?

Google Test does provide a way to mock function calls, but only for virtual class methods (which if you know C++, makes a lot of sense). But that means regular old static functions cannot be mocked out. In other words, if I'm using someone else's library, I need to first convince them to change their API. That or write a wrapper for every library call I make. Neither sounds all that appealing to be honest.

Re:C++ is great

[Actually, I do RTFA]

I completely grant that macro and templates, unless very simple, are usually the wrong tool. And miserable to debug. Just like (unless working on extremely performance demanding code) fiddling with low level memory management is overkill. But C++ has automatic memory management structures.

On weak typing, I still don't understand the benefit at all. But it's a wash. C++ has auto and JS has type declarations managed via IDE.

I have a lot of issues with JS when it comes to multi-person collaboration. Maybe you can explain what I'm doing wrong. I'll start with one off the top of my head (and if the conversation continues, I'm happy to supply more): JS fails completely, as compared to C++, in the inability to use header and source files to break circular includes. On large projects, that seems to be a vital requirement. Especially if you have multiple files of utility structures/functions, some of which rely on one another.

Re:C++ is great

[djinn6]

Leaving aside the common theory that circular dependencies should be avoided, there are no real problems with them in JS. Let's say you have a bunch of functions, you can include all of them in the HTML file in no particular order. When everything is there, you call your main function, which initializes any global data you need and then calls all of the other functions. At that point, they will be executed with the complete context they need.

See this for a very simple example. Note that I can refer to "c()" in the definition of "a()", even though I haven't declared "c" yet. The contents of "a()" is not evaluated when module_1.js is loaded, but rather when I explicitly call "a()" from the inline script.

This deals with 99% of the use cases. But if you really need module-level static variables that have complex dependencies, you can always go with a singleton factory and construct it on first use.

Was OK for the '80's, But Its Time Has Past

[Bruce Perens]

C++ is a 1980's language (actually, Bjorn started work in 1979). It's lasted long enough that we don't have to shed any tears for its demise.

We have many better options today. Personally, I am writing in Crystal, and you can see my explorations here:

• Introduction.
• Why Dynamic Linking Doesn't Make Sense for Modern Languages.
• Tiny Crystal.

Re:Was OK for the '80's, But Its Time Has Past

[_merlin]

Killing dynamic linking means you need to update absolutely everything when a security bug is found in a common library. That's far worse than just some extra memory use.

Re: Was OK for the '80's, But Its Time Has Past

[Bruce Perens]

This was already the case for bugs in templates and headers in languages like C and C++. In this case It's a cost you have to pay for a more powerful language.

Re:Was OK for the '80's, But Its Time Has Past

[phantomfive]

In the 90s Bertrand Meyer wrote a long book theorizing about how to organize programs, especially in the OO way. Now, I don't think he got it right (I'm not entirely sure I know how to do it right), but he was at least theorizing about it, and building on past theorizers about how to organize programs (although he missed stuff like Alan Kay's work). Nobody is doing that kind of thing now: language designers have mainly reverted to playing with syntactic sugar and a grab-bag of features (RUST maybe excepted, but they're wild and crazy).

I think the reason there's so much churn in languages is because no one has figured out how to do organization correctly. The language that does will win the war.

Re:Obcious

[Joce640k]

True, but it's not as horrible as all the other languages.

ALOTD (another language of the day)

[jmccue]

I am no fan of c++, and I agree it is terrible. But, creating yet a other language sounds a bit over the top.

I am convinced this is happening for one reason, companies do not want to train anyone! If they took the the time to properly train people the industry would not be in this state, now we get new methodologies and languages every other day.

When I started out, senior people spent a lot of time with me showing how I can improve my skills and how the business works. These days you are expected to muddle along hoping to learn your job. No wonder we are having large breaches and crappy software

Re:ALOTD (another language of the day)

[dcollins117]

I am no fan of c++, and I agree it is terrible. But, creating yet a other language sounds a bit over the top.

Well, if you are not a fan and agree it is terrible, yet don't want to use something else one much conclude you are a masochist.

Re:ALOTD (another language of the day)

[Raenex]

But, creating yet a other language sounds a bit over the top.

I'm not against another language, but there's too much Not Invented Here. There are lots of languages that have been designed to be C++ replacements, and they all mumble the same things about being simpler and more expressive.

How about no?

[loonycyborg]

It's the most practical language that exists. It trades this off for insane learning curve. But if you master it you'll never run into a roadblock that doesn't have a solution. Of course it's possible to make a better language for a different niche, but a person that would make such language for sure wouldn't think that C++ is "terrible" because such opinion can only appear from ignorance of C++, its alternatives and alternative solutions to issues with C++.

Re: How about no?

[phantomfive]

You really have to define practical if you are going to say that, because "learnable" should be in the definition somewhere. The easier to learn, the better the language (all other things equal).

Re:How about no?

[geoskd]

But if you master it you'll never run into a roadblock that doesn't have a solution.

Thats what you think...

I want to iterate over an enum where the code in the loop calls a templated function using the enum value as the template argument.

If you can figure out how to do it, let me know.

Re: How about no?

[loonycyborg]

For a general purpose language of its design goals it's pretty well learnable. It's about as easy as it gets for a language that is at the same time C compatible, statically typed and fast enough to be used for tight loops. Especially considering buttload of textbooks that exist for it. C++ just became victim of its own success, making it easy target because it's well known.

Re:How about no?

[loonycyborg]

If you're passing the enum as template arg you're iterating over it at compile time. That's not how you're were supposed to use templates originally. Such template metaprogramming stuff is relatively new discovery. Nonetheless there are features supporting usages like that in newer versions of C++ standard such as constexpr and variadic templates. However if you REALLY love compile time evaluation there's dedicated language supporting this: D. It was made by C++ programmers who discovered this new template metaprogramming dimension in the first place.

Re:How about no?

[angel'o'sphere]

there's dedicated language supporting this: D. It was made by C++ programmers who discovered this new template metaprogramming dimension in the first place.
D is a child of Walter Bright, he is a C++ compiler writer, not a "discoverer" of TMP. TMP is partly discovered by the guys behind the STL, partly by Andrew Koenigs, James Coplien, Jiri Sirkoup, Ulrich Eisenecker and his PhD son, Krysztof Czarnecki (and partly me, but I only made one publication :D well, I guess there are plenty more people involved, but I never heard that Walter was deep into templates. But his Symantec C++ compiler/IDE - especially the graphical debugger - rocked big time)

Re: How about no?

[phantomfive]

It's not C compatible anymore.

Re:How about no?

[loonycyborg]

Actually, I meant Andrei Alexandrescu who is co-developer of D. Though it seems he actually joined later. And actually he didn't discover TMP itself but some more advanced techniques within it.

Re:How about no?

[angel'o'sphere]

Ah, I did not know that Andrei is now in the D team, I actually did not watch D that closely recent years.

The biggest issue IMHO

[rrohbeck]

C++ is so big/complex/rich that different people or groups use different subsets, from 'better ANSI C' to 'Object hierarchies everywhere with lots of templates.' I've seen code that obviously started as "my first OO project" with classes including copy constructors and getters/setters for the most primitive structures that were later changed with basic C code and friend declarations so that this code could work around the class structure. And a bit of STL here and Boost there.

Give me C any day of the week; I can handle memory management and pointers with KISS.

Re:The biggest issue IMHO

[WinstonWolfIT]

Have templates ever improved? Back in the day, compile-time errors were nighmarish.

Re: The biggest issue IMHO

[phantomfive]

Yeah, C is overall better, due.to the clarity.

Re:The biggest issue IMHO

[Anonymous Brave Guy]

Have templates ever improved?

Yes, they have. A lot of the changes in the more recent standards have been aimed at cleaning up warts in the language or nasty edge cases. More generally, compilers have improved, particularly in how they handle templates.

Unfortunately, a lot of the developments in C++ within the past decade have been more about fixing what was already there but somewhat broken than breaking new ground. In the overall programming language space, C++ looks dated today, with many of the changes that did break new ground still looking like poor imitations of things that are done much better in other languages. Of course, part of the reason for that is that many of those other languages have been designed with the experience we had already gained by using C++ over many years and for many different applications.

Re:The biggest issue IMHO

[geoskd]

Unfortunately, a lot of the developments in C++ within the past decade have been more about fixing what was already there but somewhat broken than breaking new ground.

And yet here we are nearly 20 years later, and no one has a better alternative to TMP, and most languages don't offer anything at all.

Re:The biggest issue IMHO

[Carewolf]

C++ is so big/complex/rich that different people or groups use different subsets, from 'better ANSI C' to 'Object hierarchies everywhere with lots of templates.' I've seen code that obviously started as "my first OO project" with classes including copy constructors and getters/setters for the most primitive structures that were later changed with basic C code and friend declarations so that this code could work around the class structure. And a bit of STL here and Boost there.

I only know three common subsets:
- Industry standard - No exceptions or RTTI, used by Apple, Google, Qt, KDE, and Microsoft. Is currently limited at C++11 or C++14 depending on project.
- Kernel safe: Mostly C with some nice syntax things and a few templates, used by GCC and various low level libraries and hobby kernels.
- Language wanking - Uses everything, used by the STL, Boost, and newbies.

Re:The biggest issue IMHO

[Anonymous Brave Guy]

Better in what sense? TMP lets you do a few useful or at least interesting things, but I've always found it bizarre how much attention it gets for something that is basically an accident of C++ language semantics.

Re:The biggest issue IMHO

[rrohbeck]

Even if you have official subset guidelines, it still comes down to individual programmers' preferences.

This is why Rust is popular.

[Anonymous Coward]

Rust is a new language developed by Mozilla. It can be seen as the successor to C++, because it puts so much emphasis on zero-cost abstraction and high performance (unlike a language like Java), while also being a lot safer (unlike C). Rust is basically what C++ would have been had it been developed 30 years later. This is why we've seen Rust become so popular so quickly: it gives the benefits of C++, but avoids so many of C++'s problems. You don't have to move to a language like Java or Perl or Go any longer. You can just use Rust, which is like a leaner, more modern C++.

Re:This is why Rust is popular.

[Joce640k]

It's not any simpler than C++ though. Right now it's probably still more productive to learn to use C++ properly.

Re:This is why Rust is popular.

[Anonymous Coward]

Hyped out of proportion at every (in)conceivable opportunity by a noisy minority != popular.

Re:Obcious

[david.emery]

Disagree. It's more convoluted than C, but adapts C's very error-prone syntax. It's more complex than Basic, FORTRAN or COBOL. It doesn't have the simplicity of Pascal nor the consistency of Java or Ada.

It's definitely a 'science experiment that escaped from the lab.'

Never learned C++

[innocent_white_lamb]

I've been programming for over 40 years (shudder..) and have always used C. Never seen a need for C++ for the sort of things that I do.

Perhaps it's because I don't do games and fancy graphics. I do things like counting pulses from water meters and getting coordinates from survey instruments.

You could get some really fancy graphics out of Amigas using C, though. :)

Re:Never learned C++

[uvajed_ekil]

C is a decent language.

Your auto-correct corrected "dead" to "decent."

Re:Never learned C++

[trawg]

If I recall correctly, both Doom and Quake were written in ANSI C (maybe even up to Quake 3?). I don't think they moved to C++ until they did Doom 3.

Re:Never learned C++

[Phaid]

Similar situation here, I've been developing realtime traffic-management systems for 24 years. I have always used C for my own new projects, but I have had to learn C++ in order to support projects that I inherited. There's nothing you can do in C++ that you can't do in C; C++ just adds a bunch of constructs that are supposed to make software more modular, reusable, standardized, and "safe" from bad coding. In real life, it just makes for code that is harder to understand and harder to port to newer environments due to changing standards.

Re:Never learned C++

[Dutch Gun]

Perhaps it's because I don't do games and fancy graphics.

I'd say you're spot on here. C is great for relatively low-level procedural programming. If I have simple tools or highly procedural code to write, I almost always revert to more C-like code. It's just simpler and quicker for those types of tasks.

However, games tend to manipulate an insane amount of state... and not just simple, uniform state, but a crazy, diverse collection of state that represents an entire virtual world and all the ways that state can interact with each other). C++ is pretty good at encapsulating that sort of state and associated behaviors while keeping the complexity contained in smallish modules, all while providing some protection against programmer mistakes - if done correctly, of course. If done badly, the result is probably worse than if it was done in straight C.

Re:Never learned C++

[angel'o'sphere]

There's nothing you can do in C++ that you can't do in C
Then you don't know much about C++.
Hint: constructors, destructors, custom allocators ... you have noting like this in C.
Oh, you mean you can write your own library in C and then manually call the functions?
That is not what "languages" or "abstractions" are about.

Obviously you can write any program in any language, but then again: That is not what "languages" or "abstractions" are about.

Re:Never learned C++

[ChrisMaple]

Let's say you have to implement a new numeric type, say 144 bit scientific notation ("float".) C does not have operator overloading, so expressing
e = (a+b) * (c+d); // C++
looks like this in C
e = mult144( add144(a,b) , add144(c,d) );

The C++ version is more concise and much easier to understand.

C++ is an engineering language

[stikves]

It is one of the things that is easy to learn, but takes many years to master.

The proper way to do things take a lot of discipline, and looking at the culmination of effort bringing really stable and predictable systems is satisfying. It is no longer as "visible" as other languages, but many of the software people use daily is still mostly C++ (and C of course). For Linux there is still heavy C usage (in the Kernel, X11/Wayland, and Gnome). However KDE desktop, LibreOffice, VLC, Firefox and many other projects are done in C++. Similarly for Windows low level interfaces are already in C++, and MacOS kernel and UI libraries also use C++, and Objective C++ (but not exclusively).

Yes, they are not "sexy" software items, but they work, and I have seen much less exceptions, crashes, and failures in proven C++ code, compared to many Java, Python, or JavaScript code.

A few new low level programming languages are trying to change the situation, but the progress is slow. It could be said that D was the initial one, later Go, and Rust came along. But still most non-experimental low level and mission critical software is still developed in C or C++.

So, no C++ is not a terrible language. It gets results, and many organizations still prefer to keep using it. Unlike older generation languages like COBOL (abandoned by banks), FORTRAN (abandoned for R/Python in scientific research), or Pascal (abandoned by Apple for ObjC++), the C++ community is still thriving.

Re:C++ is an engineering language

[jcr]

the C++ community is still thriving.

Billions of flies eat shit.

-jcr

It wasn't always shit

[Tsolias]

Before c++11, c++ had great features that helped you write cleaner code.
The last time I bothered in a bureaucratic way with c++ was in 2013 when I was in a committee to send some features in for suggestion.
The meeting had a lot of people yelling at a guy who was part of isocpp iirc half a decade ago, and he flew from usa for that purpose.
I left in the middle of this shit.
Long story short and I am adding here not only my opinion but the opinion of every colleague who wrote c++ in research labs in different hierarchy levels inside an os, C devs do need C++ to help them write code easier, without hassles and give them more tools when they need them.
C++ the last 10 years has been adopting the web dev language cycle.
You have to have the bleeding edge of features to stay relevant...as frameworks languages and apis die and born every day.
C++ has no enemies, yet it's getting tackled by its own people.
Instead of having powerful lean language, just like C, you have a clusterfuck of a language.
I stopped using the bewest and coolest features because most of them are useless and don't worth the extra effort to include them in your programming style and most importantly there are out there a shitload of colleagues who don't know or care about the latest and greatest feature.... Because they are s/w engineers, not programming hipsters.
I don't think c++ will ever recover. It will grow and grow in terms of features and also those features will become more and more irrelevant as less and less people will adopt them.
Tbh C with classes had a negative meaning 15 years ago. Now it seems like the sane way of writing good and intuitive c++ code.
Maybe it's just me.

Re:It wasn't always shit

[johannesg]

You're full of it. C++11 was a fantastic upgrade, it really improved the language.

Re:It wasn't always shit

[Anonymous Coward]

> Before c++11, c++ had great features that helped you write cleaner code.

You have it completely backwards. It's the C++11 features that help you write cleaner (and correct!) code.

C++98:

for (std::vector::const_iterator it = v.begin(); it != v.end(); ++it) { // do something with "it", usually starting with dereferencing
}

C++11:

for (auto const& x : v) { // use x directly
}

Also, the smart pointers make it possible to write code that documents itself. Before, if you saw a function that returned a pointer, you had no idea who is responsible for the ownership of the pointed-to object (better hope the documentation is correct and up-to-date). With C++11, if you see a function returning a smart pointer, you know it's a factory that is creating new objects and giving out ownership. If a function takes a smart pointer by value, you know it's a sink (it takes away ownership).

The people complaining about too many new features in C++ are usually the ones unwilling to learn.

Re:It wasn't always shit

[Xtifr]

Yup, C++11 is what stopped me from abandoning C++ entirely. In addition to the new versions of "for" and "auto", which were insanely huge improvements, there's the first-class lambdas, which eliminate most of the need for all those contrived, horrible binding and function templates which 98 relied so heavily on.

And rvalue references may look a bit confusing, but the end result is a huge performance boost (especially in the standard library) for very little cost.

C++98 was a terrible language. C++11 (and later) is turning into a halfway decent one.

Not my problem!

[Anonymous Coward]

C++ is one reason why I gave up programming and became a prostitute.

Re:Not my problem!

[Purity Of Essence]

C++ is one reason why I gave up programming and became a prostitute.

So PHP.

Re:Not my problem!

[Anonymous Coward]

Back when I worked for -Large Info Services Corp-, the brass du jour decreed a college recruitment drive, and I was one of the interviewers. They brought in a dozen new CS grads: 8 BS and 4 MS. We had a standard tech test; nothing too strenuous. 2 pages C, 1 page Unix and 1 page SQL. One code question, important to a company with lots of mainframe data: write rtrim(). Take a C string, trim the trailing spaces, return new length. A simple task. Could be done in one line if you wanted to be tricky about it.

Not one of the dozen grads could do it. Not even the Masters' grads. I wondered how you could attain a postgrad degree and not know how to do this.

A few weeks later, in a strip club in Fort Lauderdale, this big blonde sits on my lap; calls herself Margot. We chat: she's from East Europe, and she's a programmer. Really, I say, and ask her to write rtrim(). She whispers it in my ear. I offer her the job. She turns it down. Makes more doing lap dances than writing code, and didn't want to move to New Jersey. I couldn't argue.

Re:Not my problem!

[gargalatas]

If you're using php you are already a prostitute. The cheap ones!

Person hates X, invents Y

[93 Escort Wagon]

These sorts of stories come up fairly regularly here on Slashdot. And, each time they do, it reminds me of the classic XKCD:

https://xkcd.com/927/

This doesn’t just apply to no-name indie developers... the good folks at Google are some of the worst offenders in this regard.

Blow is in good company

[Man On Pink Corner]

Even Stroustrup himself has been having second thoughts about building a time machine to go back and kill his own grandmother.

https://www.theregister.co.uk/...

Re:Blow is in good company

[Raenex]

Even Stroustrup himself has been having second thoughts about building a time machine to go back and kill his own grandmother.

He said nothing like that in the article you linked. He was warning against feature creep and complexity. I've never seen an article where Bjarne expresses any regrets about creating the language.

Re:Blow is in good company

[DarenN]

He doesn't say anything like that. In fact he says

I don't regret any design decisions, but if I was designing it now I would do everything slightly differently

This is reasonable - the concepts are largely good, but some of the design decisions did not age well and the processor designs we have now make some of those decisions quaint. Other things, like being constantly under attack, were not on anyone's mind when C++ was first released

I dunno, are swords really terrible weapons?

[engineerErrant]

Of course not. If it's 10,000 BC and your opponent is wielding an antelope's femur, having a sword is an overwhelming advantage! But in modern times, that answer changes. Now, a person clearly *can* be very effective with a sword, with a lot of training. But they could be much more effective with a .38, with much less training.

C++ is kind of like the sword of programming. It occupies an important place in history that should be remembered, and in the right hands, it's still fearsome. But gimme a break - in modern times, there are just better options, in every arena of computing. Other languages offer faster learning curves, less ability to blow your foot off because you didn't know some obscure intricacy of the language, and are simpler in pretty much every conceivable way.

C++ is a relic we should regard with a certain reverence, while not taking it seriously for the future.

Re:I dunno, are swords really terrible weapons?

[110010001000]

You must be kidding. All modern system software is written in C++. You guys don't know what you are talking about.

Re:I dunno, are swords really terrible weapons?

[serviscope_minor]

C++ is kind of like the sword of programming. It occupies an important place in history that should be remembered, and in the right hands, it's still fearsome. But gimme a break - in modern times, there are just better options, in every arena of computing.

Like what? Just about everything you did to type that inane comment touched C++ multiple times and in important ways.

Rust is that beautiful language within C++

[Anonymous Coward]

Bjarne is right: there is a smaller, beautiful language within C++: it is called Rust. Mozilla has taken the best parts of C++ like its fast performance and its flexible abstractions and created the ultra-safe, ultra-productive and ultra-powerful modern programming language called Rust. While C++ will probably never go away, more and more C++ programmers are opting to use Rust instead because it is so much like C++, yet so much better at the same time.

Re:Rust is that beautiful language within C++

[Carewolf]

The fact that the Rust developers knew C++ is why they while doom to recreate it, are not recreating it too terrible. It is basically a codification of C++2014 best practices, with syntax inverted so best practices is the shortest form, and bad practices look complex, while in modern C++ it looks the opposite. The fact you don't know C++ is why you don't like Rust syntax, and probably will not be able to understand the semantics either.

Re:Rust is that beautiful language within C++

[chthon]

I thought it was D!

Re:Rust is that beautiful language within C++

[serviscope_minor]

Mozilla has taken the best parts of C++

It's still missing genericisation over integers last time I checked. That's one of the best parts of C++.

Re:Rust is that beautiful language within C++

[serviscope_minor]

The problem with Rust is that it was designed by people who actually used C++.

If they hand't it would have ended up like "go" with whiny blog posts by the creator complaining about how it's just too awesome for C++ programmers. He seemed genuinely surprised that C++ programers didn't flock to it despite the fact he freely admitted he didn't know much about C++.

Using C++ willingly is a sign ... is a sign that someone has shit to do.

Re:Rust is that beautiful language within C++

[roca]

That feature has been designed and is being implemented --- slowly, since it's not the top of the priority list for various reasons.

Re:Rust is that beautiful language within C++

[roca]

You don't abide by any code of conduct to *use* Rust. If you want to participate in certain Rust-related forums, then they have a code of conduct.

C++ is no different in this regard. CppCon for example has a code of conduct: https://cppcon.org/codeofcondu...

Re:Rust is that beautiful language within C++

[jeremyp]

You're not required to subscribe to any code of conduct if you want to use Rust. You only have to subscribe to the CoC if you re part of the Rust compiler development community.

Re:Rust is that beautiful language within C++

[sosume]

The CoC will just harm its adoptation by scaring neutral developers away. Not everyone wants to fight for perceived social causes all the time or mix their work or hobbies with politics. Rust will in time vanish in obscurity. Are you truly inclusive if you exclude everyone you disagree with?

Jai?

[thePsychologist]

Jai sounds like a vent for the frustrations of this guy who hates C++. There are no public compilers yet, and the GitHub page is an unofficial source derived from YouTube videos. Sounds like more talk than results.

Re:Jai?

[mikael]

Game programmers have always written their own scripting languages, GUI's, command line editors, art tools. They make perfect sense for the games they write in the style they code. But for anyone else, it's a mess.

Yes it is terrible

[Anonymous Coward]

I'm a javascript developer, for all the crap you guys say about my programming language, at least it works easily and gets TONS of stuff done.

The publisher of the article is spot on, its wobbly with junk and that makes it more of a problem to use than it should be.

I'm going to sit back and eat popcorn now :D

Languages kludge up over time

[Tablizer]

Well-known languages seem to collect cruft as they age. Look up and try to do reflection on C#'s nullable-types for example. Nullable types were an after-thought such that they ended up bastardizing dynamic types to implement them, making for ugly reflection. Granted, perhaps there were other ways to implement nullable types, but I'm sure those would uglify something else.

This is not your grandfather's C++

[mrsam]

Modern C++ looks nothing like C++ of the years past. C++ is a comparatively old language, it's been around for over 30 (!) years.

And for the longest time C++ was gathering dist, stagnating, and remaining basically unchanged. But an effort begun to update the language, and since 2011 in my estimation C++ is now at least three times as big, and as complex as it was before.

Folks who've been around the block for a while started getting someone shocked coming across C++ code that looked nothing like the C++ they knew. And people who attempt to start learning C++ from scratch were confronted with the entire, 100% complexity, of modern C++ right off the bat.

And that's, IMO, is where the current bad rap for C++ is coming from. It is a hard, complicated, language to learn. But it's been my experience that once I spent th effort to learn the nuts and the bolts of modern C++, I found it to be a very powerful, rich, capable language. I don't think I would've been able to write LibCXXW in 2003 C++. It would've taken me five or six times longer than it did. Modern C++ attempts, in made ways, to bring many of the benefits of other, VM-based languages like Java and Perl, and bolt them on top of a compiled framework.

Some time ago, on stackoverflow, I read a question from someone wondering why their C++ compiler was running out of memory compiling their code. I looked at it. The shown code attempted to implement Sieve Of Eratosthenes in the compiler itself. That is, the code was not trying to implement it itself, but make the C++ compiler do it, via templates, with the actual code resulting in a static array of prime numbers. And the question was why the poor compiler was running out of RAM...

Try that, with Java.

C++ appeals to lovers of complexity

[Anonymous Coward]

There's a certain kind of programmer -- most people have either met one, or are one themselves -- who gets off on mastering complex, intricate systems for their own sake. They believe that complexity implies cleverness and power. They think that if you spend decades mastering every nook and cranny of C++, then surely that mastery makes you capable of doing things that programmers using lesser languages can't do.

They are wrong: complexity is evil. At times a necessary evil, but something to be minimized at all costs. Good languages are built upon a foundation of carefully chosen, complementary, and orthogonal features. And C++ is a trash pile of a language, with every passing year and new revision of the standard, they bolt on yet another poorly thought out feature which interacts badly with what came before. All built on the shifting sands of backward compatibility with C. Now, C is not too bad by itself, but C compatibility is one of the biggest contributors to complexity and error within C++.

But that backward compatibility has allowed C++ to prosper, unfortunately, and we are stuck with it.

Re:C++ appeals to lovers of complexity

[jcr]

C is not too bad by itself,

Well, aside from its lack of strings and arrays being the cause of the vast majority of security issues for the last several decades...

-jcr

Re:C++ appeals to lovers of complexity

[Joce640k]

And minor things like there being no nice way to break out of a deeply nested set of functions, cleaning up as you go.

(eg. An unexpected end of file inside a file parser).

Re:Obcious

[Joce640k]

Nope, C++ was designed to be a practical language every step of the way.

Most of the other languages you mention really were experiments that got way out of hand, especially Pascal and Java.

ref: http://www.cs.virginia.edu/~ev...

C++ has the same issue as JavaScript

[Philotomy]

C++ and JavaScript share a common issue, in that both languages have some design problems that they carry with them, but both are popular and have layers of syntax accumulation and libraries, and both will allow you to write some terrible code.

However, if you have a firm understanding of the languages (and the pitfalls particular to each), you can also write solid and elegant code in either language. It's more a matter of avoiding their bad parts than anything else, but it requires knowledge and discipline to confine yourself to the "good" subset within each language.

Yes. Yes it is

[Snotnose]

Gave up on it a good 30 years or so ago, when templates were introduced. Suddenly no 2 compilers gave the same results. Readability? It was as bad as perl. WORA. Write Once, Run Away.

Java gets a lot of crap but damn it, C++ drives me up a wall.

Specifics?

[MichaelSmith]

Even the article doesn't have any.

Yes and no

[russotto]

Yes it's terrible, no Jai or Rust or D or any other "language of the week" isn't going to replace it. They all fail on something. D has garbage collection. Rust comes with politics and really annoying fans. C++ doesn't even have fans. Plus C++ is well-entrenched; it'll be harder to dislodge than Fortran

And yes, there is a smaller and more elegant language inside C++ screaming to get out. It's called "C".

Re:Yes and no

[Joce640k]

And yes, there is a smaller and more elegant language inside C++ screaming to get out. It's called "C".

Especially C string handling, that's really elegant.

C arrays, too. Data structures that don't know how many elements they contain are awesome! Give me more of those....

Data abstraction? A piece of elegant cake in C. Take a look at the OpenSL ES library for an example of an easy to use library written in C.

Re:Yes and no

[serviscope_minor]

And yes, there is a smaller and more elegant language inside C++ screaming to get out. It's called "C".

Yes elegant languages are full of resource leaks.

So elegant.

Re:Yes and no

[Ed Avis]

Well strictly speaking the string handling is more to do with the C standard library than the language. You could use a library providing a sensible string type, and the main restriction imposed by the language would be that literal strings cannot contain the 0 byte. It's dispiriting that after so many decades the C standard library remains stuck without a decent set of string functions. (There are plenty of libraries to choose from but the real value comes in picking one and using it everywhere; it's a social rather than a technical issue.) I read that C++'s STL also lacked a string type and some lobbying was needed to get the standards committee to define one.

Re:Yes and no

[Joce640k]

No string library written in C is going to call free() automatically for you or do any sort of stack unwinding.

In short: C simply doesn't cut it for anything large/complex.

I mean, yes you can do it, but the development time will be much longer and the code will be much uglier (eg. lack of namespaces, classes and function overloading means every function name has to be unique, ie. function names get longer and longer in proportion to program size).

Stuck with C++

[Tronster]

Almost two decades ago a I had a Thinkgeek C++ round bumper sticker on my car because I thought the language was the bees' knees. Today I'm finding myself holding my tongue in watching videos from C++Con which quickly go from 1 to 10 in terms of complexity; where only the smartest of developers can remember all of the rules and the exceptions to leverage modern day C++. I feel as if the movers and shakers of the C++ language spec have an inner social circle and have lost touch with the wider developer audience.

Having used C#, Actionscript, LUA, Python and dabbled just enough in Swift and Rust, I believe that C++ either needs to have a fundamental change to break the axiom of backwards compatibility or it will be replaced by Rust, Go, or some other (LLVM) language that has been inspired by C/C++ but has a simpler, consistent syntax made for modern day computing.

My prediction: when underlying, low-level OS components are replaced with non-C, non-C++ counterparts, that will be the beginning of a global acceptance for a new language standard. Until then there will always be a place for C/C++. I really hope this change happens in the next ten years; I'm not holding my breath though.

Re:There are no 'Really Terrible Languages', ...

[russotto]

There are no 'Really Terrible Languages', just 'Really Terrible Programmers'

In addition to C++, there's PHP, Javascript, APL, Ada, and BASIC. Off the top of my head and not including novelty languages. (Also leaving off COBOL and pre-66 FORTRAN because nobody could know better then)

Accreted, not designed.

[jcr]

Aside from the fact that C++ is a steaming pile of needless complexity, the worst thing about it is the brain damage it does to coders who become proud of memorizing the minutia of said steaming pile, believing that this is equivalent to engineering skill.

-jcr

Re:Accreted, not designed.

[Anonymous Coward]

... who become proud of memorizing the minutia of said steaming pile, believing that this is equivalent to engineering skill.

-jcr

This is a general problem in IT today. No mountain is too tall to climb, but we needlessly make them taller out of pride.

No it doesn't

[mykepredko]

While I agree with the core of your thesis that you can create good and bad code, I have to disagree from the perspective of how applications are architected.

JavaScript requires a different mindset to handle exceptions and handle/recover from errors. I find it quite difficult to make sure that code flags an error properly and doesn't continue blindly on. This is okay for a fairly simple web app (which is what it was created for) but lousy when you have an application that communicates with other systems and there can be errors in responses and response time or in unexpected events.

C++ for all it's follows more traditional execution model that allows for complex applications which communicate with other systems.

For certain values of terrible.

[AnotherBlackHat]

C++ is, IMO, terrible.

I hate that it allows polymorphism. Worse, it makes people think that polymorphism is a desirable feature that helps create clear, readable code.

It encourages the creation of functions that operate on classes instead of on generic data types.
For example, if a C++ program has a "car" class that include the elements "miles" and "gas" a C++ programmer is likely to create a function
car::calc_mpg() which requires (seemingly) no arguments, rather than the more generic calc_mpg(int miles, int gas)
The problem is, the first is not reusable, and depends heavily on knowledge of the car class.

It encourages inheritance, which fundamentally breaks the box-model (a.k.a. the black-box-model) of programming.
Rather than breaking things into discrete, understandable chunks, it encourages massive classes that must be understood in their entirety.

Then there's operator overloading, code that can be executed before main(), putting code in unexpected places... I could go on, but I think you get the idea.

The main problem is, C++ adds stuff with the unjustified expectation that more stuff automatically mean better.
Sometimes more stuff is worse.

Re:For certain values of terrible.

[Eravnrekaree]

Encapsulation is a basic feature of Object Oriented language and is thought to be a generally good thing. Bundling code and data into an object is thought to be an important leading to less of a mess.

As for Polymorphism and so on, templates etc, other languages more simply solve the problems this is trying to solve by having for instance, just one scalar data type as with Perl and several others. You can have polymorphism in Perl, actually, its just less often necessary.

Re:For certain values of terrible.

[StormReaver]

It encourages inheritance, which fundamentally breaks the box-model (a.k.a. the black-box-model) of programming.
Rather than breaking things into discrete, understandable chunks, it encourages massive classes that must be understood in their entirety.

This is the exact opposite of what a good object model looks like. Anyone who writes the way you described has a very poor understanding of OOP. See SOLID for a good introduction to good OOP.

All the basic features of C++ (inheritance, polymorphism, classes, and objects) make writing large systems MUCH easier than they would be without those features. Everything in your posting indicates a near complete lack of OOP comprehension.

Re:For certain values of terrible.

[Ichijo]

I agree with both of you. C++ encourages bad habits, and the SOLID principles attempt to solve them. It would be good if the C++ language itself enforced those principles better. Otherwise we are forced to depend on programming classes to teach SOLID, and they don't even teach const-correctness so it seems hopeless without official language support.

Re:For certain values of terrible.

[AnotherBlackHat]

Anyone who writes the way you described has a very poor understanding of OOP.

No TRUE C++ programmer would ever program that way, eh?

All the basic features of C++ (inheritance, polymorphism, classes, and objects) make writing large systems MUCH easier than they would be without those features.

I've seen this kind of claim many times - and yet, the evidence is that C++ programs aren't any better that ADA, or even FORTRAN when it comes to writing large systems.

Classes only help when they're built correctly, and C++ encourages lazy people to create them poorly.

GOTO didn't force people to write spaghetti code, but that's what actually happened.

Sure, you can write good code in C++, but what is there in the actual language that encourages it?

Re:For certain values of terrible.

[munch117]

For example, if a C++ program has a "car" class that include the elements "miles" and "gas" a C++ programmer is likely to create a function car::calc_mpg() which requires (seemingly) no arguments, rather than the more generic calc_mpg(int miles, int gas) The problem is, the first is not reusable, and depends heavily on knowledge of the car class.

That's a legitimate complaint ... against Java and C#.
Perhaps you have encountered too many C++ programmers who were originally taught using Java?

Re:For certain values of terrible.

[tomxor]

It encourages inheritance, which fundamentally breaks the box-model (a.k.a. the black-box-model) of programming. Rather than breaking things into discrete, understandable chunks, it encourages massive classes that must be understood in their entirety.

I don't know any C++ (and I don't like the sound of it), but I see this same problem in JavaScript albeit in the form of prototypes (Prototypes can be used for pretty much the same purpose, and usually are, although since ES6 there are not "proper" classes).

I haven't travelled wide and far in the programming space, but I have a suspicion that people give too much credit to the "class" pattern because many languages have adopted it into it's syntax, I myself was like this for a while when younger, using classes for everything is easy - until it makes a mess that even the author can't track, now I actively try to avoid it, and find that it's completely inappropriate 95% of the time, for the other 5% things like vectors etc it's a perfect fit, and that's fine. So I suppose in summary it's people using the wrong tool for the wrong job too often, C++ sounds like it provides too many tools, and so it's inevitably going to breed bad code as people are more likely to missus them.

Re:For certain values of terrible.

[tomxor]

that was supposed to be "there are now proper classes" not "not"

Re:For certain values of terrible.

[serviscope_minor]

C++ sounds like it provides too many tools, and so it's inevitably going to breed bad code as people are more likely to missus them.

It's lines like that that sometimes really highlight the gulf between programmers and engineers.

"We should get rid of the surface grinder because having it available will only encourage people to misuse it" said no engineer ever.

Re:For certain values of terrible.

[dwpro]

That seems like a fine policy for a simple function, but at some point the number of parameters gets unweildy, leads to much repetition, and is error prone. Something like a class method is unavoidable.

Re:For certain values of terrible.

[phantomfive]

Pretty near every language allows polymorphism these days.

Re:For certain values of terrible.

[tomxor]

Your analogy doesn't really make any sense unless a surface grinder performs a redundant job among a collection of tools and is more trouble than it's worth. This is not about engineering it's closer to the psychology of UX in language design.

Re:Does Crystal have a strong backer like Rust has

[jcr]

Mozilla, one of Silicon Valley's greatest success stories

You're funny.

-jcvr

Re: Yes it is, Java is the answer

[chaboud]

I dunno. I feel the need to correct a couple of misrepresentations in that post.

He seems pretty genuine to me.

Re:Obcious

[K. S. Kyosuke]

Another ridiculous argument since by the time BWK wrote that book, Wirthian languages had already hit Modula-2 and were well on their way to Modula-3 and Oberon. That's like arguing that you shouldn't use Fortran by pointing out the deficiencies of Fortran 77.

Re: Greenspun's tenth rule

[K. S. Kyosuke]

and a community that's too academic to care about the needs of real-world programmers

I think you meant Scheme. Common Lisp is industrial, non academic. Anyway, for C++ lovers, the benefits of CL is that it is in places as dirty and ugly as C++. ;)

Re:Obcious

[jcr]

Nope, C++ wasn't designed at all: it was accreted.

-jcr

Re:Yes it is, Java is the answer

[mikael]

Dang! Our embedded systems only have 2 Gigabytes of memory and 512Mbytes is reserved for the OS and display memory.

An exaggeration of a pretentious developer

[SoulForMachine]

Creating a new language is hard, but getting people to use it is even harder, even if it is pushed by a corporation. Blow seems to fail to understand that language adoption is not just about syntax and paradigms but also ecosystem and libraries. You need people willing to make libraries for the new language so that even more people get interested in using it for their projects. This could take a decade or more. As far as I know he is working on that language by himself, or is there a community or at least some other contributors? Blow is a guy who writes his game engines from scratch and it seems that he wants to make a language that would suit his own needs, but even if other small developers like it most of them would still need 3rd party libraries to be able to use it for their projects.

Of course, C++ isn't a "really terrible language", it is an industry language used in big projects where performance is paramount and has been around for a long time. It has a lot of flaws but people use it because it's portable and has a huge number of libraries available. You cannot just replace it with a new better language because of all the legacy code, so the C++ standard committee is trying to improve it by modernizing it, expanding the standard library and deprecating features while maintaining backward compatibility. Whether this process is going in the right direction can be questioned, though.

Re:An exaggeration of a pretentious developer

[gman003]

Blow does not care that his language sees wide adoption. The only user it *needs* to satisfy is himself - if nobody else uses it, that's their problem, not is. He's not trying to kill C++, he's trying to leave it. As a bizarrely wealthy*, completely independent developer, he's in a position to do that.

As a completely independent dev, I am watching Jai with interest. C++ is a bad language - it makes things that ought to be easy, very difficult, and things that ought to be difficult, easy. I am looking at several other C++ replacements, particularly Rust, but Jai looks the most appealing to me.

You are correct with regards to the larger industry - companies with large existing codebases cannot simply rewrite everything on a whim, and the C++ committee is limited in how much they can improve, because they cannot break backwards compatibility. But that is no reason why new projects must be in C++, nor why new languages cannot succeed.

* I have played both Braid and The Witness. They were okay. A bit hollowly pretentious. I don't see why they're put on such high pedestals, or how they earned him so much money. I don't begrudge him his success, but I am a bit mystified by it.

Re:An exaggeration of a pretentious developer

[SoulForMachine]

Blow does not care that his language sees wide adoption. The only user it *needs* to satisfy is himself.

He certainly is developing the language in that manner, but he is rooting for a wider adoption if nothing just for vanity's sake.

I understand that Rust can be a viable replacement for some people because it has libraries available (it is pushed by a company), but languages like Jai still need a long way to go before anyone can actually use it. The crankish circumstances under which it is developed do not promise good chances of this happening.

C++ is bad regarding many things, but it is not that bad. It is mostly hated for it's complexity and letting you do anything you want. But especially if you are an independent developer, you are not forced to use things you don't want to, and language giving you full control is a positive thing (at least in my opinion) in contrast to strictness of Rust. I myself wish there is a better language, but the amount of libraries available to me and years of experience with the language make me stick to it.

Re:Does Crystal have a strong backer like Rust has

[El Cubano]

Mozilla, one of Silicon Valley's greatest success stories

You're funny.

If you are not aware of the history, then it might seem somewhat humorous to consider them a great success story. However, Mozilla came out of the wreck that sank Netscape. As the WWW was fast becoming important to both businesses and the general public, they decided to stop rewrite their entire application. This strategic error allowed Microsoft completely dominate the WWW for the better part of a decade (go read Spolsky's Things You Should Never Do postings for a very insightful analysis of the whole thing). Recall the Use IE for best experience with this site and other such things that were common until even a few years ago.

Mozilla came from that, clawed their way back into the fight and today they are driver for practically every useful and interesting privacy-oriented feature in just about every web browser. Either because they first implemented or because the popularized it.

I cannot think of another company (Mozilla has both a non-profit arm and a for-profit corporation under the same umbrella) that has managed to rise from the ashes after being pulverized by Microsoft in the way that they (or really their predecessors) were.

I rememberâ¦

[Dixie_Flatline]

So around 15 years ago, when I was starting my career in the games industry, there was a post here on slashdot about how someone had finally proven that the language did not have a bad recursion in it. In the comments was a programmer who I think may have been working at Microsoft talking about how every compiler programmer would go into writing a C++ compiler excited to be the first one that implemented the full language specification and having the Hope slowly beaten out of them, until they finally arrived on a sufficient compromise. And so compilers would all implement their own specific subset of the language and there was virtually no cross compatibility.

So the language started as an unimplementable mess of a spec, and unless someone has been doing some very hard work to make the language LESS complex, I greatly suspect that it has stayed that way, despite the smattering of quality of life upgrades that have been thrown to us.

In my mind, the greatest sin will always be template metaprogramming, a discoveredâ"not plannedâ"feature that was the consequence of a problem that should not have existed in the first place. They planned poorly in the beginning, threw some more bad planning on top, and ended up with a monumental clusterfuck that will be obfuscating codebases until the end of time.

tl;dr Yes, goddamnit.

Re:I rememberâ¦

[JustNiz]

G++ is and always has been the gold standard. I could be wrong but I'm pretty sure it has always implemented the full language spec.
Of course Microsoft would blame the language rather then their own lack of capability. The truth is that everything they've ever turned out has always been a fucked up piece of shit, and opensource community stuff has always showed their products up.

Re:I rememberâ¦

[mikael]

Read the developer forums. Developers now are stlll demand that the compiler developers provide a full C++99 implementation, instead of cherry picking the C++17 and C++19 features that seem the most sexy.

https://en.wikipedia.org/wiki/...
"Historically, Microsoft has been slow to implement new C features in their Visual C++ tools, instead focusing mainly on supporting developments in the C++ standards.[12] However, with the introduction of Visual C++ 2013 Microsoft implemented a limited subset of C99, which was expanded in Visual C++ 2015.[13]"

Re:I rememberâ¦

[JustNiz]

I stopped taking any jobs that were Microsoft-based back in the early 90's, but I believe the Microsoft C compiler/C-library is still not even POSIX-compliant.

Simplicity vs Brevity

[stevestyle]

I used to code on Delphi, based on Pascal, but also did some C++. The main difference I found was that if I made an error in Delphi the compiler found it and the big fix cycle was a few seconds. In C++ the compiler would find a way to interpret my code (as something I hadn't intended) and I would only find the error in unit test, with a big fix cycle of minutes. The benefit of C++ was that you could do ten things in one line. So Delphi was simpler and more verbose, C++ was briefer. But coding in Delphi was an order of magnitude faster.

Re:Simplicity vs Brevity

[DomenVrankar]

Probably depends on the version of Delphi and the features that you've used. From my experience Delphi is as error prone as C but more verbose when things go wrong and if you mix interfaces and the rest of the language it takes quite a while before you figure out why your objects are destroyed... So as far as error prone Dephi takes the lead and once you see the additions over the years you start to appreciate the amount of consistency goes into extending C++ compared to languages such as Delphi where they do the Java style "I have an idea, let's put it in without considering the rest of the language" language development. From my experience programming in Delphi is faster due to compile times but also far more error prone specially when compared to newer versions of C++.

Too hard to do simple things

[Eravnrekaree]

The problem with C++ is things which should be simple are complex, not that there are too many features. With Perl or Python, if you want to create a variable and stuff data into it, its very easy to do, syntax is very straightfoward, like my $var="hello"; $var="hello2"; The variable automatically allocates memory, resizes as needed, and is reference counted so there is never a hanging pointer . Want a dictionary? In perl, its my %hash=(key1=>"value1"); Hash allocated nice and easy, automatically resizes as needed. How to do that in C++? The syntax is more complex and convoluted. In Perl or Python, the simple is easy, the hard is possible, there are a lot of advanced features but you don't need to use complex syntax to do the simple stuff.

Re:Too hard to do simple things

[toonces33]

It is funny - I find perl syntax hopelessly arcane, and then throw in the kitchen sink in the form of a bunch of extensions.

C++ is simple and easy by comparison.

Re:Too hard to do simple things

[SpinyNorman]

It sounds like you're talking about C++ pre-2011 ..

If your writing modern C++ and find yourself allocating or freeing memory (other than in exceptional circumstances), then you are doing something wrong.

The STL, and more generally RAII principle, is based on classes that internally allocate memory (RAII => aquire resources) as needed and automatically free them in the destructor.

e.g.
To create a list of strings:

std::list var;
var.push_back("hello");
var.push_back("world");

When the var goes out of scope the memory will be freed automatically.

For a dictionary (called a map in the STL):

std::map names;
names["cat"] = "foo";
names["dog"] = "bar";

And this works for arbitrary types of keys and values with no user need to allocate or deallocate memory, or worry about how big the map is.

If you want reference-count rather than scope-based destruction, then use a shared pointer:

std::shared_ptr p1 = std::make_shared("value");
auto p2 = p1; // create additional reference

Now when all reference are destroyed, the underlying (in this case std::string) variable will be automatically destroyed and memory freed.

C++ has grown to be very complex, especially if you are doing generic template programming - typically writing frameworks or libraries rather than applications, but I'd say it also to adheres to the "simple is easy, hard is possible" paradigm.

Re:Too hard to do simple things

[SpinyNorman]

oops - should have proof-read that:

std::shared_ptr p1 = std::make_shared("value");

Incidently, if you want to iterate over any of the STL containers (or your own cistom containers for that matter), it's as simple as:

for (auto s : var) {
    std::cout s "\n";
}

For the map (dictionary):

for (auto p : names) {
    std::cout "key: " p.first "\n";
    std::cout "value: " p.second "\n";
}

The reason for the "first" and "second" is because std::map is based on std::pair which uses those names.

Re:Too hard to do simple things

[SpinyNorman]

OK, so slashdot HTML markup is eating my std::shared_ptr definition: std::shared_ptr<std::string>

Re:Too hard to do simple things

[EmperorOfCanada]

100% agree. But the template programming has become a huge problem. I am seeing people on stack overflow and others at conferences who are even initializing basic data types like they were some kind of complex beast. Templates have their place and it is only in the darkest corners of libraries.

Here is a perfect example of this academic nonsense:

int z={3} or int z(3). WTF. There are complete bozos suggesting this is the now "correct" way to init a variable. Yes that is a great idea. Let's make C++ less clear to someone coming from another language or basic human understanding. This is increasing job security or showing off their huge intellects, pure and simple. These nitwits completely miss the point that programming is to produce a quality product for the end user. Not an academic exercise. If the product takes longer, has more bugs, or is harder to maintain then your methodology is wrong.

Re:Too hard to do simple things

[phantomfive]

I used to wonder about this kind of phenomenon, which is present in all language communities. Of course code written for a library should be different than other code, it has different requirements.

I realized a lot of people learn their programming skill from looking at library APIs, because that's the only other code they look at. The way to learn programming is by looking at other code, and they only look at the code of APIs.

Re:Yes - Bless You

[NReitzel]

When one hires chimpanzees to write code, one gets code written by chimpanzees. No language tool will make up for lack of understanding. The more flexible a tool, the easier it is to write code that is simply horrid. To turn around and blame the language is disingenuous at best and at worst, promulgates the idea that good code is easy and within the grasp of just any old person.

Anyone can play a scale on a piano. Anyone can figure out what the notes on the music mean. That does not mean that anyone can play Frédéric Chopin's Minute Waltz. More to the point, a "better" piano won't fix this.

Re:Yes - Bless You

[Anonymous Brave Guy]

Anyone can play a scale on a piano. Anyone can figure out what the notes on the music mean. That does not mean that anyone can play Frédéric Chopin's Minute Waltz. More to the point, a "better" piano won't fix this.

Perhaps not, but I'd rather listen to a professional concert pianist play the Minute Waltz on a Steinway grand than a 1980s synthesizer.

Re:Does Crystal have a strong backer like Rust has

[Bruce Perens]

Consider what Linux was at the start, and what it is now. That's how Open Source works. I think the quality of the language will assure its growth, as Linux grew from the hobby project of a pimply computer science lecturer at a Helsinki college whose wife is much more macho than him (she's a martial arts champ), to the OS behind an industry. It happens there is a company behind the Crystal developers. But they are a small team, and they collect money donations from the public.

Re:Yes - Bless You

[dgatwood]

Yeah, as I always have said:

• The nice thing about making programming easy is that any idiot can write software.
• The bad thing about making programming easy is that any idiot can write software.

A good craftsperson does not blame the tools — not because you could hand that person terrible tools and get the same results as with great tools, but rather because the person would know what various tools do well, and would find ways to work within their limitations to create something good.

The same is true for programming languages. Different languages are good at different things. I'd rather smash my head repeatedly with a ball-peen hammer than deal with giant steaming piles of templates, but stick embedded C++ in the kernel without all that STL baggage or exception handling or multiple inheritance or RTTI or any of the other junk that makes the C++ runtime so bloated, and you end up with a halfway decent language for writing device driver stacks.

Need to use piles of regular expressions for some reason? Perl.

Need a lightweight template-based web backend language for a small-ish website? PHP.

Need a language for writing client code? Objective-C.

Need a language for writing enterprise-scale server code? Java.

Need a language for full-stack development by a single development team? Javascript, but don't do that. Really. Don't do that.

And so on.

Benchmarks

[Bruce Perens]

This is one try at comparing many languages at different benchmarks. Crystal is still in development, but it's based on the LLVM compiler, which of course also compiles C. I think they're still going for functionality, rather than optimization.

Not Horrible, Just Mature

[Roger W Moore]

C++ is horrible. Just stating the obvious.

It's not horrible it is just mature. Good languages, like C++, start off with a very clear syntax that greatly simplifies some important programming tasks. As people get more familiar with the language they identify new programming patterns which the language cannot handle well and so new syntax or features are added leading to bloat.

C++ has been around for a while and has had lots of new things added to it making it a mature language. At some point, someone will come up with a new, general purpose language that incorporates many of the advantages of C++ in a coherent syntax and which is useful for lots of people and not aimed at just developing just games, or web, or any other specialized function and then the cycle will repeat.

Re:Not Horrible, Just Mature

[Purity Of Essence]

That's what Jon Blow is doing. He's aiming at game developers because game developers demand speed and efficiency and it would be good to have a lean, robust language that enables fast iteration, reduces errors with simple unified syntax, gracefully transforms data sets, and doesn't hold your hand wasting your cycles and memory..It's a high-performance general purpose language for competent programmers who know what they are doing.

Re:Not Horrible, Just Mature

[Roger W Moore]

Yes, but my point is that languages aimed at niche applications are unlikely to succeed in developing a critical mass of developers. You need a broad-based replacement that everyone finds significantly better than the language it replaces. It's not just that niche languages may not address others' problems there is a psychological effect too: a "games development language" is going to have significant barriers to being adopted by serious businesses. You should have seen the raised eyebrows a colleague of mine got from administrators when he was purchasing several cheap "gamer" GPU cards to run photon tracking algorithms for a large international physics experiment! The fact that each card came with a "free game" did not help!

What was the history

[AHuxley]

BASIC on a chip that got sold with a computer? Slow and it often faced low hardware memory.
Try some POKE?
Go for assembly?
C++ let a smart generation escape limitations and work on really great code.
That was fast and allowed the USA export code that a world of computer users needed and would pay for.

A code that was faster, let people try new things and that they could give away, sell. Their software sold well and with skills could really work well.
C++ made code fast and gave more freedoms to try things to smart people with advanced skills.

Re:Obcious

[theweatherelectric]

especially Pascal

"Why Pascal is Not My Favorite Programming Language" was written in 1981 and the criticisms are out of date. Pascal has moved on since then. Try FreePascal (with Lazarus) or try Delphi.

Umm......Why?

[gerald.edward.butler]

> ry that, with Java.

Why? You just said how terrible was the result.

Re: Does Crystal have a strong backer like Rust ha

[Bruce Perens]

Hey, you have to congratulate me for never even once mentioning WORLD DOMINATION.

I keep hearing this...

[gerald.edward.butler]

> Rust comes with politics and really annoying fans

1. Replace Rust with anything (not just any programming language) and the statement is equally true
2. I still find it to be the most interesting "new" language out there that is the only real competitor for the space the C++ currently fills with the "right" design to exploit future hw architectures where an emphasis on parallel and concurrent computation is important

Re:Yes - Bless You

[geoskd]

Need a language for writing enterprise-scale server code? Java.

It's funny that you expressed the opinion that people should not write fullstack purely in Javascript, but were OK with writing enterprise scale software in Java. Java is a decent language if you have more compute power than you really need, but not enough to run Python. If you are writing enterprise scale code in Java, then you are wasting a lot of compute power. The point of Java was not to make performant code easier to write, but to make code more maintainable. Any competent C++ developer can get you both performant and maintainable code. The secret really is in the template meta-programming. It allows you to do high performance things that simply can't be done in any other language, including C. I can beat the performance of any implementation in Java, using C++, by at least 25%.

A prime example of why I can do that is garbage collection. If you implement a linked list in Java or C++, as each node is created, it will have memory allocated for it from the heap. When you are done with the list, each node must then be freed. With a million nodes, that is a million memory allocations and a million frees. Using custom allocators in C++, I can avoid all of those allocations and frees, and use a single memory pool for all of the objects. This requires extra effort, but fundamentally cannot work with Garbage Collection, so in Java, you simply can't create an implementation that can compete. This is just an example of one of the many ways in which Java ties the developers hands in ways that guarantee sub-optimal performance.

All the things that people complain about being too complicated or "dangerous" in C++ are the very things that give the developers the power to write software that doesn't suck. In all, if a programmer doesn't understand the complexities of C++, then I would argue that they don't understand the complexities of programming for performance, because the first derives directly from the second, and if you fully appreciate programming for performance, then all of the mysteries of C++ will be open to you.

Re:Well to answer his question...

[AHuxley]

AC re "If you find it difficult to program in .... as opposed to other languages"

Never create something new that does not need more advanced study.
Educational software to create code attempted to help every user code in many different ways. Fro free on a new computer. It was disruptive to the way software was sold and who could be supported.
Keeping things complex keeps well paying jobs for the smart people.

Want to make and publish a game globally?
Bring in art, music, an author for the story on full wages. Get published by an existing nations entertainment brand. The smart people get good jobs doing code and existing publishers pay them well for a new game.
Who wants someone new able to write all the game and sell it to what was computers with BASIC? Using a new publisher and getting nation wide profits?
Never create tools to make your profession free.

STL & Boost

[jklappenbach]

As far as I'm concerned, the language went off a cliff when it started incorporating elements of STL in its basic definitions. One good example of this is the ranged for loop, introduced in C++11, which requires iterators that conform to APIs established in the STL. IIRC, these are statically bound to the for operator, which prevents developers from leveraging inheritance and polymorphism when designing their own iterators.

STL was a great improvement in its day, but I haven't been a fan for years, nor for Boost. Both are often cryptically written, poorly documented, and overly abstracted compared to modern frameworks. But, instead of improving on these standards with lessons learned from more recent efforts with languages and development kits, the C++ standards committee has doubled down on antiquity.

I haven't looked back.

Re:STL & Boost

[coolsnowmen]

I came here to post the exact opposite of everything you said haha. Well, to each their own,

Re:Blow knows jack shit

[Purity Of Essence]

He cut his teeth on 6809 and 6502.

Re:Firefox is starting to use Rust

[Ultra64]

I doubt it.

Linus Torvalds:

I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations.

To anyone who wants to build their own kernel from scratch, I can just wish them luck. It's a huge project, and I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting), and anybody who thinks that the choice of language simplifies those things a lot is likely to be very disappointed.

C++ is fine as long as...

[JustNiz]

C++ is fine as long as you stay at a feature level before C++11 and don't use STL (well maybe simple use of containers like string a vector are OK but definately stop there).

Re:C++ is fine as long as...

[JustNiz]

STL does not equal C++. Its perfectly easy to use C++ without going overboard on STL.
Have you ever tried debugging template-heavy code? It can easily get somewhere between insane and impossible.
I've already written my own library of objects for all that stuff you mention, with not a template in sight.

Re:C++ is fine as long as...

[DomenVrankar]

Now that's what I'd call a poor advice. I always prefer the latest version of C++ and didn't even notice how much the language has changed for the better until I was forced to switch back to C++98 for one half a year project (IBM compiler restrictions on AIX at that point in time) - at that point I really started to appreciate the upgrades that the language received. Same goes for the STL (from standard algorithms to standard containers) so when I read your comment I start wondering why some people stopped using goto for all the branching and looping and started to use that if/for madness??? Change must be a terrible plague for some people.

Re:C++ is fine as long as...

[JustNiz]

C++ != STL

Debugging with GDB code that makes heavy use of templates is a friking nightmare.

Re:Yes - Bless You

[dgatwood]

It's funny that you expressed the opinion that people should not write fullstack purely in Javascript, but were OK with writing enterprise scale software in Java.

My objection is more to do with trying to do multiple disparate types of programming in the same language than with JS as a language or its performance. Performance-wise, compiled JS is pretty good these days.

It's funny that you expressed the opinion that people should not write fullstack purely in Javascript, but were OK with writing enterprise scale software in Java. Java is a decent language if you have more compute power than you really need, but not enough to run Python.

LOL. To some degree, yes. Like scripting languages, Java has some nice advantages in terms of not caring whether you're running on x86-64 or POWER10 or ARM. If you're deploying across a heterogeneous server fleet, this can be a significant advantage. That said, whether it outweighs the performance penalty is certainly debatable.

But the main reason for picking Java is that a lot of CS programs teach Java as their main programming language. This makes it somewhat easier to find large numbers of junior-grade programmers with CS degrees who know Java than Python.

Re:Does Crystal have a strong backer like Rust has

[Waccoon]

Let me put it this way...

Their documentation is organized like a slideshow. Pass.

Aside from Hello World, their other simple example shows how to set up an HTTP server. Everything in the 7-line example is obvious and explained in detail, except for the weird part "do |context|". You have to sift through considerable amounts of documentation to figure out what the hell that does. Why gloss over the only interesting/confusing thing in the example? Pass.

Here we have some people developing a programming language, and their web page directly downloads jQuery from a 3rd-party site, rather than hosting the library locally. LOL... pass.

Until it's on the internet

[raymorris]

> programming isn't some inherently dangerous activity that only those who get special schooling should be able to approach it. It's like any other home utility

If you're writing a utility to use on your own desktop, sure. Code up your own crappy hex to binary converter - no problem with that.

As soon as the code is exposed to the internet, the situation completely changes. Code that is part of a web application or anything else reachable via the internet will be attacked multiple times per day. It must be designed and coded with attacks in mind. When it's not, it results in another headline "Acme Corp leaks 10 million customer records".

I feel for newer programmers trying to learn today. In my first five years of programming, I wasn't qualified to write secure internet-accessible code. That's hard to do, because attackers constantly scan for code with weaknesses. These days, it seems most code connects to the internet. That's not a safe place to learn.

Re:Until it's on the internet

[phantomfive]

If you're writing a utility to use on your own desktop, sure. Code up your own crappy hex to binary converter - no problem with that. As soon as the code is exposed to the internet, the situation completely changes. Code that is part of a web application or anything else reachable via the internet will be attacked multiple times per day

I want to point out that not only are you correct, but if the "hex to binary converter" opens files that come from over the internet, it becomes yet another potential attack vector.

Re:Worth repeating..

[Z00L00K]

You haven't seen NORD PL then.

C++ is one of the languages I left behind

[gweihir]

Learned it, was appalled by the shockingly bad and complex design (I learned C and Eiffel before, among others) and decided to use this mess only when there was no other choice. To be fair, the "crap for the masses" (Java) is not really any better.

These days I use Python with embedded C modules for larger things or plain C or Perl or Python for smaller things.

Re:C++ is one of the languages I left behind

[mohsel]

Same here.
I found Python/C to be the most efficient, reasonable, flexible solution. sometimes by binding one in another, sometimes one of of them for prototyping and quick implementation before translation into the other.

Re:C++ is one of the languages I left behind

[gweihir]

Indeed. Works very well as soon as you understand how to write Python classes in C.

The other thing I am currently investigating is embedding Lua in C for limited scripting capabilities. This seems to be extremely easy. It comes with some limitations, for example limited pattern-matching, i.e. no PCRE (can be retrofitted with some effort though).

Re:C++ is one of the languages I left behind

[DomenVrankar]

I went a different route and wrote my own visual scripting (Unreal engine 4 style but more limited) for my latest project that spits out C++ and compiles entire levels as shared libraries. Compile times are a bit longer but compared to bothering with bindings, garbage collection, additional dependencies and languages it outweighs the alternative big time as far as I'm concerned.
Also I wouldn't say that a half baked language such as Java is any better... From where I stand it's far worse and the worst thing is that Java programmers come to C++ thinking that similarity in syntax makes them a language expert, sprinkle new and delete all over your code making it unmaintainable and then blame the language "escape hatch" feature for being a poor excuse for a language while not even understanding the basics of RAII...
Also I could be wrong but from my experience programmers that know C before C++ are right behind Java programmers as far as abusing language features goes so either I've had a lot of bad luck with C programmers in the past or learning C before C++ is indeed more a handicap than a benefit when learning and using C++.

Re:C++ is one of the languages I left behind

[gweihir]

You probably have C coders that do not understand OO and then fail to use C++ OO right (well, as far as that is possible anyways).

Re:Blow knows jack shit

[Khyber]

And yet he's complaining about C++? He's lost his fucking mind, then. I'm also pretty sure what he learned back then ain't going to help him much on x86-64.

What language is Jai coded in?

"jai is an exciting"

Nope, marketing off the bat on the main page. When your first sentence starts with marketing speak, I'm 100% sure you're going to deliver a horrible product.

Re:Obcious

[AncalagonTotof]

False. Java is worse : it doesn't have multiple inheritance.

Pascal? Now wait a minute ...

[vrassoc]

You're welcome to relegate Pascal to the equivalent bin as COBOL, when there is another language that offers what Free Pascal and its corresponding Lazarus IDE offer: cross-platform RAD resulting in lightning fast native executables on more platforms than any other development solution that I know of - all of it at no cost.

How to organize programs

[Bruce Perens]

That was a really strange book. In the first edition, he was selling Eiffel, which was made by his own company. In the second edition, due I guess to criticism, he continued to use Eiffel to write the examples, but never named the language he was using until the last word of the book, and various anagrams including the first letters of the title of the final chapter and the first letters of a series of consecutive chapters.

There is still lots of language research going on, and as a result closures are accepted in a number of productive modern languages, type inference and global optimization are seen more often, and there is a lot of work on functional programming because of the fact that it's the only sort we can prove.

Re: How to organize programs

[phantomfive]

Yeah, all the different type systems. Those are cool, I admit, but they're mainly aimed at code correctness rather than code organization. Btw.I have no problem getting rid of dynamic linking, at this point even in the worst case of the program being an extra G or two to download, no one is going to notice.

C is Assembler 2.0, C++ is Assembler 3.0

[Qbertino]

No doubt, C and C++ are a messy hodgepodge of PLs. Historically grown over 30+ years and quite a boast mix of tools and concepts. Truth is, we know more about PLs today than we did back then, hence Kotlin, Go and Rust.

However, you have to see a PL in its historic purpose, and for that c++ is pretty neat. Especially C++ 14 GSL and newer. Yeah you can do lots of crazy shit with C++ that will trip you up, but that doesn't mean you have to. If you don't know what you're doing, don't do it. C languages (excluding c#) are little more than updates to assembler. If you don't know the background of c++ you are bound to screw things up. That's not a bad thing per se.

I personally think C++ is pretty neat and it basically was the first of modern non-trivial PLs that built some awesome stuff. I won't learn it anymore since Rust seems more sophisticated to me.

Re:C is Assembler 2.0, C++ is Assembler 3.0

[serviscope_minor]

Truth is, we know more about PLs today than we did back then, hence Kotlin, Go and Rust.

I think for go that's a bit of a stretch. It pretty much feels like a throwback to the 70s.

What's wrong with pascal

[lucasnate1]

Why is COBOL and C++ compared with Pascal? The first are languages with problems that were once popular and are now legacy with plenty of good positions. Pascal existed mostly in schools.

Re:What's wrong with pascal

[bidule]

Well, Macintosh were initially programmed in Pascal. At least is was "once popular" even if there's no legacy left.

Re:What's wrong with pascal

[angel'o'sphere]

Pascal, like basically any other language, was once the most used programming language on the planet.
E.g. everything around UCSD Pascal, later Turbo Pascal, then Apple/Mac Pascal, Delphi (yes, that is Pascal) and Embercardo, the actual Delphi Pascal.

Re:What's wrong with pascal

[lucasnate1]

Ok, in that case, here's something I do not get. Pascal was created after C, why did it die (not completely, but mostly) before it?

[Ok, in diesem Fall, ist hier etwas, was ich nicht verstehe. Pascal nach C wurde erstellt, warum hat es davor gestorben?]

Re:What's wrong with pascal

[angel'o'sphere]

Actually it is not really dead, as we still have Delphi/Embecado and http://freepascal.org/ (portable across many platforms)

I guess the reason of its decline is that e.g. Borland, which was big in Pascal, emphasized more on C++ and IDEs and bought a CASE company. Microsoft itself never was big in Pascal but focused on MFC. Apple switched from Pascal to C++ and then swiftly to Objective C.

For me "object oriented" Pascal always felt more like a hack than a sound object system. C++ is simply much more powerful, with operator overloading, multiple inheritance and templates.

In the late 1980s and early 1990s folks tried to promote Ada and Eiffel as new languages (they look a bit similar to Pascal on the first glance, Ada more than Eiffel) but both failed because they thought "programming languages" are "a product", and both started with incredible expensive compilers/IDEs.

And around 1995 Java came, and a few years later C# and .Net.

Re:What's wrong with pascal

[lucasnate1]

C++ is simply much more powerful, with operator overloading, multiple inheritance and templates

Aren't these exactly the reasons why C++ is LOSING ground today? It's weird how the world changes.

Re:What's wrong with pascal

[angel'o'sphere]

I think C++ is losing ground for various other reasons:
o Static compiled, long chain of included header files.
o steep learning curve, probably coming form C makes it even harder
o lack of a standard portable GUI library, well we have Qt, which is half commercial half OSS
o much more typing for simple things than in Java
o Smart pointers, that don't shield you from knowing what pointers actually are (and how they work)
o weak support for unicode/strings different than char*
o no reflection, which means no serialization
o no VM, which means no load time or compile time byte code weaving, which means no aspect oriented programming or similar things (Yes, there is an aspect oriented extension/tool chain based on LLVM)
o still no working cross linking of object files compiled by different compilers (on the same platform, don't even want to think about cross platform)
o no remote function/method calls, unless you switch to CORBA and good bye to multiple inheritance then

It's all about context

[grahamtriggs]

C++ is a very good language. But it's not a good choice for many circumstances. Use it where it makes sense, don't use it where it doesn't.

Re: I remember

[Dixie_Flatline]

No, you donâ(TM)t understand. When I say it had newly been proven that there was no catastrophic recursion in the grammar, I mean that until that point, nobody had proven it was even technically possible to implement the full spec. It was an open question as to whether the language was just fundamentally flawed in its definition.

Opinions...

[croftj]

Opinions are like assholes, we all have one and they all stink. Who gives a rat's ass about what this guy thinks, unless you want to make C++ better, or you think like him and have your favorite language that is not C++ you wish everything is written in.

Re:Obcious

[Joce640k]

I'm not sure about the word "kludge" but yes, compatibility with C is both what made C++ successful and where most of the warts came from.

But most of those complaints are only syntax. You can get used to any syntax. The real problems in programming languages come when they're too limited and don't allow you to express your ideas in code. That's when the real kludges are created - when some legacy app hits a brick wall and goes into a downward spiral of bad code due to limitations of the language. I've not seen it happen in C++.

(mostly because the people behind C++ were computer scientists, not a bunch of hackerclowns, eg. PHP)

Re:Yes - Bless You

[Joce640k]

Java has some nice advantages in terms of not caring whether you're running on x86-64 or POWER10 or ARM.

Neither does C++.

ITGLWATCDR

[Hognoxious]

The disadvantage of doing maintenance is that all other developers are utter idiots who do it wrong on purpose. The advantage of doing maintenance is it exposes you to things you wouldn't have used yourself if you were developing it.

Once in a while, you might even come across something that's useful.

Re:Yes - Bless You

[Joce640k]

Performance-wise, compiled JS is pretty good these days.

True, but:
a) To get that performance you have to try and program using as few dynamic features as possible.

b) The expressiveness of the language is terrible: Inheritance and code-re-use is non-existent ("prototype"? LOL!), building proper data structures in Javascript is impossible, at the end of the day everything devolves to closures and there's nothing maintainable or readable about that.

Go search for "douglas crockford javascript" on youtube and see how many knots he ties the language in towards the end. He keeps using the word "elegant" but it's not true.

Re: Yes - Bless You

[Bing Tsher E]

So what that it takes 10,000 times more cycles to complete the task. Customers are used to buying more hardware any time we write more code.

Re: Yes - Bless You

[Bing Tsher E]

There was a complete Objective-C toolchain available as an installable package with Slackware 95.

Re:Should have left C alone

[ledow]

Yep, I want C-with-knobs-on, not C++.

It went too far, too abstract, too convoluted, too obscure.

"C with classes" isn't a bad idea. But "C with better, safer constructs, while still allowing direct hardware access" is what I want. Rust ain't it. Notice, though, how lots of other languages are C-with-knobs-on, in effect.

Re:A friend of mine once observed

[ledow]

I can read other people's C. Sure, if they're DELIBERATELY being obscure, than it's game over in any language. But C is pretty fixable.

C++, however, I just find the worst language I've ever seen for understanding the context of random code, and the more "modern C++" constructs you use, the worse it gets.

Re:Obcious

[Joce640k]

Did the OP type "Modula-2"? I must have missed that.

Re:Obcious

[Joce640k]

"Why Pascal is Not My Favorite Programming Language" was written in 1981 and the criticisms are out of date. Pascal has moved on since then. Try FreePascal (with Lazarus) or try Delphi.

So... just like most people's criticisms of C++ then?

C++ has moved since the 1990s, too.

Re:Yes - Bless You

[Lonewolf666]

About your prime example:

A prime example of why I can do that is garbage collection. If you implement a linked list in Java or C++, as each node is created, it will have memory allocated for it from the heap. When you are done with the list, each node must then be freed. With a million nodes, that is a million memory allocations and a million frees.

Not necessarily.
C#, for instance, does it smarter. Whenever your list is full, the next add will internally allocate memory in larger increments. Which has its own drawbacks, but it gets around the performance problem you described.

Re:Obcious

[theweatherelectric]

So... just like most people's criticisms of C++ then?

No.

Re: I remember

[JustNiz]

> nobody had proven it was even technically possible to implement the full spec.

Like I said, I believe G++ has always implemented the full spec.

Computer Languages are for Humans

[wizmotronics]

A computer language is supposed to make it easier for the human to program the computer, thus it should be human-friendly and use language, syntax, and concepts from the human world. Otherwise, why not just write code in assembly? Or hand-coded binary machine-language?
My biggest bitch about C and C++ and all its siblings is case sensitivity. I'm not promoting Visual Basic, but at least it gets the case problem right. (And yes, I've read all the arguments about why case sensitivity is supposed to be a good thing, and I think they are all bull**** trying to justify it after-the-fact.) I would love some sort of compiler switch or IDE option to turn it off. I Can rEaD someTHinG no maTtEr how sCreweD up tHe caSe, whY cAN't tHe ComPilEr?
I also don't care for all the {braces} which are awkward to touch-type.

Complexity Issue

[NicknamesAreStupid]

My first languages were assembly (z80 and IBM 370). Assembly language forced me to understand the context of the language (hardware). The representations and abstractions were well defined by the context. I wrote my own macros and subroutines, which became libraries. Life was good. My best work was a 'Carbon Copy' like program that ran in less than 200 bytes of memory by effectively using the BIOS routines.

I documented my code well, as it helped me understand what I did better. I tried very hard to accomplish something with as little code as possible and explained why I thought it was best. In school, I challenged others to find ways to do it 'more elegantly' with less code and simpler logic flows. Of course, beyond writing a device driver, assembly language becomes complex in ways that rival C++ or even Objective C.

Later, I tried Forth. I could write really tight code, sometimes as efficient as assembly. However, I had a hard time with RPN and couldn't even document it well. I called it 'write only' code because it was so hard to read. By then, I had begun using C (also COBOL and PL/1). C was good for writing device driver utilities like configurators, and could be mixed with assembly for larger device drivers like video controllers (though I did not feel comfortable mixing languages). COBOL was good for writing business logic because it hardly needed much supplemental documentation. I liked PL/1 because it was the first language I used with strong typing and a checkout compiler. PL/1 forced more discipline into the start of my coding but made debugging easier. C++ was like that, but I had gotten so accustomed to C that it felt like my lover had become a dominatrix.

My point is that programming languages are as much for the programmer as for the target. When it is just me and my target (machine), the programming language is like a cerebral videogame controller, very intimate connection and control. As soon as you have a programming team, the code is no longer so intimate, as other humans must understand it. In my opinion, that is a huge compromise. However, that is life, human life.

The ideal might be a language that puts the machine on the same level as the programmers. It becomes part Product Owner and so some degree the Scrum Master, though the Scrum model would change quite a bit. Beyond the ideal, machines program themselves, and their code looks like this 010010101000110001010. Just a thought.

Re:Yes - Bless You

[SWPadnos]

Anyone can play a scale on a piano. Anyone can figure out what the notes on the music mean. That does not mean that anyone can play Frédéric Chopin's Minute Waltz. More to the point, a "better" piano won't fix this.

Perhaps not, but I'd rather listen to a professional concert pianist play the Minute Waltz on a Steinway grand than a 1980s synthesizer.

So basically, a good tool lets an expert produce better output, but doesn't help a novice. Sounds about right for coding too ...

Re:Obcious

[thegarbz]

So... just like most people's criticisms of C++ then?

C++ has moved since the 1990s, too.

Yes except exactly backwards. Much of the problems of C++ is how it has moved since the 1990s.

Re:Does Crystal have a strong backer like Rust has

[packrat0x]

No kidding. Netscape was originally in C. They bought Collabra and allowed the failures from Collabra to do the rewrite in C++. This gave precious time to Microsoft.

Do you know of a book about C++ models?

[Futurepower(R)]

"... C is designed to be the most powerful tool possible and it's up to you to apply it to some model."

Then there should be books about C and C++ "models". If you know of such a book, please post the title and author.

Re:Do you know of a book about C++ models?

[AmiMoJo]

C/C++ can be applied to almost any model. But really that's asking the wrong question.

With higher level languages you have some freedom to select a model. With C/C++ stuff the model is generally dictated by the application requirements. So embedded bare metal will limit you to one or two options, OS kernel one or two others etc.

So the book you want is embedded/OS kernel development.

Re:Yes - Bless You

[angel'o'sphere]

. If you are writing enterprise scale code in Java, then you are wasting a lot of compute power.
Why would that be the case?

If you implement a linked list in Java or C++, as each node is created, it will have memory allocated for it from the heap. When you are done with the list, each node must then be freed. With a million nodes, that is a million memory allocations and a million frees. Using custom allocators in C++, I can avoid all of those allocations and frees, and use a single memory pool for all of the objects.
I can do the same thing in Java, by reusing "freed" nodes by keeping them in a free list. learned that around 1984 when programming in Pascal, where we had a "new" keyword" and pointers but no corresponding free/delete.

Otherwise I agree with you. If C++ had a standard cross platform Windows/Widget library, threading, and reflection (and everything that comes from it like serialization) and would compile to a VM, preferable the JVM (LLVM is not enough): I only would program in C++

Re:Yes - Bless You

[AuMatar]

No. The secret to writing unmaintanable nightmares is template meta programming. Its code that's almost not understandable by anyone other than the original author. If you're using templates for anything other than generic container types, you're probably making something no one else will ever be able to maintain.

Needed: Sample programs that show C++ features.

[Futurepower(R)]

The book C# Programming in easy steps happens to be on my desk. I borrowed it from a library.

That book is about C#, not about C++, but it has the same shortcomings as the C++ books I've seen. For example, that book explains "Joining and comparing strings" on page 74 in a way that is better written than other books I've seen. But everything in the book is explained in tiny detail. There is no example of a finished, useful program.

I would like, for example, a complete, well-documented program for filtering and translating text or html files. That would provide a model for other programs I might write. (I've written such programs, but not with all the features I would like.)

Another example: I would like a sample program that uses SQLite to do something useful, like keeping, sorting, and helping correct the Thunderbird email program email address list. Such a program would quickly teach a model for database programming.

There are many elements of C++ that can be valuable in limited situations. But those who designed C++ never explained those areas of value, and the uses of those elements that should be avoided.

The biggest problem with C++, in my opinion? C++ is not finished. Nothing is finished until it is communicated in a way that makes understanding as easy as possible for readers.

Re:I rememberæ

[serviscope_minor]

So around 15 years ago, [...] And so compilers would all implement their own specific subset of the language and there was virtually no cross compatibility

While C++98 conformance rather lagged the release of the standard, your dates are out. By 2003 (15 years ago) I seem to remember GCC being pretty much C++98 compliant (except export!) modulo a few bugs.

The first fully compliant C++11 compiler was released in 2013, the first compliant C++14 compiler in 2014 and the first C++17 compiler in 2017. Even Microsoft who has previously been noted for being a laggard has a C++17 compliant compiler, less than 6 months after the standard was ratified.

So the language started as an unimplementable mess of a spec, and unless someone has been doing some very hard work to make the language LESS complex, I greatly suspect that it has stayed that way,

The existence of three independent, compliant implementations suggest you are mistaken.

Re:Does Crystal have a strong backer like Rust has

[roca]

Pocket doesn't "spy" nor are users forced to use it. You just made that up.

Re:Does Crystal have a strong backer like Rust has

[roca]

What are you talking about? Firefox doesn't implement anything related to SSDP.

Re:Does Crystal have a strong backer like Rust has

[roca]

Lots, of course. A few examples:
Microsoft: https://github.com/Azure/ioted...
Baidu: https://github.com/baidu/rust-...
Google: https://github.com/google/xi-e...

No, egomaniacal programmers are the problem

[EmperorOfCanada]

I have met way too many C++ programmers who think that an elegant design is completely trumped by a sophisticated templated nightmare that requires a deep understanding of what C++ is going to compile into.

They will have fiendishly complicated templates, move, and copy operations built into objects that are instantiated once using the same data types every time. There is no copying, no moving, no variations and yet they defend that their completely unmaintainable code is the only way and that anything else would be amateur hour.

Worse is that these bozos are becoming the gatekeepers for programming interviews. They are pretty much lining up the candidates like a firing squad to blow them all away saying, "Ha he couldn't do a second degree variadic template with a half twist of lemon... loser" at the same time rejecting concepts such as code coverage measurements in unit tests.

Unless you are pushing the bleeding edge of performance, nice simple C++ code that smells more like python, has great unit test coverage (branch checking and all) and doesn't cause your customer or marketing team grief, is the only way to go. Anything else is just some selfish dick ensuring job security.

Re:Yes - Bless You

[dgatwood]

Java has some nice advantages in terms of not caring whether you're running on x86-64 or POWER10 or ARM.

Neither does C++.

The heck it doesn't. Ostensibly, if you somehow manage to write code that completely avoids C primitive types (numbers, for example) or are rigorous about always using fixed-size integer and floating point types, it is just a recompile, but it is a recompile, so:

• Your build fleet has to build for multiple architectures.
• Your test fleet has to run tests on multiple architectures.

This is a nonzero cost. And that's the best-case scenario.

The worst case scenario is one in which you get subtle truncation bugs that occur only on some of your machines and cause data corruption that goes undetected for six months, and in which, once you detect the corruption, you are contractually required to freeze your entire website in read-only mode for three weeks and hire a team of ten thousand temps to go through all of your database records manually, correlating six months' worth of logs with data from six-month-old backups to compute what the correct current values for those fields should be.

Reality is usually somewhere in-between the best-case and worst-case scenario.

C++ is Fun.

[pfg23]

I have always liked programming in C++ (and Iâ(TM)m talking about way back when it first appeared). Poorly written C++ code that has to be maintained by others is definitely a drag but thatâ(TM)s a different issue. I would concede that long, nested template instantiations for predicates can be hard to parse. Macros, typedefs, and the new auto keyword help and should be used. Otherwise, does C++ make it easy to write write-only code? I donâ(TM)t think anymore than any other language. Well written C++ is no more difficult to understand than any other 3rd generation programming language.

Re:Yes - Bless You

[K. S. Kyosuke]

Its code that's almost not understandable by anyone other than the original author.

With the corollary that the same person a year later is not "the original author" either?

Is it all about beauty [clean code]?

[gargalatas]

C++ is a very beautiful language and one can produce beatiful code if he is using a subset of the tools the langugage provides. But even with this compromise one cne can always have to posibility to harden a bit and solve a problem that need better performance. That's the beauty of C++. You will never hit the wall of limitations you can reach easily with other languague. With C++ limitations are far away. So I write simple code and develop simple UI applications and you write vey complicated algoriths with graphics. But we speak the same language right? What is the problem with that?

Tool for the Job

[DarthVain]

When all you have is a hammer...

I always think of this when these programming language debates come along on here. Different languages are better at different things.

If I want to quickly throw something together with a pretty limited scope, you can do that with VB. If you're making something that is more critical, large, or fast, use something else.

I've found that two factors basically make not so much bad code, but bad applications:

The first usually happens with scope creep. Someone tacks something together using some high level language that solves some interim problem that works, but is only meant for that one thing and typically for a short period of time. Then because that thing works, gets used forever, gets bastardized into doing other things, and eventually you get a mess because it was never meant to be used that way using the technology it was built with.

The second thing I forget because apparently my brain has decided to not cooperate.

Anyway the other big difference between some languages is some are very "forgiving" while others are decidedly not. This means using one, a coder might make a lot of say bad decisions, yet still make something that "works", though perhaps not so optimal (and as mentioned, may run into trouble later). The other, in most cases won't let you get something that "works" unless you've more less done it "right" making for some better code. However at the same time, usually if you've done something wrong and it does work, it is something really bad. If any of that makes any sense...

Anyway I don't code much anymore, and when I do it is of the lighter smaller variety. Mostly just to make my life easier through automation of horrible repetitive tasks using VBA or Python. I use those mostly because of convenience and compatibility with other leveraged software. You could technically do more less the same thing with any number of languages, however it would probably take longer and would probably be overkill in most cases. The last time I used C++ was probably 17 years ago lol (along with a another scripting language that doesn't really exist anymore)

Is Jai a 'Really Terrible Language'?

[Larry Lightbulb]

We'll never know because it doesn't exist.

Re:Obcious

[suutar]

that does not actually falsify parent's statement...

and arguably lacking multiple inheritance is a feature. (Though it's weakened a bit. At first you could only multiply inherit interface, then they added a way to multiply inherit implementation. At this point the only thing you can't multiply inherit is data storage.)

More trouble than it's worth most of the time

[randomlygeneratename]

For most cases, I think it is. I learned programming with C++, so it was a little rough at first, but when concepts clicked, it seemed like an unstoppable force. You could write any code exactly how you wanted it to run, and had all kinds of features where you could essentially create your own language within C++ specifically for your project. As I've grown up I've learned that's not always a good thing though.

My career took me into more research and prototyping of ideas, and there I realized in 99% of cases, worrying about memory and speed at the level that C++ can provide over its counterparts, was always less productive than running more experiments or trying a different algorithm. The underlying library calls from Python are often written in C++ -- but the drivers and top level design never needed to be. I also have become less tolerant now when I see a new machine learning package written in C++ on Github. Most times it's a real pain getting it to compile with millions of dependencies, and run with the as-advertised performance. And if you want to modify them, there's usually a steeper learning curve.

That said I still don't really like Python's lack of typing, but it's what everyone in my field uses now. Maybe one day we can switch to F#

Wisdom of Crowds on C++

[solodon]

I'll just chime in with a table by Vincent Lextrait of the languages that world's largest and most famous projects have been developed in: The Programming Languages Beacon the collective choice of people working on these projects is somewhat more valuable than the opinion of a one man / two games shop trying to promote his new project.

Absolutely wonderful language

[seniorcoder]

How can C++ be a bad language when it provided me with a very good income for the majority of my working life (after some years of COBOL) ? :-)
Looking at it from a more technical viewpoint, I really don't care so much about what language I use.
The most important aspect of software development is the design of the software.
C++ is just one of many languages used to implement a software design. Typically, bad workmen (or workwomen) blame their tools.

Re:Yes - Bless You

[tkotz]

... embedded C++ in the kernel without all that STL baggage or exception handling or multiple inheritance or RTTI or any of the other junk that makes the C++ runtime so bloated, and you end up with a halfway decent language for writing device driver stacks.

so C?

Re:Yes - Bless You

[dgatwood]

Really everyone should be using width defined integer types at this point. If the switch from 32 bit to 64 bit computing didn't beat that through people's heads, I don't know what will.

No disagreement here. The point was that some languages enforce safety, and some gracefully let you shoot your own foot if you want to.

Re:Does Crystal have a strong backer like Rust has

[jcr]

You have me confused with someone else. I've never been involved with Netscape or Mozilla in any way at all.

-jcr

Terrible? Yes. Effective? Yes!

[bocsi]

With the really terrible attributes, c++ is a miracle is still living (yes, I am developing in it for full time for 20+ years). - context sensitive grammar? - hierarchic system of include files, causing incredibly complex and almost untrackable actual implementations? - zillions of non-intuitive language rules? - lack of fun while trying to mentally compile your stuff because fearing to start compilation and waiting for minutes just for the simpliest modifications to produce a binary? All this crap is still breathing because main goal for c++ is performance. Other languages, like c#, gives you FUN, because - lacks context sensitive grammar - lacks #include madness - has perfect interface and implementation separation - has truly multiplatform API and ABI compatibility (a C# exe compiled on Windows runs unmodified on Linux) - well thought out libraries from scratch, covering almost all aspects of everyday tasks On some days, I feel myself like a COBOL dynosaur, waiting for extinction in an extremelly well-paid position, but prostituting myself and wasting my brain cells for memorizing pointless c++ rules,,,