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

[Joce640k]

Last I heard: Unity has finally admitted that C# is no use and they're making a new version of it with no garbage collection or dynamic stuff.

(no word on whether they're going to call it 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

[Anonymous Coward]

professionals to use only tools designed for amateurs.

Maybe referring to Visual Basic, but I have seen a lot of VB applications being used at grocery counters. Those huge calculators at grocery counter might be coded by amateurs, but those codes are everywhere.

   

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]

I wrote some very tight code using lambdas last year. I can't understand it now.

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]

No, that's Lisp. And we already have several bad recreations like Python and Clojure and a few passable ones like Ruby and Scheme.

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

[Anonymous Coward]

> C# is no use
How come it's no use if it was the main language for Unity for several years? Are all these devs who used it over these years stupid for using an unusable language?

Of course, sometime you need C++'s zero overhead, but sometimes you don't.

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

[Anonymous Coward]

Not at all. Just use Fortran, and forget all these Boost+++ like a last nights nightmare.

Re: Yes

[Anonymous Coward]

Obviously you have no clue what you are talking about. C is a nice small language, while C++ is a monster from hell; there is no C/C++ . Jus read the FQA.

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

[Anonymous Coward]

The problem with that though, is that you rarely work in a vacuum. You will almost inevitably have to work with code other people have written, and they with yours.

Now, who gets to decide what parts of it you ignore and which you use—and can you not only agree on it, but first of all bring all the code inside that corral, and then keep it there?

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

[Anonymous Coward]

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

It did, and it's called D: https://dlang.org/

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

[Anonymous Coward]

People who don't understand C++ are C++ programmers. The rest avoid it.

Re: Yes

[Anonymous Coward]

Most projects realize the impossible problems at the end of the project. Or they notice them early but leave unfixed because they are hard.

Re:Yes

[Anonymous Coward]

Many years ago now, I had a conversation with someone who served as editor for some ANSI standards, about the time C++ was becoming popular. I asked him how so many odd things ended up in the standards. His reply, which I paraphrase, was interesting:

People with real jobs can't show up at every meeting. People without real jobs can come to all the standards meetings and do. They show up, propose their favorite, sexy ideas, and get them voted into the standard. As a result some really bad ideas end up becoming part of the standard.

I thought that simple statement explained a lot.

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

[Anonymous Coward]

Did he really say that? Because that's idiotic. We *do* tolerate plumbers and accountants that only have a few months training. They do our taxes, unclog toilets, etc. Not every plumber does advanced fluid dynamics for complex systems and not everyone doing accounting is doing deep risk assessment for investment banks.

The same goes for software. You don't need the guy that can write bulletproof and extremely efficient C for hardened avionics... if you're slapping a contact form on a site. You need someone that can slap a contact form on a site without breaking anything else or creating a gaping security problem.

Re:Yes

[Z00L00K]

As I see it C++ has a lot of the bad things from both C and Java while not actually adding anything extra of value these days.

You'd be a lot better off with using Ada for a large scale project though.

C++ has a tendency to be a "Write Only" language due to the large number of variations in constructs that can't be read by others not understanding the context the original programmer had.

Re:Yes

[Anonymous Coward]

I disagree about garbage collection. GC isn't an alternative to RAII -- it's an alternative to reference counting or manual memory management. And C++'s reference counting story is pretty bad.

While smart pointers mean you don't have to do manual ref counting, now you just have to manage smart pointers. You still have to deal with ownership by choosing shared_ptr, weak_ptr, unique_ptr, or whatever the flavor of the week is (boost, Loki, ATL, STL). You always have to be careful about returning "this" or ceating cycles. All this smart pointer junk only seems like a good idea when your other choice is doing it all manually.

Of course reference counting is not per se bad, as Python's implementation (with GC for cycles) doesn't have any of these problems. C# and Python are both languages where you almost never have to think about memory management. If you want scope-based resource management, use Python's "with" or C#'s "using". Both make it explicit that you have a scoped resource instead of C++ where a lock on a resource might just look like a random local variable.

dom

Re: Yes

[Anonymous Coward]

We still teach Lisp (Scheme) at the university. Until a few years ago common lisp or scheme were taught as the introductory language.

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

[Anonymous Coward]

We are talking about the opinion of a professional game developer. Do you imply that Jonathan Blow does not "understand" c++?

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

[Anonymous Coward]

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?

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)

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

What language doesn't this apply to?

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

[Rockoon]

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

Doesnt matter its all just a clunky way to implement generics. The other uses for templates are like goto and should be considered mostly harmful.

Re: Yes

[kurkosdr]

Why recreate a horrible "object oriented" language which flattens your objects into a continuous hexadecimal sludge and doesn't have garbage collection or even safe arrays, all in the name of backwards compatibility with an even worse language? The world has moved on.

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

[Anonymous Coward]

A couple weeks ago someone asked on reddit about how much of C++ was used. There were some comments that some people use C++ in a "C with classes" model, basically taking advantage of RAII and function overloading, maybe the container classes, but otherwise stick with C style coding.

That did not go over well as the comment was attacked viciously. So many fanbois getting upset that some people wanting to use the tool the way they want to use it.

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

[Anonymous Coward]

My lisp is a speech impediment you insensitive clod.

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

[Anonymous Coward]

Only people who do not understand C++ think its a good language...

Re: Yes

[Anonymous Coward]

Whatever your reasons for iterating using indices, the ones you provided are not valid. You can always compare an iterator to v.begin() in order to conditionally execute code. And, since you are talking about vectors specifically, appending items to the end of a vector does not invalidate any existing iterators.

One of the reasons for favouring an iterator style of programming over the C-style index approach is that the algorithm used will probably work regardless of the type of collection being used. Of course, in that case, changing the type of the collection might invalidate iterators if items are inserted during the iteration. However, you would have a lot of performance and other issues if you use indexes in loops on data structures that are inherently inefficient with (and donâ(TM)t naturally support) them, such as maps and lists.

So, in short, using iterators is usually preferable because the data type can then be changed without rewriting code. I.e., the algorithm can be written independently of the data structure.

Re:Yes

[Anonymous Coward]

Most the questions you raise have proper answers. Many of them are in the rationale for the standard.
On the other hand, some are simply wrong. For instance, your argument about separated declaration and definition, in the beginning (1977) K&R C did not work that way. It is a feature that was not until ANSI C that it was introduced.

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

[Anonymous Coward]

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

Like C? Personally, I still like C better than C++. I've written in C for a long time, and I know exactly what I'm going to get.

Re:Yes

[Anonymous Coward]

Maybe because the reviewers didn't write the code, and the diff doesn't

There is certainly no arguing with unfalsifiable gibberish like this. Complain about a language when it has facilities that enable you to do something about what you are complaining about. When that's pointed out complain "IT WASN'T ME".

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.

It's not about local variables. It's about what is allowed to happen to them. A constraint the compiler enforces for free.

Except that then you could see that it was a pointer just by looking at the local scope.

Who cares if it's a pointer or not? Whether something is a pointer has no purchase on the question of will or should it be molested by called function.

Re:Yes

[Anonymous Coward]

If you don't define your API how is anybody supposed to know how to use it or what it does?

Re:Yes

[thegarbz]

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

Same. Except the other day where I was debugging a library someone else wrote and couldn't understand a word of it. What is a template anyway?
(Does that make me an obvious non-programmer? :-) )

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

[Anonymous Coward]

new[] and delete[] are kind of needed for std::vector to work since it parametrizes on the allocator template parameter which is by default, std::default_allocator. And guess what std::default_allocator uses?

Re: Yes

[Zero__Kelvin]

No, it can't.

Re: Yes

[Anonymous Coward]

Bzz, wrong. Appending (push_back) invalidates all iterators if capacity is reached.

Re: Yes

[Colourspace]

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

Re: Yes

[Anonymous Coward]

Thatâ(TM)s simply not true. Every line of c++ code Iâ(TM)ve seen in the real world in the last 15 years was written before 2002, and is being barely maintained by incompetent monkeys who have no idea how it works.

There are millions upon millions of lines of c++ code in the real world still being maintained in old copies of Visual Studio 2005, because the ignorant cretins who âoemaintainâ it canâ(TM)t figure out how to update any of it to a newer compiler.

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

[Anonymous Coward]

Indeed architecture degrees involve assignments like take an empty box and come up with something interesting to put in it

Re: Yes

[Anonymous Coward]

You should have written some comments as wellthen

Re:Yes

[Anonymous Coward]

