There are many ways to look at complexity as an abstract concept. You could look at code length. Or you can count how many 'degrees of freedom' your code allows you to have, and be sure that you need to control each of those. C++ affords too much freedom for developer.
The trend meanwhile is towards reducing complexity at system/core level and focusing on application unique added value. Today, in large web applications, complex behavior is build using simple components. Those components are normally done in C, and then wrapped by some scripting language. C is not too flexible. The components are rock-solid as a result, they lack unexpected behaviour. Their code's 'degrees of freedom' are easier to control.
On top of that, there is trend towards frameworks in scripting languages which reduces 'degrees of freedom' at core/foundation level even further. Finally, there is this REST thing that wants to standardize API of a typical web app, offering us even larger blocks to code to work with. Again, all these trends have one objective - allowing to focus on unique application functionality, on interaction with other systems etc and hiding underlying complexity from the developer.
By using C++ you are likely to get complex behaviour in your code very early, at a very fundamental level. As you add functionality, the complexity/behaviour quirks will grow exponentially and you will fail.
I am convinced that Microsoft failure with Vista is mostly due to them using C++. They were simply defeated by mounting complexity, not by lack of engineering talent. Meanwhile, Unix success (Apple OS X included) is determined by relative 'dumbness' of underlying C language, Unix tradition of small single-purpose tools etc.
Interesting, thanks for sharing. So do you think I should avoid C++ altogether and stick to C? What about Google? Google uses C++ a lot and they seem pretty fine/stable to me? Maybe C++ can be good web architectural stuff (not as complex as an operating system)?
treat the c++ standard as an assembly language of sort, from which higher level langs are built, like boost. if you look at it this way, you can carve out a sane section and deal with it. if you try to hold the entirety of it in your head and code, its hell
Can anyone recommend a book that deals with the web/server-side aspect of C++ coding? I'm nearly half way through Thinking in C++ by Bruce Eckel (wonderfully well written!) but it doesn't look like it's getting near there.
There are many ways to look at complexity as an abstract concept. You could look at code length. Or you can count how many 'degrees of freedom' your code allows you to have, and be sure that you need to control each of those. C++ affords too much freedom for developer.
The trend meanwhile is towards reducing complexity at system/core level and focusing on application unique added value. Today, in large web applications, complex behavior is build using simple components. Those components are normally done in C, and then wrapped by some scripting language. C is not too flexible. The components are rock-solid as a result, they lack unexpected behaviour. Their code's 'degrees of freedom' are easier to control.
On top of that, there is trend towards frameworks in scripting languages which reduces 'degrees of freedom' at core/foundation level even further. Finally, there is this REST thing that wants to standardize API of a typical web app, offering us even larger blocks to code to work with. Again, all these trends have one objective - allowing to focus on unique application functionality, on interaction with other systems etc and hiding underlying complexity from the developer.
By using C++ you are likely to get complex behaviour in your code very early, at a very fundamental level. As you add functionality, the complexity/behaviour quirks will grow exponentially and you will fail.
I am convinced that Microsoft failure with Vista is mostly due to them using C++. They were simply defeated by mounting complexity, not by lack of engineering talent. Meanwhile, Unix success (Apple OS X included) is determined by relative 'dumbness' of underlying C language, Unix tradition of small single-purpose tools etc.