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 »

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

code:

ubuntu@domU-:~$ php
<? echo "100{1}" == 100; echo "\n"; ?>
1
ubuntu@domU-:~$ php
<? echo "100 1" == 100; echo "\n"; ?>
1

FUUUUUUUUUUUUUUUUUUUUUUUUUUUCK PHP

# ? Sep 25, 2010 18:26

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 04:05

b0lt: Apr 29, 2005

TRex EaterofCars posted:

code:

ubuntu@domU-:~$ php
<? echo "100{1}" == 100; echo "\n"; ?>
1
ubuntu@domU-:~$ php
<? echo "100 1" == 100; echo "\n"; ?>
1

FUUUUUUUUUUUUUUUUUUUUUUUUUUUCK PHP

code:

<?php
$x = 'foo';
$y = 0;
if ($x == true && $y == false && $x == $y) {
   echo "what";
}
?>

Equality isn't transitive in PHP :downs:

edit: or for that matter, symmetric

# ? Sep 25, 2010 18:42

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

b0lt posted:

code:
<?php
$x = 'foo';
$y = 0;
if ($x == true && $y == false && $x == $y) {
   echo "what";
}
?>
Equality isn't transitive in PHP

edit: or for that matter, symmetric

I think in this case it's not about the properties of == as much as a matter of php taking liberties with what a number is when its native form is a string. Once it encounters a non-digit character, instead of saying "welp this isn't a number, not equal" it apparently says "welp, ran into non-number, the rest of this string doesn't matter".

# ? Sep 25, 2010 19:46

NotShadowStar: Sep 20, 2000

TRex EaterofCars posted:

code:

ubuntu@domU-:~$ php
<? echo "100{1}" == 100; echo "\n"; ?>
1
ubuntu@domU-:~$ php
<? echo "100 1" == 100; echo "\n"; ?>
1

FUUUUUUUUUUUUUUUUUUUUUUUUUUUCK PHP

Perl does exactly the same thing. This is the weird poo poo that happens when you don't discern integers and strings.

# ? Sep 25, 2010 20:51

McGlockenshire: Dec 16, 2005; GOLLOCKS!

NotShadowStar posted:

Perl does exactly the same thing. This is the weird poo poo that happens when you don't discern integers and strings.

Or you don't know the conversio rules...

# ? Sep 25, 2010 21:15

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

NotShadowStar posted:

Perl does exactly the same thing. This is the weird poo poo that happens when you don't discern integers and strings.

Yeah, basically automatic coercion of strings to numbers in numeric context, following the stupid rules of atoi(3) or whatever is an annoying language wart. If you gently caress around hard enough with ex::override you could probably 'fix' it yourself, but there be dragons there.

# ? Sep 25, 2010 21:23

NotShadowStar: Sep 20, 2000

McGlockenshire posted:

Or you don't know the conversio rules...

I shouldn't have to because "100buttsfart" == 100 makes no intuitive logical sense. Ever.

# ? Sep 25, 2010 21:25

McGlockenshire: Dec 16, 2005; GOLLOCKS!

NotShadowStar posted:

I shouldn't have to because "100buttsfart" == 100 makes no intuitive logical sense. Ever.

Except that is how pretty much every language that can convert a string to an integer acts. You are basically writing (int)"100lolbutts" == 100. Write the same construct in Java or C#, you'll probably get the same result.

Garbage in, garbage out. If you want different behavior, ask for it expressly.

# ? Sep 25, 2010 23:18

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

code:

System.out.println(Integer.parseInt("100buttsfart") == 100))

my JVM posted:

java.lang.NumberFormatException: For input string: "100buttsfart"

...which makes a hell of a lot more sense than an implicit conversion, frankly.

Internet Janitor fucked around with this message at 00:11 on Sep 26, 2010

# ? Sep 26, 2010 00:08

OddObserver: Apr 3, 2009

McGlockenshire posted:

Garbage in, garbage out. If you want different behavior, ask for it expressly.

I am pretty sure it's normally a good design practice for the sensible behavior to be default.

Ruby, BTW, just largely keeps the types separate, and only converts if you ask (though it does ignore trailing stuff):

