Slashdot Mirror

See the perldelta doc at search.cpan.org

/Alex

As an aside, mod_perl 1.22 has been updated to work with Perl 5.6 (it was released last Wednesday). From the changelog:

compile fixes for 5.6 + -Duse5005threads
[Lincoln Stein ]

darren

More interesting is the fact that the posts (not for the faint-of-bandwidth) are made up almost entirely of quotations and jokes. Looks like someone effectively 'spammed' the thread with their cookie file (just two days ago). Makes most of the nu-generation sons and daughters of Meept! look like dabbling dilettantes.

Epic détournement or crude LWP hack? You decide.

This should be very doable with current software. Check out swig at this link. It provides a framework for interfacing C/C++ with scripting languages like python, perl, guile, etc... I'm not sure if you can interface python and perl using swig, but you could definitely write a C library that could be called from python. This C library could then use perlembed to make the appropriate perl calls. A certain amount of annoying mucking about with internals in C would be necessary, but its probably easier than writing a dozen DBI backends in python. Maybe you could even code some common data type conversions in C and make the interface general enough to handle most modules.

Of course, you could also just write a small generic server in perl that could communicate with a separate python process using an intermediate data structure implemented in both languages. And I'm sure there are a dozen other more intelligent ways to do it. After all, perl is involved, so TMTOWTDI ;-)

Perl does have an app like Zope.

Mind you, I'm only pointing this out to say that Perl is not completely lacking in such a 'killer app', not to start another Python war.

Iaijutsu is an object oriented web content management and application development framework. It has a lot in common with Zope, but diverges in many conceptual areas.

What's magical about Zope is that it looks, to users, like a content-management system with a simple Web interface that anybody can use. A non-programmer can manage a simple website, using Zope, with little training.

Iaijutsu does that now. Although I can't mention the names of very many sites because they are clients for my day job, we have quite a few fairly large name clients using Iaijutsu's content management for their sites, intranets, and business-to-business document stores.

Yeah I know, kinda a weak claim. Just suffice it to say that someone is using Iaijutsu now.

Thanks to Zope's powerful object-oriented framework, it's easy to build such a site in an efficient and economical way, inheriting (or, in Zope-speak, acquiring) common elements from ancestral objects

Acquisition != Inheritance. More of a close cousin.

