Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Thermopyle posted:

I wonder if they're like a lot of really smart guys in professions that use programming rather than being in a profession about programming. Take the typical¹ code written by a scientist...yuck.

¹ Not that I have a lot of experience looking at scientific code, but the little bit that I have is not pretty.

That tends to be the case. I have a friend who's doing some .NET work in order to automate some of his network administration tasks, and he doesn't care about the quality of the code as long as it does what he needs.

# ? Jul 2, 2012 15:25

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 16:10

Progressive JPEG: Feb 19, 2003

Thermopyle posted:

Take the typical code written by a scientist...yuck.

Going by my profs in college, a lot of scientific code is pretty much a one-off whose useful lifespan ends once a paper gets published. There may occasionally be useful fragments that get copy/pasted later, but that's about it.

# ? Jul 2, 2012 16:11

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Thermopyle posted:

I wonder if they're like a lot of really smart guys in professions that use programming rather than being in a profession about programming. Take the typical¹ code written by a scientist...yuck.

They focus on recruiting people who are good at functional programming and are willing to learn finance stuff, not finance people willing to learn to program, and their open source replacement for the OCaml standard library is fairly high quality.

# ? Jul 2, 2012 16:22

Zombywuf: Mar 29, 2008

Plorkyeran posted:

They focus on recruiting people who are good at functional programming and are willing to learn finance stuff, not finance people willing to learn to program, and their open source replacement for the OCaml standard library is fairly high quality.

Not all companies will be alike. I doubt we'll ever see an actual reflection of coding practices vs. outcomes, but I bet there are a huge number of approaches that all work about as well as each other.

# ? Jul 2, 2012 16:38

Modern Pragmatist: Aug 20, 2008

beoba posted:

Going by my profs in college, a lot of scientific code is pretty much a one-off whose useful lifespan ends once a paper gets published. There may occasionally be useful fragments that get copy/pasted later, but that's about it.

And the wheel is reinvented (poorly) annually. Paid for by your tax dollars.

# ? Jul 2, 2012 16:38

Progressive JPEG: Feb 19, 2003

Modern Pragmatist posted:

And the wheel is reinvented (poorly) annually. Paid for by your tax dollars.

Not really. For the people I knew, they relied heavily on common libraries for most of the heavy lifting (image/signal processing, math packages, etc). The messy one-off bits would be largely unique to that particular research. The ones I knew were pretty good at not wasting time on reinventing the wheel, as well as recognizing when the code they were writing only needed to work once.

# ? Jul 2, 2012 16:48

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

beoba posted:

Going by my profs in college, a lot of scientific code is pretty much a one-off whose useful lifespan ends once a paper gets published. There may occasionally be useful fragments that get copy/pasted later, but that's about it.

There's a huge problem in science right now where it's extremely difficult to replicate others work because code isn't available or the exact environment the code was used in isn't documented well.

This sort of thinking doesn't help that problem.

# ? Jul 2, 2012 17:36

tef: May 30, 2004; -> some l-system crap ->

Thermopyle posted:

There's a huge problem in science right now where it's extremely difficult to replicate others work because code isn't available or the exact environment the code was used in isn't documented well.

This sort of thinking doesn't help that problem.

�In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.�

:smug:

# ? Jul 2, 2012 18:33

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Thermopyle posted:

There's a huge problem in science right now where it's extremely difficult to replicate others work because code isn't available or the exact environment the code was used in isn't documented well.

This sort of thinking doesn't help that problem.

That's not totally bad, though, given the nature of science. The LHC has two very different detectors designed and built by two totally separate teams because it's not only good but necessary to have more than one viewpoint in order to confirm findings. Bugs in the One True Implementation Used By Everyone could produce erroneous results that don't get caught for years and then take even more years to work out of the working knowledge base.

# ? Jul 2, 2012 18:46

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Munkeymon posted:

That's not totally bad, though, given the nature of science. The LHC has two very different detectors designed and built by two totally separate teams because it's not only good but necessary to have more than one viewpoint in order to confirm findings. Bugs in the One True Implementation Used By Everyone could produce erroneous results that don't get caught for years and then take even more years to work out of the working knowledge base.

