Can anyone write this recursion for simple regexp more beautifullyand clearly than the braggarts

[Richard Bos]

Hmmm. Maybe we could morph this into a Beer vs. Ale discussion?

We can't. Ale is a kind of beer. You're thinking of ale vs. lager, or
even more correctly, of top-fermented vs. bottom-fermented beers. But
since I've just finished a Belgian trappist and am halfway through a
Dutch white beer, I'd much prefer to opine that I really, really like
both (*hic*).

Richard

 

[Richard Bos]

The reason that part of the runtime of many language implementations,
including CL, is written in C is because the environment (OS, system
libraries, etc.) is written in C, and at some point we need to
interface with them. The simplest way to interface with C is using C,
wouldn't you think?

No. Only people who understand computing theory, but not computing
practice, would think so. I would add a nasty remark about Lispers here,
but really, I can't be arsed. (And it would probably only be true about
Lisp _advocates_, anyway - as opposed to normal Lisp users.)

Richard

 

[Slobodan Blazeski]

Yes, that's pretty good. I'm working on a dynamic language now which
at present is some 3 to 10 times as slow as optimised C (although
there's some way to go yet...).

But that's measured for tight integer code. When you throw in some
string processing, higher level datatypes, and calls into the runtime,
then they can be comparable, say between 1 and 2 times as slow, for a
language considerably more expressive (ie. increase in apparent
runtime of 0 to 100%). In theory...

So perhaps some of that may be true for Lisp, although it did sound as
though you were already pulling out all the stops to get it down to
only 2x as slow as C.

It depends what are you doing with it. Beside the extremely naive
coding practices, in normal use its something like a third slower than
c++ without optimizations. That was a drop in frame rate I was
experiencing when coding graphic demos with c++ vs cl. The convenience
for that price in speed is enormous. Instead of using scripts to
modify its behavior while the demo is running I could just stop it and
use the Lisp REPL, full language is available all the time, you could
just recompile some function and restart the game loop, the new
version is immediately there, no need for rebuilding the project or do
anything like that. You could practically change the whole system at
runtime. Unless the problem is very well known the price in efficiency
is worth it.

Bobi

 

[Keith Thompson]

+---------------
| > ... Real men program in assembler.
| > But maybe if you program in binary you would save all the time it takes
| > to run through an assembler. So maybe real men program in binary.
|
| Nope, real programmers use butterflies http://xkcd.com/378/
+---------------

Naaahh... Read the tooltip text on that one:

Real programmers set the universal constants at the start such that
the universe evolves to contain the disk with the data they want.

Anthropic programming!! Simply select a universe from the Many Worlds such
that your coding problems all solve themselves. Yeah, that's the ticket...

p.s. But Emacs's "good ol' C-x M-c M-butterfly" was cute, too. ;-}

<WAY_OT>
GNU emacs 23.1 actually has a M-x butterfly command.
</WAY_OT>

 

[Pascal J. Bourguignon]

<cough, splutter> Er, okay, I think I'll put Lisp back on the shelf.
Look, it isn't dirty or anything. Thanks for your time, but I was
looking for something a little sportier. I mean, I knew it would be
slower, but a factor of TWO?

Have a look at http://cliki.net/Performance.

Now, assume you need 10 days to write your program in C, that will run
in 5 minutes. Total: 10 days, 5 minutes to get the answers.

In Lisp, indeed the program will run in 10 or perhaps 15 minutes. But
you will need only 3 days to write it in Lisp. Total: 3 days 15
minutes. That's actually 3 times faster!

 

[Seebs]

Now, assume you need 10 days to write your program in C, that will run
in 5 minutes. Total: 10 days, 5 minutes to get the answers.

In Lisp, indeed the program will run in 10 or perhaps 15 minutes. But
you will need only 3 days to write it in Lisp. Total: 3 days 15
minutes. That's actually 3 times faster!

Assuming only one person ever runs the program, and it only runs once,
yes.

Imagine that you're targeting something that will run in a period of
months on a supercomputer. At that point, a 20% decrease in runtime
could save you several times the cost of having your whole development
team work for the entire lifespan of the product.

In short, special case examples can make just about anything seem like
a good idea. In the bulk of cases, the right thing to do is to figure out
what your requirements are, and decide what tools to use based on that.
There's stuff I write in Ruby, stuff I write in shell, stuff I write in C,
and even stuff I write in English instructions to someone with 15 years'
less experience. It's all a question of costs and benefits...

-s

 

[Seebs]

To be honest, I was mildly annoyed at the randomly selected key bindings
like `M-c' and `M-butterfly'. They should have been more realistic,
eg. `M-x butterfly-mode C-u C-c C-c'. The `M-butterfly' one was the one
that almost spoiled the joke for me. But it was a very funny xkcd joke
indeed ;-)

Not random. Literary reference.

http://en.wikipedia.org/wiki/M._Butterfly

-s

 

[Giorgos Keramidas]

Anthropic programming!! Simply select a universe from the Many Worlds such
that your coding problems all solve themselves. Yeah, that's the ticket...

