Vincent Vercauteren

Congratulations and many thanks to ActiveState for providing the world with the ActivePerl 5.10.0 binary less than 24 hours after the official release! This rocks!

Oops… Almost forgot. This is to the Perl community what Alan Greenspan’s speeches were to the financial world…

Perl 5.10.0 is now out, the first in the 5.10.x major version series, after a five year long development process. There are many interesting new features, several of which are backported from Perl 6 development.

Given a software developer. She’s looking for the right language / tool to get her job done. Here’s her list of requirements / constraints (most of which are a result of corporate elitism and otherwise stifling bureaucracy):

• She wants to build small tools for internal company use, to complement existing infrastructure
  (That’s a heck of a euphemism there)
  
• Language / platform should be very quick to learn
• Productivity must be REALLY, REALLY HIGH, and we’re not talking traditional RAD here, but rather ‘the quick prototype is actually good enough for the job’
• Development tools must be affordable or even free
• She must set up a fully working development environment without administrator help
• Distribution must be extremely straightforward (again, not requiring administrative help)
• No vendor lock-in: must run on Windows, but if the company ever decided to switch to Linux, her tools should not be a hindrance (She has, well, … religious issues)
• Execution speed is not an issue, no math intensive stuff, but should a performance bottleneck occur anyway, she has to be able to easily inject her own C or C++ code to solve it.
• Lots of existing libraries should be freely available, so she doesn’t have to reinvent the wheel too often.

Now let’s take the general purpose class A languages from the TIOBE Index and see which might be appropriate:

1. Java: No Go
   • Distribution too dependent on administrative support (JRE availability)
   • Development too dependent on administrative support (JDK availability)
   • Productivity too low for quick prototyping
2. C: No Go
   • Productivity far too low for quick prototyping
3. Visual Basic and other Basic dialects: No Go
   • On .NET: similar development and distribution issues to Java
   • Other (compiled) Basic dialects: productivity too low
4. C++: No Go
   • Productivity far too low for quick prototyping
   • Very hard to learn
5. PHP: No Go
   • Dependent on administrative support for a web server
6. Perl: No Go
   • Relatively hard to learn
   • Injection of fast C code is not exactly straightforward
7. C#: No Go
   • .NET: similar development and distribution issues to Java
8. Python: No Go
   • No reliable single file distribution mechanism
9. Ruby: No Go
   • No reliable single file distribution mechanism
   • Immature libraries?
10. D: No Go
    • Productivity too low for quick prototyping
    • Quite hard to learn
11. Delphi: No Go
    • Productivity slightly too low for quick prototyping
    • Windows only (since Kylix was discontinued)

No one seems to cater for her needs… After a long tiring night of research, she comes across John Ousterhout’s Tcl/Tk (TIOBE position 31, currently) and finds it a perfect match.

Tcl/Tk : GO

I couldn’t explain any better why she chose Tickle than the Tickle guys themselves:

(copied from Tcl/Tk site)

There are probably as many reasons why people use Tcl/Tk as there are Tcl developers, but a number of reasons keep coming up again and again.

Rapid development

The most important reason why people use Tcl is that it gets their job done faster. In many cases you can implement applications 5-10x faster with Tcl than with other languages, especially if the application involves GUIs, string-handling, or integration. Once an application is built in Tcl, it can also be evolved rapidly to meet changing needs.

Graphical user interfaces

With its Tk toolkit, Tcl provides facilities for creating GUIs that are incredibly simple yet remarkably powerful. For example, the Tk canvas widget makes it easy to create displays with graphics, yet it also provides powerful facilities such as bindings and tags. The text widget provides sophisticated hypertext capabilities and more. Tk was designed from the ground up for the rapid development inherent in dynamic programming languages like Tcl; other, C++ based toolkits lack the simplicity and power of Tk.

Cross-platform applications

Tcl/Tk runs on Windows, Macintosh, and nearly every imaginable Unix platform. It provides high-level API’s that let you write code that works the same — everywhere — while Tcl/Tk worries about respecting platform differences, such as native look and feel for GUI’s.

Easy to learn

Tcl is a very simple language. Experienced programmers can learn Tcl and produce their first interesting application in just a few hours or days. Casual programmers can also learn Tcl quickly. Tcl is often used in situations where experienced programmers create a base set of facilities, and more casual programmers write Tcl scripts to customize those facilities, create business rules, etc.

Mature but Evolving

Tcl and Tk have been under continuous, active development and use by a large group of developers since the early 1990’s. Because of this, Tcl has had a long time to get right all those “finishing touches” real applications depend on: rock solid reliability, rich internationalization support, thread safety, high performance, portability, integration, networking support and more. And because Tcl is constantly evolving, new cutting edge features are being added all the time, yet always with an eye to the consistent quality and concern for backwards compatibility that Tcl has always been known for.

