About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2003.Dec.22 Mon
Some time ago, Todd Blanchard wrote:
Some time before C++ started to proliferate, the developers of most operating systems defined a standard binary object file format that all compilers would generate. It was common to use FORTRAN math libraries from C, Pascal, or COBOL programs. You could mix or match to your heart's content. The object formats were the same so the linker didn't care.
The introduction of C++, in a misguided effort to make use of existing linker technology, introduced a technique called name mangling and essentially broke the guarantee that object files were interchangable regardless of which compiler were used. C++ code compiled with different compilers couldn't even interoperate.
The end result was projects now had to select a single language for the entire project and stay with it. The cost of calling out to code written in other languages went up. Thus began the porting wars.
Companies now spend money to port significant portions of their existing software assets to the current darling in the language world. Even conservative aerospace companies have risked introducing new defects by porting reliable and fast math libraries written in FORTRAN to C++ just because "everything is going towards C++".
Suckers.
They did it again with Java for the same reasons. I expect they'll do it yet again with C# and .NET.
The real fact of the matter is that there has been no real progress in the software industry in something like 10 years. In fact we've lost some interoperability capabilities among programming languages.
As a side effect of changing the rules every year, experience is marginalized and hiring low cost unskilled programmers labor begins to look attractive. After all, even the old timers are going to have to learn everything all over. Thus, the endless march of new stuff for the sake of being new stuff nullifies the value of experience and hinders the development of masters in the field.
Fortunately some languages are easier to interoperate with than others:
Bruce Eckel: "Zope is the enterprise application server I use for my website. Zope is virtually all Python, but includes some C code, because they profiled and optimized Zope so it would run faster..."
Questions for Designing a Language
Questions to ask yourself when designing a programming language, via reflectivesurface:
- What need are you trying to fill?
- What's the metaphor? (OO, logic, imperative, functional, etc.)
- Is high performance an issue?
- Is high programmer productivity an issue?
- How portable across platforms do you want the language to be?
- and so on...
There are over 7000 programming languages, so think twice before creating a new one. If you're looking at creating a way to script your application there are several alternatives to creating a new language:
Python can be "embedded" in an application, and is free and cross-platform.
On Windows, you can export functionality in your application via COM, and thus any COM-compatible scripting language can then script your application -- VBScript, VisualBasic, JScript, Python, Perl, and so on.
On MacOS X, programming in Cocoa or PowerPlant make it fairly easy to make your application scriptable via AppleScript, and via AppleEvents (the supporting layer for AppleScript) your app can be scripted via Python and other languages.
Because Cocoa/Objective-C has bridges to/from Java, Ruby, Python, and FScript, your MacOS X application implemented with Cocoa can be scripted or interfaced with several other languages.
Java, Python, Squeak Smalltalk, and so on, are very 'portable' languages, but they are implemented in C, so C is even more portable (though portable GUI frameworks via C/C++ are problematic -- sometimes more trouble than they are work). Smalltalk and many other languages which have environments "built-in" actually restrict portability -- I can't write a TWAIN plugin in a portable dialect of Smalltalk, for example.
Unfortunately, popularity of a language does not correspond to fitness of purpose. Many people program in languages that are optimized for machine-performance rather than programmer-performance. CPUs are 100's of times faster now, compared to when those languages were designed, and for the most part these days, the CPU is idle most of the time.
Rather than trying to find cheaper programmers, businesses should be looking at a less "expensive" programming languages/environments/methods: ones that provide power and speed to the programmers who are the most expensive "part" of the process.
The obstacle is the path. -- Zen Proverb