Slashdot Mirror


Eric Raymond Shares 'Code Archaeology' Tips, Urges Bug-Hunts in Ancient Code (itprotoday.com)

Open source guru Eric Raymond warned about the possibility of security bugs in critical code which can now date back more than two decades -- in a talk titled "Rescuing Ancient Code" at last week's SouthEast Linux Fest in North Carolina. In a new interview with ITPro Today, Raymond offered this advice on the increasingly important art of "code archaeology". "Apply code validators as much as you can," he said. "Static analysis, dynamic analysis, if you're working in Python use Pylons, because every bug you find with those tools is a bug that you're not going to have to bleed through your own eyeballs to find... It's a good thing when you have a legacy code base to occasionally unleash somebody on it with a decent sense of architecture and say, 'Here's some money and some time; refactor it until it's clean.' Looks like a waste of money until you run into major systemic problems later because the code base got too crufty. You want to head that off...."

"Documentation is important," he added, "applying all the validators you can is important, paying attention to architecture, paying attention to what's clean is important, because dirty code attracts defects. Code that's difficult to read, difficult to understand, that's where the bugs are going to come out of apparent nowhere and mug you."

For a final word of advice, Raymond suggested that it might be time to consider moving away from some legacy programming languages as well. "I've been a C programmer for 35 years and have written C++, though I don't like it very much," he said. "One of the things I think is happening right now is the dominance of that pair of languages is coming to an end. It's time to start looking beyond those languages for systems programming. The reason is we've reached a project scale, we've reached a typical volume of code, at which the defect rates from the kind of manual memory management that you have to do in those languages are simply unacceptable anymore... think it's time for working programmers and project managers to start thinking about, how about if we not do this in C and not incur those crazy downstream error rates."

Raymond says he prefers Go for his alternative to C, complaining that Rust has a high entry barrier, partly because "the Rust people have not gotten their act together about a standard library."

