On Sun, 10 Dec 2006 03:37:26 +0000, Kirk Sluder wrote:
>> But at least you know that foolib is a module or package. You know what
>> from and import do, and that can't change. And you know that bar is an
>> object with a method also called bar, it is being called, and the
>> argument is a string "somefile". Those things can't change. Imagine a
>> hypothetical language where those two lines could mean *anything*.
>
> But as was pointed out earlier in the thread, those keywords can be
> overshadowed by custom functions in python as well.
Really?
>>> def import():
File "<stdin>", line 1
def import():
^
SyntaxError: invalid syntax
Nope, can't shadow or change keywords. (And yes, the error message could
be better.)
> The only reason
> that we don't assume those two python lines could mean *anything* is
> because those mechanisms are not well advertised, and most people
> don't have a need to shadow "import."
Or because they can't mean just anything.
> Of course, it is possible to abstract away all of the lisp in such a
> way that you have a completely new programming language. But is this
> really a problem? Perl5 and bash are abstractions of C. Python has
> been implemented on both C and java, and chunks of perl6 have been
> implemented on top of Haskell.
That depends. If somebody smart is designing a new programming language,
then no, you get a new programming language.
If somebody not-so-smart is merely hammering the round peg of Lisp into
the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
that will be a problem. But apparently, despite the talk of using macros
to implement anything in Lisp, nobody actually does that.
>> My point isn't whether or not their claims are correct (a "couple" of
>> macros? really?) but that things like this feed the perception that Lisp
>> is close to that hypothetical language where anything could be anything.
>> If anything could be anything, do you really know what (+ 1 2) means
>> without reading every line of code?
>
> How do you know that operator has not been shadowed or overloaded in
> python?
Because the tokens 1 and 2 cannot be anything but ints, and + with two
int args cannot be anything but addition.
>> Or maybe it is only an advantage while Lisp programmers are a
>> self-selected group of above-average skill. Wait until fifty million VB
>> code monkeys start writing Lisp macros and maybe, just maybe, you'll wish
>> they were using a less powerful and more restrictive language.
>
> Perhaps it's because I'm a social scientist and not a programmer by
> training, but I find many arguments for *technical* solutions to
> *human performance* problems to be rather weak as a general
> practice. In some cases, using a very restrictive language may be
> the best solution for the problem.
I don't know about you, but I'm not talking about VERY restrictive
languages -- I'm using Python, which isn't very restrictive at all. But
even Lisp has some restrictions -- you can't jump to an arbitrary memory
location and treat whatever random bytes are there as executable code, can
you?
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