p.s. But Emacs's "good ol' C-x M-c M-butterfly" was cute, too. ;-}

To be honest, I was mildly annoyed at the randomly selected key bindings
like `M-c' and `M-butterfly'. They should have been more realistic,
eg. `M-x butterfly-mode C-u C-c C-c'. The `M-butterfly' one was the one
that almost spoiled the joke for me. But it was a very funny xkcd joke
indeed ;-)

 

[Flash Gordon]

Have a look at http://cliki.net/Performance.

Now, assume you need 10 days to write your program in C, that will run
in 5 minutes. Total: 10 days, 5 minutes to get the answers.

In Lisp, indeed the program will run in 10 or perhaps 15 minutes. But
you will need only 3 days to write it in Lisp. Total: 3 days 15
minutes. That's actually 3 times faster!

That assumes the software is only being run once. I've just been doing
server sizing for one customer, and they are talking about over 600
users, so if each user only uses the software once that is 600 uses, so...

lisp 10 minutes * 600 = 6000 minutes = 100 hours = approx 4 days
So list would be total of 7 days assuming one use only.

C gives 12 days.

Now, how many pieces of software are only run once? This customer will
be buying an annual license. So assume only half the users use it on any
given day and they only use it once, and a working year of 200 days.
Suddenly a much smaller performance improvement becomes well worth
while! Oh, and that is one customer among many.

Sometimes performance is important, and spending a few days to save a
few seconds can be worth while.

 

[Zach Beane]

Now, assume I need two days to write it in C, and it will run in 5
minutes. Total: 2 days 5 minutes to get the answers.

In Lisp, the program may indeed run in 10 or perhaps 15 minutes. But,
speaking personally, I will need several months to write the program.
Total time: several months and 15 minutes.

A farmer from Maine was visiting his cousin in Texas. "I can get in my
truck at dawn, drive all day, and still not be at the other end of my
ranch by sundown," his cousin bragged. The Mainer nodded. "I used to
have a truck like that, too."

Zach

 

[James Kuyper]

Pascal J. Bourguignon wrote:
....

Now, assume you need 10 days to write your program in C, that will run
in 5 minutes. Total: 10 days, 5 minutes to get the answers.

In Lisp, indeed the program will run in 10 or perhaps 15 minutes. But
you will need only 3 days to write it in Lisp. Total: 3 days 15
minutes. That's actually 3 times faster!

You're assuming that the program will only be run once. Most of my
programs get run several thousand times per day, each copy using up
about 5 minutes of CPU time per run. I spend about a month per year
rewriting each program to keep pace with changing requirements. The
trade-offs are a little bit different when that is the case.

 

[Ben Bacarisse]

Pascal J. Bourguignon wrote:
...

You're assuming that the program will only be run once. Most of my
programs get run several thousand times per day, each copy using up
about 5 minutes of CPU time per run. I spend about a month per year
rewriting each program to keep pace with changing requirements. The
trade-offs are a little bit different when that is the case.

It's interesting that you don't say what the new trade-offs are --
probably because they are hard to characterise.

I've never liked these discussions where programmer time and run time
are equated (or traded off). They may be measured using the same
units but they are very different things. Even when you try to
monetise them (so that they have some sort of "equality of value") the
results are usually contrived.

For example, I've re-written software (at the expense of the
organisation employing me) just to try out something new. The program
did not run much faster but I became a slightly better programmer for
having done it. The costs and benefits can be very complex.

On the run-time side, the software on my phone runs for hours every
day (and in thousands of copies round the world), but even doubling
it's speed won't help me (or anyone else) because it is fast enough.
I once wrote some logging software that was absolutely fast enough
right up until the database insert started to take longer than the
required logging period at which point it became hopelessly slow. All
seconds are of equal length but some are more equal than others.

I suspect this another dodgy analogy, borrowed from the world of
continuous systems, that does not translate well into the discrete and
discontinuous world of software.

 

[Ben Bacarisse]

<g> I heard it as an American tourist in Israel, but yes. It's a
question of how you look at the problem. An experienced lisper who
has perhaps not very much (or no) background in C is obviously going
to knock out a Lisp solution more quickly than he could write a C
solution. But someone with little or no Lisp experience but lots of C
experience (me, for example) is going to write the C solution more
quickly.

Programming doesn't just allow us to express what we think (in a way
that a computer can understand); it also affects *how* we think. I'm
reminded of Obi-Wan's explanation of the Force - it obeys your
commands, but also it partially controls your actions. I think
programming is similar. Our thoughts shape our language, but our
language also shapes our thoughts - one of Hofstadter's "strange
loop" mutual recursions.

Thus, this whole language advocacy thing is a bit daft. Those who
(knowledgably) advocate Lisp have presumably used it for a long time
and liked it. Those who (knowledgably) advocate C have presumably
used C for a long time and liked it. These two different languages
have very different characteristics, and we tend to be drawn to
lanugages that have the characteristics we want. How futile, then, to
try to argue a programmer into changing his favourite language,
whatever that language may be.

