Using the Python Interpreter as a Reference

[Steven D'Aprano]

On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:

> Personally, I find a lot of good things in Python. I thinking tabs are
> out-of-date. Even the MAKE community wishes that the need for tabs would
> go away and many implementations have done just that.

Tabs have every theoretical advantage and only one practical 
disadvantage: the common toolsets used by Unix programmers are crap in 
their handling of tabs, and instead of fixing the toolsets, they blame 
the tabs.

The use of spaces as indentation is a clear case of a technically worse 
solution winning over a better solution.


> I have been
> seriously debating about whether to force a specific number of spaces,
> such as the classic 4, but I am not sure yet. Some times, 2 or even 8
> spaces is appropriate (although I'm not sure when).

Why on earth should your language dictate the width of an indentation? I 
can understand that you might care that indents are consistent within a 
single source code unit (a file?), but anything more than that is just 
obnoxious.


> I have always found the standard library for Python to be disjoint. That
> can be really beneficial where it keeps the learning curve down and the
> size of the standard modules down. At the same time, it means
> re-learning whenever you use a new module.

I know what disjoint means, but I don't understand what you think it 
means for a software library to be disjoint. I don't understand the rest 
of the paragraph.


> My language combines generators and collection initializers, instead of
> creating a whole new syntax for comprehensions.
> 
> [| for i in 0..10: for j in 0.10: yield return i * j |]

Are we supposed to intuit what that means? 

Is | a token, or are the delimiters [| and |] ? 

Is there a difference between iterating over 0..10 and iterating over 
what looks like a float 0.10? 

What is "yield return"?


> Lambdas and functions are the same thing in my language, so no need for
> a special keyword.

That does not follow. Lambdas and def functions are the same thing in 
Python, but Python requires a special keyword.


> I also distinguish between initialization and
> assignment via the let keyword.

What does this mean? I can guess, but I might guess wrong.


> Also, non-locals do not need to be
> defined explicitly, since the scoping rules in Unit are far more "anal".

What does this mean? I can't even guess what you consider more anal 
scoping rules.


> In reality though, it takes a certain level of arrogance to assume that
> any language will turn out without bumps. It is like I was told in
> college long ago, "Only the smallest programs are bug free." I think the
> same thing could be said for a language. The only language without flaws
> would be so small that it would be useless.

I'm pretty sure that being so small that it is useless would count as a 
flaw.

What does it mean to say that a language is "small"?

A Turing Machine is a pretty small language, with only a few 
instructions: step forward, step backwards, erase a cell, write a cell, 
branch on the state of the cell. And yet anything that can be computed, 
anything at all, can be computed by a Turning Machine: a Turing Machine 
can do anything you can do in C, Lisp, Fortran, Python, Java... and very 
probably anything you can (mentally) do, full stop. So what does that 
mean about "small" languages?

On the other hand, take Epigram, a functional programming language:

http://en.wikipedia.org/wiki/Epigram_(programming_language)

It is *less* powerful than a Turing Machine, despite being far more 
complex. Similarly languages like regular expressions, finite automata 
and context-free grammers are more complex, "bigger", possibly with 
dozens or hundreds of instructions, and yet less powerful. Likewise for 
spreadsheets without cycles.

Forth is much smaller than Java, but I would say that Forth is much, much 
more powerful in some sense than Java. You could write a Java compiler in 
Forth more easily than you could write a Forth compiler in Java.



-- 
Steven