Re: Thoughts on Guido's ITC audio interview
Stephen Toledo-Brown <[EMAIL PROTECTED]> writes: > I've not tried Mac, but under both Windows and Linux on x86, I find > Eclipse (3.0) is slow with less than 1.25 GB of RAM, reasonably fast > with 1.5GB or more. Processor speed and disk speed don't seem to be > anywhere near as important. I've used Eclipse on a 512mb laptop (1.5 ghz Pentium M) and it's been ok. I'm not sure what version. I'm not a Java fan. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Markus Wankus wrote: > > My opinion - If you aren't willing to try something new, or have an > aversion to it in the first place, nothing we can say will change your > mind. Correction... *There are some people, who* if they aren't willing to try something new, or have an aversion to it in the first place, nothing we can say will change their mind. M. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Stephen Toledo-Brown wrote: > Tony Meyer wrote: > >>> Everyone complaining about Eclipse in this thread needs to go try >>> 3.1. The interface is much much much more responsive. >> >> >> >> The problem with Eclipse, IMO, is Java. I've tried 3.1 on a WinXP >> machine >> and, like just about any Java program, it's incredibly slow and a real >> pain >> to use. On a (similarly spec'd) Mac OS X Tiger machine, it runs nice and >> smoothly and is reasonably nice to use. I'd happily recommend that Mac >> users try Eclipse, but never a Windows (Python) programmer. > > > I've not tried Mac, but under both Windows and Linux on x86, I find > Eclipse (3.0) is slow with less than 1.25 GB of RAM, reasonably fast > with 1.5GB or more. Processor speed and disk speed don't seem to be > anywhere near as important. I guess we all have different views on "slow". I have been using it to develop a full IDE in Eclipse for over 2 years (since 2.1), and I can't understand where you guys are coming from. I self-host (run a development Eclipse SDK, plus a Runtime - that's 2 Eclipse's running...sometimes 3) all day every day and it does admittedly get "slow", but only down when I am doing serious debugging (Eclipse debugging the internals of Eclipse). I only have 512MB RAM, and a wimpy 1.3 GHz Athlon on Windows. And BTW - if you used Eclipse seriously, you would know that Mac and Linux are inherently slower than Windows due to the SWT GUI library lagging performance-wise on those platforms (especially GTK on Linux), so I have no idea how you can resonably say that you would *never* recommend a Windows programmer to try Eclipse. Those types of performance claims are simply not true (beyond a 10 minute evaluation), and it's just plain silly to say Eclipse is not usable on Windows. My opinion - If you aren't willing to try something new, or have an aversion to it in the first place, nothing we can say will change your mind. As for me - I'll continue to enjoy the benefits of Eclipse's tools - especially with PyDev coming along the way it is. The ultimate would be for something like Jython or JPype to come to fruition so Eclipse plugins could be written in Python. Now *that* would be something. Actually, the *ultimate* would be to implement the equivalent of Eclipse in Python, but that is a pipe dream... ;o) Markus. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Tony Meyer wrote: >>Everyone complaining about Eclipse in this thread needs to go >>try 3.1. The interface is much much much more responsive. > > > The problem with Eclipse, IMO, is Java. I've tried 3.1 on a WinXP machine > and, like just about any Java program, it's incredibly slow and a real pain > to use. On a (similarly spec'd) Mac OS X Tiger machine, it runs nice and > smoothly and is reasonably nice to use. I'd happily recommend that Mac > users try Eclipse, but never a Windows (Python) programmer. I've not tried Mac, but under both Windows and Linux on x86, I find Eclipse (3.0) is slow with less than 1.25 GB of RAM, reasonably fast with 1.5GB or more. Processor speed and disk speed don't seem to be anywhere near as important. -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
> For me, performance is the minor issue. Usability is the major issue. If > find Eclipse to be highly unusable, so I don't use it. I find it to be the best option out there -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
Tony Meyer wrote: > It would be interesting to know which JRE the Eclipse advocates are > using, and which the people that dislike Eclipse are using... For me, performance is the minor issue. Usability is the major issue. If find Eclipse to be highly unusable, so I don't use it. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
> "Java" as a term means different things to different people, Agreed. Python is similar in this respect - it's common to refer to cPython here as Python, for example. > but I expect most would think of the core language and its > standard library first and the JRE/JVM second. So saying "the > problem of X is Java" when you really mean "the problem of X > in platform Y is Sun's JVM in Y" is kinda misleading. Obviously I wouldn't agree :) The discussion here is about Java from a user's POV, not a programmer (because we are using a Java application to program in Python), and from the user's POV, the JRE/JVM is what is important, not the language. Much the same as a programmer who is using an IDE written in Python to program in some other language would really only care about how the Python VM performs. > Disclaimer: I am neither Java's not Eclipse's advocate; I'll > choose python over Java any day, but let's put the blame > where it is due. If there isn't a good VM for the OS that the vast majority of computers use, then the language has a problem, IMO. Having a great language spec is one thing, but it's not really much use without a good implementation. It would be interesting to know which JRE the Eclipse advocates are using, and which the people that dislike Eclipse are using... =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
"Tony Meyer" <[EMAIL PROTECTED]> wrote: > > Your first sentence contradicts the rest of your post; how is > > Java the problem if it runs nice on a Mac and is sluggish on > > Windows ? > > Because any Java program on (any version of) Windows (in my experience) is > sluggish, and this is not true (again, in my experience) for Java programs > on a Mac. > > There is a vast difference between the various JREs; whereas every platform > I've used a cPython interpreter on has given reasonably constant performance > (which is to be expected, with a C implementation). "Java" as a term means different things to different people, but I expect most would think of the core language and its standard library first and the JRE/JVM second. So saying "the problem of X is Java" when you really mean "the problem of X in platform Y is Sun's JVM in Y" is kinda misleading. Disclaimer: I am neither Java's not Eclipse's advocate; I'll choose python over Java any day, but let's put the blame where it is due. George -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
> Your first sentence contradicts the rest of your post; how is > Java the problem if it runs nice on a Mac and is sluggish on > Windows ? Because any Java program on (any version of) Windows (in my experience) is sluggish, and this is not true (again, in my experience) for Java programs on a Mac. There is a vast difference between the various JREs; whereas every platform I've used a cPython interpreter on has given reasonably constant performance (which is to be expected, with a C implementation). > At best this may say something about the difference > in perfomance between the two JREs (assuming that most > Windows and Mac users of Eclipse have similar experience with yours). Which was my point. From what I've seen of this thread, people aren't saying which platform they are using Eclipse on - I have a suspicion that the JRE that people are using significantly effects the resulting opinion of Eclipse. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
"Tony Meyer" <[EMAIL PROTECTED]> wrote: > The problem with Eclipse, IMO, is Java. I've tried 3.1 on a WinXP machine > and, like just about any Java program, it's incredibly slow and a real pain > to use. On a (similarly spec'd) Mac OS X Tiger machine, it runs nice and > smoothly and is reasonably nice to use. I'd happily recommend that Mac > users try Eclipse, but never a Windows (Python) programmer. > > =Tony.Meyer Your first sentence contradicts the rest of your post; how is Java the problem if it runs nice on a Mac and is sluggish on Windows ? At best this may say something about the difference in perfomance between the two JREs (assuming that most Windows and Mac users of Eclipse have similar experience with yours). George -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
> Everyone complaining about Eclipse in this thread needs to go > try 3.1. The interface is much much much more responsive. The problem with Eclipse, IMO, is Java. I've tried 3.1 on a WinXP machine and, like just about any Java program, it's incredibly slow and a real pain to use. On a (similarly spec'd) Mac OS X Tiger machine, it runs nice and smoothly and is reasonably nice to use. I'd happily recommend that Mac users try Eclipse, but never a Windows (Python) programmer. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Joseph Garvin <[EMAIL PROTECTED]> writes: > Also, everyone keeps discussing Eclipse as something that gives Java a > leg up on Python. *Ahem* PyDev :) Which you should also give another > try if you haven't in a few versions. Easiest way to get a GUI > debugger for python. Can you give a brief description of what the Python debugger is like? Can it debug multi-threaded Python programs? IDLE has a rudimentary debugger that can be useful sometimes, but it wedges up when you exit from it, making its usefulness limited. > My only misgiving with Eclipse now is that I think development of > plugins for it is always going to be slower than for Emacs and other > editors because they have to be written in Java. I had thought that using the Python debugging interface for required writing C extensions. There's a mention in the Python cookbook of some C-only interface needed for cross-thread signalling. What's up with that? -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Everyone complaining about Eclipse in this thread needs to go try 3.1. The interface is much much much more responsive. Also, everyone keeps discussing Eclipse as something that gives Java a leg up on Python. *Ahem* PyDev :) Which you should also give another try if you haven't in a few versions. Easiest way to get a GUI debugger for python. My only misgiving with Eclipse now is that I think development of plugins for it is always going to be slower than for Emacs and other editors because they have to be written in Java. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
> "Fabio" == Fabio Zadrozny <[EMAIL PROTECTED]> writes: >> I agree about the project management part. Though I would still love >> to use Eclipse instead, if it only was supported for my line of work >> :-/. Fabio> What line of work is not supported in eclipse? C++ programming for Symbian OS. Editing the C++ code works, debugging doesn't, at least yet. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
D H <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Dave Benjamin wrote: > > Someone in the audience surprised everyone by mentioning an actual project > > attempting this, called javaclass: > > Sounds like it really is converting java classes to python classes, Yes, it is converting Java classes to Python classes at runtime using an import hook, in fact. > which are very different things. Lot of limitations mentioned such as: > "It runs on the Python runtime which does not have the security, > threading and just-in-time compiler features that people enjoy about > Java runtimes" The conversion done by javaclass relies on various limitations around the Java class model compared to its Python counterpart (eg. single vs. multiple inheritance), various things where the Python runtime is a lot less fussy about classes and objects than the Java runtime is (eg. the various low-level type-specific operations which can each be mapped to the same Python bytecode), but also upon the similarities that one would expect between any two mainstream virtual machines. Python virtual machine instructions are more general than many Java virtual machine instructions, but providing that the semantics are preserved this should/does make the hosting of Java code easier/possible. Things like security and just-in-time compilation are arguably orthogonal to replicating the semantics of most Java code, and since the Python runtime is more conservative about concurrency, threading becomes more of a performance/latency concern - again, an orthogonal issue. For the proposal of javaclass and similar schemes as usable tools, however, I would personally worry more about matching the exception handling and import semantics of the two language systems - those being things that have arisen as problems "on the ground". Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Ville Vainio wrote: >>"Timothy" == Delaney, Timothy (Tim) <[EMAIL PROTECTED]> writes: >> >> > >Timothy> Absolutely. I've really tried to use Eclipse - it's the >Timothy> standard editor for my current project (Java - blegh!). I >Timothy> *hate* it. It's huge, bulky, slow ... I've gone back to >Timothy> my text editor. I'm a hell of a lot more > >Have you tried the recently released 3.1 version? It seems to be a tad >snappier than the old version. > >Timothy> The only IDE I've ever actually liked using was >Timothy> Metrowerks CodeWarrior (on MacOS classic). Simple, >Timothy> unobtrusive. Good project management, without trying to >Timothy> control every aspect of the development process. And > >The debugger in CodeWarrior is quite crappy IMHO. Unlike visual >studio, it doesn't show the return values of function calls. The >editor is also quite lacking, without the ability to create macros >etc. > >I agree about the project management part. Though I would still love >to use Eclipse instead, if it only was supported for my line of work >:-/. > >Timothy> it allowed me to use the entire screen for editing if I >Timothy> wished whilst still having everything readily available. > >Eclipse allows this as well. ctrl+m is maximize/unmaximize. > > > What line of work is not supported in eclipse? -- Fabio Zadrozny -- Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
> "Timothy" == Delaney, Timothy (Tim) <[EMAIL PROTECTED]> writes: Timothy> Absolutely. I've really tried to use Eclipse - it's the Timothy> standard editor for my current project (Java - blegh!). I Timothy> *hate* it. It's huge, bulky, slow ... I've gone back to Timothy> my text editor. I'm a hell of a lot more Have you tried the recently released 3.1 version? It seems to be a tad snappier than the old version. Timothy> The only IDE I've ever actually liked using was Timothy> Metrowerks CodeWarrior (on MacOS classic). Simple, Timothy> unobtrusive. Good project management, without trying to Timothy> control every aspect of the development process. And The debugger in CodeWarrior is quite crappy IMHO. Unlike visual studio, it doesn't show the return values of function calls. The editor is also quite lacking, without the ability to create macros etc. I agree about the project management part. Though I would still love to use Eclipse instead, if it only was supported for my line of work :-/. Timothy> it allowed me to use the entire screen for editing if I Timothy> wished whilst still having everything readily available. Eclipse allows this as well. ctrl+m is maximize/unmaximize. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
In message <[EMAIL PROTECTED]>, Markus Wankus <[EMAIL PROTECTED]> writes >just think it is silly not to benefit from them. In which case you misunderstood me - I never said people should not use them, just that they should not be relied on for productivity improvements. They must factor in at a fraction of 1% of productivity. I don't really class improvements at that level as much to be shouted about :-) Stephen -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk/software.html Computer Consultancy, Software Development Windows C++, Java, Assembler, Performance Analysis, Troubleshooting -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Stephen Kellett wrote: > In message <[EMAIL PROTECTED]>, Markus Wankus > <[EMAIL PROTECTED]> writes > >> Have you ever tried anything that provides real, usable refactoring >> like Eclipse does with Java? I guarantee if you used it more than a >> few times your view would most likely change. > > > I was forced to use Eclipse recently. Dreadful. I really disliked it. I > never got as far as wanting to refactor things. I couldn't wait to stop > using it. > >> The fact is, code evolves. You simply cannot write high-quality >> software in one pass. > > > Total agreement. My point is that productivity gains from refactoring > tools are the least of your worries. Hiring good staff that know how to > write, test and debug software is very much more important than the > amount of time a refactoring tool will save. > > Stephen Well, I have been using it for 2 years now, and while I still prefer Python "big-time" to Java, I have really grown to love Eclipse. To each his own I guess. I agree you shouldn't bank on productivity gains from refactoring tools. And I agree they are definitely no kind of replacement for good people. I just think it is silly not to benefit from them. M. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
In message <[EMAIL PROTECTED]>, Markus Wankus <[EMAIL PROTECTED]> writes >Have you ever tried anything that provides real, usable refactoring >like Eclipse does with Java? I guarantee if you used it more than a >few times your view would most likely change. I was forced to use Eclipse recently. Dreadful. I really disliked it. I never got as far as wanting to refactor things. I couldn't wait to stop using it. >The fact is, code evolves. You simply cannot write high-quality >software in one pass. Total agreement. My point is that productivity gains from refactoring tools are the least of your worries. Hiring good staff that know how to write, test and debug software is very much more important than the amount of time a refactoring tool will save. Stephen -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk/software.html Computer Consultancy, Software Development Windows C++, Java, Assembler, Performance Analysis, Troubleshooting -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Stephen Kellett wrote: > In message <[EMAIL PROTECTED]>, Simon > Brunning <[EMAIL PROTECTED]> writes > >> Eclipse's refactorings are a great boon, I find. Refectoring is never >> *fully* automatic, of course, but the ability to, for example, select >> a chunk of code and have it extracted into a separate method with all >> needed arguments and the return value worked out for you is very >> helpful. All you have to do is give the new method a name. And this >> sort of thing can certainly improve readability. > > > This is not an attach on you Simon, but if people are relying on that > type of thing for increases in software productivity they are hiring the > wrong people. > > Stephen Have you ever tried anything that provides real, usable refactoring like Eclipse does with Java? I guarantee if you used it more than a few times your view would most likely change. The fact is, code evolves. You simply cannot write high-quality software in one pass. Good refactoring tools save time, and therefore money. I sure wouldn't hire anyone who thought otherwise... Markus. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Sakesun Roykiattisak wrote: > >> What's being ignored is that type information is useful for other things >> than compile type checking. The major case in point is the way IDEs >> such as IntelliJ and Eclipse use type information to do refactoring, code >> completion and eventually numerous other things. A Java programmer >> using IntelliJ or Eclipse can eliminate the advantage that Python >> used to have, and possibly even pull ahead. >> > 1. Automatic refactoring never solve the readability issue. True, but with the aid of automatic refactoring, you can make code more readable, by splitting up classes and functions, giving things better names, etc. Another readability issue in a similar vein is "intellisense" / context-sensitive menus. They allow you to give every class and method really long or confusing names without slowing you down, since you can just pick it from a menu. But I think this has some negative consequences. First, as you've stated, you still have to read the code. Second, you become reliant on these menus, rather than just "flowing". For instance, I almost never have to look up documentation for any of Python's list, dictionary, and string methods. They're short and simple, and they're easy to memorize. I think this is at least partially a consequence of the fact that people type them in, by hand, all the time, so they're designed to be friendly and memorable. > 2. I've never been lucky enough to have enough resource for those IDE. It's worth noting that IntelliJ IDEA has gotten rather slow and bulky with the more recent releases. It used to be pretty quick. Emacs, which was at one point considered a total resource hog, is lean and mean in comparison, and doesn't seem to be expanding much these days... =) Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Stephen Kellett wrote: > In message <[EMAIL PROTECTED]>, Simon > Brunning <[EMAIL PROTECTED]> writes > >> Eclipse's refactorings are a great boon, I find. Refectoring is never >> *fully* automatic, of course, but the ability to, for example, select >> a chunk of code and have it extracted into a separate method with all >> needed arguments and the return value worked out for you is very >> helpful. All you have to do is give the new method a name. And this >> sort of thing can certainly improve readability. > > This is not an attach on you Simon, but if people are relying on that > type of thing for increases in software productivity they are hiring the > wrong people. I think that the right people to hire are the ones that can make the best use of whatever tools are available so they can get their job done well and in a reasonable amount of time. I'm not a big fan of Java programming, but sometimes I have to do it, and when I do, I must say that the refactoring capabilities of IDEs like IntelliJ IDEA are very helpful. Being able to rename classes, variables and functions across multiple files, extract methods with automatic naming and typing of parameters and throws-clauses, and move methods from one class to another makes it so much easier to reorganize and improve large amounts of code. And due to Java's verbosity, there usually is a lot of code to manage even for simple changes. In Python, there's still a need to do these sorts of things. Typically, we use "search and replace" and "cut and paste" instead. You could make a similar statement about those tools - if you rely on "cut and paste" to increase your productivity... gah, it makes me cringe just writing that! Nonetheless, I would hate to program without "cut and paste" as a tool. In any language. The need for automatic refactoring tools in Python is smaller; Python gives you the opportunity to program at a higher level of abstraction, so there is less code to deal with. In addition, since Python doesn't have checked exceptions or require type annotation, design changes tend to "splatter" less across your code base. Still, Python's dynamic nature limits the sort of automatic changes you can make reliably, and we ought to recognize that. By using Python, we are making a tradeoff: in communicating less information, we are forcing IDEs to do more guesswork. Java requires less guesswork for the IDE, but requires significantly more communication on behalf of the programmer. I don't think it's a cut-and-dry win for either language. Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
In message <[EMAIL PROTECTED]>, Simon Brunning <[EMAIL PROTECTED]> writes >Eclipse's refactorings are a great boon, I find. Refectoring is never >*fully* automatic, of course, but the ability to, for example, select >a chunk of code and have it extracted into a separate method with all >needed arguments and the return value worked out for you is very >helpful. All you have to do is give the new method a name. And this >sort of thing can certainly improve readability. This is not an attach on you Simon, but if people are relying on that type of thing for increases in software productivity they are hiring the wrong people. Stephen -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk/software.html Computer Consultancy, Software Development Windows C++, Java, Assembler, Performance Analysis, Troubleshooting -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
On 6/27/05, Sakesun Roykiattisak <[EMAIL PROTECTED]> wrote: > 1. Automatic refactoring never solve the readability issue. Eclipse's refactorings are a great boon, I find. Refectoring is never *fully* automatic, of course, but the ability to, for example, select a chunk of code and have it extracted into a separate method with all needed arguments and the return value worked out for you is very helpful. All you have to do is give the new method a name. And this sort of thing can certainly improve readability. > 2. I've never been lucky enough to have enough resource for those IDE. Eclipse is indeed a memory hog of the first order. > 3. Python solve my problem. Mine too - but I'm not free to choose. -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
On 6/26/05, John Roth <[EMAIL PROTECTED]> wrote: > What's being ignored is that type information is useful for other things > than compile type checking. The major case in point is the way IDEs > such as IntelliJ and Eclipse use type information to do refactoring, code > completion and eventually numerous other things. A Java programmer > using IntelliJ or Eclipse can eliminate the advantage that Python > used to have, and possibly even pull ahead. I'm a Java programmer as my day job, most of the time, and I use Eclipse. I'm fairly proficient with it, but nevertheless I'm more productive with Python and SciTE than I am with Java and Eclipse. Eclipse helps a lot, true - I certainly wouldn't want to code Java without it or something like it - but it's not enought to pull ahead of Python's inherent superiority. -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Dave Benjamin wrote: > Guido gave a good, long interview, available at IT Conversations, as was > recently announced by Dr. Dobb's Python-URL! The audio clips are available > here: > > http://www.itconversations.com/shows/detail545.html > http://www.itconversations.com/shows/detail559.html Thanks for the links Dave. :-) He talked a fair amount on adding type checking to python. From reading his blog on that subject, it seems Guido is leaning towards having the types as part of function and method definitions via the 'as' and/or '->' operator in function and class argument definitions. My first thoughts on this was to do it by associating the types to the names. Limiting reassignment of a names to specific types would be a form of persistent name constraint that would serve as a dynamic type system. Has any form of "name constraints" been discussed or considered previously? Regards, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
In article <[EMAIL PROTECTED]>, Ivan Van Laningham <[EMAIL PROTECTED]> wrote: >Aahz wrote: >> >> Perhaps. But adding the time to learn those IDEs in addition to the time >> to learn Java is ridiculous. I've been forced to use Java a bit to >> support credit cards for our web application; I've got a friend whose >> Java-vs-Python argument hinges on the use of Eclipse; I was unable to >> make use of Eclipse in the time I had available for the project. > >Were there _good_ reasons not to do the credit card part of the web app >in Java instead of Python? As in, there is no secure module, or you >didn't have time, or Python doesn't support crucial APIs? I'm very >curious. The problem was that we needed to use a vendor-supplied library. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
Aahz wrote: > Perhaps. But adding the time to learn those IDEs in addition to the > time > to learn Java is ridiculous. I've been forced to use Java a bit to > support credit cards for our web application; I've got a friend whose > Java-vs-Python argument hinges on the use of Eclipse; I was unable to > make use of Eclipse in the time I had available for the project. Absolutely. I've really tried to use Eclipse - it's the standard editor for my current project (Java - blegh!). I *hate* it. It's huge, bulky, slow ... I've gone back to my text editor. I'm a hell of a lot more productive because the IDE isn't getting in my way. The only IDE I've ever actually liked using was Metrowerks CodeWarrior (on MacOS classic). Simple, unobtrusive. Good project management, without trying to control every aspect of the development process. And it allowed me to use the entire screen for editing if I wished whilst still having everything readily available. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Hi All-- Aahz wrote: > > Perhaps. But adding the time to learn those IDEs in addition to the time > to learn Java is ridiculous. I've been forced to use Java a bit to > support credit cards for our web application; I've got a friend whose > Java-vs-Python argument hinges on the use of Eclipse; I was unable to > make use of Eclipse in the time I had available for the project. > Were there _good_ reasons not to do the credit card part of the web app in Java instead of Python? As in, there is no secure module, or you didn't have time, or Python doesn't support crucial APIs? I'm very curious. > f u cn rd ths, u cn gt a gd jb n nx prgrmmng. > l tk t. Metta, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
In article <[EMAIL PROTECTED]>, John Roth <[EMAIL PROTECTED]> wrote: > >What's being ignored is that type information is useful for other >things than compile type checking. The major case in point is the >way IDEs such as IntelliJ and Eclipse use type information to do >refactoring, code completion and eventually numerous other things. A >Java programmer using IntelliJ or Eclipse can eliminate the advantage >that Python used to have, and possibly even pull ahead. Perhaps. But adding the time to learn those IDEs in addition to the time to learn Java is ridiculous. I've been forced to use Java a bit to support credit cards for our web application; I've got a friend whose Java-vs-Python argument hinges on the use of Eclipse; I was unable to make use of Eclipse in the time I had available for the project. Meanwhile, I'm busy with a code base that I doubt any IDE could handle... -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
>What's being ignored is that type information is useful for other things >than compile type checking. The major case in point is the way IDEs >such as IntelliJ and Eclipse use type information to do refactoring, code >completion and eventually numerous other things. A Java programmer >using IntelliJ or Eclipse can eliminate the advantage that Python >used to have, and possibly even pull ahead. > > 1. Automatic refactoring never solve the readability issue. 2. I've never been lucky enough to have enough resource for those IDE. 3. Python solve my problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Dave Benjamin wrote: > ... > I think Python's decision to use reference counting was an instance of > worse-is-better: at the time, reference counting was already known not to be > "the right thing", but it worked, and the implementation was simple. > Likewise with dynamic typing versus type inference. It seems that Guido > shares Alan Kay's viewpoint that type inference is really "the right thing", > but modern language technology is really not ready to make it mainstream, > whereas dynamic typing works today, and is arguably a better "worse" > solution than explicit/manifest static typing due to its verbosity. > > From the perspective of writing C extensions, Guido claims that the amount > of pain (regarding memory management) is about the same whether you're > extending a reference-counted language like CPython or a garbage collected > language like Java. Anyone with experience writing C extensions want to > comment on this? This is probably true for extensions written from scratch. From the point of view of connecting an existing block of code, Python made a great choice. If allocated memory doesn't need to move, and the garbage collector needn't get to _all_ the references in the system, the extension can make blocks of memory and include references to it in their own code, in their own format. They simply need to hold the objects in a Python-visible way. If the memory system needs to move allocated blocks, many data structures lose their efficiency in a haze of either adjusting and identifying references or indirection through piles of tables. One of the hard problems of talking "cross- language" has to do with "who is in charge of memory." Lots of languages are happy to allow interaction with another language as long as the other language is restricted to writing subroutines fitting the model of "the language really in charge." The fights are usually about memory allocation, non-standard flow of control, and intermediate data structures. C is easy to talk to because it was conceived as a "portable assembly language". Only straight assembler is easier to write language extensions in, because only assembly has less of a preconception of how memory is used and what code is and is not allowed to do. If you want to know pure hell, try to write a program that has significant code in both Smalltalk and Lisp (or even better, ML) in the same address space. They both want to be in charge, and you will quickly decide the best thing to do is put each language into its own process. > Type inferencing is especially difficult to add to a dynamically typed > language, and in general I think results are much better if you have type > inference from the very beginning (like ML and Haskell) rather than trying > to retrofit it later. Guido says that they've only been able to get it to > work reliably in Python with constants, which isn't very useful. Look at the Self language. That language has less of a surface concept of type than Python (classes are not defined). Still, Self was/is used as a platform to investigate type inferencing, code specialization, and native code generation. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote: > You are welcome to change the specifications of findall() and turn it into > an iterator which returns each match one at a time instead of all at once, > but then the name is misleading, wouldn't you agree? The regex module has since 2.2 a function (and method for regex objects) called finditer that does exactly that. Perhaps str (and unicode) should have it too for consistency ? George -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
On Sat, 25 Jun 2005 23:49:40 -0600, John Roth wrote: >>> What's being ignored is that type information is useful for other >>> things than compile type checking. The major case in point is the way >>> IDEs such as IntelliJ and Eclipse use type information to do >>> refactoring, code completion and eventually numerous other things. A >>> Java programmer using IntelliJ or Eclipse can eliminate the advantage >>> that Python used to have, and possibly even pull ahead. >> >> I haven't used IntelliJ or Eclipse, so I guess I'll have to take your >> word for how wonderful they are. > > You might want to look at something outside of Python. The world > changes, and if you keep your eyes closed, you might not notice it > changing until it rolls over you. If and when I have personal experience with either of these IDEs, I'll be sure to let you know if I disagree with you. But until then, since I have no reason to doubt what you say, and life is too short to check everything in the world, I will accept your opinion on IntelliJ and Eclipse. >> [snip] >>> I'll throw out one very simple example in the string library. The >>> index() and find() methods, and their variants, suffer from a bad case >>> of non-obviousness inherited from the C library. >> >> It must be an very bad case of non-obviousness indeed, because it isn't >> obvious to me at all what particular bit of non-obviousness it is that >> you are referring to. > > The result of find() cannot be used cleanly in an if statement; you need > to compare it to -1. This is not obvious to a novice, and is a fertile > source of mistakes. It's an irregularity that has to be checked for. Oh, that? It was obvious to me from the moment I understood that strings were indexed from 0, not 1. How else could it work? find() doesn't return a truth-value, it returns an index. You can't sensibly use that index where Python expects a truth-value, but then you also can't use it where Python expects a dict or a tuple or a function. I realised that in about 5 seconds, was disappointed that Python used 0-based indexing rather than 1-based, and got over it. I never once even tried passing the index returned by find() to if. Yes, a lot of novices make that mistake. Shame on them. I've made plenty of stupid mistakes in my time, and no doubt I will continue to do so. When I make a stupid mistake, I am ashamed at MY stupid mistake, and don't blame the language for my failures. (I have writen p = S.find(substr); if p >= -1: in error.) [snip] >> Am I the only one who has reservations about having to build a list of >> all the matches before doing anything with them? > > You don't have to build a list of all the matches. First, that's what > the maxfind parameter is all about, second, as I said below, it could be > implemented as an iterator. I'd expect that to happen if it was going to > be used in a for statement. Firstly, I've already noted that sometimes you can't predict before hand how many matches you need, so maxfind doesn't always help. And as for it being an iterator, I quote your specification for what findall should do: "findall returns a list (possibly a tuple) of the beginning index of each substring which matches sub. If there are no matches, an empty list is returned." Whether it is implemented as an iterator or not is irrelevant: it still has to package up all those yields and stick them in a list before returning that list. I believe there is a case for turning find() into an iterator. There might even be a good case to make for a function findall. But I think it is a terrible idea to replace find() with a function which "returns a list of the beginning index of each substring which matches". You are welcome to change the specifications of findall() and turn it into an iterator which returns each match one at a time instead of all at once, but then the name is misleading, wouldn't you agree? >>> This version works intuitively with if statements (an empty list is >>> false), goes directly into for statements, can be implemented as an >>> iterator, and is only less efficient by a constant (creation of the >>> list) if the maxfind parameter is used. It never throws an exception >>> (unless the parameter list has the wrong types). Its an example of a >>> method that can be used cleanly with a type inferencer, while the >>> index and find methods cannot. >> >> Er, how does that last one work? How can findall be used cleanly? Why >> can't find? > > findall() has a definite type: a list of integers, specifically a list > of integers > that are legitimate indexes into a specific string. Not according to your specification. It can also return an empty list. There are no legitimate indexes in an empty list. If your IDE or compiler or other tool can deal with that special case, why can't it deal with the special case of find returning -1? In any case, there is no such type as "legitimate indexes", and there can't be for arbitrary strings. In general, you don't kn
Re: Thoughts on Guido's ITC audio interview
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sat, 25 Jun 2005 19:31:20 -0600, John Roth wrote:
>
>>
>> "Dave Benjamin" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> Guido gave a good, long interview, available at IT Conversations, as was
>>> recently announced by Dr. Dobb's Python-URL! The audio clips are
>>> available
>>
>> [snip]
>>
>>> - Java: the usual static vs. dynamic, static analysis vs. unit testing
>>>arguments. Guido says that there's such a small amount of problems
>>> that
>>>can be caught at compile time, and even the smallest amount of unit
>>>testing would also catch these problems. "The blindness of that
>>> [static]
>>>position... escapes me."
>>
>> Three years ago, this was a viable arguement. Two years ago, it was
>> beginning to show difficulties. Today anyone who makes it can be
>> accused of having their head in the sand [1].
>>
>> What's being ignored is that type information is useful for other things
>> than compile type checking. The major case in point is the way IDEs
>> such as IntelliJ and Eclipse use type information to do refactoring, code
>> completion and eventually numerous other things. A Java programmer
>> using IntelliJ or Eclipse can eliminate the advantage that Python
>> used to have, and possibly even pull ahead.
>
> I haven't used IntelliJ or Eclipse, so I guess I'll have to take your word
> for how wonderful they are.
You might want to look at something outside of Python. The world
changes, and if you keep your eyes closed, you might not notice
it changing until it rolls over you.
> [snip]
>> I'll throw out one very simple example in the string library. The
>> index() and find() methods, and their variants, suffer from a bad case
>> of non-obviousness inherited from the C library.
>
> It must be an very bad case of non-obviousness indeed, because it isn't
> obvious to me at all what particular bit of non-obviousness it is that
> you are referring to.
The result of find() cannot be used cleanly in an if statement; you
need to compare it to -1. This is not obvious to a novice, and is
a fertile source of mistakes. It's an irregularity that has to be checked
for.
>
>> A very simple
>> replacement would fix this.
>>
>>
>>
>> findall([maxfind,] sub, [start, [end]])
>>
>> findall returns a list (possibly a tuple) of the beginning index of each
>> substring which matches sub. If there are no matches, an empty list is
>> returned. At most maxfind indexes are returned. start and end have the
>> same meaning as in the existing find and index methods.
>
> Am I the only one who has reservations about having to build a list of all
> the matches before doing anything with them?
You don't have to build a list of all the matches. First, that's what the
maxfind parameter is all about, second, as I said below, it could be
implemented as an iterator. I'd expect that to happen if it was going
to be used in a for statement.
>
> s = "a" * 1000 # 10 MB of data to search
> L = s.findall("a") # lots of matches means L is very large
>
> or imagine a more complex case where I have to programmatically change my
> search string as I go. I might not know how many matches I need until I
> have found them and can analyse the text around the match.
>
> Seems to me that rather than having to find all matches regardless of what
> you actually want, it would be better to turn find into a generator. Then
> findall becomes list(find) and you still have the flexibility of finding
> matches one at a time.
See below. I covered it.
>> This version works intuitively with if statements (an empty list is
>> false), goes directly into for statements, can be implemented as an
>> iterator, and is only less efficient by a constant (creation of the
>> list) if the maxfind parameter is used. It never throws an exception
>> (unless the parameter list has the wrong types). Its an example of a
>> method that can be used cleanly with a type inferencer, while the index
>> and find methods cannot.
>
> Er, how does that last one work? How can findall be used cleanly? Why
> can't find?
findall() has a definite type: a list of integers, specifically a list of
integers
that are legitimate indexes into a specific string. The result of find()
does
not have this property: it can be an integer that is an index into the
string,
or it can be a -1. Index can either return an index into the string, or it
can throw an exception. Both of these are complex result types that
hinder further type inference.
John Roth
>
>
> --
> Steven.
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
On Sat, 25 Jun 2005 19:31:20 -0600, John Roth wrote:
>
> "Dave Benjamin" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Guido gave a good, long interview, available at IT Conversations, as was
>> recently announced by Dr. Dobb's Python-URL! The audio clips are available
>
> [snip]
>
>> - Java: the usual static vs. dynamic, static analysis vs. unit testing
>>arguments. Guido says that there's such a small amount of problems that
>>can be caught at compile time, and even the smallest amount of unit
>>testing would also catch these problems. "The blindness of that
>> [static]
>>position... escapes me."
>
> Three years ago, this was a viable arguement. Two years ago, it was
> beginning to show difficulties. Today anyone who makes it can be
> accused of having their head in the sand [1].
>
> What's being ignored is that type information is useful for other things
> than compile type checking. The major case in point is the way IDEs
> such as IntelliJ and Eclipse use type information to do refactoring, code
> completion and eventually numerous other things. A Java programmer
> using IntelliJ or Eclipse can eliminate the advantage that Python
> used to have, and possibly even pull ahead.
I haven't used IntelliJ or Eclipse, so I guess I'll have to take your word
for how wonderful they are.
[snip]
> I'll throw out one very simple example in the string library. The
> index() and find() methods, and their variants, suffer from a bad case
> of non-obviousness inherited from the C library.
It must be an very bad case of non-obviousness indeed, because it isn't
obvious to me at all what particular bit of non-obviousness it is that
you are referring to.
> A very simple
> replacement would fix this.
>
>
>
> findall([maxfind,] sub, [start, [end]])
>
> findall returns a list (possibly a tuple) of the beginning index of each
> substring which matches sub. If there are no matches, an empty list is
> returned. At most maxfind indexes are returned. start and end have the
> same meaning as in the existing find and index methods.
Am I the only one who has reservations about having to build a list of all
the matches before doing anything with them?
s = "a" * 1000 # 10 MB of data to search
L = s.findall("a") # lots of matches means L is very large
or imagine a more complex case where I have to programmatically change my
search string as I go. I might not know how many matches I need until I
have found them and can analyse the text around the match.
Seems to me that rather than having to find all matches regardless of what
you actually want, it would be better to turn find into a generator. Then
findall becomes list(find) and you still have the flexibility of finding
matches one at a time.
> This version works intuitively with if statements (an empty list is
> false), goes directly into for statements, can be implemented as an
> iterator, and is only less efficient by a constant (creation of the
> list) if the maxfind parameter is used. It never throws an exception
> (unless the parameter list has the wrong types). Its an example of a
> method that can be used cleanly with a type inferencer, while the index
> and find methods cannot.
Er, how does that last one work? How can findall be used cleanly? Why
can't find?
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
Dave Benjamin wrote: > One thing Guido mentions in his comparison of ABC (Python's predecessor) and > Python is how ABC was inextricably tied to its environment (a la Smalltalk), What surprised me was that this was the only thing he really mentioned. He didn't mention anything about the theoretical underpinnings of ABC, he was only involved in the implementation of ABC, and others did all the language design. And his main criticism is a pragmatic issue with using the ABC in real tasks like reading external files. It explains why sometimes Python's features seem to be more implementation-driven rather than design-driven. Such as perhaps the use of self, but a counter-example is slicing syntax, borrowed from the language Icon apparently. I think when you borrow some features from a language but not all, you have to re-evaluate every part of the language design. Colons at the end of lines for example help readability in the ABC language because keywords are all uppercase (unlike python). So the colons in effect counteract some of the negative impact uppercase words place on readability. In Python however, I don't see how colons really are needed to help readability at all. And there are other issues too such as changing python to be case-insensitive or making 7/4 == 1.75 instead of 1 which even Guido wanted at one point ( http://www.linuxjournal.com/article/5028 ), but only the latter was implemented (yet not enabled by default yet). > I find that a similar comparison can be made between Python and Java. Java's > startup time is so long that it is not practical for writing small tools for > use in command-line scripts, and the propensity toward application servers > and integrated development environments suggests a strong preference for a > monolithic, self-contained, single-language environments. That's a very good point. Yeah you never hear of people using java for making quick little scripts, which python and php are really great for (among other things). > Guido makes a funny jab at Paul Graham about Graham's nine things that make > Lisp Lisp (available here: http://www.paulgraham.com/icad.html) - I had read > this essay many times but never saw the subtle irony behind claims of > "Greenspunning": in order to claim that a language is approaching Lisp, you > have to define what it is about Lisp that other languages are purportedly > emulating, and this begs the question of why you have the authority to > declare which 9 (or n) attributes of Lisp are most important. I like Paul > Graham and his essays a lot, but I must admit I had to laugh too when I > heard the way Guido framed this argument. I'm not so sure that Python has 8 > out of 9, though: the statement/expression dichotomy rules out #6, and the > lack of macros rules out #9. These are arguable, depending on how you define > things, but I think the most obvious thing that Python lacks compared with > Lisp and Scheme (and also Ruby) is a symbol type (#7). I'm in the process of > trying to understand what symbols are good for, outside the context of Lisp > and its nested lists of symbols as executable code. Ruby seems to have come > up with some creative uses for symbols within Python-like syntax, though I > haven't seen anything terribly compelling so far. Other python extensions and descendants I mentioned in this note are exploring the two main things lisp has but python doesn't - #6 eliminating the expression/statement distinction (at least in some cases like assignments), and #9 macros: http://groups-beta.google.com/group/comp.lang.python/msg/360c99b7ab7b839c?dmode=print&hl=en > - Java: the usual static vs. dynamic, static analysis vs. unit testing > arguments. Guido says that there's such a small amount of problems that > can be caught at compile time, and even the smallest amount of unit > testing would also catch these problems. "The blindness of that [static] > position... escapes me." As pointed out elsewhere, type declarations also help with documenting your code, as well as dramatically speeding up your program. > I think Python's decision to use reference counting was an instance of > worse-is-better: at the time, reference counting was already known not to be > "the right thing", but it worked, and the implementation was simple. > Likewise with dynamic typing versus type inference. It seems that Guido > shares Alan Kay's viewpoint that type inference is really "the right thing", > but modern language technology is really not ready to make it mainstream, > whereas dynamic typing works today, and is arguably a better "worse" > solution than explicit/manifest static typing due to its verbosity. That's very interesting. Type inference isn't always perfect though. There are some cases where it can't infer the type, or it infers the wrong type that you really want. Type inference + dynamic typing is a good combination that can speed up your code without slowing
Re: Thoughts on Guido's ITC audio interview
"Dave Benjamin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Guido gave a good, long interview, available at IT Conversations, as was > recently announced by Dr. Dobb's Python-URL! The audio clips are available [snip] > - Java: the usual static vs. dynamic, static analysis vs. unit testing >arguments. Guido says that there's such a small amount of problems that >can be caught at compile time, and even the smallest amount of unit >testing would also catch these problems. "The blindness of that > [static] >position... escapes me." Three years ago, this was a viable arguement. Two years ago, it was beginning to show difficulties. Today anyone who makes it can be accused of having their head in the sand [1]. What's being ignored is that type information is useful for other things than compile type checking. The major case in point is the way IDEs such as IntelliJ and Eclipse use type information to do refactoring, code completion and eventually numerous other things. A Java programmer using IntelliJ or Eclipse can eliminate the advantage that Python used to have, and possibly even pull ahead. The only thing that is even vaguely similar in the Python community is Bycycle Repair Man, and, to be brutal about it, it sucks in comparison with what either Eclipse or IntelliJ can do. I agree with Guido's point later in the interview that type inference is the way to go, and that it's very difficult to retrofit it to an existing language. Difficult does not mean impossible though. The place to start is to go through the standard objects and make sure all return values make sense. I'll throw out one very simple example in the string library. The index() and find() methods, and their variants, suffer from a bad case of non-obviousness inherited from the C library. A very simple replacement would fix this. findall([maxfind,] sub, [start, [end]]) findall returns a list (possibly a tuple) of the beginning index of each substring which matches sub. If there are no matches, an empty list is returned. At most maxfind indexes are returned. start and end have the same meaning as in the existing find and index methods. This version works intuitively with if statements (an empty list is false), goes directly into for statements, can be implemented as an iterator, and is only less efficient by a constant (creation of the list) if the maxfind parameter is used. It never throws an exception (unless the parameter list has the wrong types). Its an example of a method that can be used cleanly with a type inferencer, while the index and find methods cannot. [snip] John Roth [1] I'm well aware that ostritches do not stick their heads in the sand to avoid looking at distressing things, such as advancing predators. It is, however, a useful metaphor. > > Cheers, > Dave -- http://mail.python.org/mailman/listinfo/python-list
Thoughts on Guido's ITC audio interview
Guido gave a good, long interview, available at IT Conversations, as was recently announced by Dr. Dobb's Python-URL! The audio clips are available here: http://www.itconversations.com/shows/detail545.html http://www.itconversations.com/shows/detail559.html I'd like to comment on a few parts of that interview. One thing Guido mentions in his comparison of ABC (Python's predecessor) and Python is how ABC was inextricably tied to its environment (a la Smalltalk), where Python, though it supports an interactive mode, follows more of a UNIX-style "do one thing well" philosophy, and was designed to integrate with other tools rather than being a whole world to its own. I find that a similar comparison can be made between Python and Java. Java's startup time is so long that it is not practical for writing small tools for use in command-line scripts, and the propensity toward application servers and integrated development environments suggests a strong preference for a monolithic, self-contained, single-language environments. On the other hand, even though internally "there's only one way to do it" in Python, Python itself is one of many ways to develop software, and does not insist on being the one perfect way to do it. You can use whatever editor you like, and the language doesn't go out of its way to make it difficult to use other programs and processes, including the operating system if so desired. It is a bit ironic that, according to Guido, the command-line interpreter interface to Python was more of an afterthought, since my whole experience with Python has very much centered around the interpreter. Like many, I think, my first use for Python was as a calculator. =) In fact, since discovering Python, I've been very resistant toward learning any language that doesn't have an interpreter. Ruby, Scheme, OCaml and SML/NJ have been fun to learn because I can tinker with them at the command line. "perl -de 42" is rather frustrating to use, as is Haskell's "hugs" due to the inability to define new functions at the command line. Command-line interfaces are a great way to get up to speed on new languages and libraries. One of the advantages of Python is that it allows you to graft a CLI onto environments that weren't designed with one. For instance, Jython gives Java a command-line interface, and this makes working with Java much more tolerable since you can interact with libraries in real-time and learn how they behave at runtime. Likewise with PythonWin and COM scripting. I am glad to see that IronPython is designed with a command-line interpreter as well, should I ever need to learn my way around .NET in a hurry. Guido makes a funny jab at Paul Graham about Graham's nine things that make Lisp Lisp (available here: http://www.paulgraham.com/icad.html) - I had read this essay many times but never saw the subtle irony behind claims of "Greenspunning": in order to claim that a language is approaching Lisp, you have to define what it is about Lisp that other languages are purportedly emulating, and this begs the question of why you have the authority to declare which 9 (or n) attributes of Lisp are most important. I like Paul Graham and his essays a lot, but I must admit I had to laugh too when I heard the way Guido framed this argument. I'm not so sure that Python has 8 out of 9, though: the statement/expression dichotomy rules out #6, and the lack of macros rules out #9. These are arguable, depending on how you define things, but I think the most obvious thing that Python lacks compared with Lisp and Scheme (and also Ruby) is a symbol type (#7). I'm in the process of trying to understand what symbols are good for, outside the context of Lisp and its nested lists of symbols as executable code. Ruby seems to have come up with some creative uses for symbols within Python-like syntax, though I haven't seen anything terribly compelling so far. Guido briefly summarizes language comparisons with other languages: - Perl: similar niche, but Perl is for regexes and text processing, and Python is for objects, data structures, and more general-purpose programming. Obligatory TMTOWTDI argument. - PHP: very successful at its niche, being a point-solution for adding bits of script to web pages. Not very useful outside that context, and lots of language-design gaffes. - Java: the usual static vs. dynamic, static analysis vs. unit testing arguments. Guido says that there's such a small amount of problems that can be caught at compile time, and even the smallest amount of unit testing would also catch these problems. "The blindness of that [static] position... escapes me." - C/C++: same arguments as Java, plus most programmers aren't up to the task of manual memory-management. - Lisp: even though there's no code-equals-data in Python, you still have the compiler available at runtime, and there's a lot you can do to treat code as data even though they're not syntacticall
