Criticism of AO3's User Interface

A few observations on UI design prompted by a comment I read on reddit.

Look at Archive Of Our Own for a good example. It has a much, much easier interface than fanfiction.net, its tagging system is rich and has a lot of advantages, it has nice features like letting you group stories into collections, you can reply to reader comments with proper discussion threads, etc. 

On A3O you can't do social tagging as you could with delicious more than a decade ago. There is only dictatorial tagging with the author being the sole dictator. You also as a reader can't cut out seeing insignificant tags, whether it's because they're so general as to be meaningless or so unique as to be unguessable. So those useless tags clutter up your attention and screen space while browsing, slowing everything down. Even though detecting insignificant tags by software operation is trivial.

You also can't do logic operations with search operators, only nest searches in a narrow way. You don't even have access to the simple NOT operator. And finally, the whole paradigm of search is entropic because it annihilates the existing lattice structure that exists in browsing rather than filtering that structure and collapsing sparse branches.

The comment system offers no levels of privacy nor ways to aggregate comments OR readers in any useful discussion-oriented manner. Because A3O isn't about discussion nor debate nor criticism nor anything like that, its model is strictly pairbonding and attentional. That's why "gift stories" exist on A3O. Everything is about readers giving attention to the author and possibly authors giving attention to the readers and authors giving attention to each other. And that is IT. A3O is functioning at the level of a human infant.

And because every comment is public, it's impossible to hide anything. Which means that strangers can scrutinize your interactions and apply their values to them. And which values get applied in any large open community? Gaian values of doing nothing, surviving at any cost and giving no offense to anyone for any reason whatsoever. Anyone who critiques others heavily is labeled an antagonist, a "troll", and totally anathema to the rule of giving no offense to anyone, thus driven out of "the community" which is more important than any abstractions like "good storytelling" or improvement or truth or critique. Gaians run every open forum in existence, and most closed ones. It's so easy to ban people as "offensive" when everyone can see all of their stuff and you just have to wait for an asshole to report being offended.

Some features I'd like: * For readers: a feature to auto-recommend stories based on the currently viewed story or your pattern of likes, sort of like Amazon does.

Extremely difficult to implement, requires machine learning. Unlike cutting out insignificant tags which only requires an asshole to think about it. (I say asshole because there are virtually no systems designers anywhere and so you rely on assholes for all your software needs. Enjoy your frustration.)

And in any case, the "features" paradigm of design is Gaian. A feature is a property of something that has a specific purpose. X is for Y. It's an incredibly narrow way of thinking that invariably produces broken software and kludgy software that's impossible to understand. Look at C++, it's a Gaian "evolved" programming language which absolutely no one understands and everyone claims is able to do anything but in practice can do absolutely nothing. Every program written in C++ is intrinsically broken, precisely because of its many, many, many "features". Brokenness is an intrinsic property of Gaianness, or any biological or ecological or evolved system. The only property those systems have is survival by cravenly appealing to their audiences or neighbors.

Genuine design works on the meta-level by COHERING features and ERADICATING features that don't fit within higher principles. Or even merely eradicating features whose benefit is not above a certain minimum which represents the cost of the feature taking up the user's and all programmers' mental space (so they can learn to avoid it as they inevitably have to do with broken crap). Undesigned "evolved" systems that have features added and added and added with none ever taken away because some asshole depends on them, are intrinsically broken because 90% of them is unused by 90% of the population, and 50% of them is unused by 99% of the population. And it's always a different 1% that wants each tiny feature and will whine. And Gaians will say cravenly that there is a "demand" for each feature and it would take "effort" to remove them.

For authors: a way to upload chapters and have them published automatically at preset dates/times.

See, instead of having a "feature" that does this, such as a script or something, you could just have a versioned object system that symmetrically allows you to read and write both the past and the future. So instead of a "scheduled" story, you just have a story that's written in the future. But nobody does systems design, least of all "architects", everyone is enamored of their little "features" which are really kludges.

The advantages of writing in the future are obvious: no more deadlocks ever but rather a solid transaction-oriented system. The advantages of writing in the past are difficult for lesser minds to fathom but they are far far more extensive. They boil down to: equity. If designed correctly, writing to the past can be done without the possibility of unending time wars.

But of course, there is that problem "if designed correctly" and the lack of systems designers on the Earth. At least recognized job-holding ones with significant whip power. It doesn't help that few systems designers understand systems design or can teach it, so you mostly end up with assholes with pretensions of grandeur like the inventors of Unix and C. Both of them 50 year old dinosaurs that really should have every single contributor to them summarily put to death.

I am not prepared to forgive the existence of C or Unix or C++.


So in summary, AO3 enforces the values of brokenness and inequity while superficially appealing to values such as freedom but really anarchistic hatred of all social organization.

No Interfaces Worthy Of The Name

Between self-sufficient concepts such as cars or Class Car on the one hand and large scale models on the other hand, there are interfaces. Not interactions or relationships but interfaces. The problem is that the software industry is extremely impoverished in those and as a result, dealing with it is excruciating torture to me. Because interfaces are what I'm best at and what I love. MVC is a good example of interfaces which are debilitatingly painful to me due to being hopelessly broken and low-level.

Think about it and think about how many concepts there are for large scale structure. Some patterns, architectures, frameworks, libraries, that's 4 categories already. Then how many concepts there are for small scale self-sufficient structure, probably hundreds of the latter. And then how many concepts there are for interfaces that one would be willing to use (so command and instruction and function don't count).

Events? But events are broken and not first class, so they aren't real. Object-capabilities? Disgustingly low level and broken. Object, maybe but that counts as small-scale structure really, or non-interface even. So there's message passing, inheritance, polymorphism? that one doesn't count. delegation. cloning vs instantiating, subclassing. Oh yes, aspects vs crosscutting, those are nice. Agents? Not really. Actors? Hmm maybe, maybe not. Probably not. Meh, probably yes but the problem is I just don't give a damn since it's about distribution and concurrency.

So there's no first class events, there's no first class dependencies, aspects aren't in any language I know. Transformational programming seemed in its infancy when I first heard about it, and I've never heard anyone ever ever mention it since then. Namespaces suck rocks so they're broken. Naked Objects? Oh yeah there's some guy who implemented it as a library or framework in Java, that's good for him honestly but doesn't count. Especially with the implementation being so kitsch and primitive rather than thorough and comprehensive. I mean, where's the IDE using naked objects? Nowhere.

There's remote message sends and proxy object, doesNotUnderstand: NullObject, those are another 4 interface concepts. So that makes what? 10? An even dozen? Twenty? It doesn't matter how many there are because here's the sick thing, they're enumerable. and they're not categories of things either, they're discrete instances of interfaces.

The software world forms an uncanny valley type field to me. There's large scale structure and then there's small scale structure and there's no bridges between them.

I don't think I'm the only one who loathes debugging or reverse-engineering with a passion. But I do think I'm the only one who understands why. The tools are worthless because the concepts to even minimally support asking "where did this bug come from?" and "how do I use this?" don't exist in software.

Conversation On Secure Multiplexing

I drew some insights into the execution stack from TUNES. More of them than the whole exokernel thing.

Main and only insight from exokernel was that secure multiplexing is independent of abstraction. You can have ONLY secure multiplexing enabling you to present something that looks exactly like the bare resource you're multiplexing. That insight fueled Xen and other hyper-virtualization things.

The only problem with it is it's a lie. Secure multiplexing is an abstraction by itself. You run into the limitations of the abstraction if you push it, exposing the underlayer's existence, at which point the abstraction starts to fray and reveal its nature. For example, that there ARE other OSes running on top of the hypervisor because there's "missing time". and then it becomes obvious that hiding each other and not permitting any way to cooperate or interact is a choice of abstraction.

Joe B: fuck, I comprehend nothing

Okay, say you've got a CPU. now the traditional way to multiplex (slice and share it) is with a scheduler. Problem is that OS schedulers look nothing like CPUs, they're higher level. What people managing a cloud want ideally is to present CPUs, bare and naked, and tell everyone to fuck off because hey there's your CPU, your problem.

Now they don't want those CPUs to be REAL CPUs because that's not scalable. But they also don't want them to interact, so one asshole customer can't bring the whole business crawling to its knees. They want no-stick teflon quarantine isolation from each other. better than quarantine, they want everyone stuck in their own reality with no way to guess that they're stuck in a virtual reality.

multiplexing = slicing and sharing
secure multiplexing = teflon nostick compartmentalized quarantined isolated slicing and sharing

If you're a bank, you give out gold. but you want to give out virtual gold tokens that function just like actual gold. and you want to give out as much as people will buy without collapsing your business. You don't want to give out REAL gold because most of it's just going to sit in people's homes unused rather than being consumed in jewelry and electronics. And if people are only going to trade them then they only need to be pseudo-real enough for the purposes of trading. The virtual gold tokens need to look and feel real when they're being tested by a buyer, and at no other time, which is money.

Any questions? Or is this too primitive?

Joe B: no, this is perfect

