From: Quentin Crain Date: 2002-01-01T13:38:32+09:00 Subject: [ruby-talk:29930] Re: Ruby/Python: Software Engineering James/All: Embedded: At 09:06 AM 1/1/2002 +0900, James Britt (rubydev) wrote: > > > > > Enforcement of indentation, lack of what you call "line noise" and > lack of short cuts > > > have very little to do with quality of software. > > > > > > > This can quickly turn into another topic, but it seems to me if you use > > "classic" methodologies, then you might be right: You spend a bunch of > time > > facilitating communication outside of code (eg. w/ documents such as > > specifications, test plans, etc.)--you can then "afford" to have > unintelligable > > code, because it is explained somewhere else. If one follows "lightweight" > > process, then the code itself become more important, and must be more > than just "code". > > > > My environment happens to be one where "classic" documentation is > 'difficult' > > to implement and for whatever other reasons not done for the most part. > >The use of the word "classic" suggests that software development is a >mature field, with >a long, venerable history of knowldege and techniques. People have been >writing >code for less than 100 years. Calling anything to do with computers >"classic" >seems odd. (It makes me think of "classic rock"; might make sense in 200 >years.) Umm ... my interpretation of the above is that you did understand my meaning of "classic" (duly quoted), so its usage seems to be clear nonetheless. >I'm not convinced that writing software is engineering. I'd rather pick >my tools >the way I would pick drawing pencils or a violin; I want things that give me >freedom, not force me to work in a certain style. In short: It is not important to be able to draw, create music or code in "unnatural" styles. The point is to use the tools which are "friendly" without loss of power. Or do I miss something? > > > > Finally, if this is the case, then what is the benefit to Ruby > being/having: > > > > It is simple, straight-forward, ... > >I find Ruby makes it simpler to write code that does just what I want done. >It's easier to read, and easier to see what's supposed to be happening. I find Python makes it simpler to write code that when read by another is easier for them to see what I want done. > > > > > > If readable code has little to do with "quality software" then, well > ... that > > can not be what you meant to say .... > >Illegible code can still be well-designed, though it can be a major pain >to maintain. Readability goes beyond indentation and avoiding line-noise >shortcuts. >I've yet to hear of a language that prevents you from misnaming variables or >methods. (Hmm. Maybe we need a language that prevents variables names less >than five characters long; must have a least one vowel? Might be a start ...) Agreed--but why does this matter? Obviously anything/everything can be misused; but that does not mean everything is then equal. >Besides, enforcing decent coding style is generally not hard. The odd-person- >out gets ridiculed and ostracized by the other developers. :) > > > > > > Nobody will try to force you to switch from Python to Ruby. > > > > Unfortunately, this is NOT the case. When my group within my company > looks to > > improve productivity, one question is: Can we develop code better? Again, > > unfortunately, most people simply compare languages by their "features" > (eg. > > "pure"-OO or iterators). When asked: What about choosing a langauge > which is > > "friendly" towards one's problems *and methodologies*? one is dismissed > with: > > You can write bad code in any language. Well, sure you can, but why > *encourage* it?! > >I think you may be putting the cart before the horse. What looks like bad >code according to one design method may be fine according to another. If a >language >requires (or strongly encourages) following a particular philosophy then >it also >restricts you from exploring others. Agreed again. But just because a language says it does not restrict you does not make it true. Or better put, every language has a philosophy and restricts to it. Ruby is no different right? In fact, by being "pure"-OO it forces *that* particular philosophy (would it not?). >Evolving one's development philosophy shouldn't require you to change >languages >(though that may happen anyway). One day people will look back at XP and say, >"How quaint." Not because XP is wrong or misguided, but because it will >inevitably >lead to other, better things. You shouldn't have to ditch code because the >language forces you to think in a way you no longer find appropriate. I do not understand this. I hear you saying that I should not rewrite just because I have changed my thinking. Fine--but *new* code should be written in the way I find appropriate right? Otherwise, is not this saying: One should code in ways one does not think? That can not be very efficient nor productive. > > >... > > > > > > A language is more than its syntax--it ought to fit into a methodology, > > ... > >Perhaps it should be the other way around: Find languages that provide >clean ways to do most things with a minimum of fuss, and see what development >methods can be derived from their use. Unless I am misunderstanding this says: The tools should drive the methodology. I believe the needs of the developers (along with being human) take precedence. And I would be confused as to how things would go better when forcing people to act in "unnatural" ways, ways forced on them by their tool choices. >James > > > > > > > thanks!! <