Видео

James Mickens, is that you?

@@everythingisrealrivers6582 nope, sorry. just a programmer with a bit of sanity left.

This is amazing hahahah

Q

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.

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.

He would probably already be happy if Javascript was internally consistent.

typeof "a string" !== typeof new String("also a string")

He's now a tenured CS professor at Harvard.

lol

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.

all virtual languages have hacks. But JS is not junk as it for short use , and has enormous speed . Unlike super slow rb , python & .net things .

Those last two sentences make zero sense. Scripting languages _are_ programming languages, and whether properties are re-evaluated is completely unrelated to what “kind” of language JavaScript is. The real issue with the array examples is twofold: First, “Array” is a misnomer and should be called “List”, like in Python. Second, James actually misused the Array interface: a JS Array is supposed to be used like a list of elements. If you have missing indexes, i.e. a _sparse_ Array, or want to delete certain indexes, you really should be using a plain object instead. Arrays are objects and behave as such, but when you misuse them, you break a lot of assumptions about how an Array will behave when iterated over, extended or spliced, etc.

Kirk Gleason They are swapped, the first line calls the second function. Looks like a typo but he doesn't point that.

const.

+c4tch This is a common argument, that people impose knowledge of previously used languages onto JavaScript preventing them from _getting_ JavaScript. This argument is in fact proof of how bad JavaScript is. These preconceived notions are based on the mathematical correctness of data structures. An array is called such because it behaves like an array structure, just as stacks, queues, lists, and sets have certain proofs of correctness. Operations on these structures conform to sensible accepted preconditions and postconditions. For example: Given a stack _s_ with 0 items, and an item _x_, the function push(s, x) -> _s'_ such that _s'_ is a stack with _x_ as the top element and size = 1. These structures in programming languages are implementations of their abstract mathematical counterparts. Deviating from this expected behavior makes it difficult to reason about code. JavaScript has many deviations from expected and sensible behavior. I've used many different languages and all of these structures tend to work in a similar, expected way. It is sensible for anyone to map previous experience to them because they are simply implementations of constructs with expected behavior. JavaScript is a poorly conceived language. I don't see any way to prove otherwise.

+c4tch First, let's get one thing out of the day. JSON is a *language-independent* data interchange format. Code to generate and parse JSON-format data is available in many programming languages. JSON is hardly a reason to use JavaScript. Second, an "array" has a universally understood definition and meaning that are common to nearly every programming language in the universe, *except for JavaScript*. Why is this? If a JavaScript "array" isn't really like the array most of us know, then give it a different name and help avoid confusion. Third, JavaScript needs a proper array type because there are many useful algorithms that rely on the conventional array definition *and its predictable behaviour*. I don't know what the current JavaScript arrays would be used for, or *where* they would be used, or *why* they would be used. Perhaps someone can enlighten me and explain their justification for existing. While I'm at it, let me say that JavaScript also needs a proper integer type. What the hell kind of language doesn't have an integer type???

Yeah. People have the same problem with calvinball. It

In the universe of how arrays behave in all languages, Javascript is the retarded step-child. No reasonable assumptions about how arrays work apply in Javascript, and there's no good reason why they behave the way they do. Javascript was literally created in like 2 days by Brendan Eich and has persisted as historical accident. It's a trash language, which is why ES6 and Typescript had to be invented to make it less trash, go away now.

@c4tch This comment is now 6 years old. Curious to know if you're still a programmer and still feel this way?