On Sun, 15 May 2005 13:53:33 -0500, <[EMAIL PROTECTED]> wrote: >>there are times when it's actually worth the effort to ... >Oh yes. Now, do you determine whether the trip is worthwhile >by examining hammers or by examining the nails? >(Language zealots all seem to have the problem >of looking only at the hammers;) >
You're too right about zealots only looking at the hammers but I also consider it a mistake to only look at the nails (the problems that need to be solved). When I make the choice (or often, get to make the choice) of which tools to use my main concern is what is being built rather than the tools used or the problems must be solved to build it. If I see any chance the "what" will evolve into something bigger, my main concern is if the tools used to solve the problem(s) will result in maintainable and extensible code. -It's just the way I try to be prepared for the inevitable mid stream or post facto requirement changes made by those without a clue. >>A Britt, a Scotsman, an Aussie, a Texan, a New Yorker and a Californian >>were sitting in a bar... >>-None of them could understand what the others were saying. >Better scope than "America and England are divided by a common language". >Since programming is an entropy reducing exercise, the style is used >to obtain leverage on certain aspects of the problem (claimed advantages) >at the expense of ignored and unknown aspects (unclaimed disadvantages). > I'm not one of those gifted vision, algorithm and architecture guys, so my approach is simplistic brute force. I'll use anything and everything to hack out a fast, dirty, rough draft solution to the problem. Some times it takes me a few tries, kind of like experimentation but once I figure out how to solve the problem, I can then go back to square one, pick the applicable tools and do it right. >>And perl is a dialect of LISP, isn't it? >Methinks this is too much like the "high-level" and "low-level" bit about >languages. >The level is in the use of the language, not the language itself. >I would guess that perl evolves to "do" LISP as opposed to "be" LISP. > >LISP suffers because it has exactly the right number of parentheses, >too many, and none of them optional. LOL! Yes, the parentheses problem in lisp closures is notorious but I think it's more of a human problem than a technical one. For example, when you read perl code you see countless $, @ and ; characters all over the place identifying variables and line endings but by some magic your mind learns to kind of skip over them. In lisp you've got all these parentheses, and a good chunk of them are stacked up at the end of blocks. For some strange reason, it's tough to learn to just ignore them and see the meaning. It may be a matter of practice or some failing on my part (since I've worked in LISP based languages for years) but I think the root of the problem is that they are just not "natural" enough. When I type "teh" you somehow know it was just a simple mistake. When I type "Micro$oft" you still recognize and understand the pattern. The extensive bracketing in LISP based languages results in patterns that are just not similar enough to the common errors that we normally learn to "read through" when mentally parsing the character patterns. Worse yet, it's tough to differentiate between ")))))))" and "))))))))" even though the difference is very important. >LISP has an advatage in that it is possible to say exactly what it intended, >without a lot of extraneous baggage going along for the ride. >For any particular context, it is relatively easy to do something better >than LISP. >If the context is unknown (or worse if what is "known" is wrong) >then LISP has the advantage. Aproximately. >Hammer strikes nail. Hammer shatters. Nail just sits there. >Nail is driven in eventually. Nail is driven in quickly and efficiently. >How good does the hammer have to be so that the nail doesn't win? >What I like about PHP is that it is possible to use it effectively, >without taking the time required to learn PHP. The functions are irregular >because PHP prefers not to get in the middle of the mess. >This has of course the disadvantage that it will NOT stretch very far. >(Which applies to any language, even LISP;) > >Composition of functions is associative. >Gaining leverage on that fact tends to be rather lispy. >I suspect that perl will employ a different tact (than LISP). >Functional code, even straight-forward top-down brute force, >is not as ineffecient as one might imagine. >Any leverage will dominate the so-called language efficiencies. > I agree language efficiencies are a myth. Though one could argue, and many do, that particular programming languages are "more efficient" for particular classes of problems, when you get down to the business reality of paying salaries and getting things done, the bulk of efficiency is always in the practitioner. For example, I've got a friend who is fluent in some 20 different human languages. She is undoubtedly smart and skilled but still, I know better than to ever ask her for directions or try to eat anything she cooks. ;-) JCR
