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 »

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

Bognar posted:

Try this?
code:
get = chrome.storage.local.get.bind(chrome.storage.local); get()
If that works, then this is not really a Chrome bug, it's just how JavaScript is. Functions aren't bound to objects by default. Maybe Chrome should expose a more resilient API, but that's a different argument.

Yeah I woke up this morning and looked at where it was being called, I couldn't actually trace back where functionSchemas was being declared but it was being called as `this.functionSchemas[blah]`

Debugging Chrome Extensions is hard enough but it was just frustrating running into that first bug, which required me to close all my tabs, and then hitting this second bug right before I wanted to sleep. I'm pretty sure I know why this was put in (reuse code for local/sync/managed functions) so the way it was written I think is part of the same discussion (it's bad for this weird error to popup when a developer is trying to use your tools, let alone the obscure error message).

# ? Jan 14, 2016 02:23

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 04:00

taint toucher: Sep 23, 2004

Found this gem in production today:

code:

	const maxCharacters = get(field, 'attrs.maximumCharacters');
	if (maxCharacters) {
		if (!maxCharacters > value.length) {
			return {errorMessage: `The content exceeds the maximum number of characters (${maxCharacters}).`, isValid: false};
		}
	}

# ? Jan 14, 2016 21:28

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

That's a pretty good one.

# ? Jan 15, 2016 00:25

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Does ! bind more strongly than >? Is that the problem there?

# ? Jan 15, 2016 00:28

Sedro: Dec 31, 2008

TooMuchAbstraction posted:

Does ! bind more strongly than >? Is that the problem there?

Yeah, the block will never execute (assuming length is >= 0).

That's ember.js, right?

# ? Jan 15, 2016 00:37

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Strong Sauce posted:

Yeah I woke up this morning and looked at where it was being called, I couldn't actually trace back where functionSchemas was being declared but it was being called as `this.functionSchemas[blah]`

Debugging Chrome Extensions is hard enough but it was just frustrating running into that first bug, which required me to close all my tabs, and then hitting this second bug right before I wanted to sleep. I'm pretty sure I know why this was put in (reuse code for local/sync/managed functions) so the way it was written I think is part of the same discussion (it's bad for this weird error to popup when a developer is trying to use your tools, let alone the obscure error message).

javascript "this" is dynamically scoped and bound to the caller of the function so the error makes sense in an obtuse way

# ? Jan 15, 2016 00:55

taint toucher: Sep 23, 2004

TooMuchAbstraction posted:

Does ! bind more strongly than >? Is that the problem there?

Sedro posted:

Yeah, the block will never execute (assuming length is >= 0).

That's ember.js, right?

Yes and yes! And in this particular case that number will (famous last words) never anything but a non-zero, positive integer.

We are not really looking forward to migrating to ember.js 2.

# ? Jan 15, 2016 01:09

Sedro: Dec 31, 2008

Action Jackson! posted:

We are not really looking forward to migrating to ember.js 2.

I just upgraded ours to version 2 last week. I like ember but the 1.12->2.0 transition was not cool.

# ? Jan 15, 2016 01:25

taint toucher: Sep 23, 2004

Sedro posted:

I just upgraded ours to version 2 last week. I like ember but the 1.12->2.0 transition was not cool.

We have a major release coming in like a month so we are going to have to wait a bit until that dies down. So much to do and our feature freeze starts next Friday.

# ? Jan 15, 2016 01:27

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

What's with those backticks?

# ? Jan 15, 2016 03:22

taint toucher: Sep 23, 2004

Suspicious Dish posted:

What's with those backticks?

Backticks are used for ES6's template strings.

# ? Jan 15, 2016 03:31

KernelSlanders: May 27, 2013; Rogue operating systems on occasion spread lies and rumors about me.

Subjunctive posted:

No it's not. String literals always have the same type.

Except when used in a context that expects a boolean.

# ? Jan 15, 2016 08:04

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

Oh hey, C++ is broken too!

C++ code:

if (2) {
    printf("WTF!\n");
}

if (2 == true) {
    printf("Jesus, what a bad language!\n");
}

And Python!

Python code:

if "what the heck!":
    print "what was Guido thinking!!!"

if "what the heck!" == True:
    print "hamburger"

# ? Jan 15, 2016 08:20

Bongo Bill: Jan 17, 2012

Using non-boolean values in boolean contexts should be avoided because the results are often surprising.

# ? Jan 15, 2016 08:40

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

KernelSlanders posted:

Except when used in a context that expects a boolean.

No, string literals have one type and one type only. Performing different operations with a string as an operand can involve converting that string to another type as one of the steps, but it's the temporary that has a different type. 0 always has the type "number", similarly, though different operations can convert a number to string, boolean, or object.

Consider: what type does the literal "horse" have in these two cases?

code:


if ("horse") {
  gallop();
}

code:


var h = "horse";

// many lines of code go here

if (h) {
  gallop();
}

# ? Jan 15, 2016 08:59

Linear Zoetrope: Nov 28, 2011; A hero must cook

Strictly, yes, there's an implicit, anonymous function from string -> boolean being invoked in these cases. But in practice it makes the semantics of the language's typing feel capricious and arbitrary. (This goes for C too, but C somewhat has the various excuses "we hadn't learned yet" and "is just slightly more portable assembly")

# ? Jan 15, 2016 09:03

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

I agree, there are too many implicit type coercions, and some of them are more confusing than useful. (Witness the confusion in this thread already.) The "truthy"/"falsy" conversions are an artifact of its time, and more so its C heritage.

E: C doesn't really have much of a "we didn't know better" excuse, given that Algol itself lacked coercion between integers and booleans, though.

Subjunctive fucked around with this message at 11:21 on Jan 15, 2016

# ? Jan 15, 2016 10:58

SupSuper: Apr 8, 2009; At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

C technically doesn't have booleans though, so it's less "coercion" and more "everything's a integer".

# ? Jan 15, 2016 11:57

Space Kablooey: May 6, 2009

Suspicious Dish posted:

And Python!

Python code:

if "what the heck!":
    print "what was Guido thinking!!!"

if "what the heck!" == True:
    print "hamburger"

I can't test the C++ code, but what's wrong with those? Or do you just dislike the whole "falsey" or "truthy" thing?

# ? Jan 15, 2016 14:41

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

SupSuper posted:

C technically doesn't have booleans though, so it's less "coercion" and more "everything's a integer".

C99 has _Bool, which is a constrained integer -- casting a value to _Bool will always produce 0 or 1, which is not the case for casting to a general purpose integer. C and C++ also test truthiness of pointers differently from integers, since NULL may be a non-zero bit pattern on some architectures.

# ? Jan 15, 2016 15:51

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

HardDisk posted:

I can't test the C++ code, but what's wrong with those? Or do you just dislike the whole "falsey" or "truthy" thing?

This guy was saying JS was broken for having this feature — they expected truthiness and comparisons to true to match, for some reason. I was sarcastically pointing it out that it also happens in Good Plang, Python.

KernelSlanders posted:

Somehow that's both typed and untyped at the same time.

# ? Jan 15, 2016 16:54

M31: Jun 12, 2012

I really hate Groovy:

code:

class A {}

class B extends A {}

A getA() { new B() }

B getB() { getA() }

println getB() // prints B

Very efficient type system: just ignore all of it. (It does check at runtime)

# ? Jan 15, 2016 17:33

eth0.n: Jun 1, 2012

M31 posted:

I really hate Groovy:
code:
...
Very efficient type system: just ignore all of it. (It does check at runtime)

Isn't that basically the same as Java? Just with an implicit run-time-checked downcast in getB? As scripting languages go, that seems rather mild.

# ? Jan 15, 2016 17:55

brap: Aug 23, 2004; Grimey Drawer

