Still relevant today? In 1988, I was briefed by Ibm how they would use Smalltalk with about 10 programmer develop something to ... do not believe them for 1s.
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.
i am struggeling to understand what you are trying to say. could you please elaborate?
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.
It’s no mystery. In the early-mid 90s IBM was ramping up on Smalltalk believing it to be the language of the future enterprise. In the late 90s they realised that jumping on the Java bandwagon would be more profitable so they ditched Smalltalk almost overnight. The same reason IBM does anything, including Linux.
I know a guy that worked for IBM writing a large bunch of UI in Smalltalk (80?), desktop of course, on OS/2. He was highly supportive of the productivity and environment, but business concerns pushed them in another direction.
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
Inside a mildew-covered Tudor barn, and primed with much whiskey, Dave Thomas convinced me that the Open Source Movement was bad for invention and progress: Where it may do good, it also robbed developers of the opportunity to be paid fairly for their work, and that was bad.
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.
Twenty years ago (crikey, that long?), I was a pretty vocal Open Source advocate. At the time, it seemed like the only way to avoid a Microsoft monoculture, and I'm still not sure that wasn't true. But now we're seeing monocultures of corporate-sponsored open source (Chrome/Blink's dominance seems particularly alarming in this sense), and managers who are more reluctant than ever to accept technical solutions which aren't "standard".
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.
The Cloud is similarly tricky: As we can factor our non-essential costs and push them to someone who can trade on their efficiency- there may still be competitors to Amazon, but monoculture is creating a strangling-effect there as well.
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.
I'm certainly with you on The Cloud. I've been expecting a backlash for a while, but not much sign of it so far. A big monthly bill from $CLOUD_VENDOR_OF_CHOICE seems to have become this century's equivalent of "nobody gets fired for buying IBM".
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.
Stella! And then everyone started calling it "wife beater", because whilst it was slightly more expensive, it had a higher alcohol content.
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.
With language runtimes abstracting OS and hardware, the Cloud providers have become the new OSes, and coupled with the Web, we are back to the timesharing days, with the browser as a pretty VT100.
Nothing stops the others who are contributing to that consultant’s underlying free software from taking pride in their work. Nothing stops you from spending your bench time improving (or replacing!) that free software with others.
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.
Mine; yours, and everyones salary is based on the value our contribution brings to our customers needs.
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.
> Mine; yours, and everyones salary is based on the value our contribution brings to our customers needs.
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.
I don't think you understand what I'm saying, and perhaps that's my fault for not putting it clearly enough:
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.
I see the major culprints devs that want to get paid, while refusing wholeheartedly to pay in any form for the work of others.
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.
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.
Well, look at lispworks for example, that compiler costs $1500 for a hobbyist edition, i can't afford to pay for that. Maybe if you price your product reasonably for end users you can still sell software(including compilers/devtools), a lot of people pay for sublime text.
Sublime Text is a good example that always gets posts about devs not wanting to pay for a mere $80 for a perpetual license, valid across all supported OSes, in spite of making much more than that per hour in many world regions.
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 are some product areas where lowering the prices will not increase the market such that one can still pay salaries for employees... and still move the product forward through platform changes. Commercial Common Lisp seems to be such an area.
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...
This argument assumes developers have access to the market. In reality most of us are not in a position to benefit directly from selling software, regardless of how "good" or "bad" it is. We can only sell our labour for a pre-negotiated salary to an employer who will then pocket the profits. In such an environment, sharing, taking pride in, and building upon each other's work makes a lot of sense and works in the developer's long-term interest (as well as your employer-du-jour's).
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.
Good old DT. Dave was a prof of mine in the late 1980's.. CompSci at Carleton in Ottawa, Canada. SmallTalk...my first reaction (95.202 for those that remember...) was WTF?? We had just done Pascal...SmallTalk just blew our minds. It was like you had to smoke dope first... you know, to get it. Many late nights in the lab... it was running in Mac emulation on ancient Lisa computers (I shit you not). Anyhow, none of really understood why we had to learn SmallTalk. There were certainly no summer jobs for SmallTalk guys (dBase? C? sure... ) But DT and the rest of the profs on the 5th floor extolled the value of Objects. Smalltalk is just the tool they said...to learn about OOP. DT always had the best lectures...he was a total blast to listen to. I may have even learned a few things. The only guys I knew that made a buck off of SmallTalk went to work for Dave at OTI. And then that got bought by IBM. Dave absolutely did well...I'm sure he's still smiling.
29 comments
[ 4.4 ms ] story [ 77.6 ms ] threadWhat 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?
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.
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.
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?
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.
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...
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.