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!

«‹›1501 »

Xenogenesis: Nov 8, 2005

NotShadowStar posted:

Looks like another Java or PHP programmer doesn't understand Rails. I bet that was in a controller too.

Yep, definitely PHP and a bad PHP developer at that. Hello SQL injection.

nah thats in a model

And how does conditionally interpolating "LIMIT ?" into the query open this to SQL injection? Notice the actual value isn't interpolated. (It's building a string to be used with find_by_sql, the values are later added to the end of that array, but I assumed the "?"'s made that obvious)

Unfortunately though I'm the developer in question here :\ This query fetches from each user's top score (ordered by judgement) on a chart, the top n scores from each of a given set of charts. This monstrosity happened because I don't want to pull every score into the app just to filter them in Ruby. Can ActiveRecord actually help me here?

Xenogenesis fucked around with this message at 04:41 on Dec 8, 2010

# ? Dec 8, 2010 04:30

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 09:26

NotShadowStar: Sep 20, 2000

ActiveRecord 2 or 3?

# ? Dec 8, 2010 04:42

Xenogenesis: Nov 8, 2005

NotShadowStar posted:

ActiveRecord 2 or 3?

# ? Dec 8, 2010 04:54

Surface: May 5, 2007; <3 boomstick

# ? Dec 8, 2010 05:13

Bozart: Oct 28, 2006; Give me the finger.

Someone made this at work in response to the insane requests people made of him:
(redacted to protect the guilty)

Click here for the full 1284x1000 image.

# ? Dec 8, 2010 06:58

king_kilr: May 25, 2007

From a client's project: in the test suite there are lovely blocks like:

code:

def my_test(self):
    try:
        call_some_function()
    except:
        print "failed"

and other such idiotic poo poo. I want to loving kill this client.

# ? Dec 8, 2010 07:02

npe: Oct 15, 2004

Bozart posted:

Someone made this at work in response to the insane requests people made of him:
(redacted to protect the guilty)

Click here for the full 1284x1000 image.

I've also seen "Bug: Square Peg does not fit into Round Hole", which exists solely so that tickets can be closed as a duplicate of it....

# ? Dec 8, 2010 14:14

Zombywuf: Mar 29, 2008

We just have the status "Resolved (Muppet)"

# ? Dec 8, 2010 15:07

_aaron: Jul 24, 2007; The underscore is silent.

npe posted:

I've also seen "Bug: Square Peg does not fit into Round Hole", which exists solely so that tickets can be closed as a duplicate of it....

This rules. No way it would fly at my company, though

# ? Dec 8, 2010 15:21

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

ColdPie posted:

Hahahahahahahahahahahaha

Missing why this is funny except for a childish jab at IE, isn't IE9 supposed to be wicked fast, like way faster than Chrome/Firefox/Safari?

# ? Dec 8, 2010 17:24

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Orzo posted:

Missing why this is funny except for a childish jab at IE, isn't IE9 supposed to be wicked fast, like way faster than Chrome/Firefox/Safari?

No

Well, it's "supposed" to be, but actual benchmarks have shown it to be somewhere around Firefox 3.5. Still better than IE6, but nowhere near FF4 or whatever Chrome's at.

Interestingly, it might in reality be even slower; IE was caught cheating on Sunspider, by special-casing a few particular functions. Inserting things like "if (false) {}" into the code, or changing the order of variable assignment, can cause it to revert to previous (slow) performance.

# ? Dec 8, 2010 17:51

NotShadowStar: Sep 20, 2000

Xenogenesis posted:

2

Ergh.

It's certainly possible to get rid of that monstrosity, but it requires named scopes on associated models. You really should look into that, maintaining that thing is going to be your albatross.

quote:

Interestingly, it might in reality be even slower; IE was caught cheating on Sunspider, by special-casing a few particular functions. Inserting things like "if (false) {}" into the code, or changing the order of variable assignment, can cause it to revert to previous (slow) performance.

That's not entirely true. MS was optimizing Javascript like it was a static language. Some of the dynamic sunspider loops were instantly optimized away as dead unreachable code incorrectly. This would affect real world code as well.

# ? Dec 8, 2010 17:58

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Janin posted:

Interestingly, it might in reality be even slower; IE was caught cheating on Sunspider, by special-casing a few particular functions. Inserting things like "if (false) {}" into the code, or changing the order of variable assignment, can cause it to revert to previous (slow) performance.