You separately declare and then define every part of your API because it's a best practice to allow interface and implementation to evolve independently. If you don't, then you: a)retain flexibility in implementation only at the cost of renouncing strong checking of contracts (loosely, interfaces), as in dynamic languages; or b)reimplement the feature with explicit lexical elements, like Java's "class" vs "interface" and "extends" vs. "implements". In general, support for a software engineering best practice directly in the code is a Good Thing (TM).
Similarly, a parent class doesn't mark its destructor as virtual because it doesn't want to impose the cost of a virtual table, virtual resolution and one extra de-reference on every method call on its derived classes. If that's the right decision or not depends, of course, on your design (it is simply not true that all subclasses will silently fail to clean up correctly, you just need to know the proper techniques to use), but again the fact that the language doesn't impose that cost on you is a Good Thing: some domains (e.g., chess programmng, or numeric computing, to mention the two with which I'm most familiar) really frown on things like virtual invokation and frequent allocation/deallocation of memory (but are not by any means unique, see e.g., embedded, auto industry best practices, avionics).
So I'm sorry that you don't know enough C++ to know when and how to use it properly or why the language makes the specific trade-offs it makes (yup, C backwards compatibility is/was a part of the reason, but certainly not the whole story); failed programmers don't a bad language design make. There are quite a few reasons why C++'s design can be fairly criticized (see, e.g., the committee's egregious flip-flopping on "const"), but yours and other's similarly uninformed whining doesn't amount to much.

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

[Anonymous Coward]

Go (golang) is the answer for those who didn't understand the question.

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

[Anonymous Coward]

You've never used Erlang.

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

[Anonymous Coward]

Every operating systems, Really ? And in C++ ?

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

[Anonymous Coward]

I first learnt to program on a 80s micro with 16k of memory and plus a full basic interpretter crammed into an 8k rom. It was moderately user friendly - certainly moreso than you're typical "small" (as in a handful of mb) linux install - had rudimentary graphics and sound and could do useful work with minimal effort (or you could just have fun).

Now I mostly work in C++. *Maybe* if you stripped out absolutely every unnecessary thingy, did some heavy customisation in the right places and perhaps used a bit of inline assembly you *might* be able to cram a hello world program into 16k, but I doubt it. And C++ is nowhere near as easy to work with as microworld colour basic.

Progress? I guess so, but only on a good day.

Re:Yes

[Anonymous Coward]

Compared to the number of experienced C++ programmers that monumentally fuck things up such as myriads of buffer overflow vulnerabilities etc. Yeah, right-o. A More complex language allows you to fuck up more completely.

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

[Anonymous Coward]

If I had a dollar for the number of times I've pointed out that GC is not a panacea for resource management to colleagues. That's why with Java you have to manually inline finally everywhere.

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

[Anonymous Coward]

>Because the compiling of the template is totally depending of the template arguments

Ada's generics could be compiled separately, although the assumption seems to have been that the output was merely an intemediate form of the source, ready for instantiation. I've seen hacks in C++ to access internals that weren't meant to be accessed. In the simplest case, someone copied the header file and changed 'private' to 'public'. In another, someone added an offset to 'this' to get at the data member he wanted. This doesn't fly in an Ada environment.

Separation of definition and declaration is a good thing. It allows you to have a senior architect write the interface, and the junior programmer writes the implementation and doesn't get to break the class's contract easily.

Re:Yes

[Anonymous Coward]

They said that about the wheel too!!!

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

[Anonymous Coward]

Really what we are seeing is more and more people getting into Programming, because being a hipster dev is 'cool', gets you paid well and is no longer a turn off to 'hot fake chicks' the 'look at me and how cool I am' people yearn to land as a trophy.

Understanding CPU architecture, memory management and instruction sets that tell the CPU to do things is hard. Only a few % people are capable of both the mental capacity to understand it all and the patience to learn it all.

So make it easier and simpler. Add layers of inefficiency that adds commonality and consistency to most things people need to do, at the expense of efficiency/performance at micro scales. In return the workforce is more efficient and produces more, a fair trade-off of electricity for more productivity. If energy was more expensive, people would be asked to write in lower-level languages with great skill and efficiency. Energy is currently cheap, so spend the energy to get more services online to bill people against!

Paying the fine is often cheaper than following the regulations, just like buying more energy on a planet dying from spending energy senselessly is cheaper than being as efficient with energy as possible (which translates to writing code that is as efficient with resources as possible when it runs on a large scale).

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.

Re: Yes

[Anonymous Coward]

Lua?

Re:Yes

[Anonymous Coward]

That sure as shit isn't C++.

Fuck, sometimes I think Bjarne and shitheads like you are worse that Rasmus and his merry little band of incompetent fucktards.

numbnuts

Re: Yes

[Anonymous Coward]

Depending on what the program is doing Fortran, Lisp, OCaml, and even Java can outperform C++ on both performance and scalability. That list is not exhaustive

numbnuts

Re:Yes

[Anonymous Coward]

Macros on steroids? LAWL

Powerful macros don't exist in C++ and templates is just noisy garbage.

Go look at Lisp or better yet, Elixir macros.

numbnuts

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.

[Anonymous Coward]

Yeah yeah, lets blame the programmers that we're using The Evil C.
Rather than Bjorne that deliberately created Cplusplus this messy way.

In fact C code works, while Cplusplus project inevitably ends up being a huge mess.

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.

[Anonymous Coward]

This is the main reason why I abandoned programming a couple of decades ago.

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.

Greenspun's tenth rule

[Anonymous Coward]

What can C++ (or Jai, or whatever the flavor of the month is) do that Lisp can't?

Re: Greenspun's tenth rule

[Anonymous Coward]

Well, the main problems with Lisp and its offspring are very limited type systems, an atrocious syntax for humans to work with, and a community that's too academic to care about the needs of real-world programmers. C++ isn't perfect, but it gives us a real type system, a more practical syntax, and a community that understands what a programming language needs to offer to build huge systems. If you don't want to use C++, the solution isn't to move to Lisp. The solution is to move to a modern, C++-inspired programming language, namely Rust.

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++. ;)

Use a subset

[Anonymous Coward]

And choose your libraries wisely.

Re: Yes it is, Java is the answer

[Anonymous Coward]

Obvious troll is obvious.

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.

[Joce640k]

The word you want is "idioms".

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

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.

[Anonymous Coward]

Just a for instance, C++ has overloading. And that's great. Until you meet the king of overloading where you have to follow a dozen overloaded methods to find the actual implementation. Please don't tell me that there is a tool to help with that (class browser). Your class shouldn't be so complicated it needs a special tool to just examine the source code. C++ also lets you overload operators. That's fine _where it makes sense_. Otherwise you shouldn't be doing this "because it's cool".

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.

You're confusing a Ferrari of a language with a Boeing 747 of a language. The Ferrari might be fast, shiny, cool and "easy" to use right, but it won't get you to another continent. The Boeing will (C++), but not everyone is skilled enough to use it right and not crash.

Re:Know what things to avoid.

[Anonymous Coward]

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.

Or maybe you should learn more before you start using it.

Why expect someone who doesn't even understand the basic language primitives to accurately tell some program what to hide from them? How would it know when they've learned enough to move up to the next skill level? Is there some EXP bar they need to fill??? This is a problem with the human's expectations not the machine. If you are going to program anything beyond "hello world" and intend to use it in a production environment, then you should have a basic understanding of the language before you start. Anything less is asking for trouble.

That's the problem with all of these "The X programming language is horrible" articles. They all try to paint the language as being too complicated to learn, and then declare the expected minimal skill set to be absolutely no prior knowledge. To use a car analogy, this would be like complaining that you are constantly getting pulled over by the police, while having no idea what the laws are for driving, and demanding that the car drive for you.

Get off your butt, accept that to use something well takes effort and practice, and quit making excuses. No, you won't get it right 100% of the time. Especially when you're just starting something new. Either do the work and improve yourself, or give up and do something else.

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.

[Anonymous Coward]

The problem with this approach is that you don't always get to decide what to avoid. When you need to work with other people's code you don't have the option of just knowing part of the language. Some other idiot can use those parts, and avoid the wrong things. I've had to work with C++ code done by someone who "embraced" operator overloading to the point that the end was practically obfuscated C++.

Re:Know what things to avoid.

[Anonymous Coward]

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.

When I read the above all I see is a haphazard collection of unorganized opinions completely lacking in any useful specificity or objective information content.

Is this what you learned at university? How to spew unsubstantiated dogma? Get a grip.

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.

[Anonymous Coward]

This. Mod up.

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.

[Anonymous Coward]

Pretty sure you are confusing C++ with Common Lisp.

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

[Anonymous Coward]

C is no longer the performance king. A highly skilled C++ programmer can write c++ code that will outperform even the best C code.

cough cough...bullshit... cough...

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.

You ivory tower types are all the same. Look at me I'm an elitist snob and I don't even know what the fuck I'm talking about to boot. Meaningful performance is achieved through algorithm design/selection. Rest is worthless masturbation of the worst kind. Spinning up another core is cheaper than paying programmers to masturbate. 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.

Genius. Teaching crap languages nobody will ever use once they leave university is certainly time well spent.

Re: Doctor, it hurts when I go like this

[Anonymous Coward]

This. I read his post 3 times. Sounds like someone from academia trying to pimp out there fav language.

You'd love that I bet.

Re: Doctor, it hurts when I go like this

[Anonymous Coward]

You start out your essay with a lie. Therefore I'm not inclined to believe anything else you say.

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.

Re:Doctor, it hurts when I go like this

[Anonymous Coward]

I have to know where every cycle goes because I have hard limits on wall clock execution time

In other words you have niche requirements and don't appear to understand few besides yourself get paid to care about how many CPU cycles a block of C code takes to execute given hardware typically costs significantly less than salaries.

and thanks to having actual data security, throwing cloud based resources

Who said anything about cloud? Does all of your code run serially on a single core? Single NUMA domain? Single system?

Using TMP, I can beat even the tightest inner loops written in pure C.

Tight loops is the opposite of how you write performant code. You write performant code by keeping pipeline full avoiding stalls.

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 admitted yourself two months ago you only make 80k. Most of the people reading this make more. The narcissism and constantly invoking words like "incompetence" and "ignorance" don't do you any favors.

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.

Love the continuing theme of blurting out unspecific assertions that can't be evaluated by the reader. So let me blurt out a contrarian assertion. Iterating over all of the records is a choice that can be avoided with better system design. (materialized views..etc.)

Any reasonably sized database will have millions of records. The databases I deal with have trillions of records.

Is record count supposed to mean something to the reader? For all anyone knows each record is single bit in a sparse table over a total physical extent of 1 megabyte. It's not useful to blurt out ***** records in vacuum without any contextual data. This fails to effectively communicate information.

Yuo certainly don't want to waste iterations, but thinking that the amount of processing in the record loop is irrelevant is ignorant.

For most people "you're doing it wrong" is the normal response to serially iterating over trillions of records.

Betteridges law applies here.

[Anonymous Coward]

Anyone who thinks c++ is bad lives in a javascript glass house.

Wow!

[Anonymous Coward]

It's rare for me to get to read /. comments before the replies to the first comment make it take too long to bother scrolling to find the second comment! /. please fix your mobile experience in the comments section.

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]

