2009/8/17 William Stein <wst...@gmail.com>: > > On Sun, Aug 16, 2009 at 10:54 PM, rjf<fate...@gmail.com> wrote: >>> > I agree with you entirely, which is why I asked about the 5000 lines >>> > with mpz. >>> > One possible answer is, "#...@#$%$, Python doesn't have macros." > > That is not why the Sage library uses the GMP C library interface in > some places. The Sage library uses the GMP C library interface, > because much of Sage (several hundred thousand lines of code) is > written in Cython, and Cython is really a "smooth blend of C and > Python". In short, much of the Sage library *is* literally C code > (but without semicolons), and it is completely natural that C code > that uses the GMP library would... use the GMP library. > >>> But I bet cython does. It also depends what you want to call a macro. >> >> Uh, do I read into this an admission that PYTHON DOES NOT HAVE >> MACROS?
Yes. >> I truly did not know (until today) that Python had no macro processing >> capability. >> I don't know what excuses you might have for saying "it depends". But >> it's >> awfully handy. > > Python code does not have "macros" in the sense of say #define in CPP > (the C preparser). I personally think this is one of the (many) > brilliant design decisions that Guido van Rosum made that explain why > I find Python code is frequently easier to read than much C/C++ and > Lisp code. It is important to note that Lisp has much more sophisticated macro processing capabilities than C++. It's actually rather a language feature of Lisp, which I imagine is why Richard is getting all excited about it. I can imagine that if you have used this language for many years, the thought of using a language without this direct capability would be anathema. > > I am really glad Python is so readable, since that is absolutely > critical in creating a large community of people working voluntarily > on a mathematics software project. The Sage project as a volunteer > project at its current scale would be impossible if it were done in > Lisp or C/C++, just because of difficulty of getting such a wide range > of people going with the codebase. The proof is in the pudding. > In fact, this has turned out to be much more important than I had > thought it would be. I can honestly say that about 75% of python is completely comprehensible to a newby with very little knowledge of the language. I've been unable to read lisp code at all. It looks like a pile of punctuation to me (mainly (I would say), lot's of (useless) (and really (really) annoying) parentheses. > > Bill Hart said: >>> By and large Python is much easier to use than most other languages. >> >> So you are familiar with most other languages? I might have inserted "commonly used". Of the languages listed below by William I have not used Tcl. I have used numerous other languages and have a nodding familiarity with a few additional ones. I have a fairly good knowledge of what goes into a compiler, etc, etc. > > There are research papers and studies about productivity of > programmers using various languages. Here's one: > > http://sequoia.cs.byu.edu/files/pubs/Delorey2007.pdf > > It looks at the top 10 most popular languages used by 9999 sourceforge > projects, which unfortunately doesn't include Lisp. The productivity > rankings they arrive at are: > > Javascript > Perl > Tcl > Python > PHP > Java > C > C++ > C# > Pascal > > It takes a large amount of work to do such studies, but fortunately > they have been done, and continue to be done. I *greatly* appreciate > the work of researchers who apply solid statistical methods to these > sorts of questions, because the results provide valuable insight into > how as a community we can all be more productive. (+1 to slashdot > for popularizing some of this research.) That's rather surprising research. C and C++ are rarely behind python in such rankings. Similarly Perl is rarely so far up the list. Here are some others rankings (different criteria): http://www.devtopics.com/most-popular-programming-languages/ > >>> So even if it were true that python didn't have a convenient level >>> upon which to implement such a thing, the enormous number of other >>> conveniences over a language like Lisp far outweigh this disadvantage. >> >> Actually, I assumed the advantage of Python was that it had many >> libraries to access >> operating system facilities in a manner that was relatively >> independent of the operating >> system. The OS libraries constitute a very small proportion of the libraries available for Python. The collection is absolutely vast and covers everything from abstract syntax trees, to GUI widgets to game API's to pretty much anything you can dream up. >> And that, although it had a foolish policy regarding indentation, it >> was nevertheless >> not too much unlike Lisp, and only a moderate factor slower. > Actually Python is often vastly slower than Lisp. It is very rarely faster. The point of python is most certainly not its speed. It is ease of use, through and through. The whole language was designed with that in mind. Of course the speed problem becomes much less of a problem when you can link in libraries written in C, assembler and Cython of course (which compiles to C++ and fairly closely approximates it). > Yep, those are probably some of the reasons for Python being popular. > >>> It has not been >>> done because of a (valid) design decision to keep the syntax as close >>> to python as possible (the Sage preprocessor does almost nothing). >> >> If it were a good decision, I think one would not have to write mpz_s >> so much. > I wonder if William only included Cython and Python files in his count, or whether he also included all the compiled Cython files and perhaps even the C libraries. There's only about 100 uses of mpz_add across the whole of Sage in Python and Cython code. That actually really surprises me, because it is so low. > What is wrong with writing code that uses the GMP library directly? > The GMP library API is clean, mature, explicit, well thought out, > offers hundreds of useful functions, is stable, and code written than > uses it is often straightforward to read and understand, and is very > fast. Many programmers like writing tight "inner loop" code that > has to be fast against the GMP API. I *like* GMP. > As far as I can tell, Maxima doesn't even use GMP. It must be dog slow for multiprecision arithmetic. GMP and MPIR have sped up by about a factor of 2 in the last year and the speed increases have been going like that for years in GMP. How does maxima handle multiprecision arithmetic? Or does it just do everything to single precision? Anyhow, where is your large Lisp based computational algebra package which I can grep for mpz_add? You are comparing Sage's 100 occurrences with what exactly? Bill. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
