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.

Proof That Unix Programmers Are Retarded Morons

It doesn't get any more retarded than being unable to name colours. Like confusing silver for grey, or roses for chestnuts, or violets for royal purple, or bamboo green for every other forest green.

And the worst part of it is that HTML sucks and was obviously made by retards so Unix programmers are losing a colour naming contest with retards. Because they think glowing CRT colours are reasonable standards.

I realize now, 'retarded' and 'moronic' are inaccurate descriptions of Unix programmers - inbred is better. The only colours they dealt with were from CRT screens so they thought it would be reasonable to name colours solely on their own inbred concerns.

Unix programmers are inbred morons who don't know anything outside of their own little pathetic Unix world.

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.

Formal Theory of Intelligence

A few years ago I tried my hand at a formal definition of intelligence by saying it's 'living representation'. I'd just been observing that there isn't a formal definition of intelligence anywhere. I'd also just formally defined 'life', another key concept that has no formal definition anywhere save for the one I gave it.

You see, intelligence may be just rote memorization (yes, even the Raven's progressive matrices) but there's more to rote memorization than just recording and archival of data with absolute fidelity. Real learning builds associations and is also lossy, entirely different from the way a computer stores data. And it just occurred to me now that 'living representation' is a good way to describe the 'compression unit' described in this paper describing a formal theory of creativity, fun and intrinsic motivation.

The compression unit's purpose is to ensure the knowledge base isn't drowned in an ocean of entropy (ie, waste information). So new facts are stored and then they're associated with all old facts and the whole is recompressed all over again, continuously. And that's how you get dimensional decomposition and natural language processing since they are just compression techniques!

Just a little insight inspired by thinking of idiot people incapable of coming up with proper definitions of key concepts in psych. Frankly, those psychologists who try to make definitions are so bad at it that they come up with the most ridiculous tripe unimaginable. So from that to my rather esoteric and seemingly poetic formal definition of intelligence, then to the relation between beauty and compression, and finally linking to what we know about how machine learning works.