Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Mike == Mike Meyer [EMAIL PROTECTED] writes: Mike IPython's pysh seems a little clumsy for interactive use, as Mike it requires special characters to distinguish between Mike commands to be passed to the shell and commands to be passed Mike to the scripting language. This should be contrasted with What do you mean by the commands to be passed to the shell? Commands on the path (the normal situation in Unix) can be executed directly just like in bash et al. Ditto for magic functions if automagic is on. I only use ! for calling commands that are in the current directory. A *real* deficiency with ipython/pysh under Linux is the lack of job control (in the sense that ^z suspends the whole ipython). I don't see why pysh would not be able to match and exceed the capabilities of shell in job control as well. It's not a priority for fperez himself ATM, but we'll see how easy it is to add shellish job control in the future after the refactoring... Mike I'll say it again - if you're arguing about which language Mike to use, you're arguing about the wrong thing. In a sense C is the native language of Unix and Windows (system calls are in C). It might make sense to expose the OS as Python objects. I work w/ Symbian OS in my day job, with the OS API in C++. I'm not sure whether it's a good idea or not, but at least some people are doing it :). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Mike == Mike Meyer [EMAIL PROTECTED] writes: Mike I've actually done some work on using CORBA as a COM for Mike Unix (or, as I think of it, an ARexx for Unix). After being Mike exposed to Plan 9, I've decided that's a better Mike solution. CORBA has the advantage that you can work on it Mike without getting buy-in from kernel vendors. The problem w/ CORBA is the alleged lack of speed. ISTR there was lots of controversy w/ the way Gnome used CORBA (Bonobo) and how it was too slow for Desktop apps. I don't know what the current status is - CORBA has always seemed more than fast enough for me. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Ville Vainio [EMAIL PROTECTED] writes: Mike == Mike Meyer [EMAIL PROTECTED] writes: Mike IPython's pysh seems a little clumsy for interactive use, as Mike it requires special characters to distinguish between Mike commands to be passed to the shell and commands to be passed Mike to the scripting language. This should be contrasted with What do you mean by the commands to be passed to the shell? Commands on the path (the normal situation in Unix) can be executed directly just like in bash et al. Ditto for magic functions if automagic is on. Ok, I missed that. My bad. Mike I'll say it again - if you're arguing about which language Mike to use, you're arguing about the wrong thing. In a sense C is the native language of Unix and Windows (system calls are in C). It might make sense to expose the OS as Python objects. Ugh. It would make more sense to expose it as (say) CORBA objects, so you aren't tied to a specific language. Following the Plan 9 approach and exposing it as a file system would probably require more work, but would allow more flexibility. Then again, both approaches get you into a recursion when you start trying to expose the facilities that are used by the exposing infrastructure. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Mike Meyer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Arich Chanachai [EMAIL PROTECTED] writes: When the CLR is integrated, it will allow a wide array of problem solving choices for uuu users. You've missed the point. Allowing a wide array of problem solving choices is a goal, not a means. Instead of concentrating on adding langauges, you should be provding an infrastructure that makes adding langauges simple. The Plan 9 example does this best, as any language that can do file I/O is supported. This discussion collides quite nicely with two of the more quoted articles on software development: http://primates.ximian.com/~miguel/bongo-bong.html http://www.jwz.org/doc/groupware.html The first of which eventually addresses the issue of how programs communicate with the operating system services and each other, although I'm sure I've seen a more succinct overview from Mr De Icaza on that subject. The second brings up the topic of making things enterprise-ready - probably one of the more popular motivations for introducing something like the CLR into a project which doesn't necessarily need it and isn't yet familiar with it. From what I've seen of Unununium, the motivation for using Python seems to stem from the way Python's runtime system provides services which overlap with those of an operating system; programs can dynamically import code, inspect the properties of such code, and invoke such code reasonably safely (as opposed to the jump to this memory address model of lower-level runtime systems), although these features are not unique to Python - the Erlang runtime system is apparently designed for use at this level, and the Java environment (and presumably the CLR) provides introspection and dynamic loading capabilities. I would also imagine that the development of Lisp operating systems and environments was similarly motivated. In contrast, the standard UNIX model of interprocess communication and introspection, extended substantially by Plan 9 and more conservatively by modern UNIX variants, is said to leave something to be desired, and those wishing more informative details about the interfaces exposed by programs and services usually end up putting something more complicated on top - see the emergence of Bonobo, DCOP and D-BUS. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Donn == Donn Cave [EMAIL PROTECTED] writes:
Donn I don't know what the Windows version is like, but for all
Donn the UNIX shell's weaknesses, it's very well suited to its
Donn role. The Plan 9
I don't know about that - I don't see anything in shell that couldn't
be done better in Python (well, launching subshells perhaps, and the
smaller size == faster launch). The Windows incarnation is obviously
so horrible that it hardly deserves mention, but the scripts done with
unix shell also always have this hackish flavour.
(I'm aware that this is an unpopular opinion that is likely to collect
some flames, but some people never learn ;-).
Donn shell (rc) is similar with much improved syntax, and has a
Donn distant relative es that I think is the closest thing I've
Donn ever seen to a 1st class language that works as a shell
I assume you've tried IPython ('ipython -p pysh')? I just apt-getted
es and it seems to be like ipython, only for scheme.
Donn Well, honestly I think that's stretching it. Your order
Donn issue here seems to apply only to operators, and they don't
Donn really figure that heavily in the kinds of things we
Donn normally do with the OS. The only
I think they do - summing sets of files, adding extensions to
filenames, etc.
Donn Now, we Python users know very well that's not true, Python's as clear
Donn as could be. But theoretically, if you wanted to talk about order
Donn issues, for example ... is it really easier to understand when a
language
Donn sometimes expresses a function f over x and y this way
Donn f(x, y)
Donn sometimes this way (+ is a function, really)
Donn x f y
Donn and sometimes this way
Donn x.f(y)
Donn ?
Yes - operators like + and - are very intuitive to everybody. Having
only one way to call functions is more orthogonal and cleaner in a
theoretical sense, but noi in practical sense.
Donn I don't know, I'm just thinking that while Python's notation
Donn might be just fine for people who've gotten here the way
Donn most of us have, it's not obvious from this that it's just
Donn fine 4 everyone.
Perhaps not for everyone but for the majority I guess the python
notation would be more suitable.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Nick Coghlan [EMAIL PROTECTED] writes: Mike Meyer wrote: Arich Chanachai [EMAIL PROTECTED] writes: Mike Meyer wrote: Whatever the intentions may be, the *act* is one of dictation. Since the point of the underlying OS is to increase the interconnections between applications (assuming I've found the correct web page and interpreted it correctly), the underlying architecture should be language-neutral. That allows as many applications as possible to play in the environment. *Allowing* other languages is one thing, but that shouldn't preclude having a 'default' language. On other OS's, the default language is some form of shell scripting (i.e. Unix shell scripts, or Windows batch files). It would be good to have a real language to fill that role. Um - I'd say Unix has no default language. Traditional Eunices come with a nice selection of languages (sh, awk, sed, C), and modern ones include more (C++, Perl, Python, Ruby, Lua). Tagging one as the default does a disservice to the other languages, and to the OS as a whole. For that matter, I'd say that these days the default on Windows is VB, unless there are hooks to talk to COM from batch files, since COM is the standard scripting mechanism on Windows. Note that by providing a scripting mechanism instead of a scripting language, you can script applications with Python as or more easily than you can script them with the MS provided solution of VB. You've missed the point. Allowing a wide array of problem solving choices is a goal, not a means. Instead of concentrating on adding langauges, you should be provding an infrastructure that makes adding langauges simple. The Plan 9 example does this best, as any language that can do file I/O is supported. Still, the builtin shell is going to need *some* form of scripting support. And if that looks like IPython's shell mode, so much the better. Scripting support shouldn't look like a language, it should look like a mechanism for hooking languages up to the system being scripted. Shells are a particularly easy hookup, as they have only three types of objects to deal with - commands, command results, and text streams. Any language which lets you invoke commands and manipulate the results of those commands and text streams is sufficient for shell scripting. IPython's pysh seems a little clumsy for interactive use, as it requires special characters to distinguish between commands to be passed to the shell and commands to be passed to the scripting language. This should be contrasted with languages designed for working in a command environment, like Rexx, sh and rc. Anyway, the reason to prefer Python to LISP for something like this, is that Python reads much more naturally for most people, whereas LISP requires that you write things 'out of order'. I'll say it again - if you're arguing about which language to use, you're arguing about the wrong thing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
[EMAIL PROTECTED] (Paul Boddie) writes: Mike Meyer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Arich Chanachai [EMAIL PROTECTED] writes: When the CLR is integrated, it will allow a wide array of problem solving choices for uuu users. You've missed the point. Allowing a wide array of problem solving choices is a goal, not a means. Instead of concentrating on adding langauges, you should be provding an infrastructure that makes adding langauges simple. The Plan 9 example does this best, as any language that can do file I/O is supported. This discussion collides quite nicely with two of the more quoted articles on software development: http://primates.ximian.com/~miguel/bongo-bong.html I've actually done some work on using CORBA as a COM for Unix (or, as I think of it, an ARexx for Unix). After being exposed to Plan 9, I've decided that's a better solution. CORBA has the advantage that you can work on it without getting buy-in from kernel vendors. In contrast, the standard UNIX model of interprocess communication and introspection, extended substantially by Plan 9 and more conservatively by modern UNIX variants, is said to leave something to be desired, and those wishing more informative details about the interfaces exposed by programs and services usually end up putting something more complicated on top - see the emergence of Bonobo, DCOP and D-BUS. The crucial question isn't whether the underlying mechanism is complete, but whether it's sufficient. The underlying Unix facilities provide byte streams - because that's what Unix does. What that leaves to be desired is a standard high-level way for applications to interact with each other, passing back and forth things that are more complicated than byte streams. Having standars for these high-level objects allows for code reuse and data sharing. This is a good thing, and there's nothing inherently wrong with doing things this way. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Mike Meyer wrote: Arich Chanachai [EMAIL PROTECTED] writes: Mike Meyer wrote: Whatever the intentions may be, the *act* is one of dictation. Since the point of the underlying OS is to increase the interconnections between applications (assuming I've found the correct web page and interpreted it correctly), the underlying architecture should be language-neutral. That allows as many applications as possible to play in the environment. *Allowing* other languages is one thing, but that shouldn't preclude having a 'default' language. On other OS's, the default language is some form of shell scripting (i.e. Unix shell scripts, or Windows batch files). It would be good to have a real language to fill that role. You've missed the point. Allowing a wide array of problem solving choices is a goal, not a means. Instead of concentrating on adding langauges, you should be provding an infrastructure that makes adding langauges simple. The Plan 9 example does this best, as any language that can do file I/O is supported. Still, the builtin shell is going to need *some* form of scripting support. And if that looks like IPython's shell mode, so much the better. Anyway, the reason to prefer Python to LISP for something like this, is that Python reads much more naturally for most people, whereas LISP requires that you write things 'out of order'. Compare out-of-the-box Python: a = 1 + 2 + 3 + 4 And out-of-the-box Lisp: (setq a (+ 1 2 3 4)) Which language has the lower barrier for entry? That should be a fairly important consideration for a language that is going to sit at the heart of an OS. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Compare out-of-the-box Python: a = 1 + 2 + 3 + 4 And out-of-the-box Lisp: (setq a (+ 1 2 3 4)) Which language has the lower barrier for entry? That should be a fairly important consideration for a language that is going to sit at the heart of an OS. Huh? Why does mucking about in the heart of an OS need a low barrier of entry? It doesn't. I was looking at it from the point of view of *scripting* the OS - which *should* have a low barrier for entry :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Quoth Nick Coghlan [EMAIL PROTECTED]: [... re Python OS interface vs. language-generic model ] | *Allowing* other languages is one thing, but that shouldn't preclude having a | 'default' language. On other OS's, the default language is some form of shell | scripting (i.e. Unix shell scripts, or Windows batch files). It would be good to | have a real language to fill that role. I don't know what the Windows version is like, but for all the UNIX shell's weaknesses, it's very well suited to its role. The Plan 9 shell (rc) is similar with much improved syntax, and has a distant relative es that I think is the closest thing I've ever seen to a 1st class language that works as a shell (though the implementation was only at the proof of concept level.) (I'm not forgetting REXX, it's a fairly respectable effort but not 1st class.) ... | Still, the builtin shell is going to need *some* form of scripting support. An | if that looks like IPython's shell mode, so much the better. | | Anyway, the reason to prefer Python to LISP for something like this, is that | Python reads much more naturally for most people, whereas LISP requires that y | write things 'out of order'. | | Compare out-of-the-box Python: |a = 1 + 2 + 3 + 4 | | And out-of-the-box Lisp: |(setq a (+ 1 2 3 4)) | | Which language has the lower barrier for entry? That should be a fairly | important consideration for a language that is going to sit at the heart of an OS. Well, honestly I think that's stretching it. Your order issue here seems to apply only to operators, and they don't really figure that heavily in the kinds of things we normally do with the OS. The only operator I can think of in rc is ^, an odd sort of string multiplication thing, and I can't think of any in the original Bourne shell. Meanwhile, the idea that barriers to entry are built out of things like + 1 2 3 4 vs. 1 + 2 + 3 + 4 is really quite open to question. 10 years ago when BeOS was a little hotter than it is today, there were a couple enthusiasts pushing Python as an official language. A few of the people following BeOS at that point had come from a strong Amiga background, and I remember one of them arguing vehemently against Python because its arcane, complicated syntax was totally unsuited to casual use. Compared to, say, REXX. Now, we Python users know very well that's not true, Python's as clear as could be. But theoretically, if you wanted to talk about order issues, for example ... is it really easier to understand when a language sometimes expresses a function f over x and y this way f(x, y) sometimes this way (+ is a function, really) x f y and sometimes this way x.f(y) ? I don't know, I'm just thinking that while Python's notation might be just fine for people who've gotten here the way most of us have, it's not obvious from this that it's just fine 4 everyone. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Arich Chanachai [EMAIL PROTECTED] writes: Mike Meyer wrote: Whatever the intentions may be, the *act* is one of dictation. Since the point of the underlying OS is to increase the interconnections between applications (assuming I've found the correct web page and interpreted it correctly), the underlying architecture should be language-neutral. That allows as many applications as possible to play in the environment. When the CLR is integrated, it will allow a wide array of problem solving choices for uuu users. You've missed the point. Allowing a wide array of problem solving choices is a goal, not a means. Instead of concentrating on adding langauges, you should be provding an infrastructure that makes adding langauges simple. The Plan 9 example does this best, as any language that can do file I/O is supported. It may be that CLR is just such an infrastructure (I'm not familiar with it). In that case, instead of pushing Python, you should be pushing CLR with IronPython as an option. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
pythonUser_07 wrote: Some quick thoughts. 1- Python is not new relatively speaking. Quite true, good point. 2)- Python is a natural language for learning basic scripting, but can carry you through to object oriented program. 3)- Knowing python, instantly gets you access to jython. I've found jython incredibly helpful in learning java. Finally, jython seems to be the defacto test scripting language for java. Cheers. These last two points kind of diverge from the point, no? What I mean is that we want to present the argument of why Python is the best choice as THE built-in programming language for the revolutionary uuu operating system. Unless Java becomes built-in, the ability to transition from Python to Jython isn't pertinent info when talking about the uuu project. The idea is to have an easily maintainable (hence readable) OS core of functionality built with Python and to support advanced yet clean and simple modules which can run on the OS with support from the ground-up. On the other hand, are you suggesting against Python in favor of Java? - Arich -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
I see your point. Consider points 2 and 3 a nice side effect. The language I favor actually ties into the environment I am working in: Python for rapid prototyping, java for larger projects where the eclipse IDE comes in very handy. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Arich Chanachai [EMAIL PROTECTED] writes: These last two points kind of diverge from the point, no? What I mean is that we want to present the argument of why Python is the best choice as THE built-in programming language for the revolutionary uuu operating system. A new operating system shouldn't be picking THE built-in programming language. It should instead be providing mechanisms to allow arbitrary programming languages to be used wherever they are required. Tying the users of the OS - or of some application - down to a specific language is a disservice to the developers and users of that OS or application. While Python is an excellent language, and has a nice implementation for embedding/extending applications, it's not necessarily the best choice for all problems. You're be doing much better for your users to allow them to choose the right language for the problem than to dictate the language that has to be used. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Mike Meyer wrote: Arich Chanachai [EMAIL PROTECTED] writes: These last two points kind of diverge from the point, no? What I mean is that we want to present the argument of why Python is the best choice as THE built-in programming language for the revolutionary uuu operating system. A new operating system shouldn't be picking THE built-in programming language. It should instead be providing mechanisms to allow arbitrary programming languages to be used wherever they are required. Tying the users of the OS - or of some application - down to a specific language is a disservice to the developers and users of that OS or application. While Python is an excellent language, and has a nice implementation for embedding/extending applications, it's not necessarily the best choice for all problems. You're be doing much better for your users to allow them to choose the right language for the problem than to dictate the language that has to be used. mike There is no intention to dictate, but instead to provide out-of-the-box, built-into-the-architecture support for a single language or a wide array of languages. For now, this will begin with a single language and the question is merely which one. Python has been chosen, but some would argue that others are a better choice, such as Lisp. In the future, or whenever someone steps up to the plate, support for the CLR will be implemented, thus broadening the array of integrally supported programming languages (i.e IronPython, Boo, and so forth). -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Arich Chanachai [EMAIL PROTECTED] writes: Mike Meyer wrote: Arich Chanachai [EMAIL PROTECTED] writes: These last two points kind of diverge from the point, no? What I mean is that we want to present the argument of why Python is the best choice as THE built-in programming language for the revolutionary uuu operating system. A new operating system shouldn't be picking THE built-in programming language. It should instead be providing mechanisms to allow arbitrary programming languages to be used wherever they are required. Tying the users of the OS - or of some application - down to a specific language is a disservice to the developers and users of that OS or application. While Python is an excellent language, and has a nice implementation for embedding/extending applications, it's not necessarily the best choice for all problems. You're be doing much better for your users to allow them to choose the right language for the problem than to dictate the language that has to be used. There is no intention to dictate, but instead to provide out-of-the-box, built-into-the-architecture support for a single language or a wide array of languages. For now, this will begin with a single language and the question is merely which one. Whatever the intentions may be, the *act* is one of dictation. Since the point of the underlying OS is to increase the interconnections between applications (assuming I've found the correct web page and interpreted it correctly), the underlying architecture should be language-neutral. That allows as many applications as possible to play in the environment. I did this with CORBA (see http://www.mired.org/home/mwm/scripting/ ) just to show that Unix can play in this arena as well as various desktop OS's. Plan 9 provides a much better mechanism that allows any programming language that can do file I/O to be used for building interconnections. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Mike Meyer wrote: Arich Chanachai [EMAIL PROTECTED] writes: Mike Meyer wrote: Arich Chanachai [EMAIL PROTECTED] writes: These last two points kind of diverge from the point, no? What I mean is that we want to present the argument of why Python is the best choice as THE built-in programming language for the revolutionary uuu operating system. A new operating system shouldn't be picking THE built-in programming language. It should instead be providing mechanisms to allow arbitrary programming languages to be used wherever they are required. Tying the users of the OS - or of some application - down to a specific language is a disservice to the developers and users of that OS or application. While Python is an excellent language, and has a nice implementation for embedding/extending applications, it's not necessarily the best choice for all problems. You're be doing much better for your users to allow them to choose the right language for the problem than to dictate the language that has to be used. There is no intention to dictate, but instead to provide out-of-the-box, built-into-the-architecture support for a single language or a wide array of languages. For now, this will begin with a single language and the question is merely which one. Whatever the intentions may be, the *act* is one of dictation. Since the point of the underlying OS is to increase the interconnections between applications (assuming I've found the correct web page and interpreted it correctly), the underlying architecture should be language-neutral. That allows as many applications as possible to play in the environment. I did this with CORBA (see http://www.mired.org/home/mwm/scripting/ ) just to show that Unix can play in this arena as well as various desktop OS's. Plan 9 provides a much better mechanism that allows any programming language that can do file I/O to be used for building interconnections. mike When the CLR is integrated, it will allow a wide array of problem solving choices for uuu users. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Fwd: Re: [Uuu-devel] languages] -- Why Python
Arich == Arich Chanachai [EMAIL PROTECTED] writes: Arich From: Richard Taytor [EMAIL PROTECTED] Arich To: [EMAIL PROTECTED] Arich Sent: Thursday, February 17, 2005 4:28 PM Arich Subject: [Uuu-devel] languages First, thank you for Unununium. I first learned of the project years ago and I'm happy to see it is alive and well. I'm curious: For the same reasons cited for using Python, why not use Lisp? I understand that Python is more popular/pervasive, but if reducing the cognitive load on the programmers, increasing the elegance and efficiency between programmer and code, c., is of primary concern, Lisp (or as mentioned in the documentation, creating a new language) seems a better choice (as it appears to me). What do you think? Essentially this seems like advocacy material for Lisp (doesn't seem to address any UUU-specific issues, just claims that Lisp is better than Python), and should be treated as such. Go googling for heaps of Python vs. Lisp material. Go ahead and learn Lisp - I guess you'll quickly realize that perfectly rational people may well choose Python for reasons other than not knowing Lisp. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