Commercial programmers have no brains. After thirty years, man I don't know is between your ears there.

Re: You are holding it wrong

[Anonymous Coward]

"That sort of approach would elegantly hide away all traces of the applications flow..."

You just summed up why I dislike JavaScript programming: the async-heavy code does exactly that.

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

[Anonymous Coward]

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.

This is a straw man, the problem is C++ makes it difficult to NOT write really horrible code.

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

[Anonymous Coward]

C++ is not necessarily a horrible language, but it does allow you to write horrible code. ....
 

Exactly my words, it is even scary how you think the same way.

Re:You are holding it wrong

[antdude]

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

Re: You are holding it wrong

[Anonymous Coward]

The point of templates is typesafety. The more bugs you find at compile time less stupid bugs there are in the product.

Java makes this really easy because with Eclipse you see errors in realtime as you type . In addition you easily see redundant or wrong includes and static code analysis is easy and accurate. In addition there is JUnit and Mockito that make unit testing easy.

Re: You are holding it wrong

[Anonymous Coward]

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.

Yawn... another if all of the stars align then .... sales pitch.

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.

You just don't get it do you? How long an iteration of a loop takes to execute is irrelevant. What matters is the circumstances contributing to iteration count.

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.

What are the odds locality hit from all these piecemeal fast paths not actually tanking performance? What are the odds being clever is NOT in your employers best interests?

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

[Anonymous Coward]

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

Well, he also missed the entire point of macros and their most powerful capabilities as well.

Luckily it all cancels itself out. Your typical assembler macro can handle the example you gave and for the same purpose. (The kind of register allocation mikael suggested is something I haven't seen used other than to provide a form of portability by implementing instructions that are missing in one CPU as a macro instead.)
Unfortunately ISO-C didn't get macros that were as powerful as those that macro assemblers had so it was a bit lacking int that regard.
Templates in C++ solves that problem, but can probable be used for even more.

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.

Re:You are holding it wrong

[Anonymous Coward]

I believe many features were added to C++ simply out of human nature. Basically the C++ committee has many brilliant individuals who devote a huge amount of time and labor to updating the language.It is psychologically almost impossible to to believe that the results of your efforts was simply stopping a language enhancement. Instead it is much more satisfying to trade support for you particular feature with another . Mr. Stroustrup has successfully stopped a few marginal enhancement but political forces eventually prevail.

Re:You are holding it wrong

[Anonymous Coward]

I think you summarised it well. C++ has too many features which should be used sparingly and in the right situation but unfortunately many abuse these features and write extremely complex code which is hard to debug and maintain. I had the unfortunate privilege of being hired to maintain a delivered project which consisted of more than 1 million lines of C++ source code. Some developers decided to overuse features like multiple inheritance, dynamic binding and operator overloading which made it a nightmare to debug and fix issues. It was definitely a compelling reason for me to move out of coding and into testing lol

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

[Joce640k]

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

It already has this, in the newer versions.

eg. The 'auto' keyword.

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

[Anonymous Coward]

I concur. C++ is not a bad language, it offers a lot of possibilities, the trouble is the way in which you express them, partly due to C inheritance.
Give me the same language capabilities, with much less obtuse ways of expressing them, even if it is a bit more verbose.

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

[Anonymous Coward]

Ugh no. A lot of recent featuritis is just step after step in the wrong direction (eg auto). Strip away this feature creap and bring it back go C (or something like it) with classes, but done right this time. Simplify and redesign where required rather than papering over the shortcomings with evermore obtuse features and cruft to learn. A good language is simple, compact and powerful, not bloated and messy.

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

[Anonymous Coward]

That's double double plus good!

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

[Anonymous Coward]

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#.

Actually, three pluses is fine. Just break one in half.
You can stack them like this .....
whole half
half whole

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

[Anonymous Coward]

SPECS is an alternative C++ syntax: http://users.monash.edu/~damian/papers/HTML/ModestProposal.html

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?

That's why I...

[Anonymous Coward]

...use Visual Basic.

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

[Anonymous Coward]

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

Sure, if all those other people are there to fix your bugs

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

[Anonymous Coward]

Oh, very sorry, but you/they are definitely using it wrong. With design/programming by contract and exceptions, there's no reason why you ever have to chase a core dump. As to the difficulty of writing unit tests ... What are you talking about? Check Google Test if you need your hand held, but you can start writing your unit tests immediately and with zero third party support if you know how to use (standard C) asserts; gcov and gperf handle your basic coverage and profiling needs, clint your static analysis, valgrind your memory integrity checks, make (or one of its zillions of variants) manage your continous integration/delivery. There's no reason why you can't implement a development environment for C++ supporting modern best practices; as to if it's worth for you to learn how to do it only you can answer; for myself all I can say is I see no point in trying to replicate my environment to work with, say, Python, only to end up with a slower, more limited product.

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

[Anonymous Coward]

Crystal looks interesting. How does it do in benchmarks vs C++?

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:Was OK for the '80's, But Its Time Has Past

[bingoUV]

If a library's code is not available , dynamic linking is the only way to use that library right ? What are your plans about that ?

It is a similar problem with Linux's lack of a stable ABI : drivers need to create a "open-source" adapter to interact with their binary blob of a driver. For crystal, providers of "closed source" libraries would have to give a crystal adapter for their actual closed source binary blob : which they would write in, say C or C++.

It already exists. It's called Rust.

[Anonymous Coward]

What you propose exists. It's called the Rust programming language. It's a next-generation systems programming language designed by Mozilla that has achieved the perfect balance between low-level freedom, high-level abstraction, and compiler-enforced safety, all without compromising performance. C++ was a great pioneering language. Rust is C++'s successor, learning from the lessons that C++ has taught us, while adding in the critical functionality we need in the 21st century.

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)

[Anonymous Coward]

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

So your answer is to keep adding more bondo to that old VW bus? Smoke another joint and listen to the grateful dead, that's your lot in life.

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.

JAI: It's Another Programming Language

[sarku]

Hey, look kids, another programmer saying the language he developed is going to solve all the problems of that other bad language. In his language, he's not ever going to let anyone write bad code, because it's HIS language, and HE'S obviously qualified, way more qualified than that Stroustrup guy or whatever his name is, who's been writing and maintaining a language for decades!

Re: JAI: It's Another Programming Language

[Anonymous Coward]

Well this is Jon Blow, who made not one, but *two* successful indie games. Surely such genius should not be questioned by mere mortals like us.

Re: JAI: It's Another Programming Language

[Anonymous Coward]

Actually he's done more than that, those are just the two that were published by him and not someone else.

I know Jon personally and he's actually a very smart guy. Whether you agree with him or not, he wouldn't make such statements lightly. I suggest you read what he says instead of responding in knee-jerk, fanboi fashion.

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?

[Anonymous Coward]

Assuming you have control over the enum definition, this isn't that hard

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.

No, its not

[Anonymous Coward]

The problem today is that there's many jr-middle level developers and they don't really understan languages that doesn't have any sort of Garbage Collectors. GCs are the reason that most of code today have worst quality than those written 30years ago. Developers got lazy

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.

927

[Anonymous Coward]

We should build a language better than all others one... soon https://xkcd.com/927/

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]

Sounds like just the place for you, then!

Re:This is why Rust is popular.

[Anonymous Coward]

I do not disagree. I suspect out of this generation of new languages Rust is going to be around for awhile. Not sure if I can articulate it correctly but it 'feels right'. However C/C++ is going nowhere. No mater how much anyone wants it to. However I can do the exact same thing you just said in C++ and just use it as a leaner more modern C++ and not give up anything. I do not think anyone bashing on it is using C++ 14 or above. They cleaned up a *lot* of the mess that templates created. Being an old school c++98 guy they *really* made it a better language and is actually makes things simpler to use.

