Loading ...
Sorry, an error occurred while loading the content.

241Re: [feyerabend-project] An introduction to Lisp

Expand Messages
  • Erann Gat
    Aug 21, 2002
      > Dirk Riehle wrote:
      >
      > > 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?

      It depends on what kind of product the company makes.

      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
      understatement.

      <rant>
      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.
      </rant>

      E.
    • Show all 22 messages in this topic