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 »

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

Internally, the Boehm GC hack is extremely clever, but extremely awful. There's papers on the implementation details. It's everything C was not designed to do.

# ? Jul 4, 2012 19:10

Adbot: ADBOT LOVES YOU

# ? Apr 19, 2024 16:39

raminasi: Jan 25, 2005; a last drink with no ice

Suspicious Dish posted:

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.

Does the C standard promise a scannable stack? Serious question, I don't know much about this stuff.

# ? Jul 4, 2012 21:17

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.

It doesn't even promise a stack.

# ? Jul 4, 2012 21:29

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Suspicious Dish posted:

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:

[elided]

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.

So instead the alternative being chosen is ... rooting objects not by using any sane API or anything, but instead by making sure you have a pointer to them somewhere on the stack.

Honestly I don't see how that's any better. You still need to be explicit about rooting your objects, but instead of being testable you now have to worry about forgetting to root an object, having it work just fine on your machine, and then silently break in some later build.

# ? Jul 4, 2012 21:50

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Otto Skorzeny posted:

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

Yeah, but in our lifetimes we will have constructed machines that masturbate quantitatively and qualitatively better than any human could even imagine!

# ? Jul 4, 2012 22:07

Frozen Peach: Aug 25, 2004; garbage man from a garbage can

I found a rather hilarious coding horror today in our website's ordering process. For a few fields empty strings were being replaced by 0. This is particularly strange because I haven't made any changes to how the website places orders for a few months, and have never had a reason to touch the fields that were breaking.

When I did some digging, I found this line of code in each of the affected fields:

substr(trim($this->ShippingContact),0,25)

In this case, if trim() returned an empty string, then substr would be confused since there isn't a "0" position in an empty string. This makes substr return boolean false, which then gets passed into our database as if it were a bit field, making it 0.

Note that this is all in PHP, and once again this line of code hasn't changed for probably 2 years since we released this latest version. This bug, thanks to PHP being the horror that it is, should have been existent for the entire time. Why did it suddenly start breaking?

This weekend we changed how our database class works. We had a function that builds insert and update statements based on an array of values. Basically it just made it really easy to do prepared statements, and until a few months ago I never looked into that code. The person who wrote the function actually just made a loop create a concatenated SQL query, and wasn't actually using prepared statements! Since it was building queries from scratch, rather than preparing them like it should have been, it was also manually escaping quotes.

$field_data = str_replace("'", "''", $field_data);

Apparently substr() can't tell that an empty string should stay an empty string, but str_replace() can tell that boolean false should be an empty string after all the single quotes were removed from the... boolean false? :psyduck:

So a horror in PHP revealed a horror in our code, which then revealed even more horrors in PHP! It's a horrorception!

# ? Jul 5, 2012 16:47

Ari: Jun 18, 2002; Ask me about who Jewish girls should not marry!

Frozen-Solid posted:

In this case, if trim() returned an empty string, then substr would be confused since there isn't a "0" position in an empty string. This makes substr return boolean false, which then gets passed into our database as if it were a bit field, making it 0.

Why in the world would substr ever return anything that wasn't a string? This is a horror in itself.

# ? Jul 5, 2012 17:07

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Ari posted:

Why in the world would substr ever return anything that wasn't a string? This is a horror in itself.

Because the core of PHP was designed before exceptions were added, and because the PHP core devs think that adding exceptions to the core functions would break the world, core functions tend to return false or null when something goes awry.

It happens that substr returns false when you give it bogus arguments.

# ? Jul 5, 2012 17:33

Chopper: Feb 13, 2006

When using PHP it should be mandatory to check all functions returns against === false. Because of PHP's 'creative' tendencies with false,null,0 and empty string the only way to be sure is ===, == does not cut it.

# ? Jul 5, 2012 17:37

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

Sometimes the return value changes between versions for those error cases https://bugs.php.net/bug.php?id=50696

# ? Jul 5, 2012 18:45

qntm: Jun 17, 2009

McGlockenshire posted:

Because the core of PHP was designed before exceptions were added, and because the PHP core devs think that adding exceptions to the core functions would break the world, core functions tend to return false or null when something goes awry.

It happens that substr returns false when you give it bogus arguments.

...and str_replace() doesn't.

# ? Jul 5, 2012 18:46

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

qntm posted:

...and str_replace() doesn't.

code:

php > var_dump(str_replace("b", "a",False));
string(0) ""
php > var_dump(str_replace("b", "a",0));
string(1) "0"