Sure, but the solution to the problem isn't "gently caress it, let's make it as hard as possible to replicate", it's to make the code open.

# ? Jul 2, 2012 19:26

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Thermopyle posted:

Sure, but the solution to the problem isn't "gently caress it, let's make it as hard as possible to replicate", it's to make the code open.

TBH that actually isn't the hard part - people have problems in the scientific community even if you give them the source code. Just making sure all the libraries/etc that you could have linked against are present and that your build environment is reproducible is pretty tough when you don't test how easy it is to replicate your build environment (and you don't really know what you're doing).

# ? Jul 2, 2012 20:51

Beef: Jul 26, 2004

Your academic worth and survival is a function of your publication record: publish or die. There is no incentive to produce nice code or cleaning it up and releasing it in public. As much as I try to produce clean code or systems, my codebase has been mangled from years of modifications and experiments that were due yesterday.

The academic community needs to include code publishing standards as part of journal articles and conference proceedings. Next step is to also consider the code when accepting/rejecting a paper.

# ? Jul 3, 2012 12:09

OnceIWasAnOstrich: Jul 22, 2006

Beef posted:

Your academic worth and survival is a function of your publication record: publish or die. There is no incentive to produce nice code or cleaning it up and releasing it in public. As much as I try to produce clean code or systems, my codebase has been mangled from years of modifications and experiments that were due yesterday.

The academic community needs to include code publishing standards as part of journal articles and conference proceedings. Next step is to also consider the code when accepting/rejecting a paper.

As someone who has published an open source program linked to a publication, this isnt exactly true. Spending the time to make sure it will work for anyone with half a brain and a Python interpreter without any native libraries has paid huge dividends in citations and grant money.

Although I agree more standards for releasing code in papers can only be a good thing.

Edit: Especially since it would provide enough fodder for this thread for all of eternity.

OnceIWasAnOstrich fucked around with this message at 14:10 on Jul 3, 2012

# ? Jul 3, 2012 13:56

Beef: Jul 26, 2004

Depends on how you get your grant money I guess.
I'm much happier now at a lab that understands the need to code and do a good job at it. The group is getting some flak because our quantity of publications is not on par to other groups.

Cleaned up code also encourages lab mates to pick up and continue the work. A common research platform can do wonders.

Now I only need to find my notes that explain this horror:

code:

   return 
    i 
    + p * ( n - 1 ) * floor( i / p      )
    - p * (m*n - 1) * floor( i / (m*p)  )
    + p * n * (n-1) * floor( i / (m*p*n));

Beef fucked around with this message at 14:40 on Jul 3, 2012

# ? Jul 3, 2012 14:33

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

IMGO the value of publishing code associated with a paper isn't so other people can use it, it's so that other people can inspect it and find bugs that could influence the results.

# ? Jul 3, 2012 14:37

Mr. Crow: May 22, 2008; Snap City mayor for life

code:

            //Make sure enddate is formatted correctly
            EndDate = EndDate.Date;

Please tell me I'm stupid and there's some bizarre case where this makes sense.

# ? Jul 3, 2012 16:36

hepatizon: Oct 27, 2010

Mr. Crow posted:

code:
            //Make sure enddate is formatted correctly
            EndDate = EndDate.Date;
Please tell me I'm stupid and there's some bizarre case where this makes sense.

I frequently do that (in Ruby) to handle values that could be either a datetime or date.

# ? Jul 3, 2012 18:53

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

That discards the time portion of the DateTime. The comment seems dumb, but it's often a perfectly sensible thing to be doing.

# ? Jul 3, 2012 18:58

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

So I found out one of my ex-coworkers was using Django templates to do JSON formatting....

code:

{"criteria" : "{{ criteria }}",
"users" : [
    {% if criteria == "score"  %}
        {% for info in user_stats %}
        {"player" : {% if info.id == player %} true {% else %} false {% endif %}, 
         "rank" :{{ forloop.counter }},
         "public_identifier" : "{{ info.value.public_identifier }}",
         "score" : {{ info.value.score }},
         "service_identifier" : "{{ info.value.service_identifier }}"},
        {% endfor %}
    {% endif %}
    {% if criteria == "doits"  %}
        {% for info in user_stats %}
        {"player" : {% if info.id == player %} true {% else %} false {% endif %}, 
         "rank" :{{ forloop.counter }},
         "public_identifier" : "{{ info.value.public_identifier }}",
         "doits" : {{ info.value.total_doits }},
         "service_identifier" : "{{ info.value.service_identifier }}"},
        {% endfor %}
    {% endif %}
]
}

# ? Jul 3, 2012 19:54

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

ultramiraculous posted:

one of my ex-coworkers

Where are you headed next?

# ? Jul 3, 2012 20:05

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Suspicious Dish posted:

Where are you headed next?

Nah, I mean he doesn't work here anymore

# ? Jul 3, 2012 22:25

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Did the guy, like, EVER have a read through the django documentation? Considering how often serialisation is mentioned in it you'd think he would have noticed.

# ? Jul 3, 2012 23:31

bobthecheese: Jun 7, 2006; Although I've never met Martha Stewart, I'll probably never birth her child.

php:

<?
//make sure this cron isn't already running
exec("ps aux", $output);
$num=0;
foreach($output as $eachProg){
    if(strpos($eachProg,"exportToFastpick.php")!==false){
        $num++;
    }
}
if($num>1){
    die;
}?>

I don't know how to feel about this.

# ? Jul 4, 2012 01:38

Zamujasa: Oct 27, 2010; Bread Liar

quote:

I don't know how to feel about this.

At first I was thinking "Well, at least it gets the job done, even if it kind of sucks". Then I noticed that it was checking $num>1. :cripes:

# ? Jul 4, 2012 01:48

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Zamujasa posted:

At first I was thinking "Well, at least it gets the job done, even if it kind of sucks". Then I noticed that it was checking $num>1.

It works if you actually execute the correct unix commands: `ps aux | grep exportToFastpick.php | wc -l` !

# ? Jul 4, 2012 04:52

pseudorandom name: May 6, 2007

Zamujasa posted:

At first I was thinking "Well, at least it gets the job done, even if it kind of sucks". Then I noticed that it was checking $num>1.

The script counts itself, so $num > 1 is "correct."

The real problem is that two instances can both decide that the other was started first and exit without doing whatever work they're supposed to do.

# ? Jul 4, 2012 04:57

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

I don't think this was posted here yet:

quote:

The general case

Given valid C code, gcc will generate machine instructions that correctly do what you want. Of course, there are bugs in gcc just like any other piece of software. The problem in this case is not gcc. The problem is that the object and garbage collection implementations in REE/MRI/YARV are not valid C code, so it is not possible for gcc to generate machine instructions that do the right thing. In other words, Ruby's object and GC implementations are breaking their contract with gcc.

The end result is the need for poo poo like RB_GC_GUARD in REE/MRI/YARV and also in Ruby gems to selectively paper over valid gcc optimizations. Having an API that might cause the Ruby VM to loving explode unless you proactively mark things with RB_GC_GUARD is not on the path of least resistance toward building a maintainable, safe, and performant system. Very few people out there know that the volatile type qualifier exists, let alone what it does. Essentially, this means that authors of Ruby gems must understand how GC works in the VM to prevent their gems from causing GC to break the universe.

That is loving beyond stupid.

Quoted from http://timetobleed.com/the-broken-promises-of-mrireeyarv/

I rather like this guy's style.

E:

code:

if (until_no_new)
  {
    /* Require 4 successive iterations which do not find any new threads.
        The 4 is a heuristic: there is an inherent race here, and I have
        seen that 2 iterations in a row are not always sufficient to
        "capture" all threads.  */
    for (i = 0, loop = 0; loop < 4; ++i, ++loop)
        if (find_new_threads_once (info, i, NULL) != 0)
          /* Found some new threads.  Restart the loop from beginning.��*/
          loop = -1;
  }

Which is actually from GDB http://timetobleed.com/how-do-debuggers-keep-track-of-the-threads-in-your-program/

Munkeymon fucked around with this message at 05:34 on Jul 4, 2012

