Not only am I going to run into edge cases with this in the future, but I'm going to have all sorts of problems with virtually every keyword in the javascript language at some point.
But ultimately, i feel that once you get them, you get to a point where you can write cleaner, more legible code. Whether that's a tangible, quantifiable ability or an imaginary boyscout patch is another matter. As an example, before I knew you could do short circuit execution with the && operator, I found code that employed it weird and unwieldy. Now it's a valuable tool I have to explain my ideas more precisely.
I really liked the hackernoon article you've linked, and am inclined to agree more with some of the other points, (var is dead, RIP for) and if you're coming at it from a purely functional point of view, then I'd have to agree. But I still find plenty of ways to mess around with object oriented patterns every now and then, and this is a useful component when trying to reason about things in that way.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
I would disagree with this and the example I will provide is NULL. NULL is one of the simplest concepts to understand. So simple it could be the very first lesson of someone learning to program for the first time.
It's an interesting idea, and as you say above, one of the reasons JS is now so ubiquitous is that you can mould the language in whatever shape you like just through coding style. I will, probably keep using this in my react components, and when doing anything that feels like it should be more object oriented, but it's great to have alternatives, and as functional dialects become more widely adopted, and thus more legible, I'm sure it's usage will probably decline anyway.
While this is a really interesting thought exercise about how different language features affect the code we write I don't think it'll affect the code I write today.
Also, practically burst out laughing reading that article about null:
If a property of an object doesn’t exist, JS returns a value to indicate the absence. The designers of JavaScript could have chosen this value to be null.
But instead they worried about cases where the property exists and is set to the value null. In a stroke of ungenius, JavaScript added undefined to distinguish a null property from a non-existent one.
But what if the property exists, and is set to the value undefined? Oddly, JavaScript stops here, and there is no uberundefined.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Two values that don't have values and one number that isn't a number. Again, we get paid to make arrangements of minerals dream about words we write. It's not related, but I feel like every conversation about coding should be had in this context.
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.
Not only am I going to run into edge cases with
thisin the future, but I'm going to have all sorts of problems with virtually every keyword in the javascript language at some point.But ultimately, i feel that once you get them, you get to a point where you can write cleaner, more legible code. Whether that's a tangible, quantifiable ability or an imaginary boyscout patch is another matter. As an example, before I knew you could do short circuit execution with the
&&operator, I found code that employed it weird and unwieldy. Now it's a valuable tool I have to explain my ideas more precisely.I really liked the hackernoon article you've linked, and am inclined to agree more with some of the other points, (
varis dead, RIPfor) and if you're coming at it from a purely functional point of view, then I'd have to agree. But I still find plenty of ways to mess around with object oriented patterns every now and then, andthisis a useful component when trying to reason about things in that way.I would disagree with this and the example I will provide is NULL. NULL is one of the simplest concepts to understand. So simple it could be the very first lesson of someone learning to program for the first time.
Yet NULL is now considered a THE WORST MISTAKE OF COMPUTER SCIENCE and is now being called The Billion Dollar Mistake.
We all understand NULL and yet we will be plagued with
NullReferenceException's riddled throughout our code.Just because it is the status quo is not a valid reason to not change the status quo.
If we know the steps to take to eliminate entire classes of bugs, why are we so hesitant to take those steps?
If NULL is the Billion dollar mistake, how much is
thisgoing to cost us?It's an interesting idea, and as you say above, one of the reasons JS is now so ubiquitous is that you can mould the language in whatever shape you like just through coding style. I will, probably keep using
thisin my react components, and when doing anything that feels like it should be more object oriented, but it's great to have alternatives, and as functional dialects become more widely adopted, and thus more legible, I'm sure it's usage will probably decline anyway.While this is a really interesting thought exercise about how different language features affect the code we write I don't think it'll affect the code I write today.
Also, practically burst out laughing reading that article about
null:Haha ya seriously. if NULL wasn't bad enough, we got stuck with two of them! lol
Two values that don't have values and one number that isn't a number. Again, we get paid to make arrangements of minerals dream about words we write. It's not related, but I feel like every conversation about coding should be had in this context.