On Tue, Apr 13, 2010 at 11:02 AM, <ch...@seberino.org> wrote: > On Tue, Apr 13, 2010 at 10:30:49AM -0700, David MacQuigg wrote: >> Good observation. I wasn't thinking of parallel computing at all. I >> can see a need for something very different in this realm. I'll stick >> with my original bet, however, if we limit our consideration to >> "mainstream" languages. I will bet that languages like Fortress, >> designed to deal with concurrency, will be used only by specialists, and >> that the majority just needing to process payroll records or program a >> website, will stick with whatever evolves from Python. > > I agree. When speed isn't important, there is no reason to welcome the added > complexity of concurrent programming. >
Lets not exaggerate the current standing of Python within industry. The technicons in places like Indonesia still mostly don't teach it, pretty new in the Philippines etc.. Singapore / Pycon may turn some heads, but a lot of production work is done in other languages besides Python, such as Java, VB, Perl and so forth, and this is as it should be. Mathematica is one of the most prevalent languages and I don't see Python eclipsing it (or vice versa). J has its niche in the financial sector they tell me, an arena in which Python has only just emerged as a contender thanks to its now sporting a decimal type written by Facundo Batista and implemented by Facundo Batista, Eric Price, Raymond Hettinger, Aahz, and Tim Peters. All I'm saying is that Python is not now and never has been the King of Languages, nor is it my impression that it's bucking for that role (it's not my impression that geekdom even has such a job opening). Python "plays well with others" which means it expects to have others to play with, many others, including concurrently. New languages are and will be coming down the pipe, like Go most recently (a candidate implementation language?) and Python's capabilities will change depending on what it's written in. PyPy allows what by today's standards could be considered freakish behaviors, more normal to those frequenting exotic circles -- like Cirque du Soleil (currently with tents here in Portland). Fresh ideas for language features will likely keep coming from that test bed. >> That's not to say the 1% is unimportant. Here we will find brilliant >> programmers working on sophisticated techniques to break large problems >> into pieces that can be executed concurrently by hundreds of processors. >> Each problem is very different, and we may find programs for circuit >> simulation using very different techniques than programs for weather >> prediction. These programs will be run in an environment controlled by >> Python. The circuit designer or atmospheric scientist will not be >> concerned about the details of concurrency, as long as the result is fast >> and accurate. > There's a school of thought out there that says operating systems are supposed to handle concurrency pretty well. Some designs boot multiple Pythons as multiple processes and let the OS take care of concurrency issues. Why reinvent the wheel and rely on internal threading? Instead of multiple threads within Python, make each Python its own thread. These concurrently running Pythons are then trained to communicate in a loosely coupled fashion by reading and writing to centralized SQL tables, which double as audit trails. If a process dies, there might need to kill a process (zombie snake problem), and maybe the controlling process (like air traffic control) launches a new one -- depends on many factors. I'm thinking of a buzzbot I know about, by Portland Energy Strategies (Patrick Barton et al). I've posted about it before over recent months. Also, think about Twisted, the basis for vast multi-user games. You might think Python couldn't hold its own in such a server intensive interactive environment, but here the approach is to take maximum advantage of asynchronous architecture. That being said, I'm not suggesting only Python is ever used. The whole idea of a "glue language" is you have other things to glue. I don't think Python's global interpreter lock is always the big bugaboo some people consider it to be. Concurrency has many meanings, and is an issue computer science has been tackling regardless of the number of chips. What's true about Python is it's designed to shield programmers from wanting or needing to know much about machine architecture. You have sockets, ports, tcp/ip, various pickling and packaging protocols (like json), but you're not thinking in terms of chips or individual registers on those chips. Does this mean I think Python has a realistic chance of completely replacing Erlang as a cell phone language? No. Why would anyone wanna replace Erlang? They should be teaching that at New Mexico Tech, no? Promela anyone? http://en.wikipedia.org/wiki/Promela > Interesting observation. Python would still be useful in a world with > concurrent tools as a glue language at worst. In my view, the information services have a challenge to keep training a few students in esoteric so-called "dead" languages. Their "deadness" mainly involves their not evolving any more, yet they may have significant workaday responsibilities and continued maintenance of their applications remains paying work for many people. FoxPro, MUMPS, COBOL some would say Smalltalk, APL -- these are "dead languages" in the sense of being frozen APIs. Ada, Perl 5.x, Logo, Algol... all dead, and yet we could still use some help with projects implemented therein. I remember working with Bernie Gunn on his Pascal stuff. Even if the goal is to migrate to Python (or maybe Java, or both), you still need a working knowledge of the source language to move to the target language. Bernie the geochemist in New Zealand. http://www.geokem.com/ I'm thinking the approach taken by the classics and antiquities departments will come into play. How do we get students interested in Sumerian? I spell SuMerian with a capital M sometimes (like camelcase) to remind myself of this challenge. M stands for the M-language or MUMPS, a paradigm "dead language" still in use to this day, a good example of the kind of esoteric dead language that only a dwindling number will know. UC Davis still teaches M I'm pretty sure. Anyone know? http://www.vmth.ucdavis.edu/m/m_faq1.htm The work / study programs of the future will need curricula that continue to produce competent programmers in these various languages. A popular combination will probably be: learn one or two "hot" or "avant-garde" languages (whatever is in vogue, say Haskell), one workaday "old faithful" too maybe (like Java), and then one esoteric retro language that still nets you interesting clients and gigs from time to time. That could be Fortran, Pascal, even VBA. Then of course there are still the assembly languages, special to each chip. The Art of Computer Programming keeps the focus more to that level, where thinking about registers *is* important. Python is about to join the ranks of the dead at least temporarily, thanks to this recent PEP mandating a feature freeze, giving the librarians and 3rd party package developers a chance to catch up. I think this decision wins high marks for Python as a mature development community. Now that the major leap to 3.x has been made, people are willing to step back and wait for more of the assets to get over the hump. Kirby > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > http://mail.python.org/mailman/listinfo/edu-sig > _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