Extend, Embed and Integrate

Tcl is unmatched when it comes to integrating with other software. You can easily include Tcl as an embedded scripting language in an application, or make existing C, C++, or Java code look like it was built right into Tcl. The same features make it easy to use Tcl as a control language for special-purpose hardware or protocols, add a new GUI or network interface to legacy applications, and more.

Deployment

Dynamic languages often make deployment harder, because you need to get both the language interpreter and the application scripts onto the target machine. Most dynamic languages provide tools to “compile” everything into a single executable (Tcl has had that too, since about 1993). But Tcl/Tk goes way beyond those simple solutions, using technologies like the Tcl Virtual File System, and Starkits and Starpacks to make deployment more flexible, powerful and transparent. Other options allow commercial applications to protect their intellectual property, a rare capability in dynamic languages.

Testing

Tcl is an ideal language to use for automated hardware and software testing, and it may well be the dominant language used for this purpose. With Tcl you can easily connect to testing hardware or internal APIs of an application, invoke test functions, check the results, and report errors. Tcl’s interpreted implementation allows tests to be created rapidly, and the tests can be saved as Tcl script files to reuse for regression testing. If you are testing a software application, Tcl allows you to connect directly to lower-level APIs within the application, which provides much more precise and complete testing.

Network-aware applications

Tcl has a rich and powerful event-driven programming model that makes network programming easy, allowing clients and servers to be created with just a few lines of code. Networking, files, GUI events — all work the same way, making for a consistent, easy to learn and powerful programming style, without relying on extra libraries.

The Tcl community

Another attractive reason for using Tcl is the large and helpful community of Tcl users and developers. The Tcl community is a constant source of ideas, free extensions, applications, and technical support.

It’s free!

Tcl is open source — freely available, meaning you can do anything you want with it, including modifying it to suit your own needs or incorporating it into commercial products, no strings attached.

An exotic choice for an exotic situation? Maybe, if you strip off all managerial cluelessness and other corporate pathologies, it might just turn out to be a perfectly rational choice in a not so exotic situation.

Let’s end with some urgent advice for IT decision makers:

• The network is NOT the computer
• The framework is NOT the computer either
• Give users freedom: you are NOT the only one in the organisation with a working brain

Oh, did I mention that this post is by no means autobiographical?

Nice. A Google Co-op search engine dedicated to Perl.

Whenever I read things like ‘The network is the computer’, or ‘The desktop is dead’ or ‘Web-based applications are the future’, I always get a bit of a bad taste in my mouth.

Now would somebody please care to explain these things to me, because I don’t seem to get them…

AJAX-enabled applications run (preferably) in a number of different browsers. There’s actually more code that’s executed by the end user’s machine than in a traditional web application. Now instead of requiring the operating system infrastructure directly, like a desktop application, they require the browser infrastructure, which in turn is highly dependent on the operating system infrastructure. In exactly what way does this constitute a move away from the desktop?

With PC hardware becoming ever cheaper, is somebody going to try and sell me an appliance that can merely behave like a browser? How about all the hardware I connect? How about giving up control over data storage? Am I expected to accept all that to save, well, 50 dollars, or a hundred, maybe?

Am I expected to prefer the Gmail user interface in a browser, where I can’t even right-click, over a fully portable Thunderbird running from a memory stick? I currently have a 20 Mbit internet connection, the fastest I can afford… And when I run a ‘Web 2.0′ application, there is latency… Response times are not even close to those of traditional PC applications. Is anyone planning to solve this?

All in all, it seems to be about where the code sits, which abstraction layers (OS, browser, VM) are used to run it, and what distribution model is used. Not about where at least a large portion of it will be executed. That will be on the desktop, at home, at the user’s, and by a general purpose machine like a PC. There will be an increasing number of appliances dealing with information, but they’re not just going to replace the PC and its rich desktop ecosystem. We’re too far along for that, price-wise. Even industrial control systems, for instance, are moving away from ASICs to general purpose boards running general purpose kernels like Linux. Reliability is ever better, price ever lower.
Ok, I don’t want to pretend having a crystal ball here, but it’s really troubling to see so many people in the industry patting themselves on the back for how customer oriented they are, while in fact they are as far away from the user as they can be.

I remember a panel discussion at last year’s European Shareware Conference, about new, more secure authentication methods for e-commerce, like digital signatures. I apparently kind of asked the weirdest possible question, when I asked how this was actually going to improve my security as a consumer, who can, in the current situation, just get a refund from the CC company when there’s a fraudulent transaction with my card. In a digital signature scheme, will I be able to get that refund if my certificate has been tampered with? Is someone trying to push the risk onto the user? Good luck.

It’s clear: I just don’t get it. I guess I’ll just have to apply for a job at Microsoft.