# ? Jul 5, 2012 18:52

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Frozen-Solid posted:

In this case, if trim() returned an empty string, then substr would be confused since there isn't a "0" position in an empty string. This makes substr return boolean false, which then gets passed into our database as if it

Note that this is also a design flaw; pretty much every other substring operation in the world permits a substring to begin immediately after the last character. The basic bug here is that PHP's library design fears and loathes the empty string.

# ? Jul 5, 2012 19:07

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

I love how this thread always comes back to PHP.

# ? Jul 5, 2012 19:09

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

PHP is a great example of mediocrity at work... Some dude created his own templating system, some other dudes hack on it, wanna-be coders everywhere adopt it en-masse. Popularity used as proof that it's great.

For reference I saw all sorts of similar horrors from coders back when I was doing ASP classic/VBScript... Including a whole host of Byzantine logic and "fun" type coercion crap. The difference is that VBScript was designed as a language by people who knew what they were doing so it produces far fewer WTFs from the platform and language itself.

Did you love the mixing of logic and presentation in Classic ASP, but hate all that useless language design? PHP: Party like its 1998!

# ? Jul 5, 2012 23:43

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

Did you know that PHP has closures?

PHP code:

$foo = "a";
$bar = 1;
$baz = TRUE;

$func = function($a, $b) use ($foo, $bar) {
   echo $foo;
   echo $bar;
   echo $a;
   echo $b;
   echo $baz; /* ERROR, not in scope */
};

# ? Jul 5, 2012 23:52

Chopper: Feb 13, 2006

Suspicious Dish posted:

Did you know that PHP has closures?

PHP code:

$foo = "a";
$bar = 1;
$baz = TRUE;

$func = function($a, $b) use ($foo, $bar) {
   echo $foo;
   echo $bar;
   echo $a;
   echo $b;
   echo $baz; /* ERROR, not in scope */
};

But the error will only be a warning, and who looks at those in PHP? :catstare:

# ? Jul 6, 2012 00:02

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Suspicious Dish posted:

Did you know that PHP has closures?

PHP code:

$foo = "a";
$bar = 1;
$baz = TRUE;

$func = function($a, $b) use ($foo, $bar) {
   echo $foo;
   echo $bar;
   echo $a;
   echo $b;
   echo $baz; /* ERROR, not in scope */
};

There is no horror here. Functions always have isolated scope in PHP. The use clause when creating a closure expressly defines what specific parts of the outside scope are made available to the closure. You can even decide whether or not the scope binding is done at define time or at call time.

The "error" is a Notice, the same Notice you get whenever doing anything with an uninitialized variable, closure, function or otherwise.

# ? Jul 6, 2012 00:31

Johnny Cache Hit: Oct 17, 2011

Suspicious Dish posted:

Did you know that PHP has closures?

PHP code:

$foo = "a";
$bar = 1;
$baz = TRUE;

$func = function($a, $b) use ($foo, $bar) {
   echo $foo;
   echo $bar;
   echo $a;
   echo $b;
   echo $baz; /* ERROR, not in scope */
};

I wonder if PHP's closures are as useful and well written as its anonymous functions.

For reference, if you call create_function() PHP uses eval() to create a function called __lambda_func_. It's all the functionality of eval() with no advantages whatsoever. :toot:

# ? Jul 6, 2012 00:35

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

Kim Jong III posted:

I wonder if PHP's closures are as useful and well written as its anonymous functions.

For reference, if you call create_function() PHP uses eval() to create a function called __lambda_func_. It's all the functionality of eval() with no advantages whatsoever.

You shouldn't have to use create_function anymore since functions are first-class citizens in PHP now.

php:

<?
$func1 = create_function('$a,$b','return $a+$b;');
$func2 = function($a,$b) { return $a+$b; };

echo $func1(3,4) . "\n";
echo $func2(3,4) . "\n";
?>

# ? Jul 6, 2012 06:33

Comrade Gritty: Sep 19, 2011; This Machine Kills Fascists

Thermopyle posted:

I love how this thread always comes back to PHP.

Ender.uNF posted:

PHP is a great example of mediocrity at work... Some dude created his own templating system, some other dudes hack on it, wanna-be coders everywhere adopt it en-masse. Popularity used as proof that it's great.

For reference I saw all sorts of similar horrors from coders back when I was doing ASP classic/VBScript... Including a whole host of Byzantine logic and "fun" type coercion crap. The difference is that VBScript was designed as a language by people who knew what they were doing so it produces far fewer WTFs from the platform and language itself.

