highCs

The lemma says: take two programs that does the same thing, one of the sources is shorter means you can attribute a produced-value (call that how you want) per line of code.

Then the theorem says: take any two programs (linux and gcc for example), the code that has, in average, the more value per line, is greater. (You have to trust that one of the two programs has, in average, more value per line of code because they have an average value says the lemma.)

Now you can say that a practice that tend to decrease the number of line of code is a good practice while the other that tends to increase the number of line of code is a bad practice assuming the resulting programs would do the same thing.

The thing is that in most situations the resulting programs are assumed to be doing the same thing. For example, when you choose between object-oriented versus functional programming, you are likely to be making a choice having a common resulting program in mind. If it's not the case, like for example, you worry that performances are not going to be good enough using this or that method, then it's indeed perfectly fine to choose the method that allows you to write the right program.

> Sometimes, spelling things out in a slightly more verbose way is better than using some slick one-liner.

I think you may have missed some details here. First, the code must be non-obfuscated. Here is the trick: you decide actually when the code is obfuscated. When it is, you probably want a more verbose code indeed.

You understand that, at some point in time, it may be hard for a programmer, you, to judge if your code is obfuscated or if it is actually weak code. If other programmers feel fine with the slick one-liner, the theorem would suggest that it might be useful for you to learn to read easily that kind of code because you may be actually writing weak code.

Finally on this: local exceptions are ok. It's all about averages.

> "all else being equal, fewer lines of code is better than more lines of code," but I'd argue that all else is rarely equal

I believe you make a little mistake here. It not all else being equal. It's for a program that does x. For a program that does x, fewer lines of code is better. Please note that, "does x" includes the complete behaviour of the program, performances, for example, included. A program that answer a request in 3 second does not do the same thing as a program that answer the exact same request in 3 minutes.

We ultimately don't have to prove it. We only have to agree together. (Another way of saying this is that it's unprovable, but every programming master will tell you it's true)

I suggest you re-read the lemma. The point is about having fewer lines of code for what the program is supposed to do. For example, one could probably not write a kernel that does exactly what the linux kernel does (that has the exact same behavior [1]) but with dramatically less lines of code.

[1] the performances of the linux kernel are part of what that program does

It's missing construction (educators I've a doubt... do they try new things? Are they viral? Do they spend money? etc.). There is a lot of money in construction plus they still may have few good softwares. I don't know, just finger in the wind.

Bottom-up is the art of coding a project from scratch. If you got the mastery of it, it means you can start and finish a project very efficiently. The idea is that you make the codebase evolve, you scult it. You code like the painter paint. By doing so, you can get a prototype very quickly and then refine it into a final product. Whatever is the time you're given, you always have a working code with every features - like a painting has everything in it even when it's not finished (and it never is). The only thing that can be missing are relative details.

I know it might sound like every other software development methods. The thing is that most developers are actually bad at it - that's point 1.

1. You can develop 10x faster than what you think. Learn functional programming and more importantly, learn to code bottom-up. Even if you do object-oriented code, that will do.

2. As a developer, you must take the initiative and drive aggressively the projects. They must listen to you, not you listen to them. Literally put your job at stake, often. If you do so and if you got results (see point 1), you gonna gain respect very quickly, then take the initiative and become unstoppable. But, before thinking about that, you need point 1.

You are the code pro, if things goes wrong about code, you are the one to blame. The spiral is you thinking you are the victim. You must understand than software must serve the business, not the opposite. Finally, nobody told software development was easy.

EDIT: I should say something here: I'm talking from experience. This is what I do, and I can testify it works. Also, it's not supposed to solve the problem, it's supposed to prevent the problem to happen.

That's exactly how Half-Life has been made: http://gamasutra.com/view/feature/131815/the_cabal_valves_de...

This has been added to java to catchup with functional programming languages.

I've read about qualities of good startup founders. Wondering now, what are the qualities of good people? (real question) What have you found? What should I read?

It's obvious actually. The drug dealer is a store. It gonna find its customers anyway.

Just for the fun, so now if I want to sell drug X, I just got to find people who got a lot of friends - who have potentially the profile to consume that drug. I bet it works really fine. You probably don't have to go in the street at all :P

EDIT: oh but how many people are saved by this: the risk/reward ratio is too high? The risk of the drug dealer is in the equation then. But you're right on something, the strong profile for drug X can do nothing and it's kinda unfair.