# ? Jul 4, 2012 05:10

pseudorandom name: May 6, 2007

Munkeymon posted:

Quoted from http://timetobleed.com/the-broken-promises-of-mrireeyarv/

For those of you who were curious like me, Java solves this problem with JNI by creating a temporary object registry before calling a native method, and adding GC visible references to that registry for every object passed to the native method or returned by a JNI function called by the native method.

# ? Jul 4, 2012 05:34

Opinion Haver: Apr 9, 2007

Munkeymon posted:

I don't think this was posted here yet:

Quoted from http://timetobleed.com/the-broken-promises-of-mrireeyarv/

I rather like this guy's style.

Looking at that C code, it looks perfectly valid to me. What's the problem?

# ? Jul 4, 2012 05:43

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Yeah, I don't understand either.

quote:

The return value of gzfile_read_raw_ensure (an address of a ruby object) is stored in rax.

gzfile_read_raw_ensure looks like it returns a boolean (or int) to me :confused:

. I understand that Ruby is doing conservative stack scanning to implement the GC, but otherwise you'd have to root/unroot every single object, which is super annoying and error-prone.

# ? Jul 4, 2012 05:54

pseudorandom name: May 6, 2007

gcc doesn't bother writing str to the stack because it is local to gzfile_read_raw_ensure() and doesn't escape. So str lives in %rax for the entire time gzfile_read_raw_ensure() is using it.

In the AMD64 psABI, %rax is not preserved across function calls -- if the current function cares about its contents, it has to save the register itself. gzfile_read_raw_ensure() doesn't bother saving str to the stack when it starts calling other functions because by that time it's done with the variable and doesn't need it anymore.

The only pointers to str that exist (those created by RSTRING_STR() and RSTRING_LEN()) point to within the RString object, not to the beginning of the object, and the GC doesn't considered internal pointers to be valid.

Edit 1: OK, the Ruby VM does consider machine registers to be GC roots, but it does it in the most retarded way possible -- it calls setjmp() and assumes the resulting buffer contains the actual register values.

Edit 2: Changed my explanation to actually be correct. Edit #1 is no longer relevant to this particular bug, but still amusing.

pseudorandom name fucked around with this message at 06:56 on Jul 4, 2012

# ? Jul 4, 2012 06:01

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Yeah, so the guy just doesn't understand conservative stack scanning. Given that the register is swamped before the GC is called, I don't see any other way around it, other than taking an explicit root.

So it's not a fundamental problem with Ruby's object model, it's that one of GCC's optimizations makes the assumption that a program should not need to scan the stack and find valid results like that. You cannot compile such programs that do fancy (but completely valid) tricks with those optimizations.

# ? Jul 4, 2012 06:49

pseudorandom name: May 6, 2007

Apparently the Ruby GC isn't conservative enough and doesn't consider addresses pointing inside an object to be object references, otherwise %rax + 0x10 and %rax + 0x18 would be sufficient.

# ? Jul 4, 2012 07:01

that awful man: Feb 18, 2007; YOSPOS, bitch

tef posted:

�In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.�

Cool, but I think this is probably my favorite Dijkstra quote:

EWD898 posted:

These were internal complications. For a better understanding of the external pressures we had better view our topic for a moment in the wider context of science and society in general. Because computers appeared in a decade when faith in the progress and wholesomeness of science and technology was virtually unlimited, it might be wise to recall that, in view of its original objectives, mankind's scientific endeavours over, say, the last five centuries have been a spectacular failure.

As you all remember, the first and foremost objective was the development of the Elixir that would give the one that drank it Eternal Youth. But since there is not much point in eternal poverty, the world of science quickly embarked on its second project, viz. the Philosopher's Stone that would enable you to make as much Gold as you needed.

Needless to say, the planning of these two grandiose research projects went far beyond the predictive powers of the seers of that day and, for sound reasons of management, the accurate prediction of the future became the third hot scientific issue.

Well, we all know what happened as the centuries went by: medicine, chemistry, and astronomy quietly divorced themselves from quackery, alchemy and astrology. New goals were set and the original objectives were kindly forgotten.