Well, the exokernel folk tried to pull the same stunt as gold => money but with CPU+memory or in general 'comp hardware'. the only problem is that nobody pretends that money ACTUALLY IS gold. nobody tries to melt money down to make jewelry. nobody tries to electroplate anything with it.  so what these guys were doing is ... debasing.

They were debasing CPU+memory+hardware and saying "it's just as good as the real thing!!" and the problem with that is inevitably they'd run into someone trying to treat it EXACTLY like the real thing (ie, someone who bought into the propaganda) and then they try to use the debased gold to electroplate something ... and feel gypped because it doesn't work.

So with exokernel, if you have a really high load on the CPU, many operating systems, you come to have missing time. and the whole mockery of it being teflon and no-stick comes crashing down. Now it's not a problem if admins in the cloud-providers keep a watch on resource utilization and add more physical computers in time ... but those admins can't pretend to themselves that it's JUST AS GOOD AS real physical computers.

And if you're going to have something that's intrinsically different from physical computers, then why not do away with some of the problems of it? So the exokernel folk's attitude that their project was somehow purer and better than everything else is just a lie.

What does the Unix scheduler provide as an execution abstraction? It provides processes. C processes to be specific. GemStone provides Smalltalk processes or smalltalk images even. The C processes *ARE* images, they're just dumb as fuck images ...

So what is the exokernel lesson? The REAL lesson? At any time, at any point in the stack of abstractions, you can insert a circular loop from a node (layer) to itself, presenting a facsimile of that layer higher up. And if you understand that then the whole exokernel project is revealed as limited in scope because it was providing ONE such circular loop among the one to two dozen layers of abstraction found in a typical operating system.

Joe B: what is this layer, and how does it loop on itself? is it the physical computer, which loops by resources being added to it?

It's any layer. you can take ANY layer and make it loop in on itself. the loop forms a layer.

Say you've got a harddisk. it presents blocks. So you can partition it and now you have four hard disks which also present blocks. And if you're smart you can make those partitions flexible.

Say you've got a monitor with 1 framebuffer. well, you can partition the monitor and present multiple framebuffers. and those are now called windows. Or you can have multiple monitors present as one framebuffer.

You generally need some OTHER resource mixed in with the first one in order to fake the first resource.

gold + paper = paper money

If you could completely supplant the underlying resource, you would do away with it and it would be called a change of technology.

TCP allows how many different sockets? That all run over a single physical copper wire. The phone company uses multiplexing to provide virtual circuits instead of real circuits.

Richard: you got what I said about OSI, right? about how SOCKS is just a circular loop of a layer?
Joe B: oh yes. I got the words, not the concept. I'd have to learn the OSI model first.
Richard: SOCKS provides a sideband and extension to the layer below but it really does nothing else. Much like barebones secure multiplexing provides a sideband, although the exokernel tried to pretend the sideband didn't exist.

application layer (protocols used by applications, supposedly close to humans)
V
transport layer (virtual circuits)
V
data layer (packets)
V
link layer (0s and 1s to the next computer)
V
physical layer (physical connectors, physical cables, electrical voltages, radio frequencies)

Joe B: okay, that makes sense

In the fibersphere model, there are no packets and the virtual circuits are pretty close to real circuits so they're fused in with the link layer. Too bad we have no fibersphere because it might have been resistant to wiretapping. since you'd need to own a substantial fraction of the world's computing resources to wiretap everybody. Not even to interpret or do analysis, JUST to wiretap.

So, the OSI's model provided two additional layers to the above, and both of them were sidebands off of the application layer and the transport layer. SOCKS takes virtual circuits and provides ... virtual circuits. + some proxying and crypto. The so-called presentation layer took in application stuff and provided ... different application stuff. MIME took text and provided images, both of them being application layer.

The fact these two layers were BESIDE the application and transport layers really confused the dumbasses that made OSI, which means moralists since this was a standard, they thought since SOCKS takes in virtual circuits we'll just ignore that it provides virtual circuits, we'll focus on the other stuff it provides and call it a higher layer. And as for the presentation layer, since there's nothing closer to humans than applications, by definition, then by stupidity it follows presentation must be below applications and let's ignore the facts to the contrary.

Joe B: yeah, I stalled at trying to distinguish application from presentation

An email is an application object. the application layer provides for emails. Well, MIME took emails and provided images and that's exactly how gmail attachments work. They just hide the MIME, as they should have in the past but didn't.

Basically, those two layers are extensions of an existing layer rather than separate layers in themselves. Extensions which aren't accepted enough to be considered part of the same layer. Or weren't at the time that OSI was made. Hence the service and presentation layers belong on the same level as transport and application ... just besides them.

Joe B: so… a loop layer is one that can take in the same entities that it can provide?

It's basically a type of extension of the layer. It's aware of the other layer and the other layer isn't aware of it.

Joe B: hmmm

Joe B: is this design, or is this analysis? well it's both. it's awesome, lol.

It's the kind of high level analysis that fuels systems design, and NOT normal design. It's part of the majestic overlayer that has been until now entirely missing. This is lesson 4?

• definitions / thinking
• manipulating datasets
• injecting values

People Hate Innovation

It took 15 years for someone to do ONE photo-gallery website correctly. The same for text.

Hell, try to look up how many new construction homes include any of (let alone ALL of): washlets, underfloor heating, central vacuums, in-wall conduits for computer network cables, foot or elbow operated bathroom fixtures, balcony panels that are transparent glass instead of metal. Or look up how many still use copper pipes instead of PEX. Or how many different kinds of mutually incompatible fittings there are for PEX pipes (the innovation there would be standardization). Or how many municipalities still use ductile iron pipes even though PVC is decades old and has superior performance? Or look up SawStop and the lame-ass "response" of the established table saw companies.

These are really things that should be legislated mandatory because it's quite obvious that people *loathe* innovations, even when they are blatantly superior to what already exists.

The reason why people come up with conspiracy theories around battery electric cars isn't because they love innovation, it's because they love conspiracy theories. Which doesn't mean that conspiracies don't happen. The Bohemian Grove is definitely an anti-democratic conspiracy. But look at all the stupid conspiracies around a suicidal fucker, john fucking kennedy, getting shot in a city where everyone wanted to kill him. Oh but can't speak ill of the dead so he was a "great man" and "everybody loved him". People lie lie lie.

The reason people love Thomas Edison and hate or scorn Nikola Tesla is not because Edison was a better inventor. In fact, Edison invented only one thing: the modern research lab, whereas Nikola Tesla invented four (AC power & generator, wireless power transmission, wireless control, and bladeless turbines). The reason people love Edison is really because he was rich and powerful. That is the ONLY reason. If he hadn't been rich, they would hate him for inventing anything at all.

Einstein is loved precisely because he is irrelevant. He invented some theories that are so complex, or supposedly so complex, that nobody is ever expected to learn or understand them. People can pat themselves on the back about how they love innovation, invention and science, while doing precisely nothing.

Einstein was a gutless fucker. He didn't set out (or accomplish) the destruction of any preexisting theories or modes of thought. And that is why he is tolerated unlike Freud who is still scorned even after he backtracked from his claims that Victorians were sexually abusing their children. Or Lloyd deMause (who is an asshole and a bully but that's besides the point) who set out to destroy most of sociology, history and anthropology. And succeeded, at least in theory.

Why do you think Star Trek is set in the 23rd century rather than the 21st century? It's because people like poverty. Why do you think every single last AI in Star Trek gets killed and every last robot wants to become human? Why do you think Star Trek, even set in the 23rd century, still has diseases, military command structures, marriage, planets and biological ecosystems? It's because people LOVE these things. And they love them for the sole reason that they're already familiar with them. Some idiots will complain that changing these things would make "storytelling" difficult, but really that just says people don't want to hear stories about societies different from their own. Which just proves my point. People hate innovation.

Gamers Are Lame

I recently discovered that gamers who aren't game designers are exceedingly lame. And I realized that the reason I'm not a gamer is simply because I'm not that lame, and because all the games ever made, all the games anyone could make, will always be lame.

There are damned few games where you get to alter the game world. The only ones I know are Minecraft, Second Life and the old MOOs (I consider Second Life a 3D MOO). And of course, the Reality MMORPG (that one's manual is really inadequate by the way).

In World of Warcraft, you don't get to change the outcome of anything at all. Things move around randomly, events happen, and you don't have any say in them. Only an unreachable deity (the Content Programmer) has any say in it at all.

In Dragon Age, Neverwinter Nights and other computer role-playing games, you get a choice of a tiny number (usually 3 or less) "endings" which are barely distinguishable. You win and become evil, you win and become good, you lose and die, so on. There isn't any possible way to get off these plot rails you're stuck on.

And aren't you happy with 3 or 4 destinations? Like I said, I'm not that lame. And although in Minecraft and possibly Dungeon Keeper, you get to craft worlds, you only get to do so on a very superficial level. Like a freaking engineer! I look down on engineers, I don't want to emulate them!

So anyways, how did I learn all this? Well, I read a couple of self-insert fics about computer games. It took me a while to figure out their authors were uncreative hacks who were novelizing the games. Cause yeah, I don't play computer games, I just read about them. And then I started wondering what the fuck was wrong with these people.

And I realized! They're cattle and insects. They don't think of anything beyond their own self-aggrandizement. The "sandbox" in Elder Scrolls where you get to acquire power, prestige (social status), and fortune (wealth) is all they could ever want.

None of them ever want to REMAKE the world, putting down railways and signal towers to keep the Tamriel Empire together. None of them want to build aqueducts, public baths and radically improve coal mining to heat the baths in Athkatla.

I suppose Civilization and Railroad Tycoon let you do that to a small degree. But they were crap, because you got bogged down in repetitive micro-management pretty damned quick. And they were over-simplistic. What you could build was exceedingly limited. The plot rails may have been conceptual but they were still there.

My favourite genre of fiction has always been crossovers with reality. And the first question that always comes to mind is what the trade opportunities would be. I think this rant kinda shows that. Healing potions for steam engines, hmm. Steam engines are nearly always possible so long as something resembling human life lives.

Semco vs Toyota

I've just been rereading all about the Toyota Production System to contrast it with Semco SA when I was struck by the fascinating realization that in many important ways, they are total ideological opposites.

Similarities

Yes, both focus on the long term, on teams, on developing people, on mutual responsibility between workers and managers, and empowering workers so they have some means of directing their work. But concerning what it is these systems control and what they let workers decide, they are total opposites.

Oppositions

In Semco, the ONLY thing that matters is your output. Everything else is up to yourself and your team. In TPS, the only thing that matters is your INPUT, your effort and the ingenuity you put into the system in order to freely but continuously improve output.

In TPS, your workflow is very bureaucratically watched, though you are free to change it however you wish so long as it objectively 'reduces waste' (and you leave it in a state that those following you can learn from). But while output is meant to always improve (in quality or cost) this is NEVER predictable nor are there ever any specific expectations about it.

Both Semco and TPS micromanage ONE thing and systematically leave the other as a free variable. But what they choose to micromanage (micro-negotiate really) and what they choose to leave free are opposites.

Finally, TPS works in a constant state of crisis whereas Semco works in a constant state of relaxation. And Semco feels like totalitarian anarcho-communism whereas TPS feels like benevolent cooperative fascism.

Generalizations

What I really want to know is what I can learn about political systems design from this. It seems like there's a very important lesson here. My hypothesis so far is that you need to micro-manage either the input or the output and stay the fuck away from the other so the people involved don't feel like you're turning them into robots.

But does that mean you must micro-manage one side or the other in order to eliminate corruption? And is there another way of splitting freedom vs authoritarianism other than input vs output? I suspect no. More likely, have I gone off the rails somewhere?

Ah yes I have. Already I see that micro-manage isn't the right word. The right-word is micro-negotiate.

Are the political lessons learned from politico-industrial systems even applicable to other kinds of political systems? I would like to think so since politico-industrial systems are particularly harsh and unforgiving. But the industrial aspect introduces an external reality which most political systems lack. At least, political systems other than China since China's obsession with industrializing means that it is, essentially, just an industrial company.

I still don't fully understand why one variable has to be left totally free. But it probably has to do with keeping a psychological comfort zone for workers to retreat to. No, not quite. In Semco it provides such a comfort zone from the external requirements of output. In Toyota there is simply no external requirement and no comfort zone from it - everything is input, intrinsic, internalized. And that's all negotiated in what I see now as a creepy way since you're negotiating your ego.

On "nobody's stopping you"

Every single time I make any kind of intelligent criticism about software, I inevitably get "why don't you do it yourself" and/or "nobody's stopping you". You don't get that with dumb criticisms since those just get dismissed quietly. But make an intelligent criticism, and you get that as a knee-jerk reaction.

That kind of lying garbage just infuriates me. First, it's double-speak. Like Americans ritualistically saying "I don't agree with what you say but will defend to the death your right to say it" when they mean "I respect your opinion like I do used toilet paper and declare this discussion closed". Second, it's not even remotely true.

As I point out in my last blog post on design principles vs engineering "principles", design is not engineering! Just because designers are capable of detecting engineering failures doesn't make them engineers. And like any good designer, I would rather slit my own throat than do engineering!

And just because I care to critique the shoddy engineering and mis-design of something doesn't mean that I want to design one myself. In the case of the Smalltalk programming language, I don't care to redesign it because I know it would end up like Klein. And I am a great designer, not some fucking hack who copies others' work!

Ultimately, what infuriates me most about suggestions that "nobody's stopping you" and "why don't you do it yourself" besides the blatant lying nature of the claim, is the fucking injustice of it all. When was the last time someone complained about a consumer product (say a brand of television or automobile) and was told "why don't you make one yourself?"

We live in a complex civilized society. And 'civilization' means 'city-builder' and the difference between 'city' and 'large village' is 'division of labour'. Look it up people, this is what these things mean to anthropologists and historians. You know, the people whose life's work is to analyze the difference between civilization and savagery.

So basically, these assholes are saying "why don't you act like a savage?' The only polite response to which is: what the fuck is your problem you crack-smoking punk?! Except I kinda know what their problem is already. They are too mentally handicapped to judge good and evil, so even though they've read everything I had to say, they still can't decide whether it's a good idea.

People who know some psychology tend to think it's because these morons have started identifying with whatever project and are feeling defensive. But that's bogus because it's impossible to react from your feelings alone unless your conscious mind is empty of thought. And in matters of good and evil, that happens when people are incapable of judgement.

And I'm not exaggerating. Asking "is design desirable?" and "what is design?" is a lot like "is goodness desirable?" and "what is good?". In other words, questions to which 90% of people are incapable of providing answers beyond what they've been indoctrinated by others to parrot. Questions to which 10% of the population thinks the answers are fucking obvious.

TOO obvious really. Only a special kind of person is capable of both independently providing the right answer to such questions and generating complete logically correct justifications for them. I've kinda got a track record of doing this now, what with 'what is life' 'why is pedophilia wrong' 'what is morality' 'what is moral theory' 'what is multi-leveling' 'what is intelligence' 'what is empathy' and 'what is design' now.

Design Principles vs Engineering "Principles"

So today I've had Newspeak programming language recommended to me a second time. On its web page the people behind it claim Newspeak is going to be "designed as a principled" language.

The big problems with that claim are first, I see no evidence of any design on that page. And second, nothing they talk about can be even loosely described as principles.

That page, and that language, are the results of typical Engineers' confusion of ... everything related to design. They speak of design when they are incapable of it. They speak of principles when they don't even know the meaning of the term. I suppose I'll have to explain exactly what the terms mean.

Engineers

It's sad that I have to explain the meanings of basic terms in the English vocabulary but I can't say it's unexpected given that I've had to explain how engineers' thought processes are different from, and inferior to, designers. And what exactly (spontaneous) creativity means that makes it blatantly fucking obvious engineers are incapable of it.

The first observation is that engineers don't operate in the realm of ideas. They are not intellectuals. They do not value ideas for their own sake. This is a straightforward consequence of the fact they can't synthesize original ideas. Why value what you can't do? It would hardly make you feel good about yourself. And so very few people care about the truth more than feeling good.

The question naturally arises, what realm do they operate in? Well, they operate in the realm of externally observable behaviours. They are actually proud of this and claim this makes them superior people when the truth is they are cognitively deficient. It's a bit like a paraplegic being proud of using a wheelchair and claiming there's nothing a legged person can do that they can't.

Engineers' Perception of Systems

What does any of that have to do with systems? Everything! Because engineers don't operate in the realm of ideas, they don't conceive of systems as being systems of ideas to be understood. To an engineer, a complex political, social or software system isn't to be understood. Rather, a system is merely to function. It merely needs to ACT in a certain way.

To an engineer, a software system that's been "architected" as a Big Ball of Mud (like Unix) isn't an obvious failure. Rather, one must determine whether or not the Big Ball of Mud is a failure empirically, by seeing whether or not it does what you want to do.

If the big ball of mud does what the engineer wants it, in his very limited imagination, to do then it's a success! And anyone who says otherwise by virtue of having a greater imagination is a "troll" (*) to be hated. And anyone who says otherwise by virtue of having a lower annoyance threshold is a "luser" to be scorned. And goodness help you if you're both!

Similarly, to an engineer, writing spaghetti code is not ipso facto a failure. Yes it's going to be unmaintainable, but this obvious truth is not at all obvious to an engineer. Rather, one must measure the maintainability of spaghetti code empirically. And if it happens that generally such systems are unmaintainable well, that's a heuristic. Something that happens to be true, most of the time, not something that is true axiomatically and/or proven from first principles.

Designers' Perception Of Systems

To a designer, the above is all so much unbelievable, ridiculous bullshit. It's all FALSE at every possible level of resolution. To a designer, a system is to be understood. And this fact is axiomatically true. If a system can't be understood then it's obviously either not been designed at all or been badly designed. This is the most obvious and simplest theorem of any and every designer.

Given this theorem, a big ball of mud isn't any kind of architecture for the exact same reasons why the broken down ruins left over from artillery shelling don't constitute architecture. It is fucking obvious! And for the exact same reason, spaghetti code can't be considered any kind of success. No matter how well it behaves. No matter how maintainable it turns out to be.

Any system that can't be understood is a failure! Automatically. Axiomatically!!

Engineers vs Designers

What it boils down to is that when engineers make "principles" about a system they're planning, these end up being of the form "everything can do X" or "everything has Y" where X and Y are concrete artifacts. Hence, "in Newspeak, every object will be an Actor". These rules may or may not be easier to understand locally, but almost always they make the system as a whole more difficult to understand globally.

Meanwhile, when designers make general rules about a system, they end up saying fuzzier things like "the system is homoiconic". Design principles are typically more difficult to understand since they are more abstract, usually fuzzy and never concrete. But they will always, always make it easier to understand the system as a whole. So, "everything is an Actor, hence the system is wildly non-deterministic" is NOT something that should be construed as a design principle.

This is why systems planned mainly or solely by engineers can't be considered designed. Let alone well-designed. Rarely has any effort been made to make them comprehensible as a whole. And any effort engineers have spared seems paltry compared to the obsessive focus a designer would invest. These systems also have a nasty tendency to be incomprehensible to anyone but an engineer. And then only by stepping through them laboriously. This is clearly unacceptable.

Design vs Engineering

The difference between design and engineering is usually waved away by engineers claiming that design is just interface engineering, but that just shows how engineers are incapable of grasping design. Design is a synthetic faculty. Engineering is an analytic one. If you want to see the difference, look no further than any house designed by Frank Lloyd Wright versus reading the Building Code.

It's actually something of a sick joke to claim that underlying local rules (what engineers call principles) actually are overarching principles. It just goes to show that engineers are incapable of the synthesis required to understand the meaning of the word "principle" in the English language. Principle means higher level and not more fundamental. These things are pretty much opposite.

Since there is an important difference between design and engineering. And since the difference is fundamental. And since engineers can't do design if you put a gun to their heads, even though they claim to be able to. And since designers can't do engineering if you put a gun to their heads, even though they claim it's beneath them and would slit their own throats if forced to. A decision has to be made between them to decide who has primacy over the other.

Who would you rather be the bitch of the other?

Who Should Plan?

Now this question has a rather important context so let's state it properly. If you're one of the end users of the world, and keeping in mind that even if you're a programmer then you use many orders of magnitude more software than you actually create, would you rather that engineers or that designers planned software systems?

Personally, I think there really ought to be a law that would allow any competent designer to shoot engineers whenever they get uppity. I think this is totally reasonable considering that good engineers are a dime a dozen and competent systems designers are rare as Archaeopteryx teeth. So just to equalize the massive imbalance in numbers between engineers and designers, you need to hand designers overwhelming power.

Actually, you would need to do this even if designers were plentiful since on any software project you need about 2 designers for every 10 engineers. Yet the few designers need to have as much input as the many engineers. Then again, if systems designers were plentiful, we wouldn't be living in a crapsack world (**) so probably the imbalance would redress itself without resorting to shooting assholes with delusions of adequacy.

*: troll: 1) a person who through sheer peevishness and desire to do evil says the world is less than perfect so as to harm the self-evident Harmony all humans enjoy with each other, with feral animals, and with natural disasters. 2) a person who challenges group-think. 3) a dissident.