JavaScript's handling of truthiness is really interesting because the || and && operators actually return the arguments of whatever type you happen to have provided. That's why people can use || like

code:

var thing = maybeNull || defaultValue;

JS will return the first truthy argument it finds from left to right.

Honestly I use truthiness in my JS code...sue me. It's often enough that I want to know that a string is not null and also not empty. Since I write TypeScript, I at least know the goddamn thing is a string.

# ? Jan 15, 2016 18:14

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Interpretation of values as booleans is something that lots of languages do subtly differently, and you just have to learn whatever idiom your language uses and adapt to it. I don't think you start getting into objectively wrong territory until you have stuff like "0 apples" evaluating to false because the language helpfully converts to a number for you and then interprets that number as a boolean.

# ? Jan 15, 2016 18:21

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

TooMuchAbstraction posted:

Interpretation of values as booleans is something that lots of languages do subtly differently, and you just have to learn whatever idiom your language uses and adapt to it. I don't think you start getting into objectively wrong territory until you have stuff like "0 apples" evaluating to false because the language helpfully converts to a number for you and then interprets that number as a boolean.

"0 but true"

# ? Jan 15, 2016 18:28

Zaxxon: Feb 14, 2004; Wir Tanzen Mekanik

fleshweasel posted:

JavaScript's handling of truthiness is really interesting because the || and && operators actually return the arguments of whatever type you happen to have provided. That's why people can use || like
code:
var thing = maybeNull || defaultValue;
JS will return the first truthy argument it finds from left to right.

Honestly I use truthiness in my JS code...sue me. It's often enough that I want to know that a string is not null and also not empty. Since I write TypeScript, I at least know the goddamn thing is a string.

that's pretty common in dynamically typed languages. Ruby, Python (2.7 at least) and lua all do the same thing.

edit: by "the same thing" I mean the binary operators returning the values they were supplied with instead of coercing things to bools. Not having bizzare "truthy/falsy" rules.

Zaxxon fucked around with this message at 19:10 on Jan 15, 2016

# ? Jan 15, 2016 19:08

Linear Zoetrope: Nov 28, 2011; A hero must cook

TooMuchAbstraction posted:

Interpretation of values as booleans is something that lots of languages do subtly differently, and you just have to learn whatever idiom your language uses and adapt to it. I don't think you start getting into objectively wrong territory until you have stuff like "0 apples" evaluating to false because the language helpfully converts to a number for you and then interprets that number as a boolean.

The only more arbitrary thing is "which magic word means 'quit' in this language's REPL?"

# ? Jan 15, 2016 19:11

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Zaxxon posted:

that's pretty common in dynamically typed languages. Ruby, Python (2.7 at least) and lua all do the same thing.

edit: by "the same thing" I mean the binary operators returning the values they were supplied with instead of coercing things to bools. Not having bizzare "truthy/falsy" rules.

And sh before them all:

code:

$ (exit 1) && (exit 2); echo $?
1
$ (exit 0) && (exit 2); echo $?
2
$ (exit 1) || (exit 2); echo $?
2
$ (exit 2) || (exit 1); echo $?
1

# ? Jan 15, 2016 19:12

Soricidus: Oct 21, 2010; freedom-hating statist shill

Jsor posted:

The only more arbitrary thing is "which magic word means 'quit' in this language's REPL?"

Control-D or GTFO

# ? Jan 15, 2016 19:37

xzzy: Mar 5, 2009

gently caress shells that have an ignoreeof option, and gently caress systems that enable it by default.

# ? Jan 15, 2016 19:55

Fergus Mac Roich: Nov 5, 2008; Soiled Meat

M31 posted:

I really hate Groovy:
code:
class A {}

class B extends A {}

A getA() { new B() }

B getB() { getA() }

println getB() // prints B
Very efficient type system: just ignore all of it. (It does check at runtime)

I don't understand what it should be doing instead.

# ? Jan 15, 2016 20:35

Carbon dioxide: Oct 9, 2012