Were they? No, not really. Evidently, the academic community continues to suffer from a lingering sense of guilt that the original objectives have not been met, for as soon as a new promising branch of science and technology sprouts, all the unfulfilled hopes and expectations are transferred to it. Such is the well-established tradition and, as we are all well aware, now computing science finds itself saddled with the thankless task of curing all the ills of the world and more, and the net result is that we have to operate in an unjustified euphoria of tacit assumptions, the doubting of which is viewed as sacrilege precisely because the justification of the euphoria is so shaky. Let me cast a few doubts, be it at our own peril.

It's a pity he didn't live to hear Kurzweil talking about how the Singularity will make him immortal.

# ? Jul 4, 2012 09:16

Zombywuf: Mar 29, 2008

Suspicious Dish posted:

So it's not a fundamental problem with Ruby's object model, it's that one of GCC's optimizations makes the assumption that a program should not need to scan the stack and find valid results like that. You cannot compile such programs that do fancy (but completely valid) tricks with those optimizations.

It's a pretty fundamental problem with Ruby if it effectively requires your entire stack to be declared volatile in order for it not to read from freed memory. I have a dream that one day people will code in C realising that they're effectively working in an abstract VM where any resemblance to the machine it's running on is purely coincidental.

# ? Jul 4, 2012 11:29

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

that awful man posted:

Cool, but I think this is probably my favorite Dijkstra quote:

It's a pity he didn't live to hear Kurzweil talking about how the Singularity will make him immortal.

Ray Kurzweil is perhaps the most talented masturbator to have ever lived, show some respect!

# ? Jul 4, 2012 17:37

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Zombywuf posted:

It's a pretty fundamental problem with Ruby if it effectively requires your entire stack to be declared volatile in order for it not to read from freed memory.

Uh? It doesn't, that's the thing. The patch they submitted was a hack. The implementation of conservative stack scanning in Ruby's GC is incomplete.

That's still not a problem with Ruby's object model. It's a fixable bug.

# ? Jul 4, 2012 17:53

Zombywuf: Mar 29, 2008

Suspicious Dish posted:

Uh? It doesn't, that's the thing. The patch they submitted was a hack. The implementation of conservative stack scanning in Ruby's GC is incomplete.

That's still not a problem with Ruby's object model. It's a fixable bug.

Urgh, the real horror is trying to automagically garbage collect C.

# ? Jul 4, 2012 18:01

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Zombywuf posted:

Urgh, the real horror is trying to automagically garbage collect C.

It's not trying to do that? Conservative stack scanning is about convenience, so that you don't have to explicitly root/unroot objects you're using from the C API. I don't know the Ruby API, so I'll use Mozilla's JSAPI instead:

C++ code:

static JSObject *
repeat_string(JSContext *cx, JSObject *str, int count) {
    JSObject *accum = JS_GetEmptyString(cx);
    while (count-- > 0)
        accum = JS_ConcatStrings(cx, accum, str);
    return accum;
}

Without conservative stack scanning, creating a new object could call a GC. Since the temporary strings aren't referenced by any object, it would get collected. The alternative is an explicit root API, to let the GC know that it should not be collected. It would look like this:

C++ code:

static JSObject *
repeat_string(JSObject *str, int count) {
    JSObject *accum = JS_GetEmptyString(cx);
    /* assume that the str passed in is rooted and the
     * caller will unroot */

    while (count-- > 0) {
        JSObject *old_accum = accum;
        /* Make sure we don't wipe the string away */
        JS_AddObjectRoot(cx, &old_accum);
        accum = JS_ConcatStrings(cx, accum, str);
        /* Make the old object collectible again */
        JS_RemoveObjectRoot(cx, &old_accum);
    }
    /* caller should root object if it needs it */
    return accum;
}

That is, every object needs to be rooted whenever you could make a JS API call at all. Imagine all this rooting for very complex methods. You're bound to get it wrong.

It's not an insane thing like the Boehm GC.

# ? Jul 4, 2012 18:27

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 16:10

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

Boehm GC is insane now? The API is five functions and there's no add/remove root stuff like that. I guess I just don't know what you really mean.

# ? Jul 4, 2012 18:57

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »