"Two-party system" = implicit ban of parties other than the two existing ones.

Partiocracy?

(Then again, Lenin said that there could only be one party.)

You said "social democracy" twice and ignored the Marxist-Leninists (but it's ok, they should be used to that by now).

Communism is considered a global labor movement for very specific and wonkish reasons that I won't explain here. Trotsky explained it briefly in the latter addenda to the Communist Manifesto, and you can read it there if you don't already understand why that is. Contrary to their global ambitions, communism is absolutely focused on achieving revolution in their own local (western, industrialized) country, because they believe it will spread. Communists don't like Socialists much, but even the Communist Manifesto says that the movements are highly compatible until well after the revolution is underway, so they should be encouraged to work together on common goals.

And these are only the major breaks! There are tons of minor ones too, like labor vs Marxist-Leninists, or the dozens of socialist sub varieties that constantly slough off the major parties.

It's true that leftist groups will never exactly agree on what should happen once capitalism is disrupted, but until then there are a lot of things they could collaborate to achieve but don't. It's like worrying about how you'll spend your lottery winnings before you've even bought a ticket. What's the point?

I'm sure the FBI has a mass grave or two.



Does it still count as two parties if their differences are superficial?

Whoops! Typo. The first time I said social democracy I intended democratic socialism. Should read like this:

I've assumed recently that the reason why is because leftist organizations want their ideologies to take the place that religion has usually occupied in modern nation states; that is, a kind of unifying cultural force that provides a sense of solidarity among people that's distinct from national identity. In other words, the revolutions that socialist movements want to bring about isn't only an economic and political one. It's also a cultural one, involving the transformation of the inner lives of people who live in socialist/communist societies (Hence the socialist/communist aspiration of creating a "New Man".) After that, it gets a little murky for me and I can't connect the dots. But I suspect that a component of it is that in order for socialist ideology to take the place of religion, economic theories or philosophical anthropologies need to take the doctrinal role that traditionally belong to orthodox beliefs that make up religion. And because orthodoxy of opinion becomes important (because it's an essential, and not an accidental feature of the revolution that socialists are trying to bring about), the content of belief becomes a potentially divisive issue, because in order for orthodoxy to be orthodoxy, other points of view need to be declared heterodox/heretical.

So basically, Alex Jones was actually right all along: the two parties are just two faces of a global conspiracy hell-bent on depriving me of my right to practice fundamentalist Christianity (and forcibly vaccinate my children and brainwash them into wanting a sex change in elementary school).

I love this movie so much lol

That's interesting, but I'm personally not convinced that religious orthodoxy is important enough that economic opinions rise to that position for want of a real one.

My own guess is that it's the bike shed effect: such economic systems are not likely to be reified any time soon, so opining forcefully has low table stakes. Maybe the converse is also why so many moderates and conservatives are lining up behind neoliberalism instead of trying something different.

Here's another way I'd put it. Revolutionary politics isn't only about imagining the society in which one wants to live and working towards implementing it. Part of the appeal to being involved in radical politics is that it provides followers a non-conformist set of beliefs that form the basis of their political identity in the present (also creating a sense of community and connection with other individuals who adhere to the same beliefs). Even if the political project/utopian society that a radical leftist aspires to create will never be realized, formulating what that society should look is a meaningful endeavour in the present. Which is just to say that there's a lot at stake in what one believes in radical politics, and reasons why disagreement would be consequential. It's related intimately to how one identifies.

How did I ever miss this (somebody in the comments to the Hermann Cain ad that Eversor linked to in the other thread mentioned it): Trump's (short lived) original campaign logo.



Who knew that Mike Pence would be the man to make America Gay Again....

I agree. The point Eversor made has some real validity to it, but I don't think it's true that socialism and religion are two sides of the same coin. Maybe if you go back to utopian socialists, but I don't think even class struggle in Marx is the same as religious doctrine.

I am hardly one qualified to comment on this since I've never met (aside from a few lefty college kids) a single socialist IRL, but it would appear that the left generally doesn't rally around organized religion. (Edit: historically, I believe this was not actually the case.)

There are few to no Republican politicians on the national level who don't identify as Christians. Though I am not sure if we can argue for a clear causal direction here, one might say that the left gave up a potent unifying signalling mechanism that the right retained, regardless of whether or not the left actually bothered to replace religion with something else like the state.

And actually, on some level this is trivially true, if we think about how, whereas fundamentalist Christianity has little use for scientific results or innovations of morality (either of which might impinge upon religious doctrine), once one takes a less axiomatic worldview, almost by definition you are going to see disagreement, until new forms of consensus are reached.

I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right:

Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.

Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.

Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.

Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.

Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.

However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.

Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better.

Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called ``PC loser-ing'' because the PC is being coerced into ``loser mode,'' where ``loser'' is the affectionate name for ``user'' at MIT.

The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.

The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix-namely, implementation simplicity was more important than interface simplicity.

The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn't understand (I'm not sure I do either).

Now I want to argue that worse-is-better is better. C is a programming language designed for writing Unix, and it was designed using the New Jersey approach. C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%--80% of what you want from an operating system and programming language.

Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven't they?

Unix and C are the ultimate computer viruses.

A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.

It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.

The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.

There is a final benefit to worse-is-better. Because a New Jersey language and system are not really powerful enough to build complex monolithic software, large systems must be designed to reuse components. Therefore, a tradition of integration springs up.

How does the right thing stack up? There are two basic scenarios: the ``big complex system scenario'' and the ``diamond-like jewel'' scenario.

The ``big complex system'' scenario goes like this:

First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware.

The ``diamond-like jewel'' scenario goes like this:

The right thing takes forever to design, but it is quite small at every point along the way. To implement it to run fast is either impossible or beyond the capabilities of most implementors.

The two scenarios correspond to Common Lisp and Scheme.

The first scenario is also the scenario for classic artificial intelligence software.

The right thing is frequently a monolithic piece of software, but for no reason other than that the right thing is often designed monolithically. That is, this characteristic is a happenstance.

The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.

A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn't.

But, one can conclude only that the Lisp community needs to seriously rethink its position on Lisp design. I will say more about this later.

rpg@lucid.com
[CENTER]The Rise of ``Worse is Better''
By Richard Gabriel
[/CENTER]

This is the ancient debate between agents of change and beneficiaries of stasis. Conservatives have a built-in rallying point: the present and past. Liberals do not have that; they must rally around desired possible futures, of which there are many. You don't need to drag religion (or lack of religion) into the discussion at all.

This argument doesn't seem compatible with either Christianity's tradition of theological innovation, or the proliferation of denominations (many of which formed for yawn-worthy reasons). In fact, Christianity strongly resembles how leftist political parties behave in practice.


Gabriel's "worse" New Jersey approach is still far better than the way most real software is made, almost comically so.

All right, I will confess that everything I wrote probably has a better chance at making sense if I swap out "Christians" for some other adjective--say, "conservatives". But then this just begs the question, and I'm forced to agree with your first paragraph.

At best we might say that fundamentalist "Christianity" is correlated with (social?) conservationism, but this might have more to do with liberals not being okay with pulling **** out of the Old Testament in order to oppress minorities.

Worse than worse is worst of all, I guess.

Anyway, I copied it here because the adaptively simple nature of conservationism as a movement reminded me of the "worse" side of Gabriel's argument, but it was just an inkling of an analogy that came to mind.

Recall, this is his "worse", which he said produces more successful software:

• Simplicity: the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
• Correctness: the design must be correct in all observable aspects. It is slightly better to be simple than correct.
• Consistency: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
• Completeness: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Gabriel made two mistakes, which were perhaps reasonable in the late 80s at the dawn of the commercial software industry, but are not reasonable today. The first mistake is the implicit assumption of greenfield development. The second mistake is the implicit assumption of cohesive design. In practice, software products are maintained and extended indefinitely; those efforts are guided by how the market responds to the product, so they can't be included in any up-front design. It's complicated by the fact that, once a product has been delivered, your users will... well, use it. They'll spend money on integration, automation, and training, and whenever you make a breaking change to existing workflows, they're gonna have to spend that money all over again. That's kind of a big deal if you make your money from license sales rather than, say, ad views. End result, you don't have "design", you have "designs": a somewhat-big design up front, and many feature designs following it.

So, this is how things really are:

• Simplicity: The feature design must be locally simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Global simplicity should always be sacrificed for local simplicity. (Someone else will refactor it eventually!)
• Correctness: The feature design should not be observably incorrect.
• Consistency: The feature design should not be locally inconsistent, when possible. If the feature doesn't fit well with the global design, then it's okay to add arbitrary amounts of global inconsistency and interface complexity.
• Completeness: The feature design should be as minimal as possible to satisfy present needs, because that is all you are paid for. But feel free to prognosticate about what bull**** features you'll have to add next, and feel free to sacrifice as much implementation complexity as necessary to make your design "extensible".

Edit: To be clear, what I'm saying is that this is how "successful" software is really made. That includes things like Linux and Windows and the C standard library. It's not a good way to make software, but it's a more accurate description of the practices he was trying to describe.

I don't mean to put on the pressure, but have you considered writing a book on this topic? You are an excellent writer and clearly have the right experience.

I wonder if there is an up-to-date example of a commercial software product today that exemplifies his "better" approach, and if so, how rare it is, and how much it deviates from his description.

Then again, I suppose there is little point in doing a post-mortem of something that by definition is presumed to work well. Or maybe it doesn't work well, and thus doesn't exist outside of NASA.

Wherever it exists, I guess this doesn't include the internet of things / cars.

OTOH, this probably has less to do with differing approaches to the software development process, than it does with the fact that the whole industry seems to have the wrong idea about security.

Maybe suckless? http://suckless.org/

The New Jersey approach optimizes for everything except completeness, which is fine, but you're not going to see much of that in an industry obsessed with ~features~. In aggregate, successful software maximizes completeness, at the expense of everything else. Nobody actually wants that, but it's what sells.

The MIT approach is pretty much right out. That's saying correctness and consistency are maximized without compromise, with a little completeness sacrificed but not much, and simplicity is left as an exercise to the reader. This is maybe achievable for an undergrad independent project, a simple program written by a single person, which will never be used by anybody else. But, even then, the TA would probably dock points because it's too complicated to understand.

Security is impossible.

Heh.



https://youtu.be/O3tVctB_VSU?t=7m58s

If you want to know what I'm talking about when I say "maximize completeness and minimize everything else is what sells", look no further than the static analyzer market.

For example, HP Fortify purports to statically analyze PHP, Python, JavaScript, even Ruby, for Christ's sake. You can't statically analyze these languages, it's a ridiculous idea; unless you solve the Halting Problem, the output is gonna be crap, and they know it's gonna be crap. But they threw together a parser and some half-assed analyzer anyway, and shipped it, and now they can tell their customers they support* Python. Nobody who actually uses these languages is dumb enough to fall for it, but the big companies with 8 million lines of C code and 50 lines of Python eat that **** up.

It's not just Fortify doing it, it's everybody, except for the bit players who don't have enough money to do it yet.

There's whole dimensions of engineering trade-offs that aren't accounted by that "worse is better" essay, and all of those, too, are neglected in exchange for completeness. That includes, for example, performance, which marches ever downward, globally and uniformly, as new features are haphazardly added to the product.

Interesting. It probably doesn't help when your sales department is falling over itself to promise ridiculous things*, if what I read about IBM Watson is any indication.

God damn this nonsense.

Do you know why humans survive for 70 years under constant attack from parasites? Because the parasites evolved not to kill us. That's it. Parasites that kill their host don't get spread as far. You look at non-human pathogens, like rabies, syphilis, black death, HIV. They don't ****in care about you, accidental host. They will kill you, and your immune system won't do **** about it.

So unless your fantasy is a software ecosystem where viruses exist to reproduce and spread, only, and not to accomplish specific nefarious actions while present in the host (like killing them or taking control of them or stealing their secrets), the human immune system is a poor model.

It's also not "in" that gigabyte of source code. That's just the firmware. Your immune system's software is in your antibodies and T-cells, some of which you inherit from your mother, some of which you get from vaccines, and most of which you develop as you are exposed to your environment (and maybe some bonus ones that kill you when you eat the wrong thing). THAT is where the magic happens, and that's an absolutely mind-boggling amount of data.

****s why everyone's afraid of bird flu and swine flu. Why not people flu? Because people flu doesn't kill people.

Ebola comes from bats. They get a mild fever. It liquefies us.

Well, I suppose there's always the possibility of simply not connecting something to a network if it doesn't need to be, and to make sure the person making this decision takes into account all the externalities that adding in whatever features they feel like they need to.

I agree that Sussman seems to be making a huge oversight here about selection based on symbiosis.

For whatever reason people in software seem to feel qualified to opine on every topic under the sun outside their field of expertise, but I can forgive the man since he helped invent Scheme, advised Richard Stallman, etc.

I don't understand why the control systems of a car needs to be connected to the entertainment system at all. It's like the CIA paid them to be so stupid.

Ew, gross.

TBF I don't think he taught him the part about eating your foot cheese, but his work with Sussman apparently is still state of the art:

No joke:

This is what happens when your expertise is expressing ideas, for want of an idea to express. Writers are the exact same way. In fact, programming and writing are the same profession, they just don't all realize it yet.

Well that certainly explains my life story of dishing out plausible bull****.

What I got out of an undergraduate pure math degree (without having the discipline to do undergraduate research, go to grad school, etc.) was, more or less:

1. Proofs are a fun way to coerce whatever plausible bull**** bubbles up into facts ("theorems") about some of the more simple things you can state in abstract language
2. For whatever reason, programmers don't seem to be aware that you can do this, this despite their obvious desire to let their imagination run wild nevertheless

Not saying that people with a C.S. background can't write proofs (or that they need to for their job), but mostly that people in the field seem to have such horrible aesthetics when it comes to knowing where to put various harebrained ideas. But hey, a blog post increases my career visibility, so maybe being promiscuous is understandably just as popular among people with ideas as it apparently is among companies promising products features.

and if you are really ambitious, you can release it as a programming language and crown yourself cult leader

I am clearly overplaying some crass skepticism by extrapolating from some visibly bad apples here, but I have to wonder if people are being shown role models that select for all the wrong traits (or maybe they are the right traits? gregariousness and experimentation sound adaptive).

Still, there is something wrong when you've got a sizeable majority using things with as many unnecessary warts as Perl has. There are research languages from universities like the ML family, or Common Lisp, that we might as well be using directly but for some reason need to wait for people to borrow from to add to the latest toy language.

I guess this rant is mostly about open source hobbyist projects that grow big enough to eclipse their superiors.

TBF things like Perl arose for locally pragmatic reasons. It just seems so arbitrary that it's these things that then take off. Maybe something to do with network effects or something.

(and yet to these languages' credit, they are more "fun" than Java / C++*)

*and according to Paul Graham, using them shows that you are a superior programmer

The funny thing is that I seem to be converging to a (negative) view of what is usually referred to affectionately as the "hacker".

Kind of makes me wonder if the chasing the archetype leads to good engineers, or if the two are even compatible. Hackers from the MIT A.I. lab days didn't really have customers beyond each other, and perhaps admitting that this has changed is too depressing for most to process.

Yep. Definitely agree. Especially with events such as the council of Nicaea, where Christological orthodoxies were first formulated that splintered Christianity into various dominations that differed about arcane questions about the nature of Jesus' divinity and humanity. Over the course of its history, Christianity has divided itself up into all of these various denominations, very often, on the basis of truly trivial matters (I'm thinking, for example, of the schism that divided the Eastern and Western Church in the 11th century). And that's despite the fact that there is in Christianity an ecumenical impulse to create a single, undivided "Church" (i.e., a single institution that is the centralized institution of all of Christendom). Thinking about it now, socialism/leftist groups have universalistic tendencies that are quite similar to Christianity. It probably is the case that those tendencies in leftist politics also contribute to why 1) orthodox opinion is important and 2) there is so much division among leftist political groups.

The recognition that unity is important for a movement can actually have the effect of producing divisions within it. As the group changes and defines itself by asserting what its orthodox opinions are, some will refuse to accept the changes, and will remain committed to beliefs they had held beforehand, rather than accept whatever the elites determine ought to be the unifying beliefs around which the group should rally in the future. The marginalized groups will then claim that they are the authentic torch bearers of the movement, and that the group from which they splintered are inauthentic. Of course the original leadership will condemn the splinter groups as inauthentic as well. Something like that happened repeatedly in the course of Christianity's history, and it is the sort of things that seems to happen all the time among leftist political groups.