Did you love the mixing of logic and presentation in Classic ASP, but hate all that useless language design? PHP: Party like its 1998!

http://otherwise-than-code.blogspot.com.au/2012/07/complex-made-easy-or-debate-over-php.html

# ? Jul 6, 2012 08:17

Civil Twilight: Apr 2, 2011

Thermopyle posted:

I love how this thread always comes back to PHP.

Well, a lot of people use PHP, and many of those people use Git, so it's the best platform ever. :colbert:

# ? Jul 6, 2012 13:09

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

quote:

In fact, it evolves much faster than any other language or web platform.

I'm pretty sure this is objectively wrong, but I'm a Java programmer.

quote:

It took some time, but PHP 5.4 also comes with some nice syntactic sugar that makes the whole experience better than ever: yes, PHP supports [] to define arrays; yes, PHP supports calling a method on a newly created object ((new Foo())->bar());

what the gently caress, this is a feature? Isn't this 100% normal for any OO language? Why wasn't it available as soon as objects were?

# ? Jul 6, 2012 13:53

nielsm: Jun 1, 2009

Aleksei Vasiliev posted:

quote:
In fact, it evolves much faster than any other language or web platform.
I'm pretty sure this is objectively wrong, but I'm a Java programmer.

Doesn't this just mean "they're working overtime attempting to cover up all the terribleness while accidentally breaking things all the time"?

# ? Jul 6, 2012 14:10

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Seriously the only good thing about php is its ubiquitous deployment that "works enough" out of the box. Everything else it does is done better elsewhere. That whole anti-rant screams "this is the only tool I know and I will defend it to my death"

# ? Jul 6, 2012 14:41

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

Aleksei Vasiliev posted:

what the gently caress, this is a feature? Isn't this 100% normal for any OO language? Why wasn't it available as soon as objects were?

It was a parse error for a long time because no one involved in writing PHP's parser has any idea how to write a parser.

# ? Jul 6, 2012 14:44

Optimus Prime Ribs: Jul 25, 2007

Aleksei Vasiliev posted:

what the gently caress, this is a feature? Isn't this 100% normal for any OO language? Why wasn't it available as soon as objects were?

I love how pretty much the only good thing that can be said about PHP is when functionality is added that should have existed in the first place.

# ? Jul 6, 2012 16:26

ephphatha: Dec 18, 2009

Civil Twilight posted:

Well, a lot of people use PHP, and many of those people use Git, so it's the best platform ever.

When your defense of a language starts with "PHP is the most common serverside scripting language. PHP must have done something right, no?" it's not looking good.

quote:

Almost all major PHP libraries, frameworks, and products are now using Git, including PHP itself.

The PHP devel team now use a version control system! That's a plus for the language.

# ? Jul 6, 2012 16:57

Zhentar: Sep 28, 2003; Brilliant Master Genius

Steampunk Hitler posted:

http://otherwise-than-code.blogspot.com.au/2012/07/complex-made-easy-or-debate-over-php.html

quote:

Since Google often lies nearby so do the solutions to even your most obscure problems with PHP, and so PHP is easy.

I don't have any experience with PHP, but I do with another language with a similarly large and "skilled" userbase, VB6. This statement is not true. There may be solutions to even your most obscure problems, but you will never find them, because they are hidden amongst tens of thousands of posts by idiots who lack even the most basic understanding of programming or the language they are using, with responses floundering about with random guesses that rarely succeed at resolving the actual problem.

# ? Jul 6, 2012 17:16

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

php does have a problem, and that problem is w3schools

an awesome commenter posted:

Imperfection can be a great concept. Might sound stupid, but we as humans have learned to deal with imperfection pretty well. That's why we started to use tools. Fast forward to today, I think it still helps us to learn and to progress. Probably that's one part of what has been done right. There ain't no true problems as there ain't no true solutions. Sorry for getting a bit philosophical here. I really enjoy that the discussion is coming on a meta level at larger scale now, that feels like fresh air.

# ? Jul 6, 2012 17:23

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

That Google argument is pretty great since the vast majority of solutions you can easily find on Google to problems are flawed in some way, often a way that isn't immediately obvious.

