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 -- https://mail.python.org/mailman/listinfo/python-list