So, I had my first encounter with Groovy scripts today, and saw something like this:

code:

String[] strarray = [];
for (Object obj : objlist.getObject()) {
  strarray += obj.getString();
}

Is... that even legal? That's no way to fill an array.

# ? Jan 15, 2016 20:36

eth0.n: Jun 1, 2012

Carbon dioxide posted:

So, I had my first encounter with Groovy scripts today, and saw something like this:
code:
String[] strarray = [];
for (Object obj : objlist.getObject()) {
  strarray += obj.getString();
}
Is... that even legal? That's no way to fill an array.

The += operator evidently appends items to arrays. I've never used Groovy, and that doesn't seem all that strange to me.

# ? Jan 15, 2016 20:45

HFX: Nov 29, 2004

Fergus Mac Roich posted:

I don't understand what it should be doing instead.

Theoretically, the type got widened to A when the new B instance was returned from getA(). Therefore it should not be compatible with B returned since it widened. That said, the compiler can probably reasonably determine that the A returned by getA() is actually a B with the information given and do an implicit corrosion back to B. Or it could ignore it, and wait for the runtime cast to B to make sure it is really a B object.

Either way is probably more type checking then the average scripting language supports.

# ? Jan 15, 2016 20:56

qntm: Jun 17, 2009

Groovy is pretty horrible. It's a superset of Java with piles and piles of "helpful" idioms added on top so you're never quite sure what's legal or what any given line of code does, or whether any bareword is a function or a class name or a variable or a type or what. Also you can leave all kinds of things implicit, leading to code which is just incoherent, like

code:

take coffee with sugar, milk and liquor

# ? Jan 15, 2016 20:59

Steve French: Sep 8, 2003

Fergus Mac Roich posted:

I don't understand what it should be doing instead.

I don't know Groovy, or really anything about it, so I'm just guessing at the syntax and type system and could be wrong. But this is what happens (and what I'd expect to happen) with what I *think* is the equivalent code in Scala:

code:


scala> class A
defined class A

scala> class B extends A
defined class B

scala> def getA: A = { new B }
getA: A

scala> def getB: B = { getA }
<console>:13: error: type mismatch;
 found   : A
 required: B
       def getB: B = { getA }

# ? Jan 15, 2016 21:00

vOv: Feb 8, 2014

The dumbest implicit boolean conversion I ever saw was some Python HTML library that treats a node with no children as falsy.

# ? Jan 15, 2016 21:11

M31: Jun 12, 2012

Fergus Mac Roich posted:

I don't understand what it should be doing instead.

Give an error, I don't know. At least give a warning or something. Yes, the only difference between this and Java is essentially implicit versus explicit casting.

code:

class A {}

class B extends A {
    def foo() {
        println 'foo';
    }
}

A a = new B();
a.foo(); // print foo

a = new A();
a.foo(); // throws MissingMethodException at runtime

Why even bother with types at that point? It's not just this though, Groovy is full of implicit behaviour and weird DSL's at random places.

qntm posted:

Groovy is pretty horrible. It's a superset of Java with piles and piles of "helpful" idioms added on top so you're never quite sure what's legal or what any given line of code does, or whether any bareword is a function or a class name or a variable or a type or what. Also you can leave all kinds of things implicit, leading to code which is just incoherent, like
code:
take coffee with sugar, milk and liquor

This! That example is in the official documentation:

code:

// equivalent to: paint(wall).with(red, green).and(yellow)
paint wall with red, green and yellow

This is just terrible in every way.

M31 fucked around with this message at 21:28 on Jan 15, 2016

# ? Jan 15, 2016 21:25

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 04:00

Pavlov: Oct 21, 2012; I've long been fascinated with how the alt-right develops elaborate and obscure dog whistles to try to communicate their meaning without having to say it out loud
Stepan Andreyevich Bandera being the most prominent example of that

It's called groovy, you should expect that the designers were on drugs.

# ? Jan 15, 2016 21:45

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 »