Types of Programmers

phenomenologically = "Let me talk to you about the experience called Flow."

epistemologically = has 50 books entitled "A Beginner's Guide For Dummies Unleashed In 30 Days". Actually even two of those abominations probably counts.

philologically = asshole knows 50 programming languages and makes sure you know it. The number of languages you know is like the length of your dick. How long is yours?

physiologically = knows the insides of the system inside and out, including all the exploits to break it. Just in case he ever gets fired. Doctors make the best murderers, don't you know?

anthropologically = knows the glorious history of not just computing standards but the standards organizations and other cultural artifacts of the computer industry.

ontologically = objects!! Of which Java has none.

Functional vs Object-Oriented Programming

Long ago I said that functional and OO were opposites in a way and I pointed to the fact that functional is verb-oriented whereas OO is noun oriented. Well today I have discovered the relation they have to each other. Functional is a gutless paradigm and OO is total.

They have the exact same relation to each other as deontology vs consequentialism, and for the exact same reason. Deontology is obsessed with obeying rules about actions regardless of consquence (state) and regardless of context, even when those rules appear blatantly insane and the consequences are insufferable. The question is WHY? Why would anyone do such a thing?

Obviously, deontology was invented by gutless people to deal with a universe they can't bring themselves to even comprehend. See no evil, hear no evil, speak no evil. The mantra of the gutless insane fuck. These people make up rules to deal with the universe and then they ... *hope for the best*. Even when they're facing the very worst, when they're facing an immoral unjust crazy and evil universe. Even in such a situation, they blind their eyes to the truth and hope for the best.

If you're going to blind and deafen and mute yourself to the actual state of the universe (state, get it?) then you have to blind and deafen and mute yourself to any consequences of your actions (future state). And while you're at it, you might as well blind and deafen and mute yourself to ALL state, because state is painful, isn't that right? If you have no coherent notion of state then you can't USE state (or nouns) in your methodology. You must resort in referential transparency (and verbs) as a last ditch method, no matter how insane it is.

The opposite of deontology is consequentialism. Consequentialism is about NOT blinding yourself to the actual state of the universe, be it so harsh or vile or nauseating or evil. Consequentialism is about understanding the state of the fucking universe, no matter how disgusting it may be, because only then can you ameliorate it. Only then can you make it less bad. Only then can you make it LESS harsh, LESS vile, LESS nauseating, and LESS evil. Consequentialism is about lessening badness.

And object-orientation? Is about understanding fucking reality. Especially, understanding the fact we live in a STATEFUL universe. A universe where objects clobber their past versions, where objects have side-effects, and where objects clobber other objects. THAT ... is ... THE UNIVERSE. Object-orientation is about fucking reality, and functional programming is about ... being gutless and weak and living in a fucking never never fairyland full of sugar plums and fairies.

Functional programming is despicable.

And logic programming.







And declarative programming.

Inferior tools for emotionally inferior minds.

What Is An OO Language?

People who understand Smalltalk make disparaging comments about how Java is Smalltalk minus minus. Something that is literally and historically true as Java was explicitly and deliberately invented as a crippled broken-down version of Smalltalk. A version of Smalltalk made more entropic to appeal to retards who were using still more entropic languages. Because when you want pigs to play with a diamond, why not coat it in mud so it resembles what they're used to? Hard to argue with that logic.

Now as I was saying, people who understand Smalltalk make disparaging comments about Java. And they understand that Java is not at all OO. Contrary to what the cretins say, it isn't true that Smalltalk is "the purest OO language". Smalltalk is not pure, it is highly impure. Smalltalk is crap and is the crappiest of OO languages. Smalltalk is the absolute bare minimum of what an OO language is. And since Java is inferior to the bare minimum, then logically it isn't OO at all. BUT, that doesn't actually explain what an OO language is and why Smalltalk is one and Java is not.

This rabid lethal epidemic of ignorance is what enables cretins such as this guy to compare Java and Smalltalk and Self without ever realizing that "one of these does not belong" much like a monkey does not belong with a man and a woman. So let us dispel the ignorance and talk about what actually makes up OO. Which is of course not classes as the majority of (entirely retarded) people claim. Rather it is objects. And by objects we mean independent dynamic contexts.