Rust has an advantage as it is shaping up to be the language of webassembly. Which in many ways is a band-aid around the real problem. There is only 1 real language of the web, Javascript. Which has way more pitfalls than C++ could even think up. They have been trying to fix that up with typescript and ES6. But it is slow going. I can teach someone C/C++ in a few weeks. But to for something like javascript I have to teach them hundreds of pitfalls and a very odd model that most people do not understand intuitively (callbacks and type injection). All at the same time for them to be able to use it properly.

Java/Python/NPM have some distinct advantages of huge repos of usable code. You do a few includes and you have very powerful programs very quickly. But you have no real idea what that code is doing or if it even fits your model. C++ has a distinct disadvantage here. The large libraries that exist to make things happen have pretty much been effectively abandoned with little new interesting work happening. The standard library and QT is helping here. But it is rough going.

Re: This is why Rust is popular.

[Anonymous Coward]

all of you are fat nìgger pieces of shit

Re:This is why Rust is popular.

[Anonymous Coward]

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

Re: This is why Rust is popular.

[Anonymous Coward]

Rust is total and utter garbage, dipshit. It's the Managed Visual Basic .NET of the hipster trans generation.

Re: This is why Rust is popular.

[Anonymous Coward]

Lol, no! That is a lie, a boldface lie.

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++

[Anonymous Coward]

std::string should be enough to get anyone to switch to C++.

Re:Never learned C++

[Anonymous Coward]

C is a decent language.
C++ is a descent into hell language.

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++

[Anonymous Coward]

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

Well, that is probably the things right there.
GUI writing is something that is a lot easier if you have an OO language to work with. Sure, you can write OO in C, but you get a little more syntactic overhead all the time.

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

You sure could, but M68k assembly is so damn pleasant to work with that you hardly need it.
Commodores standard include files adds structure and enum declaration macros and if you follow the d0,d1/a0,a1 as scratch convention then register management isn't really a chore either.

Re:Never learned C++

[Anonymous Coward]

std::string should be enough to get anyone to switch to C++.

You mean switch back to C.

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++

[Anonymous Coward]

Then you don't know much about C++.
Hint: constructors, destructors, custom allocators ... you have noting like this in C.

I've done all of the above in C. Where's my cookie?

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.

It's what all of programming is about.

Obviously you can write any program in any language, but then again

But nothing.

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

Re:C++ is an engineering language

[Anonymous Coward]

FORTRAN has not been amandoned in scientific research.

Re: C++ is an engineering language

[Anonymous Coward]

I worked with Fortran 77 CFD code up to 2014.

It gave me PTSD.

Re:C++ is an engineering language

[Anonymous Coward]

FORTRAN was never abandoned. Intel makes a brisk trade selling licenses for their tweaked compiler.

Damn Straight

[Anonymous Coward]

It called me pussy-whipped because I do javascript. That what they done tawt me in the collage of hillibilly city. Yukyuk.
  xxx

unnecssary features are not "great"

[Anonymous Coward]

Throw out all the old C stuff, throw out the preprocessor. Throw out random casting. Do that shit in assembler if you have to.

  Better yet, get a real fucking computer with typed memory. Then you can have a safe, fast language.

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

[Anonymous Coward]

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.

No, it's not just you.
The people arguing against "C with classes" were typically the people who finds a new toy and insists on using all odd features about it.
When it is time to maintain their code or add features that their latest toy weren't specifically made to handle they look for greener pastures.
They have moved on to other latest greatest languages by now.

If you want a truly readable C++ then you can look into EC++ (Embedded C++)
It strips out pretty much everything that makes C++ unreadable or unsafe.

Namespaces seems like a good idea, until you get tricked by different variables and functions using the same name. A better solution is to use a good naming convention.
Exceptions seems like a convenient way to handle errors, except that it creates a non-intuitive program flow that is hard to debug and creates run-time error conditions that you might not have expected during development/testing.
Multiple inheritance was just a bad idea from the start and should never have happened.

Re:It wasn't always shit

[Anonymous Coward]

Nope, definitely not just you. Everything in this comment is spot on, except maybe accusing coders of being programming hipsters for being early adopters of new features. That part is a touch unfair.

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.

Re:It wasn't always shit

[Anonymous Coward]

Throughout the 90's at least, C++ was taught in many places as "C with classes". I bet that's how you learnt it. It sure was how I did. And that is indeed one valid way of developing in C++. But C++ is nothing if not a portal to every programming paradigm conceived by mankind. And many of those paradigms are much more modern, type-safe, resource-safe, and maintainable than "C with classes".

Personally, I had to unlearn a lot of old behaviour and patterns in order to get into the new stuff. It's a hurdle when you're an old fart. But don't dismiss it just because you're comfortable with what you know.

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]

People probably will have longer careers as prostitutes than as programmers these days anyway.

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!

Re:Not my problem!

[Anonymous Coward]

Is that Personal Home Prostitute?

Re:Not my problem!

[Anonymous Coward]

I became a cab driver, bus driver, and then truck driver. No lie!

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

[Anonymous Coward]

The software of his time machine will be coded in Rust for sure.

Re:Blow is in good company

[Anonymous Coward]

The software of his time machine will be coded in Rust for sure.

I sure hope he does not travel into the distant future like 2024 because there won't be no more Rust programmers then to fix bugs in the code.

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?

[Anonymous Coward]

Modern C++ makes it easier to write code that won't take your foot off. I realize the language itself is much more bloated now, but I couldn't really say I liked it until C++11 came out.

W.r.t. it being a relic, what other languages are you writing embedded applications with? A lot of code runs real time on hardware and contrary to popular belief it is usually C++, not C.

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?

[Anonymous Coward]

Ada2012

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.

Re:I dunno, are swords really terrible weapons?

[Anonymous Coward]

Have you ever seen movies? The one bringing a sword to a gunfight wins. ALL THE TIME.

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++

[Anonymous Coward]

ultra-gay

Re: Rust is that beautiful language within C++

[Anonymous Coward]

This! Yes! So right! Rust! Rust!

Do you think there are 96 genders? What do you mean, "I don't want to talk politics?"

Fuck off Nazi! That's against the Rust Code of Conduct!

*rapes your corpse*

Re:Rust is that beautiful language within C++

[Anonymous Coward]

Fuck all languages that demand you subscribe to a code of conduct, which always translates to Professional Full Time Victims trying to take control and start as much drama as possible while accomplishing nothing.

Re:Rust is that beautiful language within C++

[Anonymous Coward]

ultra-safe, ultra-productive and ultra-powerful modern programming language called Rust [...] more and more C++ programmers are opting to use Rust

Wow, so little hype. So, if so many people write Rust, how come I never stumble upon code written in it? Rust's poster child is _small_parts_ of a C++ browser; the Wikipedia page on Rust has nothing of substance and list an Emacs reimplementation, a VCS no one uses, yet another text editor and obscure libraries. "Toy language" is the best description I can associate with languages with so little projects. Rust is the new Rebol.

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++

[Anonymous Coward]

I expect "Rust" to be a typo of Golang.

Doesn't have to be ultra-everything, just get the job done minimally, safely and fast.

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++

[Anonymous Coward]

This.

Fortunately I've read that Rust is a poor language overall despite the security features.

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?

Re:Rust is that beautiful language within C++

[Anonymous Coward]

is a sign that someone is shit.

FTFY

numbnuts

No

[Anonymous Coward]

...but really terrible quotes often end up in the media

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.

Re:Jai?

[Anonymous Coward]

The language is still in closed beta. You can follow development in video streams on Twitch or YouTube.

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.

Re:This is not your grandfather's C++

[Anonymous Coward]

This is especially a problem for people who go looking for resources on learning C++. You find books and online resources - with no idea how old these resources are, or which variant of C++ they cover. Other languages (PHP is a biggie) suffer from this same thing - you can easily find lots of really bad (insecure) database code online, that while later was replaced by better ways of doing it - the old ways are still there and easy to implement. Lots of feature creep but easily available documentation across all versions. There is not a "best practices" of C++ in the same way in the same way as Python. It is a big pie and everybody can have the portion they want.

I first learned C++ in 1994 - DOS programs. I learned it again a few years later when the STL became available. I learned it again a few years later in dealing with OS calls and the windows API. The amount of overhead introduced by handling File / OS / Windowing APIs suddenly got enormous. The ecosystem has gotten enormous -- and that was even before the internet became what it is today. A program today has the potential to need to know so many other things. Does it need to talk on the internet? Does it need to modify an Excel spreadsheet? How about SVG or PDF or any of a thousand other formats....

One of my classes in programming languages asked us to create a program that would expand a file based on user-defined parameters, you pick the language . My program was ~2000 lines of C++. Another person in the room did hers in Python - 74 lines, with half of that being comments. I still use C++, but mainly only on the arduino platform where the ecosystem is much smaller.

C++ gives you all the rope you could ever want, to do whatever you want.
C++ gives you all the rope to hang yourself as well.

Re: This is not your grandfather's C++

[Anonymous Coward]

As someone whoâ(TM)s been using C++ professionally since it was about 5 years old, C++11 removed much of the cruft that existed and improved the usability amd consistency of the language. C++14 and C++17 were further improvements. Yes, the language changed, but it had too. There where 20 years of OO lessons from C++ that had influenced newer OO languages that had not made their way back into C++.

No smart pointers?

[Anonymous Coward]

