|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix |
Prev | Up | Next |
|
Switchboard | ||||
Latest | |||||
Past week | |||||
Past month |
O'Reilly Network
The Windows Sys Admin's Scripting Dilemma by Robbie Allen, coauthor of Active Directory, 2nd Edition, and author of the recently released Active Directory Cookbook
As I was working on Active Directory Cookbook, I had to make a decision that many Windows system administrators face at one point or another: whether to use VBScript or Perl? I'm a long-time Perl guy, but unfortunately, no matter how much I preach the benefits of Perl, the Windows sysadmin community hasn't embraced Perl the way it has been embraced on the Unix side. Ultimately I decided to use VBScript because it is the least common denominator as far as scripting languages go on the Windows platform (besides batch files, of course). I did, however, include Perl examples on my web site so as not to leave out the Perl coders.
I was able to take the easy way out by using both in this case, but most system admins only need one, but which one? I've already stated my preference towards Perl, but I want to outline the pros and cons of each because both languages have their place. You can accomplish most of the basic system admin tasks with either language. For this reason you'll need to look at the other advantages and disadvantages of each language to determine which works best for you.Overview of VBScript
VBScript is a subset of the Visual Basic programming language. You can run VBScript code using a Windows Scripting Host interpreter (wscript.exe or cscript.exe) or from within Active Server Pages (ASP).
Advantages of VBScript
- No installation required
This is the number one reason VBScript is so widely used. Since you can run VBScript code on any Windows 2000 and later computer without needing to install anything, this makes it much easier to support on a lot of computers.
- Popular on Windows
Because VBScript comes out of the box with Windows and was developed by Microsoft, naturally there is better support for it; not only by Microsoft, which documents VBScript extensively on the Microsoft Developer Network (MSDN), but also on other non-Microsoft web sites. Generally, it is much easier to find VBScript examples than Perl examples (for Windows).
- Built-in support for COM Automation and WSH
To do much of anything with Windows, you need to use a COM-based API, such as ADSI or WMI. For scripting languages, a subset of COM is supported, which is called the COM automation interface. VBScript can use this directly with the GetObject and CreateObject functions. With Perl, you have to use Win32::OLE module to access COM objects. Here is an example that uses the VBScript
GetObject
function:set colUsers = GetObject("LDAP://cn=users,dc=rallencorp,dc=com")
And here is the same thing using Perl:
use Win32::OLE; $colUsers = Win32::OLE->GetObject("LDAP://cn=users,dc=rallencorp,dc=com")
- Readable
VBScript code is generally very readable. Here is some sample VBScript code that should be pretty easy for even non-programmers to decipher:
set colUsers = GetObject("LDAP://cn=users,dc=rallencorp,dc=com") for each objUser in colUsers WScript.Echo objUser.Name next
Here is the equivalent Perl code, which is slightly less readable:
use Win32::OLE 'in'; $colUsers = Win32::OLE->GetObject("LDAP://cn=users,dc=rallencorp,dc=com") foreach $objUser (in $colUsers) { print $objUser->Name,"\n"; }
- Easy transition for VB programmers
VBScript is a derivative of Visual Basic (VB) so if you know a little VB, it is easy to pick up VBScript.
Disadvantages of VBScript
- Limited command-line parsing and GUI support
The built-in support for parsing command-line options and generating graphical interfaces (such as a password prompt) are pretty limited in VBScript.
- Awkward and wordy language constructs
I mentioned that VBScript is very readable, but this also makes VBScript wordy in comparison to Perl. Because VBScript treats everything like an object, it often results in awkward language constructs. Perhaps the worst offender is VBScript regular expressions. Here is a simple example that tests if a string contains the letters "www" in it:
strMatch = "www.rallencorp.com" set objRegEx = New RegExp with objRegEx .Pattern = "www" .IgnoreCase = True .Global = True end with if objRegEx.Test(strMatch) then WScript.Echo "Matched" else WScript.Echo "Did not match" end if
Now here is the same example in Perl:
$match = "www.rallencorp.com"; if ($match =~ /www/i) { print "Matched\n"; } else { print "Did not match\n"; }
- Limited third-party module/add-on support
This is one of the biggest issues with VBScript. Unlike Perl, there is no large VBScript repository where programmers freely contribute and share code in the form of packaged modules or components. There are many repositories that contain sample scripts, but none that I've seen that are on the same scale as CPAN for Perl.
- No command-line code execution support
Being able to execute and test code from a command-line is an extremely useful feature of a scripting language. With Perl you can use the -e switch and execute code directly. Here is an example that prints the current time:
C:\> perl -e "print scalar localtime"
There is no counterpart to this in VBScript.
- Uncertain future
At this point, it is hard to tell what will become of VBScript. Microsoft did not provide native support for VBScript within the .NET Framework, choosing to support JScript instead. And there are already rumors flying that in the next major release of Windows, codename Longhorn, there will be a new Microsoft Shell (MSH) that will include a new scripting language. If that happens, more than likely VBScript will start to fade away.
Overview of Perl on Windows
Perl has a long history dating back to 1987 when Larry Wall released the first version. Now, an army of dedicated Perl hackers actively maintain Perl, and ports exist for virtually every modern operating system.
Advantages of Perl
- Robust
As far as scripting languages go, Perl ranks at or near the top for being the most robust and full-featured.
- Extensive module support
If I had to give one reason to choose Perl over VBScript, this would be it. The Comprehensive Perl Archive Network (CPAN) contains an extensive collection of Perl modules that you can use to do just about anything you can think of. As far as Microsoft technologies go, the Win32:: module namespace contains modules for manipulating the registry, generating GUIs, manipulating files, using the Win32 API, and much more. If you've wondered if someone has already written code to do a particular function, odds are it is in a module somewhere in CPAN. Visit http://www.cpan.org/ for more.
- Cross-platform
If you work in an environment that has a mix of Microsoft and non-Microsoft operating systems, Perl is your best bet. And depending on what you need to do, you can even write Perl code that works cross-platform.
- Actively developed
A large effort has been underway since 1999 to develop the next major version of Perl, Perl 6, which is a complete rewrite of the language.
Disadvantages of Perl
- Requires installation
This isn't a big deal, but it is something you have to consider if you want to use Perl across a large number of systems. You can download Perl for free from the ActiveState site. ActiveState provides a number of extras that you can buy if you want to build .NET components, run Perl scripts as services, create executables from Perl scripts, and so on.
- Daunting for newcomers
I hear this one quite a bit. Often when people see Perl code for the first time, they write it off as being too complicated to learn without a programming background. It is true that Perl can be extremely hard to read if not written well, but that is due more to the flexibility and capabilities of the language. You can write readable Perl code just as easy as you can write unreadable Perl code.
- Limited support by Microsoft
I debated whether to include this as a disadvantage or not, but after several years of developing large Perl applications on Windows, it is apparent to me that Microsoft doesn't like to deal with problems that arise through the use of Perl. Often when I'd find an apparent bug in a Microsoft API, they wouldn't look at the Perl code, but instead required that the error be duplicated using VBScript or VB. It is unlikely you'll find something you can't workaround, but just be aware that if you do encounter a potential bug, you may want to show it to Microsoft in one of their languages to get quicker resolution.
Summary
If you want to get serious about automation in the Windows environment, I recommend using Perl because of its extensive module support and the overall robustness of the language. If you only want to do something quick and dirty or you don't have any programming experience, VBScript is probably your better bet.
As far as other scripting languages go, a case could be made for using JScript because of its integration with the .NET Framework, but I don't find many people using JScript for system admin tasks. I'll leave that for someone else to argue.
I'd usually choose Perl for one huge reason: the code, if well written, can always run either on Windows or Linux. Even if we're talking about ASP applications (once I deployed on Linux a site application written in Perl/ASP on a NT4 box). What I really can't understand is why Perl is not more widely used, once it's far more productive than Java, for instance, it's not property of anyone and it's so feature rich! Maybe it's the lack of marketing effort (marketing seems to be everything in these days...).
VBScript Strengths
[Formatting Functions]
FormatCurrency(), FormatDateTime(), FormatNumber(), and FormatPercent() not only make short work
of tedious formatting tasks, but also use locale-specific formatting rules.
[Data Conversion]
CBool(), CByte(), CCur(), CDate(), CDbl(), CInt(), CLng(), CSng(), CStr(), CBool() all tend to overreact
to unconvertable data, but are nicely complemented by VarType(), IsDate(), IsEmpty(), IsNull(),
IsNumeric(), and IsObject(). Hex() and Oct() allow converting numbers to non-decimal strings. DateValue()
and TimeValue() allow returning just the parsed date or time values, respectively.
[Date/Time Support]
Along with the usual functions for individual date fields, Day(), Hour(), Minute(), Month(), MonthName(),
Second(), Timer(), Weekday(), WeekdayName(), Year(), and the more generic DatePart(), there are
some more granular functions for current info: Now(), Date(), Time(). The DateSerial() and TimeSerial()
functions allow for complex date arithmetic, as do DateAdd(), DateDiff(). Date literals are supported,
using # as the delimiter: #datestring#.
VBScript Weaknesses
[Unforgivably Bad Array Support]
While standard functions like Filter(), Join(), and Split() are supplied; no sort, slice, splice,
or concatenation functions exist. The stack and queue functions: push, pop, shift, and unshift are
also missing.
[Clumsy Exception Handling]
Automatic exception handling has two modes: on (all errors and warnings are fatal), and off.
[Unreasonably Strong Typing]
Objects are not first-class objects; assignment, for example, is handled completely differently
from built-in datatypes. This precludes, among other things, programs from passing functions as
arguments. Adding to this difficulty, naught is expressed in many distinct (and confusing) terms:
Nothing is an invalid object variable, Null adds the database-style complexity of three-valued logic
(not true, not false), and Empty is the value in an uninitialized variable. Numeric values can be
interpreted as booleans, as can some string values (but only if they are numeric or boolean strings).
JScript Strengths
[Strong Array Support]
A reasonable complement of expected array functions is supported: sort(), split(), join(), slice(),
splice(), concat(), push(), pop(), shift(), unshift(), and reverse(). No grep/filter, search, or
membership-test function exist.
[Native Associative Arrays (hashes)]
Actually, all JScript arrays are hashes: an array with numeric keys can have string keys added,
and all keys can be iterated via the for...in loop. As Perl programmers already know, native hash
support allows arbitrarily complex data structures to be built quite easily.
[Structured Exception Handling]
Using try...catch, errors can be handled much more readably, maintainably, and conveniently.
JScript Weaknesses
[NO Formatting Abilities]
All languages should have some kind of formatting ability: C's (and Perl's) printf, C++'s iomanip.h
library, Python's % operator, etc. JScript does not. Doing something as simple as including exactly
two digits after the decimal when converting a number to a string, or commafiying a number, is incredibly
tedious.
[Limited Data Conversion Support]
Dates and non-decimal numbers are not always converted easily. No native currency type is supported.
[Date/Time Support]
No functions exist specifically for date/time arithmetic, and there is an inadequate granularity
for parsing control. No date literal is supported.
1) I definitely would not take the formating functions of VBScript as a strong point. They are almost useless. Using the system locale specific rules is quite often a bad idea. Especialy for web based projects and for log files. I would really love to get logfiles with differently formated dates from different computers.
But you are right, it's a surprise there is at least this.
2) Data conversion in VB is also horrible. Especially thanks to the complete evaluation of conditions. The fact that I can't write
IF IsNumeric(foo) AND CInt(foo) > 0 Then
is driving me crazy every time I have to use VB(Script).
Jenda
"The very fact that it's possible to write messy programs in Perl is also what makes it possible
to write programs that are cleaner in Perl than they could ever be in a language that attempts to
enforce cleanliness. The potential for greater good goes right along with the potential for greater
evil." -- Larry Wall
During a recent migration to an MS-driven collaboration environment, we faced the same language dilemma. Longtime Perl programmers, we were (and remain) appalled by the thought of having to use vbscript to automate various system-oriented tasks. In terms of power and flexibility, there really can be no comparison between the two (in our humble opinions, of course). We found Perl (specifically ActiveState's ActivePerl) to be quite adept for the job, particularly the Win32/Directory Services features, and have used it extensively over the past few months.
We did however find that VBScript was better able to perform certain very specific tasks, particularly those specific to managing certain aspects of Active Directory.
My advice if you require Windows-based automation? Learn both. Even better, learn JScript and Perl. It isn't about the language; it's about getting the job done. Knowing both will help you do that.
Best,
Jason
http://www.wjgilmore.com/
It's also pre-installed.
It supports prototype based OO.
Lots of people are already familiar with Javascript by using it in the web page setting.
And it's neither wordy like VBScript, nor cryptic as Perl.
In a WSH environment JScript support is limitted. Prototype-based inheritance just doesn't work, so this renders JScript useless. I haven't worked with WSH extensive, so I might be wrong.
You are wrong. JScript support in WSH is not limited. Prototype-based inheritance does work.
For WSH I tend to use .wsf files and mix JScript and Perl. I like using
JScript's exception handling especially when using COM objects. If I need to spawn a process
I prefer to use Perl to open a pipe instead of using the WshScriptExec object.
I think one could make a very good argument for JScript. Especially with the integration into the .NET Framework, it is an attractive option. I'm not sure why it hasn't picked up as big of a following (from what I've seen) for doing sys admin scripting as VBScript.
I've done a lot with Javascript in HTML, but not in the WSH environment. One thing I may
do to write companion JScript examples for all of the code in the AD Cookbook: http://www.rallenhome.com/books/adcookbook/code.html.
Then I can look at the web logs and see what is the most popular.
I for one would appreciate more and better Jscript support. I've found some problems using
VBScript in some places(specifically there are some nasty bugs in ActiveX scripts embedded
in SQL Server).
Python fits very well in the windows world (can talk to dll's, COM, etc) and has cleaner object orientation than perl. Python stresses clarity and simplicity, yet it is also a very powerful language.
I wondered if someone might ask why I left out Python :-) It is also a viable option (as is a few other languages). But I see even fewer Windows Sys Admins using it. If you have a Python background and need to write scripts for the Windows environment, then you probably shouldn't look at anything else. You can accomplish pretty much the same things with Python as you can Perl on Windows. But I still prefer Perl :-)
A good follow-on question to this article is Perl or Python? (in the Windows environment) If you knew both, would one be better than another?
The interactive environment now supported by ActiveState is perhaps the best reason to go with Python in the Windows environment. (Certainly it compares favorably with running perl -e from a prompt). The COM interface is very straightforward to use, and wxWindows makes it easy to put up a good-looking GUI.
I still find that I use Perl almost exclusively in the Unix environment, simply because I had several years of Perl experience before I ever took up Python.
"and has cleaner object orientation than perl"
But why would this matter in a scripting environment? No one is going to write a class for a 20-30 line utility script.
- Joe
Agreed, Python does work quite well in the Windows environment. O'Reilly published a Python/Windows book, called "Python Programming on Win32" if I remember correctly. Another great book on Python is "Practical Python", by Magnus Hetland, published by Apress. (disclaimer: I was a tech editor).
Jason
http://www.wjgilmore.com/
06/27/2002 | O'Reilly Network
This article is based in part on my O'Reilly Open Source Convention 2002 tutorial, "Python for [Perl] Programmers/" However, this article includes more Perl and Python comparison than I've included in the tutorial. My tutorial targets experienced programmers of all sorts, with the non-Python examples drawn from Perl. In this article I'll be comparing Python's loop constructs to Perl's.
Perl has two basic looping constructs: while and for/foreach. This doesn't count variations, such as "<statement> until EXPR" or do...while, nor the fact that for/foreach has two different forms. Python also has only two looping constructs: while and for. Unlike Perl, Python's loops have no variations; instead, the for loop uses a special protocol that generalizes well. Both Perl and Python have functional constructs that loop over a sequence, but that's outside the scope of this article.
The variation in available loop constructs exemplifies the basic difference between Perl and Python: Perl's motto is TMTOWTDI (There's More Than One Way To Do It), whereas Python's counter-motto is "There's Only One Way." Python's motto is the short form of one element of Python's design philosophy: "There should be one--and preferably only one--obvious way to do it." To see the rest of Python's design philosophy, start the Python interactive interpreter (Python 2.1.2 or later) and type "import this".
So how do Python's looping constructs actually work? Let's start with a basic Perl idiom:
while (<STDIN>) { print; }
and compare it to the equivalent Python idiom:
import sys for line in sys.stdin: sys.stdout.write(line)
The main thing to notice is that Python uses a for loop instead of a while loop. There are two reasons for this:
- Python does not permit assignment in expressions. In order to do assignment as part of the loop construct, you must use a for loop.
- Python 2.2 introduced iterators, and a file object in Python is its own iterator. An iterator is an object that has a
next()
method;next()
produces the elements of a sequence, one at a time. The for loop is designed to work with iterators.Prior to Python 2.2, the loop would have been written like this:
import sys
while 1:
line = sys.stdin.readline()
if not line:
break
sys.stdout.write(line)In general, Python's for loop works much like Perl's for/foreach list form. In order to loop over a sequence of numbers, you need to produce a list:
for i in range(10): print i
This will print the numbers from 0 through 9. Like Perl arrays, Python lists are zero-based, and the
range()
function caters to that. To prove thatrange()
is in fact creating a list of numbers, fire up the Python interpreter:>>> range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Contrast this with Perl's standard indexing loops:
for ($i=0; $i<10; $i++) { print "$i\n"; }
or
foreach $i (0..9) { print "$i\n"; }
Note particularly how
range()
specifies a value one higher than the maximum index; this makes it easy to use with thelen()
function. Generally speaking,range()
is fast enough and consumes little enough memory that generating an entire list doesn't hurt. But if you're worried about that, Python does have thexrange()
function that produces one number at a time.Aside from the lack of assignment, Python's while loops function almost identically to their Perl counterparts:
Perl:
$done = 0; while (!$done) { $input = getInput(); if (defined($input)) { process($input); } else { $done = 1; } }
Python:
done = False while not done: input = getInput() if input is not None: process(input) else: done = True
Note that False is a new, built-in value in Python 2.2.1 (in Python 2.3, boolean operations will return True/False instead of 1/0). In general, any empty value generates a false truth value: False, None, 0, "", (), [], {}, and class instances with
__nonzero__()
or__len__()
methods that return 0.Note also that in Perl, if
getInput()
starts returning a hash or array instead of a scalar, the while loop needs to be modified, whereas the Python loop will continue to work fine with a dict or a list. That's because in Python, everything is done with reference semantics (called "binding" in Python because one does not access references directly); one can get the same effect in Perl by explicitly using references.In addition to iterators, Python 2.2 added generators. Generators are functions that return an iterator. It may help to think of them as something like resumable closures. Here's a subset implementation of grep:
from __future__ import generators import sys import re def grep(seq, regex): regex = re.compile(regex) for line in seq: if regex.search(line): yield line
The "yield" keyword turns an ordinary function into a generator; the generator returns an iterator that wraps the generator. Each time the yield executes (returning a result just like "return" does), the generator is paused, but the generator function's stack frame is retained (including all local variables), pending another call to the iterator's
next()
method. The iterator does not execute any of the generator's code until the first call tonext()
.Returning to this specific example, calling
grep()
returns an iterator. Each call to the iterator'snext()
method returns one match. This happens implicitly in a for loop:regex = r"\s+\w+\s+" for line in grep(sys.stdin, regex): sys.stdout.write(line)
The advantage of all this is that it's simple, clean, and efficient. You can write straightforward code--but it doesn't need to hog memory by creating an entire list before returning. Generators can be pipelined; imagine recreating other Unix utilities, such as uniq. Even if the source is a list, at least there's no need to create temporary lists.
The "from __future__" statement is needed because "yield" is a new keyword in Python 2.2 and accessing it must be done explicitly. When Python 2.3 is released, "from __future__ import generators" will no longer be required, but keeping it won't harm anything (allowing code to run under any version Python 2.2 or later).
For more information about converting Perl code to Python, see the Python/Perl Phrasebook . (The phrasebook is seven years old and out of date, but still quite useful.)
Special thanks to Cathy Mullican ([email protected]) for refreshing my badly outdated Perl knowledge.
Guido van Rossum is the well-known creator of the Python programming language. During his address at OSCON 2003's States of the Unions event, he announced that he'd soon be leaving PythonLabs to work for a California startup. Guido graciously agreed to an interview with Steve Holden on the move, recent developments, and Python in general.
... ... ...
ORN: Tim O'Reilly's keynote at OSCON was quite thought provoking. What do you think were his most interesting points?
GvR: I really liked his point about how the nature of the popular applications changes, and that Amazon or Google are applications just as much as Word or PowerPoint. I thought his point that those applications have a lot of data, and that they leverage the people who interact with the data, was particularly telling.
I think that was the key idea from his speech, and I really think that in the Python world there are things we can do with that idea. For example, the PyPI, the Python Package Index, might actually become much more useful if people can feed back what they think of a particular piece of software.
ORN: Do you think that the open source development model has proved itself as a viable alternative to proprietary methods? Can the cathedral coexist with the bazaar?
GvR: Open source development methods have absolutely proved themselves, and I don't think there's any immediate likelihood that the cathedral will be demolished. However, among open source projects, I'm a fan of those that are consciously run with a bazaar-style model.
The projects where there are a lot of programmers paid by a particular company, whether it's Netscape with Mozilla or Sun with Open Office, even though they claim a lot of success in terms of downloads, are extremely hard for the average programmer to make a contribution because the code base is so enormous, and the learning curve is therefore rather steep.
Projects that started out as grassroots, like Python, have developed more of a community and a process that makes it much more acceptable.
ORN: Python is a part of a larger open-source community. What do you see as the major challenges facing that community in the next couple of years?
GvR: Oh, man, I'm not that kind of visionary, to have an opinion about that. Some people are worried about a few things, like software patents, but in my view software patents are so absurd that I expect that open source will happily survive all that, even if situations arise where a few specific projects are forced to rewrite some of their code to work around a patent.
A few individuals will probably be hit by unfair lawsuits, but by and large I don't think that's going to break the open source community.
ORN: I sometimes think it's a good job nobody has patented breathing; otherwise we'd all owe them money.
GvR: I guess there was prior art among the reptiles [smiles].
ORN: How does Python differ from other open source projects?
GvR: I guess one difference is that it has a long history, since it was first distributed in 1991. In those days nobody talked about "open source", and Richard Stallman [founder of the Free Software Foundation] wasn't very well known and the GNU General Public License didn't exist.
It's amazing how many people who are still active in the Python community were at the first Python workshop in 1994.
ORN: How has the Python development community changed over the last few years?
GvR: The role of PythonLabs has actually been diminished, and although the perception is that PythonLabs still controls a large percentage of the core code, in fact the reality is that PythonLabs folks have all been hacking on various pieces of Zope and ZODB. So the larger developer community has taken over and has done so very successfully.
We've had a lot of "new kids" join as developers and become active in the community. We've also seen that the geographical base has broadened quite a lot, with contributions coming in from outside Western Europe and the United States.
ORN: Why do you think Python is less popular than Perl?
GvR: Perl was there first. It's definitely older than Python, and when I decided to create Python I looked at the existing Perl, which I think was 3.0. Even by that time it had managed to create a lot of mind share, and it definitely filled a need in the user community.
Perl, Python, Ruby and Tcl are the four dynamic programming languages that get the most publicity as open source projects, and I think they have a lot more in common than they differ.
ORN: What's being done (and by whom) to improve Python's visibility and grow the user community?
GvR: I don't know that enough is being done, but there are certainly a number of people who are very active in that area. I do it myself by staying where I am and giving keynotes at conferences and making my personal life the subject of discussions on Slashdot. I didn't elect to do that, but it happened--someone listening to my OSCON keynote posted the news of my move to Slashdot, and some people seemed to feel they had the right to comment on it.
ORN: Perhaps they should get lives of their own instead of discussing yours?
GvR: Perhaps. Anyway, there are some people taking specific actions to promote Python, notably Kevin Altis, who among other things put the OSCON Python track together and has set himself the goal of increasing the number of Python users tenfold in the next year or two.
There's now a "python-marketing" mailing list, and Stephan Deibel of Archaeopteryx is very active there, issuing press releases for the Python Software Foundation about various things. He'll be doing another one for the upcoming Python 2.3 release, where hopefully we can include a quote from Apple about the inclusion of Python 2.3 in the next MacOS X release.
ORN: How did you come to decide to set the 2.3 release date so the software could be included in the gold master for the next Mac OS release?
GvR: Well, Apple expressed interest, and the schedules almost matched already. Basically all we had to do was bring our deadline forward one week.
ORN: Have you seen a good response to this decision from the developer community?
GvR: Very good! Usually what happens is that when I get my act together and set a release date, all sorts of people who have been putting off checking in their changes and reviewing their patches suddenly become active. So we've seen a flurry of activity.
Of course there are a few people who are disappointed with the compressed schedule, because it's meant their changes have had to be rejected for 2.3, but there's always 2.4 or even 2.3.1.
ORN: How would you like to see the Python Software Foundation develop over, say, the next three years?
GvR: Observing how other similar non-profits like the Apache Software Foundation and also the Open Software Initiative, of which I'm a board member, I'm struck by how the PSF is still run by geeks, none of whom have significant experience running a non-profit. I think as a result we're not always doing the right things, and we don't always do things at the right time; we don't exactly know how to do it. So either we argue endlessly about how to do things, or we do them badly.
It would be good to invite some new people who are friendly to Python onto the board for the next year. You could say that I think the board needs a little adult supervision [smiles]. I realize that this is not something I'm good at: I head the board because people know my name, but I'm not very good at the schmoozing that it takes to get companies to sign up as a sponsor member, for example, or to attract large donations.
ORN: What's the situation with the python.org domain ownership, and do you anticipate any changes any time soon?
GvR: As you might know, CNRI still owns that domain, and has let the PSF use it without much restriction, although they did ask us to keep the 1.6 release on there despite the fact that nobody much uses it.
They have finally approached me, having found the time to address the question, with a contract to handle the transfer of the domain name, which is probably the most important thing, a number of trademarks, and the copyright to the content of the python.org website. The CNRI position has been that they own that copyright because the web site was started when we were all at CNRI.
That's actually quite an important contribution to the open source movement by CNRI.
ORN: What are the most difficult aspects of reconciling open source software development and making a living?
GvR: It gets more difficult once you have a family, because it's more important to have a steady stream of income that lets you pay your bills and put something away for when the kid goes to college. It seems a long way away, but you have to start saving almost from the moment they're born.
That limits me in the choice of employment.
ORN: What have been the major changes in patterns of Python usage lately? What do you see as the most interesting new application areas?
GvR: There are lots of interesting ways that Python is being applied, but none of them are especially new. Python has always been very broadly applied.
What I do appreciate is that Python is slowly but steadily becoming more known among at least the avant-garde teachers and educators. There are more and amore people who aren't too tied to traditional school districts and who are looking into Python and teaching it.
ORN: This resonates with your long-held interests in "computer programming for everyone". Don't you think that perhaps "everyone" is too broad, and that there aren't at least some people who will never be capable programming a computer?
GvR: That's a deep philosophical question. I'm optimistic about that in theory.
There are plenty of countries, although unfortunately the USA isn't one of them, where 100% of the population is literate. That doesn't necessarily mean that they can write novels or newspaper articles, but they can all read and write, and if you taught them how to type they could all express their thoughts in an email or a blog entry, for example.
Given that I believe everybody can learn to read and write, given the right education and circumstances--obviously if your parents have no money and you're sent to work when you're seven years old, you're not in a very good situation unless you're exceptionally smart--I believe that the same thing would be possible for programming and thinking logically to some extent.
ORN: What value do Python skills have in the job market? Why should a programmer bother to learn Python rather than Visual Basic or Java?
GvR: If you say, "Why should a programmer learn Python", I could say, "Because it's the most fun of all the available languages". There are situations where you're required to code everything for production in, say, Java, but you still have the opportunity to do prototypes or testing frameworks or personal and ad hoc programs using Python. So it often proves useful in situations where you least expected it. But if you don't know it, you won't be able to use it, so you may lose out on an opportunity to do something extra for your boss because you knew this new tool.
I don't think that at the moment there are enough places advertising jobs with Python as a requirement to say that Python will give you a bigger chance of getting a job, although there are some places where that's obviously true. For example, Industrial Light and Magic has seven hundred Python programmers!
... ... ...
ORN: Do you have any writing plans at present?
GvR: I don't. I'm going to put all my energy into Elemental Security and one day a week just running the Python community, sort of guiding where the next developments go. I would dearly love to write, but I can't even add something to my blog more than once every couple of months.
ORN: The literature has expanded hugely in the last three years. What gaps, if any, do you see in Python coverage nowadays?
GvR: I love the way that literature has grown. Is there a book on wxPython yet? That's still a gap [Patrick O'Brien has a book in the planning stages]. Apart from that I'd love to see more materials for use in classrooms for use by the "computer programming for everyone" crowd.
Those people are looking for tutorials and examples and books, and they have very different requirements; they can't use "Learning Python" or any of the other standard texts.
... ... ...
ORN: What's your single favorite Python application that someone else wrote?
GvR: That's an overwhelming choice; there are so many categories, and there are things that I know exist that I have never used myself that I think are absolutely exciting.
Maybe I should mention Adele Goldberg's and Dennis Allison's ThinkFive application that they presented here at OSCON. In half a year with two people they were able to create a content management system in Zope and Python, with a little bit of SmallTalk that allows master teachers to create really high-quality online classes in subject topics like geometry and algebra.
I was really very impressed by what they did, and there are three kinds of users who interact with the system. First, the people who create the courses, who interact with Zope and create Flash animations and all sorts of other stuff in XML. Then there are the teachers who use the system in the classroom, or at least mentor the students, who are taking the courses from home in some cases, and there are the students. ThinkFive does something for each of those groups.
ORN: You've spent a lot of time on Zope recently, and it's a product nearing a major new release. What is your favorite feature that people will see in Zope 3 (and why)?
GvR: That's hard to say, because everything in Zope 3 is different. What I like in Zope 3 is that for the Python programmer writing code to go into a web site, things are much less confusing than they were in Zope 2.
ORN: What do you feel was your biggest technical, professional or personal mistake along the trail from ABC to Python 2.3b2?
GvR: I think the biggest mistake was a personal one, my decision to join BeOpen.
ORN: What advice would you give to young people just starting their careers in information technology?
GvR: There is still a lot of fun to be had in software development and don't believe all the negative stuff about how the IT boom is over.
Computers still run a significant part of our lives and they will continue to get a lot better. So we will continue to have a lot of need for a lot of smart people to program the applications of the future that nobody's heard of or can even dream of.
Steve Holden acts as a consultant, advising clients on system and network architectures and the design and implementation of programmed web systems. He is also the author of "Python Web Programming".
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 12, 2019