billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (09/29/89)
OK, I just talked to a person who has knowledge of both Common Lisp and Ada, and here are the results. Common Lisp is, like Ada, a very powerful language. There are some problems in doing ADTs in Common Lisp, in that you can *define* all kinds of types, but there is not the type checking (the enforcement, the fulfillment of the limited private concept) that you get with Ada. The other major problem is that there is a very low level of translator maturity, and the code produced is generally extremely inefficient. By the way, Ted Dunning said earlier regarding Lisp: "if you want to play, grab a copy of one of the pd interepreters". I will be quite happy to consider anything that will help attain the objectives of the software engineering philosophy, and Common Lisp may well be useful in that respect. But engineers don't play; this is left for hackers. We're here to engineer products on time, under budget, and with as much quality as we can get within those two constraints. Software engineering is serious business. Bill Wolfe, wtwolfe@hubcap.clemson.edu
ted@nmsu.edu (Ted Dunning) (09/29/89)
i think we are closing in on bill wolfe's problem:
In article <6630@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
By the way, Ted Dunning said earlier regarding Lisp: "if you want to
play, grab a copy of one of the pd interepreters". I will be quite
happy to consider anything that will help attain the objectives of
the software engineering philosophy, and Common Lisp may well be
useful in that respect. But engineers don't play; this is left
for hackers. We're here to engineer products on time, under budget,
and with as much quality as we can get within those two constraints.
playing with something new is a wonderful way to find out it's
strengths and weaknesses. programming etudes to explore the
capabilities of tools without necessarily producing something that
people will sell is just as important as etudes and scales are to the
player of musical instruments.
if you never have time to do anything other than produce code, then
you will (already have?) wind up woefully ignorant of everything
outside your own specialty.
i would hope that the `software engineering philosophy' does not
preclude self-education.
--
ted@nmsu.edu
remember, when extensions and subsets are outlawed,
only outlaws will have extensions or subsetslpj@hpctdlu.HP.COM (Laura Johnson) (10/02/89)
Bill Wolfe writes: > ... engineers don't play; .... > Software engineering is serious business. ---------- Boy did I make a mistake! I got into this business so I could get my company to pay for my toys. Guess I'd better get grim. - lpj DISCLAIMER: No, boss! I don't play. Not me. Smalltalk is serious stuff. It's not fun. I promise. Please don't take it away from me...