Now, the fact classes aren't objects in Java is bad, The fact there exist non-object primitive types in Java is bad too, but the fact that as far as scoping is concerned, objects simply do not exist in Java and are totally irrelevant? That's a deal-killer. No objects in Java <=> Java not object-oriented. And now let's turn to one of the most intrinsic and yet blatantly externally obvious properties OF objects so that everyone can behold the knowledge that Java has no objects and bask in Enlightenment. The Enlightenment that even LISP manages to be OO and Java will never be.

Fermions vs Bosons

Objects in reality are made up of FERMIONS. Fractional spin particles which obey the Fermi exclusion principle. Bosons are integral spin particles which do not obey the Fermi exclusion principle and therefore stack on top of each other and FORM NO STRUCTURES. Fermions <=> exclude each other <=> form structures <=> form objects. Bosons <=> stack on top of each other <=> form no structures <=> do not form objects. Bosons are light and radio waves and fermions are planets and stars and idiots who lionize Java.

Now, in Smalltalk and in Self and in LISP, there exist dynamic contexts which EXCLUDE EACH OTHER. They DO NOT STACK. And in Java those same "dynamic contexts" STACK ON TOP OF EACH OTHER. In Java, an instance of a class can freely play with any variables of any other instance of the class. Why? Because instances do not matter, because they aren't real, because they don't exclude each other, because they stack in the same volume. In physical reality, you can stack an infinity of bosons in the same volume until the whole volume collapses down into a black hole. In Java, you can stack an infinity of instances of a class into the exact same namespace until Java runs out of memory and collapses into itself.

There are no objects in Java because there is no matter in Java because there are no fermions. This is why everyone who's ever so much as played with Smalltalk or Self or LISP has grasped intuitively the feeling that objects in those languages are more "concrete" and more "real". Because they are LITERALLY more physical than the insubstantial ungraspable bosonic crap pseudo-matter which is all you can find in Java. In OO languages, objects have SUBSTANCE, whereas in Java they do not. In OO languages, objects take up VOLUME, whereas in Java they do not. In OO languages, objects PERSIST, whereas in Java they do not. And since classes aren't real in Java, it follows the fact that Java classes DO exclude each other can't matter at all.

In Smalltalk, everything is REAL. Everything is made of REAL objects and REAL matter. Objects have volume, and they jostle each other if you try to make one object reach into the innards of another object. It is indeed possible to make them do that but only by doing surgery rather than like a holographic projection passing through you. You can FEEL the resistance against doing this. and classes are even MORE real, because all classes are objects too. You can OFTEN ask classes "you class, give me your name and ID" and "you class, are you class ThisNameIsMine?" and the browser constantly asks classes for their parents and children. and you CAN ask ClassName allInstances of a class. And that's the least of what you can do.

So, Smalltalk, LISP and Self ==> OO + real + objects + matter. Java, C++ ==> dead crap + fake + insubstantial + ectoplasm. Also, OO <=> Good, and Java <=>; Bad. The reason Java and C++ prevailed and OO lost is because most people are retarded brain-dameged idiots incapable of grasping OO. Just like they're incapable of grasping Goodness is the reason why we have capitalism and coal and disease and poverty and wars and death. Bad to the retards is "Good Enough". This is the Worse Is Better crowd.

The Economic Benefits Of Personal Computers

