The kids are all right
-
TinyIvan the Junior calls me in to show me his code. He was BTW given an internal project to hack on on his own, no guidance or my input whatsoever.
I swallow my bile and sit in, wondering what horrors await me.
TinyIvan has been stuck on validating a multi file upload. He solved the problem by googling around and adding a magic field on a magic thing in Laravel. Great.
Then, he went and refactored the Request object into its own class and moved the functionality there, so as not to pollute the controller. Then he refactored the shared functionality into a Trait, so he could use it on other pages.
All commented code and leftover garbage had been cleaned up by the time I saw the code. Everything was neat and in its place.
He then complained how a quirk in PHPStorm produces false positive errors and how it's getting on his nerves. He'd like everything to be neat and warning free.
Wha... what is happening? What is this strange, unfamiliar feeling in my chest?
-
@cartman82 said in The kids are all right:
Wha... what is happening? What is this strange, unfamiliar feeling in my chest?
That would be acid reflux from the xenomorph getting ready to burst out. Don't worry about it.
-
You did tell the guy he's doing a good job right? Wouldn't want to let him know you see through how he's trying to secure his position with needless refoctoring. Do talk to management immediately though, you don't know what he'll spring on you next. Better see to firing him now while the damage is contained.
-
He doesn't like javascript.
He prefers
len(array)in PHP toarray.length.You know what? Fuck that kid.
-
@cartman82 said in The kids are all right:
You know what? Fuck that kid.
Why don't you have a seat over there....
-
Plot twist: he's a serial murderer.
-
-
@error You can also add parenthesis to clarify things without changing the meaning!
-
@LB_ said in The kids are all right:
@error You can also add parenthesis to clarify things without changing the meaning!
Non-commutative and non-associative? Sign me up!
-
@error it's caused by braces having multiple meanings in Javascript. In the case of
{} + [], the braces are parsed as an empty code block, followed by+ []. Putting parentheses around them makes the JS parser interpret them as an object literal instead.
-
@anotherusername said in The kids are all right:
In the case of {} + [], the braces are parsed as an empty code block, followed by + [].
Wow, that doesn't sound retarded at all!
Filed under: It's almost like automatic semicolon insertion might be a bad idea.
-
@cartman82 said in The kids are all right:
What is this strange, unfamiliar feeling in my chest?
-
@blek said in The kids are all right:
Plot twist: he's a serial murderer.
Man...I ate a lot of Cheerios when I was young.
Oh...serial...
-
@error said in The kids are all right:
@anotherusername said in The kids are all right:
In the case of {} + [], the braces are parsed as an empty code block, followed by + [].
Wow, that doesn't sound retarded at all!
Filed under: It's almost like automatic semicolon insertion might be a bad idea.
It's not really about automatic semicolon insertion. It's about the parser figuring out what
{means based on what came before it, without having to look ahead at what comes after it.Even looking ahead may not always help. This:
{ label: doStuff() }can be interpreted as either a valid object literal, or a valid code block.
-
@anotherusername said in The kids are all right:
can be interpreted as either a valid object literal, or a valid code block.
UB is a giant pain in the ass, but it at least avoids shit like this.
-
@anotherusername said in The kids are all right:
It's not really about automatic semicolon insertion. It's about the parser figuring out what { means based on what came before it, without having to look ahead at what comes after it.
It's weird to me that JavaScript even allows blocks independent of e.g.
for,if,function. They don't really do anything (they don't introduce a newvarscope for example). (letandconstcame much later and aren't relevant.)ASI is relevant, because it introduces ambiguity. If
doStuffin your example had a semicolon after it, then obviously it would be a statement; but since the semicolon is optional, it become ambiguous.
-
@error said in The kids are all right:
It's weird to me that JavaScript even allows blocks independent of e.g.
for,if,function. They don't really do anything (they don't introduce a newvarscope for example). (letandconstcame much later and aren't relevant.)A block and a statement are syntactically synonymous. The fact that a block usually replaces the statement in a
for,if, orwhileis irrelevant. (The{}around afunctionbody is not an ordinary "block", it's part of the function syntax. Same goes forswitch.)A block can also be paired with a label, and then can be used to
breakfrom one or more loops, like so:label: { for (...) { for (...) { if (...) { break label; } } } }ASI is relevant, because it introduces ambiguity. If
doStuffin your example had a semicolon after it, then obviously it would be a statement; but since the semicolon is optional, it become ambiguous.Still, the parser would need to look ahead, which is an undesirable requirement. And the presence or absence of a
;would completely change its interpretation of that code, which would be an even worse
.
-
@anotherusername said in The kids are all right:
And the presence or absence of a
;would completely change its interpretation of that code, which would be an even worse.Don't worry, JavaScript already has that problem:
Why should I use a semicolon after every function in javascript?
I've seen different developers include semicolons after functions in javascript and some haven't. Which is best practice? function weLikeSemiColons(arg) { // bunch of code }; or function
-
@LB_ at least, currently, the presence or absence of
;can only affect what comes next, not what came before...I think.
I hope.
inb4 examples proving me wrong
-
@anotherusername I'm just concerned about the fact that removing a semicolon can result in code that still runs but does the wrong thing.
-
@LB_ said in The kids are all right:
the wrong thing
Well, “wrong” is a value judgement, a mere point-of-view…
-
@cartman82 said in The kids are all right:
He doesn't like javascript.
No sane people like javascript
He prefers len(array) in PHP to array.length.
What is so different about these 2?
-
@fbmac said in The kids are all right:
What is so different about these 2?
Object notation vs procedural notation. Behind the scenes, it's the same shit.
PHP has always been picking up influences of whatever tech or style is currently popular. I guess the
lencount came in at the time they were fapping off to python.As to why I prefer object notation, one word - intellisense. Find a coder stuck using a text editor instead of IDE, the chance is they'll be just fine with having hundreds of undiscoverable contextless little functions all over the place. No bueno for me.
-
@cartman82 some languages only support ADL with non-member functions. What would you suggest instead?
-
@cartman82 I think Juniors just tend to hate a particular languages because they don't understand how to do some simple things because they don't have the mental tooling yet to quickly learn said language. Frustration kicks in and they end up blerting "Fucking JavaScript".
Once you learn a second for third language, you tend to think "I need to learn how to do these things to be able to achieve this task, in this language ... so I will learn those first".
-
@cartman82
len(foo)versusfoo.Len()? The difference is that if they had made arrays implement a method, they would have matched some non-empty interface. Go would be a lot more complicated if unnamed types could match interfaces other than the empty one.
