April 25, 2024
Conclusion
Many years ago I trained to be an aeronautical engineer at The City University in London. Like many engineers I was taught, not very successfully, FORTRAN. If you needed a number cruncher, this was the language of choice. Students were expected to write a program and enter data taken from a wind tunnel test, or some structural loading experiment. Holes were punched into a bunch of small IBM cards by hand and carefully ordered. One card out of sequence would result in disaster.
I would take my precious cargo into the bowels of the university, where the computer department housed its mainframe. Not that I ever saw it. One was inevitably confronted by some hairy postgraduate in a white lab-coat. After passing across the offending bundle he would growl something like, "Come back in a week." Computer scientists were not always blessed with much in the way of social skills. My programming skills were equally inept. When I returned to collect my printout, I would, more often than not, find the equivalent of half Norway's annual logging output. This was prefaced by one simple message - DID NOT RUN.
After several episodes of this nature I studiously avoided computing for another twenty five years, by which time the nature of the subject had been transformed. M206 was the first computing course that I took with the OU. All I can say is thank God/XeroxPARC for Smalltalk.
I'm going to point you to an article "Design Principles Behind Smalltalk", written in 1981, by Dan Ingalls at Xerox PARC. Here are a few quotes.
"The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone. Our work flows from a vision that includes a creative individual and the best computing hardware available."
"...human potential manifests itself in individuals. To realize this potential, we must provide a medium that can be mastered by a single individual. Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be changed or that is not sufficiently general is a likely source of impediment. If one part of the system works differently from all the rest, that part will require additional effort to control. Such an added burden may detract from the final result and will inhibit future endeavors in that area."
Some may think that Ingalls' article veers a little too much towards promises of spiritual rebirth, but if you can get past the tone of the article, it will pay dividends. Ingalls has something else to say about OOP.
"Instead of a bit-grinding processor raping and plundering data structures, we have a universe of well-behaved objects that courteously ask each other to carry out their various desires."
So there we have the OO paradigm in a nutshell. It's about objects that have responsibilities to behave in a considered manner; it's collaborative and it's about making requests of these objects to discharge those responsibilities. All in all, a quite civilised way of going about things; wouldn't you say?
Next page » Collections
Previous page « Booleans
⇑ Up to top of page