Some people (engineers and fascists, not that those two terms aren't almost synonymous) have difficulty grasping that modern personal computers have vastly increased productivity of individuals. They say correctly that big mainframes greatly helped the record-keeping of large corporations. And that smaller computers helped the lesser record-keeping of smaller corporations. And that's it, because individuals can't possibly be doing any record-keeping.

These people also get greatly upset over computer games and other modern "distractions" and are dismissive of the fact these things are more enriching and valuable than other equally mindless age-old pastimes of chatting over the water cooler, being brainwashed by the idiot box, square dancing, and bobbing for apples. Never mind those, age-old means traditional and there can't possibly be anything wrong with that! In fact, when people aren't slaving for a corporation they should just go to bed like the good slaves they are.

Never mind the benefits of automation. The order clerks that don't have to be paid for because web sites are processing their orders. The large retail warehouses (not a new phenomenon) where order pickers are aided by autonomous robots. The ATM machines everywhere. The self-checkout machines. Being able to do your banking and taxes online with the aid of software. No, we're not going to go into those. It's not like they greatly benefit individuals and the economy and are aided by small computers.

No, we will here talk about individual record-keeping. Because individuals DO in fact keep records. These are called "notes". And in the bad old days which the engineers are conveniently forgetting, individuals had to keep records ANYWAYS. They were just on this thing called "paper" which had no search functionality, random or fast lookup. In the bad old days, people used these things called "index cards" as meta-records. They were shit! In the bad old days, people did linear searches through all of their records instead of using 'grep' or 'google'.

People DID have records in the bad old days, and they DID engage in record-keeping. But in the bad old days, even though you could write at as much as 1/10th the speed of typing, getting writer's cramp a hundred times faster than RSI (and infinitely faster if you're smart enough to switch to Dvorak keymap and/or get a Kinesis keyboard). Hmm, a 10-fold productivity improvement you say? Nay! Because in the bad old days, retrieval of records was so difficult it was prohibitively expensive. Yea, in the bad old days, in order to be able to maintain any kind of records, you needed very high intelligence to remember where your records were.

And nowadays ... intelligence no longer matters. You want to remember something? Type it up. If you're moderately organized, you'll be able to remember it. So that nowadays, it's possible for someone to function with as low as 2 slots in working memory when people normally have 4, in other words at less than 50% capacity. You know those times when your head is fuzzy and you're braindead? Well, it's actually possible to measure numerically how far your mental capacity has gone down. And it no longer matters. Because you can still do productive work ... with your cybernetic memory.

Thanks to personal computers, everyone now has an IQ of roughly 150. An enormous boost to personal productivity and the economy. Sure, people aren't any more logical than they ever used to be, and they aren't any more creative than they used to be. But in terms of raw intelligence, raw memorization ability, the boost provided by computers is phenomenal!

Of course, none of that matters as individuals cannot possibly matter to slaves or insects. Which is what the typical engineer is.

And to think, this is all without the computer / Internet revolution having happened yet. Because it still hasn't. For all that you morons believe it's taken the world by storm, it is barely inching its way through the world. It still hasn't happened in any meaningful way as cybernetic memory (or dirt cheap social organization provided by the Internet) is nothing compared to what's coming.

Speaking of dirt cheap social organization provided by the Internet. That was pioneered by people illicitly sharing porn and movies. It took over two decades for business finance to move to take advantage of it. So no wonder fascists and engineers, to whom only corporations and governments could possibly matter, would be utterly blind to the phenomenon. After all, it's not like dirt cheap porn brings any value to anyone's life. Certainly not to someone who takes seriously the notion of sexual abstinence for adolescents.

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.

General-Purpose Self-Improvement

It's often said that the human brain is a computing machine, and this is blatantly true. It's less often said that the human mind is an operating system or programming language. And when it is said, it's assumed to be some kind of metaphor. It isn't a metaphor, it is exactingly true. (Consciousness though has no exact analogue.)

There are two general-purpose psychological self-improvement techniques. And strangely enough, they correspond to two paradigms for programming languages in computing. The two paradigms that admit not only thinking, but thinking about thinking, and thinking about thinking about thinking, and ... to infinity. Computing is about thinking precisely. OO and Functional are about improving your thinking by thinking about thinking.

I think I'm on the right track that this kind of correspondence exists. And I think I'm on the right track that the Core Values paradigm I invented is the one that 'happens' to correspond to the computing paradigm I like (OO). And I think I'm on the right track that the common features between my paradigm and the computing paradigm I like ... are also the same things that make this computing paradigm understandable and natural for the overwhelming majority of programmers.

The OTHER technique is to pretend to be the kind of person you would like to be. And the guy whom I learned this technique from (the writer of Self 2.0) considered it too dangerous to use past a certain point. Myself, I consider it anathema.

Functional Requirements

I was doing some idle reading when I came across this sentence which startled me:

A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security.

Since when did any of these things become non-functional requirements? Up to now I'd always understood non-functional requirements as arbitrary choices of aesthetics and judgement calls. The fuzzier and least trackable aspects of a software designer's job.

