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:
- 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.
- 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.
- 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.
- 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.
- #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.
- 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.
- 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.
- 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.
- 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
- Smalltalk is not homoiconic the way LISP was and is
- the event system is not debuggable
- 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.
Posts
22 comments:
"The failure of the software industry" -> Which failure are you talking about? I personnally don't see any failure... Am I missing something?
"Am I missing something?" -- Yes.
Wow, I don't know what to say.
Worse, you call yourself a software developer. I guess they'll allow any person to program, no matter how ignorant.
Does the fact that Unix, an OS invented for non-interactive BATCH computers, still exist in the age of 3D graphics cards not mean anything to you?
Does the fact that Symbolics Genera Lisp Machine still serves as a source of inspiration for operating systems designers seeking new original features not mean anything to you?
Does the fact that the mainstream programming language is distinctly inferior to Smalltalk-80 not mean anything to you? Or how about the fact Java was explicitly created as an inferior version of Smalltalk?
What kind of industry do you know of where things are WORSE now than they were 30 years ago? And how the bleeding fuck can you NOT perceive this as a failure?!
Does the fact that software projects fail all the time not mean anything to you?
Does the fact that software FAILS all the fucking time not mean anything to you?
What kind of a professional are you? Does the term "professional pride" not mean anything to you?
Are you missing something? Just about the last 30 years. Just about the ENTIRETY of the software industry!
Richard,
have a look at the Newspeak language and its characteristics (modularity, security, functional, variable handling, etc.).
It doesn't solve all the problems you've mentioned but it is certainly and interesting successor for Smalltalk!
PS: I agree totally with the state of GUIs in Smalltalk - its a mess...
Have a look at one or two of the movies of Genera in this page that was recommended to me by Stanislav (due credit). Notice how the objects are selectable by the mouse when it hovers over them? Now that's an OO UI! Of course, it doesn't necessarily meet my criteria for an OOUI but the fact NO Smalltalk has this functionality is pathetic.
I've had Newspeak recommended to me a few weeks ago and I find nothing particularly noteworthy about it. The use of namespaces has been done in visualworks to some extent and so is derivative. I doubt they're going to do anything deep with object-capabilities otherwise they would advertise it. The term 'pluggable types' means nothing to me. Their advertising 'dynamically typed' and 'nested classes' makes me shudder in dread and horror respectively.
I believe the reflectivity they advertise to be hype. And the modularity and security to be of the same type as Pharo rather than Self 0.1. In other words, they do not aim to incorporate any genuinely new high-level properties into Smalltalk. Rather they are just fucking around for the sake of fucking around. Or for political reasons in the case of Pharo.
Actually, if you look in their web page, the first paper reveals what they mean by "reflectivity" which is very far from what anyone else means by it!
Also, the so-called "justification" for Newspeak they provide proves my accusations that there is NOTHING principled about Newspeak. This is at best a re-engineering exercise of very limited value. Even if they are successful in their aims it will have very little appeal since the features they want to introduce to Smalltalk are incomprehensible and esoteric.
Nobody cares about Actors. And nobody will ever, ever care about Objects As Services. Just like nobody cared about Transformational Programming or Aspect Oriented Programming or Array Oriented Programming or synchronized computation (opencroquet).
Note that nobody cares about object-capabilities either, but at least object-capabilities has direct application to end-users. All of the crap I previously listed has applications ONLY to programmers.
In summary, Newspeak is typical engineers' circle-jerking. It is neither relevant nor original.
The only thing I can think is that history is not your specialty. Let me take two examples:
-- Guns, invented in the 13th century in China. They were unreliable for centuries, and not reproducible in quantity until the 19th century.
-- Trains, invented in some form by the mid 16th century, were not powered until the early 19th, and not really safe until the mid to late 19th century.
Software is still a young field, and has not yet seen the equivalent of replaceable parts come along. For the most part, you seem utterly blind to this simple fact.
> I've had Newspeak recommended to me a few weeks ago and I find nothing particularly noteworthy about it. The use of namespaces has been done in visualworks to some extent and so is derivative.
As if the general tone of your writing didn't give your ignorance away - Newspeak does not have namespaces.
http://bracha.org/newspeak-modules.pdf
Moreover Newspeak addresses several of your original concerns about Smalltalk...
I had started to reply to some of the other parts of your rant that quite frankly I find laughable, but then what would be the point?
James, fuck off! LOL. Your contention is utterly ludicrous.
First, technological development has accelerated enormously. There has been as much technological development in the last 30 years as ... blah blah.
I'm not telling you anything you don't already know, so I'm astonished you think you can get away with this disingenuous crap argument.
The refrain that "we are a young field" is often used but that doesn't change the fact that it's special pleading.
And it's particularly grating for you to make that claim when I already pointed out in the comment above that the software industry has been stagnant or even moving backwards for the past 30 years. Youth cannot POSSIBLY excuse this.
In fact, if anything, the software industry acts not like a youth stumbling and exploring but like a geriatric old geezer that's one step away from croaking at the slightest movement.
That makes two Great Deceptions you're attempting to perpetrate. But I'll go in for the kill by revealing your third Great Deception, the supposed lack of any "interchangeable parts".
I'm sure you know what the term "molecular nanotechnology" refers to. At least I hope so because for a programmer (ostensibly future oriented) to NOT know of this key future-tech is unforgivable.
Well, what's the appeal of molecular nanotech? It's the fact of its INHERENT ATOMIC PRECISION. It's like building using only LEGO blocks. Because the units are atoms and they are unbreakable, indivisible and totally exchangeable.
In other words, molecular technology once it is developed will be using interchangeable parts FROM DAY ONE. Because that is its whole purpose.
Can you guess when the software field started using interchangeable parts? When computers went digital. And that happened a long, long time ago.
Now you could argue that software is about the design and engineering of complex systems, and that THAT field is still in its infancy. So much in its infancy that we still have only a set of problems and I personally only have hints of a few solutions. Whereas the rest of you are fucking clueless. Yes, if you had argued that then I would have said you're bang on.
Except that's not what you argued at all. And the design and engineering of complex systems is hardly restricted to software. You people are completely clueless about political systems as well.
No, your arguments are crap, and not only do you not know what the fuck you're talking about but you are actually anti-insightful. It's not just lying FUD with you, is it? You're some new kind of creature. Before reading your argument I had never thought it possible for negative insight to exist.
James, your greatest misconception about software creation is that it is a field. It is not. It is a meta-field.
Creating software isn't like creating automobiles or books. As a programmer your purpose isn't to use, apply or instantiate technology. Your purpose is to create new technology.
So you are stupidly asking for the field to settle, for well-designed interchangeable parts to appear, for designs to achieve local minima of difficulty and maxima of expressiveness.
When the truth is, that will NEVER happen because the day it does, programmers will be done with these parts of software and move on to something completely different.
Once you have the ultimate photo-gallery, you don't need to program other ones. That would be stupid.
And the fact that it took 15 years for the ultimate photo gallery to be invented would be acceptable in any other field. But it isn't for software because software is a META-field.
It is not acceptable for software to take 15 years to be perfected.
As a programmer, you'll no doubt turn to methodologies. First you had waterfall now you have XP. Whatever. Those are all crap and don't address the real problem.
The truth is, the software revolution will only come about when programmers learn to become designers' bitches.
What that means is that YOU are supposed to be MY bitch. But that's a lesson you're not and never will be prepared to learn, is it?
So ultimately, the reason for the failure of the software revolution to come about is ... you.
And you can engage in all the special pleading you want. Make all the pathetic, worthless, lying, and anti-insightful excuses you want. Because really, the fault is ... you.
I see you're still a sad angry little man. Your venom has utterly destroyed your potential.
I could sling the 'no one is stopping you' nonsense argument at you but that won't productive.
Anyways I think your ignoring the other perspective: the world didn't blow up either nor did it come to a screaming halt.
Projects fail and the bigger they are the more often they fail, but that has little to do with software in particular, as projects that don't involve software fail just as well.
Software fails, yes some software more often then others. It's usually related to how the requirements where and the preparedness to pay for them as well as one software developer being more skilled that the other. But how is that any different with cars.
Super elite programmers.. great. Are there enough of them? Will they work at any price? is poor quality good enough if it's available right now?
it comes down to economics 101, which I probably don't need to point out.
Do we all want to save the world? sure. Do we have other responsibilities to take care off as well? likely.
ps. what java probably proved is that tooling and availability of libraries just might trump any deficiencies the language has.
I would respond with on "nobody's stopping you".
I'm sure you've heard the aphorism: An optimist is someone who believes this is the best of all possible worlds. A pessimist fears this is true.
Well, I have always firmly believed that this is a Crapsack World just as surely as Warhammer 40k. Only recently did I note a single difference between your world and Hell.
That single difference was the beginning of my apotheosis. Let's hope this process continues to completion before I die.
Non-software projects don't fail at rates of 90%.
You also seem to be a fan of the Waterfall methodology. You probably don't know this but waterfall is total crap for greater than 90% of projects. The projects to which it's a good idea are a miniscule minority.
Do read up on Extreme Programming methodology and tell me what the fuck it has in common with automobiles or automobile engineering. Hint: nothing.
Oh and you might want to compare the rates at which the automotive industry comes up with a new brand of automobile, and the rate at which the software industry comes up with a new version of software. For that matter, aren't there only a dozen or so types of automobiles? Compared to a few thousand different software packages?
> it comes down to economics 101, which I probably don't need to point out.
No, no it really doesn't. If economic considerations applied then systems designers (who are rare as archaeopterix teeth) would rule everything. What actually happens in practice is they are scorned by the more numerous programmers.
This happens because systems designers are too few to have achieved the critical mass to do ANY OF:
* identifying children with the talent
* tracking children with the talent
* producing educational material for children with the talent
* differentiating themselves in the public's mind from other creatives, from engineers, from academics
* educating those with the talent through adolescence
* educating them through young adulthood
* dragging the Art into modernity by anti-specializing
* mastering the Art to its maximum potential
* researching the Art so it can be taught systematically
* support our young economically, financially and politically while they incubate
* produce standards to determine each other's competence
* push those standards on to hostile and clueless employers
It's not economics that rules, it's POLITICS.
> Do we all want to save the world? sure.
No, no you don't.
> Do we have other responsibilities to take care off as well? likely.
Aha, you admit it! You don't care about saving the world. And even those that do are too fucking stupid. And ultimately don't care since they're perfectly content doing useless make-work (eg, "protests) that THEY KNOW will never, ever work. Because it never has.
Finally, Smalltalk proved that tooling was important a long, long time ago. And it did so without having the crippling deficiencies of Java. In other words, Java proved absolutely nothing new. For fuck's sake, why do you think Smalltalk was chosen as the target to make a more deficient language?
Smalltalk was not created to be perfect. It was an experiment; an iterative attempt to create a language that was more likeable for children small and big alike. Before Smalltalk80 came Smaltalk76 and Smalltalk72. After Smalltalk80 there should have come other Smalltalks... but then Self was the last version.
As Alan Kay said: Smalltalks biggest problem is not being message-based entirely.
RD
Smalltalk failed even by Alan Kay's standards. He wanted to create a language that helped children program. In the experiments he ran with Smalltalk, he discovered that this wasn't possible.
The reality is about half the general population can never be taught programming under ANY circumstances. And that the other half doesn't NEED to be taught because they'll learn it themselves, regardless of language.
Alan Kay gathered all the empirical data of his failure and he ... refused to acknowledge it. Thus, Alan Kay himself is a failure. Not as an innovator but as a human being.
And you know what? You're condemning Smalltalk by trying to excuse it. See, at least as a failure at perfection, it's a spectacular and instructive failure. Whereas if we take your point of view then Smalltalk is a successful nothing.
I know as an absolute certainty which one I would prefer for my own projects. So just in case I crash and burn, could you please shut the fuck up rather than trying to cut me down to your Lilliputian height?
Just because you're a midget doesn't mean everyone enjoys being called stumpy.
"Non-software projects don't fail at rates of 90%."
If you take the criteria under which the software project are deemded a failure on the reports that produce those numbers: not on time or not within budget set at the beginning of the project or never used for what it was actually designed for..
unless you go completely prefab how many houses are actually build and on time and within budget etc? Or any government project that had any significant budget..
waterfall sucks for all but the smallest, without uncertainties, projects.
The cars reference bit was a reference to the bugs are included in the price. quality is sacrificed to lower price, different car brands target different client expectations.
In most software development processes, including agile ones, (software) quality attributes are ordered given importance and handled as such. Some times speed is favored over robustness, if it fails run it again. Sometimes robustness is favored over speed.
It's easy to complain software is slow but if it was never designed to be fast is it still a defect, a failure?
I also like to think people get better as they go, which probably means that any programmer was responsible for producing bad software are some point.
'would rule everything' It's your typical capacity problem. people will get by and go with what works, however imperfect. There is a demand for bad programmer because there is a shortage of good ones.
"It's not economics that rules, it's POLITICS." Did they become mutual exclusive just now? ;D
"Aha, you admit it! You don't care about saving the world." Don't know about not caring, I'm just pretty sure that I can not have my cake and eat it too. Thus I endure this world as is.
Considering the general tone of the "discussion" here, I would suggest that you would all do well to read this: http://alarmingdevelopment.org/?p=422
I am constantly amazed to see discussions amongst "professionals" at this level.
FINALLY, it is gratifying to see SOME programmer publicly admit what worthless inferiors his brethren are and what a disgusting retarded inbred joke of a field they all belong to.
Lest there be any confusion in inferior minds, the rebuke obviously doesn't apply to me as I am one of the godly ones, the systems designers, whose numbers in the world can be counted on the fingers of one hand. And whose key cognitive trait is not analysis but synthesis.
Topical essays of mine:
* how programmers are more egomaniacal (self-indulgent) than EVERY other profession in their cognitive type
* how engineers (and programmers) are lower life forms
* How the field of programming is a joke
* the so-called "analytic intelligence"
As seen above, analysis can be trumped by syntheses (spontaneous creativity). And synthesis is something programmers almost universally lack. The proof of this is that synthesis+analysis synergize into judgement. A faculty which the moron who wrote that essay severely lacks!
Java was always meant to be a trade-off between Smalltalk and C.
Easier to learn for C people, which might have difficulties to grasp the OO paradigma.
Yes, Java was about making money - but why is that so bad? You need money to support/enhance a language.
Just compare how many extensions you have for Java and how many you have for any Smalltalk.
As far as those eight exceptions you list, sorry, that is just petty.
The first two I would not even want changed in any way and certainly, I do not want to #perform: anything.
The beauty about Smalltalk is that you can change almost all of the bevahiour you so violently and wordly detest. So how about that?
Don't be absurd. You can't change anything at all since things like the behaviour of #at:put: have become part of the ANSI standard even though THEY ARE WRONG.
As for these details being petty, I am a systems designer. Look up what that means. But I will explain to you that it is ANY designer's JOB to obsess and fuss over EVERY detail.
Furthermore, you didn't pick up on the objections I have to Smalltalk that are BIG HONKING PROBLEMS like the lack of homoiconicity. Probably because you don't even understand what homoiconicity is. And frankly, that's why I didn't bother going into it. Because you all would be clueless.
It's amazing how perfect Smalltalk is. So perfect that clueless people like you will dismiss any imperfections as entirely irrelevant. And then be profoundly baffled when deeper problems are raised. But then again, the whole POINT of this post completely passed you by.
You know what else completely passed you by? That there is a point to anything at all in this world that isn't making money. Are you a psychopath?
so what you are saying is smalltalk really is good?
The arrogance of the writer of this article is risible to the point of absurdity. If a designer in any other field of technical endeavour produced something like Smalltalk, they would be sacked on the spot. Smalltalk is a disgustingly slow, inconceivably useless language which came out of a place whose only contribution to the software industry was to have its better ideas nicked and implemented in languages which didn't eat up clock cycles like a hungry elephant.
Unix was successful because it worked. Did it work well? No, but it didn't have to - it only had to work well enough to let people get useful stuff done. The C programming language doesn't waste its time with pointless metaphors. You don't see anybody in the car industry saying, "Hey, let's think of the dashboard as a cat!", the same way that people in the software industry seem to think of their programs in terms of objects rather than mathematics.
Honestly, if the writer of this article was in any sort of field where he had to design hardware which had the potential to be life-threatening, either his company would go bust, or his co-workers would get so pissed off that they'd stick him into the hardware as a test dummy. The operative word, of course, is "dummy".
Dude, are you for real? I cannot believe anyone could have ANY intellectual intelligence at all, which you clearly have, and be so entirely bereft of emotional intelligence.
So I'm left thinking this blog must be facetious. But then... why?? Why bother?
Post a Comment