241Re: [feyerabend-project] An introduction to Lisp
- Aug 21, 2002
> Dirk Riehle wrote:It depends on what kind of product the company makes.
> > If you were the CTO of a startup, and you would have to convince your
> > CEO to start development efforts using CLOS rather than Java, how
> > would you argue its case?
If the source code is actually part of the company's business strategy
(e.g. if the exit strategy is to be acquired, or the company provides
software consulting services or some such thing) then I would not try to
convince my CEO because developing in CLOS under that assumption is almost
certainly the wrong thing to do. (I think that's an unfortunate statement
about the state of the world.)
On the other hand, if the development language is not an integral part of
the business strategy (e.g. the software is purely server-side, no
strategic plan to be acquired, etc.), then it's a purely technical
decision and as CTO I would expect that to be my call. Again, no reason
to do any "convincing". (I might have to do some explaining, but that's
not the same thing at all.) I would expect my CEO to either support me in
my decision or ask me to resign.
The situation is very different if you're not in an executive position.
Then it gets much more complicated, and very often you really do need to
"convince" your superiors. To say it isn't easy is, alas, a serious
The whole situation with languages in software engineering has
always struck me as rather bizzare. The skills of a software engineer are
almost invariably defined in terms of the languages they use, which is to
say, in terms of the tools they use, not in terms of the tasks they
perform. Job ads ask for a "C++ programmer" or a "Perl programmer". If
you had the equivalent situation in, say, building construction you'd see
"hammer user" or "screwdriver user" instead of "carpenter." Of course,
you do see things like "forklift operator", but even there the task is
implicit in the tool. There's only one thing people do with forklifts,
which is move big pallets around. Not so with hammers, screwdrivers, or
programming languages. Writing software is (or ought to be) a lot more
like carpentry than it is like operating a forklift. I think that a big
part of the reason that so much software sucks is that businesses try to
construct software with employees whom they treat like forklift operators.
- << Previous post in topic Next post in topic >>