I'm not an IE apologist by any means, but this issue is not as simple as 'they were caught cheating' and it's irresponsible to state that as if it were true.

# ? Dec 8, 2010 18:05

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

Orzo posted:

I'm not an IE apologist by any means, but this issue is not as simple as 'they were caught cheating' and it's irresponsible to state that as if it were true.

How about "specifically optimizing for SunSpider"?

Their dead-code analysis is in theory general-purpose, but is in practice A) incredibly fragile, and B) oddly works very well on SunSpider.

# ? Dec 8, 2010 18:09

Zombywuf: Mar 29, 2008

Aleksei Vasiliev posted:

How about "specifically optimizing for SunSpider"?

Their dead-code analysis is in theory general-purpose, but is in practice A) incredibly fragile, and B) oddly works very well on SunSpider.

Where fragile means adding nops in the dead code caused it to break.

# ? Dec 8, 2010 18:10

Vanadium: Jan 8, 2005

So it is dead-code analysis that gets broken by dead code?

# ? Dec 8, 2010 18:13

McGlockenshire: Dec 16, 2005; GOLLOCKS!

ErIog posted:

Do we know yet if that behavior is different in IE9? Microsoft seems like they understand that the old versions of IE were abominations with the decisions they've been making with IE9.

If IE9 ends up actually being on par with Chrome, Firefox, or Safari then PHP might be all we have left.

IE9 is indeed a relatively standards compliant, relatively decent, relatively fast browser. I still wouldn't use it for my daily browsing, but it's not going to be the shithole that previous versions were. The IE team seems to be taking things seriously now, and Browser Wars 2.0 is likely to be a win for everybody.

The problem is going to be what IE9 supports: Vista and 7. They aren't going to do a version for XP because it would involve backporting a lot of system libraries and technologies. This means that the latest version of IE available for XP is going to remain IE8.

As long as XP exists in the wild, we are going to need to support IE8. And 7, and 6. Microsoft will be patching XP through the spring of 2014. An unfortunate number of corporate users are going to be using XP even past that point, and who knows how long home users will stick with it.

We're probably going to be dealing with the fallout for the next five years, if not longer. That is the coding horror.

# ? Dec 8, 2010 18:15

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Vanadium posted:

So it is dead-code analysis that gets broken by dead code?

You make it sound like writing something to eliminate 'dead code' is trivial. It isn't. You have to be extremely careful when writing an optimization like that since it's so dramatic (removing entire blocks of code). Who knows what the internal implementation is? All we know is that adding some things makes it not work anymore, and even if they look like completely trivial additions, it's entirely plausible that the algorithm pessimistically gives up (as it should) rather than making the statement that Microsoft is cheating (poorly) on one of many, many browser tests.

Or maybe you were just making a humorous statement that wasn't meant to be taken seriously, either way I'm just trying to point out how absurd the argument against Microsoft here is.

# ? Dec 8, 2010 18:30

Zombywuf: Mar 29, 2008

Orzo posted:

Or maybe you were just making a humorous statement that wasn't meant to be taken seriously, either way I'm just trying to point out how absurd the argument against Microsoft here is.

I think you haven't actually read the analysis into this.

http://digitizor.com/2010/11/17/internet-explorer-9-caught-cheating-in-sunspider-benchmark/

http://news.ycombinator.com/item?id=1913315

The dead code analysis seems to be very very specific in this case.

# ? Dec 8, 2010 18:45

ErIog: Jul 11, 2001

Zombywuf posted:

I think you haven't actually read the analysis into this.

http://digitizor.com/2010/11/17/internet-explorer-9-caught-cheating-in-sunspider-benchmark/

http://news.ycombinator.com/item?id=1913315

The dead code analysis seems to be very very specific in this case.

I think you haven't actually read the analysis into this all the way.

http://arstechnica.com/microsoft/news/2010/11/lies-damned-lies-and-benchmarks-is-ie9-cheating-at-sunspider.ars

Some changes to the CORDIC code were noticed by the optimization while others weren't. It's not simply a case of Microsoft programming a cheat to one of many pieces of one of many synthetic browser benchmarks. The reason it's not uniform is because dead code analysis is really difficult to do, and so it is usually done extremely conservatively.

ErIog fucked around with this message at 19:00 on Dec 8, 2010

# ? Dec 8, 2010 18:57

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