code:

irb(main):001:0> 0 == false
=> false
irb(main):002:0> 1 == true
=> false
irb(main):003:0> "0" == 0
=> false
irb(main):004:0> "1" == 1
=> false
irb(main):005:0> "0".to_i == 0
=> true
irb(main):006:0> "0boo".to_i == 0
=> true

# ? Sep 26, 2010 00:28

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

OddObserver posted:

I am pretty sure it's normally a good design practice for the sensible behavior to be default.

Perl is designed so that common tasks can be achieved really easily, even if it results in unintuitive behaviour when taken out of context.

So in this case, instead of being erroring out when you compare a string to a number, it converts the string to a number and then compares them. If you want a string-based comparison, convert the number to a string and then compare.

Perl also assumes that the programmer knows what they're doing - if you convert a string that is only partially numeric to a number, it converts the numeric part and ignores the rest. If you want to do something different if the string is not just a number, explicitly test for that.

# ? Sep 26, 2010 00:45

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

Jabor posted:

Perl is designed so that common tasks can be achieved really easily, even if it results in unintuitive behaviour when taken out of context.

So in this case, instead of being erroring out when you compare a string to a number, it converts the string to a number and then compares them. If you want a string-based comparison, convert the number to a string and then compare.

Perl also assumes that the programmer knows what they're doing - if you convert a string that is only partially numeric to a number, it converts the numeric part and ignores the rest. If you want to do something different if the string is not just a number, explicitly test for that.

I think it's more that Perl wants to DWIM when you do something like print if $_ == 4 where the value of $_ is the string "4". Often Perl is helpful by trying to DWIM, but in this case the situation is just too hairy and the eager coercion causes more problems than it solves.

# ? Sep 26, 2010 00:53

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

Jabor posted:

Perl is designed so that common tasks can be achieved really easily, even if it results in unintuitive behaviour when taken out of context.

So in this case, instead of being erroring out when you compare a string to a number, it converts the string to a number and then compares them. If you want a string-based comparison, convert the number to a string and then compare.

Perl requires the programmer to explicitly specify if they want numeric comparison or string comparison for each and every comparison. It never decides based on the values that happen to be being compared, and the programmer can always look at any given comparison and say if it will involve coercing the values to numbers.

Jabor posted:

Perl also assumes that the programmer knows what they're doing - if you convert a string that is only partially numeric to a number, it converts the numeric part and ignores the rest. If you want to do something different if the string is not just a number, explicitly test for that.

When Perl converts a string to a number, if the conversion discarded some of the string (execpt in a small number of very specific cases) it will throw a warnings, rather than proceeding silently.

What PHP is doing is very nearly completely indefensible. If you have a comparison of two variables in PHP, it is very difficult (if not impossible) for the programmer to look at that comparison and decide which of the byzantine comparison rules will be used, as it is heavily dependent on the internal representation of both of the values involved. Because equality in PHP is non-transitive, this is potentially a correctness-altering property, and it's incredibly weird that there is action at a distance here.

# ? Sep 26, 2010 01:46

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

ShoulderDaemon posted:

Perl requires the programmer to explicitly specify if they want numeric comparison or string comparison for each and every comparison.

Exactly. Perl does not have the ==/=== semantics but eq/==. Also, perl ignores leading 0s, PHP treats them as octal.

quote:

When Perl converts a string to a number, if the conversion discarded some of the string (execpt in a small number of very specific cases) it will throw a warnings, rather than proceeding silently.

Notably "0 but true" passes without warning.

quote:

What PHP is doing is very nearly completely indefensible.

PHP is uniformly terrible, etc etc etc. The little templating language that could.

# ? Sep 26, 2010 02:29

Opinion Haver: Apr 9, 2007

tef posted:

Exactly. Perl does not have the ==/=== semantics but eq/==. Also, perl ignores leading 0s, PHP treats them as octal.

$ perl -e 'print 010, "\n", "010"'
8
010

# ? Sep 26, 2010 02:33

Vanadium: Jan 8, 2005

I am trying to decide whether perl or php's behaviour annoys me more than having to explicitly convert integers when I want to multiple them with doubles in haskell, help me out here.

# ? Sep 26, 2010 02:40

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

Vanadium posted:

I am trying to decide whether perl or php's behaviour annoys me more than having to explicitly convert integers when I want to multiple them with doubles in haskell, help me out here.

Haskell's number types are always the worst design decision. Always.

# ? Sep 26, 2010 02:56

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

Every new release of php is a drumbeat of failure and terrors, akin to dumping toxic waste on chernobyl.

http://phpxmlrpc.sourceforge.net/#security early and naive implementations of xml parsers in php used eval, and as such were terribly insecure and hacked en masse

http://php.net/manual/en/security.magicquotes.php -- man, if only we wrapped string on a ini file setting, it wouldn't prevent injection attacks at all, really all it means is that the standard library isn't portable any more as the semantics and return values can change on a site basis.

http://php.net/manual/en/security.globals.php 'you know what would be good if we could trash variables from the browser' 'we've turned it off now, good thing that people won't turn it back on for older scripts, and it will affect every script'

http://php.net/manual/en/language.oop5.late-static-bindings.php - broken oo implementation? sure, we'll just make the keyword for dynamic dispatch 'static'

http://php.net/manual/en/language.namespaces.php - the namespace character is the string escape character. I mean that will never backfire if people don't use 'variable functions', or using a string to lookup a function http://us.php.net/manual/en/functions.variable-functions.php

http://php.net/manual/en/control-structures.goto.php - or, if you like: named breaks do the same thing without the crazy.

http://use.perl.org/~Aristotle/journal/33448 - how do we fix a security vulnerability? why checking to see if an int is bigger than INT_MAX

https://www.trl.ibm.com/people/mich/pub/200901_popl2009phpsem.pdf - the implementation and semantics of php don't match up

http://en.wikipedia.org/wiki/PHP_accelerator - php by default doesn't cache bytecode, unlike, nearly everything ever, for commercial reasons, as zend sell one as a product.

http://www.phpcompiler.org/doc/phc-0.2.0.3/representingphp.html#CONCRETETREE - the grammar is terribly broken, so much so it is nearly impossible to do obvious and useful things like foo(1,2,3)[0]

http://blog.php-security.org/archives/61-Retired-from-securityphp.net.html the development team is toxic and reluctant to provide actual solutions for security

there are many php builtins which have vague return values which change indeterminately between releases and arguments, or several competing implementations often under a different naming scheme.

I don't care that you can beat a worthwhile database skin out of it, it is a terrible language. the syntax and grammar are atrocious, the library is inconsistent, and the implementation is crippled for commercial reasons, and maintained by idiots.

it's not that you can't go around writing trivial application code in your glorified cms, php is less terrible at that for sure. it is just that it is much, much more terrible at anything else. secure, hardened safe code becomes verbose and boilerplate, wrapping the standard library and patching the default install to get a fast, portable implementation is backwards, and any sort of large scale programming is doomed to large balls of mud after working around some of the crazier semantics.

and it is only getting worse

:sperg:

tef fucked around with this message at 03:11 on Sep 26, 2010

# ? Sep 26, 2010 03:06

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

yaoi prophet posted:

$ perl -e 'print 010, "\n", "010"'
8
010

It ignores leading zeros in strings, not in number literals

code:

$ perl -e 'print 010 + 1,"\n",(1+"010"),"\n"'
9
11

Or amusingly on increment: it preserves leading zeros

code:

perl -e '$a="000";print (++$a);'
001

# ? Sep 26, 2010 03:10

Opinion Haver: Apr 9, 2007

tef posted:

Or amusingly on increment: it preserves leading zeros
code:
perl -e '$a="000";print (++$a);'
001

That's because you can autoincrement (but not autodecrement!) strings:

code:

$ perl -e '$x = "abc"; print ++$x'
abd

# ? Sep 26, 2010 03:14

Zhentar: Sep 28, 2003; Brilliant Master Genius

McGlockenshire posted:

Except that is how pretty much every language that can convert a string to an integer acts.