**: Hmm, I guess this makes me a Knight in Sour Armour.

Mezzanine: Hyped Up Electronic Whiteboard

Tell me if this presentation means anything to you. They make a big deal of moving images between screens, which is of course the most stupidly derivative thing imaginable.

They say "optimized for big data sets and real time" as if this means something. Because if it means something to end users then I haven't the foggiest clue what it is.

Just like I don't have the foggiest clue what a "spatial environment operating system" is supposed to mean. My money's on it just being an empty meaningless marketroid-invented buzzword.

As far as I can tell, this is an electronic whiteboard. Of course, XEROX PARC has been playing with those things for at least a decade under the rubric of Ubiquitous Computing.

But no, this can't be an electronic whiteboard because it's supposed to be "revolutionary" and "the future of computing". Garbage!

As near as I can tell, this is totally useless hyped up prestige crap aimed at idiots with too much money to spend. So-called "executives" seeking expensive status symbols.

Just like the multi-touch was a status symbol for hoteliers.

OOUIs and Naked Objects

I was reading Erik Naggum's take on so-called "free software", a perspective I agree with entirely. It's interesting to see how his prediction has been borne out. Though I wouldn't go so far as to say "free" software has destroyed inventiveness, since I think C/C++ and lately Java have done more than enough of that. Annihilating inventiveness I mean, not being inventive!

But I agree with him that "free" software is entirely dictatorial and very, very far from free. And I even have a good idea how to remedy this. But that's not the point. The point is that it inspired me to check out the license for GNU Smalltalk since I was planning to maybe use it. Yes it has no GUI but this is a plus for me. No, it has no IDE, but I can get around this by porting from Dolphin. It's either that or Pharo.

The Point

Well, the license to GNU Smalltalk seems sensible, but that's not the point either. The point is that I started reading the documentation for fun. And I found this little gem in it:

The Smalltalk programming language is an object oriented programming language. This means, for one thing, that when programming you are thinking of not only the data that an object contains, but also of the operations available on that object. The object's data representation capabilities and the operations available on the object are “inseparable”;

And that's important because for years I've struggled with what the fuck is a "naked objects" UI framework. I've read about it. I think it's a fantastic idea. And this is an improvement over "OOUI" which I hadn't the faintest clue what the fuck it meant, although it sounded good too.

So I knew what a naked objects framework did, and I had some ideas on how it did it. But I never had an Aha moment and I could never explain in any principled way what it was about or why to have one. Yes, I understood the practical advantages well, but I consider such "understanding" strictly third rate. The pathetic bleating of people who are incapable of understanding anything.

So What Is It?

It turns out it's all very simple. Simple and yet profound. After all, it only took me years and dozens of design iterations to get it. An OOUI is one where representations belong to objects. So in OOP, code belongs to objects. And in OOUIs, representations belong to objects.

Now, this doesn't mean that each object has one and only one representation. That would be as ridiculous as an object having one and only one method. What it does mean is that the farce of "pluggable views" in the MVC (Model View Controller) paradigm is chucked away as so much lying garbage.

The whole notion of pluggable views is a sick joke and a lie. Not just because it's impossible in practice. But because it's not even desirable. Looking through your class hierarchy browser at some class and having not the slightest fucking clue how it represents itself ... this is Not Good.

Distractions

So anyways, I finally cottoned on to this ridiculously simple insight two days ago. It didn't help at all that the Naked Objects framework written for Java actually fails, totally and utterly, to heed this simple insight.

It also didn't help that so-called OOUIs are nothing of the kind. For one thing, people claim that Smalltalk has an OOUI but anyone who takes a look at Genera knows what a sick lying joke that is. There is no Smalltalk UI with Genera's abilities, and that's a really sad pathetic thing.

I would chalk up my view of OOUIs as an original invention except if Genera's UI is implemented the way I think it is, then it probably has it down. Or at least, that's how I invented it. By trying to imagine how I would implement the functionality I saw in that video of a Lisp Machine.

Now just think about this last paragraph and reflect upon it. An original invention ... replicating 30 year old functionality. There is something seriously wrong with the world when this can be said with a straight face.

On Meta-Leveling - Design Strategy #1

Importance of Formal Definitions

Like other commonly understood terms such as life, intelligence, empathy & morality, meta-leveling is easily understood and admits to many crappy semi-useful definitions.

Definitions which don't provide any useful insight into what the fuck the phenomenon actually is since they are fuzzy, slippery and squishy. This "wealth" of crappy inaccurate, incorrect definitions leaves people scratching their heads when boundary cases come up. As they inevitably do.

Are viruses alive? Most biologists don't know because they don't have enough insight into what life is. And they lack insight because they don't have a single fucking formal definition. Is having just one too much to ask? Mathematicians often work with half a dozen, and gain insight from each and every one of them.

Unyielding, rigid and formal definitions of common terms are exceedingly useful when you're pushing the boundaries. When you're not content not-thinking the same crap every other group-thinking moron is not-thinking about. And I'm not talking about average people here, I'm talking about academics who supposedly are intellectuals.

What Is Meta-Leveling?

Well, you've just had a fine example of it above. I intended to write an article about a formal definition of meta-leveling I developed a few weeks ago. It's in my mind now because just yesterday I developed a definition of transcending.

But before getting into a formal definition of meta-leveling, I thought it would be important to get straight what it is in the first place. And then I realized it was even more important to explain why a formal definition of meta-leveling is important.

What is meta-leveling formally? It is making a complete model of a system and then annotating the model by determining its most important elements. Which are almost always the elements with the greatest freedom of output.

How To Meta-Level