Smart pointers are easy and standard even in C++ these days. The not planning these seems like a significant weakness.

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:C++ appeals to lovers of complexity

[Anonymous Coward]

[Disclaimer: I'm not the grandparent AC.]

IMO undefined behavior is the worst part of both C and C++. It's nearly impossible to write a non-trivial program that's free of undefined behavior -- so difficult in fact, that even compiler writers have bugs where the compiler itself segfaults (I reported one in gcc in the past couple of years, and they patched it very quickly). If that's not enough proof that nobody can write UB-free code, then I don't know what is!

I'd love to see compiler flags and/or pragmas that let the programmer choose which behavior should be taken for things like throwing on signed integer overflows and null pointer dereferences. Furthermore, I'd like to have flags that let you specify that all types are implicitly default / 0-initialized, unless you explicitly request int foo = std::uninitialized; or something. They could even give you flags to control the default values of each primitive type! And I'd also love to have a compiler flag that disables ALL implicit conversions / promotions, and another one that makes all non-member values const by default (e.g. require "mutable int x;" if you want to be able to change the value).

Yes, I understand that it's not possible to ensure program validity when the user does things like unsafe type-punning and cast random pages of garbage memory to function pointers, etc, and I agree that everyone shouldn't have to pay for bounds checking on every random memory access, but there are some of us who value safety over performance, we'd gladly take a perf-hit to have valgrind-like memory access checks for "unsafe" accesses that the compiler can't statically prove are safe.

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.

Does Crystal have a strong backer like Rust has?

[Anonymous Coward]

Does Crystal have an established organization backing it, or is it just a hobbyist project?

Compare it to a modern C++ competitor like Rust. Rust is backed by Mozilla, one of Silicon Valley's greatest success stories. I trust that Mozilla will guide and support Rust in the years to come.

When I use established languages like C++ and Rust, I feel confident knowing those languages will still be supported and popular 10, 20, and even 100 years from now. I don't get that same feeling drom Crystal, at least not yet.

At this point I wout have to go with Rust instead of Crystal.

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.

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

[Anonymous Coward]

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

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)

Well to answer his question...

[Anonymous Coward]

No. C++ is not a terrible language, and never has been. If you find it difficult to program in C++ as opposed to other languages it means you're just dumb.

Freaking wannabe developers. What a joke.

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.

Specifics?

[MichaelSmith]

Even the article doesn't have any.

Re:Specifics?

[Anonymous Coward]

Well, most game devs suck because they program to make a game/money, not to make good code. So you rush and do everything possible to make it RUN, not necessarily to properly WORK while making your game run.

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

[theweatherelectric]

C string handling, that's really elegant.

It really isn't. Pascal's string handling is superior. Try it out with Free Pascal.

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

[Anonymous Coward]

Using C with a C++ compiler is really great. Having reference variables and construct's and destruct's to manage resources is great. Context programming with C gets a little pedantic, supplying the implied `this` of C++.

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:Stuck with C++

[Anonymous Coward]

Where did C come into your shitlist?

There's no reason to move away from C. There's plenty of problems with the way C++ did things, though. The idea that if you program in a C-like fashion in C++, you are either (a) writing efficient and standards compliant code or (b) totally clueless about The Right New Way- that's a huge issue. You shouldn't have a language subdivided so sharply, and in attempts to appease new philosophies while remaining compliant with the standards, C++ is arguably two or three languages on top of C. That's an issue, and one that should probably be solved by starting from C and going somewhere, keeping in mind the pieces of C++ that you are trying to keep around. Alternatively, you could simply name the different styles of programming, see if you can style them appropriately, and try to do that without embedding predjudice, so that I don't have to listen to two C++ developers argue about whether some standards compliant code is "too old' or "risky" or whatever.

The influx of this shit into C++ is why I try to argue for C where appropriate, because it eliminates a lot of misunderstandings that appear inevitable with C++. Pretty sure it is a losing battle however.

Re:Stuck with C++

[Anonymous Coward]

"I believe that C++ either needs to have a fundamental change to break the axiom of backwards compatibility"

Amen.

C++ does suck

[Anonymous Coward]

I'm way too lazy to deal with manual memory management and pointers and shit.

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.

"Arbitrary Compile Time Execution"

[Anonymous Coward]

Maybe I'm crazy for having never needed this, but why is this the first point in "Jai" (which I don't even know how to pronounce)?

"Arbitrary compile-time code execution – Any function of the program can be made to run at compile time with #run"

It's definitely charming that you can't even fucking compile the source code in this language without vetting it carefully to be sure that it won't own your box, and that's its NUMBER ONE FEATURE.

Re:"Arbitrary Compile Time Execution"

[Anonymous Coward]

Seems to be a hazard with anything game programming related. zip files of demos that contain viruses, executable demos that need a server to talk to, device driver downloaders and updaters that send telemetry back to the mothership

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.

[Anonymous Coward]

I think you argued against OOP not C++. FYI: The modern C++ approach is to create Algorithm::calc_mpg<T>(T gasVehicle).

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.

[Anonymous Coward]

rather than the more generic calc_mpg(int miles, int gas)

That rather clueless. How do you calculate the mpg of electric cars?

Your calc_mpg() will end up as a spaghetti of switch cases.

Re:For certain values of terrible.

[Anonymous Coward]

"is thought" is equivalent to "they say"?

Meaning, of course, that it is impossible to judge whether the statement is factual or not except by appeal to (self-proclaimed) authority....

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.

[Anonymous Coward]

Trying to decide is poster being sarcastic or not. Complaining about an object-oriented language using polymorphism and inheritance, core aspects of OOP, is just... wtf ?!?

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.

[Anonymous Coward]

Encapsulation is a basic feature of Object Oriented language and is thought to be a generally good thing.

Well, it *was*, until the dependency injection crowd decided that it wasn't any more.

Software engineering has lost its way - each generation embracing the new shiny and building code bases which are slower to execute, harder to write and more difficult to maintain - more akin to literary criticism than to an engineering discipline.

Re:For certain values of terrible.

[Anonymous Coward]

This is a shortsighted comment that basically amounts to "I don't use this stuff, therefore it shouldn't be here at all."

I mean, of all the things to complain about, *operator overloading*?? Get real.

Re:For certain values of terrible.

[Anonymous Coward]

Oh, boy ...
Polymorphism *is* a desirable feature that helps create clear, readable code. Your lusting for functions that operate on generic data types is called, precisely, type polymorphism. Undeniably useful, helps create clear, readable code and all that ... but has the drawback that you can't check correctness until it's instantiated with a type, because only then you know if the instantiating type satisfies the template's requirements (e.g., supported operators). So, you can try to check those requirements early by introducing an interface (in C++, an "abstract base class") that explicitly indicates what is needed from any type that is intended to be used with that function; hence, class polymorphism (in the end, all interfaces need to be implemented by concrete classes).
However, if you're the type of "designer" that, having miles and gas in a type, thinks adding calculate_mpg(miles, gas) to that type is a good idea, totally oblivious to the problems of ambiguity and weakening of the class invariant that creates, then you need to learn *a lot* before you're allowed to design your own classes. In your case, your poor understanding of basic OO concepts is the real issue; please don't try to get anywhere near C++ until you have acquired a lot more knowledge and experience, you will only hurt yourself and others, badly!

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.

Gaining expertise in C++

[Anonymous Coward]

Results in symptoms identical to Stockholm syndrome.

Not every software component is best represented as a new data type (class).

Which version?

[Anonymous Coward]

It depends which version of C++ you are talking about. The language has changed considerably from the 1990's C with classes to todays template meta-programming language of sorts. I think C is a great language. It does exactly what it is supposed to do and those of us who basically need a portable assembler with structures use C. It's the workhorse that device drivers, kernels, and all sorts of low-level software is written in. And for that it's just fine.

C++ started out as a way to fix a few sins of C and to introduce a simple, thin set of OOP constructs. In the 80's and 90's, it did just that. As an older guy I can't even make heads or tails of C++ code written today. Before people jump up and down saying "This guy doesn't get the power of meta-programming!" I certainly do. I've programmed in Scheme and FORTH. Both languages have meta-programming.

The problem is C++ tries to do it with a sort of "declarative language" -- noble in approach, terrible in practice. Now before those same people jump up and down saying "This guy doesn't get the power of declarative languages" of course I do. I like languages like Prolog and SQL where you don't bother with the "how" component.

But for meta programming C++'s approach, syntax, historical baggage, and (the worst) design by committee has rendered it a pile of crap. And I'm a guy who likes VHDL and Ada syntax!

Yes, yes it is.

[Anonymous Coward]

Go back to pascal already. Programmers could have conquered the world with that language if it had not been for C++ aka COBOL for the modern era.

Let's take this language and light on fire inside a dumpster somewhere already.

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.

Firefox is starting to use Rust

[Anonymous Coward]

Mozilla is starting to rewrite important parts of Firefox using Rust. I think that once more programmers see how using Rust has let Firefox's devs get to be so much more productive we will start to see other software be written in it, too. I know this might be hard to believe, but I think within the next 10 years we'll see a big push to port the Linux kernel to Rust, and I think it will be fully ported to Rust by 2030, with no C code left at that point.

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.

