> > For Basic and C, if the compiler/interpretor is not already on a > > machine (any machine), any idiot can buy it at the corner computer > > store and install.
which is by C/C++ and VB usage has become so wide spread.
> > For Scheme and Lisp, finding/buying/downloading and then compile/install > > is distinctly not for people still learning to write "Hello World".
> So you are saying that one of the qualities of a language is where you > can buy it? I'll remember that next time I'm creating a computer > language...get contracts with Egghead and K-Mart before writing the > technical spec.
No, the quality of the language has absolutely NOTHING to do with it's uptake. The Ada language is a perfect example of this. A high quality language (leaves C for dead as I have previously stated) but almost zero uptake, simply because of availability and cost! While the big vendors (DEC, IBM, ...) did provide quality compilers their cost was astronomical in mid-range systems and PC terms. The DEC compiler/environment cost upward of $100,000 on a machine that was barely adequate to support a single programmer. In the scheme of a large defense contract, forking out 0.5 - 1.0 mill for multiple compiler licenses probably would barely have appeared on the bottom line costing of a project, but for everyone else it is QUITE significant and meant that for your smaller project people would fall back on what was available at affordable cost, ie. C!
There is probably some hope for a quality language (J++?!) given availability at reasonable cost, although I don't think M$ is prepared to give up the battle just yet.
* Cyber Surfer | EVAL is useful for creating an interactive language, but it's | not something I want to deliver to a client.
excuse me for saying this, but aren't you complaining all the time that you don't _have_ any clients you could have delivered anything Lispy to at all? once you get Lisp clients, you may find cause to reconsider.
people who are afraid of the name `eval' invent their own version of its functionality, badly. just like people who are afraid of the name `lisp'.
#\Erik -- Please address private replies, only, to "erik". Junk mail, spam, stupid flames, courtesy copies, etc, should be sent to "nobody".
Steve Barnard <st...@megafauna.com> writes: >I really like Lisp, too. It is far more pleasant to use Lisp than C, >but you'd have to be a fool to use Lisp for performance-oriented >supercomputer codes, unless there have been some developments in the >last few years that I'm unaware of.
for floating point code that is not slower than C (even faster on some platform/compiler combinations). This is at least the case if you use CMU Common Lisp (http://www.cons.org/cmucl/). CMUCL has been around for some years now.
I wrote many programs were I found C (no ++) to be a pleasure to use, BTW.
Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Martin_Craca...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
Steve Barnard <st...@megafauna.com> writes: >1. It has all the control structures and support for data structures >that I need.
So, has GWbasic all the constructs you'd need? No? IMHO, the features a programmer feels a need for rely on what he did before.
People usually use a subset of what their language offers (mostly a fairly complete subset). Since they already have some constructs they don't need in their current langauge, the impression that more powerful langauges offer no more features than needed is close.
The situation gets really bad when a programmers comes around to learn a langauge where the number of features are minimized, but the flexibilty of features is maximized (A dinfition of what Scheme is intended to be).
At that point, one can get really frustrated with any number of features as long as the langauge doesn't allow to define your own implementations of features of the same power of they build-in features of the language.
In other words: The point about Lisp is that you can work on a 'meta-level', in C you are bound to a number of language features.
>2. It lets me get as close to the machine as I want to get.
What about alignment in structures? The compiler doesn't support control without non-ANSI extensions. You'll have to use byte arrays to do so portably, but then you can do the same in Lisp.
>3. Pointer arithmetic is the single greatest language feature I've ever >seen for a performance-oriented programmer (Java and Fortran90 >notwithstanding).
See below.
>4. It is extremely portable, if I decide that I want to write portable >code.
printf is part of the language, no? So, could you please give me an example how you can write a printf control string that prints a data type where the actual type is hidden by a typedef inside an include files that is machine-dependent?
This is obviously not a difficult part for (format ...)
The NetBSD folks who have an OS that is portable across a number of machine already though of adding a printf %-directive that accepts a control string where the data type to print is given. Something like printf("%(off_t)I",some_off_t). Of course, such a solution would still require that your output format is still the same for all types.
>5. It doesn't take the stance that I'm an idiot and have to be protected >from my own mistakes. It lets me shoot myself in the foot if I want to.
A good Lisp compiler offers all the Guns you need. It is certainly more difficult to use than in C, don't pointers to any lacation are part of all high-quality Lisp implementations I know of.
>6. At the same time, it allows me to use the compiler to detect many >programming errors, assuming I have the good sense to use function >prototyping.
This is the usual static/dynamic typing debate and a matter of taste. Common Lisp and Scheme clearly decided to be on the dynamic side. You might want to look into SML if you want static typing. I don't know too much about it, but my above points about low-level features in high-quality Lisp implementation certainly apply to SML/NJ as well. ML introduces some performance problems by definition, maybe someone can point out a langauge that is Lisp-like, but to so much functional-programming oriennted as ML (and has a descent compiler).
>I say this as a former Lisp hacker of many years (in my previous AI >life). The only problem I have with Lisp is that it hides the machine, >which is bad if your God is performance.
I like C, too and there are many point I don't like about Common Lisp and Scheme, but performance is no longer the reason to prefer one of the other. A C function in a Lisp program usually does its job as well when I'm too lazy to beat on my Lisp compiler.
Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Martin_Craca...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
}Chris Pirih, proverbs at wolfenet dot com wrote: }> In article <58k2rr$...@news.network.com>, }> r...@network.com (Rob Peglar) wrote: }> | What is south of I-90? Iowa. }> Have I wandered into comp.geography.bigot by mistake? }Actually... geography does have a lot to do with who we are. }In the beginning... there was Philadelphia.
In the beginning... there was Ames, Iowa.
}Now do you understand why we cherish our geographic roots?
* Steve Barnard wrote: > 3. Pointer arithmetic is the single greatest language feature I've ever > seen for a performance-oriented programmer (Java and Fortran90 > notwithstanding).
Hmmm. But isn't pointer arithmetic just what makes languages like C a real pain to write optimising compilers for (compared to fortran &c)?
> 5. It doesn't take the stance that I'm an idiot and have to be protected > from my own mistakes. It lets me shoot myself in the foot if I want to.
Everyone is an idiot and needs to be protected from their own mistakes.
> > But you could write a different book about why computers crash, not > > the technical details, but the *real* reason. Talk about what > > software engineering is and why it's so difficult, especially on large > > projects like operating systems. That could be reasonably accessible > > (a la Soul of a New Machine).
> It doesn't really matter whether software engineering is hard or easy, the > market in the last ten years has shown that once you get the machine > stable enough to run for a couple of hours for the average user, it's > better to spend any additional money/resources on more features and > marketing than on getting out the remaining bugs.
At cynical as it sounds, it appears to be true. The new book by Yourdon "The Rise and Resurretion of the American Programmer" makes more or less this point. He calls it "Good Enough" programming. Whether you agree with this or not, the book is worth reading.
In article <3059670197357...@naggum.no> nob...@naggum.no "Erik Naggum" writes: > excuse me for saying this, but aren't you complaining all the time that you > don't _have_ any clients you could have delivered anything Lispy to at all? > once you get Lisp clients, you may find cause to reconsider.
Excuse me, but I think I know my clients rather better than you do. They don't give a shit about Lisp, but they do care about a great many other things, like image size.
> people who are afraid of the name `eval' invent their own version of its > functionality, badly. just like people who are afraid of the name `lisp'.
I've no use for EVAL. I've never used it in any of my code, nor I expect to ever do so. Did you see the figures for code sizes that I posted? Can you deny that EVAL was so much larger than anything else in Gambit C? Can you convince me that I really need all this code?
If I can live without it, then I will. And I do. Sadly, I don't do it in Lisp, but I can certainly live without it. I've not yet found a Lisp to C compiler that does what I'm looking for (mostly Win32-specific things), but there are plenty that do things that I don't want (e.g. EVAL).
Curiously, Smalltalk MT appears to do _all_ the things that I'm currently interested in, and will soon be able to do some things that will also be _very_ welcome. As standard. For a mere $295.
Forgive me if I'm misrepresenting you, but it often seems to me that your argument is that everyone can and should use Lisp, regardless of what anyone else thinks. If somebody would like to pay me to write Lisp, instead of Windows, software...
Please note that distinction. I don't put Lisp first, and the OS second. The job comes first, and the tools are often determined by the work to be done. That in turn depends on a great many other factors, not least of which are the clients' requirements.
If there's a way of satisfying them by using Lisp, then I'll be very interested. However, I don't start by choosing Lisp, and then looking for clients to write code for. Perhaps you're more fortunate than I am...
I'm not knocking the free Lisp compilers available via the Internet. That would be unfair. However, I'm more than happy to spent a little money to get the features that I'm looking for, and to avoid those features that I'd rather not "pay" for, at runtime.
With C++. I'm "paying" at development time. ;-) I'd like to avoid that, too. If I can do it by using alternatives to Lisp, like Smalltalk MT and eventually DylanWorks, then I will. BTW, when I refer to Lisp, I include Scheme, ANSI Common Lisp, ISO Lisp, and Standard Lisp, amoung other dialects. I think of Dylan as a dialect of Lisp, even if some Lisp people don't. I'm not dogmatic about using Lisp, or defining what it is or isn't.
Followups narrowed to: comp.lang.lisp,comp.arch -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
In article <1996Dec16.114937.4...@wavehh.hanse.de>,
Martin Cracauer <craca...@wavehh.hanse.de> wrote: > >4. It is extremely portable, if I decide that I want to write portable > >code. > printf is part of the language, no?
In article <32B333DC.5FC32...@clarkcom.com>, Glen Clark <g...@clarkcom.com> wrote:
> Stanley Chow wrote: > > The C language is particularly rich with ways of writing a program > > that totally hides the original design intent. > Some things are just so elegant, many of Frank Lloyd Wright's > designs come to mind, that you just want to stand and marvel > at them. I think the above one-liner is in that class.
It's a great one-liner, but it seems to me that if your code hides your intent then you shouldn't have taken on that code, except perhaps as a learning experience, in the first place. Sorta like the way Utson quit halfway through the building of the Sydney Opera House because his design was unworkable... the resulting structure is in my mind far more beautiful than the low elliptical arches he wanted. He shouldn't have tried to actually implement his inspiration... -- </peter>
Bruce Hoult <Br...@hoult.actrix.gen.nz> wrote: > It doesn't really matter whether software engineering is hard or easy, the > market in the last ten years has shown that once you get the machine > stable enough to run for a couple of hours for the average user, it's > better to spend any additional money/resources on more features and > marketing than on getting out the remaining bugs.
Man you are *so* cynical. If that was true, why, how could anyone possibly compete with a company that ships alphas as products and does quality control by random consumer testing... -- </peter>
* Cyber Surfer | Excuse me, but I think I know my clients rather better than you do.
no doubt, but we all know they are clients who don't want solutions, they want to make decisions about random factors of the implementation, ...
| They don't give a shit about Lisp, but they do care about a great many | other things, like image size.
... like image size.
| I've no use for EVAL. I've never used it in any of my code, nor I expect | to ever do so.
can you think of Emacs without `eval'? or indeed any other Lisp system? I rely on `eval' like nothing else in the Lisp systems I use.
| Did you see the figures for code sizes that I posted? | Can you deny that EVAL was so much larger than anything else in Gambit C? | Can you convince me that I really need all this code?
how the hell is anybody supposed to know what a figure like that means? your numbers are _literally_ meaningless. like most statistics, they are presented as if numbers alone had meaning. like anybody who has even an inkling of understanding of statistics knows, it's what you have measured that give the meaning, not the (numerical) measurement.
| Forgive me if I'm misrepresenting you, but it often seems to me that your | argument is that everyone can and should use Lisp, regardless of what | anyone else thinks. If somebody would like to pay me to write Lisp, | instead of Windows, software...
first, there is a very fundamental difference between rejecting invalid arguments and embracing the opposite of an invalid argument, whatever that might be. you don't seem to understand this difference very well. just because you offer so many invalid arguments and so much bullshit about how hard Lisp is for your sorry case, and I object and reject them, does not mean that any more of your invalid arguments, this time about what I think, magically become true. you're illogical and irrational. that annoys me, more so when you don't seem to recognize that more than just your arguments are being rejected -- the entire set of premises from which you draw them is being rejected.
second, there is nothing more destructive in a community of professionals than the sickening tendency among people of lesser integrity to consider _first_ what other people might think, _then_ what might be possible. I make my living on the premise that the reverse order is the only valid one, and frequently forget what other people might think. sometimes it takes a lot of effort to ignore other people's objections, however.
third, "somebody" doesn't just call you up, saying "we'd like to pay you to write Lisp". they call you up to ask for your assistance on a hard problem, they listen to your suggestions and accept your design if you can present it credibly, they are willing to fork over a lot of money for a license to a supported, commercial Lisp development environment if you present the case for it, but only if you present the case for it, and they leave you alone for a month or five while you work out the magic. but you don't get called like that just by sitting in your uncomfortable office chair, writing Windows applications and airing your frustrations on comp.lang.lisp -- I sure as hell wouldn't call you with an offer to work on a Lisp project. it takes real-life effort, and may put tens of thousands of pounds of your personal income on the line, in saying "this can save us much more than it costs and much more than any alternative", and actually prove it.
| If there's a way of satisfying them by using Lisp, then I'll be very | interested. However, I don't start by choosing Lisp, and then looking for | clients to write code for. Perhaps you're more fortunate than I am...
perhaps I just work harder at it than you do. perhaps I work on problems that can't be solved in a realistic time frame in any other language than Common Lisp and within a large Common Lisp system. perhaps this has cost me three years of basically living off of writing articles and giving lectures instead of programming. perhaps I succeed in what I want because I don't waste my time and brain prostituting myself on Windows and Visual whatever? perhaps I got so sick and tired of programming in stupid languages like C and C++ that I wanted to sit down and invent my own language, build up my own support organization and try to sell it to others. or I could find a language that gave me all I needed, and as soon as I found a client who was interested in more than trivial solutions, have them fund my acquisition of tools from somebody who had already invented and implemented such a language. I chose the latter. nonetheless, I enjoy nitty-gritty details of implementation, _ONCE_. I'd like to do things only until I learn to do them expertly, then move on.
| I'm not dogmatic about using Lisp, or defining what it is or isn't.
the net effect is that you're not programming in Lisp for any clients. you can use whatever reasons you want to defend this position, if you think it needs defending (and if my recollection of your postings here for the past few months is correct, you portray a tremendous need to defend yourself and your position). my impression is indeed that you are dogmatic about Lisp, but not positively so, _negatively_ so: you repeat and stress how Lisp is never the right solution for you, despite repeated examples and much assistance to the contrary. this is very, very annoying. instead of concluding that "Lisp is not right for the jobs that Cyber Surfer does", the conclusion becomes "Cyber Surfer is not right or the jobs that Cyber Surfer does". I would never hire you for your newspostings. several people _have_ hired me for my newspostings.
I'm no longer interested in understanding why you hold the positions you do, because I have yet to find any actually _constructive_ part to your whining. also, I have proven that with a much effort and with a braveness that I look back upon in awe -- I put much more on the line than I ever realized -- I have managed to land two contracts that bring me out of the Lisp wannabe camp, and right into the middle of a breakneck action movie. I haven't had so much fun in many, many years. I don't know if I will come out of this on top, but for the first time in at least five years, I can say to myself "I want to be a programmer and I think I can make it".
and by "a programmer" I don't mean an assembly line worker who churns out C or C++ or any of that shit. I want to build large structures and systems, not just line up a lot of new copies of the same old stuff side by side and call that a career. now I think I can pull it off, but I couldn't do it without a major Lisp vendor giving me unparalleled moral and technical support, and I couldn't do it without clients who really understand and listen to what I have presented to them. incidentally, most of this has happened in the past couple months, with _years_ of preparation on my part. maybe I have just been very fortunate, but I don't think these things just happen. still, I'm deeply grateful to the people who make it possible for me to enjoy programming for pay, again -- this time in a language that lets me think hard about hard issues, not waste all my time on trivial things.
Peter da Silva (pe...@nmti.com) wrote: : In article <2933267...@hoult.actrix.gen.nz>, : Bruce Hoult <Br...@hoult.actrix.gen.nz> wrote: : > It doesn't really matter whether software engineering is hard or easy, the : > market in the last ten years has shown that once you get the machine : > stable enough to run for a couple of hours for the average user, it's : > better to spend any additional money/resources on more features and : > marketing than on getting out the remaining bugs.
: Man you are *so* cynical. If that was true, why, how could anyone possibly : compete with a company that ships alphas as products and does quality control : by random consumer testing...
Oh, I don't know. Haven't you just described Microsoft?
[ 8^) Couldn't resist. Now in pennance I must say Hail Hoppers...]
> In article <2933267...@hoult.actrix.gen.nz>, > Bruce Hoult <Br...@hoult.actrix.gen.nz> wrote: > > It doesn't really matter whether software engineering is hard or easy, the > > market in the last ten years has shown that once you get the machine > > stable enough to run for a couple of hours for the average user, it's > > better to spend any additional money/resources on more features and > > marketing than on getting out the remaining bugs.
> Man you are *so* cynical. If that was true, why, how could anyone possibly > compete with a company that ships alphas as products and does quality control > by random consumer testing... > -- > </peter>
An excellent question. Microsoft's competitors have wondered about that for years ;-).
In article <594ro9$...@web.nmti.com>, Peter da Silva <pe...@nmti.com> wrote:
>In article <32B333DC.5FC32...@clarkcom.com>, >Glen Clark <g...@clarkcom.com> wrote: >> Stanley Chow wrote: >> > The C language is particularly rich with ways of writing a program >> > that totally hides the original design intent.
>> Some things are just so elegant, many of Frank Lloyd Wright's >> designs come to mind, that you just want to stand and marvel >> at them. I think the above one-liner is in that class.
Thanks Glen.
>It's a great one-liner, but it seems to me that if your code hides your >intent then you shouldn't have taken on that code, except perhaps as a >learning experience, in the first place.
Hmm, aren't you making some pretty strong assumptions?
"Your code", "your intent", "shouldn't take on", "learning".
Of course, I only ever write well-structured, clearly-commented, trivial-to-understand, simple-to-modify, universially-portable, algorithmicly-optimal and micro-efficent programs; and surely your standard is similar. As I always say:
if you can't afford a year to write a hundred *good* lines, you ought not be programming in C.
We are discussing those unwashed masses - not trained to appreciate the subtle distinctions between pointer and array, unaware of how some compiler writers take "implementation dependent" at face value. Those fools actually have to take some grubby code and make some changes, worse, they even have to meet deadlines or stop feeding their kids! How barbaric can you get!
>Sorta like the way Utson quit >halfway through the building of the Sydney Opera House because his design >was unworkable... the resulting structure is in my mind far more beautiful >than the low elliptical arches he wanted. He shouldn't have tried to >actually implement his inspiration...
I am not sure what this means. Are you saying people should forget their design and just write code? Or are you saying people should adapt their design as the project progresses?
-- Stanley Chow; sc...@bnr.ca, stanley.chow-...@nt.com; (613) 763-2831 Bell Northern Research Ltd., PO Box 3511 Station C, Ottawa, Ontario Me? Represent other people? Don't make them laugh so hard.
>| I've no use for EVAL. I've never used it in any of my code, nor I expect >| to ever do so.
Erik Naggum replied:
>can you think of Emacs without `eval'? or indeed any other Lisp system? >I rely on `eval' like nothing else in the Lisp systems I use.
Emacs isn't a particularly good benchmark for making generalizations about Lisp systems - elisp is a fairly old, quirky language without many of the features of Common Lisp. I've written many hundreds of thousands of lines of Common Lisp without ever calling eval once - and this was in dynamic, end-user programmable environments (class & prototype based visual programming systems, highly parallel blackboard systems with integrated rule engines), defining new classes and methods on the fly, etc...
As for the rest : [ extensive dogmatic flamage deleted ]
Just chill out and discuss this like adults. I've always noted Cyber Surfer's posts to be reasonable, intelligent, and open-minded, quite unlike #\Erik's flamage.
> > 3. Pointer arithmetic is the single greatest language feature I've ever > > seen for a performance-oriented programmer (Java and Fortran90 > > notwithstanding).
> Hmmm. But isn't pointer arithmetic just what makes languages like C a > real pain to write optimising compilers for (compared to fortran &c)?
That may well be true, but there are often times when an optimizing compiler can't do a good job. A lot of stuff I develop involves very unstructured, sparse-matrix operations, usually on distributed-memory parallel computers. There is so much indirection that I've found that compiler-generated optimizations are often not as good as what I can do by hand with pointer arithmetic. Sometimes I'll even precompute and store absolute addresses to avoid doing indexing arithmetic over and over (assuming I have space).
You may argue that if I were using a language without pointer arithmetic (say, Fortran) then the compiler would optimize well enough, but Fortran77 doesn't have other features that I need, like dynamic storage allocation. I'm just starting to look at Fortran90 and it looks pretty good, but it's still not as universally available as C and so Fortran90 code isn't as portable. I don't have it on my SGI Indy workstation, for example.
> > 5. It doesn't take the stance that I'm an idiot and have to be protected > > from my own mistakes. It lets me shoot myself in the foot if I want to.
> Everyone is an idiot and needs to be protected from their own > mistakes.
You must be either a liberal Democrat or a product-liability attorney. :-)
>Bruce Hoult <Br...@hoult.actrix.gen.nz> wrote: >> It doesn't really matter whether software engineering is hard or easy, the >> market in the last ten years has shown that once you get the machine >> stable enough to run for a couple of hours for the average user, it's >> better to spend any additional money/resources on more features and >> marketing than on getting out the remaining bugs.
>Man you are *so* cynical. If that was true, why, how could anyone possibly >compete with a company that ships alphas as products and does quality control >by random consumer testing...
Maybe I'm cynical, too. But aren't we just seeing this happening? That software from a company called MegaHard ? (or whatever it is called?)
* Adam Alpern | I've written many hundreds of thousands of lines of Common Lisp without | ever calling eval once - and this was in dynamic, end-user programmable | environments (class & prototype based visual programming systems, highly | parallel blackboard systems with integrated rule engines), defining new | classes and methods on the fly, etc...
then it should be entirely safe for you to evaluate (fmakunbound 'eval) and report how well your system works, or how well you work. right? if not, please explain what you mean by "without ever calling eval once". just because somebody else does it for you, doesn't mean you don't use it. otherwise, you could just have a "designated eval caller" (a.k.a "the fall guy") in any Lisp community, and he could write a wrapper with another name which you could call. washing your hands of all eval, you can now use this function, instead.
this is like some orthodox Jews who are forbidden to do work that involves machinery of any kind during the Sabbath, and thus can't turn on electric lights. to solve this problem, they have devised a stick that they can use to turn the switch for them. it's not machinery, and they do get light.
it's also quite symptomatic and tragic that you didn't see the point in what you deleted as "dogmatic flamage": _work_ hard and be prepared to sacrifice a lot to realize the dreams you take seriously, don't just sit there and _whine_ about a life you refuse to change. now, I suppose you disagree with _this_, too.
* Adam Alpern | I've written many hundreds of thousands of lines of Common Lisp without | ever calling eval once - and this was in dynamic, end-user programmable | environments (class & prototype based visual programming systems, highly | parallel blackboard systems with integrated rule engines), defining new | classes and methods on the fly, etc...
at first I was impressed by this, but it didn't match the contents of your article so I ignored it. then I looked you up on the Web, and found that you have just (as of 1996-07-02) graduated from Hampshire College, and that you don't mention this work in your resume.
at full speed, I write about 1 line of Lisp code per minute, including think time. "many hundreds of thousands of lines of Common Lisp" would translate, for me, into many hundreds of thousands of minutes, if we make the invalid assumption that I can sustain this speed for a whole day at a time. suppose now that we have 500 minutes a day available for programming Lisp, and suppose that "many" means more than 5, we can safely assume that you have been working on this system full time for at least three years, five if you take vacations and weekends off. this flies in the face of your resume, and must therefore be assumed to be an utterly foolish lie on your part.
next time you feel a desire to brag like that, update your resume first.
as for some real numbers, when I stopped writing C for fun and profit three years go, at about the time you entered college. I estimated that I had _written_ about a million lines of code over the preceding 15 years, but published (i.e., made available to more than 10 people, either as source or compiled code) less than a tenth of that. I can hope to have published "many hundreds of thousands of lines of Common Lisp" when I celebrate my 40th anniversary. I would consider that a real achievement.
I regret that I wasted time on finding this information, but I would have liked to know somebody who had written many hundreds of thousands of lines of Common Lisp.
> In article <2933267...@hoult.actrix.gen.nz>, > Bruce Hoult <Br...@hoult.actrix.gen.nz> wrote: > > It doesn't really matter whether software engineering is hard or easy, the > > market in the last ten years has shown that once you get the machine > > stable enough to run for a couple of hours for the average user, it's > > better to spend any additional money/resources on more features and > > marketing than on getting out the remaining bugs.
> Man you are *so* cynical. If that was true, why, how could anyone possibly > compete with a company that ships alphas as products and does quality control > by random consumer testing...
You're right. It couldn't possibly happen. I was mistaken. Any company can rise to the top if they only strive for technical perfection.
-- Bruce
-- ...in 1996, software marketers wore out a record 31,296 copies of Roget's Thesaurus searching for synonyms to the word "coffee" ...
Would you _both_ please take this off-line? Thanks. -- William A. Barnett-Lewis wle...@mailbag.com ------------------------------------------------------------------------ - "We are artists. Poets paint motion and light. Historians paint stills. It can be dangerous to get history from a poet. It can also be the greatest blessing." ------------------------------------------------------------------------ -
