john13@garfield.MUN.EDU (John Russell) (10/16/88)
In article <39400002@m.cs.uiuc.edu> wsmith@m.cs.uiuc.edu writes:
]
]>A good rule of thumb I've observed is that anytime a project can
]>be done by one or (maybe) two people, a PC is probably your best choice.
]I don't
]have much respect for PC make facilities especially since a PC has limited
]concurrent execution powers to allow for the nested makes needed for the nested
]directory structure.
That isn't necessarily true of all PC's (personal computers, as opposed to
"IBM PC" which is what most people consider PC to mean).
An Amiga has concurrent execution powers limited only by available memory. You
might be able to fill up available memory, although it's no problem to make
heavily used executables resident (ie only one copy of executable code for
multiple invocations).
I've been disappointed with mainframe performance ever since the end of the
summer, when the load average went back to real-world levels and my compiles
started turning into meal-breaks :-(.
John
--
"The 68000 processor can't possibly handle a colour display. You must have a
68020 system and not know it."
-- Amiga and Atari ST owners shared a chuckle over this view
from sales *and* technical people at the local Apple dealermike@ai.etl.army.mil (Mike McDonnell) (10/24/88)
In article <4935@garfield.MUN.EDU> john13@garfield.UUCP (John Russell) writes: >In article <39400002@m.cs.uiuc.edu> wsmith@m.cs.uiuc.edu writes: >] >]>A good rule of thumb I've observed is that anytime a project can >]>be done by one or (maybe) two people, a PC is probably your best choice. > >"IBM PC" which is what most people consider PC to mean). The best software development environment on the planet earth is a lisp machine. This is a "PC" in the generic sense. It is the quality of the supporting environment that makes this so. Those of us who know and love these beasts are saddened by the manufacturing and marketing ineptitude of the selling companies who have more-or-less insured that "lispms" will never be much more than a curiosity. Sigh. -- Mike McDonnell at the U.S. Army Engineer Topographic Laboratories, Bldg. 2592 Fort Belvoir, VA 22060-5546 TEL:(202)355-2724 ARPA: mike@ai.etl.army.mil
lishka@uwslh.UUCP (Fish-Guts) (10/25/88)
In article <197@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes: > >The best software development environment on the planet earth is a lisp >machine. This is a "PC" in the generic sense. It is the quality of the >supporting environment that makes this so. Those of us who know and >love these beasts are saddened by the manufacturing and marketing >ineptitude of the selling companies who have more-or-less insured that >"lispms" will never be much more than a curiosity. Sigh. Do other people in this group feel this way as well? I agree that Lisp environments typically have some nice features and tools, but trying to read Lisp for too long makes me see non-existant parentheses. That and the dynamic scoping make it harder to read than many other languages, IMHO. Don't get me wrong: I think Lisp is one of the all-time GREAT languages (although I prefer the Scheme dialect), but I do not think it is one of the best to have to write/read/revise/debug/maintain code in. There just isn't enough structure to the actual language. BTW, I've used some Franz Lisp, Emacs Lisp, XLisp, C-Scheme, and did several semester projects on Xerox Lisp Workstations ("1108's") in InterLisp, LOOPS, and OPS5 (a Lisp-derived language). Aside from the language, the Xerox 1108 workstations do not seem to offer that much more than modern environments for other languages. Windowing is now common. Browsers are becoming common. Language-oriented editors are becoming common. Symbolic debuggers are becoming common. Interpretters for compiled languages (such as C) are becoming common. Although most language environments do not offer all of the above features, most of them are present. On my Amiga, I have everything listed above except the interpreter (although not as well integrated; what do you expect for mostly PD software? ;-). Are Lisp environments still *that* much better for development.? One thing I have considered doing is adding an extensive preprocessor to Lisp, to make it look more "structured" (like C or Pascal). Essentially, one would write in my structured language (call it CL), and the CL-parser would spit out Lisp code as an intermediate language, to be interpretted or compiled or whatever. I'm sure *someone* has thought of this before. Any comments? >Mike McDonnell at the U.S. Army Engineer Topographic Laboratories, Bldg. 2592 .oO Chris Oo. -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 lishka@uwslh.uucp ---- "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
shebs@Apple.COM (Stanley Todd Shebs) (10/26/88)
In article <396@uwslh.UUCP> lishka@uwslh.UUCP (Fish-Guts) writes: >In article <197@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes: >>[...] manufacturing and marketing >>ineptitude of the selling companies who have more-or-less insured that >>"lispms" will never be much more than a curiosity. Sigh. Amen to that. There are also technical reasons that have been argued over endlessly. My view is that specialized Lisp processors have never been able to stay ahead of stock hardware and "normal" programming environments for more than a year or two - if for no other reason than that the good ideas in the Lisp environment get imitated/improved on elsewhere. For instance, Lispms have complicated and slow window systems, while the rest of the world ends up using X. Lispms have hardware for tags, now SPARC has it too, but simpler and less obtrusive. Nowadays the big push is to have GC for every language, down to and including C. Lisp isn't some sort of magic that renders systems uncopyable; instead the Lisp marketeers are in the unenviable position of pioneering, then being trampled by the hordes following along and re-engineering! >[...] trying to read Lisp for too long makes me see non-existant >parentheses. You have clearly failed to reach the level of true Lisp wizardry :-). Parentheses are unimportant to reading, about as significant as commas in most languages. Indentation and special forms, that's all that counts. > One thing I have considered doing is adding an extensive >preprocessor to Lisp, to make it look more "structured" (like C or >Pascal). Essentially, one would write in my structured language (call >it CL), and the CL-parser would spit out Lisp code as an intermediate >language, to be interpretted or compiled or whatever. This has been done several times since the 60s. LISP2, CLISP for Interlisp, and RLISP for Portable Standard Lisp spring to mind immediately; there are probably others. stan shebs shebs@apple.com
tom@chionia.amara.uucp (Tom Doehne) (10/26/88)
In article <396@uwslh.UUCP> lishka@uwslh.UUCP (Fish-Guts) writes: >In article <197@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes: > >>The best software development environment on the planet earth is a lisp >>machine. This is a "PC" in the generic sense. It is the quality of the >>supporting environment that makes this so. Those of us who know and ...regrets deleted... > Do other people in this group feel this way as well? Yes, I feel this way. My reasons are below. > I agree >that Lisp environments typically have some nice features and tools, >but... opinion of Lisp as a difficult unstructured language omitted... > Aside from the language, the Xerox 1108 workstations do not seem >to offer that much more than modern environments for other languages. >Windowing is now common. Browsers are becoming common. >Language-oriented editors are becoming common. Symbolic debuggers are >becoming common. Interpretters for compiled languages (such as C) are >becoming common. Although most language environments do not offer all >of the above features, most of them are present. On my Amiga, I have >everything listed above except the interpreter (although not as well >integrated; what do you expect for mostly PD software? ;-). Are Lisp >environments still *that* much better for development.? The greatest shortcoming is that all those things are not integrated in non Lisp-machine environments, lacking the tremendous advantages integration gives. I worked on a Symbolics 3670 for the last two years, and feel that it is one of the finest development environments available for rapid prototyping. The integration of the parts of the environment give the following benefits: The editor not only `knows' about the language, but about the program you are writing. With a keystroke or two, it will load the definition of the function your cursor is on, so it can be edited. Or it will let you cycle through all calls to a function. Incremental compilation of a selected part of the edit buffer is useful, as are things like setting trace and breakpoints. Cutting from the editor to an interpreter or vice versa is helpful, especially if you want some idea of what an expression will do in the program and don't want to type it twice. I also liked being able to call up documentation by positioning the cursor on the function name and hitting <cntl>-<sh>-d. In the debugger, it is nice to be able to invoke the editor on an offending function definition, change and recompile it, then return to the debugger window and reinvoke the call from a point just before the problem occurred. (An advantage of an interpretive language.) It is also possible to grab the values of variables in the debugger, operate on them, return the resulting value(s) as the function's result(s), and continue with execution. This is especially nice for ignoring a bug that is fairly unimportant so that you can test what you are working on at the moment. Finally, the Symbolics debugger gives you numerous options for continuing execution when you enter it (if it can). Finally, you can `inspect' any data object on the stack, and follow all the pointers easily, by invoking the Inspector. The inspector (a data browser) made it easy to follow pointers, examine nested data structures, and edit them. Since you can call it from your code, you can easily stub a function by calling the inspector with a list of parameters. When it is called play with the parameters in the inspector to get the value the function should return, and exit the inspector giving it that value to return (a matter of a few mouse clicks). Helps a lot with testing, especially if someone else doesn't have the function written, but you have a good idea of what it should return. It's also possible to simply try things out on a command line interpreter, then cut the sequence from the interpreter and paste it into the editor to turn it into part of your program. The latest Symbolics online documentation is quite impressive. Not only can you go through list of sections that contain a certain string, but the sections are hypertext, so you can go from one topic to a related one mentioned there. It supports diagrams not just text. It has a tree structured summary for browsing. And the ability to shove topics to one side (literally) and take them up later. Even days later (you can permanently store the list of topics you have). I won't mention the support for OOPS, except to say it's fairly nice. Disclaimer: These opinions are mine, and don't reflect those of my current employer or my former one. -- ------------------------------------------------------------------- Tom Doehne Applied Dynamics International tom%amara.UUCP@umix.cc.umich.edu 3800 Stone School Rd. ...(uunet|umix)!amara!tom Ann Arbor, Mi 48108 -------------------------------------(313)973-1300-----------------
new@udel.EDU (Darren New) (11/04/88)
In article <TOM.88Oct25170554@chionia.amara.uucp> tom@chionia.amara.uucp (Tom Doehne) writes: > >In article <396@uwslh.UUCP> lishka@uwslh.UUCP (Fish-Guts) writes: >>In article <197@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes: >> >>>The best software development environment on the planet earth is a lisp >>>machine. This is a "PC" in the generic sense. It is the quality of the >>>supporting environment that makes this so. Those of us who know and >...regrets deleted... > >> Do other people in this group feel this way as well? N.B., most if not all of the advantages of an integrated LISP environment cited in the above articles are also present in Smalltalk. Not only that, but Smalltalk runs on many different and standard machines (Suns, Macs, ...) without change to ANY conde (object compatible). It also supplies real structure for your data, instead of forcing everything to look like a list. Since everything is accessable to your code, even things like the debugger (allowing everything cited above, including evaluation of subexpressions, code correction and restart, ...) are all written in Smalltalk without needing anything special in the interpreter. Check this out before claiming LISP as the "best". I would say "one of the best" myself. - Darren New
pf@csc.ti.com (Paul Fuqua) (11/08/88)
Date: Thursday, November 3, 1988 2:57pm (CST)
From: new at udel.EDU (Darren New)
Subject: Re: What's a PC? (What's the best environment)
Newsgroups: comp.software-eng
In article <TOM.88Oct25170554@chionia.amara.uucp> tom@chionia.amara.uucp (Tom Doehne) writes:
>
>In article <396@uwslh.UUCP> lishka@uwslh.UUCP (Fish-Guts) writes:
>>In article <197@ai.etl.army.mil> mike@ai.etl.army.mil (Mike McDonnell) writes:
>>
>>>The best software development environment on the planet earth is a lisp
>>>machine. This is a "PC" in the generic sense. It is the quality of the
>>>supporting environment that makes this so. Those of us who know and
>...regrets deleted...
>
>> Do other people in this group feel this way as well?
N.B., most if not all of the advantages of an integrated LISP
environment cited in the above articles are also present in
Smalltalk.
That's the point: it's not the language, per se, it's the integrated
environment. Lispms just seem to be better-known. And, gradually,
environments for lesser languages are catching up to those that already
exist for Lisp and Smalltalk (check out Saber-C).
So what got Lisp and Smalltalk there first? My vote goes to the
object-oriented aspect of both languages, which is also filtering out to
lesser languages (I see C++ as a broader dialect of C).
It also supplies real structure
for your data, instead of forcing everything to look like a list.
Most modern Lisps provide lists, arrays, structures, and "objects" (as
in Flavors or CLOS).
pf
Paul Fuqua
Texas Instruments Computer Science Center, Dallas, Texas
CSNet: pf@csc.ti.com (ARPA too, sometimes)
UUCP: {smu, texsun, cs.utexas.edu, im4u, rice}!ti-csl!pfnew@udel.EDU (Darren New) (11/11/88)
In article <62959@ti-csl.CSNET> pf@csc.ti.com (Paul Fuqua) writes: > >That's the point: it's not the language, per se, it's the integrated >environment. Lispms just seem to be better-known. And, gradually, >environments for lesser languages are catching up to those that already >exist for Lisp and Smalltalk (check out Saber-C). > >So what got Lisp and Smalltalk there first? My vote goes to the >object-oriented aspect of both languages, which is also filtering out to >lesser languages (I see C++ as a broader dialect of C). > Funny... I feel that the object-oriented aspect is much less important. After all, I can imagine a non-object-oriented environment (lisp) in which I am just as productive as in Smalltalk. Personally, I think the browsers (system browser, debugger, inspector, ...) and the predefined classes (views, collections, ...) are the main contributors to productivity. Also, the almost instant turn-around fromchange to test is vital. Of course, the o-o aspect is important in supplying such abilities. Languages like (say) Pascal or Ada will not lend themselves easily to "random access" code browsers. Lisp, of course, is much better at this due to the lack of nesting of functions and complex scoping rules. Another great feature is the ability to save complex hand-created data in the "snapshot" file. In a language like C, I would have to either write a file-in/file-out routine or recreate the data at each run. The ability to save the state makes testing much easier. In Lisp, the print and read functions supply the file-in/file-out routines for any (non-circular) lisp data. In my opinion, both Smalltalk and Lisp supply nice development environments, but possibly through different mechanisms. > It also supplies real structure > for your data, instead of forcing everything to look like a list. > >Most modern Lisps provide lists, arrays, structures, and "objects" (as >in Flavors or CLOS). > > pf But it doesn't supply Rectangles, Debuggers, Contexts, CompilerParseNodes, ... One of the advantages (and disadvantages) of Smalltalk is that EVERYTHING is an object, including your execution stack, your mouse, your compiler, your menus, your screen, your source, your object, and so on. Even error messages are messages sent to objects. Can you add multiple inheritance (cleanly) to your OO Lisp? (Not to bash Lisp, you understand. I just enjoy looking at ideas taken to extremes... like Smalltalk, Lisp, Forth, ...) > >Paul Fuqua >Texas Instruments Computer Science Center, Dallas, Texas >CSNet: pf@csc.ti.com (ARPA too, sometimes) >UUCP: {smu, texsun, cs.utexas.edu, im4u, rice}!ti-csl!pf
pf@csc.ti.com (Paul Fuqua) (11/12/88)
Date: Thursday, November 10, 1988 3:22pm (CST)
From: new at udel.EDU (Darren New)
Subject: Re: What's a PC? (What's the best environment)
Newsgroups: comp.software-eng
Personally, I think the browsers
(system browser, debugger, inspector, ...) and the predefined classes
(views, collections, ...) are the main contributors to productivity.
Also, the almost instant turn-around fromchange to test is vital.
That's part of what I mean by "integrated environment." As a colleague
put it, you get much more than just the program you're running, you also
get the debugger, etc. (cf Unix and C, in which you usually have to
recompile with -g to use the debugger effectively).
The environment lends itself to quick edit-test-debug cycles on small
parts of the program, which can then be built up independently and
combined and reused and modified. When I did my last simulator, I first
built up the display from existing windowing code (which itself is built
on the window code supplied with the system), then added the command
loop, then went back and built up the simulation objects and their
operations, then hooked the parts together and started running. Pieces
of that code came from previous projects, and other pieces are in later
projects, and it's mostly because modularity is easy.
Of course, the o-o aspect is important in supplying such abilities.
Exactly. That's what I was saying.
>Most modern Lisps provide lists, arrays, structures, and "objects" (as
>in Flavors or CLOS).
But it doesn't supply Rectangles, Debuggers, Contexts, CompilerParseNodes, ...
We're going to get into religion here if we're not careful. I use a TI
Explorer, and before that a Symbolics 3600, so my biases are toward Lisp
machines in the MIT mold, which *do* supply that sort of thing. What
you can't do is send messages to arbitrary things, because not
everything is an "object," in the sense of understanding messages and
having state. However, many of the data types available have components
and operations upon them, and you can get a handle on nearly anything
and pass it around, so even the non-"objects" are a lot closer to
object-oriented than, say, C or Fortran. It's a short step from data
abstraction to object orientation.
One of the advantages (and disadvantages) of Smalltalk is that EVERYTHING
is an object, including your execution stack, your mouse, your compiler,
your menus, your screen, your source, your object, and so on.
Even error messages are messages sent to objects.
On a lispm, error instances are objects, with operations to print their
message or enter the debugger.
Can you add multiple inheritance (cleanly) to your OO Lisp?
It's already there, as part of the basic design of both Flavors and
CLOS. Folks I work with wonder how anyone tolerates the lack of
multiple inheritance in C++.
pf
Paul Fuqua
Texas Instruments Computer Science Center, Dallas, Texas
CSNet: pf@csc.ti.com (ARPA too, sometimes)
UUCP: {smu, texsun, cs.utexas.edu, im4u, rice}!ti-csl!pfpeter@ficc.uu.net (Peter da Silva) (11/13/88)
In article <5315@louie.udel.EDU>, new@udel.EDU (Darren New) writes: > Funny... I feel that the object-oriented aspect is much less important. ... > Also, the almost instant turn-around fromchange to test is vital. You mean like in Forth? > (Not to bash Lisp, you understand. I just enjoy looking at ideas taken > to extremes... like Smalltalk, Lisp, Forth, ...) Yeh, that's the ticket. Seriously, though, Forth provides one of the great working environments for people on tight budgets. Sort of like a diamond in the rough. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net