Re:Firefox is starting to use Rust

[Anonymous Coward]

think within the next 10 years we'll see a big push to port the Linux kernel to Rust, and I think it will be fully ported to Rust by 2030, with no C code left at that point.

Or maybe the ownership model is ported to C before it, and the kernel developers can choose to use memory safe C, when applicable, by then.

Re: Firefox is starting to use Rust

[Anonymous Coward]

"Mozilla is starting to rewrite important parts of Firefox using Rust. I think that once more programmers see how using Rust has let Firefox's devs get to be so much more productive we will start to see other software be written in it, too."

And what could be more productive than rewriting things that already work in the language flavor of the month? I'm sure they'll really show off how bug-free and stable everything is too, because it's pretty unlikely they'll introduce new bugs in the rewrite process.

Re:Obcious

[jcr]

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

-jcr

A friend of mine once observed

[Anonymous Coward]

that C, C+, C++, etc., ad nauseam, are "write only languages": you can write code in them, but you sure can't read most of it.

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: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.

ONLY IF YOU ARE A STUPID NIGGER

[Anonymous Coward]

FUC

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.

Re:I rememberâ¦

[Anonymous Coward]

You try to pass your ignorance as evidence of your correctness: total fail.
No need to "suspect": you can use free g++, OSS clang or gratis MSVC, depending on your biases and needs, to develop on standard C++ 14. Implementation of C++ 17 features is also quite mature in all of them, and things like the GSL (which might get included as part of the standard in C++ 20, and which is *exactly* a large amount of work intended to make its usage less complex) are already supported as well. As for best practices, template metaprogramming was a long time ago identified as problematic and essentially rejected from professional praxis ... Amazing how those people that work with the language every day are smart enough to discontinue use of features that even a casual ignoramus non-user realizes are overcomplicated, ain't it?

Re: I rememberâ¦

[Anonymous Coward]

Donâ(TM)t forget, Microsoft has tried to kill everything they didnâ(TM)t own.

Re:I rememberâ¦

[Anonymous Coward]

I don't understand all this hate: 25 years ago, C++ was a great little language!

Not a mess

[Anonymous Coward]

Long time C++ developer. In truth: It's an awesome, very capable language and immensely powerful language. I wouldn't use it for scripting tasks but for serious computing it's amazing

The truth though: Bjarne and the committees have added layers and layers of unnecessary crap over the years which bloat the language, replicate existing functionality like lambdas did and in some cases force rewrites like the stream debacle, and streams were an overcomplicated mess from day one.

But all that new function the have piled on over the years? You just don't need this shit. I avoid it Most tragically: I don't need it anyway. And it turns people off.

What they really do need: Serialization. At the moment you must do this manually. It's a pain in the butt but you can do it. An automated serialization system would be much better. Yes, I know Boost has a serialization system but it's verbose. Whole point of using a library function is to have less and simpler code.

People who whine about dangling pointers and the like need to grow up. It just isn't a problem for me. I code so it isn't a problem. Yes if you've been brought up using scripting languages I can see why this would be a problem for you. But to learn any new language you need to adapt. If you can't, stay where you are. If you don't it's like moving to France and complaining they speak French there.

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 it is, Java is the answer

[Anonymous Coward]

Hehe it was literally the stupidest thing Iâ(TM)ve read on the internet in a while

C++ could be a great language!

[Anonymous Coward]

All you have to do is not use any of the libraries that try to make it look like assembly, Fortran, Pascal, Lisp, Ruby, Basic, Modula, java, or Ada.

But seriously, C++ suffers from "look what I can add and make this work like something else"

Different People

[Anonymous Coward]

We all think in different ways, so there's never going to be one language that is everything to everyone. I had to take a COBOL class in college, but before that I had taught myself a couple of different languages; and damned if that COBOL class didn't help me to understand certain concepts better. Every language has its own set of strengths, weaknesses, and quirks. Sometimes Language X works in a way that is more in line with how Person A thinks, but Person B may be more of a Language Y type. Just use what is closest to the way you think and stop worrying if other people are the same.

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.

Re:Benchmarks

[Anonymous Coward]

Why crystal over the older more established Julia?
I had a quick read at the doc and I don't see what http://genieframework.com on https://julialang.org doesn't already provide me. Am I missing something

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!

Re:Not Horrible, Just Mature

[Anonymous Coward]

Well, no, in C++ after 30-40 years of groping around figuring out what the good practices are* they put in language support for them, but all the cruft has been left behind for backwards compatibility's sake. Which is how it must be ... if the new version of C++ didn't let people compile QT or any of the other frameworks nobody would ever use the new version.

* Which is putting it kindly ... at first C++ didn't even know what kind of language it was supposed to be. At first it was considered big and slow (with RTTI, exceptions etc.) and while those issues were never really solved, it did manage to become faster in some cases than C with move semantics and things like that.

If you want to compare C++ to another language, look at Objective C. It's also crufty, very fast and powerful in the hands of experts and very difficult for novices to use correctly.

A mature language is something like C. It's basically the same thing but with a few new features that are entirely optional.

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.

Re: Does Crystal have a strong backer like Rust ha

[Anonymous Coward]

You could have just written, "No."

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.

Blow knows jack shit

[Khyber]

Maybe he should take up ASM programming, then he can talk about level of programming difficulty, the fucking n00b.

Re:Blow knows jack shit

[Purity Of Essence]

He cut his teeth on 6809 and 6502.

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:Blow knows jack shit

[Anonymous Coward]

"When your first sentence starts with marketing speak, I'm 100% sure you're going to deliver a horrible product."

your sig

"Stupid people are like glow sticks."

Hm.

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:STL & Boost

[Anonymous Coward]

As far as I'm concerned, the language went off a cliff when it started incorporating elements of STL in its basic definitions.

So in the early days already with std::type_info as result of the typeid operator or do you mean the more prominent new that can have parts replaced and throws a std::bad_alloc exception?

One good example of this is the ranged for loop [cppreference.com], introduced in C++11, which requires iterators that conform to APIs established in the STL.

You could just make the iterator object your virtual begin/end functions return a wrapper around a polymorphic one?

Re:Does Crystal have a strong backer like Rust has

[Anonymous Coward]

> today they are driver for practically every useful and interesting privacy-oriented feature in just about every web browser.

You know, like making a sham buyout for a Web 2.0 fancy bookmark pyramid scheme then forcing your entire user base to use it despite the fact that it spies on you. Can't thank them enough for that.

Should have left C alone

[Anonymous Coward]

Should have left c well enough alone. All the extra shit in c++ is just gibberish.

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.

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...

[Anonymous Coward]

That's the feature level that gave C++ its bad reputation for many new programmers, and the reason we are talking about the complexity right here.

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

[Anonymous Coward]

Exaclty the opposite.. then there is no reason to use it.

C++ excels and it is clearly superior to every single imperative langauge exactly because of modern c++ paradigm

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

[Anonymous Coward]

Oh yeas, definitely never use maps or sets, they're just too hard (for you, may be). Or streams. Or ASIO. Or multithreading. Or 80% of the libraries. If you do, you won't be able to whine about how C++ lacks all the things that every other programming languge has. How dare those C++ people make stuff you actually have to *study* and *learn*, instead of read your mind and adapt itself to your wishes?

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.

I think the Jai proponent is asking for too much

[Anonymous Coward]

He says:
"People think a programming language should be a complicated ecosystem," Blow said to the audience. "I don't want to learn an ecosystem for a year, I just want to put 3D graphics on there."

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.

The application:
"Companies have very large game engines that would be very costly to replace. So a game like Assassin's Creed, last I heard a couple of years ago, was like ten million lines of source code... It's probably bigger now."

I can see why publishers like EA are so nickel and dime, and push sequelitis. They have to write enormous amounts of performance optimized code for the PS4 and Xbox One. That codebase probably costs hundreds of millions of dollars to write. That is the market for C++.

He'd probably be happier writing less optimized code in Java, or C#, and use the standard library. They are certainly easier to debug.

Re: Yes - Bless You

[Anonymous Coward]

Kinda agree, but just want to point out that there are ways to tune and minimise the impact of garbage collection and make its impact negligible.... though sometimes that is hard and have other trade offs.

Re:Worth repeating..

[Anonymous Coward]

I've said it once, I've said it 1000 times: C++ is the product of troubled minds.

It is an absolutely horrific language. It is second only to Perl.

Nah, PHP has them both beat, by a large margin. And then there is MUMPS...

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:Yes - Bless You

[Anonymous Coward]

Java is an example of idiots writing software. It is not appropriate anywhere.

Re:Obcious

[Z00L00K]

All languages have been an experiment at one time, but C++ is really a kludge solution on top of C.

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).

Labyrinthine ecosystem is the problem

[Anonymous Coward]

Blow is right.

Now, C++ is an excellent language, the problem is the complexity of the ecosystem that's grown around it.

But who can follow through that labyrinth of objects? Whoever can, is a *real* champion.

Re:Yes it is, Java is the answer

[Anonymous Coward]

Although I don't agree with the parent, I think he makes a lot of extremely valid points.
Therefore I think it's an abuse of moderator privileges to mod it to -1.

tl;dr: -1 does not mean "I disagree."

Re:Does Crystal have a strong backer like Rust has

