toadpipe

What a crock. The things we know amount to nothing compared to the things we don't, and education doesn't even move the needle on that dial. So what? What matters is what you need to know to accomplish some goal vs. what you know right now, and that's much more tractable. Focusing on the (incorrect) idea that no one else knows anything either so you're just fine the way you are is pabulum designed to boost self-esteem at the expense of actually learning something.

Niceness is not the same thing as determination. Also, trying to flatter someone described as a good judge of character doesn't seem like a good idea to me. /serious

People who give up too early, for any reason.

Pretty much the entire industry, as well as the academic system, is based on the premise that the vast majority of code can and should be written by programmers who will be borrowing heavily against great (in the sense of being large even more than in the sense of being high quality or thoughtfully designed) black box systems in the form of languages, compilers, libraries, operating systems, databases, and other applications that are written by a small fraction and are mostly built to make sure that the rest can't screw things up too badly. Leveraging Ruby on Rails to throw together a barely functional website/app is just one of the more blatant examples of the pattern that pervades the pipeline that now produces most of the software in the world.

There seems to be a large demand for software, and the system is good at producing a lot of software.

If you are not interested in learning how to do it properly, then hire someone who is. Failing that, do not attempt to do it in C.

It can increase people's commitment to compassion too. Like Lisp or Forth, it is an amplifier. Actually placebos are a better analogy. Both are imaginary social support that allows a body to commit resources that would otherwise be held in reserve.

Expressiveness in a single line of code is such a stupid metric.

magic()

What's that? It's a function call. What does it do? Anything. Everything. Why does it need a complex grammar? It doesn't. Spend your time thinking about the problem, not the language. What a concept!

Do simple things take many lines of code in C? Yes. If you only have a few data structures and algorithms in your mental toolbox, simple things will take many lines of code in C, or C++, or in any language. Why do people advocate baroque languages by claiming that you cannot do simple things simply except with baroque languages, and then blame people for complicating their programs by using that baroqueness?

Yeah, C++ programmers are feature junkies; the language is designed by a feature junkie and promotes language features as the solution to every problem. If you go against that, you are going against the whole culture.

If PL/I was the fatal disease, C++ is the shambling corpse.

If someone could come along and invest the millions of man hours required in making a performance-critical high-level language without the C-baggage

As long as it also had C syntax, and something close to the C memory model, and was recognizably object oriented and/or functional. And came with a lot of libraries. And 3D graphics engines. And physics engines.

Unless some independent game developer does something in a new language that other developers can't easily duplicate with their current ecosystem (not that it couldn't be done in C++), and it catches on, there's no incentive to do anything other than continue to evolve things in the most backwards compatible way. There are always more C++ programmers coming off the assembly lines who want nothing more than to work on games.

This is really tempting, but my guess is that the answer is going to be no. Users want something that just works, and they would probably rather dig through a pile of stuff to find that one thing that just works rather than script it themselves. Elegant solution > pile of features > elegant scripting > source. Or you can do it all, like Excel. Even Word has scripting.

