Christopher Browne wrote: > Unfortunately, in order to obtain a copy of "Acura Style," it appears that > you need to be an owner of an Acura automobile.
And I wouldn't know an Acura even if it ran me over.
> I unfortunately seem to have left the magazine at the office; I'd be game > to take a digital photograph of it and distribute via whatever relevant > means, should that be meaningful as proof.
> If you want to pass on word, feel free to quote me on it...
> If you want a copy, you might contact a local Acura dealer. They > probably haven't the faintest clue what's *in* the magazine...
Thanks for this. I never knew that such a car existed. I not sure there's a lot of call for the Acura in North Yorkshire (but I could be wrong ;).
> >> Lisp is not, by that token, `cool.'
> >Uhuh. And I rest my case.
> Remember, I said `cool,' not cool... :-)
Yes, I *think* that is what I said. cool not `cool'. Thanks again,
On 03 Mar 2000 08:54:27 +0000, Erik Naggum <e...@naggum.no> wrote:
> per invocation. that's the difference between 40 and 50 invocations per
40 vs 50 doesn't bother me at all in this case, but 40 vs 1000 might. What I really want to know is how long a minimal executable built by ACL would take to start on my machine. Someone else posted a measurement that was many times yours, and I'm wondering if there might be a lot of factors affecting speed besides just the raw MHz. A better way to measure it might be to write a null program in C++ and post the ratio between how many times per second it can run vs how many times per second a null Lisp program can run. Then I could run the same C++ program on my machine, and use the same ratio to estimate how long ACL-built executables might take to start. Or even better, Franz should post some ACL-built executables on their web site, for just such purposes as this.
Lisp encourages better paradigms than C++, but C++ programmers aren't likely to adopt those better paradigms till after they have a lot of experience with Lisp. To really meet their needs, it has to fit not only the better paradigms but also the ones they already use, even if it doesn't fit them as well as C++ does. The programmers know they will be working towards something better, but they need a foundation to stand on while they work, and that means being able to do what they do now, and advance from there one step at a time. If a particular program takes N% longer to run when built by ACL than when built in C++, that doesn't mean C++ programmers are going to reject Lisp. They know they get lots of advantages, and know there is a lot of serious learninig to do before they can make good use of all those advantages, and they're probably willing to make that tradeoff. But fear of other tradeoffs, such as a 1000 to 1 ratio of the above test, might be what keeps them from proceeding. By posting the real numbers, even if they turn out to be 10 to 1 or 50 to 1, such fears can be mitigated, and more people are likely to end up using Lisp. And posting real executable code, which they can download and test for themselves, might mitigate their fears even more.
Your post of your numbers was appreciated and surprising. I had no idea ACL could start that fast on any machine. I'm a lot more interested in the possibility of using it for a future project now than I was before. I'm also wondering if LispWorks can start that fast, and where I could find a good review of what advantages and disadvantages they have vs each other.
In article <7yGv4.4893$a82.53...@news.uswest.net>, Frank A. Adrian wrote: >brick, we probably would do well to ignore you. And, if you can and will do >that, hopefully you'd be smart enough to acknowledge the results once you >have been proven incorrect (though I have my doubts).
I haven't been proven incorrect at all -- read the other posts. I pointed out flaws in the metrics used. Period. No if, ands, ors, or buts about it. Unbeknownst to me, these flaws had already been pointed out in an earlier message. And for the record, I did acknowledge my error, quite publicly.
Your comprehension of what I had written is in error, and your anger towards me is unwarrented. If anything, it is YOU who should be ignored.
-- KC5TJA/6, DM13, QRP-L #1447 Samuel A. Falvo II Oceanside, CA
In article <3161062467384...@naggum.no>, Erik Naggum wrote: > oh, geez, when will this _end_?
When you give a more precise description of the testing environment, which you then proceeded to do. I would like to thank you for completing the picture for me.
> non-trivial duties. at the time I ran those tests, it turns out that it > was servicing a few thousand FTP requests from local network machines
Not bad; this is about as heavy as a streaming backup would be. And with 6 other backups going concurrently worst case that would be the type of load that I'm talking about.
> so let's assume the measurement errors were on the order of 20 vs 25 ms > per invocation. that's the difference between 40 and 50 invocations per > second. this bothers you a great deal, apparently. it doesn't bother me.
No it doesn't bother me. I was just pointing out that the conditions of the test would affect the results. Upon further investigation, and a repost from another reader of the newsgroup, I'd apparently glossed over where you'd stated that already.
> as long as any goddamn fool can cast doubt on anything anybody says, I > suggest a much more honest starting point: "I don't want to believe you!" > instead of trying to smear whoever is trying to answer their questions.
I personally don't think my text is "smearing." If you feel that way, you should have said this up front, instead of attempting to smear back at me. I'm human -- ergo, I'm not perfect. And neither are you.
> I'm getting sick of the rampant stupidity that comes with benchmarks and > any other myth-deflating devices. myths, apparently, are necessary for > the mental survival of some people. perhaps it is not a good idea to try > to destroy their misguided beliefs because they turn out to be lunatics > if they can't keep their myths alive and well.
This, arguably, is itself a myth.
-- KC5TJA/6, DM13, QRP-L #1447 Samuel A. Falvo II Oceanside, CA
not.for.em...@not.for.spam writes: > 40 vs 50 doesn't bother me at all in this case, but 40 vs 1000 might. > What I really want to know is how long a minimal executable built > by ACL would take to start on my machine. Someone else posted
But why would you want to know such a thing? What if I can build a minimal executable (language and implementation doesn't matter), that starts 1000 times a second, but once I add a single line of code, it only starts 10 times a second, or even less. What if nearly any reasonable program you would want to write in that language/env would need that line? And what if only 10% of the programs need that line? Or only exactly your program?
What if something starts 40 times a second on an idle machine, but once you get only a little load from other programs, some cache or kernel algorithm starts thrashing, and this drops to 4 times a second?
What if something starts 500 times a second on my machine, but only twice a second on your machine, although my machine is seemingly not very different from your machine? What if my OS allows C++ programs to start up very quickly, because it's dynamic linker implementation isn't brain-dead, whereas your OS's is? Or vice-versa? And what if on the same OSes, ACL doesn't use your OS's dynamic linker, and thus starts much much quicker in relation to your C++, as ACL does on my OS in relation to my C++? Or vice-versa? Or nothing of the sort?
The world's a strange place, the hardware world doubly so, and it's getting stranger all the time. We've long left that nice cozy world of "simple" VAXen and PDPs. Todays CPU architectures, memory hierarchies, MMUs, busses and OSs are strange beasts indeed, and very unpredictable.
Benchmarking is a very, very difficult business, even when you can benchmark the code you're gonna use on the OS and hardware you're gonna use, with a load-profile _you think_ will be realistic. It get's nearly impossible to do right in other situations. Transferring benchmark results from one platform to another, is an exercise in blind archery after a ride on a rollercoster: Yes a few Zen masters will probably hit every time, and some drunken stranger might even hit out of pure luck, but then again he might hit you. Let's try to avoid that...
> By posting the real numbers, even if they turn out to be 10 to 1 or > 50 to 1, such fears can be mitigated, and more people are likely > to end up using Lisp. And posting real executable code, which
As I'm trying to tell you, there will be no "real" numbers for any useful definition of real.
> they can download and test for themselves, might mitigate their > fears even more.
If you are still interested in how fast a "null program" will start up on ACL on your machine, then download one of the ACL Trial Editions (which you can get for free), and time this for yourself. If you use Linux or FreeBSD, timing the following might give you some indication (but then again it might not. I'm not the one suggesting this is a useful benchmark, so I'm not going to worry about measurement errors and the like):
time lisp -qq -Q -kill > /dev/null
or put the line "lisp -qq -Q -kill" 1000 times in a shell script (named time-acl50.sh), and do
time ./time-acl50.sh > /dev/null
Better yet, download the Trial Edition, start writing a useful, if small, program, and time that instead. Or time anything of real value, really.
> Your post of your numbers was appreciated and surprising. I had > no idea ACL could start that fast on any machine. I'm a lot more > interested in the possibility of using it for a future project now than > I was before. I'm also wondering if LispWorks can start that fast, > and where I could find a good review of what advantages and > disadvantages they have vs each other.
I'd suggest you download the LispWorks Personal Edition, and time that, only the PE doesn't allow saving new images (IIRC), and therefore you won't be able to get a non-GUI image (again AFAIK). You _might_ run across the same problems trying to do the tests with ACL on Windows using Franz' free demo version for Windows, but I wouldn't know that.
Regs, Pierre.
PS: Since C++ and C have come up, let's add them to our senseless benchmarking table, just to throw more nonsense out into the world:
Running 1000 null processes from a subshell takes:
Non-serious conclusion: Dynamic vs. static linking on Linux 2.2 sometimes makes more difference than language choice. ;)
PPS: Yes the ECL binary in question is statically linked. :)
Regs, Pierre.
-- Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* not.for.em...@not.for.spam | Or even better, Franz should post some ACL-built executables on their web | site, for just such purposes as this.
the Franz Inc sales staff and their engineers have related to me in the past, and I'm sure I'm not misrepresenting them now, that they see extremely little business value in catering to people who mainly execute really tiny programs like the null program or "hello, world" programs. rather, they have told me, and I have reason to believe them, that their main customers use Common Lisp in large-scale applications. their pricing model, licensing terms, and their Value Added Reseller programs all work very well together to indicate to me that they regard themselves somewhat like Oracle, which also provides a huge environment that people mainly use to deploy Really Important Applications, not somewhat like Larry Wall and the Perl team, who provide a large fuzzy toy environment that people mainly use to deploy Really Unimportant Applications.
catering to the RUA people is antithetical to doing business well with the RIA people. everybody in the computer business _knows_ this, except the RUA people, but they don't _actually_ count, even though they think they do. for some bizarre reason, RUA people think their RUAs grow into RIAs when in fact they don't. vast networks of half-cooperating RUAs are actually reimplemented by RIA people into a much smaller and leaner RIA than the RUA people could ever hope to realize when push comes to shove.
RUA people can graduate into RIA people if they first learn to dispense with the notion that RUAs _matter_. they don't. really. nobody is interested in how many RUAs you have written when they are looking for people to write RIAs. and I _mean_ nobody. RIA people need to show their ability to deal with complexity by reducing problems by solving the really big problems. RUA people show their ability to create complexity by profilerating tiny solutions. if making something you yourself can use takes 1 unit of time, making something somebody else can use takes 3 units of time, and making a system that somebody else can use to to build something that starts the whole scale all over again, takes 9 units of time. most people are extremely unprepared to build such systems, yet this is what it takes to grow an RIA programmer from an RUA programmer. that's why we need RIAs so people who think they are worth something in this here overheated industry can write RUAs on top of RIAs and make their employers happy -- they should not _ever_ believe that because they are using an RIA to write RUAs, they are somehow equipped to write RIAs.
| To really meet their needs, it has to fit not only the better paradigms | but also the ones they already use, even if it doesn't fit them as well | as C++ does.
for some reason, everybody realizes that civil engineering is different from building a toy city in a sandbox. you can't become a civil engineer by presenting however many pictures of beautiful sandbox cities. it takes much more than that, different skills, realizing different needs, different attitudes, different time lines, different economies. for one thing, you can't tear up a real city like you can destroy your sandbox city and you can't just start over if you realize that you failed. this is the really big difference between RUAs and RIAs. an RUA can be torn down and replaced on short notice. that's what makes it an RUA. an RIA can't be torn down without jeopardizing really serious investments, such as the entire existence of a company.
there is hope for RUA people who are bored of writing small things, but there is no hope at all for RUA people who still think "hello, world" is interesting in any way, shape, or form. RIA people think differently, too -- most of them enjoy discussing large-scale philosophical issues, and are usually very hostile to the really petty issues that most people think are inordinately important in their own lives. RUa people are well suited to deal with their own lives in all its detail. RIA people deal with thousands and millions of lives in some particular respect.
| The programmers know they will be working towards something better, but | they need a foundation to stand on while they work, and that means being | able to do what they do now, and advance from there one step at a time.
this is almost entirely false. it is true in the sense that people need to make one step at a time to make any serious changes to their lives, but deciding to go from RUA to RIA is like going from playing doctor with the kid next door (while yourself a kid -- we're not talking about Visual Basic, here) to actually putting in the planning and all the effort to _become_ a doctor some fifteen years later, during which time you don't play doctor all that much, I can tell you. deciding to go from RUA to RIA is a _complete_ replacement of your whole mind-set towards what computers can and should do. (e.g., an RUA person may think it's OK for a computer to crash. an RIA person thinks of a dying machine the same way a doctor does about a patient, or a military leader about soldiers: it should not happen without conscious effort to avoid it to the best of one's ability.)
| But fear of other tradeoffs, such as a 1000 to 1 ratio of the above test, | might be what keeps them from proceeding.
no, what keeps them at bay is fear of insufficiency in becoming an RIA person. trust me on this -- I try every single day to find RIA material among the hundreds and thousands of RUA people I brush against on the Net and in real life. perhaps one in 200 people are suitable, and the best way you can spot them is they are _not_ exicited about trifling news and hyped-up products or stale ideas in new packaging.
| Your post of your numbers was appreciated and surprising. I had no idea | ACL could start that fast on any machine. I'm a lot more interested in | the possibility of using it for a future project now than I was before.
I'm sort of glad you appreciate it, but to me, the whole point was to get _rid_ of your false concerns, not help you validate them. I regret very much if I did the latter. start-up time is _completely_ irrelevant. as others have pointed out, if you need to perform a certain task often, you investigate scaling issues and find that optimizing for scale is a very different task from optimizing for individual execution. it's somewhat like optimizing for having fun in your sandbox compared to saving a city billions of dollars through excellence in civil engineering.
> > Unfortunately, in order to obtain a copy of "Acura Style," it appears that > > you need to be an owner of an Acura automobile.
> And I wouldn't know an Acura even if it ran me over.
In Europe the Acura cars are marketed under the Honda brand. Honda owns them; Acura is their "luxury" brand in America. Toyota has an "Infiniti" luxury brand here as well.
In article <38c41a3b.70349...@news.earthlink.net>,
not.for.em...@not.for.spam wrote: > 40 vs 50 doesn't bother me at all in this case, but 40 vs 1000 might.
Why?
I rarely care about the difference between 40 and 3000ms for C++ startup because my C++ programs run for several seconds during almost all of their development and useful life. The only times I notice C++ startup are when I'm testing "do nothing" and when I'm pipeing a number of things with null inputs. Neither is common.
However, I probably wouldn't even notice a lisp startup that took 10-15 seconds.
The difference comes from the different way that one uses a lisp image vs using a C++ image. During development, I reload my lisp image far more often than most people, which means that I reload it every 5-10 edits, or 2-3 times an hour, or easily an order of magnitude less often than I reload C++. I stay in a lisp image for quite a while, doing lots of stuff that would require C++ recompiles. Everyone I know reloads far less often - some people don't reload for days. During production, the image runs for quite a while, so again startup time is almost irrelevant.
Hmm - startup time doesn't include compile-time. I'll bet that most people spend more time waiting for a C++ compile than they do waiting for startup. During some stages of development, I compile constantly, and don't run at all. Most people using lisp tend to run far more than they compile. (I'm using "compile" in the sense of "wait while some tool pokes around your program", so it doesn't include JITs, which merely affect run-time.)
I'm reminded of a comparison between the boot times of early sun boxes and lisp machines. The sun boxes then could reboot in well under a minute, which was important, because rebooting them was common - some people had to reboot dozens of times/day. The Lisp machines in that era took 10-15 minutes to reboot, but people didn't reboot for weeks at a time, so the reboot time was far less important. Not only did people spend less time rebooting lisp machines, the time lost while rebooting was less. (You can't wander off and do something else during "I've got to figure out why it crashed again" while you can during a "it's Monday, so I'll reboot while I get coffee and see who's playing chess".).
BTW - There are granularity and contxt issues. For example, the difference between 10ms and 500ms can be important in some cases (like character processing) and irrelevant in others (like startup). Meanwhile, the difference between 3 minutes and 5 minutes is almost always irrelevant because 3 minutes is a huge break in concentration and once a human has task-switched, there's no big penalty to staying away longer.
On 03 Mar 2000 22:58:49 +0000, Erik Naggum <e...@naggum.no> wrote:
> extremely little business value in catering to people who mainly execute > really tiny programs like the null program or "hello, world" programs.
That's silly. It should be obvious to you that people who want to test "hello world" programs do not have such programs as their main goal. The main purpose of such a program is to minimize the complexity of a program to explore the issues of compiling, installing, etc., independently of issues of program complexity.
My interest in null programs is because I happen to presently use a lot of software in the "pipes and filters" paradigm, and I would like to replace some of that software with my own versions, which I might like to write in Lisp.
Note that I am not advocating using "pipes and filters" as a good paradigm for any particular project. The reason I want to use it is to be compatible with software I already have. I also want to use Lisp or some such language for bigger projects, but would rather use the same language and programming environment for both types of projects.
Besides Lisp, I'm also investigating a number of other languages and environments, such as Smalltalk, SML, OCaml, Eiffel, Dylan, etc.
> like optimizing for having fun in your sandbox compared to saving a city > billions of dollars through excellence in civil engineering.
That's not a good analogy because Lisp is a lot more like playing than like doing civil engineering. Civil engineers rely on the experience of thousands of years of civil engineers who came before them. Programmers have to rely more on their own experience than on any such long history. Civil engineers cause disasters that kill people. Generations of civil engineers that follow them learn from those disasters. Lisp programmers cause disasters that require them to redo some work. Lisp programmers can play with their domain objects to learn how to manage them in their programs. They can very rapidly and very efficiently educate themselves in their domains until they develop the knowledge and skills to develop and maintain high quality software in those domains. Civil engineers are much less efficiently educated in their domains. They can require years of specialized study to learn and understand the same depth of domain details a Lisp programmer can learn and understand in a few weeks or months of interactive "playing" with the domain.
not.for.em...@not.for.spam writes: > Your post of your numbers was appreciated and surprising. I had > no idea ACL could start that fast on any machine. I'm a lot more > interested in the possibility of using it for a future project now than > I was before. I'm also wondering if LispWorks can start that fast, > and where I could find a good review of what advantages and > disadvantages they have vs each other.
Such as? Obvious decision criteria I'd suggest include
- size as displayed by ls -l - size(1) output - default font height in IDE (if supplied) - time taken to run an infinite loop - maybe run "strings" on the executable and see how many obscene words it contains
* not.for.em...@not.for.spam | On 03 Mar 2000 22:58:49 +0000, Erik Naggum <e...@naggum.no> wrote: | | > extremely little business value in catering to people who mainly execute | > really tiny programs like the null program or "hello, world" programs. | | That's silly.
then why do you argue that people spend time publishing results in that area? clearly, your argument is that these things matter a great deal. but I quite agree that it's silly to be concerned about such things, and I'm delighted that you recognize silliness when properly framed -- you might actually recognize that your core argument is indeed very silly.
| It should be obvious to you that people who want to test "hello world" | programs do not have such programs as their main goal. The main purpose | of such a program is to minimize the complexity of a program to explore | the issues of compiling, installing, etc., independently of issues of | program complexity.
if that _were_ the goal, I'd agree that it would be useful to help people with such programs. however, it isn't, and you know it isn't. those who argue for small executables do so on the basis of "overhead", which is not a question of how much the language needs, but how well the operating system is able to accomodate its needs. so small executable size is a tribute to the operating system and the language, while large executable overhead is a blemish on the operating system. oddly enough, people take it out on the language. this is not just silly, it's idiotic.
| My interest in null programs is because I happen to presently use a lot | of software in the "pipes and filters" paradigm, and I would like to | replace some of that software with my own versions, which I might like to | write in Lisp.
if you were truly interested, you would be willing to consider many ways to accomplish your needs. "pipes and filters" does _not_ translate into "small executable with short startup-up time" except to the permanently braindamaged C victims. in particular, a good way to make use of Lisp is to have a very heavy process that maintains a lot of state, but which tiny C programs talk to via sockets, if this is hard to do directly from whatever "scripts" are otherwise engaged in the "pipes and filters" thing. (IMNSHO, the sorry fact that shells have not grown to be able to make network connections instead of just pipes is _really_ pathetic.)
| Note that I am not advocating using "pipes and filters" as a good | paradigm for any particular project. The reason I want to use it is to | be compatible with software I already have. I also want to use Lisp or | some such language for bigger projects, but would rather use the same | language and programming environment for both types of projects.
you can, but you have to zoom out and _think_ about your problem. you can't expect everything new to fit the same old mold. in this case, the friggin obvious solution is to write a pipe-and-filter thingy in C that talks to the Lisp process. that way, you reduce the start-up time to that of C (which you seem to believe is short) plus the overhead of connecting to the already running Lisp process, which is, like, _really_ short. if you have problems with this extra "layer" of code, yet observe that you get dramatically improved performance, which you would if you tried it instead of just rejecting any other solutions than "run the program", I'd say you have a political agenda and not an engineering problem, anymore.
it so happens that _every_ other person who has posted to this newsgroup about his misgivings about startup times has had a political agenda and a need to complain rather than get any real work done. you're not in good company. if you don't like this, you need do nothing more than show that you have worthy goals with your quest -- and that is best shown by simply abandoning the bad solutions that you keep complaining about.
| That's not a good analogy because Lisp is a lot more like playing than | like doing civil engineering.
I'm glad you show me I was right in judging you to be an RUA person, but really, don't you think I spent all that time with a glimmer of hope that you might recognize how RIA people _differ_ from yourself in what I wrote?
time for the lament of the day: it is so often such a terrible _waste_ to write anything non-mundane to this newsgroup it's truly _exasperating_. the only thing you fucking dolts care about is whether people use nice words or bad, and then if you get nice, approved words, your brains seal shut with "oh, it's nothing dramatically new, so I'll just lull myself into my cozy old stupidity and enjoy the peace and quiet from not having to listen to anyone". I get _sick_ of such idiocy and stupidity! many of you guys seem to want it more than anything else, and some even go out of their way to _encourage_ nice and cozy, non-threatening stupidity.
you, in particular, don't know much about programming, Mr. anonymous not for e-mail at not for spam dude, so it would help a lot if you didn't pretend you did and that you didn't tell people who have outgrown your childish approach to programming _decades_ ago about how you have _not_ understood that this here programming thing is _not_ about playing in a sandbox. a few people have tried to share their experience with you, and you just reject them because you refuse to believe that there's anything beyond toy code (by our measures, not yours).
> Civil engineers cause disasters that kill > people. Generations of civil engineers that follow them learn from > those disasters. Lisp programmers cause disasters that require them > to redo some work.
That is a stupid thing to say. Lisp programmers, just like other programmers, can cause disasters which kill people.
On 04 Mar 2000 14:55:59 +0000, Erik Naggum <e...@naggum.no> wrote:
> to have a very heavy process that maintains a lot of state, but which > tiny C programs talk to via sockets, if this is hard to do directly from
Yes, I've done something like that. I used a named pipe and shared memory, and the big program was not written in Lisp, but it's the same idea. But in spite of that it's reasonable for me to ask about startup time, because there is some value in not needing to do it that way, and if some Lisps can start up a lot faster than others, that is one of many factors to consider in choosing one vs another.
> talks to the Lisp process. that way, you reduce the start-up time to > that of C (which you seem to believe is short) plus the overhead of
I've measured null program startup from a lot more than Lisp and C. In my measurements, C was the fastest, Dylan and Eiffel were about six times slower, SML was somewhat slower than those, and Lisp and Smalltalk were about six times slower than SML. I haven't measured OCaml yet because I don't have the right assembler on my computer, but will have it soon. The particular implementations I measured were not necessarily representative, but the measurements continue. I'm presently downloading some more implementations of Smalltalk, which became available for download in the past couple of days.
I have no particular involvement in Lisp, and could just as easily choose another language. The startup time is just one of many factors to take into account. The possible need for a foreground/background solution is a factor, not an obstacle.
> program", I'd say you have a political agenda and not an engineering
What kind of political agenda could I possibly have? Even if my point of view seems like completely irrational engineering, that doesn't make it political. I want a programming language and development environment that meets several criteria, some of which may seem more rational to you than others. I'm taking a lot of factors into account and probably giving most of those factors different weights than you would. That doesn't make me your political enemy.
On 04 Mar 2000 18:04:24 +0000, Tim Bradshaw <t...@cley.com> wrote:
>That is a stupid thing to say. Lisp programmers, just like other >programmers, can cause disasters which kill people.
My point is not about the fatality of the disaster but about the time lines involved. Civil engineers can't rely on their own experience because they can't get enough experience to do their jobs. They have to rely on the experience of thousands of years of civil engineering. Lisp programming is entirely different. You can see what you're doing, and can see its effects, before you commit to doing it that way. Lisp programming involves learning how to do what you want to do while you do it. Civil engineering requires learning everything before you do anything. Civil engineering uses the waterfall paradigm. That paradigm has been shown to be a failure in software development. Thus programming is not at all like civil engineering. The point I was refuting was that Lisp programming is like civil engineering. It's not.
* not.for.em...@not.for.spam | What kind of political agenda could I possibly have? Even if my point of | view seems like completely irrational engineering, that doesn't make it | political. I want a programming language and development environment | that meets several criteria, some of which may seem more rational to you | than others. I'm taking a lot of factors into account and probably | giving most of those factors different weights than you would. That | doesn't make me your political enemy.
it seems reasonable to assume that you failed to read the whole sentence you just quoted a tiny little the part of. let me try it again:
if you have problems with this extra "layer" of code, yet observe that you get dramatically improved performance, which you would if you tried it instead of just rejecting any other solutions than "run the program", I'd say you have a political agenda and not an engineering problem, anymore.
the keyword here is "rejecting any other solutions". being dead set on exploring only a particular solution space _is_ a political decision on your part. you can argue for its engineering _necessity_, but it is still a political decision. believing otherwise does you no good.
you seem to be extraordinarily focused on not seeing your problems other than in light of how you can solve them with technology you already know. this is the really exasperating part of trying to tell you something new that might change your perception of the _problem_, not the solutions. and as with every other political decision where people get "stuck" in their pet problems, we find that they don't really want any solutions, but will go on and on and on and on about their problem. so there's no telling when some benchmark-crazed doofus will be satisfied, because there's nothing he actually wants to _know_. such unfocusedness is rampant in bad engineering circles where political agendas are much more important than solving problems. you find them here in comp.lang.lisp at times, too, where someone comes up with something he _desperately_ wants to do only particular way and any suggestions otherwise fall on deaf ears.
>> b) No stable standard, and better yet no really mature implementations,
>pascal started the publicity quite early (when the first implementation >was ready), c, and c++ gained popularity at universities (unix) and >spread with graduates to the industry. it really took off in the dos >world with borland
You seem to be confusing C and C++. They are separate languages.
>> c) Lot's of money somewhere in the picture.
>there definitely was not much money involved in the popularisation of >pascal, and i don't think that c or c++ had much money behind them
Hmm. C++ didn't have money behind it?
-- Kenneth P. Turvey <kt-...@SprocketShop.com> -------------------------------------------- I wake up each morning determined to change the World... and also to have one hell of a good time. Sometimes that makes planning the day a little difficult. -- E.B. White
EN> ... (IMNSHO, the sorry fact EN> that shells have not grown to be able to make network EN> connections instead of just pipes is _really_ pathetic.)...
Actaully, this can be remedied reasonably easily using little programs like netcat. (goes by the name 'nc' usually).
* not.for.em...@not.for.spam | Lisp programming is entirely different. You can see what you're doing, | and can see its effects, before you commit to doing it that way. Lisp | programming involves learning how to do what you want to do while you do | it. Civil engineering requires learning everything before you do | anything. Civil engineering uses the waterfall paradigm.
your belief system is severely misguided, and also self-reinforcing in a sense that will make it impossible for you ever to graduate into serious software development of the Really Important Application kind.
| That paradigm has been shown to be a failure in software development. | Thus programming is not at all like civil engineering. The point I was | refuting was that Lisp programming is like civil engineering. It's not.
I'm sorry to burst your bubble, Mr. not.for.em...@not.for.spam, but the waterfall paradigm works just fine at the coarse development level. since you apparently only build Really Unimportant Applications, where there _is_ no coarse development level, only the details level that you keep describing with very good accuracy, you're missing the point: that there is _more_ than the nitty-gritty details level.
but I give up. people who aren't equipped to understand big pictures will only get increasingly hostile and adamant that only their small pictures exist when you try to force them to open their eyes.
* Bulent Murtezaoglu <b...@acm.org> | Actaully, this can be remedied reasonably easily using little programs like | netcat. (goes by the name 'nc' usually).
... which is the little C program that starts up in no time, right?
if the shells could do their own network connections, there wouldn't be any need to start up those little programs. after all, the shells don't run small programs do to filename globbing, anymore, and numerous other common tasks have been incorporated into the shells, simply because it makes a lot more sense to incorporate them than to run small programs all the time, partly because start-up time for even small programs begin to matter when you have to do it hundreds of times because everything you _do_ is made up a whole school of tiny little programs.
in case it hasn't become obvious by now: the more people get good at writing small programs that run in "barely noticeable time" each, the more silly things like start-up time matter to them. the more they get good at these silly things, the less intelligently they design their software, and the less likely they are ever to produce software that doesn't consist of tiny little fragments of code that never quite work together.
when you reinvent serious programming languages in scripting languages, which people have been doing in the Unix world for ages, what you get is a lot of people who can do useful things in no time, and no people who can figure out how to do stuff that obviates the need for tiny hacks or at least that curbs their dramatic increase. the result is a never- ending increase in the need for more tiny little programs, which costs all parties involved in the processes a lot of money, and which drives up the cost of hiring and doing business. the only people who profit from this development are bad programmers.
I see no reason why Common Lisp should take part in that development. instead, we should try to explain to people who think they have to hire bad programmers that they don't have to -- they could hire a Common Lisp programmer who knows how to change a mass of RUAs into a coherent system that it takes far less effort to build and maintain than just to keep the old system running. it's somewhat like the difference between a mass of disorganized files and information strewn all over the place and a real database system. and the funny thing is: some people _do_ get the idea.
[on netcat] EN> ... which is the little C program that starts up in no time, EN> right?
Well, I don't know how long it takes to start up. Usually whatever it is you will be doing with the network dominates the times it takes to use it I suppose. But specifics of netcat is not your point, anyway.
EN> if the shells could do their own network connections, there EN> wouldn't be any need to start up those little programs.
Yes, though I for one don't think I would like it for shells to get even more bloated than they are. Following your terminology, if the task at hand is Really Unimportant, I don't particularly care what little programs I would start up. If you are sitting at a Unix shell prompt, needing to do something one-off or not terribly time critical, you have already been dealt your hand and it is clear what you need to do to play the game to a successful conclusion.
EN> after EN> all, the shells don't run small programs do to filename EN> globbing, anymore, and numerous other common tasks have been EN> incorporated into the shells, simply because it makes a lot EN> more sense to incorporate them than to run small programs all EN> the time, partly because start-up time for even small programs EN> begin to matter when you have to do it hundreds of times EN> because everything you _do_ is made up a whole school of tiny EN> little programs.
Yes, this is true from an elegance point of view. Olin Shivers makes a similar argument in his scsh paper. I agree with him and I agree with you. There are two semi distinct arguments here though. One concerns the inelegance and inefficiency of the Unix way of doing things with lots of little programs glued together by the shell scripts and/or pipes. This is mostly an aesthetic argument as far as I am concerned. These things work just fine for Real Unimportant Tasks. I think the more significant point, which is distinct from the first, is what you say below:
EN> in case it hasn't become obvious by now: the more people get EN> good at writing small programs that run in "barely noticeable EN> time" each, the more silly things like start-up time matter to EN> them. the more they get good at these silly things, the less EN> intelligently they design their software, and the less likely EN> they are ever to produce software that doesn't consist of tiny EN> little fragments of code that never quite work together.
This is an important observation and precisely why people entering the field by writing shell scripts need to somehow (at school? by mentors at work?) be told that even though what they know how to do works and works fine for Real Unimportant/Simple Tasks, it most certainly is NOT the one true way of doing things. When this is not done,
EN> when you reinvent serious programming languages in scripting EN> languages, which people have been doing in the Unix world for EN> ages, what you get is a lot of people who can do useful things EN> in no time, and no people who can figure out how to do stuff EN> that obviates the need for tiny hacks or at least that curbs EN> their dramatic increase.
Yes. So it gives rise to inefficiency, and a waste of _probable_ talent. The silver lining, IMHO, is that most of these little hacks only eat up human resources once and then they are shared.
EN> the result is a never- ending EN> increase in the need for more tiny little programs, which EN> costs all parties involved in the processes a lot of money, EN> and which drives up the cost of hiring and doing business. EN> the only people who profit from this development are bad EN> programmers.
I am not sure _I_ have seen enough evidence for this conclusion. Clearly, ignorance passing as expertise would be more likely to be costly than not. I am not sure that cost is paid by businesses, it might be spread out to society at large. But if we will argue in this vein, than we probably need to talk about non-monetary costs (eg the hypothetical smart kid who could find a cure for cancer making a decent living as a bad programmer hacking up HTML-generating Visual Basic for ipo.com.) I am not willing to have this discussion in cll, though I would listen to it elsewhere.
EN> I see no reason why Common Lisp should take part in that EN> development. instead, we should try to explain to people who EN> think they have to hire bad programmers that they don't have EN> to -- they could hire a Common Lisp programmer who knows how EN> to change a mass of RUAs into a coherent system that it takes EN> far less effort to build and maintain than just to keep the EN> old system running.
I agree that this would be possible if people could also be convinced that Common Lisp programmers can be found by making a few phone calls. They cannot be found that easily. If anyone pays me for my opinion on anything like this, I probably am more likely to say get 5 perl hacks and a slave driver because I know that can be done, than get Eric Naggum and clone a spare. Depends on what the project is, of course. I am assuming that a mass of RUA's can go a passable job.
EN> it's somewhat like the difference between EN> a mass of disorganized files and information strewn all over EN> the place and a real database system. and the funny thing is: EN> some people _do_ get the idea.
I think you are being too optimistic here. In the case of databases, they don't get the idea, they just follow the best practice as it is widely known (which can be done sheepishly).
> My point is not about the fatality of the disaster but about the time > lines involved. Civil engineers can't rely on their own experience > because they can't get enough experience to do their jobs.
Neither can programmers. Look at old code (not just in Lisp, in any language) if you don't believe that. Look at language design. There's a reason things are now different (better, perhaps), and that's because people are learning from others' experience.
> The point I was refuting was that Lisp programming is like civil > engineering. It's not.
It's much more like it than most people think. If programmers (lisp included) behaved a bit more like civil engineers we wouldn't have so much fouled up and broken software to deal with, and we wouldn't spend so much time repeating the same mistakes over and over.
Erik Naggum <e...@naggum.no> writes: > matter of fact, if you see somebody angry at you, the first thing to do > is consider the question: "what did I do?", _not_ "I don't deserve this!" > and go self-defensive.
On 05 Mar 2000 01:37:04 +0000, Erik Naggum <e...@naggum.no> wrote:
> at least that curbs their dramatic increase. the result is a never- > ending increase in the need for more tiny little programs, which costs [...] > bad programmers that they don't have to -- they could hire a Common Lisp > programmer who knows how to change a mass of RUAs into a coherent system
Is the scsh design a step in the right direction? I would appreciate your comments or opinions on this issue.
In particular, check the paper "A Universal Scripting Framework / or / Lambda: the ultimate ``little language''" among the publications of Olin Shivers. His site is:
In article <3161113129999...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
> * not.for.em...@not.for.spam > | Or even better, Franz should post some
ACL-built executables on their web
> | site, for just such purposes as this.
> the Franz Inc sales staff and their engineers
have related to me in the
> past, and I'm sure I'm not misrepresenting
them now, that they see
> extremely little business value in catering to
people who mainly execute
> really tiny programs like the null program or
"hello, world" programs.
> rather, they have told me, and I have reason
to believe them, that their
> main customers use Common Lisp in large-scale
applications. their
> pricing model, licensing terms, and their
Value Added Reseller programs
> all work very well together to indicate to me
that they regard themselves
> somewhat like Oracle, which also provides a
huge environment that people
> mainly use to deploy Really Important
Applications, not somewhat like
> Larry Wall and the Perl team, who provide a
large fuzzy toy environment
> that people mainly use to deploy Really
Unimportant Applications.
> catering to the RUA people is antithetical to
doing business well with
> the RIA people. everybody in the computer
business _knows_ this, except
> the RUA people, but they don't _actually_
count, even though they think
> they do. for some bizarre reason, RUA people
think their RUAs grow into
> RIAs when in fact they don't. vast networks
of half-cooperating RUAs are
> actually reimplemented by RIA people into a
much smaller and leaner RIA
> than the RUA people could ever hope to realize
when push comes to shove.
> RUA people can graduate into RIA people if
they first learn to dispense
> with the notion that RUAs _matter_. they
don't. really. nobody is
> interested in how many RUAs you have written
when they are looking for
> people to write RIAs. and I _mean_ nobody.
RIA people need to show
> their ability to deal with complexity by
reducing problems by solving the
> really big problems. RUA people show their
ability to create complexity
> by profilerating tiny solutions. if making
something you yourself can
> use takes 1 unit of time, making something
somebody else can use takes 3
> units of time, and making a system that
somebody else can use to to build
> something that starts the whole scale all over
again, takes 9 units of
> time. most people are extremely unprepared to
build such systems, yet
> this is what it takes to grow an RIA
programmer from an RUA programmer.
> that's why we need RIAs so people who think
they are worth something in
> this here overheated industry can write RUAs
on top of RIAs and make
> their employers happy -- they should not
_ever_ believe that because they
> are using an RIA to write RUAs, they are
somehow equipped to write RIAs.
> | To really meet their needs, it has to fit not
only the better paradigms
> | but also the ones they already use, even if it
doesn't fit them as well
> | as C++ does.
> for some reason, everybody realizes that civil
engineering is different
> from building a toy city in a sandbox. you
can't become a civil engineer
> by presenting however many pictures of
beautiful sandbox cities. it
> takes much more than that, different skills,
realizing different needs,
> different attitudes, different time lines,
different economies. for one
> thing, you can't tear up a real city like you
can destroy your sandbox
> city and you can't just start over if you
realize that you failed. this
> is the really big difference between RUAs and
RIAs. an RUA can be torn
> down and replaced on short notice. that's
what makes it an RUA. an RIA
> can't be torn down without jeopardizing really
serious investments, such
> as the entire existence of a company.
> there is hope for RUA people who are bored of
writing small things, but
> there is no hope at all for RUA people who
still think "hello, world" is
> interesting in any way, shape, or form. RIA
people think differently,
> too -- most of them enjoy discussing
large-scale philosophical issues,
> and are usually very hostile to the really
petty issues that most people
> think are inordinately important in their own
lives. RUa people are well
> suited to deal with their own lives in all its
detail. RIA people deal
> with thousands and millions of lives in some particular respect.
> | The programmers know they will be working
towards something better, but
> | they need a foundation to stand on while they
work, and that means being
> | able to do what they do now, and advance from
there one step at a time.
> this is almost entirely false. it is true in
the sense that people need
> to make one step at a time to make any serious
changes to their lives,
> but deciding to go from RUA to RIA is like
going from playing doctor with
> the kid next door (while yourself a kid --
we're not talking about Visual
> Basic, here) to actually putting in the
planning and all the effort to
> _become_ a doctor some fifteen years later,
during which time you don't
> play doctor all that much, I can tell you.
deciding to go from RUA to
> RIA is a _complete_ replacement of your whole
mind-set towards what
> computers can and should do. (e.g., an RUA
person may think it's OK for
> a computer to crash. an RIA person thinks of
a dying machine the same
> way a doctor does about a patient, or a
military leader about soldiers:
> it should not happen without conscious effort
to avoid it to the best of
> one's ability.)
> | But fear of other tradeoffs, such as a 1000 to
1 ratio of the above test,
> | might be what keeps them from proceeding.
> no, what keeps them at bay is fear of
insufficiency in becoming an RIA
> person. trust me on this -- I try every
single day to find RIA material
> among the hundreds and thousands of RUA people
I brush against on the Net
> and in real life. perhaps one in 200 people
are suitable, and the best
> way you can spot them is they are _not_
exicited about trifling news and
> hyped-up products or stale ideas in new packaging.
> | Your post of your numbers was appreciated and
surprising. I had no idea
> | ACL could start that fast on any machine. I'm
a lot more interested in
> | the possibility of using it for a future
project now than I was before.
> I'm sort of glad you appreciate it, but to me,
the whole point was to get
> _rid_ of your false concerns, not help you
validate them. I regret very
> much if I did the latter. start-up time is
_completely_ irrelevant. as
> others have pointed out, if you need to
perform a certain task often, you
> investigate scaling issues and find that
optimizing for scale is a very
> different task from optimizing for individual
execution. it's somewhat
> like optimizing for having fun in your sandbox
compared to saving a city
> billions of dollars through excellence in civil engineering.
> #:Erik
what planet are you from? your generalized RUA name doesn't make sense. Are you talking about OpenSource developers as a whole? Explain please.
I'll admit, i haven't written RIA's. But what do you mean by saying RIA's are different from RUA's? Is the linux OS an RIA or an RUA? sure, the processes are different between corporations and opensource, but i dont see how that matters, as linux is an excellent os, and most commercial ones are simply adequite.
Ill also admit there are craploads of apps under opensource that are RUA's, but thats a nobrainer; these are often dead-wood projects, projects-in-embryo, or just flat-out failures that people started for fun. But the funny thing is, these RUA's DO turn into RIA's often. Maybe you have a chip on your shoulder? :^)
