Post #40,017
5/27/02 4:40:11 AM
|
Fascinating article about the power of LISP
[link|http://www.paulgraham.com/icad.html|Revenge of the Nerds]
|
Post #40,018
5/27/02 6:26:03 AM
|
Nice article.
And I know enough languages, old and new, to see what he's on about. It's kinda scary, actually. I just wish either Lisp macros were called something else or everything else that uses the term "macro" used a different term. :-/
Wade.
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #40,051
5/27/02 12:09:10 PM
|
Paul Graham writes a lot of good Lisp advocacy
Much food for thought in there, as usual.
My only major criticism is that he underestimates the power of good libraries where those libraries keep on being delivered. If available libraries are static, then they are a constant you can discount. If you are cutting-edge, then you are ahead of delivered libraries, and again you can discount. But if you have a good variety of needs and no need to ride the bleeding edge, then a feature like CPAN simply should not be underestimated.
I suspect that he doesn't underestimate this. In previous articles he said that ViaWeb used Lisp for the core, but did various "system programming" pieces in Perl. Which makes sense. Use what makes you most productive for your core that you work on all of the time. Go for the libraries for the random stuff that isn't core.
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #40,116
5/27/02 10:13:20 PM
|
A nice "read". My favorite quote:
Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. And, the [link|http://www.thocp.net/hardware/pictures/ibm_704_1956.jpg|IBM 704] was bigger than a refrigerator. As an undergraduate student, I got to use one for Fortran problems (by submitting punch card decks and waiting till the next day for output!). Years later, I got to write some LISP programs as a graduate student. It takes a modal shift of the brain to write LISP, but thee is no question about its power. Alex
"Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill (1874-1965)
|
Post #40,121
5/27/02 11:04:08 PM
|
But as always, suite tool to the job
When I was in college, the physics department had a LISP machine that run LISP in hardware to run Macsyma faster.
I don't doubt LISP has its pluses, and I most certainly agree that using an appropriate tool is much more important than 'using what everyone else is'. That PHB approach reminds me of Andrew G's quote about businesses paying anything to be able to say "We have no choice!".
For what I'm doing now, I need a lot of flexiblity (so it's easy for us to customize -- and for our customers to do a bit...how much will depend on the customer). Since I want others, who aren't professional programmers, to be able to do some bug fixing and simple modification, I needed a language that was easy to learn. And, since I don't have time to re-create libraries, libraries for GUI, databases, COM, etc are essential. So far I've been very happy with my choice of Python.
I do think the author underestimates the importance of libraries. Of course, good programmers are good at stealing the work of others, even in other languages (e.g. the Tk GUI has been used for all kinds of languages, e.g. Python (Tkinter) and Inferno).
And, when embedded programming is considered, especially my favorite area of factory automation, there are a whole different set of concerns. Available memory and processing speed can be quite constrained, along with the added pressure of real time constraints. I don't think anyone will be writing ISR's in LISP anytime soon.
One of these days I'll publish a rant on the state of factory automation programming. It's pretty sorry overall, and could certainly learn a LOT from Computer Science.
Tony
|
Post #40,128
5/27/02 11:15:53 PM
|
Interesting article
Interesting article, and I agree with a lot of what he says. The point that it is better to pick a language that suits the problem then the other way around is very valid. And his reasoning for why we have seen more new programming languages over the past few years is at least partially correct, though I would give two other factors equal billing.*
But his argument about code size and programming power is stunningly spurious. His claim that length of program** and length of time to program it is simply wrong in my experience, I would go so far as to say that two are only trivially related. For any non-trivial problem, more time will be spent planning and designing then coding.
Jay
* Those factors being the importance of problem for which previous languages where ill suited and the rise of Linux.
** Note that he is talking programming elements here, not raw character count.
|
Post #40,138
5/28/02 1:36:38 AM
|
That reminds me.
I've re-learnt recently the adage of "Be prepared to throw the first one away!". The time taken to re-implement better should be factored in somehow.
Wade.
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #41,033
6/3/02 11:30:53 PM
|
Re: code size and programming power is stunningly spurious
Not really. It relates to how easy it is to create and deal with abstractions. In [link|http://www.users.cloud9.net/~bradmcc/APL.html|APL], (a language I used some in the late sixties), for example, you can invert a matrix with a single symbol. That's power!
Alex
"Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." -- Winston Churchill (1874-1965)
|
Post #41,048
6/4/02 1:27:01 AM
|
You, uh, missed the point
I'm not trying to argue that a program written in a more 'powerful' language isn't going to be smaller.
What I'm arguing is that this won't actually save you much real programming time, if any at all. In my experience, for any non-trival program, the actual time spent typing is a fairly small portion of the time spent on the program.
The design and analysis phase are usually both longer then the time spent in the physical typing and programming portion of the program. When you add in testing, debugging, documentation, and so on, you find that for complex problems the coding phase is often less then 25% of the overall project time.
Thus even if your programming language can solve a problem in half the elements as another one it won't reduce the overall time to do the project by 50%.
And that's assuming that a programming language with twice the number of elements is actually twice as powerful. This is itself an obviously flawed concept. At some point the number of elements in language becomes so large that it becomes impossible to remember or use them all effectivly. And in any case, there are factors other then number of elements involved in measuring how usefull a language really is.
Lisp is a really good language, but the idea that it is better because it can solve problems in fewer elements is misguided.
Jay
|
Post #41,065
6/4/02 8:07:20 AM
|
And *you* missed the point
My experience backs up Paul who got his idea from The Mythical Man-Month.
Less code wins in a whole ton of ways, and typing is the least of them. It wins because there is less to keep in mind, and therefore you are more likely to get away with a small team (with all of the small team dynamics). It wins because there are fewer places you can make mistakes leading to fewer bugs to track down, speeding up the debugging phase. It wins because the reduction in size corresponds to an improved factoring of the problem, which has all sorts of ways of coming back and making you happy.
And for the record, it seems that languages which allow shorter do not mainly do it by offering a ton more elements. They do it by getting rid of things that take up lots of space and thought (like memory management), and allowing for options that give you better ways to build on your own code-base (OO, native associative arrays, closures, macros). The result is that you cut code size in half while far less than doubling the complexity of the language.
In fact it is quite possible for a simpler language to beat a more complex one. Well-integrated features and design can easily beat more features.
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #41,101
6/4/02 12:08:12 PM
|
Programming Time
More powerful languages win hugely as programming time is much more than typing. The conceptual load is much lower in the more powerful (and simpler) language. Example: Assume list of integral, we want a subset of list with only non-negative values. In Java:
Iterator it = list.iterator();
List newList = new ArrayList();
while(it.hasNext())
{
Integer i = (Integer) it.next();
if(i.intValue() >= 0)
{
newList.add(i);
}
}
The Smalltalk equivalent is:
| newList |
newList := list collect: [:x | x >= 0].
The conceptual load in the Java version is an order of magnitude higher as I have to deal with setting up a loop, determining a good end condition, the duality of objects and primitives, the allocation of the new list container including the selection of an appropriate implementation, setting up the test that determines inclusion, doing the cast from Object down to Integer. There are a *lot* of things to get wrong in the Java version. In fact, the Java version will go terribly wrong if there is some other kind of number representation in the list, like a Long. Maybe I need to go back and check for that case. The average hunter gatherer works 20 hours a week.
The average farmer works 40 hours a week.
The average programmer works 60 hours a week.
What the hell are we thinking?
|
Post #41,184
6/4/02 7:23:44 PM
|
"Any sufficiently complex program reinvents the DB"
How about
select * from myList where x > 0
Or XBase:
use myList
set filter to x > 0
Smalltalk fans seem to delight in reinventing the database. However, the drawback of ST databases is that it is hard to share the data with other languages in real-time and you have to roll-your-own services like backups, contention management, etc.
________________
oop.ismad.com
|
Post #41,859
6/10/02 4:38:27 PM
|
Proper abstraction
Makes the same action work on both a database or in memory data store. So you use the same actions on both. So on one hand I sort of agree with you - set operations are lacking from most collections libraries and this is sad since they are so useful in databases - OTOH, I view the db itself as implementation detail - maybe the data is persistent in a database or maybe its some stuff I happen to have in memory and I don't need to save. I don't care. So long as I have powerful set operations that work on the tuples in the collections.
The average hunter gatherer works 20 hours a week.
The average farmer works 40 hours a week.
The average programmer works 60 hours a week.
What the hell are we thinking?
|
Post #41,991
6/11/02 5:05:52 PM
|
Persistence is not the main issue
(* OTOH, I view the db itself as implementation detail - maybe the data is persistent in a database or maybe its some stuff I happen to have in memory and I don't need to save. I don't care. So long as I have powerful set operations that work on the tuples in the collections. *)
Databases are about managing collections, period. Whether you save them or not is another matter. (Vendor support for virtual or temp tables varies. That is not my fault.)
Anyhow, as long as you don't distinguish between "types" of collections, then we are pretty much saying the same thing. Whether we store the collection or keep it in a temporary buffer only (such as RAM) is also an "implementation detail". One should not have to alter their collection interface if they decide to "save" a collection for whatever reason, and visa versa (beyond setting an attribute or two).
|
Post #41,183
6/4/02 7:15:31 PM
|
Organic software engineering?
(* The design and analysis phase are usually both longer then the time spent in the physical typing and programming portion of the program. When you add in testing, debugging, documentation, and so on, you find that for complex problems the coding phase is often less then 25% of the overall project time. *)
IIRC, Paul Graham suggested that he sort of "hacked his way into" his zillion-dollar application. IOW, an organic kind of growth rather than up-front planning. Also, he would probably say, "less code == less to debug". He also said something like, "There is less things to slow you down when you toss the suits out". [paraphrased]
I would definitely agree with the suits claim. Well, maybe not toss them, but simply give them an information-finding role only. They have a habbit of sticking their fingers into the pie simply because they want their fingers in there.
________________
oop.ismad.com
|
Post #40,597
5/30/02 5:17:16 PM
5/30/02 5:23:19 PM
|
non-justified example
I agree with what he says about OO patterns. The p/r equivalents are usually simpler and are "local views", often based on relational formulas, and not some large hand-built monmonstrosity.
One thing about his program size challenge problem is that he does not justify the need for it. Just because a language can do something intellectually keen does not by itself make it a better language. "My vacuum tube can make new vacuum tubes" might be a neat trick, but not very useful if nobody wants vacuum tubes.
He should show it in a practical context.
I also like his comment about how to sneak LISP into an organization: tell the boss that it is XML. Perhaps somebody can write an interpreter that uses angle brackets instead of parenthesis.
________________
oop.ismad.com
Edited by tablizer
May 30, 2002, 05:23:19 PM EDT
|
Post #40,898
6/2/02 2:50:41 PM
|
Clarification
(* .... does not justify the need for it. *)
"It" is a given feature, and not program size in general.
________________
oop.ismad.com
|