Aleksei Vasiliev posted:

How about "specifically optimizing for SunSpider"?

Their dead-code analysis is in theory general-purpose, but is in practice A) incredibly fragile, and B) oddly works very well on SunSpider.

Because SunSpider is just dead code* and was probably a popular test case because of that. Even after breaking the dead code removal, it takes about twice as long as Chrome in the benchmarks I saw. Chrome being pretty loving fast, that's not really bad at all.

*If you look at the source, you'll notice it doesn't return anything at all or change anything in the global scope.

# ? Dec 8, 2010 19:07

Vanadium: Jan 8, 2005

Orzo posted:

You make it sound like writing something to eliminate 'dead code' is trivial. It isn't. You have to be extremely careful when writing an optimization like that since it's so dramatic (removing entire blocks of code). Who knows what the internal implementation is? All we know is that adding some things makes it not work anymore, and even if they look like completely trivial additions, it's entirely plausible that the algorithm pessimistically gives up (as it should) rather than making the statement that Microsoft is cheating (poorly) on one of many, many browser tests.

Or maybe you were just making a humorous statement that wasn't meant to be taken seriously, either way I'm just trying to point out how absurd the argument against Microsoft here is.

The examples I saw were adding lines like "if (false) {}" and "true;" in the middle or "return;" at the end. I understand the whole thing is not trivial but I am not sure I can figure out why you would be able to carefully deduce that this entire function is dead code, but some more pretty-obviously-dead code throws it off. What I took away from the hackernews discussion I had read earlier is that the consensus was that IE is pretty obviously just targetting this specific test with its optimisation, and it pretty much not applying to any other code, even code that is fundamentally similar.

I guess if that makes me misinformed, by all means take it as an attempt at a humorous observation of the post preceding mine.

# ? Dec 8, 2010 19:08

Zombywuf: Mar 29, 2008

ErIog posted:

Some changes to the CORDIC code were noticed by the optimization while others weren't. It's not simply a case of Microsoft programming a cheat to one of many pieces of one of many synthetic browser benchmarks. The reason it's not uniform is because dead code analysis is really difficult to do, and so it is usually done extremely conservatively.

It has almost certainly been fixed to the point where it works on exactly sunspider and left at that. As opposed to, you know, working generally. This isn't "cheating" exactly, which I never claimed, just pretty lovely. It's the same mechanism why windows starts to run slowly after you've used it for long enough to close a sales contract.

# ? Dec 8, 2010 19:14

king_kilr: May 25, 2007

Orzo posted:

You make it sound like writing something to eliminate 'dead code' is trivial. It isn't. You have to be extremely careful when writing an optimization like that since it's so dramatic (removing entire blocks of code). Who knows what the internal implementation is? All we know is that adding some things makes it not work anymore, and even if they look like completely trivial additions, it's entirely plausible that the algorithm pessimistically gives up (as it should) rather than making the statement that Microsoft is cheating (poorly) on one of many, many browser tests.

Or maybe you were just making a humorous statement that wasn't meant to be taken seriously, either way I'm just trying to point out how absurd the argument against Microsoft here is.

As someone who works on a JIT, this is a crock of poo poo. The "optimization" fails in such hilarious ways it's exceptionally clear (IMO) that they either a) wrote the optimization without any consideration for the semantics of javascript, or b) wrote it specifically for this test.

# ? Dec 8, 2010 19:19

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

ErIog posted:

I think you haven't actually read the analysis into this all the way.

http://arstechnica.com/microsoft/news/2010/11/lies-damned-lies-and-benchmarks-is-ie9-cheating-at-sunspider.ars

Some changes to the CORDIC code were noticed by the optimization while others weren't. It's not simply a case of Microsoft programming a cheat to one of many pieces of one of many synthetic browser benchmarks. The reason it's not uniform is because dead code analysis is really difficult to do, and so it is usually done extremely conservatively.

So your position is that Microsoft wrote an extremely fragile DCE algo, one that it so difficult to trigger that changing from "foo = 5; bar = 2;" to "bar = 2; foo = 5;" can break it, and by sheer coincidence the only thing it works on is a widely used benchmark suite?

# ? Dec 8, 2010 19:19

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

The argument in defense of Microsoft isn't that they're competent, merely that they're not necessarily being dishonest. Also, the whole thing is still in beta isn't it?

# ? Dec 8, 2010 19:32