Which made me realize that the whole concept of a "non-functional" requirement as others know it, complete with the connotation that they are less important and less comprehensible, is something I find appalling and incomprehensibly alien.

I understand a meta-requirement well. Testability and Maintainability are meta-requirements. And yes I invented that on the spot in 5 seconds. But "non-functional" puzzled me.

So I had to look up the concept of "non-functional requirements" because I couldn't wrap my brain around it or guess the kind of brain damage of anyone who originated it.

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.

Ah of course ... engineers. The people who obsess about behaviour rather than understanding. I understand the brain damage involved in the concept now.

Engineering is the mental disorder where a total lack of synthesis leads the sufferer to be incapable of intuiting internals and so 1) they delude themselves that internals can't matter, then 2) raise their crippling disability to the status of a virtue by claiming that fuzzy qualitative behaviours are much less important than quantitative ones.

In short, the narcissistic delusion that what you can't do, wasn't important in the first place. No matter how often empirical reality says the exact opposite.

People Who Waste My Time Calling Me A Troll

The ultimate hypocrisy is a lying asshole like programmer Tom Novelli of TUNES fame calling me a troll after he has gone out of his way to deliberately waste my time.

Let me be very clear. If you think I'm a "troll", a person who "goes out of his way to upset everyone's precious Harmony" ... fuck you. Seriously, go fuck yourself. I do not care to talk to you. Ever. I consider you to be retarded and a moron to boot. Talking to you will be either painful or excruciatingly boring to me. It is not an experience I will enjoy.

I do not need you to be my "friend". I do not even need you to be friendly. What I need from you is to stay the fuck out of my way. Preferably by warning me that you are worthless if I think otherwise. Because as you pat yourself on the back about how tolerant and open-minded you are like some POMO cultural relativistic fucker, the truth is that you are stealing my time!

What I need from people who aren't my intellectual equals is their acceptance of that simple fact. Either so they will believe what I tell them implicitly or so I can avoid the many subjects they cannot understand. Anyone who is hostile to me and hostile to the truth will obviously not provide me that acceptance. So they can just go fuck themselves and stay out of my way.

And if you don't. If after this warning you still waste my time in order to make yourself feel better, I will do everything I can, and it is considerable, to destroy you psychologically.

What Are Lambdas?

I'll start with some observations.

First, you can't say you fully understand something until you can explain it to others. Second, whenever you explain something fundamental, you can do so as a totally arbitrary property or in terms of some cognitively fundamental concept. 

Defining numbers as idempotent to sets is pretty fundamental. Defining addition as merging of sets is also fundamental. This is good. Defining these things in terms of Peano axioms is uselessly verbose and obfuscatory besides. This is bad.

Lambdas

Lambdas are just blocks of code. Lambdas DO things. This is a good, simple, cognitively fundamental explanation. The problem with this explanation is it violates every tenet of functional programming. It says lambdas DO something instead of MEANING something.

Since programmers are all idiots and computer "scientists" are even worse evil idiots, they resort to hocus pocus about ISK and lambda calculus. Read above about uselessly verbose and obfuscatory "explanations" of totally arbitrary properties. Summary: these explanations are bad!

So we come to the conclusion that Haskell programmers and computer "scientists" don't know what lambdas are. This is ... totally unsurprising. We have a world chock full of idiots here. A crapsack world from my perspective. A world where just one more drop of evil would lessen the horror I experience at it.

What Lambdas Are

When you finally realize what they are, it's just beautiful. Lambdas are "the meta-relation 'relation'". Everything is a relation in functional programming, and lambdas are the meta-relation. When you apply lambda R, you state the input and output are related through R.

All to say that today I finally learned what lambdas are from an FP perspective. And it's all so laughably trivial. There is something distinctly wrong with your brains that you couldn't have taught me (or anyone) this trivial thing. This trivial thing that properly belongs on the first page of the very first book read by anyone learning functional programming.

What the fuck is wrong with you all? I mean, there are plenty of idiotically written books on OOP that explain objects are "data structures with member functions" whatever the fuck that means. But at least, people understand 'hey, an OBJECT' from their real world experience.