[Anonymous Coward]

Not forgetting SSDP streamcasting your computer screen. I know for a fact wheneven I had Firefox running on my PC, a contractor at work was able to see the contents of my screen. He would be standing next to my coworker practically reading out a list of things on my TODO list.

Re: Yes - Bless You

[Anonymous Coward]

Cool, but you also take 2 months/years/never to do that.

Re:Obcious

[AncalagonTotof]

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

Re:Does Crystal have a strong backer like Rust has

[Anonymous Coward]

C++ and Rust, I feel confident knowing those languages will still be supported and popular 10, 20, and even 100 years from now

Rust? unless they get rid of their toxic SJW community it'll simply implode the day when someone realizes some piece of code is better than some other piece of code and it's a form of intimidation and because intimidation is a something historically associated with cis men, it's also transphobic and against women.

What non-trivial Rust code exists apart from bits of Firefox? Exactly.

Yes, it is terrible.

[Anonymous Coward]

Context is critical. As a language for hobbyists like me, it is truly a mass of steaming vomit and feces. On the other hand, the fact that it has been able to (sort of) keep up with the enormous changes in what is being asked of it is just as amazing. It's like having a mother, girlfriend, wife, secretary, and nurse in a single package. Like having a 1000 tool, 50 pound Swiss Army Knife. I don't want either one, thank you very much.

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.

Domains

[Anonymous Coward]

Is C++ a 'Really Terrible Language'?

Yes, C++ is a really terrible language. But it's also a really good language. Which is why this same argument comes up so often here on /.

It's a terrible language because you have to concentrate on the programming domain instead of the problem domain. It's a really good language if what interests you is the programming domain and how to get C++ to do something.

Over all, that makes C++ a really terrible language for everyone because it's bad for solving the problem.

Give me std::file::read_all_text

[Anonymous Coward]

Instead of that crappy streams

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.

Re:Yes - Bless You

[Anonymous Coward]

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

Yes, because only apple gadgets are ever used as client machines.

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

Oh fuck off

Yes and No

[Anonymous Coward]

C++ is a horrible language, but it’s also an important one. I agree it’s convoluted; but the situation is more complex than what people have said here.

Yes, it was already convoluted and too complex in the early years. But people tried to improve it - the one problem was backward compatibility. If what() returns a char* instead of a string& that’s because we want existing code still to compile with a C++17 compiler.

BTW, once you embrace a library like Boost (which you will need to do, since the standard library is too spartan), the same app in C++ might well be fewer lines of code than in Java, because the latter is full of fluff syntactic (public static void main() { ... } anyone?).

The argument people should move to Rust has some merit, but again things aren’t that simple: C++ is a standard language with enormous support in terms of compilers, ecosystem, and most importantly, trained developers. “Exotic” languages are always risky to use because you can’t find experienced staff (and there won’t be those answers one needs on Stack Exhange).

C++ is also important:
- Google uses C++.
- Many large banks use C++.
- The only reason why Python is productive is most libraries in Python are written in C/C++. As soon as you need to maintain/fix a library, you’ll need to learn it.

C++ is also difficult (and not event taught by universities anymore). Because of these reasons, there’s actually a shortage of capable C++ developers in the market.

PS: If you propose to throw C++ away, it would be offensive to put it in the same bin as Pascal - Pascal is beautiful and small. Use the COBOL bin.

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

Nice try. Haskell surely "recreated C++"!

[Anonymous Coward]

Aftrt having worked two decades in a world of C++ and its cousins, learning Haskell taught me, how insanely limited C++ makes the minds of those that think it is the greatest, and how insanely cumbersone it is to use.
Going back to C++ is worse than going back to the child of Basic and JavaScript.

I'm certainly not hailing Haskell as the perfect language. I would not even recommend it for your bread and butter projects. But it certainly opens your eyes and mind, real wide. And with that, monstrosities like C++ or PHO or JavaScript, and even C (strings as char* + int? seriously??), become really really unbearable.

False dichtotmy. C++ AND C# are turds.

[Anonymous Coward]

C# does really well at putting lipstick and makeup and a dress and high heels and a smile on a C++pig.

It's still a pig.

Re: False dichtotmy. C++ AND C# are turds.

[Anonymous Coward]

So....that makes C++ still a pig as well?

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:Yes - Bless You

[Anonymous Coward]

>With a million nodes, that is a million memory allocations and a million frees.

So what? If the application meets all of the necessary requirements and SLAs, is supportable and maintainable, then why do you care if it is doing a million allocations and a million frees? Those allocations/frees aren't causing wear and tear on the memory chips.

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

[Anonymous Coward]

>It is not appropriate anywhere.

That's why 90% of Fortune 500 companies use it.

Sounds to me like someone is butt hurt about their favorite toy not having the traction Java has.

Re:Yes - Bless You

[Joce640k]

If you are writing enterprise scale code in Java, then you are wasting a lot of compute power.

I assure you that enterprises don't care about that.

The point of Java was not to make performant code easier to write, but to make code more maintainable.

No, Java was designed for embedded code in interactive TV sets:
https://en.wikipedia.org/wiki/...

The fact that people tried to use it for enterprise code was mostly down to Sun's aggressive marketing, not because Java was designed for it (or even suitable).

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:ITGLWATCDR

[Anonymous Coward]

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.

I'm working on an inherited codebase currently. It was still an obsolete version of .NET and showed all the signs of being in the valley of code and patch for awhile, such as massively complicated and intermixed classes. (I separated one to like 8 different classes.) It also had an unholy mix left and right of WPF and windows forms.

I moved it to a newer .NET, which while not state of the art is what other stuff is using. I try to build new stuff with separation of concerns, using a modern database for what it is good far (SQLite for now). One task I separated GUI elements from output code by simply using a simple internal thread safe queue, framing the interop with JSON, and framing output by liberal application of .NET reflection, so I can trivially map the JSON to the premade output classes, and handle any future variation of this task. (One of my favorite complaints from users is when they tell me, but there will never be any other variations.)

This is low rate stuff so and it is all beginning to work fine. A couple of the users seem to believe they know more than me though, and demand I recode with the GUI code strictly tied to the output and no intermediate layers. I.E. They want the provided output classes to be directly referenced in the GUI code, in the theory that it is most important to have code break with the API changes. I offered to wrap their provided classes, which would have done the same thing, but that wasn't good enough. I'm not buying it, since you would see the break as soon as you did the first test, which could be automated, but anyway....

I suppose my question how often at a big company do people get lower level people telling the people actually coding you must do it this way, cause if it breaks we are going to blame you for it if you don't? Originally this design was picked partly due to lack of requirements, since I didn't know details and would have to support anything, but in general, it seems a pretty good design from what I can tell, since if they need to change functionality, they can do it themselves, and if we need to support something new, it is trivial. Performance might not be optimal, but for this, there is no need.

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: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.

Terrible yes, but still very useful

[Anonymous Coward]

The C++ language standard is like petrol or dynamite. You can use it to do great things or disastrous things. It's productive use depends on the skill and judgement of the user. The language standard provides many temptations for mischief. But well hidden in the standards committee cruft is a tool set capable of making high performance maintainable code solving complex problems. That hidden subset is a pretty high standard which few, if any other languages meet.

What's terrible is that the only way I can get this subset is by continually fending off temptations. This is near impossible in a team environment. And definitely to be avoided (Python?) if performance is not necessary.

Given the size of the C and C++ codebase, I suspect this problem will be with us for quite some time. Instead of complaining how terrible it is, what can be done to improve the situation. For problems that require large code bases and direct hardware level performance, what other options are available? What can be done the refocus the standards committee on something productive?

Re:Obcious

[theweatherelectric]

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

No.

What an insulting question

[Anonymous Coward]

Has C++ become a horrific mess that we should ultimately relegate to the bins of COBOL and Pascal?

That's one of the nastiest things I have ever seen anyone ever imply about a programming language.

Why would someone say such a vicious thing about COBOL and Pascal?

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.

Re:Yes - Bless You

[Anonymous Coward]

I would change just one thing.

Don't use java for anything, and just let it die.

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

[Joce640k]

No it hasn't moved or yes the 1990s C++ criticisms are still valid?

C++ is gonzo because they hate keywords

[Anonymous Coward]

the real reason C++ is a dumpster fire gonzo crazy language is the language designers hate adding keywords, so they overload existing ones and add punctuation as syntax - that's where C++ went horribly wrong - a few breaking changes to add sane, descriptive keywords to replace punctuation would have helped - i looked at lambdas in C++ and just gave up

All programming language are awful

[Anonymous Coward]

And from time to time people try to use the wrong language in the wrong way.

Re: Yes - Bless You

[Anonymous Coward]

Jai is specifically meant to be a good tool for experts.

No PMP Certified

[Anonymous Coward]

Nothing quite like putting PMP after your name.

http://projectmanagementplus.com/

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.

Lisp