MUMPS handles it in a reliable, logical, intuitive manner.

code:

USER>w "100"=100                                                                 
1                                                                                
USER>w "100 "=100                                                                
0                                                                                
USER>w +"100 "=100                                                               
1

# ? Sep 26, 2010 03:15

shrughes: Oct 11, 2008; (call/cc call/cc)

ShoulderDaemon posted:

Haskell's number types are always the worst design decision. Always.

Lies. Haskell's numeric library is actually quite reasonable. If you recognize that designing a numeric library for extensibility is insane anyway.

# ? Sep 26, 2010 06:24

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

shrughes posted:

Lies. Haskell's numeric library is actually quite reasonable. If you recognize that designing a numeric library for extensibility is insane anyway.

Yeah, it's OK as long as you don't want to create your own number types, because then you don't have to care about the interrelationships between the Num, Fractional, Integral, Real, RealFrac, RealFloat, and Floating classes and the fact that many members were scattered about almost at random between them. It's just kind of sad that the Haskell designers went through all the work of creating an intricate class hierarchy, and it's not even easy to build what should be simple extensions to the numeric types like vectors, matrices, or numbers that carry units.

Personally, I'm hoping something like numeric-prelude makes it into some HaskellPrime.

# ? Sep 26, 2010 06:40

NotShadowStar: Sep 20, 2000

McGlockenshire posted:

Except that is how pretty much every language that can convert a string to an integer acts. You are basically writing (int)"100lolbutts" == 100. Write the same construct in Java or C#, you'll probably get the same result.

Garbage in, garbage out. If you want different behavior, ask for it expressly.

Erm, no. That's not at all how non-batshit languages work.

code:


[01:12][~]$ csharp
Mono C# Shell, type "help;" for help

Enter statements below.
csharp> int x = Convert.ToInt32("100lolbutts");
System.FormatException: Input string was not in the correct format

csharp> int x = (int)"100lolbutts";
{interactive}(2,1): error CS0030: Cannot convert type `string' to `int'
csharp> exit();

[01:17][~]$ python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> int("100lolbutts") == 100
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '100lolbutts'

I prefer Ruby but the way it handles string to integer conversions I've never been a fan of. It has roots in Perl and also pre 1.9 string slicing was completely batshit. If you sliced a single character it would return the ASCII code for that character, but if you sliced a range it gave you a substring of that slice. loving. Crazy. 1.9 is much better though.

code:

[01:20][~]$ rvm 1.8.7
[01:20][~]$ irb
ruby-1.8.7-p302 > "100lolbutts"[0]
 => 49 
ruby-1.8.7-p302 > "100lolbutts"[0..2]
 => "100"
ruby-1.8.7-p302 > exit
[01:22][~]$ rvm 1.9.2
ruby-1.9.2-p0 > "100lolbutts"[0]
 => "1"

e: actually no, Ruby et al have their conversion roots from Smalltalk's asNumber method and not Perl, which exceptions if the initial character wasn't a digit, otherwise it ran through the sequence until it hit the first non-digit character. Still, Ruby, IO and all that never do implicit conversion which is the loving devil. Implicit conversion is the only thing you can do when you smoke a gigantic pile of weed and go 'HEY MAN WHAT IF, LIKE, THINGS HAD NO TYPE' which seems like a great idea until you hit a wall of when you actually care about types.

code:

print 0x1 == "1";
print "\n";
print "0x1" == 1;
print "\n";
print "0x1" == 0x1;
print "\n";
print "0x1" == "1";

Yeah gently caress that.

NotShadowStar fucked around with this message at 07:59 on Sep 26, 2010

# ? Sep 26, 2010 07:34

shrughes: Oct 11, 2008; (call/cc call/cc)

ShoulderDaemon posted:

Yeah, it's OK as long as you don't want to create your own number types, because then you don't have to care about the interrelationships between the Num, Fractional, Integral, Real, RealFrac, RealFloat, and Floating classes and the fact that many members were scattered about almost at random between them. It's just kind of sad that the Haskell designers went through all the work of creating an intricate class hierarchy, and it's not even easy to build what should be simple extensions to the numeric types like vectors, matrices, or numbers that carry units.

