4 ms·

>Thousands of applications were made not so long ago with manual memory management. And pretty much all of them are unreliable garbage that we as an industry s

>Thousands of applications were made not so long ago with manual memory management. And pretty much all of them are unreliable garbage that we as an industry should have been too embarrassed to ship.

Jare 11y ago
As opposed to the slow and laggy garbage we as an industry should be too embarrassed to ship today. (of course, vulnerabilities and unreliability in those apps came from more places than just manual memory management, just as today's slowness comes from more places than the GC)
narag 11y ago
And pretty much all of them are unreliable garbage... So you have experienced thousands of unreliable garbage apps. I feel really sorry for you. My experience has been the opposite: lots of wonderful and reliable programs. And when I found one that wasn't good, I stopped using it and replaced it with a better one. I mean as a user. As a programmer I've seen all kind of programs, from "critical mission" to "quick hack" and from excelent to unreliable garbage. And you know what? It's not language features but ludicrous incompetence what makes an app unreliable garbage. There are programmers out there that can make unreliable garbage in any language. The "secret" to make some app reliable is not reserved to NASA and the like. Follow two simple patterns: 1. For every user action, validate input, try executing the code, catch the occasional exception and show an error message. 2. For every resource, allocate, try{ using it } finally { release it } Put each of these skeletons in a function or method, so the resource is a local variable (no colateral effects) and it's easy to debug. That's all. Well, also: don't be too "creative" unless you know what you're doing (most times you don't). I'm fifty-something, spent a lot of painful time mechanically applying that recipes to rotten codebases, and when I read the kind of criticisms you made I assume they come from people too young to have real world experience on what they're criticizing. The alternative is worse: to be the kind of people that created that rot and then blamed the language. Just in case: I don't believe that manual memory languages are "better". I love Python and (most of the time) JavaScript.
- pcwalton 11y ago
  > I read the kind of criticisms you made I assume they come from people too young to have real world experience on what they're criticizing. Actually, every single year I've worked on security-critical software I've understood more and more how impossible it is to secure large C and C++ codebases worked on by large teams with just "careful coding". The picture changes a lot when you have people actively searching for vulnerabilities.
  - deleted 11y ago
    [deleted]
  - narag 11y ago
    Please, reread carefully your initial comment and the one by prodigal_erik (the two comments I've answered to in this thread) and you will see that you've made a gross generalization, while now you're narrowing the field you meant to apply your words. Do you believe that security software or browsers are better writen in other languages than C/C++? I won't dispute that, even if I'd have some questions about relative merits. Please think of some well known Perl and PHP applications and their security record. Anyway the unqualified: That's because correct C-style memory management never† scales up to large software projects in a way that doesn't result in crashes and, worse, vulnerabilities. ... and talking about manual memory management in general... And pretty much all of them are unreliable garbage that we as an industry should have been too embarrassed to ship. ... are simply not true. Worse, they're insulting for everyone who has worked in this kind of application.
    - pcwalton 11y ago
      > Do you believe that security software or browsers are better writen in other languages than C/C++? Yes. And lots and lots of apps (most public network facing things) are security sensitive. > Please think of some well known Perl and PHP applications and their security record. Nobody is saying that "memory safe == no vulnerabilities". I do think it's true that being memory unsafe results in many more vulnerabilities. I've measured this precise statistic in our bug tracker. > That's because correct C-style memory management never† scales up to large software projects in a way that doesn't result in crashes and, worse, vulnerabilities. It's true. And I work in native code myself! It's only an insult if you presuppose that introducing vulnerabilities reflects badly on the programmer who introduced them. I don't believe that; most major vulnerabilities I've seen were introduced by very good programmers. It's a problem with the tools they're working with.

>Thousands of applications were made not so long ago with manual memory management. And pretty much all of them are unreliable garbage that we as an industry should have been too embarrassed to ship.

Jare 11y ago

As opposed to the slow and laggy garbage we as an industry should be too embarrassed to ship today. (of course, vulnerabilities and unreliability in those apps came from more places than just manual memory management, just as today's slowness comes from more places than the GC)

narag 11y ago

And pretty much all of them are unreliable garbage... So you have experienced thousands of unreliable garbage apps. I feel really sorry for you. My experience has been the opposite: lots of wonderful and reliable programs. And when I found one that wasn't good, I stopped using it and replaced it with a better one. I mean as a user. As a programmer I've seen all kind of programs, from "critical mission" to "quick hack" and from excelent to unreliable garbage. And you know what? It's not language features but ludicrous incompetence what makes an app unreliable garbage. There are programmers out there that can make unreliable garbage in any language. The "secret" to make some app reliable is not reserved to NASA and the like. Follow two simple patterns: 1. For every user action, validate input, try executing the code, catch the occasional exception and show an error message. 2. For every resource, allocate, try{ using it } finally { release it } Put each of these skeletons in a function or method, so the resource is a local variable (no colateral effects) and it's easy to debug. That's all. Well, also: don't be too "creative" unless you know what you're doing (most times you don't). I'm fifty-something, spent a lot of painful time mechanically applying that recipes to rotten codebases, and when I read the kind of criticisms you made I assume they come from people too young to have real world experience on what they're criticizing. The alternative is worse: to be the kind of people that created that rot and then blamed the language. Just in case: I don't believe that manual memory languages are "better". I love Python and (most of the time) JavaScript.

pcwalton 11y ago
> I read the kind of criticisms you made I assume they come from people too young to have real world experience on what they're criticizing. Actually, every single year I've worked on security-critical software I've understood more and more how impossible it is to secure large C and C++ codebases worked on by large teams with just "careful coding". The picture changes a lot when you have people actively searching for vulnerabilities.
- deleted 11y ago
  [deleted]
- narag 11y ago
  Please, reread carefully your initial comment and the one by prodigal_erik (the two comments I've answered to in this thread) and you will see that you've made a gross generalization, while now you're narrowing the field you meant to apply your words. Do you believe that security software or browsers are better writen in other languages than C/C++? I won't dispute that, even if I'd have some questions about relative merits. Please think of some well known Perl and PHP applications and their security record. Anyway the unqualified: That's because correct C-style memory management never† scales up to large software projects in a way that doesn't result in crashes and, worse, vulnerabilities. ... and talking about manual memory management in general... And pretty much all of them are unreliable garbage that we as an industry should have been too embarrassed to ship. ... are simply not true. Worse, they're insulting for everyone who has worked in this kind of application.
  - pcwalton 11y ago
    > Do you believe that security software or browsers are better writen in other languages than C/C++? Yes. And lots and lots of apps (most public network facing things) are security sensitive. > Please think of some well known Perl and PHP applications and their security record. Nobody is saying that "memory safe == no vulnerabilities". I do think it's true that being memory unsafe results in many more vulnerabilities. I've measured this precise statistic in our bug tracker. > That's because correct C-style memory management never† scales up to large software projects in a way that doesn't result in crashes and, worse, vulnerabilities. It's true. And I work in native code myself! It's only an insult if you presuppose that introducing vulnerabilities reflects badly on the programmer who introduced them. I don't believe that; most major vulnerabilities I've seen were introduced by very good programmers. It's a problem with the tools they're working with.