Nice, though dated, article
Here's a nice, though dated, article: New Tricks for an Old Dog.
One interesting practical application that uses embedded Smalltalk is an 8-line PBX (private branch exchange) telephone system with integral voice mail... Most amazing, perhaps, is the time scale needed to develop the application: It took four engineers just nine months to bring the product to field testing, and a further three months to go to market.
-----
Smalltalk's fast development times and small development teams are corroborated by numerous practical examples. EDS estimates that development time in Smalltalk is about one-fifth that of development in C++. And a European bank that recently rewrote its client management software using OTI's Smalltalk cut the size of its development team from about 1,000 (COBOL) to fewer than 100 (Smalltalk) programmers, who now write more complex systems in the bargain.
-----
Clohessy claims that only 10% of a typical application is speed-critical, and these speed-critical parts are the only ones that need to be written in C (or assembler).
Or Fortran!
One interesting practical application that uses embedded Smalltalk is an 8-line PBX (private branch exchange) telephone system with integral voice mail... Most amazing, perhaps, is the time scale needed to develop the application: It took four engineers just nine months to bring the product to field testing, and a further three months to go to market.
-----
Smalltalk's fast development times and small development teams are corroborated by numerous practical examples. EDS estimates that development time in Smalltalk is about one-fifth that of development in C++. And a European bank that recently rewrote its client management software using OTI's Smalltalk cut the size of its development team from about 1,000 (COBOL) to fewer than 100 (Smalltalk) programmers, who now write more complex systems in the bargain.
-----
Clohessy claims that only 10% of a typical application is speed-critical, and these speed-critical parts are the only ones that need to be written in C (or assembler).
Or Fortran!
posted by Darkest Knight | 4:52 PM
1 Comments:
Just in case you think I’m talking through my hat...
In the course of my 20-year-long career as a software developer, I’ve worked for more than a dozen companies. I’ve worked on about 18 software projects. I’ve worked in something like ten different application domains (including database, real-time, enterprise, device drivers, graphics). I’ve used Fortran, C, C#, C++, TAL, assembler, on Unix and Windows PCs, S/370 mainframes, AS/400, DEC machines, Tandem NonStop, Modcomp. In short, I’ve accumulated a heck of a lot of experience under my belt. I...have...seen...it...all.
And I know how software tools can negatively affect programmer productivity (and cause slipped milestones). Thanks to Per Brinch Hansen, since the late 1980s I have come to appreciate simplicity in language tools. Once I got started learning Smalltalk, I immediately saw its potential for easing the programming task, thanks to its simplicity and elegance. This immediate recognition should not be underestimated. It suggests that there is something very unique and special about Smalltalk, that it is the closest to the “ideal” programming environment that has ever existed. The question now remains: Will anything ever surpass Smalltalk’s superiority? (Rubyists will undoubtedly say yes, it exists now! But I contend that Ruby is merely a different flavour of Smalltalk, not something much different or improved.)
One Internet poster suggested that Smalltalk has nearly all the necessary attributes to take the IT world by storm. The only outstanding thing, he says, is to make Smalltalk “sexy” to CIOs, CTOs, and corporate managers around the world. It reduces to a marketing problem.
Post a Comment
<< Home