Okay, when I say model, you can forget UML or any other such crap. You'll see why in a minute.  You can also forget functional modeling since that only works for mathematicians. 90% of human beings are better suited to OO since human brains prefer SVO word order to VOO. So pick up Object Oriented Systems Analysis by Embley, Kurts  & Woodfield. It's available from Powells and of course Amazon.

Meta-leveling is nothing more than creating a complete OOSA model of the system whose parts you're thinking about then annotating the model. It's based on those annotations that you decide what parts of the system to think about. Because some elements (objects, relationships or interactions) are more free in their output than others (they're generally the ones that control the system).

Other elements contradict each other in the system. There may also be contradictions between elements and the system as a whole. There may be overly complicated elements that can be simplified. Or made weaker, or made stronger, or made more general, or more flexible, or more restricted depending on your concerns. There may be objects that can be unified together.

Meta-leveling is the process of creating this OOSA model and annotating it with all of these descriptions. Ideally, you do all this in your head without relying on paper. Or even conscious thought. So if you're talking about some objects in the system with someone but one of the other objects in the completed model is more worthy of attention and consideration then shifting the conversation to those other objects is said to be meta-leveling. The beginning of this essay is a good example. I had no outline nor any plan, the shift just popped up from my subconscious.

What Meta-Leveling Is For

Meta-leveling is known as Judgement in Bloom's original taxonomy of cognition. It is the highest form of cognition, one which not all people are capable of. It is also known as Evaluation. Judgement is the capacity to distinguish not just right and wrong (fitness to a predetermined goal) but good and evil (determining the goals themselves). Strictly speaking, judgement is broader than determining good and evil. It's just that 

Eliezer Yudkowsky makes a big deal of recursion. In planning, recursion is not just considering your goals and plans, but the other players' goals and plans. And in double recursion, you assume that the other players have considered your goals and plans, so you account for that as well. Well, meta-leveling is so much more powerful than recursion that it makes recursion look like a weak pathetic thing.

After all, meta-leveling was the crucial step required to go from playing a game using rules to playing against the other players. Recursion is nothing compared to meta-leveling since it stays on the same level always. Eliezer Yudkowsy harps on recursion because he is incapable of meta-leveling, because he is incapable of synthesis.

By meta-leveling the first time you go from playing the pieces of the game, to playing the players in the game. By meta-leveling a second time, you change the game's rules, outcomes and players entirely. It's like going from playing against your opponent in chess, to playing 3 dimensional fantasy chess where the winners are the best 3 cooperators out of 5 players.

Meta-Meta-Leveling

Meta-leveling twice in a row is called transcending. The first meta-leveling step gave you a model of the system and identified its most important elements. The second meta-leveling step gives you all the ways this system can evolve in future, all the forces that direct its evolution, and the entire space of possibilities for you to redesign the system. Transcending a system means to redesign its entire architecture so that it is no longer recognizable as the original system. It is not an improved system, it is radically different and better.

On reflection, my definition of meta-leveling isn't nearly as formal as I'd like. Meta-leveling is not just creating a model, it's annotating it. Doing it a second time is creating a super-model and annotating that. I didn't make this correspondence explicit enough. I also didn't point out that every time you model (or meta-level) you make things more generic, more abstract. Now there are multiple types of super-models but this is exactly as it should be since there are multiple aspects to any system. Every real system admits to multiple models, and every model admits to multiple super-models. Mathematicians ought to be very familiar with this.

In particular, if you create a model in the OOSA style then the OOSA book is one possible super-model. It's not a very interesting super-model (or form of transcending) so don't waste your time on it. If you didn't use the OOSA style but just did it in your head, then a model of your mind is the super-model that replaces the OOSA book (and a theory of the human mind replaces the endnotes of the OOSA book). That's at least more interesting than the book. What I described at the beginning of this section is a reliably interesting type of super-model for a systems designer.

It now seems dubious to me that there can be more than two types of meta-leveling. The first goes upwards to the conceptual space. The second goes upwards to the realization that contains the concept. What else can there be?

Meta-Meta-Meta-Leveling

By meta-leveling three times in a row, you leave the system entirely behind you to enter into the realm of generic systems design. If the level is chess, the meta-level is a rulebook on chess and transcending is fantasy cooperative chess, then meta**3 is talking about the nature of meta-leveling and how important it is for systems design. In other words, this blog post.

Which reminds me, meta-leveling and transcending are the #1 and #2 tools of any systems designer. If you can't do them then don't even bother. Another crucial tool is empathy. Now, the really funny thing is that empathy's formal definition is: the capacity for formation of other-identities (to complement self-identity). Psychopaths are incapable of this, probably because they lack a crucial form of synthesis.

Multi-Leveling

Now what makes this funny is that formation of identities for others is ... meta-leveling. What Dabrowski calls "multi-leveling" (formation of a complex and utterly accurate self-identity) is ... meta-leveling your own mind. Empathy is just ... meta-leveling other people's minds. So you see, the top three tools of any systems designer are meta-leveling any system, meta-leveling twice in a row, and meta-leveling human minds. Hmm, I sense a pattern here. It's almost like meta-leveling is important.

Incidentally, Dabrowski was incapable of multi-leveling or meta-leveling, which is why he didn't have any insights into the process. He never realized that multi-leveling was meta-circular (the whole of the meta-level exists as a subpart inside of the level it describes) or that it was related to consciousness (which is also meta-circular). In fact, he never understood multi-leveling as the formation of a complex and accurate self-identity. Beyond identifying that the process existed and that it had something to do with ethics and integrity, he was in the dark about it.

Dabrowski also made up the crappiest theories about the nature of Development Potential (people who can multi-level). But his estimation of less than 10% of the general population capable of multi-leveling sounds about right. Of those 10% less than one tenth are naturally prone to multi-leveling because they use their synthesis more heavily than their analysis. Synthesis is what drives the process after all, while analysis just keeps it in check. These one or two percent of the population will try to meta-level everything they come across.

Who Can Meta-Level?

It's not every person that can meta-level. The process can be described so that any person capable of logic will be able to follow it, but it takes synthesis (creativity) to actually do it. Engineers and mere programmers for instance, will never be able to meta-level. So why bother describing it? So that I can say in your face you pretentious assholes! Because they claim to be able to do synthesis and the truth is, they can't.

Meta-leveling is the province of people capable of both synthesis and analysis. It takes synthesis to create the original concepts and it takes analysis for those concepts to be both correct and also to keep the meta-level strictly separate from the level. People lacking in logic are prone to thinking the map is the same as the system it describes, that by changing the map, they change how the system works. This is literal magical thinking.

But let's set aside the pretentious fuckers who can't meta-level but desperately want to be thought of as just as good as those who can. For those who possess both analysis and synthesis, and thus CAN meta-level, the whole process of meta-leveling is something that can be learned and practiced.

Skill and Talent

Of course, a person will show skill at meta-leveling only when they can do it subconsciously. When they have no need to draw out the diagrams on paper at all. This is why I said UML software is worthless. If you need computer software to help you meta-level, you're hopelessly incompetent. And then of course there is the question of talent. Let's say that a person shows talent only if they're able to meta-level subconsciously before ever learning to do it consciously.

If you're able to skim the first couple chapters of Object Oriented Systems Analysis by Embley then flip to the endnotes (where they have a formal OOSA model of the OOSA modeling formalism) and make sense of them then congrats, you've got talent. If you're able to read that book and this article, then think back to how you were meta-leveling years ago as an adolescent, then congrats you've definitely got talent.

And if you haven't got talent at it, then go back and reread the previous section where I go on about how the overwhelming majority of people will never do it in their lives and couldn't do it even if there were a loaded gun stuck to their heads and their lives depended on it. Be glad that you can do it at all. Be glad you can learn. Be glad and appreciate your cognitive gifts.

And if you can't meta-level at all? Fuck off.

Kinect Is Useless

Aha! It took a long time but I finally figured out that Kinect is useless. I blame having just woken up.

Gesture languages are just castrated forms of sign languages, which are full-fledged langugaes. And sign languages are useless for people who aren't deaf. So gesture languages are useless. QED. I've known that for years now.

Oh and they also make you look retarded, take a look at the photo of the three retards behind the conference table in Google's Gmail Motion for proof. Google seriously thinks this photo will help sell this piece of crapware. "more efficient and intuitive" my ass!

Conceptual Analysis

The problem is that it seemed Kinect had more. And it turns out the "more" bit, the part about moving stuff from device to device "with a flick of your fingers" can be done entirely without flicking your fingers.

All it requires is a good UI, one that provides an extensible spatio-visual field. So that your computer exists in a space represented on its monitor and other devices exist as extensions of that space. That's the basic conceptual mechanism underlying "moving stuff from device to device".

Note that this conceptual mechanism does not in any way rely on fingers or hand motions or body motions or "multi-touch" (ugh!) or anything of the kind. It can be achieved with the mouse, which is a perfectly usable pointing device.

A device far, far more sensitive than that crappy fucking piece of shit Kinect that requires you to move your hand 15 centimeters for a gesture. Seriously, what the fuck? Those ergonomics are atrocious!

You see, when you break things down at their conceptual level, you've got a conceptual mechanism + hardware, and those are independent. Kinect provides the hardware only. And this hardware sucks for ergonomic reasons.

If an input device like Kinect ever acquired sub-centimeter resolution then it would compete directly against the mouse and could be superior to it. But I predict that such an input device won't use (because it won't need) shitty gimmicks like gesture languages.

