Used to is the important word here. They improved a lot.
I like them. MDN is great, but w3schools is better in giving examples on how to use stuff.
I like them. MDN is great, but w3schools is better in giving examples on how to use stuff.
W3schools were so bad, essentially just a click farm promoting any old crap for the pageview, that it'll take a huge amount of correcting, improving, and newly found ethical standards to let me forgive them. Or forget there really was a need for w3fools. They always gave lots of examples, and they were often simply wrong.
Even when they apparently have the answer, until I can validate it on SO or some other place, I'll tend to not trusting...
<p>see the Console API</p>
<footer>don't use alert(), don't talk about alert(), don't teach alert(), it's not 1997 anymore</footer>
You just have to give proper context.
That's not 'tests' — tests would be something like Mocha, or Jasmine — what you're actually talking about here is one of the many forms of ad hoc in-browser debugging.
Ah, if only there was a single word - a verb perhaps - that developers could use to colloquially refer to this process!
If you're teaching, teach people to use console.log because that's where they're going to get REAL insight into what the code's doing (console.table you say? amazing!) and never look back. And if you're learning, demand people teach you modern practices. Not ridiculous things from 20 years ago.
Original comment:
There is still some complete nonsense on w3schools. For example, I wanted to know recently whether Python supports arrays. The first result on Google is this page: https://www.w3schools.com/python/python_arrays.asp
There is a small disclaimer at the top stating: "Note: Python does not have built-in support for Arrays, but Python Lists can be used instead."
Why the fuck is your page called "Python Arrays" if you don't plan to talk about arrays?
Then the rest of the page talks about lists, while erroneously calling them arrays, in complete defiance of the disclaimer. I imagine what happened is that someone who doesn't know what an array is wrote the page originally, then someone else came by later and realized it was wrong, but instead of actually fixing it, slapped that half-assed disclaimer on top.
I still don't know whether stock Python actually supports arrays. I ended up just importing Numpy.
I have literally never seen or heard of a definition of array according to which lists are arrays -- can you cite one?
By the only universal definition I can think of, python lists are arrays.
Python lists most certainly meet the mathematical definition of array (ie name by index)
That makes my point even stronger. The article about "Python Arrays" directly claims that Python Arrays don't exist, which is apparently wrong!
The whole point is that I came away from the article believing information that is false.
Same as how a hashtable is used to implement a mapping.
One of the useful definitions of an array is that it guarantees contiguous storage in memory. In Python, there is no way to guarantee that; even if a list is a C array of Python references under the hood, there's no way to store the information represented by those references contiguously in memory. From that perspective, pure Python doesn't have any arrays at all, which is precisely why the popular NumPy has to offer explicit support for numeric arrays.
From another perspective, arrays are a set of O() guarantees for various operations. From that perspective, Python lists will generally meet the specifications that you'd write for a resizable array, or perhaps what you might call "vector", depending. CPython comes with some awful constant factors but the O() of the lists will be what you'd expect.
Rather than arguing about whether Python has "arrays" interminably, it's better to carefully define array, then dispassionately examine Python lists to see if they match that definiton. You'll get a yes sometimes and no others. I say "dispassionately" because too many people seem to assign moral qualities to whether or not something conforms to a given definition, but that's not a path to understanding. No matter what definition you write down for "array", not a single characteristic of Python will change.
that w3schools page is indeed nonsense. They should probably stick to JS.
If they are, then the article is even worse, as the disclaimer that Python doesn't have arrays is a lie!
While the Python 3 docs for arrays certainly do lean on the type-constraint, I notice it also has the various operations that imply a contiguous buffer (cast to bytes, etc.), so I wonder if that's not the real distinction and the type constraint serves that.
Traditional Python lists are much closer to what I know as a vector: indexable like an array, but dynamically expandable and usually implemented as a list of references to data structures instead of containing the data itself so allows for heterogenous data.
Informally, I've certainly called both types of things arrays, right or wrong, and rarely call anything a vector other than container classes by that name, but I do suspect that's what your parent comment is drilling on.
* Then there's the JS Array class, which acts more like a vector than array by those definitions, so who knows.
That's a pattern of the language and why I don't like it: It's very often almost like the other C-like languages, only to be that much different that it gets confusing. To just ignore that and call a list an array is not correct, but it makes the beginner searching how to do array-like stuff in python succeed in his task.
I'd be more annoyed at that page if they didn't explain the situation, but they do.
Actually, they don't. The article claims that arrays don't exist, but you can use lists instead.
Apparently the polar opposite is true: lists don't exist, but you can use arrays instead! (And they're called "lists" for whatever reason).
But python also has an array module you can use after an import, it's not loaded by default. That data structure behaves even more like the thing C calls an array.
I don't see why a python list is not a list per se. Don't be confused by the others explaining it is not a linked list - something does not have to be a linked list to be a list. It's still a numbered collection of stuff that can be sorted, thus a list.
Though it is true that as a programmer you probably are first confronted with a data structure called list when you learn a LISP, and that data structure will be a linked list.
Confronting beginners with all this is not useful for them, w3schools just adding a note and calling the python default collection thing an array is thus not that unreasonable. Though I'd prefer it if they just called it a list in the explanation below the note, after explaining that this list structure is what you are probably searching, with a link "look there for what python calls an array". So in that way I agree with you, this is not optimal.
The whole point of my comment is that I went away from the article still not knowing whether Python has arrays, or not. I can't understand how anyone would defend an article called "X" that doesn't even properly inform you whether X exists
If a programmer from another language asks for an array, I'm going to point them at the `list` class in Python.
As some other sub-comments under your original post note, some uses of an array want the actual data to be contiguous. But Python `list`'s values are references to other values, not the direct values themselves. If you're familiar w/ C, it's closer to an array of pointers to objects. That matters for some niche cases. But in basic tutorial? No. And Python has some built-in types to account for some of the niche cases. Sure, that pointer is not free, and the overhead of a Python object is not free, but Python is a high level scripting language, and generally, `list` provides a random-access ordered collection, which is what most people want when they say "array", and the overhead doesn't matter for many things.
An optimizing Python doing escape analysis could see a list was going to be converted to a set and swap in a set and change the method calls. Or it could see a large number of concatenations and use a linked list as an intermediate form.
Of course improvement without expectation of reward shows a higher moral stature, but it is a stature that is perhaps not to be expected, whereas improvement based on reward seems more likely to exist in our world - given studies of the matter.