Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

C# Memory Leak Torpedoed Princeton's DARPA Chances 560

nil0lab writes "In a case of 20/20 hindsight, Princeton DARPA Grand Challenge team member Bryan Cattle reflects on how their code failed to forget obstacles it had passed. It was written in Microsoft's C#, which isn't supposed to let you have memory leaks. 'We kept noticing that the computer would begin to bog down after extended periods of driving. This problem was pernicious because it only showed up after 40 minutes to an hour of driving around and collecting obstacles. The computer performance would just gradually slow down until the car just simply stopped responding, usually with the gas pedal down, and would just drive off into the bush until we pulled the plug. We looked through the code on paper, literally line by line, and just couldn't for the life of us imagine what the problem was.'"
This discussion has been archived. No new comments can be posted.

C# Memory Leak Torpedoed Princeton's DARPA Chances

Comments Filter:
  • by mariuszbi ( 1113049 ) on Saturday November 17, 2007 @06:36AM (#21388605)
    I've RTFA, is wasn't a memory leak caused by C#, is was caused by bad programming. After that,the whole article starts to advertise some obscure profiling tool. Maybe they should should have written the whole thing in C++ and use valgrind instead. Just an ideea...
  • by JanusFury ( 452699 ) <kevin...gadd@@@gmail...com> on Saturday November 17, 2007 @06:39AM (#21388615) Homepage Journal
    It's not as if C doesn't leak memory when you mishandle resources. All these people needed to do was spend 5 minutes with the (free) MS .NET profiler and look at the allocation and GC graphs, and they'd be done.
  • by MathFox ( 686808 ) on Saturday November 17, 2007 @06:52AM (#21388653)
    I do think that this "object lifetime" bug is NOT a memory leak, but that does not change the effects (crash) of the system.
    What is interesting is to see that garbage collection changes one class of bugs (forgetting to explicitly deallocate memory) to another one: unintentionally keeping objects around. Princeton's "obstacle object" lifetime policy was stepped upon by a Dotnet library; Java has similar problems in its libraries. For the Princeton car software, an explicit deallocation routine (like in C/C++) would have been easy to implement.

    Problem is that both C/C++ style memory leaks and C#/Java hidden reference bugs usually remain hidden until the system crashes or trashes after some time. It makes them hard to find in the course of ordinary testing.

  • by ceeam ( 39911 ) on Saturday November 17, 2007 @06:59AM (#21388685)
    Of course it has nothing to do with differences between "managed code" and native, right?
  • by El Lobo ( 994537 ) on Saturday November 17, 2007 @07:03AM (#21388699)
    The problem was not the garbage collector if you read TFA. The articule is just a shameless plug, some ad spam for some very obscure profile.

    This just tells us once again that our wonderful editors on /. don't even try to understand what's behind an article, but they just find some sensationalistic title (the more AntiMS, the better) and done. This results in more comments of the type... "See, M$ id teh SuCkS", or "thanks god for my Linuzzz."..., so they got more profit for their /. ads (oh, the irony often MS ads, BTW).

    Yellow press..... yes, I know, /. is not supposed to have any credibility like any other parasite news sites, but anyway....

  • by slashdot.org ( 321932 ) on Saturday November 17, 2007 @07:04AM (#21388701) Homepage Journal
    Yeah, it's kind of bizarre. I'm not part of the crowd that actually believes the /. people get anything for posting these articles.

    But I do believe that articles written by companies pretending to be written by end-users are not terribly useful and probably shouldn't end up on /.

    I mean, the article clearly states at the top "By Red Gate Software.".

    So where did the "Bryan Cattle reflects on ..." credit come from? Some random line towards the bottom of what appears a highly edited blurb?

    Seriously.

    "One of our team members downloaded the 14-day trial of ANTS Profiler"

    "To our amazement, it was only minutes before we realized that our list of detected obstacles was never getting garbage collected"

    "If Only We Had Used It Earlier..."

    ANTS Profiler helped us fix a problem in minutes that would have taken us weeks to track down. If only we'd thought of it before the competition, we would most likely have finished the entire race and had a chance at the top prize money.

    All this stuff sounds either very naive or very marketing. You choose.
  • by maxwell demon ( 590494 ) on Saturday November 17, 2007 @07:17AM (#21388751) Journal
    As user of programs written in GCed languages, in my experience usually they are bad memory hogs. And don't tell me that memory is cheap. People constantly forget that we are not any more in the days of DOS, where there was essentially only one program running at any time.
  • by Bill Dog ( 726542 ) on Saturday November 17, 2007 @07:18AM (#21388757) Journal
    ...the whole thing in C++ and use valgrind instead.

    Or better yet, in C++ and use the RAII idiom. I.e. utilize the power of deterministic destruction, that C# and Java lack, to arrange it so that resources, including but not limited to just memory, are auto-freed. (You *can* run into this same kind of problem using reference-counted smart pointers in C++, but happily much of the time they aren't needed.)
  • by blowdart ( 31458 ) on Saturday November 17, 2007 @07:25AM (#21388789) Homepage

    I think you're getting hung up on the method name. There is no standard "delete" function that marks something as unused (dispose on the other hand sort of gets there). The article itself is unclear but I would assume that they were simply deleting the collision objects from a collection of potential hazards. Whilst that would remove the object from the collection itself it is *not* a delete. As references to the object existed elsewhere the object still exists (look ma, no null pointer exceptions) no delete happens. You cannot specifically say to the GC "We're done with this, delete it", the GC sweeps on a regular basis looking for objects with no references.

    Would you really want the GC deciding that just because an object is no longer part of a collection it's safe to unsubscribe it from events and delete it? I know I wouldn't.

  • by slashdot.org ( 321932 ) on Saturday November 17, 2007 @07:34AM (#21388833) Homepage Journal
    Of course you can have a memory leak in a managed language! Any Java programmer who's decent understands that.

    Decent programmers might understand that, but let's be honest, it's not like Java (and other GC languages) haven't been presented as if memory leaks were a thing of the past.

    As a matter of fact, some people will probably still claim that it's technically not a memory leak, but instead an object life-span issue.

    What surprises me is that outspoken proponents of managed languages use the garbage collection so often as a good thing, as if now you can be a sloppier programmer and get away with it.

    In reality you have to identify/control the lifespan of objects anyway, so I personally never understood what the big deal is about freeing memory manually. Not to mention that memory leaks in say, C++ code, really aren't that hard to find. The tools have become pretty freakin decent.

    And also not to mention that garbage collection might be handy for memory, but memory is only one of a plethora of resources that can be leaked. And since for many resources it isn't nearly as appropriate to 'lazy' free them, as a programmer you still have to be aware of the allocate/free paradigm. (as just one silly example, it would suck if you wouldn't be able to explicitly close a file, because you can't delete it before it's closed)

    In other words, you are right. Of course you can have memory leaks in garbage collected languages. And I wish people would stop using GC as an argument why languages as Java are so much better to use than C++.
  • by WeirdJohn ( 1170585 ) on Saturday November 17, 2007 @07:34AM (#21388835)
    The whole 'reboot to fix it' is a methodology that we're going to see more and more of, as students who have only ever been exposed to windows platforms become more and more pervasive.

    Kinda scary when they start writing systems for medical applications, industrial controllers and power supply chain management, let alone nationwide air traffic monitoring or emergency services interactions management.

      "Hang on, we have to reboot our systems every 6 hours in order to manage this natural disaster - You can be advised when the flood waters will peak in about 15 minutes - did you say the bridge is washing away, and your phone lines are about to fall down? Ring us back in 15 minutes after the systems finish rebooting"
  • by jmccay ( 70985 ) on Saturday November 17, 2007 @08:13AM (#21388969) Journal
    I think this is just poor code debugging skills. The new garbage collected languages (C# and Java) seem to be creating coders that don't know the basics of debugging. If this was C++, the bug would have shown up when an event occurred and the code called a deleted object. It would have been harder to track down. In any case, I would have added code to analyze the state of the stack and it's objects since it only occurred after the program/car had been running for a while. Also, had it not occurred to them to increase the number of obstacles beyond the "controlled" environment? You can easily write test code to to add a lot of objects into the stack without the use of the car.

    Our cars used an asynchronous event-based code stack written from scratch by us.
    They wrote their code stack from scratch. They should have modified an existing one that was proven to work. Either way, I think this is a case of sloppy programming. I don't think it is worth mention aside from the case what the closest thing to a memory leak is that you can have. Unfortunately, that too should have come to mind from them. They ruled that out because "most of [their] code is written in garbage-collected C#". Just because a language is garbage collected, it doesn't mean you can just ignore the issues. All reference to the object must be removed for it to be deleted. This is definitely a case of sloppy programming. I would be embarrassed if my name were attached to this.

          Some old Visual Basic programmer jokes come to mind when I read this article. People use to make fun of Visual Basic programmers because it was to easy to write programs in VB. They thought it would produce sloppy code with errors, and other similar things. To some extent, it appears that same case could be made for C#, and to a lesser extent Java. In the end this is simply a case of not stress testing their event stack.
  • by Ihlosi ( 895663 ) on Saturday November 17, 2007 @08:26AM (#21389009)
    usually with the gas pedal down, and would just drive off into the bush until we pulled the plug.

    Yikes. So these guys have the smarts to make a computer drive a car on its own, but managed to forget some basic safety mechanisms such as a watchdog and other failsafe mechanisms ?

    Geez guys - real world engineering 101: Do not let a computer control anything that might have a remote chance of harming someone without appropriate safety mechanisms.

  • by MajorCatastrophe ( 662787 ) on Saturday November 17, 2007 @08:34AM (#21389035)

    What "ruined their chances" was not that they overlooked a memory leak, what ruined their chances was that they didn't know what they were doing.

    Whereas code written by people who "know what they're doing" has zero bugs - ever. Right. And to assert that they didn't test their software is ludicrous.

  • by multi io ( 640409 ) <olaf.klischat@googlemail.com> on Saturday November 17, 2007 @08:46AM (#21389081)
    You could just use weak references (does C# support that?) for all references that the event sender uses to reference its event receivers. In that case, as soon as a receiver has been removed from all those "obstacle lists" and all other objects that held references to it, the weak reference would be the only reference pointing to the receiver, which would make the receiver eligible for garbage collection.
  • by Anonymous Coward on Saturday November 17, 2007 @08:56AM (#21389125)
    Sad story, but it was THEIR fault. The story title "C# Memory Leak ..." is flat out wrong.

    There is no leak in C# per se. They kept a reference to the objects, so the CLR wasn't even supposed to delete them.

    Morons shouldn't be making car software.

  • by h4rm0ny ( 722443 ) on Saturday November 17, 2007 @08:58AM (#21389133) Journal

    Agreed. I was a good VB programmer. But my VB experience was an eight-month interval between C++ jobs. I've knocked out minor MS Office applications when needed since then, but that's it. I'm sorry to say that most of the VB programmers I've worked with were very poor engineers. Admittedly I've not worked in VB for wealthy companies whilst I have in C++, so that colours things somewhat. I don't doubt that there are some good VB programmers out there. But in the cases of most of those I worked with, I could very clearly see how VB led them to be poor engineers. The amount of shortcuts and wizards and instances where they would start their program by dragging a form object onto the design panel and dumping form objects onto it was obviously a leading reason for their poor skills. VB *led* them to take this approach. It works for small Excel apps, barely for database front-ends and not well at all for large projects.

    As is common with the lower end of Microsoft products, the selling point is that they make it very easy to do what they think you want to do. The ability of VB to knock out an interactive form with near-zero knowledge of programming has encouraged a lot of colleges to sell people the idea that a ten-week course of dragging and dropping text box objects is programming whilst a lot of cheap or ignorant employers have taken the graduates at their word and plunged them in over their heads.

    VB is a poor language in many ways and not, imo, suited to a large or sophisticated project. But you can find good VB programmers (was one). It's just that it encourages bad ones.

    Oh, the summary is also wrong. C# hasn't started springing leaks. The programmers missed a reference to objects that they were creating and the garbage collection therefore never triggered to unallocate the memory. I don't doubt it's not easy to automate a vehicle to drive any even 9 miles, but this could have been detected with more thorough debugging. At any rate, the article submitter and overseeing editor should be ashamed of twisting this into an anti-Microsoft jab. I'm a Linux programmer. I can tell you that Linux can compete happily without sinking to the level of lies and misinformation.
  • Reference counting (Score:2, Insightful)

    by Megane ( 129182 ) on Saturday November 17, 2007 @09:07AM (#21389159)

    I just read TFA and it doesn't give any details. My guess? I just checked, and C# apparently uses reference-count garbage collection. That means that an object will stay around until there are zero references to it. The best way to create an object that will never go away is to create a circular linked list, then delete the reference to the list. All the items refer to each other, but there is nothing else that references them. But any complicated data structure that can have circular references will leak memory.

    A mark-sweep garbage collector will catch this, but at the cost of interrupting the program temporarily to do GC. This isn't exactly friendly to real-time applications.

    So basically this looks like a classic noob blunder. Just because there is "automatic" garbage collection doesn't mean that you can turn your brain off.

  • by _merlin ( 160982 ) on Saturday November 17, 2007 @09:16AM (#21389191) Homepage Journal
    I'm guessing you wanted me to laugh, but in a highly parallel system, going through the code line by line is often the most effective way of finding a problem. When you catch the bug on a running system, you can see the state it's got itself into. But to figure out how it could have got there, you need to read and analyse the code. People are often far too eager to jump into the debugger when critically analysing the code is often a better solution.

    It obviously doesn't work in situations like this where the bug is in the runtime and not the application.
  • Re:only 10KLOC? (Score:4, Insightful)

    by dkf ( 304284 ) <donal.k.fellows@manchester.ac.uk> on Saturday November 17, 2007 @09:35AM (#21389261) Homepage

    What surprises me most is the small size of their software, only 10 thousands lines of source code (I think that the average car processor already have these for today's cars -ignition & braking systems-). Given a team of a dozen programmers working for a year, I was expecting at least 50KLOC, or maybe 200KLOC (for example, the GCC compiler is 3MLOC, and the linux kernel has comparable size.)
    Ah, but that 10kLOC needs to be the right 10k, and not all lines of code are the same (incrementing a variable is quite a bit simpler than calling a complex method). Plus you also don't know how many lines of code they threw away.
  • by WhatAmIDoingHere ( 742870 ) * <sexwithanimals@gmail.com> on Saturday November 17, 2007 @09:38AM (#21389271) Homepage
    Slashdot is a blog not a news source. I wish more people would realize that.
  • by bhima ( 46039 ) <(Bhima.Pandava) (at) (gmail.com)> on Saturday November 17, 2007 @10:32AM (#21389587) Journal
    Fuck. You are so right. This article is just some advertisement for some obscure profiler.

    However I take exception to your use of the world "Editor". Slashdot does not have Editors. They have guys who accept submissions.
    They don't read The Fucking Articles, They don't check links, The don't edit submissions...
  • by noidentity ( 188756 ) on Saturday November 17, 2007 @10:42AM (#21389649)

    I just checked, and C# apparently uses reference-count garbage collection.

    I highly doubt that. Got a link?

  • by gbjbaanb ( 229885 ) on Saturday November 17, 2007 @10:59AM (#21389779)

    And given the level of skill the average programmer has, anything that makes memory leaks less likely (though not impossible) has got to be seen as a good thing.
    NO! It is not a good thing, if a program slowly leaks memory then it just makes it harder to find the bug. If you have to reboot the app every week because it has a little leak, no-one's going to be bothered (except the users who see it slowly getting slower). If it has to be restarted daily then you're going to be looking to fix the bug.

    It is easy to leak memory in C++, if you don't know what you're doing. Its easy to leak memory in C#/Java if you don't know what you're doing. That the language makes it easy for you to avoid becoming a better programmer is NOT a good thing.

    I have a good analogy - Firefox. I use FF a lot, I like it, but it does tend to increase its memory usage over time, and has been rightly criticised for it. Now, I'm sure the 'bug' is an aspect of its design and not a programming bug (and I don't want to start a FF memory discussion - I'm only using it as a real-world example) but just imagine if *every* program was like FF - slowly using more and more RAM over time until you restarted it.

    This is what you're asking for when you say that its ok for the average programmer to use C# because the app will have fewer leaks: you'll get fewer leaks. Not none. If the app leaked like a sieve, it'd be spotted in development/test and fixed; if it leaks slowly enough so it passes an hour's testing in certification, then it'll be shipped - and its you that'll get to find the bug as you use it.
  • by samkass ( 174571 ) on Saturday November 17, 2007 @11:07AM (#21389829) Homepage Journal
    The new garbage collected languages (C# and Java) seem to be creating coders that don't know the basics of debugging.

    An interesting observation. Java is a lot harder to write bugs in and is easier to debug (with more runtime information), so coders spend a lot less time in the debug cycle and therefore get less experience doing it. So should we design our languages to be obtuse and hard to read (ie. C++) or continue trying to design languages that make it harder to get things wrong?

    Java has made some wrong turns in this regard (ie. autoboxing-- I wonder if we can yank that from the language in JDK7), but in general has done a great job of making it difficult to tie that noose for yourself.

  • in the URL (Score:5, Insightful)

    by HeroreV ( 869368 ) on Saturday November 17, 2007 @11:31AM (#21390007) Homepage
    Slashdot editors are even more pathetic than I thought they were. It's bad enough that they didn't skim through the article, but they apparently didn't even take a look at the URL. Look at this thing:
    http://www.codeproject.com/showcase/IfOnlyWedUsedANTSProfiler.asp
    "IfOnlyWedUsedANTSProfiler"? That didn't raise any flags?

    Of course, I'm trying to assume good faith and not just conclude that the editors knew this was an advertisement, but they sure are making that difficult.
  • by fuali ( 546548 ) on Saturday November 17, 2007 @11:38AM (#21390069) Homepage
    ...on slash dot if it was written in perl on the linux platform. This is just an oppurtunity for someone to read part of a story, make a snappy title that bashes Microsoft based on the misunderstanding of the technology in an article.

    This is not a c# memory leak, it was a memory leak written in c#. The developers used a commerical tool to find there problem, a trail version even. So how about a title "Commercial Code Profiler Saves the Day For DARPA team"?

    Oh because then it would never be a slash dot article, ugh.

    Developers making a mistake != c# bug

    The IDisposable interface is there for a reason.
  • Comment removed (Score:3, Insightful)

    by account_deleted ( 4530225 ) on Saturday November 17, 2007 @11:45AM (#21390105)
    Comment removed based on user account deletion
  • Re:Ummm... (Score:4, Insightful)

    by 19thNervousBreakdown ( 768619 ) <davec-slashdot&lepertheory,net> on Saturday November 17, 2007 @11:47AM (#21390115) Homepage

    It's the programmer and the language. Give the world's best carpenter a ball-peen hammer and ask him to build you a beautiful armoire, see what happens.

    You can say now that they'll be much further next year, but until then "Which means that the language did the job very nicely" should be "Which would mean that the language did the job very nicely." If you put in a reminder of some sort to come back and say I told you so, I'd be more than happy to eat my words if they continue using C# and place in the top 33%. Hell, I'd even concede that you might be right if they manage the top 50%.

    I say, however, that there is a right language for the job. Sure, there's overlap, but you don't implement your FFT in Perl when the problem is that you need the fastest FFT possible, you don't write a word-processor in assembly, and you don't write anything in Brainfuck even though they're all Turing-complete. Anyone who says you can do anything in any language is trying to justify using their favorite language for absolutely everything.

  • Re:Ahahaha! (Score:3, Insightful)

    by gbjbaanb ( 229885 ) on Saturday November 17, 2007 @11:49AM (#21390131)
    No flame here - I think the issues you describe with C# programmers are to do with the age of the language, no-ones really an expert in it as although its been around a while, its only recently people have started coding 'proper' applications in it.

    Its my experience with it that apps written using it are poor too though. I've been headhunted twice now by companies that rewrote their old apps in this cool, new language only to find that it performed so badly they couldn't sell it. (I used to be a performance engineer/troubleshooter at my last job).

    And its not just C#, its the .NET thing in its entirety. I had a little task to do once that involved taking a dozen DB columns and merging them into 1. No problem, I thought I'd write it in managed C++ (as it was a throwaway oneoff task), and it was easy to write and ran ok on my test DB of 300 rows. When I ran it on the live DB, I calculated it would have taken 13 hours to run through all the half-million rows they had (even after doing every optimisation trick I knew, and cutting the code to the minimum). So I rewrote it in "old-fashioned" OLE-DB and it took 10 minutes.

    I'm not a fan of .NET either.
  • by simonech ( 229668 ) on Saturday November 17, 2007 @12:11PM (#21390281) Homepage
    I usually like /. articles, even the ones against MS, but I cannot just skip over this one:
    if the moderator read the article he would have noticed that the article was an advertisement for the profiler product, not just a review of it (it was written directly by Red Gate).
    Second, the article itself says that they found that the error was in how they coded the application, because they left some reference so the garbage collector didn't trow away the objects.
    This is a really bad article and bad information.
  • by spun ( 1352 ) <loverevolutionary@@@yahoo...com> on Saturday November 17, 2007 @12:14PM (#21390299) Journal
    Come on. Really. What kind of idiot marketer sends in stories like this to Slashdot? We know what happens. First, you get derided mercilessly for trying to sway us with your ridiculously transparent attempt at marketing. Then, the real experts come out and poke holes in everything you've said. Then everyone else chimes in with better (and often free) alternatives. You and your company end up looking like buffoons, and your product ends up looking like utter garbage.

    You may think you're pulling one over on the editors, and maybe you are. But you aren't pulling one over on us, and I think after all these years, the editors know this. So, just don't. Unless your product or service is absolutely bulletproof people here are more likely to shoot it full of holes than rush out and buy it.
  • by Anonymous Brave Guy ( 457657 ) on Saturday November 17, 2007 @12:35PM (#21390423)

    I think there's a rite of passage in programming. First, you see a bug and immediately assume your code is right and the compiler is wrong. With a little experience, you learn that it's actually a darn good bet that your code is the thing with the problem. With a lot of experience, you learn that while it's a darn good bet, on rare occasions the compiler really does get it wrong, but that it usually takes a horrendously long, assembly-level debugging session to prove it.

    Much the same is true of the standard library that comes with your programming language, or any high quality third party library you use. Some of these are considerably more robust than others, but usually if it's something thousands of projects are using, it's going to be your project code that's wrong rather than the library.

  • by TargetBoy ( 322020 ) on Saturday November 17, 2007 @12:43PM (#21390469)

    They wrote their code stack from scratch. They should have modified an existing one that was proven to work. Either way, I think this is a case of sloppy programming. I don't think it is worth mention aside from the case what the closest thing to a memory leak is that you can have. Unfortunately, that too should have come to mind from them. They ruled that out because "most of [their] code is written in garbage-collected C#". Just because a language is garbage collected, it doesn't mean you can just ignore the issues. All reference to the object must be removed for it to be deleted. This is definitely a case of sloppy programming. I would be embarrassed if my name were attached to this

    We have to teach every new developer to share and reuse code and generally avoid continually reinventing the wheel because the anti-cheating rules in college keep them from learning it there. They were probably required to create it from scratch. There needs to be an upper level class where students are given projects that are impossible to complete in the allotted time unless they reuse code that is readily available.
  • by WED Fan ( 911325 ) <akahige@NOspAm.trashmail.net> on Saturday November 17, 2007 @01:20PM (#21390721) Homepage Journal

    Slashdot is a blog not a news source. I wish more people would realize that.

    ...

    News for Nerds. Stuff that matters.

    O.K., I'll bite, what part of that line do you not understand? If /. billed itself as a "blog" then I'd understand your point. However, /. is a corporate based, self-billed "News" site. Whether reader submission driven or not, it is a news site. You are wrong. But, thanks for your thoughts.

  • by Crazy Taco ( 1083423 ) on Saturday November 17, 2007 @03:09PM (#21391425)

    This just tells us once again that our wonderful editors on /. don't even try to understand what's behind an article, but they just find some sensationalistic title (the more AntiMS, the better) and done.

    I suspect it is the fault of slashdot user base as much as the editors. I bet a lot of users were in the firehose, saw the sensationalist title, etc, and rated it highly. The editor comes in, sees it has a sensationalist title and is now colored read, meaning users really think it is great, and posts it. So yes, the editor may not have read the article, but I'm sure the user base didn't either, at least not until after it got posted.

  • by budgenator ( 254554 ) on Saturday November 17, 2007 @03:14PM (#21391461) Journal
    hopefully you programmed things so if the accelerator_actuator object hasn't heard from the speed_control object in a while it returns to an idle mode rather than bizercko autonomus vehicle peddle to the metal mode, like the Princeton guys did.
  • Re:only 10KLOC? (Score:5, Insightful)

    by comp.sci ( 557773 ) on Saturday November 17, 2007 @03:37PM (#21391629)
    It's amusing to see that there are still people who believe in the old "more lines of code means better performance".
    Seriously, the performance of these cars is amazing, a huge step from just a few years ago. The hard part of this project was certainly not the programming, but the concepts behind the obstacle detection and such. This is not an implementation exercise, but more of an academic experiment to test out new ideas.

    (Nice work on mentioning Haskell to guarantee an upmod btw.)
  • by asills ( 230118 ) on Saturday November 17, 2007 @04:26PM (#21391975)
    This "article" also shows why you don't let college students write productions systems.

    "We set a timer to restart the computer after 40 minutes".

    Wait. What? Really? That's classic programming by accident. "I added one and it started working, so I moved on."
  • by chromatic ( 9471 ) on Saturday November 17, 2007 @04:32PM (#21392011) Homepage

    This may sound horrible, but having to actually understand code in order to work with it is a recipe for disaster.

    It seems to me that hiring barely-competent monkeys to maintain software you care about is the real problem.

  • by Brett Buck ( 811747 ) on Saturday November 17, 2007 @04:39PM (#21392061)
    Hey, here's a wacky idea that's just crazy enough to work - DON"T USE DYNAMIC MEMORY ALLOCATION! Why in holy hell would someone construct what amount to an embedded real-time system using dynamic memory. Define fixed memory allocations for everything. Run tests. If the memory is insufficient, the program crashes. Then you can see where the program crashes and why. Then you can fix it.

          Just because you *can* do something doesn't mean you should.

              Brett
  • by nametaken ( 610866 ) on Saturday November 17, 2007 @04:51PM (#21392133)

    I'm sure you're a much better programmer than I am, so I have to ask... why does using the form designer makes someone write bad database access? I'm also curious about what makes VB a poor language. I hear this pretty frequently, but have never gotten a honest explanation of why. Personally, I don't think I've ever encountered a task accomplished, or bit of code written in C# that I couldn't easily translate to VB, and vice-versa. Someone once told me there was some limitation on utilizing System.Reflection, but I just haven't encountered any problems yet. Also, don't the both compile to the same runtime language? I've always assumed it was a "6 and one half dozen" situation, and had more to do with syntax preference than anything.

  • by dbIII ( 701233 ) on Saturday November 17, 2007 @09:08PM (#21393985)
    It's sort of a blog from before the word was thought of and not Reuters.
  • by MickDownUnder ( 627418 ) on Sunday November 18, 2007 @12:33PM (#21398171)
    You are right, the wording of this article is extremely misleading.

    There was a memory leak but it was due to their code, not with the Microsoft .NET Framework. Specifically their code was creating objects that were never being garbage collected as they were still being referenced in their code, i.e. they forgot to dispose and unsubscribe from events to objects that were still active. This is a really simple mistake you'd probably find in 40% of newbie programmers C# or Java code. Yes... this sort of problem can occur just as easily in Java (even more easily if you believe Microsoft).

    Now on to flaming slashdot...

    I really think Slashdot should pull articles like these either completely or at least from the front page when they realise they're misleading or factually incorrect.

    This story simply isn't news worthy, it's not even interesting for anyone half competant in .NET development. It reflects really poorly on slashdot and reduces the sight to the quality of your average web blog. In summary it's a waste of everyone's time.

Neutrinos have bad breadth.

Working...