One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
On the other hand, this question is great to start a conversation on why old-school JavaScript is bad - JavaScript has good parts, but had lots of flaws as well, most of which were fixed later by EcmaScript 6, Typescript, React, Angular, ...
I started my career in Android land which, at the time, requires lots of ceremonial boilerplate to get things going.
Kotlin is a huge improvement. Thatβs besides the point
Iβve now been working with React and React Native professionally for a couple years and really have become enamored with the ease of iteration.
As an independent developer, shlopping JSON around the application and perhaps providing some required props here and there is all Iβve really needed. We donβt need statically typed languages to write mobile applications.
Would they have helped on some crazy debugging issues Iβve had? Absolutely.
Should I have gone through the hassle of adding another layer of abstraction just because they essentially give me better warnings? Jury is still out. For me personally, I donβt think so.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Yes, and every tool should work on fixing its main flaws. This is basically what was done with JavaScript with both EcmaScript 6 and TypeScript and React and Angular...
No-one would dispute that "old-school JavaScript" had lots of flaws; but most developers with a job will have migrated to a "safer" programming language some time ago; namely JavaScript. Believe it or not the language has moved on since Crockford wrote "The Good Parts"; as is obvious from the ES6 solution provided.
And Typescript is not "another programming language" that magically guarantees you are free of the issues illustrated in the example question. It's still just JavaScript. I can still type that problem loop into my editor; Typescript will still compile and it will still produce the same output.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Believe it or not the language has moved on since Crockford wrote "The Good Parts"; as is obvious from the ES6 solution provided
I believe it!
I have edited my original answer, it was not my intention to claim that the current JavaScript ecosystem is the same as "old school Javascript".
Agree with you. At first I thought the same thing everyone else did. It would print out the value. But as soon as I saw the index 4, I knew exactly what was happening.
This is the sort of thing you usually don't spot while coding but once you see it happening (usually in test run), is trivial to debug and fix. For one, using let and const over var produces more sensible and predictable results.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you on the interview process.
On the other hand, this question is great to start a conversation on why old-school JavaScript is bad - JavaScript has good parts, but had lots of flaws as well, most of which were fixed later by EcmaScript 6, Typescript, React, Angular, ...
Edit: clarified my answer
Every tool has its uses.
I started my career in Android land which, at the time, requires lots of ceremonial boilerplate to get things going.
Kotlin is a huge improvement. Thatβs besides the point
Iβve now been working with React and React Native professionally for a couple years and really have become enamored with the ease of iteration.
As an independent developer, shlopping JSON around the application and perhaps providing some required props here and there is all Iβve really needed. We donβt need statically typed languages to write mobile applications.
Would they have helped on some crazy debugging issues Iβve had? Absolutely.
Should I have gone through the hassle of adding another layer of abstraction just because they essentially give me better warnings? Jury is still out. For me personally, I donβt think so.
I am no fan of Android as described here :)
Android's billion-dollar mistake(s)
Jean-Michel Fayard γ» Sep 25 γ» 10 min read
Yes, and every tool should work on fixing its main flaws. This is basically what was done with JavaScript with both EcmaScript 6 and TypeScript and React and Angular...
No-one would dispute that "old-school JavaScript" had lots of flaws; but most developers with a job will have migrated to a "safer" programming language some time ago; namely JavaScript. Believe it or not the language has moved on since Crockford wrote "The Good Parts"; as is obvious from the ES6 solution provided.
And Typescript is not "another programming language" that magically guarantees you are free of the issues illustrated in the example question. It's still just JavaScript. I can still type that problem loop into my editor; Typescript will still compile and it will still produce the same output.
I believe it!
I have edited my original answer, it was not my intention to claim that the current JavaScript ecosystem is the same as "old school Javascript".
Agree with you. At first I thought the same thing everyone else did. It would print out the value. But as soon as I saw the index 4, I knew exactly what was happening.
This is the sort of thing you usually don't spot while coding but once you see it happening (usually in test run), is trivial to debug and fix. For one, using let and const over var produces more sensible and predictable results.