The ITworld.com Network   Network Search ¦ Sites ¦ Services ¦ ITcareers ¦ Product Finder  


Advertisement: Support Unix Insider, click here!

Home Home E-mail this article E-mail this article Printer-friendly version Printer-friendly version Tell us what you think Tell us what you think
Spacer
Spacer SEARCH
put phrases in quotes
Spacer
Spacer
Spacer
Spacer
Spacer NAVIGATE Spacer
Spacer Subscribe -- It's Free Spacer
Spacer Topical Index Spacer
Spacer Back Issues Spacer
Spacer UnixWHERE Spacer
Spacer Events Calendar Spacer
Spacer Community Discussions
Spacer
Spacer TECHNICAL FAQs Spacer
Spacer Solaris Security Spacer
Spacer Secure Programming Spacer
Spacer Performance Q&A Spacer
Spacer SE Toolkit Spacer
Spacer
Spacer ADVERTISEMENT Spacer
Spacer
Spacer

Spacer
Spacer
Spacer
Spacer UNIX INSIDER PARTNERS
Spacer
Spacer Spacer
Spacer ITcareers.com Spacer
Spacer Expert Advice Spacer
Spacer RFP Center Spacer
Spacer Training Center Spacer
Spacer Research Spacer
Spacer Vendor Content Spacer
Spacer
Spacer ABOUT UNIX INSIDER Spacer
Spacer Advertising Info Spacer
Spacer Unix Insider FAQ Spacer
Spacer Unix Insider Editors Spacer
Spacer Masthead Spacer
Spacer Editorial Calendar Spacer
Spacer Writers' Guidelines Spacer
Spacer Privacy Policy Spacer
Spacer Link to Us! Spacer
Spacer Copyright Spacer
Spacer BACK TO TOP Spacer
Spacer

Pulling different threads

Support means something specific to each language

Summary
At the beginning of the month, Cameron and Kathryn offered advice to those trying to decide which of the popular scripting languages to learn. In this installment of Regular Expressions, they compare languages in more depth, with regard to the specific technical status of threading. (1,100 words)


  REGULAR EXPRESSIONS  

By Cameron Laird and Kathryn Soraiz
Remember the main points we made before:

  • Languages' capabilities have converged
  • You must learn a lot before you know which differences between languages truly matter to you
  • Social factors are important

Feature charts typically anchor comparative articles. We can't do that, though; for us, feature checklists hide more than they reveal. While the languages certainly differ, sometimes even in specific dimensions, it's hard to reduce any of those dimensions to a single value. We've run tests that said Perl was 14 times faster than Python, and tests that said it was 4 times slower. Such foggy numbers can't capture the true character of these languages.

The languages have broad personality traits, though. You'll see a language differently as you learn about it and use it, and as the language itself develops through different releases. The essential character that remains constant is what our last column outlined. To enrich that illustration, we'll look at a few details that many programmers take months to stumble on.

Why thread
Application developers thread for two good reasons:

  1. It's one of several useful concurrency programming models, along with co-routines, event-based approaches, and others
  2. Certain system resources are best accessed through threading

There are also bad reasons to thread: quite a few programmers mistakenly believe that multithreading necessarily boosts performance or that it is the only way to build a GUI.

Threading capabilities reveal a great deal about languages. Perl 5.6 doesn't thread particularly well. More precisely, Perl mailing lists frequently rehash the specific errors and performance impairments in the current implementation. Perl 6is intended to be friendlier to threading.

These minor disabilities seem to have done little harm to Perl. It's a capable general-purpose language and is more widely used than any of its scripting peers. One way to explain this is that threading is largely dispensable; you can usually achieve results without threading. When Perl needs multiprocessing, it most often forks or selects.

Python threads well worn
Python takes almost the opposite approach. Perl won its first fans for its ability with batched administrative reports and the kind of text-mangling found in the Web's Common Gateway Interface (CGI). Python, in contrast, was designed to express general algorithms with a more academic or educational flavor.

Thread has been a built-in Python module since the 0.9.x versions almost a decade ago. Python threads are quite mature and well-behaved, but they occasionally surprise their users. That underscores one of the points of this article: comparing languages based on generalities and abstractions has severely limited value. Details matter.

Here's an example: Java is proving to be an entirely effective system programming language for many development teams. Its concurrency model is quite inadequate for highly multiplexed data, though. It's difficult to wring adequate responsiveness from Java threads when you are managing more than a couple dozen distinct channels. This is crucial for some projects, of course, but how many engineers know ahead of time to assess that particular detail?

Python threads also have a particular character that meets the needs of nearly all Python programmers. Briefly, Python threads are cooperative, rather than preemptive, with respect to system operations. That means an entire Python process stalls while a particular Python thread finishes a computation coded outside of Python. Thus, a network name resolution, database retrieval, or expensive engineering calculation can freeze a Python application.

Few Python programmers worry about this. Python threading meets the most common requirements. The processwide run lock is an issue only for relatively specialized requirement sets.

Tcl arrives late but handily
Tcl's threading is different from Perl's and Python's (and Java's too, for that matter). Tcl has a long history of hostility toward threads as a concurrency model: Tcl creator John Ousterhout once wrote an essay called "Why Threads Are A Bad Idea."

However, Tcl makes good glue. With the introduction of programmable threads in the 8.x sequence of releases, Tcl can thread in ways difficult for Python. Tcl doesn't aspire to match Python's sophistication in syntax or object orientation, for example. However, it's always been paramount in Tcl to handle external code written in other languages. Therefore, Tcl threads encapsulate system-level capabilities more flexibly than Perl or Python.

Here's an example: Kevin Kenny, a computer scientist at the General Electric Research & Development Center, is responsible for the NBC network control room's software. Tcl's threading capabilities have been crucial to his success in accessing a variety of system resources available through Win32 APIs. "You must use threads to manage them," Kenny said.

Summary
It's hard to compare languages meaningfully. Even when we restrict our focus to one aspect -- like threading -- languages satisfy different programmers in different ways, because their requirements and expectations are so different. In this column, we usually concentrate on principles that apply to several languages, and we always try to ground our observations in specific examples that you can test out.

Reaction to our last column underscored the subjectivity of language comparisons. Correspondents have written, "What I hate most about X is its illogical and complicated syntax," and X has taken on every available value. That reinforces our belief in the importance of a language's character at a level deeper than syntax or fashion, and so, for the third time in the last couple of years, we looked at how different languages manage concurrency. In March, we'll examine encoding of human languages, scripting and geographic information, and more. Good luck keeping your own threads untangled.

About the author
Cameron Laird and Kathryn Soraiz manage their own software consultancy, Phaseit, located within walking distance of Houston city limits. Visit Cameron's Future Computing discussion in the Linux forum, hosted on ITworld.com.

Home | Next Story | Mail this Story | Printer-Friendly Version | Comment on this Story | Resources and Related Links

Advertisement: Support Unix Insider, click here!

Resources and Related Links
  Other Unix Insider resources  

Tell Us What You Thought of This Story
 
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough
 
 
 
    
 

(c) Copyright 2001 Web Publishing Inc., and IDG Communication company

If you have technical problems with this magazine, contact webmaster@unixinsider.com

URL: http://www.unixinsider.com/swol-02-2001/swol-0216-regex.html
Last modified: Monday, February 26, 2001