[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: source code
- To: Mark Watson <watson@esosun.css.gov>
- Subject: Re: source code
- From: Brad Miller <miller@SOL.CS.ROCHESTER.EDU>
- Date: Fri, 31 Aug 90 16:52 EDT
- Cc: info-macl@cambridge.apple.com
- Default-character-style: (:FIX :CONDENSED :NORMAL)
- Fonts: CPTFONTC
- In-reply-to: <9008311505.AA11269@esosun.css.gov>
- Organization: University of Rochester, Department of Computer Science
- Phone: 716-275-1118
- Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
- Reply-to: miller@SOL.CS.ROCHESTER.EDU
- Sender: miller@SOL.CS.ROCHESTER.EDU
Date: Fri, 31 Aug 90 08:05:02 PDT
From: watson@esosun.css.gov (Mark Watson)
How about asking Microsoft for the source code to Excel
while you are at it! <grin>
Actually, I agree with the prior proposals. I work on a Symbolics every day,
we are evaluting UNIX lisp environments, and the one thing that will
virtually automatically veto a vendor's system is the lack of availability
of source code. For a number of reasons, including the ability to support
ourselves (should, e.g. the vendor go out of business or an inability to
provide a patch on a timely basis), make custom modifications (e.g. in the
case of lisps, we often modify the editor, debugger, top level, or network
and file handling...).
Personally I don't like systems that don't come with source code, everything
we have that runs on our UNIX systems or our lisp machines has it, and it's
only the Mac that seems to have this "tradition" of no source. (Yes, we even
get kernel sources from SUN).
It can be fixed, I suppose, intellectual property rights aren't fixed in
stone, and it would be a useful thing if any copyright protection were
denied to programs that did not have source code distributed. But that is
another issue. The main thing is that only through the source code can we
actually discover how something works, rather than use it through
superstition. We have paid good money for a program, we should get all that
this payment implies, which includes the ability to modify it for our own
particular purposes. I'm certainly free to do that with a car, a house, or a
stereo, why not my programming environment? After all, it's what I have to
deal with on a day to day basis... and I have no reason to believe that any
vendor is going to know how I want to go about getting my job done better
than I will. The ability to modify my environment to whatever extent I
wish, (e.g. more than whatever customization variables the developer may
have chosen to export) is therefore a very important thing to me.
I realize that not EVERYONE requires this, and I think Apple would do their
customers very well to include SOME sources with their product, e.g. at
least to the user interface sorts of things (like all of FRED, the debugger,
the toplevel) and allow individuals to PURCHASE the source for stuff at
lower levels. Since the high level stuff is unlikely to be useful to anyone
not using MACL, it's also not much of a security problem (not that I think
there is really much in MACL worth stealing at this level: the user
interface is tied too closely to the peculiarities of the MAC to be useful
on any other system). Another useful thing to have some sources for would be
parts of the compiler, in particular, one should be able to specify
optimizations for certain functions and forms, given that the compiler isn't
smart enough to figure it out for itself. (The Symbolics has
compiler:add-optimizer. The hash-table code would be useful too, in order to
be able to write hashfunctions for equivalence class predicates that are
outside of CL's predefined ones (e.g. an equalp for my structures).
So I would like to add my voice lobbying Apple to supply at least some
sources with the MACL product, and then make any other sources at least
available on an unbundled, separate cost, basis. I know for us, it would be
one step that would make MACL a serious choice for serious development work,
rather than the toy for quick hacks it is treated as here now. (There are
still other hurdles to overcome, of course, but this is the one under
discussion :-).
----
Brad Miller U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}