On Feb 16, 2009, at 12:12 PM, glen e. p. ropella wrote:
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.
At my previous job at a non-profit I could have written some systems
administration scripts/programs in Ruby or Python. I chose to write
everything in BASH (except one or two things I had to do in PERL)
because I felt it would be irresponsible of me to leave the job to a
recent college graduate (as occurred) who might not have had any
experience with Ruby (for example).
I guess my point here is that, if I understand what he is saying, I
agree with Owen about problem of the silo of IT vs. what I consider
"real programmers" to be doing. IMHO, the needs, considerations, and
motivations of a sysadmin writing maintenance/monitoring/reporting
scripts vs. someone hired to write a custom webapp for an organization
are quite different. I said I'd never dare call myself a programmer
because of my skill level, and because I don't get paid to write
software. I do mostly systems administration, in the context of which
I write programs as a consequence thereof. While it could be argued
that sysadmins get paid to write software too, I think many of of are
in a different league that is many echelons below the skill/experience
level of those of you who write functional applications of more
complexity, features, and containing more lines of code in a variety
of languages. Also I consider the "maintenance software" as more OS
level work and webapps or desktop applications more application-layer
programming. Returning to Owen's point, I wish to educate myself away
from the silo mentality and approach as I hope doing so will improve
my skills and work and potentially open the door to more versatility
for myself and the people I'm serving in doing my job (supporting
bioinformatics research).
To address the same point obliquely from another angle, my decisions
on script language are as much based on organizational and personnel
needs and sticking to longstanding and well-understood standards as
anything else; with particular emphasis on who would inherit the
maintenance of the software, however simple that software may be (RAID
hardware monitoring and reporting scripts). The last script I wrote in
PERL ran 2x faster when re-written in Python, but at 500ms execution
time vs. 1 second who cares other than me and does it even matter? At
my first real Unix job 13 years ago I was promised training I never
received and am grateful that the mission critical systems I was
examining in my learning process were running standard software and
relatively uniform shell scripts. I'm not sure how well I'd do if I
inherited the same situation today and %20 of the administration
software was written each in a different language (C, BASH, PERL, and
Ruby.....however similar they might be in some respects). But, from a
learning standpoint, both I and my successor's probably would have
learned more if I'd left the same script behind in two to three
languages (BASH, PERL, and Python) though in reality since time is my
most precious commodity and at a premium, it's unlikely I would have
been able to do that. As skill increases, however, this becomes
possible and is an idea that intrigues me.
When I was young and naive I complained about the way my predecessors
did things when I inherited scripts, Unix systems and the like. Today
my attitude is more that "if I don't like it, I should change it, and
if I lack the skill to do so I have no right to complain". From
another point of view maybe in my field the language of maintenance
scripts is irrelevant and it's the job of whoever inherits the job to
deal with what they find, or learn, or find another vocation. I don't
have a hard and fast answer to this question of "what's appropriate to
leave behind?" but I know I have tried to stick to basics and portable
maintenance programs (BASH) whenever I can, keeping in mind the person
who might inherit my work (instead of leaving a C binary and throwing
away the source code).
Lastly, I'm very grateful for this discussion as it's both very
interesting to me and I feel I'm learning from it. Thank you,
-Nick
----------------------------------------
Nicholas S. Frost
7 Avenida Vista Grande #325
Santa Fe, NM 87508
[email protected]
----------------------------------------
============================================================
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