If you losers wanted to avoid explaining what lambdas are, couldn't you have named them oh I don't know 'meta-function'? None of you losers seem able to grasp things for WHAT THEY ARE. How long did it take to rename CAR and CDR as head and tail or CONS cell to Association?

It's like you stare at a plane and think "shiny metal thing with two giant outflying struts each with underslung fast-spinning rotors attached". Fucking autistics, ought all be shot. Or at least get declared as second-class citizens.

Lambdas Are Meta

Lambdas are unavoidably meta. Their meta-ness stares you in the face when you know what lambdas are, because meta-ness is ALL they are. Which functional programmers don't seem to understand since they are all idiots. Or evil idiots. Bureaucrats writing tomes about type theory to pad out their resumes.

I emphasize this point because LISP has no special syntax for lambdas so it makes it appear that the relation 'meta-relation' is a similar kind of thing to other relations. And this blatantly violates a fundamental rule of UI design which states that you must never confuse the level with the meta-level.

I like Smalltalk's Block O' Code syntax - [:variable1 :variable2 | variable1 + variable2]. It's very ... hefty. It's very special. It's very good. It's exactly what it should be. When you stare at it, there is no doubt in your mind "this thing is not like these other things". And it really isn't.

90% of Software Projects Fail

In reply to the delusional asshole programmer who commented on my other post claiming the software industry's modus of failures was perfectly acceptable and didn't see any meaningful difference between it and any other industries ... I just want to share this little gem of a paper which I ran across in my delicious account. (I was trying to find stats I'd bookmarked about how Americans are stingy assholes compared to Scandinavians.)

From the paper (emphasis added),

On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

Yes, the software industry really does have a 90% failure rate! That's not hyperbole!

My personal OS project is long-delayed but the design has grown to include greater than 500% of the original features and functions. So I can only sneer contemptuously at those who ship broken down software without a trace of shame or embarrassment. I do not consider shipping a castrated version of what you promised to be any kind of success. I consider it a clear and total failure.

As opposed to my own project which even when it ships will only be not-exactly-a-failure-and-not-exactly-a-success.

Except you know what? I distinctly recall saying 10 years ago something like "even if it takes me 10 years to ship, it won't matter because the software industry is so stagnant, my OS will still be revolutionary then". And back then I knew it would take me two years to ship if I got support. Which I never got.

So yeah, I could have shipped a long time ago. I didn't because the worst conditions I imagined actually came to pass. Which puts me now on the exact time-frame I predicted back then.

I blame the failure part of my project on you all. I claim the success entirely for myself. I hate you all and fuck you very much for nothing you narrow-minded selfish fucking assholes.

And in case you read this far, the reason I'm now willing to talk about this is because as of before yesterday I've substantially finished design so the massively unpredictable part is over and the easy job is starting. Meanwhile, you guys couldn't even hack the easy part. Nor could you predict the predictable part. So I ask, what the fuck are you good for?

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.

Engineers Are An Inferior Form of Life

Engineers lack the capacity to synthesize original ideas, which is one of the two pillars of Judgement. Which means engineers are amoral and incapable of discerning good from evil without a market survey. Which will of course return bogus answers.

That's the abstract explanation. Let us examine a concrete example. Let us look at how software engineers decided to handle data.

The History of Unix and Windows

Long ago, software engineers looked at data on hard disks and they asked themselves: what dimensionality is yon data, what is its nature? And they determined it was one dimensional (bytestreams) and they patted themselves on the back and saw that it was good.

Then software engineers looked at data on CRT monitors and they asked themselves: what dimensionality is yon presentation, what is its nature? And they determined it was TWO dimensional (bit-BLOCKS) and they scratched themselves on the head and they said "we have a problem".

But lo, a brave engineer came forth and said: we shall Reduce the dimensionality of the CRT so that it maps the one-dimensional data in two-dimensions. Look, it is simple, Cantor did this! And the engineers toiled for a day and a half and they named their creation the Command Line Interface and they patted themselves on the back and saw that it was good.

Then some evil-doers (called Lusers) made a Feature Request, and they asked: we want to embed this directory data inside of other directory data, can we have this? And the engineers saw that this Feature Request was Easy. So they toiled half a day and they named their creation (now with fractional dimensionality) the Filesystem and they patted themselves on the back and saw that it was good.

Then some evil-doers (incomprehensible unfathomable aliens called Artists) said: look, this is all well and good but I have these things called PHOTOS, what the fuck do Command Lines and Bytestreams have to do with my Photos? And the engineers now had a Real Problem.

But the Engineers' procedures had "worked" so well they had produced something 5% as usable as Symbolics' Lisp Machine or Smalltalk OS, so they said they might as well get on with it and produced Windows. And they patted themselves on the back and saw that other people were calling them delusional fuckers. And they were very surprised.

The History of Lisp Machines and Smalltalk

Needless to say, the approach of genuine systems researchers and designers to data was ... a bit different. For one thing, these weren't engineers. They were experimentalists. And they were either capable of original thought themselves, or if they weren't personally capable of creativity, they were at least capable of recognizing that genuine creativity was something to be cherished, not something to be scorned, crushed and dismissed by claiming it didn't fit a Market Need.

The Researchers' and Designers' approach to data was thus: okay so we've got an encoding of data, but we forgot about it because it's not even remotely relevant. We've got a presentation of data, that's almost relevant but mostly it's misleading so we'll actively put it out of our minds. What we need to do is figure out the NATURE of the DATA ITSELF.

For starters, what dimensionality does this data naturally exist in? Oh, it's K-dimensional fractal data where K varies arbitrarily, hmm that's interesting. Okay, so it looks like we'll need a couple of transformations to encode the data and a completely different family of transformations to present it.

And lo the Researchers approached some engineers and the engineers said: say what? I don't fucking get what you're talking about! What are these "objects" you're talking about? Why would anybody need this? What is this "idea space" you keep talking about?! This is absurd and inefficient! Only hardware exists. ONLY HARDWARE!

Then the researchers scratched their heads and said unto themselves: what we need is to buy some engineers and if they don't DO AS WE SAY then we will FIRE THEIR ASS. And lo this was done and through natural selection the Researchers and Designers finally got some engineers that had faith in their Word, and Lisp Machines and Smalltalk were both invented. And this was magnificent.

And to this day, still the Engineers maintain that Unix and Windows are "good" because they refuse to shut the fuck up and do as they're told!

Why Software Is Stupidly Slow

People often bitch about software being slow and they have every reason to. Modern hardware has plenty of CPU and GPU cycles to spare, so why the fuck is it so slow? The software I have to use that's slow as molasses is Office, Opera and Firefox.

The first thing I observe is that these pieces of crapware do things I never asked them to do, I don't want them to do, things I don't need them to do, things I don't want them to do, things that nobody anywhere either wants nor needs them to do. Let's look at some examples.

Opera keeps all 30 pages I have in tabs immediately renderable. Did I ever ask it to do that? Like fuck I did. Most of those tabs are things I haven't looked at in days. One of them I hadn't looked at in 3 weeks.

Inevitably those 30 tabs will grow to 120 tabs, which will have Opera thrashing for no good fucking reason and then I'll save them all as a new session (rendering them unusable) and start from scratch.

If there were a better way to organize tabs than multiple windows (which are difficult to use and unhelpful) then I would use them. Not that moving the tabs to another window would help since Opera insists like some kind of fucking moronic retard to keep those tabs immediately renderable too!

Who the fuck decided it was a good idea to keep every bit of cruft a web user left opened immediately renderable? What kind of fucking retard at Opera decided on this dys"functionality"? I never wanted this feature, I never asked for it, I don't need it, NOBODY needs it. Nobody on the fucking planet needs it!

Nevermind that it is dysfunctional and fucking harmful, nobody needs this.

The same goes for Firefox and Office. I only open Office to read RTF files. Do I fucking need all this "functionality" that takes 30 seconds to load? For fuck's sake, does any Office user need it?! I would dearly love to know whether more than 10% of core Office users need to regularly change between 50 different fonts. I use one font, ONE, Sylfaen, that's it! 

It seems to me if software did ONLY what every one of the core users needs (instead of what's expected by the programmer's peers and tradition, or what the programmer thinks might be nice, or what users say they want or ask for, or what some user wants, or what non-core users need) then so much crap falls away in the code, so many "features" go away, that there's plenty of computing power for what's actually needed.

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.

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.