Lowercasing a String in Java with toLowercase() can break your app if you rely on it to act like the String is English, not Turkish; reading/writing a text file without defining an encoding will only work fine if you're working solely in ASCII; various other things I can't remember off the top of my head but I know are rarely discussed in tutorials/answers and that will break stuff I've written under certain conditions if I hadn't known about them.
easy example of :ughh:

that I found in 15s:
Java Traps: Big Decimal

Selected excerpt posted:

double d1 = 2.2; System.out.println(new BigDecimal(d1)); >> 2.20000000000000017763568394002504646778106689453125

There are ways to avoid the problem.

Always use strings when instantiating BigDecimal

System.out.println(new BigDecimal("" + d1));

# ? Jul 6, 2012 17:29

dis astranagant: Dec 14, 2006

Is that still the case? That article's talking about an 8 year old version of Java.

# ? Jul 6, 2012 17:43

Zorro KingOfEngland: May 7, 2008

Aleksei Vasiliev posted:

various other things I can't remember off the top of my head but I know are rarely discussed in tutorials/answers and that will break stuff I've written under certain conditions if I hadn't known about them.
easy example of that I found in 15s:
Java Traps: Big Decimal

To be fair, that constructor quirk is at least noted in the javadocs: http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal(double).

# ? Jul 6, 2012 17:43

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

Zorro KingOfEngland posted:

To be fair, that constructor quirk is at least noted in the javadocs: http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal(double).

Right, due to how floating-point works. But the fix isn't to turn the double into a String; while that works in this case, due to built-in rounding when printing a floating-point value, it won't work for all values. The correct way is to write the value as a String in the first place, and pass that to the BigDecimal(String) constructor. He's recommending a hack that completely misses the issue.

(Also I only spent 15s reading his post, too, so I might have missed if he actually recommends a proper fix :v:

)

# ? Jul 6, 2012 17:49

dis astranagant: Dec 14, 2006

Ah, the elusive "not really a horror, just covers a use case you didn't think of".

# ? Jul 6, 2012 17:50

Zombywuf: Mar 29, 2008

Aleksei Vasiliev posted:

Lowercasing a String in Java with toLowercase() can break your app if you rely on it to act like the String is English, not Turkish; reading/writing a text file without defining an encoding will only work fine if you're working solely in ASCII; various other things I can't remember off the top of my head but I know are rarely discussed in tutorials/answers and that will break stuff I've written under certain conditions if I hadn't known about them.

Java has many problems, but the fact that most developers seem to not understand character encoding is not one of them.

# ? Jul 6, 2012 17:52

ToxicFrog: Apr 26, 2008

Zombywuf posted:

Java has many problems, but the fact that most developers seem to not understand character encoding is not one of them.

The point he's making is that "solutions to any of the problems you'll have are just a google away, so it's easy" is bullshit, because the solutions you'll find will be written by programmers who (for example) do not understand character encoding.

# ? Jul 6, 2012 17:55

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

Aleksei Vasiliev posted:

what the gently caress, this is a feature? Isn't this 100% normal for any OO language? Why wasn't it available as soon as objects were?

Same reason foo(1,2,3)[0] was a syntax error until recently. the grammar is a mess.

# ? Jul 6, 2012 18:41

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Steampunk Hitler posted:

http://otherwise-than-code.blogspot.com.au/2012/07/complex-made-easy-or-debate-over-php.html

quote:

The array in PHP does everything. Need an array in PHP? Use array. Need a map in PHP? Use array. Need a set in PHP? Use array. PHP arrays are the ultimate one-size-fits-all data structure. ...and so PHP is complex

Lua's table is a similar "one-size-fits-all data structure", and JavaScript's objects/arrays aren't far off. There's no inherent complexity here. PHP suffers from impossibly unintuitive interactions between library functions and its one true data structure.

# ? Jul 6, 2012 18:46

Adbot: ADBOT LOVES YOU

# ? Apr 19, 2024 16:39

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

Lua's tables are significantly more one-size-fits-all, since there outright aren't any other data structures (other than closures). However, Lua doesn't really suffer from the specific problem he's talking about. The problem is that there's a basic data structure which tries to do everything, but doesn't come close to doing everything since it isn't actually an object. In Lua, there's no temptation to implement a set with a table plus array_unique, since you can just override __newindex in the metatable for the same initial amount of effort and have a real set.

I do think he's overstated the degree to which it's a problem, though. PHP's arrays are pretty obviously the result of a bunch of features being crammed in rather than any sort of design, but the end result isn't all that bad.

# ? Jul 6, 2012 19:14

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 »