It's a similar analysis that reveals that touch screens absolutely suck for general computers and laptops.

It's another similar analysis that reveals multi-touch is useless. I mean for fuck's sake, in my design work I've come up with two pointers and am struggling to have any kind of justification to have more. I don't have any use for multi-touch.

It's another similar analysis that reveals that mouse buttons are useless so mice should really have zero buttons. Because the mouse can never support as many buttons as the keyboard (ergonomics) and the keyboard is where buttons belong (conceptually)!

The Fundamentals

The basic problem with input devices is this:

• you've got your discrete events device - the keyboard provides zero dimensional input
• you've got your continuous 2D device - the mouse provides 2 dimensional input

what's left?

Adding buttons to mice doesn't improve them because they shouldn't have any buttons at all. Mice shouldn't generate discrete events at all! It is a defect in UI programmers' imaginations that has made users associate so-called "mouse events" with mice.

Laser mice are a great change to mice hardware but they don't change what the mice does conceptually so it's evolutionary, not revolutionary, to users. To hardware designers, laser mice are of course revolutionary.

Multi-touch is having 2 or 3 times the already existing continuous 2D device. And you can achieve 90% of the benefits of that by having an easy way to switch off between multiple pointers. Chasing that remaining 10% is just not worth the effort - you end up "needing" it only for gimmicks.

Touch screens are just 2D continuous input devices with horrible ergonomics. Interesting in theory, useless in practice. You need something as bizarre as the iPad where the proportion of input to output activity is miniscule (eg, restricted to flipping pages) to make touchscreens viable.

1D continuous input is ... provided by the scroll wheel. Hence that is revolutionary from the user's point of view! So now we have in the present situation

• a 0D input device - the keyboard
• a 1D input device - the wheel
• a 2D input device - the mouse

What the fuck more do we need?

The False Need For 3D

In certain rarefied applications, we might desire a genuinely 3D input device. These (eg, ringmouse) haven't panned out because of technological problems with resolution. Hmm, poor resolution, does that sound familiar?

The bigger problem with them is that their applicability is extremely limited. Because the visual cortex of homo sapiens sapiens isn't 3D! It's strictly 2+1D, like a topographical map or bitmap. Which is exactly what the wheelmouse provides!