And you don't need acquisition for efficiency and economy-- on the contrary, I've kept acqusition from permeating the design of Iaijutsu because it seemed to me to be one of the most confusing aspects of Zope. However, acquisition is still possible in Iaijutsu. (There's more than one way to do it! :) )

Thanks to Zope's built-in object database, it's easy to restructure the site -- for example, by cutting a subtree of objects from one location and pasting it into another.

I implemented this about 6 months ago.

Out of the box, in other words, Zope is a useful Web content manager for nonprogrammers.

Iaijutsu is this right now. However, the documentation is even less complete than Zope's. :) Soon...

There's a tag language called DTML (Document Template Markup Language) which, like Cold Fusion Markup Language or Java Server Pages or Active Server Pages, mixes HTML templates with programming instructions that can populate these templates with data drawn from SQL stores or Zope's own object database.

Iaijutsu has this, via Andy Wardley's awesome Template Toolkit.

However, unlike Zope, Iaijutsu is designed with the philosophy that content, logic, and presentation should be like oil and water. The templates are for presentation-- you do not build application with template documents. This goes against the concept of DTML, ASP, JSP, LiveWire, PHP, EmbPerl, and all the other code-in-page systems.

You compose content in object properties, applications with object methods, and display content and application results via templates. The only logic in your HTML templates should be only what's required for display. (See XSL for a similar concept.)

When this mid-level programming environment runs out of gas, you can drop down to Python -- Zope's native implementation language -- to write powerful extensions that communicate intimately with Zope's internal machinery.

The same ability exists in Iaijutsu. Content and application classes can be written in Object Oriented Perl.

However, there is also a hybrid Perl/XML format for writing classes online in web forms. And you need not write any perl at all in these class definitions.

Anyway, I've babbled enough. Just trying to set the record straight, that Zope is not without competition soon. :)

The decision for Quote.Com to change wasn't only based on the "reliability" of the platform.

Their decision was also based on facts like:

• There are more pre-built software components for IIS/SQL server
• Things like XML support are very primitive in PERL, for example.
• MCSEs are cheaper to hire than Unix admin/programmers
• With more, cheaper machines, you can play the "uptime numbers game"

A lot of developers are working on XML support in PERL (there is a Perl/XML FAQ), but you still can't support Unicode. Perl still relies on 8-bit character sets, so we use UTF-8 instead of 16-bit Unicode. Unicode support is neccesary for a complete XML implementation.

You'll also find that MCSEs will be cheaper to hire than Unix programmers. This is partly due to their (general) lack of skills, and partly due to their great abundance. An MSCE course only teaches you how to think the Microsoft Way. I wouldn't trust an MSCE to maintain or write code in C++ or Perl, for example. Without the MFC and a pointy-clicky interface, an MSCE can't function.

However, give the MSCE the MFC and a pointy-clicky interface, and an MSCE can deliver a program faster than a "traditional" developer. The fact that the program inherits all the bugs and mis-features of the MFC is not an issue here. The fact that the program was slapped together without regard for maintenance or robustness is also not an issue here. The issue that Quote.Com chose to focus on was delivery time, not quality of product.

As for the uptime numbers game, it works like this:

If you have 1 Sun server, and you need to upgrade the hardware, you need to shut it down. If it takes 1 hour to shut down, replace the hardware and restart, then you have 1 hour downtime.

If you have 2 Windows NT servers (for the same price as 1 Sun machine), and you need to upgrade the hardware, you need to shut them down. If you do it one machine at a time, and take 4 hours total to replace the hardware, then the server pool still has 0 hours downtime. Windows NT pundits will happily overlook the fact that the individual machines are constantly being overhauled.

In addition, Microsoft introduces the idea of "scheduled downtime". That is - you plan to reboot each machine once a day, to make sure the system remains stable. So twice a day, you have one of your two machines reboot. One machine reboots in the morning, the other in the afternoon. The total downtime of the server pool as a whole is still 0 hours (because you're not counting "scheduled downtime" as "real downtime").

Now combine the MSCE factor with the downtime numbers game factor, and you'll find that you can get away with shoddy code, because when your server crashes, it's not really downtime anymore. The problem of data integrity in your backend database is something for the DBA to worry about. You've got your uptime figures and time-to-delivery figures up there in the top 10. If the DBA complains about data integrity, you sack her and fire someone with a more "can-do" attitude. You don't want slackers in your Microsoft Powered enterprise!

Daily Reboots:

• Win95 prescription: 50mg of reboot daily
• What's So Bad About Microsoft?

I'm quite surprised that some guys only talks about personal preferences & this sort of stuff. Ok, it's important but to me, the project itself should be more important than any other thing. The questions should be "what sort of data do I have to access/modify/process", "where will the stuff will run", "what is the most important thing to the project : speed/maintenance/etc..."
I don't preach a ISO900*. analysis each time you do a cgi but if you plan to create a medium size ou bigger site, don't hesitate !! Ask the correct questions, sketch your data & your methods to process it, find the minimal requirements of your project ( speed/size/etc... ) and then choose the technologies/OS/languages.

Personal hint
If it's only to play with cgi, then choose Perl, it's so fun & easy especially with the right modules as ePerl or Text::Templates. And perl can help you anytime ( it's very powerfull and very extendable --- there's already a ton of modules ( at the CPAN ) for all your needs !!
/Personal hint

Yet Another Anonymous Coward

• man -k does not find texinfo documents.
  
• Using texinfo docs from EMACS (or an EMACS like tool like info) is cool (do it all the time), but why could man pages not be browsed in the same way? I can think of some reasons, but they are all solved by some basic indexing techniques that were old tech in the seventies.
  
• Texinfo as a format is actually much better than roff. It is more readable, easier to learn and has a more regular syntax. However, it suffers exactly the same problems (e.g. being a general purpose markup language as opposed to a constrained UNIX documentation format) without the established conventions for accessing the documents on a UNIX (like) system.
  

Yes, but we aren't speeking [sic] Greek, we are speaking English.

Importing plurals along with loan words is a stupid anomaly.

That criterion and phenomenon, or bacterium and millennium, shall someday undergo more complete assimilation is far more likely a question of "when" than it is of "whether". As this occurs, strange corruptions like double plurals sometimes arise and occasionally persist, such as the "these bacteriae" example I read and recoiled from the other day. What's next, "millennias"? :-(

All you really have to go on is your ear, but checking the OED never hurt anybody. :-) And at this time, "criteria is" seems just jolting an error in numeric concordance as "pathos are". Yes, Greek sucks in its complexity. And English is annoying in its unpredictable assimilation strategies. But you really aren't going to change either. That's just how it is.

To make this posting useful and geek-relevant, you might check out Perl's Lingua::EN::In flect module. It's filled with boatloads of examples of these.

ObFunny: How many Germen [sic] does it take to change a language? :-)

A CPAN like mechanism would work well for languages that have very well defined, unambiguous specifications. Perl, for instance, behaves pretty much the same way on all (at least Unix) machines. Java and Python, as well as most other "interpreted" languages also share this characteristic.

C and C++, being much older, with more carryover "baggage", however, do not have the luxury of a fully specified language definition. In the ANSI spec for C/C++, there isn't even a set size for the basic data types! All that is required are various ambiguous properties such as sizeof(long) >= sizeof(int) >= sizeof(short)

A generic C/C++ code repository would face much difficulty in maintaining portable code that would just work for anyone, given the nature of these languages. As far as Perl, Java, and Python go, there are already many code repositories available: CPAN, Gamelan, and Python.org all contain links for downloadable "modules" for these languages, repsectively.

The problem with creating a single monolothic open source repository stuffed with functions and class libraries for everything under the sun is that people's needs are far too diverse. The current model, where tidbits of functionality for specific topics are maintained by various organizations considered "authoritative" in that field, has proved fairly effective. Some notable examples include netlib, libwww, ARPACK and of course CPAN.

I'm not sure what purpose would be served by bringing all of these various efforts under a single roof. They all have differing philosophies, goals, and styles. Some, such as ARPACK, are highly domain specific, and its maintainers are unlikely to care about "generic code repositories." The STL filled a very important niche, but having gotten the basic algorithms and data structures out of the way, creating a massive interdisciplinary code repository is an unachievable and perhaps undesirable feat.

Perl has just such a thing (as I'm sure most of you know) - CPAN, the Comprehensive Perl Archive Network. I've done Perl development from time to time and I've often found very useful things in CPAN which I could directly apply to my work.

I program primarily in C and have never seen the C CPAN equivalent... I would love to see a widely mirrored repository of reusable C code.

As far as quality goes, CPAN seems to be of very good quality... I have no idea how submissions are handled, but I assume there's some sort of acceptance process. If it's all self-regulated I'm impressed.

Although many people point to the ease of writing Perl as the primary reason it is on top for CGI programming, there are many other reasons. I would imagine that topping this list is the fact that more people know and use Perl regularly than most other languages, since it is such a flexible and portable language; when people start writing CGI scripts, Perl is a natural for them.

Perl has tons of freely available libraries and modules that encapsulate almost every bit of functionality that you could ever want. Anything that takes more than a few lines of code has probably been done and encapsulated before. You just need to get it (CPAN).

Perl is a very expressive language, more so than most other languages I've seen or used. Because of this, people get very attached to Perl and what it can do.

Perl has better support for regular expressions, parsing, and string manipulation than any other language or tool in existance. This becomes extrememly important when converting data on the fly, from text files, other formats (such as XML), from databases, or from any other thing you can think of. Grabbing raw data and parameters from the URLs and from POSTed scripts is easier in Perl than in most other languages, due to this support.

What people usually bring up as downside to using Perl as a CGI language are not specific to Perl, they're specific to CGI. "Perl is a huge executable," they say, "and it is expensive to run a Perl script." But most of the overhead comes from the webserver forking a process, not from Perl itself. Yes, Perl scripts can become bogged down with tons of modules and libraries, but so can any language that has the capability to use libraries. As far as being a huge executable, take a look at the binaries produced by some of the Microsoft Web solutions (ahem, VB, ahem) and we'll talk about huge executables. The Tcl binary is about the same size as the Perl binary, and many complex C programs end up being very large also, once you incorporate regex parsing routines, CGI libraries, and image processing libraries.

darren

... the results would be seriously skewed toward certain types of programming (which I, as a kernel hacker, generally refer to as the "lightweight" side).

So what? A study that only includes Linux programmers is excessively skewed toward kernel hacing. If you're interested in the demographics of open source programmers, and this is what they're doing, then that's what you should be investigating. You do know that kernel hacking is not the whole universe of open source, don't you?

Nobody ever wrote a filesystem or device driver in perl, nobody ever will, and there are many more programming categories where it's almost equally unusable. The findings would be overly weighted toward text munging and web crap.

Uh, while it's true that no one would use Perl for kernel hacking, file systems or device drivers, I think you have a very narrow and uninformed view of the things people do use it for. Have a look at the list of module categories, you'll see many different kinds of applications, including system-level stuff (in fact, there are modules that access the filesystem and an interface to Windows serial device drivers there). Note that Perl modules don't have to be written in Perl; they can be written in the C API, which is often done to create a Perl interface to the operating system level.

I think your conclusion has it completely backwards. Perl may be the project that covers the widest variety of programming categories, because it's used for so many different purposes.

If you're going to follow up on the study, why don't you try to find out what you can from the authors list of the CPAN archive for contributions to Perl? It's a large list, and although it does not include information about their locations, most of them at least provide their email addresses.

There is public biographical info about many of the contributors to the Apache server.

But above all, please try to include more projects next time. I'm bothered that the headlines on ZDNet and Slashdot said "Open Source", when in fact the study was just about Linux.

A number of OSS projects have spawned from the company. One of them is CONS, a wonderful replacement for make that we use internally for many of our projects. Another one is the Net::SNMP Perl module.

Please note the license terms for these packages. They have the usual "use at your own risk" licenses.

1. Questions

The most important issue, and one which surprisingly few posters have addressed, is to identify the properties that are desirable in a 1st programming language. Identify also which properties are considered undesirable in that same environment. Once you've done a thorough study of these issues, only then can you analyse existing programming languages for how well they fit these criteria, or to create a new one that better satisfies them than existing languages. But until you know against what metrics these languages are to be judged, you cannot objectively do so.

Is this ideal beginner-oriented programming language also a language that's good for other focused domains? Will the decisions you've made in designing or selecting this ideal beginner-oriented programming language render it less than optimal for programming that isn't oriented toward non-programmers? Or if you add in properties conducive to non-beginner programming, will this compromise your goals of creating something for beginners?

Can we leverage our natural cognitive strengths in learning natural languages to learn a programming language? Does this imply that we acquire language more readily when we have lots of easy, contextual examples than we would if presented with sets of rules and axioms? Does this mean learning by a usable subset of a language first, and only adding sophistication if and when it becomes necessary? If so, does this not engender dialectical subsets? Would a beginner (equivalent to a seven-year-old speaker of his native tongue) confronted by a complex piece in the language (say, equivalent to a doctoral thesis) find himself somewhat lost? Would it be better to throw out the language you'd learned until age seven and start a new one so this can't happen, or is it better to learn incrementally?

Does it make sense to expect the same language that is used for one domain to be equally applicable to an unrelated domain? Aren't domain-specific languages both more powerful and more user-friendly?

Are we talking about a particular age group, such as ages 9-12, 13-17, or 18-21? Does this affect our criteria? Should a university really be used as nothing but a high-classed tech school as feeders for industry? If so, shouldn't diverse core curricula emphasizing reading, writing, and effective skills get more attention?

Do we understand the differences between "IT" training and "CS" training? What's a business programmer, and how is that different than a programmer? Is the goal to teach programming, or is it to teach computer science? Or are we just talking about teaching computer use? Since when is a computer science degree required to use a computer, or even administrate it?

How do you define "readability"? Does resemblance to a natural language suffice? Is this a good thing? Remember one notorious attempt to create a programming language that even non-programmers could use cursed us with Cobol. Wouldn't it be nice to avoid that next time around?

Is readability culturally biased? Can a language designed to be easy for Unix users to learn be equally easy for non-Unix users? Can a language designed to be easy for non-Unix users to learn be equally easy for Unix users? Think of it this way: Does your knowledge of Greek help you learning Russian? Is it the character sets, or are there more important underlying similarities? Is a language designed to be used by people who know language XXX going to be different than one designed for those ignorant of XXX? Do semantics grow out of syntax (ordering, positioning), or should they be explicitly reinforced by inflection markers (singular vs plural, noun vs verb, etc)?

Should a programming language require a fancy, hand-holding IDE before it can be used effectively, or should a line editor suffice? How much hand-holding is useful to the beginner but annoying to the expert? Can you make a programming language that's designed to be completely learnable in a very short time that doesn't rule out its use later down the road? Is "user-friendly" well defined? Does "user-friendly" always denote "expert-hostile"? Will software that pleases one set also please the other set? Should it? Are languages designed for short-term use or long-term use? Where then should optimization occur?

That's certainly plenty to think about, and mostly what I just did is provide important questions that should be thought through. In many of the questions, there is no single right answer, but there are consequences. Try answering the questions in more than one way, and then compare the resulting trade-offs that arise depending on which path you took.

2. Answers

I certainly don't have all the answers to those questions. But I do have some comments on the Perl matters. The first is that Perl and Python are actually essentially the same language, and that there are a great deal of other sorts of languages out there that a computer scientist should be exposed to. Much like the warning to beware the man of one book, also be wary of the programmer of just one programming language.

And before you can begin to compare two languages, you actually have to know them both! Oh, not necessarily with equal fluency, but you actually have to have taken the time and energy to play with them, to sound them out in real situations. Superficial assessments based upon surface appearances are useless.

The "scripting language" versus "programming language" bigotry is nothing but cultural arrogance borne out of theoretic ignorance. I'm aware of Ousterhout's paper, and I have responded to it before. John is a very bright man, but like all of us, he carries with him his own historical baggage from the past and unfolding agenda for the future.

In this case, this a false dualism of "scripting" versus "programming" does nothing but harm. It has virtually no basis in theory, and little in practice. The assertion that byte-compiled Perl or Python can't handle certain tasks but that by merit of being compiled to machine language, C or Pascal or Ada or Modula automatically can--well, this is completely ludicrous.

Rob Kolstad long ago conjectured the following: "The success of a new programming language is directly proportionate to its resemblance to C." Perhaps a more accurate statement would be "The degree to which a new programming language will be embraced by C programmers is directly proportionate to its resemblance to C." And now you can swap in other programming languages in that equation.

As far as real-world programming goes, I assert that the majority of it gets done using C or a derivative of the same; and yes, I consider Awk, C++, Java, and Perl to be derivatives of C. Now, I'm not trying to claim that this is the best of all possible worlds. I'm simply stating that it's the reality. And given that reality, overcoming the inertia to get existing C-oriented programmers to jump to a completely different programming language, such as Smalltalk, Lisp, ML, or Prolog, is non-trivial at best.

There was some question of non-Unix support for Perl. As far as non-Unix ports go, Perl runs on so many diverse sorts of systems that it's easy to lose track of them. Not only that, but it also ships (or will ship in the next release) as part of the standard O/S release. Perl in some form ships with, or can ship, with at least some systems from these vendors: Apple, BSDI, Be, Compaq, Data General, Debian, FreeBSD, HP, IBM, Microsoft, Novell, OpenBSD, Red Hat, SCO, SGI, Sequent, Siemens-Nixdorf, Slackware, Stratus, and Sun. Those are just standard systems. The major workstation vendors like SGI, HP, Sun, IBM, and DEC/Compaq are all shipping Perl with their current or upcoming release. That means it's in the standard vendor configuration, which is important to many people.

Of course, Perl I run on nearly anything, including: 3b1, aix, altos486, amigaos, apollo, aux, beos, bsdos, convexos, cxux, cygwin32, dcosx, dec_osf, dgux, dos_djgpp, dynix, dynixptx, epix, esix4, fps, freebsd, genix, gnu, greenhills, hpux, irix, isc, linux, lynxos, machten, mint, mips, mpc, mpeix, ncr_tower, netbsd, newsos4, next, openbsd, opus, os2, os390, posix-bc, powerux, qnx, rhapsody, sco, solaris, stellar, sunos, svr4, ti1500, titanos, ultrix, umips, unicos, unicosmk, unisysdynix, utekv, uts, uwin, and vmesa.

On the matter of Microsoft compatabilty for you MIS and IT types, we CS types have tried very hard to make sure that standard Perl programs try very hard to run everywhere. That doesn't mean you can't get at the Unix getpwuid() function or the Microsoft Win32::Process module if you want, but that's not the same as basic functionality that is expected runs everywhere. This includes portable systems programming as well. Basic systems programming functions in Perl like rename() and flock() are not restricted to those systems that support rename(2) and flock(2) syscalls, i.e. kernel traps. We use whatever emulation is necessary to provide the same semantics using whatever your system's primitives provide.

And we don't stop there. The POSIX fork(2) syscall, that simple, elegant, and incredibly powerful feature that has long formed an essential keystone for systems programmers, and one which Mr Bill has never figured out how to do, will be supported on Microsoft's systems as well. This will show up in the 5.6 release of Perl, which is now in late alpha and imminently passing into beta. That means your traditional multitasking server that calls accept() on a socket and then fork()s off a clone to handle the incoming connection will work even if you're a Prisoner of Bill.

If you aren't familiar with the wealth of Perl modules out there, or how easy it is to build and install them, you should look at this search engine.

Perl has seriously different design goals than Python. One of these was to be easy for Unix programmers to learn and use, both simple sh programmers and sophisticated C programmers. Another was to support incremental learning and incremental growth of the language itself. Another was to provide good support for multiple different programming styles (procedural, object oriented, and functional), which goes along with avoiding moral judgments about programming style issues and letting people program the way that comes naturally to them. Python supports both procedural and object-oriented programming reasonably well, but its support for functional programming is clumsy and unsatisfying. Without the nested lexical scoping in anonymous that languages like Perl and Scheme provide, there's only so much you can do. This is not in practice an onerous restriction, however.

Another was speed of execution; as a result of this design requirement, Perl's compiler is remarkably more clever than Python's, because it does quite a few more optimizations and special-case detection at compile time, so that run-time is more streamlined. This includes string-related issues like pattern matching, but also simple base programming features, such as when identifiers are looked up in symbol tables. Python was never designed to run fast, and by and large, it doesn't.

Perl was designed to conform itself to the programmer, not to make the programmer conform themself to the language. This is seen in the "do what I mean" (DWIM) principle. Matters such as memory management and strong typing are largely there to help the computer not the programmer. Because of this, you'll see Perl and Python take divergent paths when it comes to these matters. For example, Perl will automatically allocate space for strings, indexed arrays, and associative arrays as they are needed, without requirements of pre-growing the way Python's lists need. Another example is that Perl doesn't distinguish between 3/2 and 3./2 the way Python does. In Perl, a number is just a number, and if the compiler or run-time library needs to perform some promotions behind the curtain to do what the programmer meant, it goes and does it.

Perl was also intended to support short-cuts for common programming tasks so that expert programmers wouldn't be forever bogged down by spelling things out the long way. In short, it was designed to be expert-friendly, by which I mean that it did not become tedious for those who actually knew how to use it. One example of this is the multiple assignment statement of

@array[1,5,2,9] = @array[3,2,8,1];
# or likewise, via indirection
@idx1 = (1,5,2,9)
@idx2 = (3,2,8,1);
@array[@idx1] = @array[@idx2];

Some of Python's design properties were that explicit is better than implicit, that general cases are better than special ones, and that simple features are better than complicated ones--even when this makes the programmer to put the simple features together in complicated ways. But like any language that actually gets used, these goals are not always followed. Compromises happen. I'm not going to sit here and point out all the warts and knobs in either language. Rest assured that they are there.

Do not be distracted by Python's whitespace issue nor by Perl's type-markers. These are both red herrings that aren't related to the core of what the language can truly do. Interestingly, both of these features commonly cited as negatives were actually added to ameliorate not to exacerbate legibility.

Despite Perl and Python starting from different sets of design criteria, they are, in most of the senses that really matter, the same language, just as C and Pascal are really the same language. I strongly encourage anybody who only knows one of them to go out at learn the other as well as you can in a week or two's worth of playing around. Try to write equivalent programs. By and large, you'll find that the final program takes more lines of code in Python than it does in Perl, and that the Perl version runs faster than the Python one. But not usually by a large amount. Usually it's just 20% or 30%.

But if the problem domain happens to be text manipulation, (and not just sed and awk style either), then the difference can be far more dramatic. It is not at all unheard of to find that Perl requires just 1/3 the code that the Python does, and that the Perl version runs in just 1/10 the execution time. Perl is not just about text processing, and there is no tool that's best for all jobs. But if there's one place where Perl outshines all competitors, this is that place. Even people who are heavy users of Python often turn to Perl for these tasks.

Learn as much as you can.

There are only a few IDEs for both Perl/Tk and Perl/Gtk at this time, though it appears that more and more commercial tool developers are at least making Perl sensitive code editors these days. However, in reading through the comments this question brought forth I noticed that noone gave the CPAN directory for Perl/Gtk which is either: $CPAN/authors/Kenneth_Albanowski/
or $CPAN/modules/by-module/Gtk/ Which I hope will prove useful to some folks.

I think you'll find that either the Parse::RecDescent module or the Parse:Yapp module will do what you want. They're really very neat, although I've only ever spent much time reading up on the first of them.

I think you'll find that either the Parse::RecDescent module or the Parse:Yapp module will do what you want. They're really very neat, although I've only ever spent much time reading up on the first of them.

Off-topic, I'd appreciate some feedback on any particular collections of...

Actually, CPAN has this, although it isn't very populated yet. (Probably because most people don't know about it)

http://www.cpan.org/scripts

doog wrote:

What do you mean ASP modules exist for Apache? What are they called?

Check out Apache-ASP by Joshua Chamas.


According to Netscapes web site, LiveWire runs on Solaris.. If I can't run SSJS on Linux, then I have to convince the suits to buy solaris AND netscapes server which will cost more than NT.

Netscape's FastTrack server runs server side Javascript on Linux. It costs only $295, which should be easier for your bosses to swallow. Unfortunately, I don't think it handles ASP, you would need to convert those pages into some other form (which is a good thing in the long run).