Yeah, it is sad. The truth is that type classes are too constrictive and should be abolished :eng101:

# ? Sep 26, 2010 08:21

McGlockenshire: Dec 16, 2005; GOLLOCKS!

NotShadowStar posted:

Erm, no. That's not at all how non-batshit languages work.

I stand corrected.

But how do other languages parse strings that should be numbers, but might not be, while still making a best effort? There's still a 100 there, how do I get to it? Other than pulling out a regex and doing it manually, I mean.

Maybe it's years of abuse at the horrible hands of PHP, but I really don't see the nature of the offense here.

# ? Sep 27, 2010 05:34

baquerd: Jul 2, 2007; by FactsAreUseless

McGlockenshire posted:

Maybe it's years of abuse at the horrible hands of PHP, but I really don't see the nature of the offense here.

You're dropping data with no warning or logging. Something like that is definitely not good as a default for something as common as this.

# ? Sep 27, 2010 05:40

ToxicFrog: Apr 26, 2008

^ Typically you have some function for "convert this string to a number, and report failure in some way if the string cannot be parsed as a number". You might also have something like C's strtol() ("convert the leading portion of this string to a number, report both the resulting number (if any) and how much of the string is left afterwards").

In your case of "I have a string, there's a 100 in there somewhere, how do I get at" I see this as being either of the following:
- input was meant to be a number, is actually a string. Input is invalid and bitching about it is the correct approach.
- input is meant to be a string with a number in it somewhere. Use your favorite string processing tools (regexes, PEGs, parser combinators, etc) to extract the numeric portion from it and then feed that to the abovementioned function. (Or use your local strtol() equivalent, if you know the number is at the start.)

Note that even in the case of a best-effort numeric parser like strtol(), this is an explicit "I want the contents of this string interpreted as a number", not "hey let's silently and automatically convert this string here".

Coercion is the real horror.

# ? Sep 27, 2010 05:48

McGlockenshire: Dec 16, 2005; GOLLOCKS!

baquerd posted:

You're dropping data with no warning or logging.

ToxicFrog posted:

Coercion is the real horror.

These are very good points.

But... if my language of choice raised an exception when I passed it contaminated data rather than make a best effort to clean it up, I don't think I'd prefer that language for much longer.

Sometimes it's easiest to just say "gently caress you, you're an int" to a string and ignore the fallout, even if there is potentially a loss of data. I mean, hell, I force expected integer data to an int as input validation. If you put garbage into a field, you get a zero. If that field doesn't accept a zero, you get an error.

I hate what PHP has done to me. This feels ... unclean now.

# ? Sep 27, 2010 06:10

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

ToxicFrog posted:

Coercion is the real horror.

The more I think about this, the less I believe eager coercion is a bad idea per se, just badly done coercion. The behavior of recent perl, for instance, doesn't fill me with dread:

code:

mike@cheez-it:~$ perl -wE 'say 4 == "4" ? "yes" : "no"'
yes
mike@cheez-it:~$ perl -wE 'say 4 == "4butts" ? "yes" : "no"'
Argument "4butts" isn't numeric in numeric eq (==) at -e line 1.
yes
mike@cheez-it:~$ perl -wE 'say 4 == "3" ? "yes" : "no"'
no
mike@cheez-it:~$ perl -wE 'say 4 == "nan" ? "yes" : "no"'
no
mike@cheez-it:~$ perl -wE 'say 4 == "nancy" ? "yes" : "no"'
Argument "nancy" isn't numeric in numeric eq (==) at -e line 1.
no

# ? Sep 27, 2010 06:12

Shavnir: Apr 5, 2005; A MAN'S DREAM CAN NEVER DIE

McGlockenshire posted:

But... if my language of choice raised an exception when I passed it contaminated data rather than make a best effort to clean it up, I don't think I'd prefer that language for much longer.

Weren't you the one that said "Garbage in, garbage out"?

Then again I program in Ada so the idea of going from strings to ints is a horrifying concept anyways :v:

# ? Sep 27, 2010 06:15

baquerd: Jul 2, 2007; by FactsAreUseless

McGlockenshire posted:

I mean, hell, I force expected integer data to an int as input validation.

Enter a donation amount: 100iamacat

Valid input?

# ? Sep 27, 2010 06:21

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Shavnir posted:

Weren't you the one that said "Garbage in, garbage out"?

In PHP and Perl, "100 but not one hundred" can be turned into 100.

In PHP and Perl "Your face is on fire" has no sane numeric interpretation, you get nothing if you take it in numeric context.

It seems other languages would prefer that both of these are errors. I was operating under the assumption that when asked expressly to cast the string as an integer, they'd make the same best effort that PHP and Perl do. That assumption was wrong.

I would consider the string "100 but not one hundred" to be garbage, but I'd rather get the 100 out of it, or even a zero, than an exception.

e:

baquerd posted:

Enter a donation amount: 100iamacat

Valid input?

It depends on how strictly I deal with the field, and whether or not there's any client-side validation first. Let's assume there is, but the client is malicious and is also a cat, so "100iamacat" gets passed in. If I'm only allowing whole dollar amounts (no cents), I'm very likely to not bother with a regex and just cast it after trimming. Because I work with PHP and Perl, I'd get integer 100 out of that under these specific conditions, with no errors and a warning if it's Perl.

If I wasn't dealing with whole numbers, there'd probably be a regex there to either validate the format or remove anything other than [\d\.], which would also yield 100 in this scenario regardless of what language was used.

Now that I think about it, this is a bad example. If this was a public page instead of an internal page (where I can speak to my users face to face), I'd probably also end up with the nuke-everything-but-the-numbers regex. Public users tend to be stupid, I can easily see a "how much would you like to donate?" box getting dollar signs entered in it. Therefore, this specific case mandates a regex for any sort of sanity.

A simple quantity field might make a better example. Do you really want to order "100iamacat" items? Sure, I'll give you 100 of them and not complain about it.

I guess it all depends on how idiotic I expect the users to be and how smart I want to make the correction of their inevitable errors.

McGlockenshire fucked around with this message at 06:37 on Sep 27, 2010

# ? Sep 27, 2010 06:24

baquerd: Jul 2, 2007; by FactsAreUseless

McGlockenshire posted:

A simple quantity field might make a better example. Do you really want to order "100iamacat" items? Sure, I'll give you 100 of them and not complain about it.

I guess it all depends on how idiotic I expect the users to be and how smart I want to make the correction of their inevitable errors.

Let's pretend instead of a user entering this data, you're parsing from a file detailing financial transactions. Today there's a fun error in the supplied file, merging a numeric field and a string field accidentally.

Your data: "9638410 year treasury"

Do I need to point out the problem?

# ? Sep 27, 2010 06:40

McGlockenshire: Dec 16, 2005; GOLLOCKS!

baquerd posted:

Let's pretend instead of a user entering this data, you're parsing from a file detailing financial transactions. Today there's a fun error in the supplied file, merging a numeric field and a string field accidentally.

Your data: "9638410 year treasury"

Do I need to point out the problem?

Nope.

In fact, a similar situation happened to us two weeks ago. One of our vendors gave us a malformed data feed for a few days, and the nightly import log was 70 megs of Perl complaining about doing addition on a string (converting it to a number by adding zero). The difference was the number was now preceded by one letter and a tab. Under Perl's coercion rules, "X 1234" is zero. That import code was sloppy, and ended up "silently" zeroing their apparent sale price on 600k components because it blindly assumed the contents in that column would be correct and well-formed. This would have been a major problem for our purchasing folks, if we ever used this particular vendor.

(Related: Mister hardware vendor, xBase is neither a suitable nor sane data export format. This is one of many reasons we never buy anything from you.)

Look, all I'm saying is that sometimes, being "sloppy" can be acceptable if the result of the sloppyness isn't harmful in the worst case. If all I need is an int, and I don't care what the user typed after it, I'm gonna cast it and spend my time fixing other problems instead. I'd rather not have my programming language make that decision for me.

