6 ms·

Well, the 'everyone' he is talking about are some of the most respected people in the computer world, that should count for something. And while they're busy b

by dtf 17y ago

Well, the 'everyone' he is talking about are some of the most respected people in the computer world, that should count for something. And while they're busy bitching and hating and pontificating, humble unknowns are getting things done and making the world a better place. C++ is to systems programming what PHP is to web programming: the loyal packhorse that the A-list wouldn't be seen dead on.

jacquesm 17y ago
That is very true. PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. I think this is in part why the web is so disruptive, because it enables all these upstarts using very light and nimble stuff to challenge the big and established companies directly. You can pretty much tell what is enterprise stuff and what is 'quick & dirty but does the job' by comparing hourly rates for programmers. It also has everything to do with the length of time before someone can be productive in a new environment. If that length of time is very short then there is not a very high barrier, which tends to create a lot of 'wannabe' programmers in that language. By raising the bar you only end up with people that are willing to invest a large amount of time in a platform, that tends to favour people that get paid for their work, which in turn is found mostly in enterprise locations.
- jrockway 17y ago
  PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. Not sure if this is true in general. I work at a bank. We use a lot of Perl. Banks existed long before "the web", and our Perl stuff is not a web application either. All the internal web apps are Java. It is kind of weird, actually -- Java for stuff like the HR apps, and Perl for the stuff that makes us money. (If it were my decision, I would use Perl for the web apps and Haskell for the algorithmic stuff... but it's not.)
  - jacquesm 17y ago
    > We use a lot of Perl. That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is. But then again, is there even an 'enterprise scripting language' ? > All the internal web apps are Java. That's what I would expect. Sun really did some good marketing in that sphere.
    - coliveira 17y ago
      The area of a bank that generate money employs the smartest people, usually coming from academia. So, it doesn't surprise me.
      - jacquesm 17y ago
        Good point. Yours and gcheong's comment just above makes me wonder if someone missed the boat in getting an enterprise level scripting language out the door. It looks like there never was a 'natural' successor to stuff like JCL.
        coliveira 17y ago
        Sun and MS are trying to bring scripting languages to their managed environments. .NET already supports Python reasonably well (I was surprised to see that SharpDevelop http://www.icsharpcode.net/OpenSource/SD/ http://www.icsharpcode.net/OpenSource/SD/ can easily convert most of my C++ into Python).
    - gcheong 17y ago
      >> We use a lot of Perl. >That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is. I've seen a lot of Perl used in banking/finance. It really is the "Practical Extraction and Reporting Language" and certainly seemed to have almost completely replaced shell scripting in the last place I worked at. One interesting anecdote about Perl was that a group I worked in originally chose ADA as their language when they were just starting out but eventually gave up and went with Perl just because of it's relative power and simplicity. That company also has a major initiative to replace alot of what was written in Perl (and runs the company to this day) with a system written in Java. That system is still not doing any serious production work and is at least a couple years late. I don't think it has as much to do with the Java language as the "this will be the mother of all systems" approach they tried to take with it in the beginning though.
rpledge 17y ago
I completely agree. While C++ certainly isn't perfect, those of us that write real code that is used and maintained day to day can be very productive. While I know who most of the people in the article are and respect their contributions to the world of software engineering, day to day real world pressures of delivery aren't the same as an example in a book. A hammer isn't an elegant tool, but it gets the nail into the wood.
- jacquesm 17y ago
  If you code in a 'safe' way and you stay away from nifty tricks then you are in good shape. I'm sure you have a little list of stuff that you should stay away from or that you would at least discourage. The problems usually come when people start to use all those nifty features in combinations, especially 'newbie' programmers going wild on all that high level sugar. C/C++ is performance wise also as good as unbeatable, if you know what you're doing, which is another reason why it has such staying power.
  - rpledge 17y ago
    I have a list of things to stay away from indeed, but it's due to my own sanity of being. For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. If I was designing in Java exceptions are wonderful, in C++, asking for issues
    - jacquesm 17y ago
      > but it's due to my own sanity of being. I think that is what such lists have in common :) > For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. That is something I rarely have had trouble with, but I never worked much in teams. I did notice that the double-free and never-freed pointers are a good portion of the problems you encounter in live code though. And every time firefox goes EWOL I'm fairly sure that somewhere deep down someones code just tried to reference a stale pointer or something like that. Even in Java exceptions are not all that wonderful, I think they are just a way to say "I don't feel like coding the stuff required to handle this situation properly, let's thrown an exception". You end up with more exception handling code sometimes than functional code and that isn't the right balance either.

by dtf 17y ago

jacquesm 17y ago

That is very true. PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. I think this is in part why the web is so disruptive, because it enables all these upstarts using very light and nimble stuff to challenge the big and established companies directly. You can pretty much tell what is enterprise stuff and what is 'quick & dirty but does the job' by comparing hourly rates for programmers. It also has everything to do with the length of time before someone can be productive in a new environment. If that length of time is very short then there is not a very high barrier, which tends to create a lot of 'wannabe' programmers in that language. By raising the bar you only end up with people that are willing to invest a large amount of time in a platform, that tends to favour people that get paid for their work, which in turn is found mostly in enterprise locations.

jrockway 17y ago
PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. Not sure if this is true in general. I work at a bank. We use a lot of Perl. Banks existed long before "the web", and our Perl stuff is not a web application either. All the internal web apps are Java. It is kind of weird, actually -- Java for stuff like the HR apps, and Perl for the stuff that makes us money. (If it were my decision, I would use Perl for the web apps and Haskell for the algorithmic stuff... but it's not.)
- jacquesm 17y ago
  > We use a lot of Perl. That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is. But then again, is there even an 'enterprise scripting language' ? > All the internal web apps are Java. That's what I would expect. Sun really did some good marketing in that sphere.
  - coliveira 17y ago
    The area of a bank that generate money employs the smartest people, usually coming from academia. So, it doesn't surprise me.
    - jacquesm 17y ago
      Good point. Yours and gcheong's comment just above makes me wonder if someone missed the boat in getting an enterprise level scripting language out the door. It looks like there never was a 'natural' successor to stuff like JCL.
      - coliveira 17y ago
        Sun and MS are trying to bring scripting languages to their managed environments. .NET already supports Python reasonably well (I was surprised to see that SharpDevelop http://www.icsharpcode.net/OpenSource/SD/ http://www.icsharpcode.net/OpenSource/SD/ can easily convert most of my C++ into Python).
  - gcheong 17y ago
    >> We use a lot of Perl. >That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is. I've seen a lot of Perl used in banking/finance. It really is the "Practical Extraction and Reporting Language" and certainly seemed to have almost completely replaced shell scripting in the last place I worked at. One interesting anecdote about Perl was that a group I worked in originally chose ADA as their language when they were just starting out but eventually gave up and went with Perl just because of it's relative power and simplicity. That company also has a major initiative to replace alot of what was written in Perl (and runs the company to this day) with a system written in Java. That system is still not doing any serious production work and is at least a couple years late. I don't think it has as much to do with the Java language as the "this will be the mother of all systems" approach they tried to take with it in the beginning though.

rpledge 17y ago

I completely agree. While C++ certainly isn't perfect, those of us that write real code that is used and maintained day to day can be very productive. While I know who most of the people in the article are and respect their contributions to the world of software engineering, day to day real world pressures of delivery aren't the same as an example in a book. A hammer isn't an elegant tool, but it gets the nail into the wood.

jacquesm 17y ago
If you code in a 'safe' way and you stay away from nifty tricks then you are in good shape. I'm sure you have a little list of stuff that you should stay away from or that you would at least discourage. The problems usually come when people start to use all those nifty features in combinations, especially 'newbie' programmers going wild on all that high level sugar. C/C++ is performance wise also as good as unbeatable, if you know what you're doing, which is another reason why it has such staying power.
- rpledge 17y ago
  I have a list of things to stay away from indeed, but it's due to my own sanity of being. For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. If I was designing in Java exceptions are wonderful, in C++, asking for issues
  - jacquesm 17y ago
    > but it's due to my own sanity of being. I think that is what such lists have in common :) > For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. That is something I rarely have had trouble with, but I never worked much in teams. I did notice that the double-free and never-freed pointers are a good portion of the problems you encounter in live code though. And every time firefox goes EWOL I'm fairly sure that somewhere deep down someones code just tried to reference a stale pointer or something like that. Even in Java exceptions are not all that wonderful, I think they are just a way to say "I don't feel like coding the stuff required to handle this situation properly, let's thrown an exception". You end up with more exception handling code sometimes than functional code and that isn't the right balance either.