The reason the languages that come from math rather than engineering index from 1 is because mathematics didn't originally have a 0 and even though they figured that out over a thousand years ago they stuck with the notation. On computers, it makes no sense to index from 1 as it's inefficient. While you can hide the inefficiency when treating the index as some sort of index type, there will be times where you need to convert the type (e.g., user input, serialization, etc.) and you'll introduce pointless decrements at that point.
Talk to a girl who is in her last semesters of software engineering (basically doing her intership)
David Reed
Tyler Perez
hello niggers.
Brayden Green
No, 1-indexing makes perfect sense, mathematically. The highest index equals the length of the list. 0 isn't particularly sensible.
Indexing from 0 gives you the abhorrent property, in C, that a[b] == *(a + b) == b[a]. If you're working with pointers and you hate abstraction then it makes sense, maybe. Any effect decrementing has on efficiency might as well be a rounding error, it doesn't matter.
Camden Martinez
Proper unicode support, formatting string literals, sensible division behavior, range dict_keys etcetera are lazy, generalized unpacking, optional static typing, print is a real function, syntax for declaring classes is less stupid, and a lot of other things.
Julian Perez
You don't actually know C, do you?
Ah yes, math people. This is why we don't let you write languages or network services anymore.
Asher Jenkins
You don't believe me? Watch this:
$ cat test.c#include int main (void) { int i = 3; int *p = &i; printf("%d %d %d\n", p[0], *(p + 0), 0[p]);}$ tcc -run test.c3 3 3
Sebastian Murphy
The image is to show syntax highlighing only and has errata.
[[$]] containers.;;-> Linked ListThis is a simple linked list using the Listable trait which allows you to addthis trait to your struct. prev: Listable*?. next: Listable*?.).$::LinkedList(T) < #( -> $::count: i32. $::head: Listable(T)*?. ;; Listable(T) means that the type implementing ;; Listable must be T. ? is for $::[[utils]]::Optional. $::tail: Listable(T)*?. $::add < %({&this item: Listable(T)* after: Listable(T)*?} -> !this::head? ( this::head = item. this::tail = item. $!. ;; return void ) !after? after = this::tail. after::next::prev = item. item::next = after::next::prev. item::prev = after. after::next = item. count++. ). $::remove < %({&this after: Listable(T)*?} Listable(T)*? -> after == list::tail? $=nil. item: Listable(T) = !after? list::head : after::next. item == list::tail? list::tail = item::next. item == list::head? list::head = item::next. item::next::prev = after. after::next = item::next. item::prev = nil. item::next = nil. item). ;; whatever else like find, etc.).[[$]] main.$i::item)}::decompose!}}. )}. ;; destructor autocalled0).
Dominic Moore
I won't make a bad argument for 0-indexing when Dijkstra has done it better: cs.utexas.edu
Jeremiah Gonzalez
There was nothing wrong with str treated as utf8 like in C and Linux.
.format() was backported.
Integer division being special-cased to change the type is not sensible.
xrange() and .iteritems() were fine.
Unpacking should be avoided when possible as it leads to unreadable code.
Available in 2.7 via mypy.
print() was backported.
Bikeshed.
James Flores
>>> print("café"[3])�
That's not what I meant. This is what I meant:
>>> f"x = {3}"'x = 3'
It is in a dynamically typed language. Maybe it would even be sensible in some statically typed languages. When you divide numbers it's usually much more important whether the result gets rounded or not than whether the types get preserved. / and // is a much better way to categorize what should be done than float and int.
That kind of feature duplication is bad, especially if the most obvious version is very inefficient. dict_items also has a much better repr.
In a less pleasant way.
"class Foo:" is better than "class Foo(object):". It's not a big deal but it is an improvement. Small improvements add up.