Except for a few freaks, human brains just don't process 3D data. We don't see in 3D (you can't see the inside of a box and its outside simultaneously), you don't think in 3D, you don't visualize in 3D (go ahead, try to visualize all sides of a solid box at the same time), you do nothing in 3D except move your body. You do everything in 2+1D.

Is it any wonder then that anyone wanting to push 3D input devices resorts to proprioception? To moving around and dancing with your body? Even though moving around your body has fuck all to do with any computer game or software application out there? Yeah yeah, it looks great. And you know what? Fucking useless!

Look at the video of Kinect users in the first article I linked to. Do you see any game or application in the video? No. Because the peddlers of this tech couldn't imagine anyone actually using it for anything exciting so they didn't bother to make a rigged demo. It's exactly like I said - it looks great but it's fucking useless.

The challenge for input hardware designers is that input hardware is already perfect. Excepting only that slanted QWERTY keyboards are fucking horrible and Kinesis contoured keyboards are vastly superior. Well, that's a legacy problem and a patent problem. The patent may have expired but it's been there holding up progress for a long time.

And while I'm at it, 3D output hardware (holograms and phased array optics) are also useless for individual users. They only come into their own in holodecks where multiple users can interact. Otherwise, virtual retinal display is plenty good enough. Or I suppose if you want to drive what the user sees with natural head motion without inducing nausea.

Summary

Like touchscreens, 3D output hardware is of limited applicability. Great when you absolutely need it, terrible most of the time. Like automatic kitty lasers, 3D input hardware is completely fucking useless. We don't really need 3D because the human brain just doesn't process it. We need inspired use of 2+1D. And this isn't going to take better technology but better systems designers. Unfortunately, we're pretty good at the former and terrible at the latter.

Programmers Show No Empathy

I will prove here that programmers have all of the expressed empathy of the typical serial killer and psychotic mass murderer. This will be remarkably simple since programmers consistently misrepresent everything in the real world in the way that most blatantly benefits themselves.

To programmers, colour isn't what you see when you turn your head 30 degrees to the side of your monitor. Or 15 minutes after you leave your computer. Rather, colour is light values of phosphors in CRTs.

To programmers, a document isn't an ordered sequence of paragraphs with annotations, titles and owners as almost-perfectly exemplified by this online magazine. Rather, to programmers, a document is a sequence of ASCII characters as in notepad.

(Do check out the magazine linked to above if only to behold the magnificence of paragraph numbering. At last someone of minimal intelligence replaced the ridiculous 20-year obsolete concept of "pages" for online documents. Check out also ... sidenotes! Unfortunately fixed-length but hey show me another site that has them. And you can also change the font size without a fugly dropdown menu or modal << >> buttons.)

To programmers, music isn't a smorgasbord of sound produced by skilled artists conveying their emotions and telling a story. Rather, music is an ordered sequence of 1/8th notes from disconnected recordings as in MIDI.

To programmers, sheet music isn't a means of reminding a skilled artist what to play in a concise, elegant, visually pleasing, and easy (non-busy and non-boring) manner. Rather, sheet music is an ordered sequence of 1/8th notes on a staff.

To programmers, a date and time isn't a plethora of different measures in all sorts of different calendars tied to the rotations and revolutions of various astrophysical objects. Rather, date and time are the integer number of elapsed seconds since Jan 1st 1970.

To programmers, a timezone isn't a consensual and variable means of synchronizing arbitrary clocks to solar days observed at specific geographical locations. Rather, a timezone is a one digit offset from GMT.

To programmers, money isn't tokens of economic exchange taking different forms in different countries, exchangeable between each other according to dynamically varying ratios. Rather, money is an integer number prepended by a $ sign. And ratios between forms of money are always unitary and symmetric (ie, currency controls do not exist).

To programmers, languages isn't something people know one or more of, in order of preference, from a space of possibilities weighed by global popularity and grouped by geographical commonality. Rather, languages is a flat unstructured one-dimensional list organized alphabetically from which you are munificently allowed ONE option. The list is written in English using ASCII of course.

To programmers, an architectural object such as a pipe isn't something with mass, composition (including but not limited to strength and durability), maybe even price and availability. Rather, it's a bunch of lines and planes in a CAD program, and this has been so for nearly 50 years until the very recent emergence of object-oriented architectural modeling software.

To programmers, the terms 'geek' and 'nerd' don't refer to self-obsessed idiots too mentally deficient and deranged to be able to relate to any person different from themselves. Relating to entirely different people the way a real intellectual must. No, a 'geek' or 'nerd' is a sort of champion of what being a programmer is all about and is supposedly intellectually superior.

To programmers, being called a geek or nerd isn't a source of shame that programmers are second only to psychopaths in the category of worst dregs of humanity. And then only because it's difficult to beat American executives and serial killers using the measure of 'worthless scum inimical to humanity'. Rather, being called a geek or nerd is a source of chest-thumping pride.

I leave it as an open question whether programmers fail to express any empathy due to debilitating mental deficiency or because they actually are psychopaths. I personally extend them the benefit of the doubt that they need not all be put to death to safeguard humanity as would be the case if they actually were psychopaths.

Some people may not believe it but I scrupulously extend people the benefit of the doubt. The problem is that there's so little doubt from which any of you monsters can benefit from.

Systems Designers Cannot Bloom Early

I've found the youngest systems designers in the past century bloomed in their 30s which is an interesting observation. Today I recalled an article about artistic geniuses - some of whom bloomed early and some of whom bloomed late. The early ones had conceptual breakthroughs but it's obvious now that complex systems can never count as simple concepts. So systems designers cannot bloom early because it takes a complex mind to create revolutionary complex systems. Interesting that there's a logical explanation behind the empirical pattern.

This immediately raises the question of what systems designers get up to in their incubation period. The answer to that is both "not much" and "learning about the world, themselves and systems" in conceptual ways that are anathema to academia. And it's pretty obvious to me that the more and earlier they're forced to "produce", the less they'll actually learn. The more society forces systems designers to be "useful" during their incubation period, the more twisted and stunted they'll become. And so the less they'll actually produce over their entire lifetimes.

Nikola Tesla is a great example of a stunted systems designer. Throughout his life he managed to create only 4 complex systems - the AC generator, radio remote control, wireless power transmission, and bladeless turbines. Notice any pattern? All of his achievements were squarely in electrical engineering or just one step removed from electrical engineering. What about philosophy, politics, architecture, psychology? He knew nothing of these subjects and he contributed nothing. Tesla's gifts were squandered by a mean hateful society and his contributions to the world stunted.

This world is run by mental incompetents and others totally lacking in creativity such as engineers and programmers. Their constant demands that more talented creative people "produce" according to their standards and their schedules have ruined all of the creative geniuses in this world. The people who could have been uplifting human civilization were all systematically destroyed by egotistical self-important talentless pricks who then proceeded to pat themselves on the back for it. Because they couldn't stand the existence of people more gifted and talented than they themselves. People with gifts and talents that they, the engineers and programmers and other such uncreative pricks, were far too mentally incompetent to see.

You can't force a systems designer to grow, they must incubate. So if you ever see a bright young thing who's creative and logical and intellectual but is "just wasting their life" ... BACK THE FUCK OFF!

You know, there are times when I wish I could just destroy the enemies of humanity. Unfortunately, that's 40-80% of the human population.

Smalltalk: the Software Industry's Greatest Failure

Every time I think about the miserable state of the software industry, it always comes back to one thing: the Smalltalk programming language.

The failure of the software industry is the failure of its greatest tools, the programming languages and operating systems. The failure of programming languages is the failure of the only natural and useful programming languages, the OO languages. And the failure of OO languages is the failure of the only OO language worth speaking of, Smalltalk.

Programming languages started with the imperative paradigm but they rapidly bifurcated into two mutually contradictory paradigms - functional and OO. Once the bifurcation was complete, the imperative paradigm ceased to have any importance. Beyond being a tool of mentally incompetent brainwashed morons and those desperately maintaining obsolete code of course.

The functional paradigm rejects all notion of modifiable state and orders everything around verbs so that all sentences are verb-object-object. The functional paradigm rejects state and objects so violently that it denies subjects exist. As a direct consequence it is blatantly unnatural to the human brain, contrary to physical reality, and contrary to human consciousness. Only math lovers find the functional paradigm attractive or useful which makes it useless to the rest of humanity.

The object-oriented paradigm is dominated by Smalltalk. Java for example doesn't even remotely qualify as object-oriented having been conceived as a deliberately inferior and broken pseudo-OO version of Smalltalk. The problem is Smalltalk is a failure as an OO language and has definitely not passed the test of time. And I'm not talking about popularity either. I couldn't care less about popularity of programming languages among brainwashed mental incompetents.

The failure of Smalltalk is two-fold. First, the fact that its rules are at least twice as large as they need to be. Because for every general rule of Smalltalk that someone has to assimilate in order to master the language, there is a specific rule (an exception to the general rule) that must ALSO be memorized. There are 8 such exceptions and they are:

1. variables are not objects - you can't create a variable at runtime by having 'thisContext addVariablesNamed: #('name1' 'name2' 'name3')' and | name1 name2 name3 | is not simple syntactic sugar for the previous code, as it should be. Nor can you send messages to a variable to query when it was last read from or written to.
2. the existence of variables is bound early at compile time, not at runtime - if you try to compile a method with an undeclared variable, it triggers a compile time error, not a runtime error (and compile time warning) like it should.
3. assignments and hard returns are not messages - you can't #perform: them and 4 := 3 doesn't trigger a #doesNotUnderstand: on the basis that 4 isn't a variable.
4. the unary, binary, and keyword order is not how the compiler actually evaluates anything. So in weird cases that happen 0.1% of the time, this simple rule is broken in favour of something so complicated I can't even remember it. Why? So the compiler can make a single pass instead of 3 or 4. But who gives a shit how fast the compiler operates? Other than compiler writers, literally no one.
5. #at:put: doesn't return self - collection #at: name put: object returns the argument 'object' rather than what every other method in Smalltalk would do, which is return 'collection'. And this has been empirically proven to be harmful. Another example of the language writers creating an optimization that no user wants and every user has to work around.
6. on object creation, the #initialize method isn't sent by default so you need to override #new so it sends it - this is inconsistent with the fact Smalltalk presents meaningful nil values for all instance variables in a brand new object.
7. when a collection triggers #grow (which happens at random) it won't copy over every single instance variable it has, just some completely arbitrary subset of them. So subclassing any collection class won't work unless you fix this yourself. And students who are taught to do this are rarely taught to do it properly by walking over all instVars.
8. the compiler cheats with True and False by inlining them. If you try to subclass or redefine them, it will not work. This is actually the only flaw in Smalltalk that makes any sense at all.
9. there is no infinite object cloner out of the box. You're stuck with deepCopy which is arbitrarily limited.

The second way that Smalltalk is a failure is that it was woefully incomplete when it was standardized and it got extended by incompetent hacks rather than competent systems designers.

The three biggest areas of this failure are

1. Smalltalk is not homoiconic the way LISP was and is
2. the event system is not debuggable
3. the UIs are blatantly not OO - Squeak's Morphic is so messed up it doesn't qualify as an OOUI

The lack of homoiconicity in Smalltalk is perhaps its greatest failure since it has meant that many vital extensions to Smalltalk were rendered impossible. Smalltalk has none of the capabilities security nor modularity of any modern OS and I believe lack of homoiconicity is at fault.

Smalltalk would have made a great operating system if filthy hackers hadn't completely failed to grow it within its object-oriented paradigm. And so it becomes obvious that the failure of Smalltalk is a failure on both counts - as a programming language and as an operating system. So the failure of Smalltalk really does underpin the failure of the entire software industry.

Oh and just for the record, the reason Unix and Windows aren't failures is because abominations can't fail to be travesties. Nor is their success measured solely in terms of how many fanatical masochistic cultists they've accumulated or how many victims they torture. Rather, their success is measured by the numberless violations of logic, common sense and human freedom they enshrine.

By their own measures, Unix and Windows are both the wild successes they've always been intended to be. But Smalltalk was never intended to be horrible to human beings. It wasn't even intended to be bad for people. It wasn't even intended to be good. It was intended to be perfect and to uplift the entire software industry. And it failed.

Explaining Software Systems Design To An Industrial Systems Designer

There is a superficial similarity between the jobs of a software and industrial systems designer but it disappears when you look closer than a job advertisement because the software systems designers are just going through the motions of their industrial brothers. What you have to appreciate is that three key elements are radically different in the software developer's environment.

Let me start by pointing to an advertisement for a software development company. It's obvious that EDS is quite proud of what they do. It's equally obvious that you as an industrial systems designer can see, or vividly imagine, the uncomfortable and horrified looks of EDS customers. You might want to think about what it says that EDS is proud of working in ways that would terrify any remotely sane person. I see in them complete disconnection from reality, from their customers' needs, and also from any kind of personal emotional health.

Inadequate Tools

Firstly, the tools are all inadequate and there is no objective way of measuring their inadequacies. If one of your machine tools blew up once a year killing its operator, this would be obvious and measurable. Similarly if it emitted noxious gases through 10 different ports resulting in either lots of tubes going out of it or workers choking to death on the factory floor. Similarly if it took up 20 times the volume allocated to the entire factory or turned its input into slag.

The equivalents in software are never obvious and rarely measurable. The only thing that's ever obvious in software is when your tool causes a nuclear explosion the moment it's turned on. Or completely fails to do anything at all. Your software tool merely turning half of itself to slag the moment you turn it on isn't obvious. And come to think of it, your software tool completely failing to do anything at all is only usually obvious.

Destructive Traditions

Secondly, it's traditional for the customers to provide not just worthless but actively destructive specs. Have you ever had a customer demand that all of the tools you use be branded Braun? In the software world, they do this as a matter of course.

Customers hire a software consultant to create a spec because they don't trust the programmers they're going to contract with. And they are correct since programmers are egotistical pricks uncaring of customers OR users. Well the problem with that is the consultant is just another programmer (a machinist) so he's incompetent at any kind of design. So the very first thing he specifies is the programming language that'll have to be used. Usually this is C++ or Java because they are mainstream.

This is the equivalent of specifying that you are going to buy all your parts from Canadian Tire. Because it's mainstream. And because finding people to service the parts from Canadian Tire will be easy. I am not exaggerating, this is word for word their rationale.

They are not concerned that the parts are low quality. They are not concerned that the parts will break down because they aren't durable. Or that they have a terrible MTBF. They are not concerned that using these parts will make the machine more expensive. They are not concerned that neither systems designers nor machinists (programmers) WANT to work with these parts because they are terrible, hard to work with, and break your fingers.

No, the only thing that matters is that they come from Canadian Tire because everyone uses Canadian Tire (so it must be good!) and Canadian Tire is mainstream. Again, I am not exaggerating in any way, shape or form as I believe my analogy is exact.

Recall the first point above, there is no objective (let alone obvious) way of measuring the inadequacy of any software tools or parts. Thus, the customers demand the parts be from a popular store. You certainly can't be trusted to decide what tools and parts you want to use!

Malleable Reality

Thirdly, software is made of pure information which unlike matter is infinitely malleable. Software is also a lot more complex (which feeds into point #1 above, making errors undetectable). Let me put it this way. Physical matter occupies only 3 spatial dimensions, yes? Software occupies N dimensions where N is variable and ill-defined. And if you understand the term 'race condition' then you know that's not a happy thing.

Also, with physical matter you only deal with a small finite number of interactions. Heat flow, friction, momentum and impulse, compression, tension, shear, viscosity, chemical reactions, electric and magnetic forces, optical and sound waves. With software, you define interactions out of your own imagination. And if programmers have agreed to operate in a consensus reality with a set number of interactions, this is just convention. Or I should say conventions PLURAL because I know of at least three mutually inconsistent sets of conventions (Imperative, OO, Functional) in widespread use.

(Going back to point #2, can you imagine being told "Today you will be using the following laws of physics. I know literally nobody likes these laws and you personally hate them because you think they make terrible machines. but they are the Industry Standard and so that's what you'll be using. Just be appreciative of how much better they are than the Industry Standard of 10 years ago!")

Now, consider how your job as an industrial systems designer would proceed if you could decide to change the laws of physics your machine operates on. Or you could decide to build machines that operate on multiple mutually inconsistent laws of physics (which is what C++ is by the way). So a guy comes up to you and says "we want a machine that makes cars, here's the spec of the cars we want and the volume the machine must take and the input it can take per car" but YOU have the power to change the laws of physics so they were anti-gravity cars capable of space travel. The problem you see is that the customer simply isn't capable of even IMAGINING what you can do.

Your Customers

So the customers you actually get fall into two categories. Customers with very narrowly defined needs who want cars that ONLY travel on the ground on LEGALLY DEFINED roads and cannot fly and cannot teleport and aren't bigger on the inside! And then you've got more typical customers.

Those are the customers who come up to you on the first day with a request asking for a car. Then the second day they tell you it'd be a great thing if it could fly. And on the third day they ask you if you can make it teleport home when they're done with it so they can save on parking. Which of course you CAN since all you have to do is jack in a guild navigator hopped up on spice melange to it. And the guild navigator isn't a problem because you can make it bigger on the inside.

Unfortunately, those aren't the only customers you get. Quite often you get bitchy customers who insist on a narrowly defined set of requirements. And the next day they insist on adding to the requirements so the car can fly. But all this time they insist you ONLY have the system do what THEY want. So basically they're your typical fascistic micro-managers except they don't have the common sense to realize micro-management is wrong and will ruin your work.

If you're a great systems designer and you kept in mind the need to BE FLEXIBLE from the get go (after having double-checked that your project isn't one of those very few with very narrowly defined needs, of course) then the very best customers are those who are laid back and don't give you any requirements beyond "automate what we're doing" or even better "help us do our job". They let YOU figure out what THEY need. Those are great customers and the products you come up with their help are fucking awesome.

Not nearly as good are customers that give you a sheet of requirements but don't look too closely when you throw it away. Those are problem customers because they make it difficult for you to figure out what their real requirements are because you can't admit to them that what they gave you is useless and you barely glanced at it.

The customers that try to pretend you're an industrial systems designer and they can give you a full set of requirements when they patently can't ... well they're the ones that make the job of software systems design hell on earth.

Conclusion

In summary, being a software systems designer means you can warp the laws of physics more easily than God but the only machine parts and tools that have ever been created all have sensitive spots that cause nuclear explosions if you touch them. If you're extremely competent then you'll pick unusually durable machine tools and parts that have extremely small nuclear triggers. Assuming your customers will let you since most of them insist you buy everything from Canadian Tire.

So yes most so-called "software systems designers" (by title) do the exact same tasks that you do. But with none of the same constraints and none of the same results because they operate in a radically different environment. And often they don't really care about that because they see YOU doing a GREAT job in the industrial sector so they think they can copy your success by going through the same motions. Kinda like Vanuatu tribesmen inviting cargo planes to return by building bamboo control towers.

So getting back to those copious ads you see for "software systems designers". If you examine them very closely I'll bet you'll find stuff like "must have 5 years experience in Java Enterprise" which translated means "must have 5 years experience shopping at Canadian Tire". Now consider what such an advertisement means for 1) the employer that put up the job posting, 2) what the actual job is going to be like, and 3) the kind of person that's going to be attracted to such an ad. Because I can tell you that such ads turn me completely off so my guess is they're looking for a skilled yet unusually arrogant & outspoken machinist to represent them to customers.

