Thus spake glen e. p. ropella circa 16/02/09 11:12 AM > When I write a > program for a client and that client's requirements include taking over > and developing the code themselves, then choosing Java because "Java > developers are cheaper because there are more of them" is not only NOT > dumb, it reflects a "focus on your application domain, your reason for > creating the software in the first place, ...".
It IS dumb. Not for you as the developer, but on the part of the client for making it a "requirement." All the different ways it is dumb are too numerous to go into here - but many of them derive from the fallacy that developers are a commodity. > > Likewise, if I write a program that is intended to run on a > microprocessor and will hook up to devices that require high I/O rates, > then "it runs faster" is an excellent reason for choosing 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. The dumbness arises from a failure to take into account all the factors - most notably design - that could address and resolve the performance requirements. 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. > > > So what I hear you saying is choosing a language because of its _effect_ > is dumb, instead you should choose a language because of the _cause_ of > that effect. No, I am saying that you should seek an isomorphism between the language you choose and what it is that you want to express. All programming languages were created with a purpose, based on a philosophy and a set of values. This is very evident when you read the ACM history of programming languages books. If the intrinsic 'philosophy' of a language is at odds with what you want to say you will be forced to use convoluted and complex expressions to say what you want, while in another language your expressions would be elegantly simple. I am not talking about grammar here, but design. The increasing interest in domain specific languages is based, in part, on this idea. > > But we've seen that > natural systems don't succumb as easily to solutions built with > linearized methods, which is why "agile methods" are so popular these > days. > 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] davew ============================================================ 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