C++ is, roughly speaking, a superset of C, so every valid C program is — almost — a valid C++ program. This means that, by and large, everything in our computing infrastructure is derived from C. Dennis Ritchie and Brian Kernighan probably didn’t envision this when they conceived C nearly 35 years ago, as a descendant of B. They wanted a high-level language to write the Unix operating system in. (High-level as opposed to: Assembler).
C is without a doubt the single most successful programming language ever. Here’s a (very) short list of a few things that are essential to our current-day computing infrastructure and written in C or its derivative C++. Note that the list includes operating systems, applications, and most importantly, infrastructure — interpreters, compilers or VMs — for other, more high level programming languages that are themselves extremely successful.

• GNU/Linux (C)
• MS-Windows (C++)
• perl (C)
• python (C)
• tcl (C)
• PHP (C)
• The Java Virtual Machine (C++)
• The Apache web server (C)
• MS Office (C++)
• MySQL (C)

No matter how exotic the application or the programming language, if you “recursively dismantle” its components, you’re likely to come across C somewhere.

C is simple and easy to learn, very portable across different system architectures, very fast. There’s a C compiler available for just about any operating environment. The programmer herself is responsible for memory management, and there is little or no error checking or assistance from the compiler. With great responsibility comes great freedom, however.

Slowly but surely, businesses are moving away from languages like C, which produce blazingly fast executables but consume massive amounts of expensive programmer time. They move to virtual machines, like the JVM or the CLR, or dynamically typed languages like Perl, Python, PHP or Tcl. Especially those dynamic languages are gaining ground fast, after having been dismissed or unjustly portrayed as toys by enterprises for years. Soon they will run on Parrot, a VM of their own; and Microsoft’s CLR as well as the community’s JVM have already been adapted somewhat to accommodate them.

But C and C++ can of course not be replaced entirely by the technologies that they are the very building blocks of. As low-level tools (let’s forget about Assembler), they’re unlikely to disappear for decades to come. However, a promising alternative is emerging. Walter Bright, the compiler guru and the man behind Digital Mars, has designed D, a potential successor to C++.

So much interesting stuff, so little time to learn.

Every time I come across inflammatory posts or articles in the forums where geeks meet, I can’t help but wonder what it is they’re actually fighting about. Apart from the obvious trolling, they tend to take sides, and defend a particular technology with as much ‘evidence’ as they can. When debates become heated, these arguments usually are unfair, the logic a bit too stretched, the technical ‘evidence’ a bit flawed. Some of these discussions are of the same level as “my car is faster than yours”, or even “my dad’s car is faster than your dad’s”.

Nevertheless, in some cases the technical arguments are sound. Take Perl vs. Python: both dynamic languages that are very successful. A prototypical dialog:

Camel> Perl is more expressive than Python.

Snake> Yes, but it has many peculiarities and that makes it hard to read and hard to learn.

Camel> A language shouldn’t be designed to be easy to learn, it should be designed to be easy to solve problems with for experienced programmers.

Snake> But not everyone writes code every single day. Some people are occasional programmers. Some write code in, say, Java most of the time. And it would take them too much time and effort to learn Perl. Furthermore, they wouldn’t be able to read their own code six months later.

Camel> People can write read-only code in any language. Readability depends on the programmer, not on the language.

Snake> That may be partially true, but Python encourages readability, while Perl encourages terseness.

Camel> In Perl, there’s always more than one way to solve a problem, some may be idiomatic and terse, but that’s your own choice.

Snake> All that ‘choice’ leads to factionisation. Several different ways of doing the same thing are just confusing, especially for newbies.

Camel> There we go again: newbies. A language isn’t meant for newbies. After a while people are not newbies any more, but experienced coders in need of a flexible tool that helps solve their problems quickly. A tool that makes easy things easy and hard things possible.

Snake> Sounds like they need Python then! Better OOP, batteries included, better maintainability.

(…)

This discussion could have continued forever. It didn’t go into too many technical details yet. The problem is however:
The Camel and the Snake are both right!

In the dynamic languages ecosystem, there’s room for both. Both are fantastic open-source projects with vibrant communities behind them, and both have their particular strengths. While e.g. Larry Wall is right about the newbies vs. experts issue, Guido van Rossum is also right: quick learnability can be important. It all depends on the situation. We should not fight, but learn and solve.

Camels, since it is indeed easy to learn the language of the Snakes, just learn it.

Snakes, don’t think the Camels get it wrong all the time, they are indeed amazing mammals.

Maybe we need something completely different, like a Parrot, to mend things a bit.

Recognise this?

“What is it you’re doing? Perl? Oh,… Some scripting eh?” (fake smile included).

Then read this article by chromatic (an influential voice in the Perl community).

The guy that was sitting next to me most of the time has written an excellent summary.