Jon pls, do you even Lisp Machine? Seriously, you can't base your opinion on kernels/OS:s written in Lisp on this guy's hobby project. I know what you think of GC, but history shows what an industrial Lisp OS is like and it's awesome.
>Say you can either spend X amount of effort on a 50% improvement, or you can spend X/10 on each of 10 5% improvements. Sounds the same, right?
This is the same thing. The point is that you say "10 5% improvements of state S0" in that sentence and then later on you use 10 5% improvements of state S0, S1... S9. This doesn't make any sense, could you explain to me how this would work?
> you say "10 5% improvements of state S0" in that sentence and then later on you use 10 5% improvements of state S0, S1... S9.
No, I don't.
Here's a very simplistic example. Say I've got a complicated computation with 10 nested loops, and there's a potential for a 5% speedup tweak at every nesting level, each of which takes about the same amount of effort to find; or, for the same overall effort I can speed up the whole thing by 50% by replacing the whole algorithm with a faster one.
The former case gives you a better outcome than the latter, and it doesn't matter what order you do the tweaks in, or whether you do them all at once. The point is that they can compound without caring about the previous or latter state of anything other than their own level.
Yes but the point is that the (at least I assumed so) 5% increase in speed was based on the initial performance of the system and that it didn't scale. Isn't that basically what you're talking about?
If you take two speed-ups which individually would be 5% over the initial performance and apply them both, you get 10.25%, not 10%. The point is that it can scale.
A number of discrete improvements is also more resilient. If a single perf improvement needs to be removed, only a 5% gain is removed. If the big 50% gain is monolithic it is much more susceptible to disruption.
you're statement needs a lot of qualifications. It is in only very specialized cases where this is true.
Let's say my program takes time 1.0 and is made up of part A taking 0.5 and part B taking 0.5
Defining 5% speedup is weird in the first place, but let's say 5% speedup is taking 0.95 for the program and 10% speedup is taking 0.9 for the program.
5% speedup by improving part A => 0.45 + 0.5 => 0.95 runtime
5% speedup by improving part B => 0.5 + 0.45 => 0.95 runtime
making both improvements:
0.45 + 0.45 => 0.9
So, two speed-ups which individually would be 5% over the initial performance gives us a 10% speed up.
percentage speed ups do not necessarily compound. And in practice, usually they do not.
Sure, check out pgloader (this guy re-wrote a Python program into Common Lisp and wrote about the experience), the European Lisp Symposium ( http://www.european-lisp-symposium.org/content-programme-ful... ), it's used by Google (ITA, air fairing system), it was used by Naughty Dog for their PS1 and PS2 games (they still use Lisp for scripting), it's been used by NASA, DART ( https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replannin... ), Cyc, there's a European company I can't remember the name of that uses Common Lisp for its train scheduling system. There's this new Swedish music company that uses Common Lisp for their software.
If you want to see much used applications in the Common Lisp community then check out all of Edi Weitz' software http://weitz.de/
Most Common Lisp that you use is in stuff you don't see, there're no Ruby hipsters here.
EDIT: Oh, or why not something like StumpWm? Really, thre's a lot of cool Common Lisp software out there.
I recently re-installed my OS and setting up my Lisp environment (SBCL, Quicklisp, SLIME+Emacs) took about 30 minutes.