Thus spake Prof David West circa 14/02/09 01:24 PM: > Language selection reasons like, "it is too hard to learn," "memory > leaks," "it runs faster," "Java developers are cheaper because there are > more of them," etc., are really dumb reasons for choosing a language. > Instead you should focus on your application domain, your reason for > creating the software in the first place, your working style, and how > well you truly understand the problem, and any potential solution to > that problem, you are trying to address.
This paragraph seems a little self-contradictory. 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, ...". The same goes with the "it is too hard to learn" justification. Often, the system requirements flow down to those justifications. And they're not dumb if they follow directly from the requirements. 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. Of course "it runs faster" is an oversimplification of the full complexity of the build process; but it's not dumb if it flows directly from the requirements. The requirements are the cause and the characteristics of the solution are the effect. 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. In reality, of course, systems engineering is not linear or acyclic. So, choosing a language based on its effect in a certain context versus choosing a language based on the requirements for the solution are _both_ perfectly reasonable.... and are arguably the same thing. Any attempt to linearize or factor systems engineering into disjoint justifications (like what a language was originally intended for or the desire to get children to learn it) will fail because there are always multiple, inextricably intertwined requirements for any solution. There are always multiple objectives, usually where many conflict. Of course, that's subject to the "80/20" rule. A linearized engineering process is usually be good enough, at least within the domains of engineered devices like bridges or computers. 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. -- 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
