To each his own, but out of curiosity what do you like about using the term Vec for dynamically-sized arrays? To me it just seems that it's an inaccurate usage of a term with a precise mathematical meaning (what is a vector of strings exactly?), and as somebody who works with linear algebra a lot in code, it's a frequent point of consternation to have this built into two of the most relevant languages for achieving high performance.
Meaning is inherently contextual, so different things meaning different things in different contexts is the norm, not the exception. Do I get upset that a "string" isn't made of "thread"s?
It is true that mathematics is closer to programming than tailoring is, but you can't escape this issue. So I don't get particularly worked up about it.
(This context is why this matters too; "vector" as a term for this is established, just like the linear algebra term is established.)
(I do like to joke about getting worked up about this though, but I pick on String, which should be StrBuf, instead of vectors.)
So I generally agree with your point, and I'm not trying to say this is some giant issue which makes Rust and C++ unusable - on the contrary I think it's a minor annoyance at worst when trying to carve out a naming scheme for my own components.
But for the sake of internet pedantry, you seem to be saying that calling it vector is acceptable because it's established, not that there are any inherent advantages to this right? Because I would argue that we can and should take the opportunity to turn the page on imprecise terms of art which only exist for historical reasons.
Even looking at Rust, I'm very glad that char|short|int|long has been replaced with i8|i16|i32|i64 even if the former are terms of art which everyone can understand.
I am at least saying something similar to what you're saying. The inherent advantage is familiarity. You may not consider that inherent. That's okay too :)
Please excuse my WIP CSS, but I wrote a longer bit about this over at https://steveklabnik.com/writing/the-language-strangeness-bu... . I think that, for languages that intend to be adopted broadly, you have to choose carefully where you diverge from existing practice. Sometimes, you have to change, after all, that's how progress even happens in the first place! And sometimes, you're forced to change, because you don't truly have an analogous situation.
So I agree with the thrust of the point of your article as well - I guess my only point of disagreement would be where I would have placed something like naming vectors in terms of the trade-off between progress and familiarity, which admittedly probably has a lot to do with my particular domains of programming. However it does seem like a bit of a missed opportunity given the overlap between people who care about performance, and people who are working a lot with linear algebra in fields like computer graphics, simulation and ML. But I do understand that the line has to be drawn somewhere.
(On a side note, the CSS is perfectly fine, and I've been looking for a static alternative to Ghost for blogging, so I might give next.js a try)
Ah so, next is a way to make websites in general; the template linked is a good one for a blog though. I've had pretty positive experiences with next so far; I just re-did my blog in a hurry over the weekend for unrelated reasons, so it's pretty much just the template at the moment.
You can have a vector of integers, a vector of real-numbers, why do you think a vector of strings doesn't make any sense? Strings can be given a well-defined ordering. You can think about strings as a points along a string-line, if you want to.
For example - Java often names packages using co-ordinates (vectors) in an n-dimensional string space. Seems to make sense to me?
Maybe in some technical way this is correct, but when I'm pushing a string onto a vector of strings, I'm not thinking about conceptually adding a dimension to my vector in string space.
And how would you compute the cross product of <"foo", "bar", "baz"> and <"apple", "orange", "banana"> exactly?
> And how would you compute the cross product of <"foo", "bar", "baz"> and <"apple", "orange", "banana"> exactly?
Cross product isn't a well-defined operation. The wedge product[0] would be <a,b,c>~<x,y,z>=<<ay-bx,az-cx,bz-cy>>, assuming I didn't get the signs wrong again. That would require scalar multiplication and subtraction of strings, though, neither of which are generally well-defined.
If you substitute in string multiplication (ie concatentation) and addition of negatives (alternation and reversal, the latter of which is only vaguely justified by anticommutativity of multiplication), you get:
which frankly sounds to me like a pretty good argument that vectors of strings make no sense and shouldn't be supported, but maybe someone working on parsing algebras could come up a more useful interpretation.
Vectors don't 'contain' numbers, a vector is a multidimensional value. The fact that a C++ vector is conceptually a container for values more than anything else is a reason why 'vector' is a poor name for this component.
Yes they contain a number for each dimension. Not sure what you think the point of debating individual words like this? What practical problems do you think there are?
You're the one arguing from the extremely strained logic that because ordering rules exist for strings, this somehow means that C++ vectors have anything to do with mathematical vectors in the mind of the average programmer.
The practical problem is, when you do a lot of work with linear algebra, you would really like to have the term vector to use for its canonical mathematical meaning rather than having it reserved for a data structure which is not suitable for that purpose.
