Thus spake Prof David West circa 16/02/09 05:51 PM: > It IS dumb. Not for you as the developer, but on the part of the client > for making it a "requirement."
The client doesn't _make_ it a requirement, as if requirements are created willy-nilly by some air-headed marketing type (no offense intended). The client is living within a context full of constraints, some of which disallow the open-ended search for a more optimal solution. The requirements come from the objectives of the project and the constraints that obtain in the environment. It is definitely not dumb. It's reality. It's not dumb to derive requirements from the set of extant resources and constraints. And sometimes the derived requirements point explicitly to a particular language. > "Smalltalk is too big and too slow to use for telephone switching > systems with millisecond time budgets." "C runs faster than anything > except assembler." We are developing an embedded telephony switch > therefore we absolutely positively have to use C. Dumb!! I have seen > Smalltalk applications for telephone switches that outperformed C code > doing the same job with the added advantage that they took 6 months to > develop in Smalltalk and 18 months using C. Moreover, the C team were > all senior programmers with lots of experience writing C and the > Smalltalk team had less than two years experience with that language. Heh, all I can say is "so what?" Are you simply telling me anecdotes about how people have made premature and unjustifiable claims in the past? Well, ... duh! Obviously people make premature and unjustifiable claims all the time. But that doesn't mean that _every_ time someone chooses C++ over Smalltalk because of execution time, it automatically means they made a dumb decision or that their justification is dumb. Yes, if they jump to premature and unjustified conclusions, then it's ... well, premature and unjustified. But it may not be dumb! Perhaps that's the only justification they could come up with and if they spent the next 50 years trying to find a good one, they'd be laid off and another yahoo willing to "shoot from the hip" would have taken her place and made millions of dollars on an IPO? [grin] (with which she can then spend the next 50 years figuring out and yapping about what the _best_ language would have been) This goes back to my original point: requirements are often _complex_ and cannot be linearized or deconvolved without doing severe damage to the understanding of the problem or the solution. > The dumbness arises from a failure to take into account all the factors > - most notably design - that could address and resolve the performance > requirements. But if, say, C++ is explicitly _derived_ from the requirements, then it is a smart choice. Likewise, if Smalltalk is derived from the requirements, then it is a smart choice, regardless of any linearized conception you or any other outsider may have of the problem and solution under consideration. > Years ago, companies were demanding that all of their applications be > written in C++, because of speed and because of "features" like multiple > inheritance and friend declarations that "improved the efficiency of > your code." In the process they incurred millions of dollars of > technical debt for no real reason. Stroustroup himself admitted in a > keynote speech that in his career he had encountered exactly one > instance where he positively absolutely could not have satisfied > performance requirements without using multiple inheritance (and another > for a friend declaration) which means that 99.9% of the software written > in companies that mandated C++ could have been written in other > languages at less cost. That is absurd waste. [grin] You act as if you _know_ all the facts and circumstances. That's nice that you're so convinced. I remain skeptical of _both_ corporate policies mandating languages _and_ your accusation that these particular ones were an absurd waste. It reminds me of many of the "business process reengineering" people I've met. They often have _no_ idea of how efficient their current business processes are. They just know that they're getting pressure from their stock holders, board, and management to change _something_ ... _anything_ ... because the performance of the company (as measured through some myopic lens) isn't satisfactory. You think such a corporate mandate is a waste. But do you really _know_ that? Can you _demonstrate_ it? (or at least provide some experimental data to show that it was a waste ... "experimental" in the same sense as scientific data, by the way ... not some long-winded prophet who writes books for a living) > No, I am saying that you should seek an isomorphism between the language > you choose and what it is that you want to express. Again, you're linearizing the requirements process. Language choice is a result of all the _many_ and intertwined requirements for any given project, including the time you have, the money you can pay, the people you have available, _and_ what you want to express with the language. > So if you want to find elegant solutions for problems arising in natural > systems you should choose a language that was explicitly designed to > support exploratory, iterative, incremental, adaptive, and evolutionary > development; that is not strongly typed (because the real world is not); > that hides implementation details (like memory management); and, > supports the use of domain vernacular in its grammar, etc. etc. Sounds > like Smalltalk. [grin] Heh, _no_. I'll use whatever languages _allow_ me to find elegant solutions for problems arising in the particular natural systems I'm trying to represent. _Whatever_ languages they happen to be. Why? Because the objective is to actually get the work done, not pontificate on or wring my hands in subservience to "What One Should Do" ... like some 10 commandments of the Software God. It sounds like you don't actually object to formalized, repeatable, and communicable decision making processes. It sounds more like you merely require others to use _your_ formalized, repeatable, communicable process. -- glen e. p. ropella, 971-222-9095, http://agent-based-modeling.com ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