[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.

It's call Lisp.

Re: Yes - Bless You

[Anonymous Coward]

So what? Nobody writing performance critical software use Java, Java is just another one of those pesky bacteria that infest our infrastructure. Large companies use many languages and are pretty much forced to use Java in some contexts.

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.

Why would it be bad?

[Anonymous Coward]

If one thinks C++ to be hard.. save everyone's time.. and leave Tech field. If learning that is hard for you thatn you are worthless with dealing with anything really difficult.

Re: Yes - Bless You

[Anonymous Coward]

They use java because colleges churn out tens of thousands of java monkeys every year.

That is the ONLY reason.

FreePascal & Delphi prove him wrong... apk

[Anonymous Coward]

See subject: Neither has the buffer overflow problems C has (security issues & unless you send 2 pointers into a string to determine its length (1 being 2x the size of the other & wait for error on larger + double size of smaller former)) = hassle!

* NOTE HOW HE HAS TO SAY "IN PASCAL'S 'STD. FORM'" LOL - the ABOVE is PART OF WHY HE HAS TO TRY THAT BULLSHIT!

I also love his STATIC bullshit - Variables that are LOCAL to a proc/function STAY THAT WAY (& destruct @ proc ending, even if ABORT or EXIT is used - their SCOPE is limited there). You have global vars IF You need them OR GLOBAL CONSTANTS too (so much for that CRAP too). HOWEVER - you CAN PASS variable values to other procedures (via functions), again, so much for his BULLSHIT!

No sensible way to deal w/ files? BULLSHIT - I do it everyday using Object Pascal & it works (as do 100's of 1,000's of my users too).

No way to compile LARGE programs? What is ticketmaster?? It's done largely in Delphi (& I've done programs that number into the MILLIONS OF LINES that run entire companies' info. infrastructure using DELPHI).

NO ESCAPE?? WTF is EXIT or ABORT I noted above??

He's FULL OF SHIT!

* I'd take that FOOL on any day of the week on Pascal vs. C & utterly DESTROY him (see above).

Object Pascal in Delphi DESTROYED MSVC++ in string & math performance BY DOUBLE - explain THAT Mr. K., please (every program works in them) in VB Programmer's Journal Oct 1997 issue "Inside the VB5 Compiler" w/ Delphi WINNING 4/6 tests & tying in 1 (losing only 1 which C++ lost to VB too).

APK

P.S.=> REPEAT - Kernighan is FULL OF SHIT - bring him here & I'll rip him a new asshole in seconds with the list above, easily... apk

Identity issue

[Anonymous Coward]

If I want to develop fast, I use C# or Java. Absolutely wonderful languages, mainly C#. If I want to go low level, Iâ(TM)ll use C. I still find C to be an amazing language. While not as productive as higher level languages, C is a very clear programming language, and powerful. As for C++, it is simply trying too hard to be too many things at the same time, while not being really good at none. Not as clear and simple as C. Not nearly as productive and elegant as C# (or Java).

I mean, if I think, C, I think procedure oriented. If I think C#, I clearly think about objects. When I thick about C++, yeah sure, it is object oriented, but itâ(TM)s not focused... its kind of a mesh of ideas, itâ(TM)s a mess.

Correct & I did recently... apk

[Anonymous Coward]

See subject & APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p (remove spaces between characters & download).

Yields more security/speed/reliability/anonymity vs. any SINGLE solution (99% of threats = hostnames vs. IP address that most firewalls use) more efficiently/FASTER + NATIVELY 4 less!

(Vs. "Bolt on 'MoAr' illogic-logic" competitors slowing you, hosts speed you up 2 ways (adblocks + hardcodes u spend most time @) vs. competition loaded w/ security bugs (DNS/AntiVir) + overheads (messagepass ('souled-out' to advertiser addons) + filtering drivers) & their complexity leads to exploitation).

* ONLY 1 of its kind in GUI on Linux!

Better vs. Windows model in speed/efficiency/merge.

APK

P.S.=> I chose Object Pascal over C for 2 reasons: BETTER string (& math) PERFORMANCE vs. C++ & C bufferoverflows (stated @ outset of https://developers.slashdot.or... )... apk

Registered /.ers review of the Win64 model

[Anonymous Coward]

Your software is just fine - well written, functional... I'm going to continue using the Host File Engine by mmell February 17, 2017

Your premise that hostfiles are a good way to deal with advertising and malvertising is quite valid - by JazzLad April 20, 2016

his hosts program is actually pretty good by xenotransplant August 10 2015

his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg September 25 2015

I like your host file system by Karmashock September 09 2015

that APK guy, I use his host file by rogoshen1 Tuesday March 03, 2015

I personally use a HOSTS file blocker produced from a genius called APK by 110010001000 October 27 2017

* Best part = Linux 64-bit model's faster/more efficient (2x work in 1/2 the time)

APK

P.S.=> For a faster/safer/more reliable internet... apk

What niche does C++ fill?

[Anonymous Coward]

Several other languages have been mentioned as alternatives, or improvements, over C++. But it is not completely clear in this discussion, where Java is so superior to C++, other than obvious hardware interfaces.

This discussion should focus on problem solving solutions, not on low level hardware interfaces or on performance issues related to virtual machines or bytecode.

The best quote of this discussion was from Bjarne Stroustrup's interview at MIT, page 12 on the need for expert programmers. He favors C++ as an expert friendly language.

http://www.stroustrup.com/MIT-TR-original.pdf

You can also say that the C language is also an expert friendly language. Each language has it's niche, and C has a niche in system software not shared by C++, Java, or Javascript (barf).

So this discussion should focus on what niche C++ fits in, and what niches it doesn't fit in.

C++ is a greatly documented language.

[Anonymous Coward]

.....and you need a lot of books to elarn C++. It is a great experiment in language design.... and if you need to do actual programming, there's always C and COBOL and Java.

Re: Yes it is, Java is the answer

[Anonymous Coward]

Hmmm. I think the -1 in this case means

"You are wrong and a fucking idiot"

But, he was trolling, you were trolling. Am I trolling?

Re: Yes it is, Java is the answer

[Anonymous Coward]

List one of these extremely valid points he brings up. Should be easy since you said he's stated a couple ;)

We will wait....

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: Worth repeating..

[Anonymous Coward]

I prefer PLANC.

Anybody have that crabby patty recipe? :bad joke I know. Sue me Bruce. ;)

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

[Anonymous Coward]

Or better yet, write a great piece of music.

Electronic music has allowed people who don't know how to write music to nonetheless compose vast pieces that are currently more popular judging by concert attendance and revenue than classical and jazz.

Western music notation is a little tricky to learn and harder to read spontaneously for players, who if not improvising act as playback device.

Composing (coding) music in western notation has allowed people to create horrible and great music -- skilled composers versus lousy composers, all using the same language.

Some avant guard composers invented new notation for experimental pieces but these weren't adopted outside of tiny circles of composers.

Perhaps the questions should be (1) what computer language most limits the accidental creation of security flaws by Average programmers and (2) what language provides the best performance?

The answer to the latter used to be assembly language back in the day.

Poor developers and libraries plague every languag

[Anonymous Coward]

Poor developers and libraries plague every language except those that are overly simple or poorly supported. As someone who has been writing software professionally for over 25 years Iâ(TM)ve seen very poorly designed libraries (packages, assemblies, or modules) in many languages, from Bash and Perl, to Java and C#, to C, C++, and assembly. The cause is always weak design and analysis skills, a rush to get something done, and poor or non-existent testing environment. Historically, C++ was the most widely used and supported of the early OO languages and this shows in the legacy features of pre-C++17 standard. Many lessons learned by users of early versions of C++ shaped latter languages, but took time to be integrated back into C++ because of the standards process. The standards process, often lamented, is one of the greatest assets of C++ since no single individual, small group, or company owns C++. Ultimately it is strong analysis and design skills, and a rich testing environment, that produces quality software.

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.

another bad programmer

[Anonymous Coward]

another bad programmer claiming himself a game developer.. Mammoths doesn't fall from sky because of C++..

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.

Is there a batter alternative to it?

[Anonymous Coward]

C++ gives you C-like performance _and_ the ability to use high levels of abstraction. Of course, it needs quite a skill to achieve both simultaneously, but at least it's _possible_!

Is there any other language out there that gives these two diametrically opposite features? As long as there isn't one, C++ will continue to be used as heavily as it currently is.

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?

C++ without C++

[Anonymous Coward]

Are there better or easier to use languages that weren't created by using C++? Python was created with C++ (I believe) so isn't any appeal to another language that was built in C++ just a praise for a library of C++?

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.)

Re:Yes - Bless You

[Anonymous Coward]

or are rigorous about always using fixed-size integer and floating point types, it is just a recompile

In short, if you write your code portably, it will be portable.

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.

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

[Anonymous Coward]

Mozilla, one of Silicon Valley's greatest success stories

You're funny.

If you are not aware of the history,

If you are not aware of who JCR is, you might want to google it. He was the person who guided Mozilla came out of the wreck that sank Netscape....

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

Re:Yes - Bless You

[Anonymous Coward]

Regular expressions: Snobol hands down.
Web development: Colt 45 to the head Russian roulette style, alternatively Python.
Client code: Simula.
Server code: Simula again.
Full stack: Lisp or APL.

Re: Yes - Bless You

[Anonymous Coward]

Popular doesn't mean better fuckstain.

Go listen to that whore Taylor Swifts latest abortion. Total hack job by a mediocre singer and shit songwriter.

Or go listen to any of that inbred shitheel country 'music'.

numbnuts

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,,,