Dr Monkeysee: Oct 11, 2002; just a fox like a hundred thousand others; Nap Ghost

Despite the sheer amount of pain and suffering IE has caused in my professional life I have to feel bad for the team itself. It can't be easy trying to turn the IE ship around and bring it up to par with modern browsers while still maintaining support for all the integrated shell stuff Trident is called on to do.

The problem is Firefox, Opera, Chrome, Safari, etc. are *just* browsers. IE is built on a rendering engine that does a lot more than just web browsing, and a lot of those decisions about what else it needs to do were made 10 years ago.

# ? Dec 8, 2010 19:43

Zhentar: Sep 28, 2003; Brilliant Master Genius

Zombywuf posted:

It has almost certainly been fixed to the point where it works on exactly sunspider and left at that.

This. I would bet that they evaluate the performance impact of development based on its impact on sunspider scores (I know Firefox does). Get it working to the point where it gets a big boost on a SunSpider test, awesome, good job everybody. Keep working on it past that, wasting development hours for a 0% performance impact? Not happening.

# ? Dec 8, 2010 19:54

ErIog: Jul 11, 2001

Janin posted:

So your position is that Microsoft wrote an extremely fragile DCE algo, one that it so difficult to trigger that changing from "foo = 5; bar = 2;" to "bar = 2; foo = 5;" can break it, and by sheer coincidence the only thing it works on is a widely used benchmark suite?

It's not the entire suite, though. It's a single test, CORDIC, that accounts for something like 0.5% of the overall score for most browsers. CORDIC is also written in such a way that it is conceivable for an optimization that is doing its job correctly to classify the entire test as dead code because it is, in fact, dead code.

Arstechnica Article posted:

That really isn't the case here; of course the optimization helps the overall score, but the scores of the top browsers are so similar (all in the 200-300 millisecond range) that they're just trading places without any meaningful difference between them. Even without the optimization, Internet Explorer 9 achieves a score within that range; it doesn't need, and isn't getting, a 179.art-style boost to its scores.

The way the scoring works means that even if the Internet Explorer team did feel it necessary to cheat, a single optimization wouldn't be the way to do it. It would take a whole raft of special-cased optimizations that applied across the range of tests, and we would expect to see consistent improvement.

But if we look at the actual results, (PP6, PP7) they look, well, realistic. PP7 is faster overall than PP6�to be expected, given PP7's billing as a performance-focused release�but not universally. There are a couple of performance regressions, which certainly give the results a veneer of plausibility. Compiler optimization is not an exact science, and a change that may be beneficial most of them time, and hence worth making, can result in worse performance some of the time.

I'm just not ready to get the pitchforks out to go after MS over what appears to be a mistake. It's also not like the IE9 preview build feels slow. It feels about as fast as the benchmarks would dictate. If you ran almost any beta build of any software through enough test suites, it seems like the chance is fairly high that one of the tests in one of those test suites would expose some sort of bug like this. There's a reason it's still in beta, and a bug like this is one of those reasons. This whole thing was a headline in search of a story.

Alert the press! Bug found in beta software!

ErIog fucked around with this message at 20:04 on Dec 8, 2010

# ? Dec 8, 2010 20:00

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Has somebody written some test benchmarks (not just altering the Sunspider one) to see exactly what the optimizer can and can't do?

# ? Dec 8, 2010 20:04

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

Orzo posted:

Has somebody written some test benchmarks (not just altering the Sunspider one) to see exactly what the optimizer can and can't do?

In the Ars article there's a link to a test someone wrote which IE9 optimizes away as dead code and it actually changes the result. The optimizer makes some incorrect assumptions about JS as a language, like immutability of system types - you can make the system array type have side effects when you get a value from it, for example.

So it's really fragile about what code it will apply optimizations to, but not fragile enough because it's still wrong in some corner cases.

# ? Dec 8, 2010 21:12

Kilson: Jan 16, 2003; I EAT LITTLE CHILDREN FOR BREAKFAST !!11!!1!!!!111!

Ryouga Inverse posted:

you can make the system array type have side effects when you get a value from it, for example.

Doing that would be the horror.

# ? Dec 8, 2010 23:55

Vanadium: Jan 8, 2005

If you are not cool with that kind of horror maybe you should not be using a dynamic language in the first place.

# ? Dec 8, 2010 23:58

MononcQc: May 29, 2007