That is true for the individual, but are you really saying that the
debate about languages is also "a bit daft" for whole groups? When
intelligent people debate the pros and cons of languages they do so
from the perspective of "all other things being equal". I don't want
to underplay the difficulty of doing this -- there are very few good
quality studies of programmer productivity and error rates but --
unless you tell me otherwise, I'd rather assume that agree that this
is a question that /could/ be studied and useful answers arrived at.

Schools, colleges, and universities have to decide what languages to
teach and though they have to keep an eye on what employers current
say they want, they have the freedoms to influence future generations
of programmers. Employers, too, sometimes get to decide what skills
to recruit without being tied to what they have always used, so it
makes sense to ask what language might help productivity and reduce
errors. There will be a lot of other technical considerations
(availability of implementations, speed, interfacing to specialised
hardware, and so on) but these don't always dictate the language.

 

[D Herring]

I'm of the opinion that both LISP and C are pretty rockin', and we all
should just go out for pints. Amen.

Reasons to buy Beej a beer: http://beej.us/guide/

Thanks Beej,
Daniel

P.S. What were we flaming about? The color blue is superior to red?

 

[James Kuyper]

It's interesting that you don't say what the new trade-offs are --
probably because they are hard to characterise.

Precisely. Extremely hard!

 

[Seebs]

On the run-time side, the software on my phone runs for hours every
day (and in thousands of copies round the world), but even doubling
it's speed won't help me (or anyone else) because it is fast enough.

I do not believe this analysis is correct.

Most mobile phone CPUs are extremely efficient at shutting down (and
conserving power) when not in use. Doubling its speed might well
dramatically reduce battery usage.

-s

 

[Nick Keighley]

Programming doesn't just allow us to express what we think (in a way
that a computer can understand); it also affects *how* we think. I'm
reminded of Obi-Wan's explanation of the Force - it obeys your
commands, but also it partially controls your actions. I think
programming is similar. Our thoughts shape our language, but our
language also shapes our thoughts - one of Hofstadter's "strange
loop" mutual recursions.

sounds like a good argument for learning multiple langauges
with different paradigms! If we have multiple ways of thinking
then we can tackle a bigger spectrum of problems. And have a
larger collection of tools of tools for addressing them.

Thus, this whole language advocacy thing is a bit daft. Those who
(knowledgably) advocate Lisp have presumably used it for a long time
and liked it. Those who (knowledgably) advocate C have presumably
used C for a long time and liked it. These two different languages
have very different characteristics, and we tend to be drawn to
lanugages that have the characteristics we want. How futile, then, to
try to argue a programmer into changing his favourite language,
whatever that language may be.

unless it's Basic or Cobol or course...

 

[Nick Keighley]

On the run-time side, the software on my phone runs for hours every
day (and in thousands of copies round the world), but even doubling
it's speed won't help me (or anyone else) because it is fast enough.

well most of the time. Most of the time it's doing two-thirds of
bugger all
(and has probably dropped into a lower power mode). But when it has
to
work for its living it really has to work. Codec-ing voice is probably
not too expensive these days but if there was more processing
available
(for the same milli-watts) it might be able to use cleverer
modulation
schemes hence saving bandwidth and bandwidth on the air is something
that
really matters. Phone companies pay *billions* for radio spectrum.

But as you say trying to stick all these things on the same dollar
scal is tricky is down-right misleading.

Since we're quoting SF. I'll go with Dune- any ecology is limited by
the most limited resource. The resource a phone has to horde is
mostly power.

 

[Pascal J. Bourguignon]

Ah, a nice neutral, impartial, unbiased... Lisp advocacy site. Furrfu.

Don't be silly.

But notice that some of the referenced papers are not written by Lisp
advocate, but just watching the raw data presented in the tables,
you'll see that Lisp comes out the best (even if the paper was written
to advocate a different language). So, do not count on Lispers'
impartiality, count on that of others'.

Now, assume I need two days to write it in C, and it will run in 5
minutes. Total: 2 days 5 minutes to get the answers.

That is not what we observe in controled experiments.

In Lisp, the program may indeed run in 10 or perhaps 15 minutes. But,
speaking personally, I will need several months to write the program.
Total time: several months and 15 minutes.

This only indicates your own limitations. A company shouldn't be too
concerned by your personnal limintations. They can hire as easily
lisp programmers (after all, most students are taught some kind of
lisp).

 

[Ben Bacarisse]

I do not believe this analysis is correct.

Most mobile phone CPUs are extremely efficient at shutting down (and
conserving power) when not in use. Doubling its speed might well
dramatically reduce battery usage.

If you tell me you know about this stuff I'll just take your word for
it (because I don't) but I would otherwise have thought that a fair
proportion of the power use during talk goes on the radios and the
screen. During standby, everything is in a low-power nearly-off mode
for more than 95% of a 24hr day. Could the CPU being able to shut
down in half the time really have a dramatic effect?