109 comments

  1. Rust: act together about a standard lib, by ReneR · · Score: 1

    Well, that reminds me on my this weeks Rust bootstrapping experience to actually only build Firefox: https://www.youtube.com/watch?...

  2. Related Links by Anonymous Coward · · Score: 0

    This is from the related links section on this story:
    Interviews: ESR Answers Your Questions
    Ask Slashdot: What Are Some Things That Every Hacker Once Knew?
    ESR Sees Three Viable Alternatives To C
    Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C
    ESR's Newest Project: An Open Hardware/Open Source UPS

  3. What an idiot by Anonymous Coward · · Score: 0

    Learn C++ you stupid fuck, memory management is optional, just like your brain.

    1. Re:What an idiot by Anonymous Coward · · Score: 0

      Yes, he acts like the languages haven't evolved. C & C++ have been updated this decade. C++ has garbage collection support.

      While I personally hate C++, it is a very good language for some tasks including drivers.

    2. Re: What an idiot by Anonymous Coward · · Score: 0

      Riiight, can you point me to the section of the C++ standard that describes said garbage collection?

    3. Re:What an idiot by Z00L00K · · Score: 4, Informative

      Personally I think that C++ contains a lot of the bad parts from C and Java while not really offering any major advantage.

      In any case - Valgrind and Splint are great for C programs, but for kernel work it's a bit hard to use Valgrind.

      When coding Java I have had great experience using Findbugs. For C# I haven't seen any tool as good as that tool.

      As a rule - never ignore compiler warnings, they may be the tip of an iceberg problem. I have found a lot of naughty bugs and coding that way.

      Also beware of re-using variables, something that I have seen is very easy in VB - a variable is re-used and suddenly contains a new data type. That's really nasty. And some script languages allows that as well.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    4. Re: What an idiot by Anonymous Coward · · Score: 0

      Google. It's your friend. And who said anything about a standard? Why can't it be
      In a library?

    5. Re:What an idiot by Darinbob · · Score: 1

      Not really garbage collection. It's a "good enough" collector. A real garbage collecting language has zero allocation routines and zero freeing routines, and will reclaim every single object eventually, and do this faster than manual alloc/free. Not a lot of common languages do this these days, because it requires deep hooks into the OS and CPU. Whereas modern scripting languages often find it faster to get going by building the framework on top of device independent languages like C or C++.

    6. Re:What an idiot by Darinbob · · Score: 1

      I used C++ for a long time, starting with Cfront, though the last decade has been C/assembler. C++ seems to have lost focus and the later standards seem somewhat strange like they're adding new features that aren't needed except to pad out the new standard. Now it's not so great for a low level systems language unless you use a lot of self discipline to avoid features, and it's completely bloated for big applications if you use the fashionable styles, and scripting languages do so much better and rapid prototyping. So it doesn't feel like it has a niche anymore, except as a place for the gurus to sit around and argue about what should change next.

    7. Re:What an idiot by Pinky's+Brain · · Score: 1

      Being able to write memory safe code in a memory unsafe language is not enough, you need machine validation that only the memory safe constructs are used.

      C and C++ programmers given the freedom to do so will inevitably create exploitable bugs because of memory unsafe programming.

    8. Re: What an idiot by Anonymous Coward · · Score: 1

      eric raymond is the most over rated "hacker" in history. he has no actual technical achievements to speak of, he's famous for promoting open source, sending a death threat to bruce perens, and for attempting (and massively failing) to write a new build system for the linux kernel.

    9. Re:What an idiot by Anonymous Coward · · Score: 0

      [...] and do this faster than manual alloc/free.

      HAHAHAHAHA

    10. Re:What an idiot by Anonymous Coward · · Score: 0

      Being able to write memory safe code in a memory-unsafe language is not enough; you need machine validation that only the memory safe constructs are used.

      FTFY.
      I see that English is not your first language. You were missing a hyphen between "memory" and "unsafe" (needed in order to make it into a compound adjective modifying "language") and you had a comma that should have been a semicolon.

      You're welcome!

    11. Re:What an idiot by Anonymous Coward · · Score: 0

      While I personally hate C++, it is a very good language for some tasks including drivers.

      A guy on my team insisted we switch to C++ to write our drivers. I transferred him to another group and he left the company 3 months later.Sayounara Jeff! And take your weird hat with you.

    12. Re:What an idiot by Anonymous Coward · · Score: 0

      C++ contains a lot of the bad parts from C and Java

      From Java? Has the arrow of time turned around, or are you actually referring to Boost libraries?

    13. Re:What an idiot by serviscope_minor · · Score: 1

      Personally I think that C++ contains a lot of the bad parts from C and Java while not really offering any major advantage.

      I disagree for a few reasons. Firstly, Java? What? C++ predates Java.

      I've also not had a memory leak in C++ in probably 15 years. Either I'm the awesomest programmer ever or C++ offers some pretty big advantages. RAII is fantastic for resource management. Generics make equivalent code faster and simpler than the C equivalent.

      --
      SJW n. One who posts facts.
    14. Re:What an idiot by serviscope_minor · · Score: 1

      C++ seems to have lost focus and the later standards seem somewhat strange like they're adding new features that aren't needed except to pad out the new standard.

      Like what? I mea technically no feature is "needed" in that the language is turing complete and pretty fuctional circa 1998, but I'd say the latest standards have added a fair bit good. C++14 and 17 have both been fairly minor additions, but have given some nice refinements to the rules and some much needed additions to the library.

      A shame concepts never made it in to 17 (roll on 2a!). They've been on the cards since the early 90s.

      Now it's not so great for a low level systems language

      Yes it is. The new features haven't modified anything in that regard.

      unless you use a lot of self discipline to avoid features,

      Like what? You could argue exceptions though unless you're writing hard realtime code, or some parts of kernel code I'd disagree.

      and it's completely bloated for big applications if you use the fashionable styles,

      No it isn't. There's no evidence for this.

      --
      SJW n. One who posts facts.
    15. Re:What an idiot by TheRealMindChild · · Score: 1

      Also beware of re-using variables, something that I have seen is very easy in VB - a variable is re-used and suddenly contains a new data type

      Why in the hell are you using a typeless variable in VB?

      --

      "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
    16. Re:What an idiot by Z00L00K · · Score: 1

      No I don't, but I have seen code where it existed. Facepalm time there.

      Unfortunately we can't have ADA everywhere. But for VB then I blame Microsoft for creating a shitty language that didn't force users from the beginning to be strict.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    17. Re:What an idiot by paolo.redaelli · · Score: 1

      Can you please point out some of those languages, those "eal garbage collecting language has zero allocation routines and zero freeing routines, and will reclaim every single object eventually, and do this faster than manual alloc/free"?

    18. Re:What an idiot by Darinbob · · Score: 1

      Smalltalk, Lisp, ML, etc.

    19. Re:What an idiot by Anonymous Coward · · Score: 0

      Ada.

      It's a person's name, not an acronym.

    20. Re:What an idiot by Zontar+The+Mindless · · Score: 1

      Was that really necessary?

      --
      Il n'y a pas de Planet B.
    21. Re: What an idiot by Anonymous Coward · · Score: 0

      Swift ;)

      ARC

  4. Re:remember by Anonymous Coward · · Score: 0

    +1

  5. New languages are not portable by Anonymous Coward · · Score: 0

    The problem with many of the newer languages is that they only target a few operating systems and make the barrier to add more difficult. Rust in particular requires very specific LLVM versions and patch sets. The community is also a bit odd.

    We need to start dinging projects that only support the big three (Win/Mac/Linux)

  6. No manual memory management necessary in C++ by Anonymous Coward · · Score: 0

    I've been writing code in C++ for 25+ years and *never* had to use 'manual memory management' except for very low-level parts of systems (way less than 1% of the code in typical projects). Whoever writes such bullshit has not understood the language and it's no wonder we get vulnerabilities.

    1. Re:No manual memory management necessary in C++ by Anonymous Coward · · Score: 1

      I agree, I just plow ahead and figure someone will fix everything for me at some point. We have milestones that need to be hit.

    2. Re: No manual memory management necessary in C++ by Anonymous Coward · · Score: 0

      What, you assert that C++ had a full GC 25 years ago? Riiiiight.

    3. Re:No manual memory management necessary in C++ by Z00L00K · · Score: 2, Informative

      When I coded C for MS-DOS I had to make sure that I did malloc/free in the right order just to avoid memory leaks. So if I did one malloc for A then one for B the result was that I had to free B before A or I would have trouble coming.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    4. Re:No manual memory management necessary in C++ by CSMoran · · Score: 1

      You're confusing memory fragmentation with memory leaks.

      --
      Every end has half a stick.
    5. Re:No manual memory management necessary in C++ by lucasnate1 · · Score: 1

      C++ also provides easy reference counting and insurance of pointer uniqueness. I agree that one can do the same with very well ordered C, but C++ automates the process for you, and that's one of the things that programming languages are about, automating simple thought processes for the programmer.

    6. Re: No manual memory management necessary in C++ by Anonymous Coward · · Score: 0

      If you stick to STL containers, you could get away without manual memory management back then. It wasn't needlessly efficient. GC is just one element of MM. When sharing memory across languages GC can be unhelpful at times.

    7. Re:No manual memory management necessary in C++ by dfghjk · · Score: 1

      Anyone who considers such fundamental concepts of C++ as useful to "way less than 1% of the code in typical projects" "has not understood the language" either.

  7. Re:remember by ToTheStars · · Score: 1

    It's spelled "Murdock", btw: https://en.wikipedia.org/wiki/...

  8. Crystal - Slick as Ruby, Fast as C by Bruce+Perens · · Score: 5, Interesting

    Eric suggests it's time to move on from C, and there are indeed better languages today that can help eliminate many classes of error.

    Crystal is a rising programming language with the slogan "Fast as C, Slick as Ruby". It has some compelling features that make it more attractive than other modern language attempts like Go. You really can program in a Ruby-like language and achieve software that performs with the speed of a compiled language. And you can do systems programming in Crystal, too, because while it doesn't encourage you to use them for anything but systems programming and inter-language interfaces, it has pointers, and it can format structs as required to work on hardware registers.

    But the greatest advantage of Crystal, that I have experienced so far, is that it provides type-safety without excessive declarations as you would see in Java. It does this through program-wide type inference. So, if you write a function like this:

    def add(a, b)
    a + b end

    add(1, 2) # => 3, and the returned type is Int32
    add(1.0, 2) # => 3.0, and the returned type is Float64

    You get type-safe duck-typing at compile-time. If a method isn't available in a type, you'll find out at compile-time. Similarly, the type of a variable can be inferred from what you assign to it, and does not have to be declared.

    Now, let's say you never want to see nil as a variable value. If you declare the type of a variable, the compiler will complain at compile-time if anything tries to assign another type to it. So, this catches all of those problems you might have in Ruby or Javascript with nil popping up unexpectedly as a value and your code breaking in production because nil doesn't have the methods you expect.

    There are union types. So, if you want to see nil, you can declare your variable this way:

    a : String | Nil

    a : String? # Shorthand for the above.

    Crystal handles metaprogramming in several ways. Type inference and duck typing gives functions and class methods parameterized types for free, without any declaration overhead. Then there are generics which allow you to declare a class with parameterized types. And there is an extremely powerful macro system. The macro system gives access to AST nodes in the compiler, type inference, and a very rich set of operators. You can call shell commands at compile-time and incorporate their output into macros. Most of the methods of String are duplicated for macros, so you can do arbitrary textual transformations.

    There is an excellent interface to cross-language calls, so you can incorporate C code, etc. There are pointers and structs, so systems programming (like device drivers) is possible. Pointers and cross-language calls are "unsafe" (can cause segmentation faults, buffer overflows, etc.) but most programmers would never go there.

    What have I missed so far? Run-time debugging is at a very primitive state. The developers complain that LLVM and LLDB have changed their debugging data format several times recently. There's no const and no frozen objects. The developers correctly point out that const is propagated through all of your code and doesn't often result in code optimization. I actually like it from an error-catching perspective, and to store some constant data in a way that's easily shareable across multiple threads. But Crystal already stores strings and some other data this way. And these are small issues compared to the benefits of the language.

    Lucky

    Paul Smith of Thoughtbot (a company well-known for their Ruby on Rails expertise) is creating the Lucky web framework, written in Crystal and inspired by Rails, which has pervasive type-safety - and without the declaration overhead as in Java.

    The point of all of this is that you can create a web application as you might using Ruby on Rails, but you won't have to spend as much time writing tests, because some of the

    1. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      Phew, I was worried there weren't enough web frameworks.

    2. Re: Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      Sounds great, you are hired!

      TLDR not better than Python

    3. Re:Crystal - Slick as Ruby, Fast as C by Darinbob · · Score: 1

      I find it very difficult to find really good C programmers who can also have good understanding of low level systems with some domain knowledge. Lots of self taught C programmers though, they can write stuff that's good enough for their own simple tools, but who lack experience working on complex software in a team, mostly they're coming from EE or science backgrounds. People coming from a CS background don't seem to know C, only vaguely know C++ (and can't make the tiny step from there to C), and who complain that everything should be in a third party library already.

      So with that background of having difficulty finding really good C programmers, going to a brand new language with a worldwide user base in the dozens is going to be difficult. Even slightly more popular things like Rust or Go just does not have the necessary mass to replace C anytime soon.

      Companies are not going to port existing software to a new platform, there's no money in it. That's why COBOL is still around and you can get paid quite well if you want to work on it. C is going to stick around a long time for the same reason. Now a NEW project might want to do a new language, but you still need some critical mass to get a team together for it otherwise it ends up as a single programmer project that eventually languishes because original developer left and no one knows what to do with it.

    4. Re: Crystal - Slick as Ruby, Fast as C by Bing+Tsher+E · · Score: 1

      I find C programmers in embedded work who don't understand that they are responsible for everything coming up out of the reset vector. They assume timers are initiated, that interrupt vectors are pre-defined, and that they can just coast along at an application level. That's just the consequence of too much programming on top of an operating system, I guess.

    5. Re:Crystal - Slick as Ruby, Fast as C by Bruce+Perens · · Score: 1

      I am not so concerned with companies making the move, as the Open Source community and green-field projects. The same folks who use Rails in start-ups should be keeping an eye on this.

    6. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      Apropos of the last paragraph, as an old fart I have seen quite a few projects go belly up re-writing their code in the flavor of the month to assuage the feelings of the young Turks. They could have kept their jobs by implementing new features instead, as the software that replaced them did.

    7. Re:Crystal - Slick as Ruby, Fast as C by angel'o'sphere · · Score: 2

      I find it very difficult to find really good C programmers
      If you really need C programmers, why not hire a competent programmer and teach him C or simply ask him to learn it over a weekend ...

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    8. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      If you really need C programmers, why not hire a competent programmer and teach him C or simply ask him to learn it over a weekend ...

      It's not simply knowing the language that makes them good, or rather, qualified.

    9. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      > Code that's difficult to read, difficult to understand, that's where the bugs are going to come out of apparent nowhere and mug you."

      For the most part, difficult to read difficult to understand code is just about any code which does not follow your own programming style.

      Expect to see C jobs paying much higher rates in the next few years. We couldn't find developers willing to write C++ or OpenGL in anyone under 40 years old even with good pay rates. This is for a large multinational company with decent benefits.

      The industry needs to wake up and pay a 'risk based pay rate' for jobs which drain skills off of your resume such as large legacy system maintenance work in C.

      The vanilla JavaScript / CSS / Html / MS Aspnet.MVC / SQL Server project we're implementing is at best treading water when it comes to skills on resume.

    10. Re:Crystal - Slick as Ruby, Fast as C by jma05 · · Score: 1

      You should also check out Nim.
      https://nim-lang.org/

      It is the Python version of Crystal. It transpiles to C/C++/Node. Has type inference, integrates Boehm GC, good FFI, meta-programming etc. Similar performance to C (CPU, RAM, static binary size), but with the productivity of Python.

      Crystal seems to have more modules - both seem to have the essential libraries covered.

    11. Re:Crystal - Slick as Ruby, Fast as C by jma05 · · Score: 1

      C takes a huge amount of experience before you stop shooting yourself in the foot and start being productive. Languages like Go are trivial to learn. Rust is less trivial.

      No one is expecting C to disappear any time soon.

    12. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      learn C "over the weekend"?

      That's hilarious.

    13. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      > learn C "over the weekend"?
      > That's hilarious.

      ANSI C only has 32 keywords. C99 adds 5 more.

      If you're an experienced programmer and familiar with the concepts, then yes, you can start writing non-trivial programs in C after a weekend of study.

      Learning the libraries and APIs, of course, will take a bit longer...

    14. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      "Learning the libraries and APIs, of course, will take a bit longer..."

      You are grossly underestimating how long that could take. Writing useful, professional programs is likely to use a lot of libraries. This is why I laughed about the "over the weekend" comment, not because C has only 32 keywords. Learning the core of a language is fairly straightforward, but getting comfortable with the most popular libraries available takes a lot more time.

    15. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      >> "Learning the libraries and APIs, of course, will take a bit longer..."

      > You are grossly underestimating how long that could take.

      No, that was an intentionally laughable understatement.

    16. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      Crystal [crystal-lang.org] is a rising programming language with the slogan "Fast as C, Slick as Ruby".

      You had me til you said Ruby.

      The features do indeed sound like they remove a lot of needless drudgery from coding. But why would they shackle themselves to a dead niche Perl derivative that no one takes seriously?

      Work on marketing it better and you might actually have something there.

    17. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      Like it or hate it, Ruby is not a 'Perl derivative.'

    18. Re:Crystal - Slick as Ruby, Fast as C by eddeye · · Score: 1

      Like it or hate it, Ruby is not a 'Perl derivative.'

      Like it or leave it, you don't know what you're talking about.

      From the official ruby faq:

      "Ruby is a modern object-oriented language, combining elements of Perl, Smalltalk, and Scheme

      Influenced by Perl, Matz wanted to use a jewel name for his new language, so he named Ruby after a colleague's birthstone. Later, he realized that Ruby comes right after Perl in several situations. In birthstones, pearl is June, ruby is July. When measuring font sizes, pearl is 5pt, ruby is 5.5pt. He thought Ruby was a good name for a programming language newer (and hopefully better) than Perl.

      Ruby's syntax and design philosophy are heavily influenced by Perl.... Many, many things are lifted directly from Perl."

      --
      Democracy is two wolves and a sheep voting on lunch.
    19. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      "influenced by"... "combining elements of"... "design philosophy"...

      None of this adds up to a derivative of Perl.

      AFAIK it doesn't use any Perl code, so it's a completely independent work.

    20. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      You may as well call C an "Algol derivative," with that same reasoning.

    21. Re:Crystal - Slick as Ruby, Fast as C by eddeye · · Score: 1

      AFAIK it doesn't use any Perl code, so it's a completely independent work.

      lol... do you even know what that means? Are you saying the Ruby interpreter isn't coded in Perl? That's meaningless.

      Are you saying that you can't copy/paste code directly from a Perl program into a Ruby program? Again, meaningless. Do you even know what derivative means?

      Derivative = not original, derived. derived = received or obtained from a source or origin. Hmmm, where have we heard something like that before? Wait, I know:

      "Ruby's syntax and design philosophy are heavily influenced by Perl.... Many, many things are lifted directly from Perl."

      So pretty much the dictionary definition of derivative.

      --
      Democracy is two wolves and a sheep voting on lunch.
    22. Re:Crystal - Slick as Ruby, Fast as C by Anonymous Coward · · Score: 0

      No, I'm saying it doesn't share any code with the Perl interpreter. It is NOT a derivative work.

      Ruby takes some ideas and syntax from Perl, that is all. And Perl isn't alone in its influence.

      Sure, it would be different if Perl didn't exist, but it's definitely not an offshoot, fork, derivative or descendent of Perl.

  9. Sadly Go still needs shared lib support by Anonymous Coward · · Score: 0

    I almost had my team convinced to move to Go on our embedded platform, but our device's flash isn't roomy enough for multie 2+MB binaries. We'll still use it for build reporting, and other non-target tools but until the Go runtime/libs can be shared amongst all the binaries, it's going to have to wait.

  10. Re:remember by Anonymous Coward · · Score: 0

    He was a drunk loser who suicided himself when his white privilege didn't work in lefty SF.

  11. dejour article by jmccue · · Score: 1

    Another language de-jour article, I remember in the early days of UNIX one of the sayings about c was something like "it expects the programmer to know what they are doing, it is in a hold-your-hand language".

    Well I guess we should go back to COBOL or FORTRAN then

    1. Re:dejour article by jmccue · · Score: 1

      Well a typo, instead of " it is in a" I meant " it is NOT a". Anyway this was tongue due to "archaeology"

  12. Re:remember by Bruce+Perens · · Score: 5, Informative

    REMEMBER THE MURDER

    Ian was and continues to be very admired for his achievements, and his death was unnecessary and completely undignified, and is a continuing source of disquiet for me personally. Ian is a victim of mental illness. This is acknowledged by his family and by those who knew him more closely, rather than simply admiring him from afar. Rather than dishonor Ian by discussing this in detail, I would prefer to simply state that he was a victim of mental illness, not the police.

  13. Pylons? by Anonymous Coward · · Score: 0

    You are personally connected to Pylons? Did you mean to say pylint?

    1. Re:Pylons? by Anonymous Coward · · Score: 0

      "You are personally connected to Pylons?"

      He is shackled to one, in the basement of the Asylum for the Criminally Insane.

  14. Re: remember by Anonymous Coward · · Score: 1

    Do you want us to say the same things about you when the police decide it's your turn to pay the piper?

    When the police pump you with 30 holes, we will say "it wasn't the police officers fault for shooting Bruce 30 times, it was mental illness."

    You are a very smart man, but sometimes you make me sick. It's like you only stand up for things that won't get you in trouble. You tip toe around, when you should be bringing these issues to light. You use your fame to hide issues, choosing to Instead derail conversations.

    How come nobody wanted to help Ian before all this happen? How come we never heard about Ian being mentally ill before all of this? Now all of a sudden he's mentally ill and the cops were justified in shooting an unarmed man? I'm not blaming you or anyone, I'm just saying, if he was that mentally ill, then his friends should have tried to get him help, or at least have
    Him committed for his own safety. Yet you guys did nothing. I'm confused.

    Christ, the world just keeps getting shittier, and when our heroes are now apart of that lie, we have no where to turn.

    I'm not even going to get started on the whole open source dibacle we've already gone over on slashdot.

    I'll leave you with this famous quote:

    Torpedo: Little bit of advise, Bob. If you want a role model, choose an old guy. By the time you're grown up they're dead.

  15. Re: remember by Anonymous Coward · · Score: 0

    Sorry Bruce, I did not mean to attack you personally. It's just that this whole issue with police pisses me off. The people who are supposed to protect and serve are no longer doing their jobs.

    Once again, I apologize if I was out of line.

  16. clisp anyone? by Anonymous Coward · · Score: 0

    Tried, true, tested, and still extremely powerful. Standardized.
    Lisp compilers are the original place where much of the foundation in compiler theory was built.
    The community is far from dead and the libraries continue to grow.
    They tend to just keep their head down and get stuff done. Right. Usually the first time.

    All these other languages in the algol family tree seem to just keep cycling through the same issues in one flavor or another.

  17. Re: remember by Anonymous Coward · · Score: 0

    Yes. He was kilked as ordered by systems supporters who shoehorned systemd on Debian after that.

  18. Re: remember by Anonymous Coward · · Score: 0

    The police protected and served the people whose door Murdock was trying to smash down in a drunken rampage.

  19. What does he actually know? by lucasnate1 · · Score: 2, Insightful

    Eric Raymond is not well reknowned for his programming/engineering achievements, but for being a public speaker. What is the value of his advice?

    1. Re:What does he actually know? by Anonymous Coward · · Score: 0

      Well he is an idiot when it comes to memory allocation. You are just trading one set if problems for another switching from manual to "automatic" memory allocation. Who hasn't debugged a Java program that just leaks references like crazy but works as long you have a massive machine to run it. So far, I am not impressed by go's garbage collection either. They have reworked it recently so it might be better.

    2. Re: What does he actually know? by Bing+Tsher+E · · Score: 1

      He is visionary in the same sense that a guy assigned to give the keynote speech at an IBM Symposium in 1966 was visionary.

    3. Re:What does he actually know? by Anonymous Coward · · Score: 0

      "The Art of Unix Programming" is some pretty good and valuable advice. Well regarded my many.

    4. Re:What does he actually know? by Pinky's+Brain · · Score: 1

      A memory leak in Java code might get you a DOS attack, a buffer overflow in C might get you complete owned.

      Apples and rotten oranges.

    5. Re:What does he actually know? by p4nther2004 · · Score: 1

      What is the value of his advice?

      I always find it valuable to evaluate the advice first; then see whom it came from.

      Let's look at his advice:

      • Add static code analysis even to legacy code.

        Frankly I think static code analysis is always worth doing. It's a way of doing automated "apply learned lessons from someone else". Yes, there may be false positives - but you'll quickly uncover code smells.

      • Change to modern languages.

        I think this one is also a no-brainer. I used to do Fortran...switched to C/C++. Switched to Java. About to switch again.

    6. Re: What does he actually know? by Anonymous Coward · · Score: 0

      It's not a programming book tho. He is standing on the soldiers of giants. He basically interviewed the real deals(Ritchie, Kerrigan, etc) and transcribed their processes down into a book.

    7. Re: What does he actually know? by Anonymous Coward · · Score: 0

      ? He gives no compelling reason to switch. None. Everything done in go can be damn near done in C and it's faster.

    8. Re: What does he actually know? by p4nther2004 · · Score: 1

      He gives no compelling reason to switch. None. Everything done in go can be damn near done in C and it's faster.

      Of course.

      Hell, everything can be done in go can be done assembler and it's faster (execution).

      But it won't be faster to write/debug. (Maybe you like to roll your own unit test and benchmarks, but I don't want to)

  20. Re: remember by Bruce+Perens · · Score: 2

    Do you want us to say the same things about you when the police decide it's your turn to pay the piper?

    It is heart-breaking that he died without a friend left in the world, but that was a consequence of his illness.

    I am 60 and my death isn't all that far away any longer. I am fortunate to have friends and a wonderful family, and hope to die in peace, with them around me.

  21. Re: remember by Bruce+Perens · · Score: 1

    If you really can't get this out of your head, I'll discuss it on the phone with you, and expect you not to publish the information. It wouldn't take long, and would only make you more sad.

  22. Re:remember what a fucking verb is by Hognoxious · · Score: 1

    suicided himself

    We should be thankful he didn't suicide anyone else.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  23. Re: remember by Anonymous Coward · · Score: 0

    "but that was a consequence of his illness."

    You say that like mental illness is voluntary.

  24. Re: remember by Hognoxious · · Score: 1

    They serve themselves and protect each other. Was it ever supposed to mean anything else?

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  25. Re: remember by Bing+Tsher+E · · Score: 1

    One of the consequences of a bridge falling down can be debris in the river that blocks barge traffic. That does not imply that the bridge voluntarily fell down.

  26. Re: remember by Hognoxious · · Score: 1, Insightful

    They could have protected and served them by whacking him across the arse with a truncheon, handcuffing him and dumping him in a cell to sleep it off.

    Like they do in civilised countries.

    Drunks are shit fighters, even if they think the opposite. If you can't subdue one without artillery you shouldn't be working as a cop.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  27. Jism stained green lines by Anonymous Coward · · Score: 0

    Follow the trail of jism stained green lines. There DNA will reveal the unique signature of the author: ESR. Decode and debug the mystery if you will!

  28. Re: remember by Anonymous Coward · · Score: 1

    Who are you talking about? Ian Murdock was not shot!

  29. Re:remember by Anonymous Coward · · Score: 0

    Wake the fuck up retard! I realize in 1932 or whenever you were born, people still believed in the authority of the press and all that, but take a look around. The mainstream is fucking propaganda everywhere. Mysterious deaths are always covered up to "honor the victim." I hope if I ever die mysteriously, no one dishonors me and adds insult too to call it fucking "honor." You emotionally manipulative piece of shit.

  30. Re:remember by Anonymous Coward · · Score: 0

    Bruce knew Ian and you did not, so STFU.

  31. unmitigated bullshit by Anonymous Coward · · Score: 1

    "we've reached a typical volume of code, at which the defect rates from the kind of manual memory management that you have to do in those languages are simply unacceptable anymore"

    Translation: "We kept telling programmers they're too dumb to do their own memory management and rely on high level languages like java which handle memory management automatically and now the programmers coming out of college don't even understand memory management because it's too complex so it's time to move onto something like javascript and lotsa lotsa test frameworks. I don't understand C++ at all."

    Memory management was and IS a responsibility of programmers to ensure proper resource usage and optimization and it's, get this, not difficult at all to do right so long as you don't "HACK" your code and free the used memory at the same nexus points as when you malloc them. The same is true of C++ and, get this, you even have special containers which will handle the auto-destruction for you! (gasp!) Language mechanics that have been in use for over 15 years in C++ (and no, I'm not talking about the defunct smart_ptr)

    Good God man - getting rid of memory management so you can "concentrate on the problem at hand" and write 2 dozen objects to translate a dataset using factories and facade class patterns so you can add other translations in the future when THERE'S ONLY THE ONE TRANSLATION isn't a BETTER WAY!

    1. Re:unmitigated bullshit by WorBlux · · Score: 1

      It's not a matter of dumb or smart, it's a matter of being human. There's only so many things you can pay attention to at once, and at a certain level of machine capability it's just not worth doing anymore for many use cases. And the the choice isn't C++ or silly over to top OO there is a lot of options for memory-safe languages.

  32. I'll stick with C thank you very much by Anonymous Coward · · Score: 0

    Go is controlled by Google, very much like the .NET stack is controlled by Microsoft.
    Rust is too political, they care more about their code of conduct than actual code.
    Learn about C and it's pitfalls instead and you are golden.

  33. Sanitizers by ShakaUVM · · Score: 1

    It's odd that he talks about using tools to validate your code on one hand and then recommends moving away from C or C++ on the other.

    There's actually some pretty fantastic work on sanitizers being done right now in Clang (and other tooling chains) that can enforce memory and type safety at run time.

    You can do all your development with the sanitizers turned on, and then when you want speed when you're ready to release, turn them off.

    There's still nothing faster than C or C++ than assembly, and even then you have to be reasonably skilled to beat -O3 these days.

  34. That describes him; DOES NOT EXPLAIN by Anonymous Coward · · Score: 0

    That describes him personally. To the point of ad hominem.

    THAT DOES NOT EXPLAIN THE CIRCUMSTANCES OF HIS DEATH.

    You know that, you evil person you.

    1. Re:That describes him; DOES NOT EXPLAIN by Anonymous Coward · · Score: 0

      > THAT DOES NOT EXPLAIN THE CIRCUMSTANCES OF HIS DEATH.

      The circumstances of his death were, he said he was going to kill himself, then he was found dead, having killed himself.

      To solve a crime, you need to establish motive, means and opportunity. You want to jump straight to "the police had a motiver, ergo they killed him." No evidence at all of means or opportunity.

  35. He's been a systems programmer for 35 years by Anonymous Coward · · Score: 0

    "The reason is we've reached a project scale, we've reached a typical volume of code, at which the defect rates from the kind of manual memory management that you have to do in those languages are simply unacceptable anymore..."

    Uh, really? I'm a C++ programmer and with modern idioms, memory management bugs are extremely rare. Is he just not familiar with the modern idioms or does he think his experience from 20 years ago is actually still applicable today in modern code?

    1. Re:He's been a systems programmer for 35 years by Anonymous Coward · · Score: 0

      Sounds like a C coder attempting to write C++.

    2. Re:He's been a systems programmer for 35 years by Njovich · · Score: 1

      I'm not a C++ programmer, but I'm genuinely curious. What idioms would that be?

    3. Re:He's been a systems programmer for 35 years by Anonymous Coward · · Score: 0

      A whole slew of similar idioms that can be broadly lumped under "resource acquisition is initialization" (RAII), which I think is a bit misnamed - but incredibly useful, because memory management is actually just a special case of general "resource ownership" problem. It isn't just memory we want to manage, it's things like file system handles, mutexes (mutices?), or even operating system features. This broader problem boils down to managing what parts of your code "own" those resources - where "own" means "is responsible for releasing. With RAII, the lifetime of a resource is equivalent to that of its owner. Initializing the resource's owner means the resource exists; destroying the resource's owner means the resource is also destroyed. Practically, this means that a "resource owner" in C++ will release its resource in its destructor - which is guaranteed to be called when the owner goes out of scope, assuming you aren't fucking around behind the compiler's back.

      Most problems in C++ boil down to lifetime semantics. With regards to memory management in particular, most related modern C++ idioms boil down to the principle that you *never use a raw pointer as an owner.* Smart pointers like shared_ptr and unique_ptr enforce RAII lifetime semantics - when a unique_ptr goes out of scope, its memory is released. When a shared_ptr has no more references, its memory is released. The standard containers have RAII semantics, as well.

  36. Re: remember by Anonymous Coward · · Score: 0

    No, not needed. As I said before, I was writing in the heat of the moment. If you say the cops did nothing wrong then I guess I'll have to believe you. Even if I suspect foul play.

  37. Re: remember by Anonymous Coward · · Score: 0

    Who said he was?

  38. Re: remember by Anonymous Coward · · Score: 0

    Look at GP post and it's about Murdock, did anyone else enter the discussion?

    Where'd the shit about 'artillery' come from? Basically the cops DID whack him on the ass and stick him in a cell.

  39. "Real programmers don't comment their code..." by No+Longer+an+AC · · Score: 1

    Documentation is important.....Code that's difficult to read, difficult to understand

    "Real programmers don't comment their code. If it was hard to write, it should be hard to understand." - some coder who doesn't work here anymore.