What I can't wait for is when Apple patents the space character in file names. Whew! Imagine the royalties on the "Program Files" (c:\Progra~1 to 8.3 folks out there) folder.
This just in: Apple patents the technique of "double-click launching" to launch applications visually.
Computers will control our houses and your high definition television will be your main terminal
Someone will make a mobile phone that doesn't suck as a PDA (or a PDA that doesn't suck as mobile phone)
We'll all evolve more agile thumbs from "texting"
There will be One True programming language (not a troll)
Everyone will type on a Dvorak keyboard when not using a flawless voice interface that does what you mean and not what you say
We will bathe everyone in the electromagnetic glory of Wireless
As computers get faster and faster, and software gets more and more efficient, every user interaction will receive nearly instantaneous responses
VR is the next big thing
Build from a solid foundation and some of things will happen. Build from fragile abstractions and a sneeze will knock out the grid. The promise of technology is not the promise of earnings or market creation. How well does it help us live our lives.
In the quantum world the jelly beans don't know which color they are, in fact they are BOTH colors. It's not until they are actually exaimned that they decide which color they are and retoractivly enact that policy.
Ahhh... Polymorphic beans. Maybe Java is the One True Language.
"I was also hoping for more of a discussion on the practicalities of unit testing database-driven systems, where you frequently have to test business entities which are closely coupled to the database.
This is kind of like that joke: "Doctor, it hurts when I do this..." Seriously, avoid, where possible, coupling your classes (even persistent ones) to a database. The fact that you're having trouble testing these should tell you something about the quality of the encapsulation in your system.
It certainly was an eye-opener for my development team. We were working with an implementation of the Data Access Object pattern (Service class +value object + DAO = persistent component). What we found was that the further we got from the database, the more we were repeating tests. In other words,test that DAO can retrieve, test that it can write. Then test that the service can read, then that the service can write, and go check the database. Set up and tear down was a major pain, and only got worse, until...
We figured that we couldn't be the only ones to run into this issue. We started digging around the Wiki Wiki Web to find suggestions for how to factor our classes properly to make them easier to test. We turned up the Mock Object pattern. Basically, have the DAO implement an interface, then implement that same interface in your test. You now have a well factored class, and you can do setups and teardowns of data that doesn't exist.
Handling related instances is difficult, but that leads to the next refactoring... a domain model architecture with a service layer on top, and a o/r mapping layer underneath. But that's another story.
I've read many of your posts here on Slashdot as well as your web site. I've found your arguments to be well-written. However, many of your arguments are as subjective as some of the posters here. You say in your own writings, in fact, that you have difficulty thinking about things as objects with behavior. And that, in my _opinion_, is what it's really about.
Programming languages should be built for people, as they represent a communication channel between people and computers. Software texts often must account for communication to other humans, hence the need for comments.
Experienced language designers take this into account. Their experience also leads them to add things to the language to prevent or at least deter common mistakes. Those "good features" in Visual Basic you mention, have produced a history of unreadable and buggy code.
Where would you suggest today's application programmers spend their time? Is it more valuable, more marketable to learn a single OS / OE, a single database (and be a one-trick pony), or should they spend their time on learning a single, rich API that applies to multiple platforms?
I'll make no pretenses that Java is more machine-efficient than C, or that O/R mapping is faster than embedded SQL. I will say that I find domain logic easier to unit test in isolation when you use an O-O domain model with mapping. These test can be automated and even serve as a kind of usage guide to the software.
The point of this is, the Java language has an accepted and refined way to work at a reasonable level of abstraction. If machine-efficiency were always 'better' then we'd all use CPU specific assembly languages.
BTW: The popularity metric does have merit as an argument. Popularity leads to communities. Communities can work together to advance the state of the practice, to share techniques. You complained about this very fact in your essays. 'Not enough people are contributing to the advancement of Procedural/Relational practice,' you said. I believe you are correct, and the reason for this is industry support and community.
Regards,
Michael Murphree
The opinions expressed in this post are my own, and not necessarily those of my employer.
I thank you, and the other folks who replied here, for your explanations. I'll have to reexamine my opinion. I do, however believe that Joel had a point with regard to fonts designed for the screen. Sans Serif fonts, especially those designed to account for pixel-based representations tend to look cleaner, and less distracting than fonts not so designed.
However, my experience with displayed fonts is limited to Windows and Linux. On Linux, I can't bring myself to use Open Office (although AbiWord is not bad), because I find the fonts to be such a distraction. I resort to Emacs for text editing and then find some way to format it afterward (usually as an HTML document). At some point I'll have to try OSX.
After a throrough examination by the judge, she determined the X-Men figures could not, in fact, interbreed with humans.
Re:Computer lab or vocational education?... Both.
on
Maine School & Linux
·
· Score: 1
Indeed, this is true. Focussing on teaching a specific office automation application to students is not useful. That's why I found the answer to the question of "computer lab or vocational education?" a relief.
The article explains how the computer lab was used for a broad range of computer-based education efforts, as well as education about computers. Kintergarteners are using hand-eye coordination builders. Grade schoolers use drawing software. High schoolers learn anything from office automation to research skills to advanced computer programming.
The article also shows that a critical component to real education is in place:
The basic principles of any type of operating system, office application or other similarly grouped software are the same. A student who becomes proficient in Linux will not find themselves lost in a Windows environment. I have found Linux to be the more advanced of the two operating systems, yet our students are very quickly and easily learning it. The process of copying a file or formatting a paragraph is not so different between one operating system and the other. The important thing is we are able to offer the latest in hardware and software tools to train our students in these fundamental principles--something we could not do if we went with proprietary software.
Because the students are trained to understand the metaphor, not just the syntax (push that button to make text bold), the students have a more solid foundation for learning the different twists on that same metaphor.
At the same time, I don't think that Windows or Office will remain dominant. My company depends on Microsoft Office products today. But Microsoft has made it continually more difficult for us to keep what we have. First their new licensing push, then the fact that they chose to raise prices without adding any significant value.
I cannot speak for my company, but, in my opinion, Microsoft has begun to cannabilize their own market. In attempting to lock in users to revolving subscriptions, they will drive users to other alternatives.
I use Linux, Open Office, Mozilla, and Evolution at home. The metaphors are the same, the cost is significantly less, and as a programmer, I can appreciate the fact that the computer is under my control. Computing is not a service provided to me, in the same way that transportation isn't a utility because I own (lease) an automobile.
Teaching these students the underlying metaphor of computing will put them far ahead of other students educated in only the syntax. This is analagous to teaching phonics instead of rote memorization. Phonics explicitly teaches how to frame new words and phrases so they may be understood. This makes it harder to teach, but the payoff (in test scores and in long-term reading skills) is worth it. I think the same is true for computer use. Understanding the metaphor of graphical user interfaces, of computing in general, allows a user to get more out of the system they use, and allows them to learn new applications or software tools more easily. Linux is far superior to Windows in this regard. As the article mentions, Windows goes to great length to obfuscate the inner workings of the operating system.
Actually, the copy protection layer is a code wheel on the CD that you have to slide into the right position according to a sticker on the jewel case. MS stole the idea from computer games...
...when they decide to do something (and do it right, well as much as can be expected) they can be the unstoppable force...
Agreed, so Sun, Oracle and Microsoft should be scared right now. IBM is making the right moves with Java and Linux: sell services and hardware. With IBM's services comes an integrated tool suite: Eclipse --> Web Sphere Studio --> Web Sphere --> DB/2.
I'm not saying IBM's technology is the best (JBoss beats WebSphere's architecture, for example), but in crafting the market they are making the right business moves in a very thoughtful manner. IBM is building massive inertia. You might say they've decided to be the next IBM.
Of course not. Why would you assume I condone piracy in any form, simply for voicing an opinion contrary to yours?
Your assumption aside, the idea that this is 'their rightful property' is interesting. I'd suggest, rather, that the original work should be the artist's rightful property. If I buy a recording of that work, I should have reasonable rights to do what I please with it (time-shift / location-shift / make backups). Reasonably, I have no right to sell copies for a profit over the internet, (or give them away for that matter). But the RIAA should have no right to dictate that a music CD won't play in a computer. They should have no right to require me to buy a crippled device. They should have no right impose damaging restrictions on the consumer electronics industry.
We don't think they're evil, we think they are greedy. Most of the RIAA's actions toward computer and consumer electronics technology have been driven by a desire to control their customers. Many of the industry's business plans were built around locking in customers to pay-per-use media distribution schemes or straight CD sales.
Recently, they've tumbled to the fact that campaign contributions can cause legislation to skew in their favor. They've "requested" laws that make fair use illegal, and require that disabling technologies be embedded in any consumer device. Essentially, they've asked the U.S. government to create a "safe" market for them.
There's a precendent for this: RCA attacking, then coopting the whole television thing out from under Farnsworth (television's inventor).
The RIAA's actions do little to prevent piracy. For example, the measures asked for only apply to the U.S. electronics market, and the most serious piracy happens overseas, in China. China's suppliers will not manufacture devices for that market that include crippled features when it is cheaper to manufacture and sell devices with all the features enabled. The manufacturers would be forced to add the technology to sell in the U.S., but they'd simply raise the price a notch or two to compensate.
The RIAA's moves are bad for consumers, and especially bad for computer-literate folks like those at/. Evil? Perhaps not, but very, very greedy.
I agree with Rick the Red's response. I think you're forgetting how powerful an accurate conceptual model can have on a user's ability to get work done.
Good user interfaces present a metaphor that allows a user to form a mental picture of what's happening underneath. The better a user understands the abstraction they're dealing with, the more likely they are to find new ways of working with the system to accomplish their goals. Good UI design guides a user by plainly showing the consequences of an action before that action is performed.
For example, a command button that is visually grouped with a text entry box immediately suggests to a user that operating the button causes the software to act on the text in the box.
Properly exposing underlying business metaphors (implemented with classes) through a user interface should allow the user more freedom to compose behaviors to accomplish work. There's also the potential to produce a community of users that are more clued in to what they're doing and why. This allows them to have a greater stake in the system by contributing meaningful requirements.
I can't tell you if Naked Objects does this the right way, but the idea is good. Rather than show a 'sorry state' as you put it, I think it shows a willingness to experiment with enabling users rather than thinking of them as stupid cash generators.
IIRC microchips and the integrated circuit were invented and developed by Americans (Jack Kilby and Robert Noyce, respectively), in America (Texas Instruments and Fairchild Semiconductor, respectively).
These two technologies combined had more to do with the industry of computing than the Alan Turing's team. Turing certainly produced foundational thinking with regard to computing (symbolic processing, in particular), but computers were unsuitable for mass production, and hence 'consumption' until the advent of the microchip.
First, let me apologize for the tone (it was late, I was cranky).
Second, let me say I agree with your last point. UML is a means to an end. That end might be (a) the germ of an understanding of code that doesn't exist, or (b) the germ of an understanding of code that does exist. Either way it serves as a starting point.
Third, I've walked an inexperienced team through visual dependency analysis and helped them understand how to reduce coupling, and how to predict side effects through visual structural analysis. Again, digging through (or crafting) the actual code is always required to fix the problems, or create them in the first place. The team builds UML models together, on a whiteboard, to build an understanding, and then code. The team builds UML models in a tool to generate a skeleton, and then code. The team also uses UML (reverse-engineered by a tool) to visualize the software text and look for obvious opportunities for refactoring.
But UML is only the starting point for all of these things. We depend on each other, and on each other's skills in crafting code to produce something that works well. For us, UML is the circuit diagram that helps us conceptualize the intricate IC we're staring at (or will build).
I agree that only by transforming those "bubbles and boxes," as you put it, into functioning software that the abstractions are useless. But if those abstractions can amplify understanding earlier in the process, as good abstractions usually do, then they are certainly worthwhile.
You're kidding, right? UML is a notation, not a political movement, not a religion, and not a tool, either.
It's all about abstraction, and in the case of the UML, it's about having a common visual abstraction so that developers can share ideas and discuss (visually) the design of software.
I suppose C is evil because it abstracts memory handling in a common way to make it so more developers can understand. Just as C enabled the creation of more complex and more powerful software, so, too does UML provide a stepping stone.
You argue that people automatically will use it to gain a superficial understanding of code and fix something, only to be drowned by 'nuances.' Perhaps if UML had been used in the first place, the developer who originally wrote the code could make a quick visual survey of the coupling and cohesion in the system and eliminate those side-effects (nuances by another name).
There aren't any silver bullets, and some people use UML tools carelessly, and most UML tool vendors make silver-bullet claims, but that has nothing to do with the UML.
At its heart, Design-by-Contract is an API description mechanism (think assertions). For any given method on a class, you specify what must be true in order to call it (preconditions) and what it guarantees will be true once it has finished execution or has errored out (postconditions, exceptions).
In Eiffel, however, this kind of specification is given some heft in terms of compiler support. Design-by-Contract is especially useful when defining an interface between code bases (IOW: public APIs). DbC gives client programmers of a class insight into how to call the class, and gives the language a way to enforce and check for that.
Eiffel is an object-oriented programming language designed to be replete with O-O-ness (no, really). For example, their are no primitives in Eiffel, everything is an object. Eiffel also has a singly-rooted hierarchy and garbage collection (like Java) and parameterized classes like C++.
Unlike Java, Eiffel syntax was designed to also act as a specification language of sorts, including syntactic support for contract specification.
Bertrand Meyer's book Object-Oriented Software Construction explains problems in modern software development, examines how object-orientation probably could solve them, then designs such a language. This language turns out to be Eiffel (sorry for the spoiler if you intend to read this > 1000 page book).
One of the points Meyer demonstrates is how a syntax to describe groups (classes) of solutions gets fleshed out into actual software that may execute. Eiffel, being that syntax, among other things, was intended to make you think in terms of types of objects sending messages to each other to get work done.
That said, I use Java. Why? Apache's Jakarta project.
Don't buy it, convince your friends not to buy it, but more importantly, make sure that the corporate specified standard machine does not include Palladium.
Consumer avoidance of DIVX (from bad word-of-mouth) killed it. Granted, consumers had competition to run to: DVD.
In the computing arena, consumers don't really cause battles to be won or lost, businesses do. If you can convince your boss not to buy it for the fifteen people in her department, or convince the hardware folks to avoid buying it for those 5000 or so people who need faster hardware, you'll see the hardware makers respond by providing a non-Palladium flavored version. Bulk wins, and money talks, but word-of-mouth counts too.
Slashdot Mirror
...Matrix star Keanu Reeves replied: "Whoa."
All your icons are belong to us...
What I can't wait for is when Apple patents the space character in file names. Whew! Imagine the royalties on the "Program Files" (c:\Progra~1 to 8.3 folks out there) folder.
This just in: Apple patents the technique of "double-click launching" to launch applications visually.
In the future:
Computers will control our houses and your high definition television will be your main terminal
Someone will make a mobile phone that doesn't suck as a PDA (or a PDA that doesn't suck as mobile phone)
We'll all evolve more agile thumbs from "texting"
There will be One True programming language (not a troll)
Everyone will type on a Dvorak keyboard when not using a flawless voice interface that does what you mean and not what you say
We will bathe everyone in the electromagnetic glory of Wireless
As computers get faster and faster, and software gets more and more efficient, every user interaction will receive nearly instantaneous responses
VR is the next big thing
Build from a solid foundation and some of things will happen. Build from fragile abstractions and a sneeze will knock out the grid. The promise of technology is not the promise of earnings or market creation. How well does it help us live our lives.
Flush toilet, books == good
Pager, way-too-fast-food == bad
...Crawls back in cave...
Uhhh...
yeah, that's it...
Ahhh... Polymorphic beans. Maybe Java is the One True Language.
Or, if they really knew what they were doing, they only applied the SP to their test systems, and they hadn't finished testing the applications yet.
This is kind of like that joke: "Doctor, it hurts when I do this..." Seriously, avoid, where possible, coupling your classes (even persistent ones) to a database. The fact that you're having trouble testing these should tell you something about the quality of the encapsulation in your system.
It certainly was an eye-opener for my development team. We were working with an implementation of the Data Access Object pattern (Service class +value object + DAO = persistent component). What we found was that the further we got from the database, the more we were repeating tests. In other words,test that DAO can retrieve, test that it can write. Then test that the service can read, then that the service can write, and go check the database. Set up and tear down was a major pain, and only got worse, until...
We figured that we couldn't be the only ones to run into this issue. We started digging around the Wiki Wiki Web to find suggestions for how to factor our classes properly to make them easier to test. We turned up the Mock Object pattern. Basically, have the DAO implement an interface, then implement that same interface in your test. You now have a well factored class, and you can do setups and teardowns of data that doesn't exist.
Handling related instances is difficult, but that leads to the next refactoring... a domain model architecture with a service layer on top, and a o/r mapping layer underneath. But that's another story.
Greetings Tablizer,
I've read many of your posts here on Slashdot as well as your web site. I've found your arguments to be well-written. However, many of your arguments are as subjective as some of the posters here. You say in your own writings, in fact, that you have difficulty thinking about things as objects with behavior. And that, in my _opinion_, is what it's really about.
Programming languages should be built for people, as they represent a communication channel between people and computers. Software texts often must account for communication to other humans, hence the need for comments.
Experienced language designers take this into account. Their experience also leads them to add things to the language to prevent or at least deter common mistakes. Those "good features" in Visual Basic you mention, have produced a history of unreadable and buggy code.
Where would you suggest today's application programmers spend their time? Is it more valuable, more marketable to learn a single OS / OE, a single database (and be a one-trick pony), or should they spend their time on learning a single, rich API that applies to multiple platforms?
I'll make no pretenses that Java is more machine-efficient than C, or that O/R mapping is faster than embedded SQL. I will say that I find domain logic easier to unit test in isolation when you use an O-O domain model with mapping. These test can be automated and even serve as a kind of usage guide to the software.
The point of this is, the Java language has an accepted and refined way to work at a reasonable level of abstraction. If machine-efficiency were always 'better' then we'd all use CPU specific assembly languages.
BTW: The popularity metric does have merit as an argument. Popularity leads to communities. Communities can work together to advance the state of the practice, to share techniques. You complained about this very fact in your essays. 'Not enough people are contributing to the advancement of Procedural/Relational practice,' you said. I believe you are correct, and the reason for this is industry support and community.
Regards,
Michael Murphree
The opinions expressed in this post are my own, and not necessarily those of my employer.
I thank you, and the other folks who replied here, for your explanations. I'll have to reexamine my opinion. I do, however believe that Joel had a point with regard to fonts designed for the screen. Sans Serif fonts, especially those designed to account for pixel-based representations tend to look cleaner, and less distracting than fonts not so designed.
However, my experience with displayed fonts is limited to Windows and Linux. On Linux, I can't bring myself to use Open Office (although AbiWord is not bad), because I find the fonts to be such a distraction. I resort to Emacs for text editing and then find some way to format it afterward (usually as an HTML document). At some point I'll have to try OSX.
Thanks again.
Applying antialiasing to screen fonts makes them harder to read. Seei cles/fog0000000041.html
Joel on Software for the complete argument: http://www.joelonsoftware.com/printerFriendly/art
After a throrough examination by the judge, she determined the X-Men figures could not, in fact, interbreed with humans.
Indeed, this is true. Focussing on teaching a specific office automation application to students is not useful. That's why I found the answer to the question of "computer lab or vocational education?" a relief.
The article explains how the computer lab was used for a broad range of computer-based education efforts, as well as education about computers. Kintergarteners are using hand-eye coordination builders. Grade schoolers use drawing software. High schoolers learn anything from office automation to research skills to advanced computer programming.
The article also shows that a critical component to real education is in place:
Because the students are trained to understand the metaphor, not just the syntax (push that button to make text bold), the students have a more solid foundation for learning the different twists on that same metaphor.
At the same time, I don't think that Windows or Office will remain dominant. My company depends on Microsoft Office products today. But Microsoft has made it continually more difficult for us to keep what we have. First their new licensing push, then the fact that they chose to raise prices without adding any significant value.
I cannot speak for my company, but, in my opinion, Microsoft has begun to cannabilize their own market. In attempting to lock in users to revolving subscriptions, they will drive users to other alternatives.
I use Linux, Open Office, Mozilla, and Evolution at home. The metaphors are the same, the cost is significantly less, and as a programmer, I can appreciate the fact that the computer is under my control. Computing is not a service provided to me, in the same way that transportation isn't a utility because I own (lease) an automobile.
Teaching these students the underlying metaphor of computing will put them far ahead of other students educated in only the syntax. This is analagous to teaching phonics instead of rote memorization. Phonics explicitly teaches how to frame new words and phrases so they may be understood. This makes it harder to teach, but the payoff (in test scores and in long-term reading skills) is worth it. I think the same is true for computer use. Understanding the metaphor of graphical user interfaces, of computing in general, allows a user to get more out of the system they use, and allows them to learn new applications or software tools more easily. Linux is far superior to Windows in this regard. As the article mentions, Windows goes to great length to obfuscate the inner workings of the operating system.
Just my two cents.
Microsoft Corporation announced today the impending release of Microsoft WindowsTUX. Major features include:
OpenDRM: Digital Rights Management software under GPL
MDE: The new M Desktop Environment includes spinning flashing buttons you can skin!
NoIm: NotepadImproved will automatically add ^M characters after every carriage return!
Outlook Evolution: Use it to load test your system.
Expel: Hyperfast CD ejection
BSOKP: Blue Screen of Kernel Panic
JFS: Journalist File System - automatically publishes all your files to the entire Internet so there's no need for security.
Send Microsoft your firstborn child to reserve your copy today!
Actually, the copy protection layer is a code wheel
on the CD that you have to slide into the right
position according to a sticker on the jewel case.
MS stole the idea from computer games...
Agreed, so Sun, Oracle and Microsoft should be scared right now. IBM is making the right moves with Java and Linux: sell services and hardware. With IBM's services comes an integrated tool suite: Eclipse --> Web Sphere Studio --> Web Sphere --> DB/2.
I'm not saying IBM's technology is the best (JBoss beats WebSphere's architecture, for example), but in crafting the market they are making the right business moves in a very thoughtful manner. IBM is building massive inertia. You might say they've decided to be the next IBM.
Oh... Never mind. They are evil.
Of course not. Why would you assume I condone piracy in any form, simply for voicing an opinion contrary to yours?
Your assumption aside, the idea that this is 'their rightful property' is interesting. I'd suggest, rather, that the original work should be the artist's rightful property. If I buy a recording of that work, I should have reasonable rights to do what I please with it (time-shift / location-shift / make backups). Reasonably, I have no right to sell copies for a profit over the internet, (or give them away for that matter). But the RIAA should have no right to dictate that a music CD won't play in a computer. They should have no right to require me to buy a crippled device. They should have no right impose damaging restrictions on the consumer electronics industry.
But then, that's being reasonable.
Pardon me for speaking for many on /. but:
We don't think they're evil, we think they are greedy. Most of the RIAA's actions toward computer and consumer electronics technology have been driven by a desire to control their customers. Many of the industry's business plans were built around locking in customers to pay-per-use media distribution schemes or straight CD sales.
Recently, they've tumbled to the fact that campaign contributions can cause legislation to skew in their favor. They've "requested" laws that make fair use illegal, and require that disabling technologies be embedded in any consumer device. Essentially, they've asked the U.S. government to create a "safe" market for them.
There's a precendent for this: RCA attacking, then coopting the whole television thing out from under Farnsworth (television's inventor).
The RIAA's actions do little to prevent piracy. For example, the measures asked for only apply to the U.S. electronics market, and the most serious piracy happens overseas, in China. China's suppliers will not manufacture devices for that market that include crippled features when it is cheaper to manufacture and sell devices with all the features enabled. The manufacturers would be forced to add the technology to sell in the U.S., but they'd simply raise the price a notch or two to compensate.
The RIAA's moves are bad for consumers, and especially bad for computer-literate folks like those at /. Evil? Perhaps not, but very, very greedy.
I agree with Rick the Red's response. I think you're forgetting how powerful an accurate conceptual model can have on a user's ability to get work done.
Good user interfaces present a metaphor that allows a user to form a mental picture of what's happening underneath. The better a user understands the abstraction they're dealing with, the more likely they are to find new ways of working with the system to accomplish their goals. Good UI design guides a user by plainly showing the consequences of an action before that action is performed.
For example, a command button that is visually grouped with a text entry box immediately suggests to a user that operating the button causes the software to act on the text in the box.
Properly exposing underlying business metaphors (implemented with classes) through a user interface should allow the user more freedom to compose behaviors to accomplish work. There's also the potential to produce a community of users that are more clued in to what they're doing and why. This allows them to have a greater stake in the system by contributing meaningful requirements.
I can't tell you if Naked Objects does this the right way, but the idea is good. Rather than show a 'sorry state' as you put it, I think it shows a willingness to experiment with enabling users rather than thinking of them as stupid cash generators.
IIRC microchips and the integrated circuit were invented and developed by Americans (Jack Kilby and Robert Noyce, respectively), in America (Texas Instruments and Fairchild Semiconductor, respectively).
These two technologies combined had more to do with the industry of computing than the Alan Turing's team. Turing certainly produced foundational thinking with regard to computing (symbolic processing, in particular), but computers were unsuitable for mass production, and hence 'consumption' until the advent of the microchip.
First, let me apologize for the tone (it was late, I was cranky).
Second, let me say I agree with your last point. UML is a means to an end. That end might be (a) the germ of an understanding of code that doesn't exist, or (b) the germ of an understanding of code that does exist. Either way it serves as a starting point.
Third, I've walked an inexperienced team through visual dependency analysis and helped them understand how to reduce coupling, and how to predict side effects through visual structural analysis. Again, digging through (or crafting) the actual code is always required to fix the problems, or create them in the first place. The team builds UML models together, on a whiteboard, to build an understanding, and then code. The team builds UML models in a tool to generate a skeleton, and then code. The team also uses UML (reverse-engineered by a tool) to visualize the software text and look for obvious opportunities for refactoring.
But UML is only the starting point for all of these things. We depend on each other, and on each other's skills in crafting code to produce something that works well. For us, UML is the circuit diagram that helps us conceptualize the intricate IC we're staring at (or will build).
I agree that only by transforming those "bubbles and boxes," as you put it, into functioning software that the abstractions are useless. But if those abstractions can amplify understanding earlier in the process, as good abstractions usually do, then they are certainly worthwhile.
Regards
M. Murphree
You're kidding, right? UML is a notation, not a political movement, not a religion, and not a tool, either.
It's all about abstraction, and in the case of the UML, it's about having a common visual abstraction so that developers can share ideas and discuss (visually) the design of software.
I suppose C is evil because it abstracts memory handling in a common way to make it so more developers can understand. Just as C enabled the creation of more complex and more powerful software, so, too does UML provide a stepping stone.
You argue that people automatically will use it to gain a superficial understanding of code and fix something, only to be drowned by 'nuances.' Perhaps if UML had been used in the first place, the developer who originally wrote the code could make a quick visual survey of the coupling and cohesion in the system and eliminate those side-effects (nuances by another name).
There aren't any silver bullets, and some people use UML tools carelessly, and most UML tool vendors make silver-bullet claims, but that has nothing to do with the UML.
/rantAt its heart, Design-by-Contract is an API description mechanism (think assertions). For any given method on a class, you specify what must be true in order to call it (preconditions) and what it guarantees will be true once it has finished execution or has errored out (postconditions, exceptions).
In Eiffel, however, this kind of specification is given some heft in terms of compiler support. Design-by-Contract is especially useful when defining an interface between code bases (IOW: public APIs). DbC gives client programmers of a class insight into how to call the class, and gives the language a way to enforce and check for that.
Eiffel is an object-oriented programming language designed to be replete with O-O-ness (no, really). For example, their are no primitives in Eiffel, everything is an object. Eiffel also has a singly-rooted hierarchy and garbage collection (like Java) and parameterized classes like C++.
Unlike Java, Eiffel syntax was designed to also act as a specification language of sorts, including syntactic support for contract specification.
Bertrand Meyer's book Object-Oriented Software Construction explains problems in modern software development, examines how object-orientation probably could solve them, then designs such a language. This language turns out to be Eiffel (sorry for the spoiler if you intend to read this > 1000 page book).
One of the points Meyer demonstrates is how a syntax to describe groups (classes) of solutions gets fleshed out into actual software that may execute. Eiffel, being that syntax, among other things, was intended to make you think in terms of types of objects sending messages to each other to get work done.
That said, I use Java. Why? Apache's Jakarta project.
Regards,
M. Murphree
Don't buy it, convince your friends not to buy it, but more importantly, make sure that the corporate specified standard machine does not include Palladium.
Consumer avoidance of DIVX (from bad word-of-mouth) killed it. Granted, consumers had competition to run to: DVD.
In the computing arena, consumers don't really cause battles to be won or lost, businesses do. If you can convince your boss not to buy it for the fifteen people in her department, or convince the hardware folks to avoid buying it for those 5000 or so people who need faster hardware, you'll see the hardware makers respond by providing a non-Palladium flavored version. Bulk wins, and money talks, but word-of-mouth counts too.