McGlockenshire fucked around with this message at 07:11 on Sep 27, 2010

# ? Sep 27, 2010 07:08

ToxicFrog: Apr 26, 2008

McGlockenshire posted:

These are very good points.

But... if my language of choice raised an exception when I passed it contaminated data rather than make a best effort to clean it up, I don't think I'd prefer that language for much longer.

Why should the language do this automatically, though? Yeah, it should include tools for doing this, but I'd prefer not to have it try to guess what I meant, especially when this can hide type mismatches that are genuine bugs rather than just unclean input.

Not to mention that even coercion doesn't save you from having to write error handling, unless "gently caress you not a number" coerces to 0 in a numeric context.

I guess if I had to sum up my point here, it's that cleaning up bad input is a highly program-dependent process and thus should be handled by the programmer; trying to add language features to do this means the language will guess wrong sometimes, and furthermore, complicates parts of the program that have nothing to do with cleaning up input but which trigger these features anyways.

Otto Skorzeny posted:

4 == "4"

See, I consider that "badly done coercion". (4 + "4" == 8) is acceptable, but 4 and "4" are different types, they should never compare equal unless you're doing an explicit conversion or redefining equality.

Edit:

McGlockenshire posted:

Look, all I'm saying is that sometimes, being "sloppy" can be acceptable if the result of the sloppyness isn't harmful in the worst case. If all I need is an int, and I don't care what the user typed after it, I'm gonna cast it and spend my time fixing other problems instead. I'd rather not have my programming language make that decision for me.

But with implicit coercion it is making that decision for you, and the decision is always "be sloppy". Without coercion, it's in your hands what it does - treat type mismatches as errors, convert strictly, or convert laxly (or do something else entirely I haven't thought of). And the fact that you're talking about casting it (which implies an explicit conversion) seems to indicate that you're thinking along similar lines.

If your language lacks coercion, you can still get the desired sloppiness by using strtol() or tonumber() or whatever on your input before making use of it. But if it has coercion and you don't want it to be sloppy, you're hosed - or at least, you need a lot more extensive manual type checking and error handling.

ToxicFrog fucked around with this message at 08:16 on Sep 27, 2010

# ? Sep 27, 2010 08:10

RankWeis: Jul 10, 2010

ToxicFrog posted:

See, I consider that "badly done coercion". (4 + "4" == 8) is acceptable, but 4 and "4" are different types, they should never compare equal unless you're doing an explicit conversion or redefining equality.

Well, I don't know about perl specifically, but in Python (I believe), and PHP (almost certainly) that

4 == "4"

would return True.

But there's also the identical operation,

4 === "4"

and that would return False.

It's a hassle from someone coming from a more strict programming background, but it can make these things easier.

# ? Sep 27, 2010 08:53

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

I would like to say that I'd be standing behind ToxicFrog and going "yeah", British Parliament-style.

# ? Sep 27, 2010 08:55

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

ToxicFrog posted:

See, I consider that "badly done coercion". (4 + "4" == 8) is acceptable, but 4 and "4" are different types, they should never compare equal unless you're doing an explicit conversion or redefining equality.

There's a semantic spat to be had here about whether scalar variables in Perl have types and whether perl's concept of SV's and PV's constitute datatypes, but I'll instead say that you probably also have a bone to pick with ANSI C's handling of equality between ints and floats:

code:

#include <stdio.h>

int main(void) {
    puts((4 == 4.) ? "yes" : "no");
    return 0;
}

/* output: yes */

# ? Sep 27, 2010 09:06

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 04:05

ctz: Feb 6, 2003

RankWeis posted:

Well, I don't know about perl specifically, but in Python (I believe), and PHP (almost certainly) that

4 == "4"

would return True.

But there's also the identical operation,

4 === "4"

and that would return False.

It's a hassle from someone coming from a more strict programming background, but it can make these things easier.

code:

>>> 4 == "4"
False
>>> 4 === "4"
  File "<stdin>", line 1
    4 === "4"
        ^
SyntaxError: invalid syntax

You have some strange beliefs.

# ? Sep 27, 2010 09:33

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 »