How To Punish PKs In A Fun Way

The more I read of http://mu.ranter.net's articles about multiplayer game design, the more I conclude the guy is utterly incapable of producing a novel or original idea. He is miserably incompetent as a game or any other kind of designer because he lacks synthesis and judgement. The fact he pontificates about game design theory when he lacks the very cognitive faculties that are necessary to be a designer makes him a pathetic moron.

A case in point is his idiotic proposal for solving the problem of Player Killing players in MMORPGs.

So the logical response in an MMORPG to the presence of a known criminal is to dispatch groups of NPC cops to hunt him down.

NPC cops? How illogical! This just gives the bored user more opportunity to get into interesting and challenging fights without any trace of guilt. Far better would be to have a sheriff NPC who hands out quests for the heads of criminals for PCs to collect and hands out magic compasses that point to the criminal’s location, as well as warning them about the class and level of the target. Quest rewards would give out copious XPs and gold.

And after the criminal is caught you can have a prison (a day’s lockout) for the criminal with a suicide option (with the standard penalty for resurrection). That way you punish bored PCs who misbehave with even more and longer boredom OR with an unwelcome stat penalty. Better yet, make it so the prison doesn't count offline time. When the player logs off while doing prison time, they actually manage to escape. And when he logs back in, the guards dragged him back to prison and slapped an additional penalty for escaping. Or hey, for more fun you can have escaped convicts be hunted down AGAIN.

And if the criminal is so bored of watching messages like "another day passes, you scratch another line on the wall of your cell" repeat then he can suicide in his cell. The problem with that is it leaves a corpse so if they do that (or if they're killed during an attempted capture) then their shrunken head could be sold on the open market to make voodoo dolls. Voodoo dolls that work! Maybe have a voodoo doll to shrink the convict or paralyze them at a critical moment. Or maybe to summon them arbitrarily. Basically to fuck with them and make them miserable and regret ever having tried for a life of crime. The point of all this misery is to make letting yourself be captured the preferred option if escape isn't viable.

But even more important than discouraging and punishing criminals is that for every bored PC who turns to crime, you can interest 5-10 PCs to catch and/or kill him. That way anti-criminals have MORE FUN than criminals. Contrast this with ranter's stupid idea where NPC cops reward bored players who turn to crime by providing attention to them!

But even more important than that is the fact ranter doesn't see it as any kind of a problem that the computer or GM comes swooping in to steal all of the fucking limelight from playing characters. What kind of a pathetic excuse for a game designer is he when his solution to a problem in the game world is for the programmer to have fun by stealing all of the fun which players could have had?!

Death of Graphics Art Market Predicted

Isn't it funny how the audio art revenues are collapsing even as the visual art revenues are expanding through the same digital technology? Meanwhile, both of their costs are plummeting. But the reason behind these opposite outcomes is obvious when you think about it.

Audio playback technology is far in advance of video playback. Ordinary people can LISTEN to an arbitrary master audio song (CD), but they can't as easily SEE an arbitrary master image. Only a publishing house can do that by printing a large format poster. With an incredible amount of lag and expense involved of course.

Additionally, compared to video, there's hardly any artistry or skill involved in producing audio art anyways. Even compared to 2D video, let alone 3D, and 4D. But then again, audio is maxed out at 2D. So a lot more people are involved in producing it and amassing a public library of audio art that covers the entire space of possibilities (all the music you'll ever want to hear) is so much easier than for video art.

Of course, the conclusion is inescapable - cheap, thin & lightweight wall-sized video displays will collapse the digital graphics market, destroying the entire revenue base of graphics artists. I await this technology eagerly as that will be the day when ridiculous notions like hoarding art will die.

Hoarding by so-called "collectors", a euphemism for a vile activity performed by the rich, much like other euphemisms such as "adventurers" (for useless lay-abouts) and "philanthropists" (for public policy autocrats).

But it's not just ridiculous things like canvas paintings or the whole notion of "framing" art that will finally die. Copyright will also get its long-awaited and eagerly anticipated final death. Because when copyright no longer can be forcibly imposed on music or novels or graphics, it will apply to nothing at all.

And when the ridiculous and anti-progressive notion of copyright dies, it will become obvious that ALL art must be produced on a communist basis. From each, according to his ability; to each, according to his needs. Because the alternative is that art not be produced at all, something fascists will no doubt contemplate before regretfully abandoning it. Copyright's death will be communism's triumph.

A further conclusion is now inescapable. The anti-human anti-progress patent system will collapse when 3D printers become widespread among the general population. Or in general form, when technologies are democratized and universalized, arbitrary authoritarian restrictions on them (like copyright and patents) are no longer tenable. Or put in even more general form: democracy is the enemy of authoritarianism.

It's funny what places you can find democracy waging war against authoritarianism, isn't it? But once you see it at work, it's quite uplifting to realize that democracy will win.