Vanadium posted:

If you are not cool with that kind of horror maybe you should not be using a dynamic language in the first place.

It's more than dynamic languages, though. Javascript's prototype-based approach means everything can be modified.

Python or even PHP are dynamic, but you can't as easily subvert system types to do what you want with them. I'm not a python expert, but it's my understanding that you can only create new classes that imitate basic ones' behaviour and can adopt their syntax (as PHP does). On the other hand, I believe smalltalk and Ruby support that kind of monkey-patching that exists in Javascript.

# ? Dec 9, 2010 00:08

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

MononcQc posted:

It's more than dynamic languages, though. Javascript's prototype-based approach means everything can be modified.

Python or even PHP are dynamic, but you can't as easily subvert system types to do what you want with them. I'm not a python expert, but it's my understanding that you can only create new classes that imitate basic ones' behaviour and can adopt their syntax (as PHP does). On the other hand, I believe smalltalk and Ruby support that kind of monkey-patching that exists in Javascript.

It doesn't have dick all to do with prototype - prototype is simply the message dispatch system JS uses to do OOP-y things.

Different languages simply choose to lock down different things. Python actually locks down builtin types pretty hard, Ruby and JS don't. Neither Python nor JS are inherently more or less flexible. You could make a python with easily reopenable classes and mutable everything or a JS with locked down builtins and and the ability to freeze objects without too much trouble at all.

# ? Dec 9, 2010 02:10

MononcQc: May 29, 2007

Mr. Wynand posted:

It doesn't have dick all to do with prototype - prototype is simply the message dispatch system JS uses to do OOP-y things.

Different languages simply choose to lock down different things. Python actually locks down builtin types pretty hard, Ruby and JS don't. Neither Python nor JS are inherently more or less flexible. You could make a python with easily reopenable classes and mutable everything or a JS with locked down builtins and and the ability to freeze objects without too much trouble at all.

you're right. A single counter example I can think of could be ActionScript 2.0, which wouldn't let you override every kind of prototype out there.

# ? Dec 9, 2010 03:47

dizzywhip: Dec 23, 2005

This is from a dude in a freshman programming class I'm helping out, but it still cracks me up:

code:

        // Create a new product.
        public Product() {
                System.out.println("You didn't enter any information!!!!");
        }
 
        public Product(String name, double wholeprice, double retail,int stock) {
                this.name = name;
                this.wholeprice = wholeprice;
                this.retail = retail;
                this.stock = stock;
        }

# ? Dec 9, 2010 08:28

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Gordon Cole posted:

This is from a dude in a freshman programming class I'm helping out, but it still cracks me up:

We had something like

code:

class Waveform {
   public byte[] getData(double frequency, long length, int amplitude); 
}

class SineWave extends Waveform {
   public byte[] getData(double frequency, long length, int amplitude); 
}

class SquareWave extends Waveform {
   public byte[] getData(double frequency, long length, int amplitude); 
}

and one dude was tasked with creating random noise, so he made

code:

class RandomWave extends Waveform {
   public byte[] getData(long length, int amplitude); 
}

"because frequency is meaningless with a random signal"

But yeah, freshmen.

# ? Dec 9, 2010 12:05

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

Somewhere on the Internet, someone is trying to convince me that function inlining is bad, because it'd blow up the function and general executable size. And that's bad, because going from function to function is going to eat more CPU when they're all bigger and further apart. And oh, calling any function is just a simple jmp, nothing else. :psyduck:

It'd make sense if the functions with all the inlines would (almost) exceed the size of the instruction cache, OK, but then the whole applications design's would be broken beyond belief to begin with.

I'm currently writing a polyphonic analog synth on the sidelines in C# for WinPho7. Right now I'm trying to find a way to keep some sort of modularity to keep things maintainable and readable, while maximizing performance. Call overhead is killing the app in that case. And since we don't have macros or forceful inlining, that sucks.

I was initially asking for C++/CLI project reference support in the WP7 SDK (macros!), when this guy showed up.

# ? Dec 9, 2010 15:19

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 09:26

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

I gave half a talk on php last night to a local techie startup group - the first half was a php apologist - my talk wasn't so flattering: 'php: a great way to write cgi scripts' and 'we don't write cgi-scripts any more'

anyway Otto came up with this slide and I figured I'd post it here :3:

# ? Dec 9, 2010 16:15

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!

«‹›1501 »