This is the first programming video I've watched that has made me LOL! Well done. I've been studying js for a few months and I guess I'm lucky that it's my first language. I have nothing to compare it to so everything seems normal to me...mostly. I do scratch my head sometimes. Often.
"What is a javascript array?" Hah, you won't get me, I've worked with JS, the correct answer is "Who the fuck knows?", same as the correct answer to any question about JS.
"What should I read if I want to learn JavaScript?" The Bible, probably. Or any other book that has at least theoretical chance to get the God to communicate with you and explain to you the difference between good and evil.
The problem with JavaScript is two-fold. First, its design is extremely sloppy. That's why it has tons of internal inconsistencies and WTFs, more than any other programming language I can think of. Second, its design criteria are pretty much unique to JavaScript. "Exotic" objects (of which array objects are an example) do not, IMHO, provide enough benefits for the confusion they cause. Over the past decade, we've seen evolving specifications that make the language ever larger and more complicated. JavaScript's feature set today has everything but the kitchen sink thrown in. WTF.
If this guy is freaked out by arrays, just wait until he finds out about strings "Wait, so you're telling me that you don't have to instantiate an array of characters??? What is this madness! JavaScript is crazy"
7:48 That would not return { "x": 42 } as the function name is not the same. It would throw a ReferenceError. Aside from that, I learned one thing from this video, which was that you could specify array indices as strings as well (so long as the string can be coerced to a number).
You have it backwards. Arrays are just objects whose properties are strings that represent positive integers. All property names are strings. This include indices.
The array was resized to be large enough so that it could fit an item at the requested index. Every index that was never defined was left that way. When the last item was deleted, the array did not shrink. This is fairly normal behavior I've also seen from managed arrays in other languages (they often GROW automatically, but do NOT SHRINK automatically). Who bases their opinion of a language on how the language responds to doing things you have no good reason to do, like putting an item in index 5 of a newly-initialized array? ASI (Automatic Semicolon Insertion) is weird, but getting used to how it works takes very little time, and then is no longer a significant issue. Other than that, the only major complaints I've seen about Javascript are just really stupid things, like "what happens when you compare an object to an array". Is it really the programming language's fault that you're doing something as stupid as comparing an object to an array? Maybe I'm just smarter than the average bear, and I've discovered I don't need to be protected from myself as much as the average programmer needs to be.
The first problem with arrays in JavaScripts is mostly of misleading nomenclature. In pretty much any other programming language arrays are simple stuff, just a sequence of elements indexed by consecutive integer values (generally from 0 to the array length excluded). In JS they are a completely different thing, that however tries to "fake" this in a somewhat credible way. The automatic growth is not really the big deal - although it can be argued that it makes for error-prone code - the point is that it doesn't "really" grow the array adding all the elements in between, as JavaScript arrays are essentially hashtables with a "maximum index" property. When you do var a = []; a[5] = 42; the array length becomes 6, and if you iterate over it from 0 to 6 excluded you get 4 undefined and our 42. However, those 4 undefined aren't really there, as, if you do a.forEach(function(v) { console.log(v); }); you'll discover that the only value that is "really" there is 42. More fun: if you do a[3] = a[3], element 3 becomes "alive," and set to undefined; if you do the forEach thing again you'll see just one undefined and 42, while if you iterate "normally" you'll see the exact thing as before - it's just that not all those undefined are really the same thing. length can also be written, pruning the elements in the hashtable bigger than it. So, it mostly emulates what a "regular" array of any other language does, but it's a way more complicated data structure, with strange corner cases. Actually, the "hashtable part" we are talking about is just the regular "properties" of the underlying JS object; the indexes you put in are called "numerical properties", and are numerical only in form, as ultimately they are stored (conceptually) as strings anyway; in facts, as shown in the video, even indexing with a["5"] will retrieve the 42 above (but not a["05"], which testifies that it's converting the property name to string if necessary, not converting it to number to access a numeric-indexed value). The big magic is that, if what you pass in (stringized) "looks like" a decimal integer, it keeps updated the length of the array (I never looked at the spec for this part, I'm pretty sure that, as always in the ECMAScript standard, there will be a huge algorithm with lots of juicy corner cases to determine what is really a number and what is not). I cannot see how anyone can argue that this is simple, and that this is better than a "plain" array; I'm not arguing for C-style, fixed size array, but for arrays as in most other scripting languages - e.g. Python's list. Even Lua tables - which are the most similar thing we have - are saner (mostly due to the fact that keys in Lua tables aren't restricted to strings). So the really big question is: is this big mess really necessary? As with a lot of other stuff in JS, this is superficially simple, but if you look carefully it's a huge mess, doesn't bring much useful stuff to the table, and adds a lot of cognitive load. Why do we need this bizarre contraption instead of a regular dynamic array?
@@GloomDept if you think that JS arrays work the same as Ruby arrays you don't understand at least one of them, as they are completely different data structures with deeply different behavior - and my guess is that you don't know what JS arrays are, as Ruby arrays are pretty sane. While James Mickens is an extremely smart guy, unfortunately he doesn't explain his point really well here, but he key is when he tells that a JS array is really something like a mix of an array and a dictionary. See my comment below.
Actually no. There is no concept of pre-defining the size of an array in javascript with empty values, unless you do it manually. Array(3) will not give you an array of size 3, it will give you an array with a length property of 3. And that? That is weird. No matter how you look at it, that is an incredibly weird thing. The fact that you can modify the length property of an array. And I'm not joking, you're free to try it yourself. Create an array, set its .length, and print it out. I haven't had the misfortune of working on another language where the length of an array is a lie. Even PHP, which is often seen as a combination of horrible design principals, doesn't let you do this. It's non-sense.
@@Microtardz Well, there is “new Array(3).fill()”. Is that still “doing it manually”? In modern JS applications you’d rarely use the Array constructor like this anyway. A better pattern is “Array.from({length: 3}, (_, index) => someValue(index))”, if you really want an empty array of a fixed length. But you rarely need one to begin with.
5:00 I’m not quite sure why this didn’t make sense to him, unless he’s never had to program in c/cpp before. Originally the array took up no space in memory because it wasn’t asked to. Then he gave it a value at the 3rd position, which happens to be the fourth position in every language (arrays and lists start at 0 not 1). He then deleted that value in the memory, but the memory is still assigned to the array (this would be a memory leak in cpp) you’d need to release that spot from memory if you wanted it to return back to 0. This makes a lot of sense, I’m not quite sure what tangent he was going on.
It's supposed to be a higher level language without manual memory management, so you should be able to get the length without having to worry about capacity. Other languages don't let you assign values beyond an array's capacity, and even std::vectors in C++ will decrease the length (not the capacity) when you remove an element.
Mashpoe the word delete deletes what is inside of memory only not its address or what has claimed its space, and that’s in every language. That’s memory management. The way you remove an element in JavaScript isn’t delete, it’s splice for a specific array which is what he was trying to do. He’s shown a fundamental misunderstanding of how programming languages as a whole, and JavaScript work. To address your other statement where you say other languages don’t let you assign out of an arrays scope, you are right, but what you’re talking about is completely different. JavaScript arrays are dynamically changing, like python lists etc. that means when you add something to it, it’ll add something to the list. Unlike in cpp you can’t specify a bound for an array to stay within, so it never technically goes out of bounds unless you are indexing the list and go out of bounds with your indexing.
Mashpoe as stated in Mozilla.developer.0rg the JavaScript delete operater removes a property from an object, and IF no references to it are made it will eventually release it automatically. Delete is simply a poorly made method in JS, but the people who use it will always get these errors even though there’s better methods out there.
Mashpoe check the other comments, others have mirrored what I have said. Some company / the conference itself chose him, in my opinion because he shares the same name as an accomplished Harvard engineer, but if anybody were to give him a standard software development test with algorithms and all he would fail them simply because he doesn’t understand what the stuff he’s using does.
@@zBMatt I think the point he is making (which I agree with) is that no array should behave like that, after all, it's an array, not a hashmap. To address your first point I was saying that while yes, the JavaScript example with "delete" is memory management, JavaScript is supposed to be a high level language with garbage collection, and the user should never have to deal with memory management at that level. Just because something has an explanation doesn't mean it makes sense, and if we're talking about how other languages like C++ handle "delete", it does not work on individual array elements because arrays are supposed to be consecutive in memory, e.g. there can't be a non-existent element between two filled array elements. You can have a null value, but there has to be a value of some kind because that's how arrays are supposed to work. Also methods like "splice" didn't even exist when JavaScript was created, which means that's how you were supposed to delete elements at some point, and methods like "splice" are just workarounds for something that doesn't actually behave like an array at its core.
I feel like the reason he talked about an array for so long was because he doesn't actually understand how to program, but how to copy and paste professionally like most of his presentation
8:00 is your fault for writing your code really fucking poorly. If you're returning, you need to return something, ergo, `return` should always be followed by the start of an expression on the same line. Placing the value you're returning on a separate line would be horrific style in any programming language.
This is the first programming video I've watched that has made me LOL! Well done.
I've been studying js for a few months and I guess I'm lucky that it's my first language. I have nothing to compare it to so everything seems normal to me...mostly. I do scratch my head sometimes. Often.
Wait, he moved the curly brace down one line? HERESY DETECTED!
"What is a javascript array?"
Hah, you won't get me, I've worked with JS, the correct answer is "Who the fuck knows?", same as the correct answer to any question about JS.
Q
In the example that he shows around 8:49, the 2nd alert is calling the first function. Should have worked just fine.
Kirk Gleason They are swapped, the first line calls the second function. Looks like a typo but he doesn't point that.
lol I wish he had a lecture series where he taught Javascript and all of its strange ways xD
"What should I read if I want to learn JavaScript?"
The Bible, probably. Or any other book that has at least theoretical chance to get the God to communicate with you and explain to you the difference between good and evil.
James Mickens, is that you?
@@everythingisrealrivers6582 nope, sorry. just a programmer with a bit of sanity left.
This is amazing hahahah
Javascript is effed up really. It's pretty bizzare.
I'm glad I never purchased and/or read that book!
"use strict";
const.
I guess python developers all have diabetes.
The problem with JavaScript is two-fold. First, its design is extremely sloppy. That's why it has tons of internal inconsistencies and WTFs, more than any other programming language I can think of.
Second, its design criteria are pretty much unique to JavaScript. "Exotic" objects (of which array objects are an example) do not, IMHO, provide enough benefits for the confusion they cause. Over the past decade, we've seen evolving specifications that make the language ever larger and more complicated. JavaScript's feature set today has everything but the kitchen sink thrown in. WTF.
3:08 i just noticed, he said _away_ instead of array 🤣
The array thing did not seem so weird that it would warrant being talked about for so long.
This is old stuff. JS now gives the choice to satisfy the classic software engineer.
If this guy is freaked out by arrays, just wait until he finds out about strings
"Wait, so you're telling me that you don't have to instantiate an array of characters??? What is this madness! JavaScript is crazy"
typeof "a string" !== typeof new String("also a string")
7:48 That would not return { "x": 42 } as the function name is not the same. It would throw a ReferenceError.
Aside from that, I learned one thing from this video, which was that you could specify array indices as strings as well (so long as the string can be coerced to a number).
You have it backwards. Arrays are just objects whose properties are strings that represent positive integers. All property names are strings. This include indices.
@@skepticmoderate5790 so foo["03"] may return a different object than foo["3"] ?
@@GeorgeTsiros Yes, that will do, as long as stings are used.
@@gviehmann it's an object-to-object map, then? huh.
The array was resized to be large enough so that it could fit an item at the requested index.
Every index that was never defined was left that way.
When the last item was deleted, the array did not shrink. This is fairly normal behavior I've also seen from managed arrays in other languages (they often GROW automatically, but do NOT SHRINK automatically).
Who bases their opinion of a language on how the language responds to doing things you have no good reason to do, like putting an item in index 5 of a newly-initialized array?
ASI (Automatic Semicolon Insertion) is weird, but getting used to how it works takes very little time, and then is no longer a significant issue.
Other than that, the only major complaints I've seen about Javascript are just really stupid things, like "what happens when you compare an object to an array". Is it really the programming language's fault that you're doing something as stupid as comparing an object to an array? Maybe I'm just smarter than the average bear, and I've discovered I don't need to be protected from myself as much as the average programmer needs to be.
The first problem with arrays in JavaScripts is mostly of misleading nomenclature. In pretty much any other programming language arrays are simple stuff, just a sequence of elements indexed by consecutive integer values (generally from 0 to the array length excluded). In JS they are a completely different thing, that however tries to "fake" this in a somewhat credible way.
The automatic growth is not really the big deal - although it can be argued that it makes for error-prone code - the point is that it doesn't "really" grow the array adding all the elements in between, as JavaScript arrays are essentially hashtables with a "maximum index" property.
When you do
var a = [];
a[5] = 42;
the array length becomes 6, and if you iterate over it from 0 to 6 excluded you get 4 undefined and our 42. However, those 4 undefined aren't really there, as, if you do a.forEach(function(v) { console.log(v); }); you'll discover that the only value that is "really" there is 42.
More fun: if you do a[3] = a[3], element 3 becomes "alive," and set to undefined; if you do the forEach thing again you'll see just one undefined and 42, while if you iterate "normally" you'll see the exact thing as before - it's just that not all those undefined are really the same thing.
length can also be written, pruning the elements in the hashtable bigger than it. So, it mostly emulates what a "regular" array of any other language does, but it's a way more complicated data structure, with strange corner cases.
Actually, the "hashtable part" we are talking about is just the regular "properties" of the underlying JS object; the indexes you put in are called "numerical properties", and are numerical only in form, as ultimately they are stored (conceptually) as strings anyway; in facts, as shown in the video, even indexing with a["5"] will retrieve the 42 above (but not a["05"], which testifies that it's converting the property name to string if necessary, not converting it to number to access a numeric-indexed value). The big magic is that, if what you pass in (stringized) "looks like" a decimal integer, it keeps updated the length of the array (I never looked at the spec for this part, I'm pretty sure that, as always in the ECMAScript standard, there will be a huge algorithm with lots of juicy corner cases to determine what is really a number and what is not).
I cannot see how anyone can argue that this is simple, and that this is better than a "plain" array; I'm not arguing for C-style, fixed size array, but for arrays as in most other scripting languages - e.g. Python's list. Even Lua tables - which are the most similar thing we have - are saner (mostly due to the fact that keys in Lua tables aren't restricted to strings).
So the really big question is: is this big mess really necessary? As with a lot of other stuff in JS, this is superficially simple, but if you look carefully it's a huge mess, doesn't bring much useful stuff to the table, and adds a lot of cognitive load. Why do we need this bizarre contraption instead of a regular dynamic array?
@@GloomDept if you think that JS arrays work the same as Ruby arrays you don't understand at least one of them, as they are completely different data structures with deeply different behavior - and my guess is that you don't know what JS arrays are, as Ruby arrays are pretty sane. While James Mickens is an extremely smart guy, unfortunately he doesn't explain his point really well here, but he key is when he tells that a JS array is really something like a mix of an array and a dictionary. See my comment below.
Actually no.
There is no concept of pre-defining the size of an array in javascript with empty values, unless you do it manually.
Array(3) will not give you an array of size 3, it will give you an array with a length property of 3.
And that? That is weird. No matter how you look at it, that is an incredibly weird thing. The fact that you can modify the length property of an array.
And I'm not joking, you're free to try it yourself. Create an array, set its .length, and print it out.
I haven't had the misfortune of working on another language where the length of an array is a lie. Even PHP, which is often seen as a combination of horrible design principals, doesn't let you do this. It's non-sense.
@@Microtardz Well, there is “new Array(3).fill()”. Is that still “doing it manually”? In modern JS applications you’d rarely use the Array constructor like this anyway. A better pattern is “Array.from({length: 3}, (_, index) => someValue(index))”, if you really want an empty array of a fixed length. But you rarely need one to begin with.
5:00 I’m not quite sure why this didn’t make sense to him, unless he’s never had to program in c/cpp before. Originally the array took up no space in memory because it wasn’t asked to. Then he gave it a value at the 3rd position, which happens to be the fourth position in every language (arrays and lists start at 0 not 1). He then deleted that value in the memory, but the memory is still assigned to the array (this would be a memory leak in cpp) you’d need to release that spot from memory if you wanted it to return back to 0. This makes a lot of sense, I’m not quite sure what tangent he was going on.
It's supposed to be a higher level language without manual memory management, so you should be able to get the length without having to worry about capacity. Other languages don't let you assign values beyond an array's capacity, and even std::vectors in C++ will decrease the length (not the capacity) when you remove an element.
Mashpoe the word delete deletes what is inside of memory only not its address or what has claimed its space, and that’s in every language. That’s memory management. The way you remove an element in JavaScript isn’t delete, it’s splice for a specific array which is what he was trying to do. He’s shown a fundamental misunderstanding of how programming languages as a whole, and JavaScript work. To address your other statement where you say other languages don’t let you assign out of an arrays scope, you are right, but what you’re talking about is completely different. JavaScript arrays are dynamically changing, like python lists etc. that means when you add something to it, it’ll add something to the list. Unlike in cpp you can’t specify a bound for an array to stay within, so it never technically goes out of bounds unless you are indexing the list and go out of bounds with your indexing.
Mashpoe as stated in Mozilla.developer.0rg the JavaScript delete operater removes a property from an object, and IF no references to it are made it will eventually release it automatically. Delete is simply a poorly made method in JS, but the people who use it will always get these errors even though there’s better methods out there.
Mashpoe check the other comments, others have mirrored what I have said. Some company / the conference itself chose him, in my opinion because he shares the same name as an accomplished Harvard engineer, but if anybody were to give him a standard software development test with algorithms and all he would fail them simply because he doesn’t understand what the stuff he’s using does.
@@zBMatt I think the point he is making (which I agree with) is that no array should behave like that, after all, it's an array, not a hashmap. To address your first point I was saying that while yes, the JavaScript example with "delete" is memory management, JavaScript is supposed to be a high level language with garbage collection, and the user should never have to deal with memory management at that level. Just because something has an explanation doesn't mean it makes sense, and if we're talking about how other languages like C++ handle "delete", it does not work on individual array elements because arrays are supposed to be consecutive in memory, e.g. there can't be a non-existent element between two filled array elements. You can have a null value, but there has to be a value of some kind because that's how arrays are supposed to work. Also methods like "splice" didn't even exist when JavaScript was created, which means that's how you were supposed to delete elements at some point, and methods like "splice" are just workarounds for something that doesn't actually behave like an array at its core.
No one cares, IT is crap.
I mean, it's really not that bad lol.
He is obviously too lazy to learn JS xD
This guy would be happy if every language was the same .. omg
He would probably already be happy if Javascript was internally consistent.
I feel like the reason he talked about an array for so long was because he doesn't actually understand how to program, but how to copy and paste professionally like most of his presentation
He's now a tenured CS professor at Harvard.
lol
8:00 is your fault for writing your code really fucking poorly. If you're returning, you need to return something, ergo, `return` should always be followed by the start of an expression on the same line. Placing the value you're returning on a separate line would be horrific style in any programming language.
sed -i s/java script/rust/g