Short answer: Because (a) the syntax is clumsy and limited, and (b) the range of tools in the language and standard library is also mostly limited to the basics.
It's not that you can't do some of these things in C++ in those basic cases. But please consider that very simple transform algorithm we mentioned. While you're writing the example code you gave:
for (auto & p : my_map) p.second = foo(p.second);
someone using a language with better support for manipulating data in this style is writing something like this instead:
map foo my_map
If you're writing out a whole loop longhand every time you need to do something like this then of course that takes more boilerplate and uses a lot more space. That already requires more brain on the part of someone reading your code than just naming a common pattern and calling it.
This approach also does little to help reuse or composition. When you start wanting to combine different operations over your data and scaling up to more demanding data processing requirements, of course you can just throw more logic into your loop, but now your reader has to parse the whole thing and spot the little accumulation you tucked in there, or notice the part where you skipped an item by updating the loop control variable within the loop body, or whatever.
Over the entirety of a large program that does non-trivial data crunching, these overheads can add up to a lot of boilerplate to read and write, subtle deviations from expected patterns that lead to bugs, and perhaps worst of all, a much more limited "vocabulary" for expressing common programming patterns that means you're always getting bogged down in the details instead of looking at the bigger picture.
I get the impression that you aren't familiar enough with C++ to appreciate its flexibility and expressiveness, much as I'd have a lot of trouble expressing common C++ stuff in Haskell.
I've been programming C++ professionally for more than 20 years, I've trained other professional developers up to and including senior levels in programming techniques using C++, and I've been involved in plenty of discussions along the way that brought some of those features you mentioned into the more recent standards. My appraisal of the relative strengths and weaknesses in C++ is not born of ignorance, it's born of using it for a long time and learning its good and bad points the hard way, combined with experience using other languages that do some of these things much, much better.
Sorry, I just spent an hour or so mocking up a complete, working Haskell program to illustrate some of the ideas I'm talking about for you, but apparently Slashdot thinks Haskell code has too many junk characters to include any lengthy code samples in a comment, and it massacres the whitespace in a whitespace-sensitive language even if I only post in short snippets. That's frustrating.
In any case, just to be clear, I'm not suggesting that Haskell is necessarily a better language than C++ for any given purpose. Haskell has its pros and cons, like any language. It just happens to provide some convenient examples of useful and quite powerful language features that aren't in C++'s repertoire.
It is fascinating how easily some people assume that they know better than you because you have a different point of view to theirs. I haven't the slightest interest in getting into an anatomy measuring contest with you, but you might like to consider the possibility that you're not the only poster on Slashdot today who has been doing this a while and spent time thinking about these things, and that other people might simply have reached other conclusions.
The list you gave is basically only valid for academic languages.
Some of those features are widely available even in very mainstream languages like JavaScript and Python, and all of them are available in languages used for plenty of professional work in industry.
Guaranteed tail call elimination, wow, what an awful term. Obviously this is compiler/vendor specific if a compiler does 'tail call optimization' in recursive calls.
Guaranteed tail call elimination is essential if you want to be able to implement your own control structures using recursion. Unlike C and C++, languages designed to support that programming style do mandate it as part of their specifications. It's not just about optimisation in that context.
C++ has more in common with C# on a VM than with C.
The original subject of the discussion was where using C or C++ was still a good choice. Unless you know a lot of.Net implementations that run on microcontrollers with available RAM measured in kilobytes if you're lucky, C++ and C have a lot more common in that area than either does with C#.
You seem not to grasp the huge difference between OO, templates, STL and low level C programming.
I've never said, anywhere in this whole discussion, that C and C++ were somehow the same language or didn't have significant differences. I've primarily argued that in the big picture, they are very similar in the use cases where they do or don't work well, and I stand by that. I've also argued that C++ in particular is missing a lot of useful functionality that is widely available elsewhere, and I've given specific examples for comparison. I don't know how you could read my comments here and somehow think I don't know what OO or templates are.
A computer scientist should be able to work with dynamically typed "scripty" languages, systems oriented code, and functional languages all equally.
A computer scientist has very little to do with programming at all.
Even if you were trying to sound smart there and you actually just meant a competent working programmer, your claim would still be silly. It takes significant experience to write sound, idiomatic code in each of the fields you mentioned. Someone blundering in thinking they know what they're doing and trying to apply the conventions and practices from a very different style out of context can easily do more harm than good, introducing subtle bugs, unexpected performance characteristics, or simply leaving corner cases as traps for the unwary later.
To be deficient in any is to not really understand your field.
No-one really understands everything in programming. You could spend a lifetime studying what we've already built today and still not be an expert on all of it, even if nothing was changing along the way.
If you don't think the programming field is that vast, you just haven't seen enough of it yet.
Inertia is surely a factor even so. There is no technical reason you couldn't have a language that retained the low-level control and flexibility of C while still being significantly safer, having much cleaner syntax, and including useful features that made the language more powerful but that could be implemented with no runtime overhead. But even if you did invent such a language, you'd still have to convince developers working on these kinds of applications to use that new language in preference to the global lingua franca of programming they all know already, and you'd still have to provide a way to link code written in your new language with the vast ecosystem of existing C-based libraries and APIs. That's a tall order, no matter how brilliant your new language itself might be.
Yes, real time is another field where the relative transparency of C and C++ are a big advantage. It's tough to have a heavyweight runtime and rely on things like garbage collection if you're literally on a clock.
I disagree. It may seem so on your level of skill, but advance enough and the distinctions come back.:-)
(In case you think I'm the guy who's a year out of university and only ever programmed Java and Python so he hasn't spotted the common patterns yet, you might like to check my recent posting history. I'm not that guy.)
There's a world outside America. If you want to be part of it you can either set yourself up for failure or do it efficiently allowing for easy translation afterwards.
I know; I'm not American. But you're grossly oversimplifying the commercial decisions here.
Have you programmed such UIs before? Most of this is handled by locales in the OS and in the underlying API.
Yes I have, and no it's not. You're talking about trivial details like the conventions for printing dates and times or getting the right currency symbol. That's the easy stuff. Even things like addressing aren't nearly as easy as you're making them out to be. (Obvious example: How will you match up your proposed address schema with the databases for validating payment credentials, which almost certainly won't be in the same format? Get this one wrong and large numbers of purchases in the affected country may simply fail, so think before you answer.)
One point of the EU is that the block of countries is actually incredibly similar in everything they do.
Again, that's the nice, ideal world theory talking. In reality, the EU is composed of many member states with their own cultures and languages and conventions, not to mention very different economics. Even simple things like paying for things work sometimes completely differently in different nations within the EU. And again, we're only talking about the visible surface here. Under the surface, if whatever your software deals with is itself sensitive to the local context, it's an entirely different game again.
If you really think i18n support is some sort of binary state, then again, I'm afraid that's just lack of experience on your part talking. That's understandable, because like much in software development you don't see all the little details until you try to do it for real. But the situation is still what it is, and the cost of porting even an already internationalised code base to support some new location still isn't necessarily trivial.
You can do all of those [first-class function treatments] in C++.
You can emulate the function treatments using function pointers in basic cases. It's really not the same as using a language designed to support a more functional programming style from the start, though.
The STL had the right sort of idea, but there's a big difference in the level of expressive power between the standard library containers and algorithms and iteration patterns offer in C++, even used with more recent language features like lambda expressions, and features like folds and traversals or combinators and computation patterns in a language like Haskell that specialises in this style of programming.
If you haven't come across some of those functional programming concepts, you can just compare the breadth and depth of algorithms for navigating and transforming data structures that you get out of the box in C++ and in Haskell. In C++, you get tools like std::transform, which is essentially what most functional languages would call map, a useful but entry-level algorithm. In Haskell, you get tools like mapAccumWithKey, which represents visiting each key-value pair in a map in ascending order of keys, transforming each value according to some rule, and accumulating some state along the way, which may also be used to influence later transformations and/or state updates. Obviously one of these captures a much more specific and powerful pattern than the other.
In short, the languages and libraries are working on entirely different levels here. That is because it's so much easier to work with higher order functions and function composition and partial application and closures and so on in a functional programming language. It then makes sense to have both many simple utility functions and many powerful higher-order functions for navigating and transforming data structures in the standard library. If you've only got function pointers rather than true first-class functions, as in C and C++, you don't have the glue to make those kinds of tools useful in practice. Comparing modern C++ to a language that is designed to support this sort of style well is a bit like comparing 1998 era C++ and standard library algorithms with 2017 era C++, except that the gap in the first case is much wider.
Just as a final point on this one, of course I'm choosing an extreme by putting C++ up against Haskell, but many other mainstream languages are significantly more developed in this respect than C++, even if most of them don't go as far as some of the examples I gave here.
We've had food sets and maps in the STL since about 1994 when it was still called the STL and published by SGI.
Sure, but again it's an entirely different (and much less powerful) level to languages with more robust support for these data structures. C++ has a useful std::map type, with an interface containing functions like begin, end and clear. Other parts of the programming world are taking nested maps, picking out a subset of the top-level map according to some predicate based on the key, value or both of each entry, flattening the structure a level, and then doing a deep merge of another similarly structured nested map with explicit rules for resolving any intersections, and again they're often doing this kind of thing with just a few short lines of code and with the basic patterns provided either via the standard library or directly via built-in language features.
You're still making C and C++ sound far more similar than they are. in practical terms, modern C++ look more like C-syntax python than it does C.
I think that's a bit of a stretch, but I understand your point. Nowhere in this thread have I tried to equate C and C++. I've programmed both for many years. I was part of some of the discussions on the C++ standard that led to some of the changes in more recent editions.
Yes, I agree that C++ (and C) are still good choices for the kind of work you described. I've worked on some of those too, and there wouldn't have been many other viable choices for those jobs. I just think the number of jobs where this is the case is trending downwards.
In particular, I think it will trend down sharply if and when we reach the point that higher level languages with more expressive semantic models can be compiled to run more efficiently on the relevant hardware than C or C++ code that is written closer to the metal. I see this as directly analogous to the situation with C or C++ compared with assembly language today: it is self-evident that assembly language could equal or better anything that C or C++ compiled to the same level could do in performance terms, but only if whoever is writing that assembly code is better at it than a modern C or C++ compiler, which is rarely going to be the case these days. Particularly with parallel execution and the complications of shared state, aliasing, etc, I don't think this situation is unrealistic, though it's difficult to gauge how close we might be to achieving it in practice.
I'll address your other points in reply to your other comment a bit later.
Exactly. I've been programming a long time, and I've been lucky to work with a few very capable developers during my career. Some of the best had probably mastered as many as 2 or 3 different programming languages. I doubt any of them would have claimed mastery of more than that.
The broad range of concepts you speak of are covered in any reputable computer science degree.
Perhaps, but only at the most elementary of levels. There is quite a difference between understanding basic memory management in C and hacking on the Linux kernel, or between understanding the general idea of functional programming and maintaining a large-scale production system written in Haskell.
It looks like we have similar levels of experience and we'd agree on almost everything else you mentioned, particularly the parts about learning the domain often being harder than learning the language skills. But I think you do still need a certain facility with the language and libraries you're using, even as a maintenance programmer, if you're not going to know just enough to be dangerous. I wouldn't assume that a programmer who was generally competent with the programming language(s) they'd used previously would necessarily acquire that facility quickly in a different language without help, unless the new language was very similar to something they'd used before in its programming style and idioms.
I've been learning how to be a programmer for more than 30 years and doing it professionally for more than 20. I've worked on code from web front-ends to high performance number crunching, via databases and device drivers. I've written production code in my share of different languages and in a variety of programming styles.
However, I'd still say I'm only "initially getting my feet wet" when I start many new projects, compared to someone who really understands that particular area. I'm a competent programmer by any reasonable standard, but I would never presume that I was qualified to maintain software written in an unfamiliar language and style just because that language came with a reference manual.
Almost no mainstream programming language is truly interpreted any more, though, unless you're talking about something like a REPL interface. Even the JavaScript in your browser and that Python script you wrote the other day to parse a log file are actually JIT compiled behind the scenes these days, and will probably get within a factor of 2-3 of the performance of true compiled languages in most cases. The VM-hosted static languages like Java and C# have been in that position for a long time, and get closer still in performance terms once you're passed any startup costs.
This isn't to say there aren't plenty of horribly unresponsive UIs and other inefficient code around, but that's rarely the fault of the language itself any more.
C++ meanwhile supports basically everything other modern languages provide.
Here are a few useful language features that are available in some other modern languages but not in C++:
First-class functions and closures
First-class structured data like sets and maps
Algebraic data types and pattern matching
Guaranteed tail call elimination
Hygienic macros, monkeypatching, reflection, and other metaprogramming tools
C++ does provide more limited alternatives to some of these, via the standard library or external libraries. However, because of the historical baggage, you still can't fix the awful syntax even then.
C and C++ are not the same thing, so making a very long statement about both of them is most certainly always wrong for one of the two languages.
That doesn't follow at all. Obviously the languages differ significantly, but fundamentally they have many of the same strengths and weaknesses that make them either suitable or not suitable for any given programming job. C and C++ have far more in common with each other than either of them has with a heavy runtime language like C#, a dynamic language like Python or a functional language like ML. Which of C and C++ you choose is typically more about whether you prefer the relative simplicity and transparency of one or the additional expressive power from the language features of the other.
The cost of translating is relatively low. Translators don't get paid much, unless they are doing really specialist work.
I think you're assuming some sort of direct translation, for something like a document or the soundtrack of a movie. If you're talking about something more complicated, like the UI for a software product that includes other aspects that might need to be localised for each regional market, it's an entirely different question.
The same with software. Re-writing code to translate everything into a different language is expensive. Writing a program to read the interface from a file is the same cost.
But writing code to read the interface from a file rather than encoding it in some other way may be a significant cost in itself. Perhaps more significantly, in internationalised UIs, we're typically not just talking about translating text. The whole infrastructure of your UI code may need to be different to support different time and date conventions, currency conventions, address and phone number formats, and so on. Again, the cost of generalising here may be quite significant, and it is not necessarily the same work with trivial language substitutions from one market to another. This all assumes that the functionality of your software isn't itself tied to some local standards, so it's just the UI that you need to localise.
If you think doing this for a large piece of software, with a complex UI that includes a lot of specialist terminology and notation, that needs to support a lot of different geographical and linguistic regions, costs "next to nothing", then I have to think that you've never actually done it.
For that to be the case, it would have to be sold at below cost in those poorer countries, since a profit of 1p is still more than a revenue of 0 when you've already paid to produce the goods or service.
That doesn't follow if pricing in the poorer and richer states is artificially forced to the same level by law.
Which would be dumping and proof that the free market is broken and cannot and will not work.
These laws mean it's not a free market. They artificially constrain pricing so that suppliers can't offer what consumers want at a price they are willing to pay for it. They call it a "single market" but in reality when purchasing power is so different in different parts of it, it's not naturally a single market at all.
And understanding the domain and real world requirements often matters more than knowing any particular algorithms or data structures. However, someone who understands those things and knows well the programming language being used is still going to get better results than someone who understands those things but isn't as familiar with the programming language.
This is a popular conceit, but it's still a conceit. The skills and concepts and idioms you need to work with dynamically typed "scripty" languages to write a web app are quite different to the ones you need to to work with high performance systems programming code to write device drivers, and those are different again to the ones you need to implement a compiler in a functional programming language. Programming is a vast field, and experience in one part of it doesn't necessarily make someone any good at working in another part of it just because there's a reference manual.
I wouldn't even say those are the big advantages of C and C++ any more.
It's a relatively rare application these days that needs the kind of raw speed you can't achieve with other mainstream languages yet which relies on C or C++ for its performance-critical logic rather than either dropping to assembly (or linking to someone else's library that probably does) or resorting to some form of parallelism. I'm certainly not saying that set is empty, but it's probably getting smaller by the year.
As for expressivity, if you mean how easy it is to express any particular idea in code, C and C++ are relatively weak compared to many other mainstream languages today. They lack many convenient language features widely available elsewhere, and their standard libraries aren't exactly broad and full-featured so you have to bring in additional dependencies to do almost anything useful.
The area where C and C++ still shine compared to almost anything else (and I realise this might have been what you meant by "expressivity" instead) is the low-level control. You can deal with memory and ports and interrupts and so on very transparently in these languages, and they have a very lightweight runtime with minimal dependencies that makes them suitable for use in things like systems programming and writing software for embedded devices with limited resources.
Slashdot Mirror
Why do you think any of this is difficult in C++?
Short answer: Because (a) the syntax is clumsy and limited, and (b) the range of tools in the language and standard library is also mostly limited to the basics.
It's not that you can't do some of these things in C++ in those basic cases. But please consider that very simple transform algorithm we mentioned. While you're writing the example code you gave:
someone using a language with better support for manipulating data in this style is writing something like this instead:
If you're writing out a whole loop longhand every time you need to do something like this then of course that takes more boilerplate and uses a lot more space. That already requires more brain on the part of someone reading your code than just naming a common pattern and calling it.
This approach also does little to help reuse or composition. When you start wanting to combine different operations over your data and scaling up to more demanding data processing requirements, of course you can just throw more logic into your loop, but now your reader has to parse the whole thing and spot the little accumulation you tucked in there, or notice the part where you skipped an item by updating the loop control variable within the loop body, or whatever.
Over the entirety of a large program that does non-trivial data crunching, these overheads can add up to a lot of boilerplate to read and write, subtle deviations from expected patterns that lead to bugs, and perhaps worst of all, a much more limited "vocabulary" for expressing common programming patterns that means you're always getting bogged down in the details instead of looking at the bigger picture.
I get the impression that you aren't familiar enough with C++ to appreciate its flexibility and expressiveness, much as I'd have a lot of trouble expressing common C++ stuff in Haskell.
I've been programming C++ professionally for more than 20 years, I've trained other professional developers up to and including senior levels in programming techniques using C++, and I've been involved in plenty of discussions along the way that brought some of those features you mentioned into the more recent standards. My appraisal of the relative strengths and weaknesses in C++ is not born of ignorance, it's born of using it for a long time and learning its good and bad points the hard way, combined with experience using other languages that do some of these things much, much better.
Sorry, I just spent an hour or so mocking up a complete, working Haskell program to illustrate some of the ideas I'm talking about for you, but apparently Slashdot thinks Haskell code has too many junk characters to include any lengthy code samples in a comment, and it massacres the whitespace in a whitespace-sensitive language even if I only post in short snippets. That's frustrating.
In any case, just to be clear, I'm not suggesting that Haskell is necessarily a better language than C++ for any given purpose. Haskell has its pros and cons, like any language. It just happens to provide some convenient examples of useful and quite powerful language features that aren't in C++'s repertoire.
It is fascinating how easily some people assume that they know better than you because you have a different point of view to theirs. I haven't the slightest interest in getting into an anatomy measuring contest with you, but you might like to consider the possibility that you're not the only poster on Slashdot today who has been doing this a while and spent time thinking about these things, and that other people might simply have reached other conclusions.
#1 is done by gcc (it adds code to do just that).
And what do we call extra code supplied by our tools that we didn't write ourselves, boys and girls?
And #2 is the Linux kernel.
You do understand that there are platforms in the world other than Linux and C++ compilers other than gcc, right?
The list you gave is basically only valid for academic languages.
Some of those features are widely available even in very mainstream languages like JavaScript and Python, and all of them are available in languages used for plenty of professional work in industry.
Guaranteed tail call elimination, wow, what an awful term. Obviously this is compiler/vendor specific if a compiler does 'tail call optimization' in recursive calls.
Guaranteed tail call elimination is essential if you want to be able to implement your own control structures using recursion. Unlike C and C++, languages designed to support that programming style do mandate it as part of their specifications. It's not just about optimisation in that context.
C++ has more in common with C# on a VM than with C.
The original subject of the discussion was where using C or C++ was still a good choice. Unless you know a lot of .Net implementations that run on microcontrollers with available RAM measured in kilobytes if you're lucky, C++ and C have a lot more common in that area than either does with C#.
You seem not to grasp the huge difference between OO, templates, STL and low level C programming.
I've never said, anywhere in this whole discussion, that C and C++ were somehow the same language or didn't have significant differences. I've primarily argued that in the big picture, they are very similar in the use cases where they do or don't work well, and I stand by that. I've also argued that C++ in particular is missing a lot of useful functionality that is widely available elsewhere, and I've given specific examples for comparison. I don't know how you could read my comments here and somehow think I don't know what OO or templates are.
What do you think initializes your static variables, parses your command line to provide argv/argc, etc?
A computer scientist should be able to work with dynamically typed "scripty" languages, systems oriented code, and functional languages all equally.
A computer scientist has very little to do with programming at all.
Even if you were trying to sound smart there and you actually just meant a competent working programmer, your claim would still be silly. It takes significant experience to write sound, idiomatic code in each of the fields you mentioned. Someone blundering in thinking they know what they're doing and trying to apply the conventions and practices from a very different style out of context can easily do more harm than good, introducing subtle bugs, unexpected performance characteristics, or simply leaving corner cases as traps for the unwary later.
To be deficient in any is to not really understand your field.
No-one really understands everything in programming. You could spend a lifetime studying what we've already built today and still not be an expert on all of it, even if nothing was changing along the way.
If you don't think the programming field is that vast, you just haven't seen enough of it yet.
Inertia is surely a factor even so. There is no technical reason you couldn't have a language that retained the low-level control and flexibility of C while still being significantly safer, having much cleaner syntax, and including useful features that made the language more powerful but that could be implemented with no runtime overhead. But even if you did invent such a language, you'd still have to convince developers working on these kinds of applications to use that new language in preference to the global lingua franca of programming they all know already, and you'd still have to provide a way to link code written in your new language with the vast ecosystem of existing C-based libraries and APIs. That's a tall order, no matter how brilliant your new language itself might be.
Yes, real time is another field where the relative transparency of C and C++ are a big advantage. It's tough to have a heavyweight runtime and rely on things like garbage collection if you're literally on a clock.
I disagree. It may seem so on your level of skill, but advance enough and the distinctions come back. :-)
(In case you think I'm the guy who's a year out of university and only ever programmed Java and Python so he hasn't spotted the common patterns yet, you might like to check my recent posting history. I'm not that guy.)
There's a world outside America. If you want to be part of it you can either set yourself up for failure or do it efficiently allowing for easy translation afterwards.
I know; I'm not American. But you're grossly oversimplifying the commercial decisions here.
Have you programmed such UIs before? Most of this is handled by locales in the OS and in the underlying API.
Yes I have, and no it's not. You're talking about trivial details like the conventions for printing dates and times or getting the right currency symbol. That's the easy stuff. Even things like addressing aren't nearly as easy as you're making them out to be. (Obvious example: How will you match up your proposed address schema with the databases for validating payment credentials, which almost certainly won't be in the same format? Get this one wrong and large numbers of purchases in the affected country may simply fail, so think before you answer.)
One point of the EU is that the block of countries is actually incredibly similar in everything they do.
Again, that's the nice, ideal world theory talking. In reality, the EU is composed of many member states with their own cultures and languages and conventions, not to mention very different economics. Even simple things like paying for things work sometimes completely differently in different nations within the EU. And again, we're only talking about the visible surface here. Under the surface, if whatever your software deals with is itself sensitive to the local context, it's an entirely different game again.
If you really think i18n support is some sort of binary state, then again, I'm afraid that's just lack of experience on your part talking. That's understandable, because like much in software development you don't see all the little details until you try to do it for real. But the situation is still what it is, and the cost of porting even an already internationalised code base to support some new location still isn't necessarily trivial.
You can do all of those [first-class function treatments] in C++.
You can emulate the function treatments using function pointers in basic cases. It's really not the same as using a language designed to support a more functional programming style from the start, though.
The STL had the right sort of idea, but there's a big difference in the level of expressive power between the standard library containers and algorithms and iteration patterns offer in C++, even used with more recent language features like lambda expressions, and features like folds and traversals or combinators and computation patterns in a language like Haskell that specialises in this style of programming.
If you haven't come across some of those functional programming concepts, you can just compare the breadth and depth of algorithms for navigating and transforming data structures that you get out of the box in C++ and in Haskell. In C++, you get tools like std::transform, which is essentially what most functional languages would call map, a useful but entry-level algorithm. In Haskell, you get tools like mapAccumWithKey, which represents visiting each key-value pair in a map in ascending order of keys, transforming each value according to some rule, and accumulating some state along the way, which may also be used to influence later transformations and/or state updates. Obviously one of these captures a much more specific and powerful pattern than the other.
In short, the languages and libraries are working on entirely different levels here. That is because it's so much easier to work with higher order functions and function composition and partial application and closures and so on in a functional programming language. It then makes sense to have both many simple utility functions and many powerful higher-order functions for navigating and transforming data structures in the standard library. If you've only got function pointers rather than true first-class functions, as in C and C++, you don't have the glue to make those kinds of tools useful in practice. Comparing modern C++ to a language that is designed to support this sort of style well is a bit like comparing 1998 era C++ and standard library algorithms with 2017 era C++, except that the gap in the first case is much wider.
Just as a final point on this one, of course I'm choosing an extreme by putting C++ up against Haskell, but many other mainstream languages are significantly more developed in this respect than C++, even if most of them don't go as far as some of the examples I gave here.
We've had food sets and maps in the STL since about 1994 when it was still called the STL and published by SGI.
Sure, but again it's an entirely different (and much less powerful) level to languages with more robust support for these data structures. C++ has a useful std::map type, with an interface containing functions like begin, end and clear. Other parts of the programming world are taking nested maps, picking out a subset of the top-level map according to some predicate based on the key, value or both of each entry, flattening the structure a level, and then doing a deep merge of another similarly structured nested map with explicit rules for resolving any intersections, and again they're often doing this kind of thing with just a few short lines of code and with the basic patterns provided either via the standard library or directly via built-in language features.
You're still making C and C++ sound far more similar than they are. in practical terms, modern C++ look more like C-syntax python than it does C.
I think that's a bit of a stretch, but I understand your point. Nowhere in this thread have I tried to equate C and C++. I've programmed both for many years. I was part of some of the discussions on the C++ standard that led to some of the changes in more recent editions.
Still, on a scale o
Yes, I agree that C++ (and C) are still good choices for the kind of work you described. I've worked on some of those too, and there wouldn't have been many other viable choices for those jobs. I just think the number of jobs where this is the case is trending downwards.
In particular, I think it will trend down sharply if and when we reach the point that higher level languages with more expressive semantic models can be compiled to run more efficiently on the relevant hardware than C or C++ code that is written closer to the metal. I see this as directly analogous to the situation with C or C++ compared with assembly language today: it is self-evident that assembly language could equal or better anything that C or C++ compiled to the same level could do in performance terms, but only if whoever is writing that assembly code is better at it than a modern C or C++ compiler, which is rarely going to be the case these days. Particularly with parallel execution and the complications of shared state, aliasing, etc, I don't think this situation is unrealistic, though it's difficult to gauge how close we might be to achieving it in practice.
I'll address your other points in reply to your other comment a bit later.
Exactly. I've been programming a long time, and I've been lucky to work with a few very capable developers during my career. Some of the best had probably mastered as many as 2 or 3 different programming languages. I doubt any of them would have claimed mastery of more than that.
The broad range of concepts you speak of are covered in any reputable computer science degree.
Perhaps, but only at the most elementary of levels. There is quite a difference between understanding basic memory management in C and hacking on the Linux kernel, or between understanding the general idea of functional programming and maintaining a large-scale production system written in Haskell.
It looks like we have similar levels of experience and we'd agree on almost everything else you mentioned, particularly the parts about learning the domain often being harder than learning the language skills. But I think you do still need a certain facility with the language and libraries you're using, even as a maintenance programmer, if you're not going to know just enough to be dangerous. I wouldn't assume that a programmer who was generally competent with the programming language(s) they'd used previously would necessarily acquire that facility quickly in a different language without help, unless the new language was very similar to something they'd used before in its programming style and idioms.
I've been learning how to be a programmer for more than 30 years and doing it professionally for more than 20. I've worked on code from web front-ends to high performance number crunching, via databases and device drivers. I've written production code in my share of different languages and in a variety of programming styles.
However, I'd still say I'm only "initially getting my feet wet" when I start many new projects, compared to someone who really understands that particular area. I'm a competent programmer by any reasonable standard, but I would never presume that I was qualified to maintain software written in an unfamiliar language and style just because that language came with a reference manual.
Almost no mainstream programming language is truly interpreted any more, though, unless you're talking about something like a REPL interface. Even the JavaScript in your browser and that Python script you wrote the other day to parse a log file are actually JIT compiled behind the scenes these days, and will probably get within a factor of 2-3 of the performance of true compiled languages in most cases. The VM-hosted static languages like Java and C# have been in that position for a long time, and get closer still in performance terms once you're passed any startup costs.
This isn't to say there aren't plenty of horribly unresponsive UIs and other inefficient code around, but that's rarely the fault of the language itself any more.
C++ meanwhile supports basically everything other modern languages provide.
Here are a few useful language features that are available in some other modern languages but not in C++:
C++ does provide more limited alternatives to some of these, via the standard library or external libraries. However, because of the historical baggage, you still can't fix the awful syntax even then.
C and C++ are not the same thing, so making a very long statement about both of them is most certainly always wrong for one of the two languages.
That doesn't follow at all. Obviously the languages differ significantly, but fundamentally they have many of the same strengths and weaknesses that make them either suitable or not suitable for any given programming job. C and C++ have far more in common with each other than either of them has with a heavy runtime language like C#, a dynamic language like Python or a functional language like ML. Which of C and C++ you choose is typically more about whether you prefer the relative simplicity and transparency of one or the additional expressive power from the language features of the other.
The cost of translating is relatively low. Translators don't get paid much, unless they are doing really specialist work.
I think you're assuming some sort of direct translation, for something like a document or the soundtrack of a movie. If you're talking about something more complicated, like the UI for a software product that includes other aspects that might need to be localised for each regional market, it's an entirely different question.
The same with software. Re-writing code to translate everything into a different language is expensive. Writing a program to read the interface from a file is the same cost.
But writing code to read the interface from a file rather than encoding it in some other way may be a significant cost in itself. Perhaps more significantly, in internationalised UIs, we're typically not just talking about translating text. The whole infrastructure of your UI code may need to be different to support different time and date conventions, currency conventions, address and phone number formats, and so on. Again, the cost of generalising here may be quite significant, and it is not necessarily the same work with trivial language substitutions from one market to another. This all assumes that the functionality of your software isn't itself tied to some local standards, so it's just the UI that you need to localise.
If you think doing this for a large piece of software, with a complex UI that includes a lot of specialist terminology and notation, that needs to support a lot of different geographical and linguistic regions, costs "next to nothing", then I have to think that you've never actually done it.
For that to be the case, it would have to be sold at below cost in those poorer countries, since a profit of 1p is still more than a revenue of 0 when you've already paid to produce the goods or service.
That doesn't follow if pricing in the poorer and richer states is artificially forced to the same level by law.
Which would be dumping and proof that the free market is broken and cannot and will not work.
These laws mean it's not a free market. They artificially constrain pricing so that suppliers can't offer what consumers want at a price they are willing to pay for it. They call it a "single market" but in reality when purchasing power is so different in different parts of it, it's not naturally a single market at all.
And understanding the domain and real world requirements often matters more than knowing any particular algorithms or data structures. However, someone who understands those things and knows well the programming language being used is still going to get better results than someone who understands those things but isn't as familiar with the programming language.
This is a popular conceit, but it's still a conceit. The skills and concepts and idioms you need to work with dynamically typed "scripty" languages to write a web app are quite different to the ones you need to to work with high performance systems programming code to write device drivers, and those are different again to the ones you need to implement a compiler in a functional programming language. Programming is a vast field, and experience in one part of it doesn't necessarily make someone any good at working in another part of it just because there's a reference manual.
Anything requiring speed and expressivity.
I wouldn't even say those are the big advantages of C and C++ any more.
It's a relatively rare application these days that needs the kind of raw speed you can't achieve with other mainstream languages yet which relies on C or C++ for its performance-critical logic rather than either dropping to assembly (or linking to someone else's library that probably does) or resorting to some form of parallelism. I'm certainly not saying that set is empty, but it's probably getting smaller by the year.
As for expressivity, if you mean how easy it is to express any particular idea in code, C and C++ are relatively weak compared to many other mainstream languages today. They lack many convenient language features widely available elsewhere, and their standard libraries aren't exactly broad and full-featured so you have to bring in additional dependencies to do almost anything useful.
The area where C and C++ still shine compared to almost anything else (and I realise this might have been what you meant by "expressivity" instead) is the low-level control. You can deal with memory and ports and interrupts and so on very transparently in these languages, and they have a very lightweight runtime with minimal dependencies that makes them suitable for use in things like systems programming and writing software for embedded devices with limited resources.
Not according to AniMoJo's interpretation, apparently.