Letters

Dr. Dobb's Journal April 2002

The Lightweight Language Workshop

Dear DDJ,

Eugene Kim's article "The MIT Lightweight Languages Workshop" (DDJ, February 2002) was an excellent summary — thanks. One point: The Python folks are definitely part of the MIT/Stanford culture and "get it" (functional languages, and so on). If you watch the python-dev mailing list (which I do for grins, being an old-timer in functional language design from the late '70s), you can watch them in action, and they definitely understand things.

In fact, I would say (from years of watching various languages) that Python more or less gets the most "right" of all the competing solutions. You have to experience it to understand it (I guess it's a Zen thing), but they really do have a wonderful, clean, simple, readable, exceedingly powerful dynamic language (esp. now that 2.1 fixed lexical scoping and 2.2 fixed the type/class dichotomy). Anyway, just my $0.02.

Chris Ryland
cpr@emsoftware.com

Dear DDJ,

Upon reading Eugene Kim's article "The MIT Lightweight Languages Workshop" (DDJ, February 2002), I disagree with the premise that programmers are language designers. We have been guided in to this belief by some very elite programmers, who are themselves quite lingual. One thing that the MIT crowd fails to realize is that the vast majority of people are not geniuses — just your everyday Joe. To believe that every programmer is a "language designer" is the same as thinking that every one that mispronounces your name is a "language designer." The thing that the people at MIT (and the rest of the think tanks) need to get over is how to build the next best {insert thing here} and deal with how we can best use the {insert already invented thing} better. The world does not need another language. What we need is for the languages to start speaking together and for users to start using the language correctly. I program in Perl, JavaScript, SQL, progress, expect tcl, shell, and Visual Basic, and have been involved in the computer industry for nearly 20 years.

Dave Waller
dwaller@charter.net

Strike One...

Dear DDJ,

Thanks to Jonathan Erickson's for his "Editorial" in the February 2002 issue of DDJ. Like myself, the friend who showed it to me is a former Lucent Technologies employee. We were hired by Bell Laboratories in the late 1970s and have left amid the turmoil at Lucent in the past year. As technical professionals in software development, we certainly had a strong desire to create and contribute, and to maintain the high standard of excellence that was once the hallmark of the Bell System. In our opinion, the conditions Jonathan describes at Boeing have also been developing within AT&T and Lucent during the last several years and have certainly contributed significantly to the problems those companies face today. Certainly the problems you describe are not unique to Boeing. I wish they were.

I think the conditions Jonathan described at Boeing are now typical of every publicly owned U.S. corporation whose business requires an engineering staff. Much has changed in the past 20 years. Increased competition and the desire for quicker profits have driven many corporations to do what Boeing had done. It is my observation that one highly respected company (with a reputation for excellence) after another has cannibalized their legacy to fight off competitive pressures and satisfy the demands of stockholders. Corporate management sees no choice but the get "lean and mean," creating a more "efficient" engineering environment where once proud professionals are treated like interchangeable and disposable cogs in the corporate machine. What's going to change this? Technical professionals uniting and going on strike? That might slow progress a little, but I doubt it will turn things around. Too much momentum has built up over time.

Professionalism is inefficient. A commitment to excellence requires a stable working environment where engineers are allowed to have a strong voice in their work, to experiment, make mistakes, refine their skills, and pass their experience on to their coworkers. There is no time for that now. There are always competitors offering quicker and cheaper solutions who don't have the same commitment to excellence. Sure, they may be gone in a few years because of their short-term focus, but in the meantime, they may seriously damage their more quality-minded competitors, make their management rich, and (if they end up killing off enough of their competition) even survive and prosper. Engineering skills — especially in software — become outdated much more quickly. Professionals have to spend much more time enhancing their résumés and less time cooperating with their teams and contributing to the excellence of their work. You never know when you will find yourself in a position to be downsized or replaced by [a] younger programmer with more "marketable" skills, lower salary requirement, and more time to spend on the job. Is this completely the fault of greedy managers, or is it just a sign of the times in our new, "global economy?"

Competition is healthy, but we have glorified it (often in the name of innovation) to the point where no one will say that there is such a thing as too much competition. "Good Enough Software" has replaced "Excellent Software" as the desired standard for the industry. It grabs market share and keeps the upgrade cycle rolling and the money coming in. Most customers don't want to wait for something that is designed well and works well the first time. They will flock to the first solution that is offered and, even when they adopt a particular solution, want to keep their options open in case something better comes along tomorrow. (After all, they have competition to beat too.) I think it's all part of a vicious cycle. Who knows how it will end?

Maybe we ought to face up to it. The "industrial revolution" in software has come, and cheap, plentiful components and programs stamped out at software factories are replacing those finely crafted systems that the local software guild used to produce.

Paul M. Dubuc
dubuc@earthlink.net

Correction

Figure 8 was inadvertently excluded from Alexander Pletzer's article, "Python & Finite Elements" (DDJ, March 2002).

DDJ