Slices time complexity

[Steven D'Aprano]

On Tuesday 19 May 2015 17:12, Marko Rauhamaa wrote:

> Can you get Python without getting a language like C first? 

Yes.

There are a few senses in which C is very important to Python. Python was 
designed to be a glue language for interoperability with C libraries, so 
that's a very important sense, but in another way it is a trivial sense. You 
could replace C by any other language, or no language at all, and Python 
would still be more or less the same.

Another sense is that Python has borrowed some syntax and concepts from C, 
e.g. zero-based indexing, "continue" and "break" keywords, etc. But these 
are incidentals, the language would be mostly still the same if "continue" 
was spelled "next" in the Pascal tradition.

Python has been influenced by, and borrowed concepts from, a whole slew of 
languages, including Pascal, Algol, Modula 3, Icon, CLU, Lisp, Haskell, TCL, 
Smalltalk, ML, and especially ABC.

[...]
> Still, I don't like the dichotomy of boxed/unboxed values.

Distinguishing the two is important for mere reasons of implementation 
efficiency, but it makes the language semantics messy.


> Is a Python integer an "object" or a "value?" 

Why should that be a dichotomy?

Ints are values. Floats are values. Lists are values. Strings are values. 
Structs and records and union types and even functions are values. Why 
should objects not also be values?


> The Faithful have a surefire answer,
> but I think the key is: who cares? What matters is the effect of a
> program. If two metaphysical formulations of language semantics produce
> the same outcome, neither is objectively better than the other.

By outcome, do you mean the program's output? But the metaphysical 
formulation of the language is irrelevant to the program output. You can get 
the same output in Forth, Haskell, Prolog, C, Applescript or a Turing 
Machine, despite having radically different paradigms.

The outcome which matters is *usability*. Some paradigms are better suited 
to human understanding than others. Complexity and inconsistency is hard. A 
language where the rules for dealing with lists is different from those for 
floats will be harder to use than a language where they are both treated in 
the same way.

I'm not talking about the functionality available to each type -- obviously 
lists and floats use different syntax and different functionality. But if 
you wrote `$spam = alist` to assign a list, and `spam := $afloat` to assign 
a float, that would be bad. A consistent language paradigm is better than an 
inconsistent one. Think of Perl with its complicated rules that you have to 
memorize before you know whether to prefix a variable with a $ or a @ or 
whatever the sigils are.

-- 
Steve