That's basically a question that I ask in my most recent blog post (
Jan 9, www.xanga.com/datahelper ).
The title is obviously tongue in cheek, so don't start a flame war.
So LISP programs can produce LISP programs. But in practice, can this
really improve a coder's productivity? If it can, then why hasn't LISP
become more widely spread?
I note in the my blog entry that , my very early first impression , is
that the evaluation/non-evaluation of lists and the need for the quote:
' can cause additional code maintenance costs. Do you find this to be
the case?
If you want to know who I am, I'm a pharma-statistician, mathematician
, and specialist in the realm of statistical programming languages.
Robert
From: Ken Tilton
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <5FSoh.12$t75.9@newsfe10.lga>
Robert wrote:
> That's basically a question that I ask in my most recent blog post (
> Jan 9, www.xanga.com/datahelper ).
> The title is obviously tongue in cheek, so don't start a flame war.
>
> So LISP programs can produce LISP programs. But in practice, can this
> really improve a coder's productivity? If it can, then why hasn't LISP
> become more widely spread?
>
> I note in the my blog entry that , my very early first impression , is
> that the evaluation/non-evaluation of lists and the need for the quote:
> ' can cause additional code maintenance costs. Do you find this to be
> the case?
>
> If you want to know who I am, I'm a pharma-statistician, mathematician
> , and specialist in the realm of statistical programming languages.
>
> Robert
>
1. Why do you shout when you say "Lisp"?
2. Wow! Lisp flame wars are a good way to drive traffic to a blog?
PDFTT (note that this is an unfeeding meal)
kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
Robert wrote:
> That's basically a question that I ask in my most recent blog post (
> Jan 9, www.xanga.com/datahelper ).
> The title is obviously tongue in cheek, so don't start a flame war.
Regarding the "herd mentality", I think there is a strong correlation
between people who want a 9-5 job and people who choose to program in
Java/C#.
> So LISP programs can produce LISP programs. But in practice, can this
> really improve a coder's productivity?
In some very specific circumstances, unquestionably yes.
> If it can, then why hasn't LISP become more widely spread?
What happens when a programming language's features make the elite
programmers much more productive but hinder everyone else?
Also, wide spread compared to what? If you compare Lisp to Haskell or ML
then Lisp is more popular and both Haskell and ML sacrificed EVAL for other
features that the language designers believed would improve productivity to
a greater extent.
> I note in the my blog entry that , my very early first impression , is
> that the evaluation/non-evaluation of lists and the need for the quote:
> ' can cause additional code maintenance costs. Do you find this to be
> the case?
From your blog:
> The quote keyword (with extra parentheses to boot) can quickly make your
> code very verbose.
can make your code very verbose compared to what? What is the Java
equivalent of '(+ 1 2)? Lisp is actually very concise in this specific
case...
> Do functional programming languages provide huge gains in productivity
> relative to more conventional programming languages,
Yes, definitely.
> and if so, for what problem domains?
Compilers
Interpreters
Logic
AI
Symbolic mathematics
Graphics
...
Google for programs written in functional programming languages, e.g. FFTW.
I posted a simple symbolic derivative example on Code Codex:
http://www.codecodex.com/wiki/index.php?title=Derivative
Note how much simpler the Lisp and OCaml are compared to the C++.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
>>>>> "JH" == Jon Harrop <···@ffconsultancy.com> writes:
JH> Regarding the "herd mentality", I think there is a strong
JH> correlation between people who want a 9-5 job and people who
JH> choose to program in Java/C#.
But is that cause or effect, or feedback loop?
Charlton
--
Charlton Wilbur
·······@chromatico.net
From: John Thingstad
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <op.tlwqhrgwpqzri1@pandora.upc.no>
On Tue, 09 Jan 2007 22:16:03 +0100, Charlton Wilbur
<·······@chromatico.net> wrote:
>>>>>> "JH" == Jon Harrop <···@ffconsultancy.com> writes:
>
> JH> Regarding the "herd mentality", I think there is a strong
> JH> correlation between people who want a 9-5 job and people who
> JH> choose to program in Java/C#.
>
> But is that cause or effect, or feedback loop?
>
> Charlton
>
>
Nearly all cause and effect is also a feedback loop..
Why do you think differential equations play such a large role in physics.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jon Harrop <···@ffconsultancy.com> writes:
> Robert wrote:
>> That's basically a question that I ask in my most recent blog post (
>> Jan 9, www.xanga.com/datahelper ).
>> The title is obviously tongue in cheek, so don't start a flame war.
> From your blog:
>> The quote keyword (with extra parentheses to boot) can quickly make your
>> code very verbose.
Hey Robert, can you tell me where you parked your Delorean?
In Lisp, ' exists at least since March 3, 1979.
http://zane.brouhaha.com/~healyzh/doc/lisp.doc.txt
Robert, where have you been during the last 28 years?
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
Jon Harrop wrote:
> Regarding the "herd mentality", I think there is a strong correlation
> between people who want a 9-5 job and people who choose to program in
> Java/C#.
So you're saying (1) that people who don't want to take their work home
with them choose Java and C#, and that having a life outside your work
constitutes "herd mentality"? How pathetic...
sean wrote:
> Jon Harrop wrote:
>> Regarding the "herd mentality", I think there is a strong correlation
>> between people who want a 9-5 job and people who choose to program in
>> Java/C#.
> So you're saying (1) that people who don't want to take their work home
> with them choose Java and C#, and that having a life outside your work
> constitutes "herd mentality"? How pathetic...
Mooooooooooooooooo
--
Dan
www.prairienet.org/~dsb
Jon Harrop wrote:
> Regarding the "herd mentality", I think there is a strong correlation
> between people who want a 9-5 job and people who choose to program in
> Java/C#.
So you're saying (1) that people who don't want to take their work home
with them choose Java and C#, and that having a life outside your work
constitutes "herd mentality" (which is presumably a generic "bad
thing")? How pathetic...
Lisp has been uniquely successful in two areas:
- appealing to programmers who are even more socially inept and
generally annoying than programmers generally are;
- achieving an unprecedented volume of metadiscussion about what Lisp
is good for, if anything.
I believe no other programming language is even in the same ballpark as
Lisp in these two areas. In most other areas it's pretty much a wash.
I believe Lisp's long term achievement will be to serve as the best
single identifier of people-who-should-be-made-into-soap: if someone
has ever had any involvement in Lisp, they should immediately be
rendered down: on no account attempt discussion with them.
--tim
Tim Bradshaw wrote:
> I believe Lisp's long term achievement will be to serve as the best
> single identifier of people-who-should-be-made-into-soap: if someone
> has ever had any involvement in Lisp, they should immediately be
> rendered down: on no account attempt discussion with them.
I can see the future...
A crack team of programmer assassins wandering the earth. They come
and go silently, and wherever they go lisp programmers disappear. The
unfortunate victims are rendered down in huge smell vats. The soap is
sold as a beauty product and soon corners the market.
The result of course is the collapse of civilisation. Everyday
programmers have no inclination to improve their programs, because
there is no-one smugger than themselves to make them feel uneasy. But
most seriously, men are no longer able to understand anything about
women because of the odour of parentheses from the soap. Women become
clearly defined but too abstruse for interest. Men don't understand at
what level of abstraction they're making love to their wives or
girlfriends. I can see myself, half way through unbuttoning a blouse
saying "What do you mean we're on the phone".
On 2007-01-10 04:46:36 -0500, "Tim Bradshaw" <··········@tfeb.org> said:
> I believe Lisp's long term achievement will be to serve as the best
> single identifier of people-who-should-be-made-into-soap: if someone
> has ever had any involvement in Lisp, they should immediately be
> rendered down: on no account attempt discussion with them.
Doesn't this mean that you are scheduled for the soap vat yourself? ;^)
<http://www.tfeb.org/lisp/hax.html>
Raffael Cavallaro wrote:
> Doesn't this mean that you are scheduled for the soap vat yourself? ;^)
>
> <http://www.tfeb.org/lisp/hax.html>
Like Hitler, I am allowed to make special exceptions for myself in
these matters.
--tim
Anyway, you're rashly assuming I am actually that tfb, rather than the
spirit of some ancient tentacled creature which now inhabits his
corporeal remains? I think you'll find this latter explanation fits
the facts much better.
On 2007-01-11 06:18:37 -0500, "Tim Bradshaw" <··········@tfeb.org> said:
> Like Hitler, I am allowed to make special exceptions for myself in
> these matters.
Apparently you also claim exemption from Godwin's law as well. ;^)
Or is this a deliberate attempt to end the thread?
>
> --tim
>
> Anyway, you're rashly assuming I am actually that tfb, rather than the
> spirit of some ancient tentacled creature which now inhabits his
> corporeal remains? I think you'll find this latter explanation fits
> the facts much better.
There's the small matter of Occam's Razor though... ;^)
Raffael Cavallaro wrote:
>
> Apparently you also claim exemption from Godwin's law as well. ;^)
> Or is this a deliberate attempt to end the thread?
>
Godwin's law is *so* last millennium. Bringing up islamic terrorism is
the new Godwin (and not in those dusty old newsgroups, we all use
forums[*] and chat rooms now). We call this `Bradshaw's law'.
> > ancient tentacled creature which now inhabits his
> > corporeal remains? I think you'll find this latter explanation fits
> > the facts much better.
>
> There's the small matter of Occam's Razor though... ;^)
Well, it needs to explain the tentacles.
--tim
[*] Now someone is going to point out that it should be `fora'. If you
just pull your eyeballs out and eat them now it would save a lot of
effort all round. Helicopters cost money to run, you know, not to
mention the thousands of chanting acolytes, curiously wrong geometry,
suncream for the tentacles etc.
A couple of of Tim `Soapy' Bradshaw's tentacles typed:
> We call this `Bradshaw's law'.
[snip]
> Well, it needs to explain the tentacles.
Apparently sufficient exposure to lisp causes megalomania in some cases. ;^)
From: John Thingstad
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <op.tl3lriu8pqzri1@pandora.upc.no>
On Sat, 13 Jan 2007 00:38:09 +0100, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
>
> Apparently sufficient exposure to lisp causes megalomania in some cases.
> ;^)
>
The Tilton effect? :)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> The Tilton effect? :)
He is merely one of my tentacles, yes.
From: Harald Hanche-Olsen
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <pcoy7oaswjb.fsf@shuttle.math.ntnu.no>
+ "Tim Bradshaw" <··········@tfeb.org>:
| I believe Lisp's long term achievement will be to serve as the best
| single identifier of people-who-should-be-made-into-soap:
Who needs that much soap?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
On Wed, 10 Jan 2007 01:46:36 -0800, Tim Bradshaw wrote:
>
> I believe Lisp's long term achievement will be to serve as the best
> single identifier of people-who-should-be-made-into-soap: if someone
> has ever had any involvement in Lisp, they should immediately be
> rendered down: on no account attempt discussion with them.
This goes triple for anyone who has ever at any time been in the same room
with Symbolics hardware. Anyone who ever forgets that the word 'code'
is a mass noun ought to be burned alive: Soap made from them is likely to
be rancid.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Robert wrote:
> That's basically a question that I ask in my most recent blog post (
> Jan 9, www.xanga.com/datahelper ).
> The title is obviously tongue in cheek, so don't start a flame war.
I can't see the title unfortunately, because the corporate firewall I'm
behind thinks that your site is about dating. Probably because the
title contains "data".
I'll just have to reply to your message here.
> So LISP programs can produce LISP programs. But in practice, can this
> really improve a coder's productivity?
For some applications I think so. You have to learn about it to
understand what benefits you can gain. To give an example, CL-SQL
allows the lisp programmer to write portions of his/her program with a
language very similar to SQL which is converted into SQL requests and
handled by a database. Similarly it's possible to make a sub-language
of Lisp to represent HTML or other languages. Also Lisp can be
extended slightly to introduce features not thought of in the original
design. In Lisp there is no "while" looping construct, there is a
similar one called "do". If you want while though, then you can write
it easily.
> If it can, then why hasn't LISP
> become more widely spread?
There are probably many reasons, I can't possibly tell what they really
are, neither really can others. Any answers are mainly supposition. I
think one major reason is that implementing the Common Lisp language
with good performance was difficult in the 80s and 90s.
I don't think that the difficulty of meta-programming has much to do
with it. Although I'd agree that writing major macros/meta-programs is
tricky the most useful macros are normally quite simple. Big
constructions of macros are for library designers.
It's best to assess things on how good they are not how popular they
are. Generally I don't trust the majority of programmers to be smart
enough to select the best tools. Given that I've just seen a program
confuse "data" and "dating" I'm feeling a tiny bit more vindicated in
that point of view.
> I note in the my blog entry that , my very early first impression , is
> that the evaluation/non-evaluation of lists and the need for the quote:
> ' can cause additional code maintenance costs. Do you find this to be
> the case?
Not really. It's not much different from most other languages really.
In C for example consider the function call foo(bar); . In lisp this
would be (foo bar). In both cases "bar" is evaluated to determine it's
value as a variable. If we write (foo 'bar) in lisp then the function
recieves the symbol bar. This has no direct analog in C because C has
no symbol type. The nearest thing would be (foo "bar").
Also consider (foo '(1 2 3)) this means "call foo with a list
containing 1, 2 & 3". You can't really do this in C, you have to make
the list first. If you have a function for doing so then it would be
something like foo (list(1, 2, 3)); which isn't all that different.
BTW
Your post has stimulated some of the best sarcasm I've seen on
comp.lang.lisp for a long time, thank you ;).
Robert wrote:
> That's basically a question that I ask in my most recent blog post (
> Jan 9, www.xanga.com/datahelper ).
> The title is obviously tongue in cheek, so don't start a flame war.
A fine selling point for a tool, when you're aiming at employers, is
that it resembles what people on the job market might have had
experience with. At the same time, job applicants often learn what
companies seem to demand. Such a system has self-reinforcing tendencies
to overcome.
> So LISP programs can produce LISP programs. But in practice, can this
> really improve a coder's productivity?
In addition to the insights from others on this forum, consider the
implications of decreased dependence on a single central committee
(which decides matters like notation, how the OOP system works, etc).
Tayssir
Robert wrote:
> That's basically a question that I ask in my most recent blog post (
> Jan 9, www.xanga.com/datahelper ).
> The title is obviously tongue in cheek, so don't start a flame war.
I started learning Lisp about 4 months ago (coming from the usual
C++/Python/C# treadmill) and I've found that I'm about as productive in
Lisp as I am in Python or C#. Now I find that quite a nice place to be
as those languages (especially Python) are well regarded as productive
programming environments.
I get a few other things with Lisp. Maturity is one that I value - the
language standard is established and seems to be well supported in the
free compilers I've been using.
The development cycle of Python is one step ahead of C# and C++ as it
cuts out compilation. Lisp feels like it goes one further with more of
a one function at a type style which I've got quite used to now and
which has had a nice side effect of making my code more structured and
modular. Despite trying to follow a unit test discipline in other
languages I've found Lisp to be the first language where I've really
not had to force myself to work this way. I can't fully explain why but
it just fell out naturally.
The other interesting thing I've found is that I've not run into many
of the Lisp clich�s yet (either bad or supposedly good). I don't find
the brackets confusing and unlike some who say they barely notice them
anymore, I still do see them but find them quite reassuring! I also
haven't gone macro crazy (your Lisp writing Lisp point). This could be
because it's early days for me and I may suddenly lose the plot and
start meta-programming myself into a stupor but at the moment I've
written two, maybe three and even then it was with a sort of "maybe I
should do it as a macro" naivety.
You've already managed to get responses in this thread from a number of
respected Lispers (IMHO). If you hang around you'll learn to see the
people who really know their stuff and are happy to help (provided you
help yourself).
Phil
Robert wrote:
> I note in the my blog entry that , my very early first impression , is
> that the evaluation/non-evaluation of lists and the need for the quote:
> ' can cause additional code maintenance costs. Do you find this to be
> the case?
Based on your "very early first impression" could you put a dollar
figure on these maintenance costs? Or would you then be bullshitting
outside of your regular comfort zone?
From: Pascal Costanza
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <50jtqkF1fvhn0U1@mid.individual.net>
Robert wrote:
> So LISP programs can produce LISP programs. But in practice, can this
> really improve a coder's productivity?
Yes, it can. From a certain threshold above, the only way to scale
productivity is by not having to write code yourself but being able to
delegate this task. Lisp has a principled approach for doing this at the
code representation level. Functional programming languages provide a
principled approach at the function level. Some object-oriented
programming languages provide principled approaches at the object and/or
class level.
If the programming language of your choice doesn't provide a principled
approach for metaprogramming, you have to implement all code yourself,
employ lots of programmers, or use program generation tools.
> If it can, then why hasn't LISP become more widely spread?
Because meta-level / higher-order programming is harder to understand
than base-level programming.
> I note in the my blog entry that , my very early first impression , is
> that the evaluation/non-evaluation of lists and the need for the quote:
> ' can cause additional code maintenance costs. Do you find this to be
> the case?
No.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <50juc4F1gbomvU1@mid.individual.net>
Pascal Costanza wrote:
> Robert wrote:
>
>> So LISP programs can produce LISP programs. But in practice, can this
>> really improve a coder's productivity?
>
> Yes, it can. From a certain threshold above, the only way to scale
> productivity is by not having to write code yourself but being able to
> delegate this task. Lisp has a principled approach for doing this at the
> code representation level. Functional programming languages provide a
> principled approach at the function level. Some object-oriented
> programming languages provide principled approaches at the object and/or
> class level.
>
> If the programming language of your choice doesn't provide a principled
> approach for metaprogramming, you have to implement all code yourself,
> employ lots of programmers, or use program generation tools.
>
>> If it can, then why hasn't LISP become more widely spread?
>
> Because meta-level / higher-order programming is harder to understand
> than base-level programming.
As an additional note: The benefits of such programming styles are also
not obvious from toy examples, so it's harder to convince people of
their usefulness.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza ha escrito:
> Pascal Costanza wrote:
> > Robert wrote:
> >
> >> So LISP programs can produce LISP programs. But in practice, can this
> >> really improve a coder's productivity?
> >
> > Yes, it can. From a certain threshold above, the only way to scale
> > productivity is by not having to write code yourself but being able to
> > delegate this task. Lisp has a principled approach for doing this at the
> > code representation level. Functional programming languages provide a
> > principled approach at the function level. Some object-oriented
> > programming languages provide principled approaches at the object and/or
> > class level.
> >
> > If the programming language of your choice doesn't provide a principled
> > approach for metaprogramming, you have to implement all code yourself,
> > employ lots of programmers, or use program generation tools.
> >
> >> If it can, then why hasn't LISP become more widely spread?
> >
> > Because meta-level / higher-order programming is harder to understand
> > than base-level programming.
>
> As an additional note: The benefits of such programming styles are also
> not obvious from toy examples, so it's harder to convince people of
> their usefulness.
>
Very interesting thought; to be read like "It is mainly an problem of
education"
Robert wrote:
[...]
> I note in the my blog entry that , my very early first impression , is
> that the evaluation/non-evaluation of lists and the need for the quote:
> ' can cause additional code maintenance costs. Do you find this to be
> the case?
In practice, you'll probably find that the things that screw you up at
the beginning stop screwing you up once you become familiar with the
language. Stuff like (un)quoting becomes second nature pretty fast.
I imagine that the same is true with other languages, but Lisp is the
only one I'm really comfortable enough to say for sure. People may say
that Lisp really only improves the productivity of good programmers,
but I'm a really crappy programmer and Lisp has made me more productive
than C or Fortran ever did. The REPL, garbage collection and built-in
debuggers are godsends if/when you have no idea what the hell you're
doing.
So if you're a good programmer, cool, but if you aren't such a good
one, don't be scared off by the talk about higher-order and
metaprogramming. They're cool and all, but they aren't the only thing
the language has going for it.
Cheers.
Pillsy
From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <eo31ps$jds$1@registered.motzarella.org>
Robert schrieb:
> So LISP programs can produce LISP programs. But in practice, can this
> really improve a coder's productivity? If it can, then why hasn't LISP
> become more widely spread?
http://www.lambdassociates.org/webbook/chap1.htm
Read 1.1, 1.2, 1.3 and 1.4
There you will find some ideas about the unpopularity of not only Lisp
but pretty much all functional languages.
(9 min reading time required).
Andr�
--
Robert wrote:
> I note in the my blog entry that , my very early first impression , is
> that the evaluation/non-evaluation of lists and the need for the quote:
> ' can cause additional code maintenance costs. Do you find this to be
> the case?
Since quote is one way to distinguish data from code, the above is
equivalent to asking whether the "need" for code and data "causes
additional code maintenance costs".
When the application requires both code and data, I don't find
that their existence causes additional code maintenance costs.
-andy
(message (Hello 'Robert)
(you :wrote :on '(9 Jan 2007 12:01:17 -0800))
(
R> If you want to know who I am, I'm a pharma-statistician, mathematician
R> , and specialist in the realm of statistical programming languages.
if you have programming practice, you should note that some places of code
become annoying -- you write same stuff over and over again and get bored.
you start to feel that language is inappropriate to reflect programmers
intentions.
Lisp might be best thing to remove that annoying places with metaprogramming
facilities.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Robert wrote:
> That's basically a question that I ask in my most recent blog post (
> Jan 9, www.xanga.com/datahelper ).
> The title is obviously tongue in cheek, so don't start a flame war.
>
> So LISP programs can produce LISP programs. But in practice, can this
> really improve a coder's productivity?
I won't even try to answer below because it's boring and
overdiscussed to death.
However the greatest strength of lisp i see in REPL. It's very
important when your experimenting or tuning to get results momentarily
In lisp you just write your function and test them at the moment in the
listener while editor is also accessible at least.
In C/C++/C# there's a LOOOOONG process of recompiling and relinking
everything . In the biggest system i ever worked it took sometimes
waiting for 30 minutes because I changed one lousy function or
parameter.
In the meantime you could test dozen of ideas and parameters in lisp.
Lisp is extremely productive when you're doing something new .
>If it can, then why hasn't LISP
> become more widely spread?
On Mon, 15 Jan 2007 07:20:49 -0800, fireblade wrote:
> However the greatest strength of lisp i see in REPL. It's very
> important when your experimenting or tuning to get results momentarily
> In lisp you just write your function and test them at the moment in the
> listener while editor is also accessible at least.
And with Slime, you don't even need a specific REPL: The file buffer works
as a REPL just fine and you end up with all your function definitions in a
convenient package. A lot of modern languages have a REPL, but only Slime
(and, therefore, Common Lisp) allows that kind of development AFAIK.
> In C/C++/C# there's a LOOOOONG process of recompiling and relinking
> everything . In the biggest system i ever worked it took sometimes
> waiting for 30 minutes because I changed one lousy function or
> parameter.
This makes me suspect your build environment was spectacularly stupid. Was
it recompiling every single file? Didn't it keep binaries around and only
replace the binaries derived from the files you'd dirtied? A simple
Makefile-based system would avoid that bogosity.
Maybe I'm wrong, and your compiler was just dog-slow. A C++ compiler
chewing through code that uses a lot of templates (or a few really complex
templates, for that matter) will probably slow down the process.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Chris Barts wrote:
>> In C/C++/C# there's a LOOOOONG process of recompiling and relinking
>> everything . In the biggest system i ever worked it took sometimes
>> waiting for 30 minutes because I changed one lousy function or
>> parameter.
>
> This makes me suspect your build environment was spectacularly stupid. Was
> it recompiling every single file? Didn't it keep binaries around and only
> replace the binaries derived from the files you'd dirtied? A simple
> Makefile-based system would avoid that bogosity.
A Makefile doesn't help. I have worked in a similiar system: There was a
header file with functions like drawLine, drawRect etc. and many files,
which includes this. Now you add drawCircle and nearly all files needs to
be recompiled.
You could solve this, if you use one header file for one function, but if
you use a class, you have the problem again. This is not a problem of the
language itself, but all compilers I know (maybe VisualAge C++ not) does it
like this.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Chris Barts wrote:
> >> In C/C++/C# there's a LOOOOONG process of recompiling and relinking
> >> everything . In the biggest system i ever worked it took sometimes
> >> waiting for 30 minutes because I changed one lousy function or
> >> parameter.
> >
> > This makes me suspect your build environment was spectacularly stupid. Was
> > it recompiling every single file? Didn't it keep binaries around and only
> > replace the binaries derived from the files you'd dirtied? A simple
> > Makefile-based system would avoid that bogosity.
>
> A Makefile doesn't help. I have worked in a similiar system: There was a
> header file with functions like drawLine, drawRect etc. and many files,
> which includes this. Now you add drawCircle and nearly all files needs to
> be recompiled.
>
> You could solve this, if you use one header file for one function, but if
> you use a class, you have the problem again. This is not a problem of the
> language itself, but all compilers I know (maybe VisualAge C++ not) does it
> like this.
Almost any C or C++ system can be made to compile efficient when almost
any file is changed.
In systems that use large include files those files can be split
according to modularity or by how often they are changed. Using
ramdisks can make compiles much faster too (don't believe anyone who
tells you disk caches are as good, mostly they aren't).
The issue is that doing this in C/C++ is difficult, it takes time and
work and knowledge. In Lisp you just get uniform compile speed for
free.
Rob Thorpe wrote:
> Almost any C or C++ system can be made to compile efficient when almost
> any file is changed.
> In systems that use large include files those files can be split
> according to modularity or by how often they are changed.
But how do you do this for my example? Assuming an airplane cockpit
software with a LCD screen: There are many modules for displaying states,
compass etc. And probable every module uses a base Window class. When you
change this, e.g. adding a new drawing method, every displaying module
needs to be recompiled. I don't see an easy solution with most C++
compilers, only some very unusual solutions, like using one header file for
every drawing function and passing the window class to it (but as I wrote,
IIRC VisualAge C++ saves all classes in a repository and has more
information about the structure to improve the speed of such changes).
Another case: You have a trace function. Now you add one optinional
parameter and all files, which uses trace, needs to be recompiled.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Rob Thorpe wrote:
> > Almost any C or C++ system can be made to compile efficient when almost
> > any file is changed.
> > In systems that use large include files those files can be split
> > according to modularity or by how often they are changed.
>
> But how do you do this for my example? Assuming an airplane cockpit
> software with a LCD screen: There are many modules for displaying states,
> compass etc. And probable every module uses a base Window class. When you
> change this, e.g. adding a new drawing method, every displaying module
> needs to be recompiled. I don't see an easy solution with most C++
> compilers,
> only some very unusual solutions, like using one header file for
> every drawing function and passing the window class to it
That's what I would do. Building a tree of header files each including
more.
A header say "alldraw.h" for everything, then within it headers for
drawing
different objects that can be included separately.
But, only if the problem is important. Normally things like this don't
need
to be changed that often.
> (but as I wrote,
> IIRC VisualAge C++ saves all classes in a repository and has more
> information about the structure to improve the speed of such changes).
>
> Another case: You have a trace function. Now you add one optinional
> parameter and all files, which uses trace, needs to be recompiled.
Yes. What I said earlier was "compile can be made efficient when
almost any file is changed". There are limits, changing global trace
functions will often result in a lot of recompilation. But, C++
programs
can be designed so that normal, common changes result in little
recompilation.
Chris Barts <··············@tznvy.pbz> writes:
> On Mon, 15 Jan 2007 07:20:49 -0800, fireblade wrote:
>
>> However the greatest strength of lisp i see in REPL. It's very
>> important when your experimenting or tuning to get results momentarily
>> In lisp you just write your function and test them at the moment in the
>> listener while editor is also accessible at least.
>
> And with Slime, you don't even need a specific REPL: The file buffer works
> as a REPL just fine and you end up with all your function definitions in a
> convenient package. A lot of modern languages have a REPL, but only Slime
> (and, therefore, Common Lisp) allows that kind of development AFAIK.
>
>> In C/C++/C# there's a LOOOOONG process of recompiling and relinking
>> everything . In the biggest system i ever worked it took sometimes
>> waiting for 30 minutes because I changed one lousy function or
>> parameter.
>
> This makes me suspect your build environment was spectacularly stupid. Was
> it recompiling every single file? Didn't it keep binaries around and only
> replace the binaries derived from the files you'd dirtied? A simple
> Makefile-based system would avoid that bogosity.
That happens often when you use recursive makefiles.
http://aegis.sourceforge.net/auug97.pdf
Also, C++ doesn't help, because for most modifications in a superclass
you'll have to recompile all the subclasses anyways.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
From: John Thingstad
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <op.tl87dlebpqzri1@pandora.upc.no>
On Mon, 15 Jan 2007 16:20:49 +0100, fireblade <········@YAHOO.COM> wrote:
> In C/C++/C# there's a LOOOOONG process of recompiling and relinking
> everything . In the biggest system i ever worked it took sometimes
> waiting for 30 minutes because I changed one lousy function or
> parameter.
> In the meantime you could test dozen of ideas and parameters in lisp.
> Lisp is extremely productive when you're doing something new .
To me the long compilation process of C belong in the 'Lisp is slow'
slow category. True once, recited forever more.
A full recompile can indeed be slow. With Opera (500 000 lines+)
it took about 5 minutes (in 2000). However you have incremental
(on the module level) compilation and linking. This takes only
seconds. A much bigger problem is that you need to construct
the entire datastrucure each and every time. Nothing is
remembered between runs. The fact that it is applicative
rather than functional only makes this worse.
Constructing the program to be tested on the modular level
level helps somewhat (CUnit etc).
However this is where I see Lisp's biggest win in terms
of the development cycle.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> To me the long compilation process of C belong in the 'Lisp is slow'
> slow category. True once, recited forever more.
I disagree. Although I think that C/C++ compilations can be made
reasonably fast, many systems in practice have catastrophically bad
build times, today.
> A full recompile can indeed be slow. With Opera (500 000 lines+)
> it took about 5 minutes (in 2000).
That's a *fast* build. I've worked places where the system took many
hours to rebuild, and where minor changes required compilations this
long, well after 2000. That's not to say this was a necessary feature
of these languages, but that it's very easy to create build
environments which have really dreadful performance.
> A much bigger problem is that you need to construct
> the entire datastrucure each and every time. Nothing is
> remembered between runs.
Yes, I think this must be an issue for C/C++ systems. Every
compilation unit requires the compiler to start from a completely blank
slate and reconstruct (by header files etc) everything on which that
unit may depend. I think some C/C++ environments attempt to deal with
this though. Java often has, I suspect, the same problem - you
presumably need to at least peruse all the classes on which a given
class depends to know enough to compile it, and since the Java compiler
is often effectively run from the Unix command line, it can't remember
this between invocations.
--tim
Tim Bradshaw <··········@tfeb.org> wrote:
+---------------
| John Thingstad wrote:
| > A much bigger problem is that you need to construct
| > the entire datastrucure each and every time. Nothing is
| > remembered between runs.
|
| Yes, I think this must be an issue for C/C++ systems. Every
| compilation unit requires the compiler to start from a completely blank
| slate and reconstruct (by header files etc) everything on which that
| unit may depend. I think some C/C++ environments attempt to deal with
| this though.
+---------------
(*sigh*) Yet another lesson from the 70's forgotten...
This also used to be a problem with TOPS-10 Monitor builds.
The TOPS-10 Monitor was written in MACRO-10 assembler, in
many small sources files each with *dozens* of includes of
header files. A build of just the kernel could take *hours*!
Then at some point [with the 5-Series Monitors? 1972?] they
fixed MACRO-10 to save parsed headers in memory [on the '10
you could issue multiple compilation commands to one invocation
of a compiler or assembler], then soon after added saved-on-disk
"compiled" forms of the headers. That brought the kernel build
down to just a couple of *minutes*, and a full system build
down from days to hours.
Of course, right about the same time C was re-inventing the
"start from scratch every time" model... and never got past it. :-(
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On 2007-01-17, Rob Warnock <····@rpw3.org> wrote:
> Tim Bradshaw <··········@tfeb.org> wrote:
> +---------------
>| John Thingstad wrote:
>| > A much bigger problem is that you need to construct
>| > the entire datastrucure each and every time. Nothing is
>| > remembered between runs.
>|
>| Yes, I think this must be an issue for C/C++ systems. Every
>| compilation unit requires the compiler to start from a completely blank
>| slate and reconstruct (by header files etc) everything on which that
>| unit may depend. I think some C/C++ environments attempt to deal with
>| this though.
> +---------------
>
> (*sigh*) Yet another lesson from the 70's forgotten...
>
> This also used to be a problem with TOPS-10 Monitor builds. The
> TOPS-10 Monitor was written in MACRO-10 assembler, in many
> small sources files each with *dozens* of includes of header
> files. A build of just the kernel could take *hours*! Then at
> some point [with the 5-Series Monitors? 1972?] they fixed
> MACRO-10 to save parsed headers in memory [on the '10 you could
> issue multiple compilation commands to one invocation of a
> compiler or assembler], then soon after added saved-on-disk
> "compiled" forms of the headers. That brought the kernel build
> down to just a couple of *minutes*, and a full system build
> down from days to hours.
>
> Of course, right about the same time C was re-inventing the
> "start from scratch every time" model... and never got past it.
> :-(
Today, horrible build times for small changes in large C and C++
projects can happily be attributed to thoughtless designs.
Ubiquitous abstract base classes, pointers to incomplete types,
and envelope (aka Cheshire Cat (aka pImpl)) patterns doesn't
exactly make programming more pleasant, however. And C++
templates require a whole 'nother batch of unjoy. But your build
dependencies can be nearly eradicated.
--
Neil Cerutti
The peace-making meeting scheduled for today has been cancelled due to a
conflict. --Church Bulletin Blooper
From: John Thingstad
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <op.tmbee7hnpqzri1@pandora.upc.no>
On Wed, 17 Jan 2007 15:56:59 +0100, Neil Cerutti <·······@yahoo.com> wrote:
>
> Ubiquitous abstract base classes, pointers to incomplete types,
> and envelope (aka Cheshire Cat (aka pImpl)) patterns doesn't
> exactly make programming more pleasant, however. And C++
> templates require a whole 'nother batch of unjoy. But your build
> dependencies can be nearly eradicated.
>
Agreed. I remember monuments in bad OO C++ design like
Object Windows Library and the Microsoft lookalike Windows
Foundation Classes (MFC).
Intensive used of inlining of functions deep inheritance
tight coupling and a weird event model based on functional
inheritance. Unfortunately some people still use things like this
to model OO design I think. This is not primarily (though partially)
C++'s fault. Rather the effect of people inexperienced in OO
designing systems well over their level of competence.
I remember well back in 1994 when everyone was doing OO
and few understood what it was. Much of the material from this time
is better left forgotten. SWING (for all it's weaknesses) was
the first taste of what a good OO design could look like for
many people. Qt which had the advantage of being created with
this experience is a much better library.
(.NET is Microsoft's valid attempt to get rid of MFC.. Good riddance.)
The pre compiled header hack is a dirty trick necessitated by
the 2000 line + nested includes generated by windows libraries.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Tim Bradshaw" <··········@tfeb.org> writes:
> Yes, I think this must be an issue for C/C++ systems. Every
> compilation unit requires the compiler to start from a completely blank
> slate and reconstruct (by header files etc) everything on which that
> unit may depend. I think some C/C++ environments attempt to deal with
> this though.
Yes, for example, MacOSX has prebuilt headers.
You only need to recompile them (or use source headers) when you
change the #defines before including the headers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.
On Wed, 17 Jan 2007 02:37:16 -0800, Tim Bradshaw wrote:
> John Thingstad wrote:
>
>> To me the long compilation process of C belong in the 'Lisp is slow'
>> slow category. True once, recited forever more.
>
> I disagree. Although I think that C/C++ compilations can be made
> reasonably fast, many systems in practice have catastrophically bad
> build times, today.
And others are really fast. Fabrice Bellard (?), the guy who built the
qemu virtual machine system, built a C compiler so fast that it could
reputedly boot a linux kernel *from source* in about the same amount of
time that regular systems boot. (I.e., boot-loader was C compiler.)
There are other reasons why today's more popular C and C++ compilers can
be slow-ish.
>> A full recompile can indeed be slow. With Opera (500 000 lines+) it
>> took about 5 minutes (in 2000).
>
> That's a *fast* build. I've worked places where the system took many
> hours to rebuild, and where minor changes required compilations this
> long, well after 2000. That's not to say this was a necessary feature
> of these languages, but that it's very easy to create build environments
> which have really dreadful performance.
Exactly. It's also, generally, not hard to set things up to compile
acceptably quickly, for arbitrary values of acceptable.
>> A much bigger problem is that you need to construct the entire
>> datastrucure each and every time. Nothing is remembered between runs.
>
> Yes, I think this must be an issue for C/C++ systems. Every compilation
> unit requires the compiler to start from a completely blank slate and
> reconstruct (by header files etc) everything on which that unit may
> depend. I think some C/C++ environments attempt to deal with this
> though. Java often has, I suspect, the same problem - you presumably
> need to at least peruse all the classes on which a given class depends
> to know enough to compile it, and since the Java compiler is often
> effectively run from the Unix command line, it can't remember this
> between invocations.
Of course it does. It doesn't have to parse all of the source code,
though: that information exists as meta-info in the .class files, which
are all that the compiler needs to look at.
The only alternative is punt on everything (or at least, more) until "run
time". Not everyone wants to make that trade-off. That's OK. There's a
spectrum here. Stalin isn't famous for being a quick compile, either.
--
Andrew
Andrew Reilly wrote:
>
> The only alternative is punt on everything (or at least, more) until "run
> time". Not everyone wants to make that trade-off. That's OK. There's a
> spectrum here. Stalin isn't famous for being a quick compile, either.
The point is that that's not the only alternative. A very good
alternative is to have a system which does a repeated compile/load
cycle, thus ensuring that it always already knows everything that is
needed to compile the next bit of code. That might be painful for
C/C++ systems, but should be fairly easy for Java, and is, of course,
the default approach to building Lisp systems.
(There are issues with this alternative. You can't easily compile
multiple variant versions of a system in the same image, unless there
is support for that in the language/implementation. Typical Lisp
systems don't have this, so you need to run through the compile from
the start for each variant (I am fairly sure that Java systems could
do this though, since I think there is standard support for allowing
variant versions of classes to coexist in a single JVM). In a more
typical Lisp-style development environment where you use the running
image to compile bits of code repeatedly you can get the `can't ever
rebuild from scratch' problem because of stuff that made it into the
image but never into anything nonvolatile.)
--tim
On Wed, 17 Jan 2007 06:00:15 -0800, Tim Bradshaw wrote:
> Andrew Reilly wrote:
>>
>> The only alternative is punt on everything (or at least, more) until "run
>> time". Not everyone wants to make that trade-off. That's OK. There's a
>> spectrum here. Stalin isn't famous for being a quick compile, either.
>
> The point is that that's not the only alternative. A very good
> alternative is to have a system which does a repeated compile/load
> cycle, thus ensuring that it always already knows everything that is
> needed to compile the next bit of code. That might be painful for
> C/C++ systems, but should be fairly easy for Java, and is, of course,
> the default approach to building Lisp systems.
True. That's why I said that it was a spectrum, but I probably wasn't
clear enough. There are certainly Java environments that do incremental
compilation. I imagine that you could do that with C, too, but I don't
know of any. Eiffel is at almost the same end of the language spectrum as
C++, and it's main compiler/IDE was historically an incremental thing.
The point that I was making (badly), was that the goals of these
compilation strategies are different. The C/C++ model, in its
contemporary form, allows for a lot of explicit and implicit inlining of
both code and data/values (eg structure offsets and sizes). Originally
this was just macros and typedefs in headers, but now it is also function
inlining and whole-program analysis. All in the name of absolute speed at
run-time, irrespective of the compile-time expense. There's nothing in
Lisp to prevent this sort of thing, either, but at least the model doesn't
*require* it. If you code your C exclusively with opaque types handed
around with void pointers, you get the same level of compile-time
modularisation as the languages that effectively work that way by default.
It's just that that's not the way most C code is written.
Now, once you have an inlining-based optimization model, then of course
small changes in widely used modules will require all of the dependent
modules to be recompiled. This *must* also be the case for any lisp-like
system that attempts to perform the same classes of optimizations.
> In a more
> typical Lisp-style development environment where you use the running
> image to compile bits of code repeatedly you can get the `can't ever
> rebuild from scratch' problem because of stuff that made it into the
> image but never into anything nonvolatile.
That's the bit about Lisp that still does my head in. I believe that
smalltalk and forth have (or can have) the same issue, for the same
reason. I like being able to start from scratch: it helps me to figure
out what's going on. Probably just a learned prejudice, though.
Cheers,
--
Andrew
Andrew Reilly wrote:
>
> Now, once you have an inlining-based optimization model, then of course
> small changes in widely used modules will require all of the dependent
> modules to be recompiled. This *must* also be the case for any lisp-like
> system that attempts to perform the same classes of optimizations.
This is typically already the case for Lisp systems. If I modify a
structure definition, say, then I probably need to recompile everything
that uses it directly. Indeed, it's even the case for Lisp systems
which don't do this sort of efficiency optimization: if I redefine a
macro then I need to rebuild everything that might expand it (for
instance a system I worked on used a variant DEFPACKAGE macro, and when
that changed *everything* had to be rebuilt.
But I don't think the build performance issue I was talking about is
really changed by how aggressively the system optimises. It's to do
with how the build process remembers what it knows about what has
already been built. The `reload everything from scratch, every time
you compile anything' model is just a disaster for large systems: quite
apart from anything else it means you need expensive disk systems or
vast amounts of real memory to cache cheap disk systems to compile. As
you said I think, that's why serious systems which naively look like
they are of this ilk[*] often aren't. Unfortunately lots of people
think that using gcc & naive recursive-make based build systems will
save them money, because they aren't very good at the whole
time-is-money thing. I once worked on a Lisp-based system that managed
configuration & build of CORBA/C++ systems. It took less time to do a
cold build of the whole system (LispWorks on a 600MHz laptop with usual
crap disk) than it took to build the few-tens-of-lines sample
application we used for test. And the slowness was all gcc / corba IDL
compiler time (our system didn't even actually do the build, it wrote
an (efficient) makefile that did it). And we had to buy faster
machines to make building the CORBA environment itself viable.
> That's the bit about Lisp that still does my head in. I believe that
> smalltalk and forth have (or can have) the same issue, for the same
> reason. I like being able to start from scratch: it helps me to figure
> out what's going on. Probably just a learned prejudice, though.
I didn't mean to imply that not-being-able-to-build-from-scratch was
ever a good thing: in my opinion it's a disaster. I was always very
careful to do cold builds of anything I worked on frequently. It's
just something which is more likely to leak in to resident environments
like Lisp systems.
--tim
I wrote:
> of this ilk[*]
[*] This is actually not the right way to use this word, and since I
live in Scotland I should care (even though I'm not scottish, I am
married to a scot, so I have no excuse). But I'll leave it to annoy
the prescriptive grammar weeds.
From: David Steuber
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <871wlrrzj0.fsf@david-steuber.com>
I'm working on a program in Lisp where a from scratch rebuild would
require reloading a rather large data set. Mind you, this is because
I'm not storing the data in the most efficient to load form (yet).
But still, the incremental nature of development works with an image
based system.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
From: John Thingstad
Subject: Re: What is LISP good for, that is harder in other languages?
Date:
Message-ID: <op.tmef4sgvpqzri1@pandora.upc.no>
On Wed, 17 Jan 2007 10:37:16 +0100, Tim Bradshaw <··········@tfeb.org>
wrote:
>
>> A much bigger problem is that you need to construct
>> the entire datastrucure each and every time. Nothing is
>> remembered between runs.
>
> Yes, I think this must be an issue for C/C++ systems. Every
> compilation unit requires the compiler to start from a completely blank
> slate and reconstruct (by header files etc) everything on which that
> unit may depend. I think some C/C++ environments attempt to deal with
> this though. Java often has, I suspect, the same problem - you
> presumably need to at least peruse all the classes on which a given
> class depends to know enough to compile it, and since the Java compiler
> is often effectively run from the Unix command line, it can't remember
> this between invocations.
You misunderstand me.
I am talking about the data generated by the application not the compiler.
To some extent the problem of compiler remembering is accomplished by say
pre-compiled headers. Anyhow that is a fixable problem.
Application data recovery is far more tricky.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Wed, 17 Jan 2007 10:37:16 +0100, Tim Bradshaw <··········@tfeb.org>
>
> You misunderstand me.
Yes, clearly I did, sorry.
> I am talking about the data generated by the application not the compiler.
> To some extent the problem of compiler remembering is accomplished by say
> pre-compiled headers. Anyhow that is a fixable problem.
Yes, of course it is fixable, but empirically large C/C++ systems often
do take forever to build, so it's a problem which is costing a lot of
money, at least. This, of course, doesn't mean it isn't quite easy to
fix: programmers are no more economically rational than anyone else
(perhaps less so).
> Application data recovery is far more tricky.
Agreed. (You can do interesting things with even very large data sets
if you spend a lot of time on representation so that you can read stuff
linearly, which I/O and memory systems really like, but that's hard
work and not always viable.)