UT Lisp Users Group?

Michael Halcrow mike at halcrow.us
Wed Jul 13 19:16:50 MDT 2005


On Wed, Jul 13, 2005 at 03:26:29PM -0600, Gabriel Gunderson wrote:
> Give me what works and what works well; I'll use it.  I'll look at
> the other languages for fun but go back to what I know to make
> things work.

I have implemented applications in Objective Caml, Ruby, Perl, C++,
Java, and C. I have a working knowledge Lisp and Python. I love coding
in Objective Caml, Lisp, and Ruby, but if, in a real world
mission-critical situation, a client were to come to me and ask me to
implement an application for him, I would likely choose C, because of
my experience and level of confidence with the language. That alone, I
would argue, makes C the best language for the job, if I am on it. I
know 99.9% of the language's primitives (at least for the Gnu C
compiler), I know all the common libraries, I have learned to
discipline myself to use the language right (grammatical correctness,
data structure arrangement, code organization, etc.), I know all of
the standard library routines, I know the common build environments, I
know exactly how the libraries/object files are compiled and linked, I
know where to store the libraries and how to name them, I know how to
debug it at any level necessary, I know how to write cross-platform
code, I know how to manage my memory right (it's like second nature at
this point), and (of course) I know all of the security caveats with
the language. There are more C compilers out there than for any other
language, and they are very mature and stable.

I could whip out almost any piece of C code that implements any given
function without looking up any documentation, whether it be
networking code, filesystem code, IPC code, or what have you. With any
other language, there would be a short re-learning curve while I look
up this or that nuance of the language. I could accomplish the task
just as well in that language, but I would be somewhat annoyed for the
first one or two weeks while I caught up on that target language. And
I would get *really* annoyed every time one of my assumptions for a
class or a library in another language proves false and I spend 20
minutes chasing a resulting mystery bug (we've all been there
:-). With C, there are not a lot of things that pop up that surprise
me. I am sure that there are plenty of folks on this list who could
say the same for Java or Perl.

Of course, I am a software engineer, not a C engineer, and so I am
expected to be able to adapt to any language to get the job done. If I
had to do something in Java or Perl, I would buckle down and do it,
and I would do a decent job of it. But I would prefer mission-critical
jobs that involved C; it's simply a comfort/confidence thing. A big
part of my job, after all, is to jump into the middle of a block of
someone else's C code and to start fixing things up or extending
functionality.

Now if I were working on a brand new project, if the customer
requirements were a little more liberal, if the language made sense
for the project at hand, and if I worked with a group of really open
and flexible engineers on the project, *with at least one Lisp expert
on the team* (very important detail), I might suggest that we give
Lisp a try for the project. There are definitely concerns along the
lines of code maintenance when you go that route though... the long
and short of it is, I think that Lisp is an ideal language, if it
weren't for reality. :-/ To quote Eric Raymond, ``Free markets select
for winning solutions.''

Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C  20F5 DB40 8531 6DCA 8769

Any program that runs right is obsolete.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20050713/9edaa9ec/attachment.bin 


More information about the PLUG mailing list