The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd definitely like to see more influence of the first two and less from the last one.
The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd definitely like to see more influence of the first two and less from the last one.
I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?
In most functional languages using list indices are an anti-pattern. Pattern matching and generalized iteration is a much more elegant way to handle most things you would use an index for.
The primitive collection types index at 1, but, as you said, are almost never indexed that way. I'm not sure the motivation as to why, but the fact it feels clunky to use them that way is a benefit, as it raises resistance when you're using them wrong (as indexing them almost always is).
http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
Having worked with both, I'm inclined to prefer 0 based addressing in most cases. It's slightly less intuitive, but it generally leads to cleaner code.
I see it as rather simple. If you're listing off-sets, starting at 0 makes sense, because there'll be something there. But if you're counting elements starting at 1 makes more sense. I don't have 9 fingers offset from my first one, which I call finger zero; I have ten fingers, starting with the first one.
A set with no members is the zero set, once you add one element, you have a set of one. An empty list contains no elements. It does not have a first member, because it's empty. Add an element, and it will have one member, and it will be in the first position. Not in the zeroeth offset from the beginning.
You can the numeric names of letters of a string in an array, but I don't see that as a compelling reason for naming the first letter of a word, the letter which is at the zero-eth offset from where the word is held in memory. At best, it's a low level optimization, at worst it's just a leaky abstraction. Maybe you want to store the length of the word there (like in Pascal), for a different trade-off in terms of what is optimized.
I think you mean Dijkstra, who did say that, because of an argument with mathematicians about indexing from 1.
There's even a section about this on wikipedia: https://en.m.wikipedia.org/wiki/IJ_(digraph) subsection "technical details".
Edit: from Wikipedia[1]: "It used to be common, in particular when writing in capitals, to write Y instead of IJ."
So it's an obsolete practice...
----
0. something along those lines: http://alphabetprintables.org/alphabet_printables_cursive/up...
Starting a REPL or running a computation that doesn't take long time, adjusting parameters, re-running. Startup time may not be too big in absolute numbers but it's noticeable and adds up quickly especially if you start using more packages rather than toy programs that I used as an example.
Yes, that's one example. Also when debugging one usually uses small data sets. There are plenty of cases where runtime is short.
I think the problem is that Julia is somewhat vague on how it should be used. If it stated explicitly that it is intended to be used in MATLAB-like fashion with one long-running instance that would save people from trying to use it as Python or other dynamic language.
Intel's Math Kernel Library, which is a performant math library hand-tuned for Intel processors is zero-based in MKL-CBLAS.
It all depends on what you are familiar with, and staying consistent in use. I just use zero-based indexing in J and C and my numerical low-level work.
I have used quite a few languages whose base index could be 0, 1 or whatever I choosed. Even enumerations.
https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra...
metric distance conversion chart:
cm m km
1 1.00 1.00000
2 1.01 1.00001
3 1.02 1.00002
...
101 2.00 1.00100
...
100000 1000.99 1.99999
The ratios between the values aren't fixed now; we can't go from cm to m just by scaling by 100. We must subtract, scale then add.One based indexing falls apart if you have to index a region of storage as bits, bytes and words at the same time.
Counting is indexing!
What is it that you do when you count items in a set? You put them into correspondence with the natural numbers, indicating each one as 1, 2, 3, ... The last integer is the count.
Yes, it is related to the "is the first floor ground, or the one above it"; and it's clear that some programming languages take their cue from stairs and elevators.
Nobody ever has to calculate "what is the floor twice as high as this one?" Moreover, people are unfazed by 13 missing.
(I haven't seen a language that omits 13 from indexing, fortunately.)
Is skipping the 13th floor a US thing? I don't recall ever seeing it in the UK or Germany.
And their documentation has section numbers like 1.1, 1.2, ... 5.3.3.
OTOH, for something physical that actually is indexing, or at least closely analogous to it, we could ask "what if principal quantum numbers used 1-based indexing". But, then, the answer would be "things would look exactly like they do now, because it already does."
The index is the distance from the first element. Thus, the third element is two elements away from the first, thus it has index 2.
I think the only reason zero-based indexing is not the standard everywhere is because some people (usually non-programmers) have a problem with the idea that the fifth element has index four.
I am suggesting that this is a linguistic problem that has messed up programming.
Indices can be regarded as measures. We speak about an array having a "size" or "length": that is measurement language. Something is "3 words wide": ditto.
A given record in a file can be 25 words from the beginning, or 100 bytes, or 800 bits. All of these tell us how much storage immediately precedes that record and we can easily convert among them.
If indices support calculation, they should be displacements, and displacements should originate at zero.
Indices not intended for calculation (beyond simple successor/predecessor, perhaps) can place items into correspondence with any ordered set: natural numbers, letters of the alphabet, and so on. This is where we can get away with 1 based.
Indices not intented for any calculation whatsoever can use a set: like associating character strings with objects via an "associative" array or whatever.