Travels with Smalltalk (1995)
web.archive.org
web.archive.org
Once upon a time, you could make a piece of software and sell it for $1m, but now you are competing with someone who would take a little "free software" and sell their consulting on top of it. You may be able to take pride in the quality of your work, but that consultant can't afford to so he won't. And things get worse.
If you sell a piece of popular software to many people for $100 each you could still make a lot of money, but how does your consultant fit into this? You're still competing with him, and he's willing to build on top of someone elses' work to do so. He's not delivering $100 worth of value (and doesn't charge that much either), so how can you still afford to make great software?
I feel shame if I can't make good software, and I don't want to make software so badly that I'll make bad software, but nobody pays well enough to make good software, and the market is so messed up it's almost impossible to sell commercial software that isn't bundled up as a solution of some kind.
I can get around this some by selling SAAS on prem., but there's a limited utility in this: I could never build a new Smalltalk this way. Rust and Go have seemingly massive benefactors, but paying meagre salaries to their swarms of developers and activists: Nobody is getting rich but the vassals who were already rich to begin with. I've got a great idea for a new kind of programming language, but I don't have even a few million I can spend building it.
It makes me sad that I can get paid so much more to not make software than I can get paid to make software.
I'd love to know how to bring back a bit more diversity to everyday computing. Beyond using niche systems for hobby projects, leverage seems rather limited right now.
I'm hoping that privacy and legislative effects will force companies to pull more things in-house so that they can provide controls and guarantees about their use. This can be good for software: If your medical data has to be on-prem, they have to build the right security controls to do so. If it can be in the Cloud, then they just need the security controls on paper. That creates a risk that maybe we can convince people to understand.
Makes me think: a few years ago, there was some or other beer in the UK that was (heavily) advertised with the slogan "reassuringly expensive". The Cloud vendors (perhaps AWS in particular) seem to be going down that path a bit. Very interesting to juxtapose the reluctance to pay for software with an apparent eagerness to pay for Cloud services.
Weirdly I predict a similar fate: I expect some Cloud employee will walk off with some banks cloud-hosted server containing gobs of financial data (if it hasn't happened already) and that'll be the end of that. There'll probably be a rush of "security enhanced" cloud solutions after that, but it'll probably hurt them badly in the process.
The one strange thing is that it seems to have caught IBM somewhat off-guard.
We see it all the time here, a forum supposedly for people doing their own business projects.
A ShowHN of any commercial tool is followed by endless threads of commercial software is evil and free clones or partial implementations to avoid paying for such tool.
So that leaves enterprise shops as the only customers to make money off selling tooling.
A long time ago I purchased Turbo C++, and then Watcom, but as soon as GCC got good enough I never paid for another compiler again.
I would love to make a great compiler, but how could I afford to when I'm competing with free?
If you develop some software that is dependent on Lispworks, how do you share it with others if what you are sharing depends on some Lispworks facility which isn't free?
I also believe that C++ is one of the reasons why some software is not easily shared.
Dynamic languages cannot use toolkits or libraries written in a language that is hard to interface to, Qt5 thats you. In fact I believe this is one of the main issues facing the dynamic languages, that there are no free well-featured cross-platform GUI toolkits they are able to integrate easily with.
There were cheaper alternatives in the past. Let's compare a cheaper one with LispWorks:
Around 1986 began the story of MCL: Macintosh Common Lisp was a commercial product originally developed for the 68k Mac by a small company. At some point in time Apple bought it, but mostly to maintain it and use the technology&people to develop a different language (Dylan). When Apple lost interest, there was still enough of a user base to not let it die, but to have a small company selling the product - ported to the PowerPC - the new CPU for the Mac. So the company sold MCL for PowerPC to their customers. Then Apple switched to MacOS X. MCL was moved to MacOS X on PowerPC - using a compatibility library provided by Apple (Carbon). But MCL was not ported to Cocoa. Then Apple introduced the Intel based Mac. MCL ran with the compatibility layer on the PowerPC emulator - not that great. Then Apple gave up the PowerPC and gave up the emulator and gave up Carbon -> MCL was dead. What we have now is a free version of MCL called Clozure CL - which hasn't catched up with MCL's IDE... which is really sad, since it was liked by its users.
Same time - around 1986 - LispWorks was developed by Harlequin. Initially for the UNIX market: enterprise + universities. With IDE. After several years it was ported to Windows and the IDE technology was made independent from X11 (Motif + Windows). Several CPUs were supported - not just Intel. Harlequin (a company with many offerings) went out of business - the remains were bought and the Lisp business was transferred to a new company. Then LispWorks got ported to the new Mac OS X. With native support for Cocoa. Later the UNIX version moved away from Motif to GTK+. Recently the runtime was ported to Android and iOS. There is a constant stream of porting it to the current platforms - for example it has currently supported implementations for ARM, X64, POWER and SPARC - each in 32bit and 64bit variants.
Now we have the fate of two commercial products serving the small niche of Common Lisp developers:
a) the more affordable one, formerly available only for one platform. Now dead.
b) the expensive one, available for several currently popular operating systems.
The big question nobody has been able to answer successfully: is there a place for a Common Lisp (or similar) IDE getting more popular so that a lower price point is viable - the product has a longterm future, has full-time employees maintaining it and is not bound to a single platform and its fate?
If there were a positive answer to it, then either some of the formerly existing products in that price range would have survived (Golden Common Lisp, ExperCommon Lisp, Procyon Common Lisp, Corman Common Lisp, Macintosh Common Lisp, ...) or we would have seen successful new attempts after 2000 competing with an IDE-based product against the expensive Allegro CL and LispWorks offerings.
Sublime Text is $80. Can we see a CL implementation for a smaller market (yes, there are more users for a general text editor than Lisp developers) which costs $80 AND which pays the rent for its developer(s)? Corman Lisp did cost $200 and did not survive...
Btw., this topic has been discussed a lot in the CL community. For years...
Since we are talking about Smalltalk here.
We had Energize C++, C++ Builder as C++ RAD tooling, which failed to win any representative market share.
And if it wasn't for Apple sponsoring the initial work in clang, the open source C and C++ tooling would be much worse than what was achieved the last decade.
Free Software is good for the users of software, which is ultimately good for developers, because ultimately we're all users of software first and developers second.
If we spend it making software, and we're competing with people working for free, we are simply not going to make as much money as we could be doing something else, so here's what happens:
People who love writing software, who are basically willing to work for free, will continue to write software. Some of them are good, but most of them are not.
People who are good at writing software, are also probably good at other things, and they will not program.
We have a similar problem with teachers: Surely you have heard teachers get paid poorly! We could pay them more and attract smart good teachers, or the smart good people who could also teach will do something else.
Free Software is still good, and I don't think it's useful to confuse the issue by pretending I'm saying otherwise.
this is tragically naive ; the role of business management is to control and reduce price of inputs, every time. If something absolutely vital, essential, mission-critical can be obtained for less and less dollars out, it will be done. This is a prime "function of markets and competition" .. if you are talking about salt or eggs in a subsistance population, things can go well.. in a world-connected, skills-based post-industrial world, it results in exactly what you see .. millions of 20-somethings with more years of college and better health than their parents, struggling to break-even to just survive, etc. etc.
If I can deliver a solution and I cost £500k, but some 20-something only costs £50k, then of course the customer is going to go with the cheaper option.
But if I want to make £500k, what ends up happening is that I (and others) don't program.
That's not a good thing if you value invention: Nobody can invent for £50k, and so long as that's the market rate, £500k problems simply won't get done. That is probably okay for businesses though who want solutions and not inventions.
Free software, just like proprietary, could be of good or bad quality. This depends on the people who wrote it, not so much on the choice of licensing terms.
> It makes me sad that I can get paid so much more to not make software than I can get paid to make software.
I can relate.
What is the business model is then what Microsoft teach the world. It is not technology but the business (the share to the inventor and investor) or later in 1990s (we learn from open sources) the governance and partipation model that rule.
Also, it is dynamic and environment base then, how to work in a large team is not that resolve for new firm to use it.
Hence once again a 2018 to 1998 me, is this still relevant.
I read this btw during my 15min search about this and give up. Like 1988.
https://medium.com/@richardeng/mobile-smalltalk-c6f0cc712909
what is it that you don't believe about IBM?
and what is your point about large teams and new firms?
here are my thoughts:
if you didn't think smalltalk was useful in 1988 then you probably won't feel any different today.
i feel today that smalltalk is interesting. in 1988 it would have blown my mind. here is why: today most languages in use fall into two major groups: lower level languages like C and C++ where you do your own memory management, etc. and higher level languages that use some form of runtime and do a lot of work for you. when i was studying in the early 90s, i felt that the latter group of languages were not taken seriously. they were called scripting languages and were more or less only useful for toy programs. (i know that is wrong, but that is what i was led to believe). today these so called toy languages are growing and growing and they are slowly pushing C/C++ and related languages to the side. we get more and new variants of these languages every year.
but, and that is the kicker: hardly any of these languages add something that smalltalk (and lisp) didn't already have. we keep reinventing the syntax, but we are not actually changing how we program computers. exceptions are few and far between.
additionally, smalltalk (and lisp) achieve the same with a minimalist and thus much easier to learn syntax, so that since learning those two languages, almost all others feel like a step backwards.
this is what makes smalltalk relevant today. smalltalk and lisp act like a high-water-mark, as a reminder that most of the languages we are using today don't float our boat any higher than it did 50 years ago.
1) thirty years ago you were given a sales pitch about Smalltalk that you disbelieved
2) You don't know how to make it work with a large team
3) That you gave up reading an article that is written for an audience of Smalltalk programmers on how to handle a particular situation, despite you yourself presumably not being a Smalltalk programmer
How is any of this relevant?