I think ahoyhere has alluded to the reason why the pile of features tends to win, and that is because it is better at leveraging the economies of scale in the shrinkwrap software business. It is so cheap to distribute software that you are much better off building for the mass audience. Now the hot thing is webapps which do not scale nearly as well (but avoid most of the junk that comes with shrinkwrap scaling, like having to deal with a strange machine and a crappy OS that deluges the end user in spyware, or pushing updates to users you don't know much about), so there is more incentive to meet the needs of a niche audience. And Apple is having some success sort of splitting the difference (vertical integration from the hardware up, and attempting to exert more discipline on developers to increase quality, all at the expense of distributing software to mass audiences). Microsoft, of course, is still in a pretty dominant position from exploiting this scaling to the max when IBM so graciously made the hardware into a commodity mass market item.

So far, the most successful web app (Google) is the one which has made web app discovery scale like nothing else (every page with useful content on it is a web app - code, data, it's all the same). The brilliance of Google is that it captured a mass end user market with a minimal user interface. They did it with math (maximal leverage of plain text queries plus the structure of the web, and similarly with ads which have simple interfaces at both ends and are backed with sophisticated algorithms), and scaling by imposing unusual amounts of internal discipline on the best developers they can get (and they can get pretty good ones). All this just to get to a position where they might be able to compete with Microsoft as a platform, and unseat the power of shrinkwrap scaling. I think the only way they can do it is by attracting a lot more developers than Microsoft, and the only way they can do that is by taking a lot of Microsoft's developers away. They might be able to do it, but there are all sorts of challenges. My guess is that what will happen is that they will draw a lot of developers away from Microsoft, and in the process they will lose a lot of their external cultural influence as far as being able to promote clean interfaces. Web apps will be even more dominated by the everything in one place aggregators (exemplified by Amazon and eBay) than they are now.

The problem with nice UIs is that there just aren't enough good developers to make it scale.

In my opinion, a lot of The Software Problem(tm) can be traced back to this tendency to underestimate the difficulty of using magic black box X. Maybe this is because most programmers never try to make a real magic black box X that will be used by random person Y in random situation Z themselves. If they did, they might have a little more respect for the fact that it's really fucking hard, the interface will inevitably have all sorts of corners, and the result is never going to be as magic as you would like.

So now that I've voted up every plinkplonk comment, my comment is that most people obviously haven't read the book. The post is pretty good, but the book is better. You should read it.

If you do read the book, you will see that the discussion begins with Norvig saying that he thinks one of the most important things is being able to keep everything in your head at once. Extra tools come in when the problem gets too big to do that, but here's the key: he saw right from the very beginning that the Sudoku problem could be solved with two tools from the AI toolbox. In other words, he saw the entire solution immediately, and it was never too large to fit easily in his head.

Seibel's analysis fine as far as it goes, but he misses the really important thing here, which is that this is not just an example of someone recognizing a problem that they already knew how to solve. It's a case of someone with the mental tools that allow them to dramatically reduce the (apparent) complexity and size of a very large class of problems that happens to include Sudoku. Seibel takes a bottom up look at the data structures Norvig used, but this can be misleading because they weren't designed bottom up, they were designed all at once. You simply cannot do that unless you have the necessary training in abstract thinking (read: mathematics/formal logic/language development/ai techniques/etc).

No amount of code centric techniques or tools will ever make up for not having these tools. There will always be (relatively trivial) problems that you will never be able solve without them, because you will not be able to fit everything in your head and your ability to reason about the problem will be crippled by that. Debates about TDD are not even wrong, because they are at the wrong level of abstraction. Spending any significant amount of time discussing it is premature optimization.

The point is that some people are too blinded by their ideology to even come up with a crude solution, let alone an elegant one.

Per Minsky, big brains are a liability until an innovation comes along that allows them to be used properly. IMHO big disks, along with big RAM and big processing cores (now core arrays) are liabilities because we don't know how to use them. Because we don't know how to use them, we fill them with garbage and complexity, like big brains before whatever innovation enabled the human brain, and all that capacity becomes dead weight with a huge amount of inertia. A liability.

Few things depreciate in value faster than source code. Forgetting revisions is useless if the memory is just going to be filled with more code. The prospect of petabytes of bloated, broken, and rotting code in any sort of repository is frankly disgusting to me. We are drowning under the weight of programmers who think the product of their typing (not so much thinking) is so special that it needs to be preserved forever more. I pity the new yosefks, the debuggers of tomorrow, I really do.

It's quite interesting to think about how much I've learned about nature socially, vs. directly. It seems clear that I learn almost everything socially, and everything I learn directly is probably available socially, probably at a lower cost. In other words, nothing I learn directly is really new, and what is new could very easily be predicted from models - it's hardly even information in the Shannon sense. I'm a university student, but it's not clear to me that I've ever even met anyone who learned anything new themselves either (about the environment). Almost the entire information processing capacity of the species seems to be devoted to internal processing of information and the modeling of internal behavior. It seems like there's no other way it could be, given the sheer number of people, but it does make you wonder how far that can go.

Listening to people like Gwynne Dyer talk about global warming makes it sound like the problem is not so much that we don't have enough people tracking the environment, or even that we don't propagate the information fast enough, but that the sheer inertia of the system makes it so that changes can't be made fast enough to avoid major shakeups.

Individual members of populations of every species alter their environments. Humans may do it more deliberately, but as either civilizations or as a species as a whole it's not clear to me that we're all that much better at anticipating and avoiding environmental disasters than other species; we just do everything at a larger scale (more massive individuals, across the whole planet) than any other single species. Not necessarily longer time scales though - that remains to be seen.

Of course the problem is that 99% of non-conformists are wrong, but all of them believe that they are right, some of them are really dangerous, and some of them are work very hard to be persuasive. Society is a balancing act of incorporating as much diversity as possible without losing structural integrity. Most people disagree with each other about whether we need more diversity or more conformity, to what extent we are unbalanced, and pretty much everything else at any given point in time.

Exactly. Evolution is basically a filtering process that records and compresses memories of past changes to the environment, along with mechanisms for communicating those memories as widely as possible and incorporating the communications of other agents. The better agents are at this, the more resources can be marshaled for recording, compressing, and communicating memories. For this reason larger and more tightly coupled agents are favored, but the complexity of maintaining homeostasis increases with agent size, and increasing size also serves to move agents into new selection environments. In other words, an agent's own actions may cause their fitness function to change in ways that are difficult to predict from past experience of the environment alone, and this may become a bigger problem as agents increase in size. At some scale, agents who do not add models of themselves to the fitness search space may be at a disadvantage. If they are social agents in a society of agents similar to themselves, and if they already model other agents, creating self-models may not be much of a leap.

Or at least that's my half-assed theory. Guess I should probably read up on Robert Axelrod's stuff now. Thanks for the pointer.

So you're saying that "they weren't right for their jobs" is wrong. What about the "burned out" part? What do you know about why they left? Did they just move on the more interesting things, like so many startup people do?

Genuinely curious here, as I don't know, or know much about, any of the people involved.

You are standing on the shoulders of people who design languages, vs. standing on the shoulders of people who write libraries. Languages are much closer to the central concepts in computing, and the people who work on them have done a lot more careful and general thinking, in general, than what goes into libraries. Libraries are great to build on, but only so long as they are almost exactly what you need already, because you can't change them to any significant degree.

There's a reason why all the best languages (lisp/forth/etc) are language building languages, not library building languages. A library building language is just a DSL that you can't modify. You can write anything in it, but so what? You can write anything in Brainfuck too - that's what the term "Turing tarpit" was coined to describe.

When someone tells you what their favorite language is, you should ask what that person does. If all they do is write web apps, they probably like their language because it is a good web app DSL. Nothing wrong with that, except that it doesn't scale (webapps scale, but they do it by scaling the database, not the language).

It depends on your priorities. Many U.S. families move long distances every few years, and many young single people move significantly more often than that. Certain jobs can require someone to move almost daily. Part of it is because people want to, and part of it is because the culture makes it easy by providing technology that enables it. My guess is that the future will probably trend towards even more flexibility in mobility, not less (especially in the U.S.), although there will always be many people who want to settle down.

The gold box/pepsi/coke/cola/jolt/id/idst/soda languages are indeed interesting, but from the outside of VPRI it isn't easy to figure out what they do. Listening to Alan Kay try to summarize it in a few minutes (http://irbseminars.intel-research.net/) makes it sound like even he doesn't understand it very well.

Piumarta seems to be a very sharp guy, but it's strange that a software project that is supposed to radically simplify the software stack still doesn't appear to have a working prototype of a complete two-kernel (pepsi+coke) system, almost five years after the albert paper (http://piumarta.com/papers/albert.pdf) that sketched out the basics was written. Kay keeps talking about how cool it is, and Piumarta has given at least one talk about how cool it is (http://www.youtube.com/watch?v=cn7kTPbW6QQ), but as far as I can tell it doesn't even exist yet. There are working pieces (which are each tens of thousands of lines of code), but from the outside there doesn't appear to be a working pepsi+coke system yet, let alone iterations on it. The VPRI progress reports don't even mention it.

VPRI seems all over the place, and Kay is talking about objects with AI-complete interfaces now. The mailing list is dead, and the wiki is pretty much dead. There's more information on Piumarta's personal website than anywhere else. I know it's supposed to be blue sky research, but it still seems weird.

My impression of the whole thing is that "complete" reflection/self-description is not a good foundation for minimalistic systems.

This is like the adult version of everything the culture tells you where you're a kid: "you're special! you're a unique snowflake! you can do anything, if you just believe in it! follow your dreeeeeeeeeeeeeeeams!" The adult version is more succinct, ever so slightly more specific, and doesn't have all the pretty pictures, but it's the same thing.

Well, I grew up in the culture too, and I guess I drank the Kook-Aid. If it strikes any chord in you at all, you should probably go for it. If you want my advice, don't do what everyone else is doing. Not everything has to be a social networking webapp. Get off the net and read a book once in a while. Be in a hurry, but be smart and thoughtful about it too. Always Be Creating, but make it something you'll learn a lot from, even if it fails.

But why care about my advice? There are so many other people who will tell you what to do.

Given that DSLs are hard, it does not follow that sticking "foundational concepts" into "components" is a better strategy than DSLs. If you write a DSL, you are standing on the shoulders of real giants. If you rely on components, you are going with the recently formed current conventional wisdom, and you are standing on the shoulders of relative peons.

Note that Fred Brooks argues for conceptual integrity, provided by a single human being, as the most important guarantee of product quality. If you use components, then you are accepting a system partitioning that has been decided many layers above you. If you design languages, then you cut out most of those layers. This gives you far more control over product quality.

Yeah, it's hard. Quality is hard. If your primary goal is anything other than quality, you will probably not produce a product with much of it. That's the real reason why there's no silver bullet.

Maybe it is possible for lesswrong to be less wrong after all.

The title and content of the post state that, if the UI is terrible, then it was (probably) created by a programmer. They do not say the converse, nor does the converse automatically follow (the converse being: if the UI was created by a programmer, then it is terrible).

Note to readers who might misunderstand: the above posts (parent and parent parent) are trolls. The only thing worse than dialog boxes are attention whore dialog boxes with poor writing. The user does not want to read your stupid dialog box because they should not have to read your stupid dialog box.

If you use an exclamation point, you incite the user to anger; if your message cannot be perfectly understood every time by every person with a quick skim at 30% attention, they will click a random button because they have better shit to do than read the stupid dialog box that you put there because you couldn't be bothered to come up with a sensible design.

The user has a job to do. They want to do that job. Your job is to help them do their job and make the computer disappear, not remind them that they are using yet another piece of shitty code in a shitty program on a shitty and infested piece of junk that they would destroy with a baseball bat, like that guy in Office Space, if they could do it without getting fired.

It's an excellent point that many businesses are not really technology businesses at all. However, one could make the argument that it is still in the company's best interest to promote IT quality because that is the best way to keep the IT department from bloating into something that consumes far more resources than necessary. Good technology should be reliable, cheap, and invisible, but those things take a certain amount of quality.

I would argue that most non-technology companies would be best served by employing a single very good software engineer, maybe two or three if the company is very large. If the company is small then the one engineer doesn't even have to be all that brilliant. You can't do this if you have to administrate a typical IT ecosystem, but if your company is not a technology company, why do you need a typical IT ecosystem in the first place? (Because no one knows how to do anything outside of one, and even if you can find someone you can't find a replacement. Therefore every company must support a relatively large and complex ecosystem whether they want to or not.)

This is basically a worse variation on the better Worse is Better article by Richard Gabriel, focused on software design as business strategy instead of as a pure popularity strategy.

The core observation of Worse is Better is that the 50%-80% solution, designed to be easy to replicate, is more popular than a 90% solution that is more difficult to replicate, because the worse solution will spread faster, gain a larger community, and can then evolve to an 85% solution and will not need to evolve further because users will have been conditioned to expect less.

These arguments appeal because they are basically correct descriptions of a common phenomena, but if you simplify the message to "mediocrity is good" then you miss the point. Mediocrity of product is good, but only if it allows for a 50-80% solution to an existing problem and only if that is the problem that you want to solve. Mediocrity of skill is also good, but only if your goal is to look good to managers of mediocre software products and if you have no desire to move beyond your current domain of expertise at anything beyond a snail's pace. Note how Gabriel says that C is not good enough for AI: it is a great example of this, and also of what causes people to start believing in mediocrity; namely becoming overly discouraged after working on a problem that is far too difficult to solve with current tools and levels of understanding.

I think there is a correct observation in this article as well, and that is that putting a lot of effort into designing the right thing without getting any feedback from users up front or during the process is a terrible form of premature optimization. I agree with this observation and wish it were obvious to everyone, but clearly it is not. But the real question is who are your users and what do they demand? Here the writer goes off the rails by attempting to argue that users want mediocre software, when he really means that users want software that does something very similar to the software that they already have.

The distinction is blurred by the fact that the software that users already have was probably created by someone who sacrificed quality for time to market. The problem with not making this distinction is that you fail to recognize just how much quality remained after those sacrifices had been made.

Microsoft is a good example of this. Many people like to point out their lucky breaks, their rapacious acquisition strategy, and their monopoly preservation techniques, but it is also important to remember that Microsoft, for all its bloated bureaucracy, began with a strong technical culture and has managed to retain much of that culture as it has grown. It has an excellent research division, one of the few remaining in industry (not that Microsoft is much better at leveraging it than, say, Xerox was). If Microsoft is mediocre, and it is, its level of mediocrity is higher than most people's best effort. If you think you can beat Microsoft at anything remotely large scale with a strategy of mediocrity, well, you deserve what you get.

Linux is another good example here. It is a prime case of worse is better culture; initially based on a clone of a conservative OS design, never having ambitions beyond POSIX compliance as a way to spread everywhere, and repeatedly trying and failing to get a foothold on the desktop by slavishly copying Microsoft. Apple may not beat Microsoft, but it is thrashing Linux on the desktop with a strategy of tight control and emphasis on quality. Linux is mediocre all right - too mediocre to succeed outside of the server market, and even there it is probably not as good as whatever BSD best fits your needs. The real success of Linux is when it leverages its large porting culture to spread to platforms with no alternatives. And you probably aren't even as good as the core Linux developers. Hope you're not as ambitious.

Take a look at Google, perhaps the biggest challenge Microsoft has faced yet. Did they get where they are today by being more mediocre than their competition? Quite the opposite, I think.

The secret of mediocrity is that it is more helpful as a way of capturing a mass market than you might think. The secret of quality is that it allows you to create a market that doesn't even exist yet. Do you think every mass market lasts forever? How do you think they die? How do you think their successors began?

So yeah, be mediocre, but you will be at the bottom of a long chain of increasing mediocrity, and your ambitions of being big and successful some day will never be more than delusional fever dreams. Have fun with that.

The message here is not that really that mediocrity is bad or that quality is good. The real message is that you should think carefully about what exactly mediocrity and quality mean in your situation. These are meaningless terms in the abstract. Ignore the details at your peril. Don't let "premature optimization is the root of all evil" turn into "mediocrity is better than quality" turn into "I can be lazy and get away with it" turn into "I have no job, there is no market for my skills, and I have lost the ability to learn new ones." Don't live your life by platitudes at all. Think a little bit.

It means that the anti-aliasing is done with the positions of individual RGB components in mind instead of treating whole pixels in a grid as the fundamental abstraction.

It allows for smoother anti-aliasing at the cost of some portability (things change if the display is rotated, not all displays have the same sub-component configuration, etc).

Modularization is indeed independent of programming discipline. That is basically my point. Breaking a program down into the correct components is all-important, but most of this happens well below the module level. Unless the system has been over-engineered to death, as OOP encourages.

Three cheers for not being swayed by appeal to authority, but I'm curious about what you think counts as "business OOP" that doesn't count as "enterprise," as "enterprise" seems vague enough to encompass pretty much anything.

Your critique of lists and conses is again centered on the notion that documentation and encapsulation should be done in code and enforced by the machine. These things may well be necessary to build an economy of software modules in a closed source world, but the original article is just one example of the brain damage that this sort of world creates.

I'm glad you've been exposed to functional concepts, and I don't think that business developers are idiots, but I do think they live in an environment that is by and large toxic to good programming practices. I'm not paranoid, I just see a lot of evidence for the validity of Conway's Law.