> Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.
I like this one especially.
It rings true if you imagine a world where you have complete control over your machine, you don't worry about possibly external code breaking or extracting your stuff and so on.
But lets just pretend we don't need to worry about these things for some reason. It would be so powerful. And I don't mean you have 'root' privileges, I mean your programming environment owns, controls and _is_ everything that happens. No black boxes, no overhead, nothing. Just _one_ runtime that is integrated all the way down with the expressive power of a Lisp/Smalltalk/Self or similar. It's sad that this doesn't seem like a viable option.
People just need to start chipping away at it. Eventually it’ll exist.
My favorite inspiration for “chipping away at it” is https://ephtracy.github.io/ who has been slowly building up the coolest 3D art tools one commit at a time.
The problem with environments like that is that they are never perfect. There's always something that at least some users need that they left out. But, since they're trying to be everything, they don't leave you any way to leave their world to go get something from the real OS, or the bare metal, or wherever "outside" is.
So, if you're trying to build an "everything" environment, sure, try to get everything in. But know that you will fail. And therefore, don't trap people. Leave them a way to get "outside".
> they don't leave you any way to leave their world to go get something from the real OS, or the bare metal, or wherever "outside" is.
Pretty sure the idea was and is to run Smalltalk on bare metal. Which you can absolutely do.
The more realistic problem is: what if you still need Firefox, or Office, or Photoshop? One solution is probably to run Windows and Smalltalk on a hypervisor. You still get low-level access from Smalltalk (hypervisor calls, hardware access, etc.) without giving up Windows (or Linux, etc.) apps and compatibility.
Running a web browser in a hypervisor is also probably a good idea for isolation reasons.
Another interesting idea is to run Smalltalk on the JVM (which itself was inspired by the Self and Smalltalk VMs.) You lose some low level access from Smalltalk but you gain interoperability with Java as well as portability.
In a sense that's a valid point, but what we have seems inferior in this regard. My machine is running a huge amount of individual, uncoordinated runtimes. Often there's layers and layers of uncoordinated bloat, communication overhead and everyone does his own garbage collection, scheduling format translation, gui rendering and so on. It's incredibly wasteful and the only thing that patches over it is that my computer is fast enough to handle all this crap.
/rant
I get that all of this has reasons, often historical. PC/Internet adoption just grew so fast during 80's and 90's that nobody even had the time to think it all through and design a coherent system. Even new OS's and runtimes have to carry over all this legacy stuff. I mean I get it and as a web developer I'm probably more part of the problem than the solution. But boy would computing be simpler, more powerful and expressive if we could just start over and lean on the ideas of (mostly) early, holistic visions and prototypes of personal computing.
I mean I get it and as a web developer I'm probably more part of the problem than the solution.
Ironic Humblebrag? The developer tools and consoles built into browsers are in some ways a return to the Smalltalk and LISP Machine development ideals I've read about, if you consider the Internet the machine.
I wouldn't say everyone. Most people just played games on them. They would have gotten a game console if their parents hadn't wanted it to be educational.
I’ve been playing around in Pharo [0] and it’s such an immersive experience! My first reaction was to compare to eMacs in that the editor/environment is the program and it can be edited, customized, extended… but Pharo/Smalltalk takes it to the next level of ease of use, discoverable and fun!
If you like the emacs-like aspect of Pharo, the Glamorous Toolkit project (which is built on top of Pharo) is worth checking out too. They recently released a digital notebook tool called Lepiter that has a lot of similarities to org-roam/org-babel: https://lepiter.io/feenk/introducing-lepiter--knowledge-mana...
Did they release it? The blog is about it but there's no link. This seems to be the site https://lepiter.com/ but it's just a form where you can give your email to "Register for fresh news."
It's released. It's not a separate download -- it's in the Glamorous Toolkit download (which makes sense from a Smalltalk perspective but may be weird if you're not used to it).
If you're on an iPhone, doubtless its autocorrect will assume that what you meant was the plural of that other wonderful Apple product from years past.
Literally almost every piece of consumer facing software is created using languages or frameworks that derive from Smalltalk-esque principles (OOP, MVP, IDEs, etc...).
And the creative spirit is what brings innovation. Tons of what's obvious now wasn't obvious when someone created it.
"Even if you’re designing for professional programmers, in the end your programming language is basically a user-interface design. You will get much better results regardless of what you’re trying to do if you think of it as a user-interface design." -Alan Kay
In the words of Christopher Alexander, the programmer is the true inhabiter of the program. Since we can expect the world in which the program should function will change, so should the program.
It is the programmer that has to figure out, often with experiments, what changes to the program work best.
Therefore it makes no sense to me to focus on anything but serving the programmer.
The better the experience is for the programmer, the more users will say "y'know what? This doesn't quite do what I want, I wonder how I change that" and presto, they're a programmer now.
We would never have had Hypercard if it weren't for Smalltalk and Alan Kay, and we've never had a platform as good as Hypercard since. That's a crying shame.
Precisely. Every barrier in place between using a system and programming it serves to elevate the decisions of its designers over those of its users. The greatest power of computers is their ability to be reshaped to meet whatever need the user has, but we mostly lock that power away from them.
There's a subsection of people who are very well served by that. And it has already been happening. SQL, Python, HTML/CSS/JS are all things that people use who are not primarily programmers. Applications like Unity, Excel, some Adobe stuff also blur the line here.
But let's not forget that there are a ton of people (many more than the above) who are constantly overwhelmed by computers even though they only use very few features. There's people who can't use ATMs and smartphones. Most computer users only ever use the most common applications (browsers, music/video players etc).
> Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
I sort of get where this comes from: the product should serve the users. But thinking of dev tools as the product for devs (the users in this context) is useful.
Devs code better products if they enjoy using the tools.
Only if you missed the part that this technology tries to capture "the spirit" of the creative side of the coder which is an universal, hence my analogy with making "the coder feel like a rockstar".
Absolutely! Software development is all about making money, and I think this in general is at odds with creativity (different goals, methods, practices, whatnot). However, I also think that there is large group of people who does not code for money, but to make art, have fun, or express themself, and "to serve the creative spirit" is exactly what they need.
I agree that "most software development" is not about serving the creative spirit of the coder, but it'd be a shame to lose that! And if in some way we could have our cake and eat it (i.e. enjoy the creative process of coding for most software) sounds like a win-win to me! Idealistic, but one can dream ;)
"Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be changed or that is not sufficiently general is a likely source of impediment. If one part of the system works differently from all the rest, that part will require additional effort to control."
Ironically, Smalltalk drives what the Clojure/DOP crowd considers the cause of this: custom languages. Creating classes means you have to know specific method names (a new language) to interact with a specific object. Eventually you can't wrap your head around it - but Smalltalk offers an env where you can come up with custom visualization to compress all this knowledge.
Another approach is DOP: your programs are all mixes of {} and [] and your functions mostly transform data.
I guess the question here is which approach represents your problem-solution with less concepts? Classes and method names? Or keys (as in {}) and functions?
You'll still end up with namespaces that contain all your abstractions, but it seems like DOP minimizes accidental complexity as the building blocks are simpler.
What Smalltalk brings that other systems lack is the visual environment for building different representations. Clojure (my DOP example) has the REPL and data browsers but these lack the expressiveness of the Smalltalk VM.
I haven't followed subsequent evolution of the language/environment;
I'm wondering: has anyone taken on integration of an idea of something like a native notion of modules/versioned package management?
I enjoyed the premises of working with changesets and a monolithic image, to a point;
but it always seemed it would not be that hard to integrate a contemporary notion of modularity...
I'd love an environment which allowed me to develop in Smalltalk, debug in an image, yet freeze the dependencies, with smart ephemeral compilation and the like, and...
I haven't used the latter, but the former is easy to use and based on libgit. Create a new repository, select the packages that go into it, make the initial commit. After that it'll tell you when the changes don't match the repo. You can select down to the method level since it's aware of the language's syntax and semantics. The generated repository looks like the Iceberg repo itself, a collection of directories for the packages and then .st files for the classes and their contents.
> I'd love an environment which allowed me to develop in Smalltalk, debug in an image, yet freeze the dependencies, with smart ephemeral compilation and the like, and…
I've always liked smalltalk and its ideas, but you can't use it to make shrink wrap software, at least last time I looked at it, maybe you can now. I've always thought this was a deficiency, same as Java early on.
Requiring megabytes for a base system image (although it could be stripped and compressed) the Smalltalk runtime was once considered too large to be shipped with individual apps, and apps tended to be slow and unresponsive compared to compiled C apps. There may also have been licensing issues with shipping a runtime environment.
Fast forward to 2022. Compared to current app sizes, it's laughably small. Compared to Electron/web apps, it's probably faster and more responsive. And the licensing issues have been solved with open source versions.
Those sound like nice systems and stepstones to where we may be today:
- fully free/open source implementations
- native widget integration (or we don't care anymore because we're used to crappy web apps)
- the resource usage and responsiveness gap between commonly deployed apps (such as JavaScript and web apps) and Smalltalk apps has either evaporated or is less of an issue because of faster hardware and more memory
But as you may be implying, I think that there are additional barriers to Smalltalk being used more commonly, such as unusual syntax, a different workflow compared to Java/Python/Javascript/etc., lack of type safety (note that even Python and Javascript have typed versions while typed Smalltalk doesn't seem to have caught on) and the fact that it's neither considered a web technology, nor is it promoted by influential platform companies. I suspect that the Pharo people might think that Smalltalk has a bad reputation (or something) so they never say "Smalltalk." I tend to think that not calling it Smalltalk leads to a bad outcome of confusion and fragmentation.
> If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.
Not true at all. For example, artists using Photoshop are typically not programmers and don’t understand the system at all. That doesn’t stop them from creating world class art. A great creative system hides all the complexity from the artist and frees them to express themselves in a way that is natural to them.
Also, understanding the complete system, from software to hardware etc. is pretty much impossible for an individual. So your “low level understanding” of a system will always be a simplified model of what is really going on.
I have seen this kind of thinking before and IMHO it leads you down the wrong track. Abstractions are there for a reason.
Smalltalk is a good example of this. Yes it allows you to manipulate lower levels of the stack (compared with most languages). But that hasn’t resulted in creative outcomes demonstrating the value of being able to do this. Smalltalk failed in the programming language market place.
In some talks, Alan Kay mentioned something like the user understanding a simplified model in his head. I believe he mentioned the user should be able to understand a modern car through the mental model of a Ford model T.
Edit: Alan Kay sometimes also mentions "slogan land", where you state things too black and white, so that management types understand the essence. Perhaps that applies to these rules too.
I am pretty sure very few people driving cars understand how a Ford T works. Can they explain how a combustion engine works? Can they even explain the run cycle of a single cylinder? I doubt it. The mental model people use for driving cars is extremely simple compared with how a Ford T model actually works.
> Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.
That would be nice but it is pretty much impossible in practice. No uniform framework exists that is optimum for all situations and special cases. There is a reason why we still have many different programming languages and programming environments.
> Purpose of Language: To provide a framework for communication.
Programming languages are tools used to solve problems. They are not “frameworks for communication”. Except in the narrow case of a programmer reading source code.
COBOL is an example of a programming language designed with this idea in mind (Readable by non-programmers). Enough said.
> Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
Nope. Not true. Not if you want to create a successful programming language. All successful programming languages used in the real world are multi-paradigm languages.
> Messages: Computing should be viewed as an intrinsic capability of objects that can be uniformly invoked by sending messages.
I disagree. A much simpler, and more general model is to view computing as data + data transformations. The OO thinking is a more complicated subset of this.
Indeed. Since much earlier in the article the author says,
[Edit wrong paste before sorry]
>In designing a language for use with computers, we do not have to look far to find helpful hints. Everything we know about how people think and communicate is applicable.
Taking grammatical structures as the principal guide, I'd say that functional language design is the goal.
> Storage Management: To be truly "object-oriented", a computer system must provide automatic storage management.
That’s a bad idea. A single one-size-fits-all storage solution that works for all problems in all scenarios doesn’t exist. There is a reason why we use many different storage solutions as technologies to solve problems.
For the down voter(s): please enlighten us by giving us an example of a one-size-fits-all storage solution that works in all cases in all scenarios. Good luck with that.
> Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.
I like this one especially.
It rings true if you imagine a world where you have complete control over your machine, you don't worry about possibly external code breaking or extracting your stuff and so on.
But lets just pretend we don't need to worry about these things for some reason. It would be so powerful. And I don't mean you have 'root' privileges, I mean your programming environment owns, controls and _is_ everything that happens. No black boxes, no overhead, nothing. Just _one_ runtime that is integrated all the way down with the expressive power of a Lisp/Smalltalk/Self or similar. It's sad that this doesn't seem like a viable option.
People just need to start chipping away at it. Eventually it’ll exist.
My favorite inspiration for “chipping away at it” is https://ephtracy.github.io/ who has been slowly building up the coolest 3D art tools one commit at a time.
That's amazing, and inspiring. Thanks for sharing.
I’m not convinced by the logic of the “you didn’t read the article rule”. I wish we could talk about it.
Like Oberon.
The problem with environments like that is that they are never perfect. There's always something that at least some users need that they left out. But, since they're trying to be everything, they don't leave you any way to leave their world to go get something from the real OS, or the bare metal, or wherever "outside" is.
So, if you're trying to build an "everything" environment, sure, try to get everything in. But know that you will fail. And therefore, don't trap people. Leave them a way to get "outside".
> they don't leave you any way to leave their world to go get something from the real OS, or the bare metal, or wherever "outside" is.
Pretty sure the idea was and is to run Smalltalk on bare metal. Which you can absolutely do.
The more realistic problem is: what if you still need Firefox, or Office, or Photoshop? One solution is probably to run Windows and Smalltalk on a hypervisor. You still get low-level access from Smalltalk (hypervisor calls, hardware access, etc.) without giving up Windows (or Linux, etc.) apps and compatibility.
Running a web browser in a hypervisor is also probably a good idea for isolation reasons.
Another interesting idea is to run Smalltalk on the JVM (which itself was inspired by the Self and Smalltalk VMs.) You lose some low level access from Smalltalk but you gain interoperability with Java as well as portability.
In a sense that's a valid point, but what we have seems inferior in this regard. My machine is running a huge amount of individual, uncoordinated runtimes. Often there's layers and layers of uncoordinated bloat, communication overhead and everyone does his own garbage collection, scheduling format translation, gui rendering and so on. It's incredibly wasteful and the only thing that patches over it is that my computer is fast enough to handle all this crap.
/rant
I get that all of this has reasons, often historical. PC/Internet adoption just grew so fast during 80's and 90's that nobody even had the time to think it all through and design a coherent system. Even new OS's and runtimes have to carry over all this legacy stuff. I mean I get it and as a web developer I'm probably more part of the problem than the solution. But boy would computing be simpler, more powerful and expressive if we could just start over and lean on the ideas of (mostly) early, holistic visions and prototypes of personal computing.
Everyone who grew up with 8-bit micros understands what it feels like to know the whole machine.
I wouldn't say everyone. Most people just played games on them. They would have gotten a game console if their parents hadn't wanted it to be educational.
It almost is though,
Type 1 hypervisor + language runtime on cloud deployments
Past discussions:
https://news.ycombinator.com/item?id=23496800 - 2020, 87 comments
https://news.ycombinator.com/item?id=17825747 - 2018, 30 comments
https://news.ycombinator.com/item?id=13611222 - 2017, 54 comments
https://news.ycombinator.com/item?id=1758057 - 2010, 1 comment
https://news.ycombinator.com/item?id=1643098 - 2010, 4 comments
I’ve been playing around in Pharo [0] and it’s such an immersive experience! My first reaction was to compare to eMacs in that the editor/environment is the program and it can be edited, customized, extended… but Pharo/Smalltalk takes it to the next level of ease of use, discoverable and fun!
[0] <https://pharo.org/>
If you like the emacs-like aspect of Pharo, the Glamorous Toolkit project (which is built on top of Pharo) is worth checking out too. They recently released a digital notebook tool called Lepiter that has a lot of similarities to org-roam/org-babel: https://lepiter.io/feenk/introducing-lepiter--knowledge-mana...
Did they release it? The blog is about it but there's no link. This seems to be the site https://lepiter.com/ but it's just a form where you can give your email to "Register for fresh news."
It's released. It's not a separate download -- it's in the Glamorous Toolkit download (which makes sense from a Smalltalk perspective but may be weird if you're not used to it).
thanks for the suggestion! will take a look
lol don't spell emacs like that
https://en.wikipedia.org/wiki/EMac
If you're on an iPhone, doubtless its autocorrect will assume that what you meant was the plural of that other wonderful Apple product from years past.
Every now and then we get someone on freenode/libre #emacs asking the weirdest questions.
autocorrect :)
> compare to eMacs
Not sure if this is a typo, but if not it is the first time I've ever seen it typed in such a way. No judgement, just noticing.
iPhone autocorrect…
Epic.
This one gets me every time:
Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.
That combined with instant feedback can make you feel like a rockstar coder.
And Smalltalk delivers.
Perhaps "to serve the creative spirit" of the coder is not what most software development should be about?
Literally almost every piece of consumer facing software is created using languages or frameworks that derive from Smalltalk-esque principles (OOP, MVP, IDEs, etc...).
And the creative spirit is what brings innovation. Tons of what's obvious now wasn't obvious when someone created it.
Xerox PARC has certainly been influential: "The Alto software included four different programming environments: BCPL, Mesa, Smalltalk, and Lisp."
https://computerhistory.org/blog/xerox-alto-source-code/
https://computerhistory.org/blog/the-deep-history-of-your-ap...
"Even if you’re designing for professional programmers, in the end your programming language is basically a user-interface design. You will get much better results regardless of what you’re trying to do if you think of it as a user-interface design." -Alan Kay
https://www.doc.ic.ac.uk/~susan/475/AlanKay.html
Let's take that to be true, as-before — Perhaps "to serve the creative spirit" of the coder is not what most software development should be about.
Perhaps most software development should be about effectiveness or reliability or …
In the words of Christopher Alexander, the programmer is the true inhabiter of the program. Since we can expect the world in which the program should function will change, so should the program.
It is the programmer that has to figure out, often with experiments, what changes to the program work best.
Therefore it makes no sense to me to focus on anything but serving the programmer.
The better the experience is for the programmer, the more users will say "y'know what? This doesn't quite do what I want, I wonder how I change that" and presto, they're a programmer now.
We would never have had Hypercard if it weren't for Smalltalk and Alan Kay, and we've never had a platform as good as Hypercard since. That's a crying shame.
Who does the programmer "serve" ?
Perhaps we need to get rid of this artificial distinction between users and programmers.
Precisely. Every barrier in place between using a system and programming it serves to elevate the decisions of its designers over those of its users. The greatest power of computers is their ability to be reshaped to meet whatever need the user has, but we mostly lock that power away from them.
There's a subsection of people who are very well served by that. And it has already been happening. SQL, Python, HTML/CSS/JS are all things that people use who are not primarily programmers. Applications like Unity, Excel, some Adobe stuff also blur the line here.
But let's not forget that there are a ton of people (many more than the above) who are constantly overwhelmed by computers even though they only use very few features. There's people who can't use ATMs and smartphones. Most computer users only ever use the most common applications (browsers, music/video players etc).
Perhaps users want to use apps without needing to program apps?
Perhaps some want to play in a garden without needing to dig and plant and weed and…
> Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
~ https://www.gnu.org/gnu/rms-lisp.html
I think you shouldn't need to program if you don't want to understand the problem domain.
Do you think someone should need to program if they want to understand the problem domain?
Speaking for myself, I’ve never found a better way to understand something new.
Perhaps a way to understand abstract categories.
think i've seen the term 'operator' used in this context?
I sort of get where this comes from: the product should serve the users. But thinking of dev tools as the product for devs (the users in this context) is useful.
Devs code better products if they enjoy using the tools.
> Devs code better products if they enjoy using the tools.
Is there any evidence for that claim?
A guitar's design shouldn't be at least enjoyable enough to make the guitarist a better player?
I don't think we've been talking about guitars.
Only if you missed the part that this technology tries to capture "the spirit" of the creative side of the coder which is an universal, hence my analogy with making "the coder feel like a rockstar".
I asked "Is there any evidence for" the claim that "Devs code better products if they enjoy using the tools."
So far nothing has been offered.
Absolutely! Software development is all about making money, and I think this in general is at odds with creativity (different goals, methods, practices, whatnot). However, I also think that there is large group of people who does not code for money, but to make art, have fun, or express themself, and "to serve the creative spirit" is exactly what they need.
Software development is also about making things work for other people.
I agree that "most software development" is not about serving the creative spirit of the coder, but it'd be a shame to lose that! And if in some way we could have our cake and eat it (i.e. enjoy the creative process of coding for most software) sounds like a win-win to me! Idealistic, but one can dream ;)
Isn't software a form of literacy? Why should not be about? I'm not understanding yet your line of reasoning.
"Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be changed or that is not sufficiently general is a likely source of impediment. If one part of the system works differently from all the rest, that part will require additional effort to control."
Ironically, Smalltalk drives what the Clojure/DOP crowd considers the cause of this: custom languages. Creating classes means you have to know specific method names (a new language) to interact with a specific object. Eventually you can't wrap your head around it - but Smalltalk offers an env where you can come up with custom visualization to compress all this knowledge.
Another approach is DOP: your programs are all mixes of {} and [] and your functions mostly transform data.
I guess the question here is which approach represents your problem-solution with less concepts? Classes and method names? Or keys (as in {}) and functions?
You'll still end up with namespaces that contain all your abstractions, but it seems like DOP minimizes accidental complexity as the building blocks are simpler.
What Smalltalk brings that other systems lack is the visual environment for building different representations. Clojure (my DOP example) has the REPL and data browsers but these lack the expressiveness of the Smalltalk VM.
After my last foray through Squeak,
I haven't followed subsequent evolution of the language/environment;
I'm wondering: has anyone taken on integration of an idea of something like a native notion of modules/versioned package management?
I enjoyed the premises of working with changesets and a monolithic image, to a point;
but it always seemed it would not be that hard to integrate a contemporary notion of modularity...
I'd love an environment which allowed me to develop in Smalltalk, debug in an image, yet freeze the dependencies, with smart ephemeral compilation and the like, and...
Iceberg for Pharo: https://github.com/pharo-vcs/iceberg
Monticello: http://www.wiresong.ca/monticello/
I haven't used the latter, but the former is easy to use and based on libgit. Create a new repository, select the packages that go into it, make the initial commit. After that it'll tell you when the changes don't match the repo. You can select down to the method level since it's aware of the language's syntax and semantics. The generated repository looks like the Iceberg repo itself, a collection of directories for the packages and then .st files for the classes and their contents.
> I'd love an environment which allowed me to develop in Smalltalk, debug in an image, yet freeze the dependencies, with smart ephemeral compilation and the like, and…
Once upon a time, back in the day:
https://www.google.com/books/edition/Mastering_ENVY_Develope...
Haver for Cuis - and Cuis is in any case my favourite Smalltalk.
http://haver.klix.ch
I've always liked smalltalk and its ideas, but you can't use it to make shrink wrap software, at least last time I looked at it, maybe you can now. I've always thought this was a deficiency, same as Java early on.
You can't shrink wrap because …?
Requiring megabytes for a base system image (although it could be stripped and compressed) the Smalltalk runtime was once considered too large to be shipped with individual apps, and apps tended to be slow and unresponsive compared to compiled C apps. There may also have been licensing issues with shipping a runtime environment.
Fast forward to 2022. Compared to current app sizes, it's laughably small. Compared to Electron/web apps, it's probably faster and more responsive. And the licensing issues have been solved with open source versions.
iirc Stripping the vendor's development tools avoided "the licensing issues".
iirc Dolphin Smalltalk used windows controls and packed to exe.
iirc Smalltalk/X " translates the input file into temporary c-source file and calls the standard C-compiler cc to create a binary object module."
https://live.exept.de/doc/online/english/programming/stc.man...
Those sound like nice systems and stepstones to where we may be today:
- fully free/open source implementations
- native widget integration (or we don't care anymore because we're used to crappy web apps)
- the resource usage and responsiveness gap between commonly deployed apps (such as JavaScript and web apps) and Smalltalk apps has either evaporated or is less of an issue because of faster hardware and more memory
But as you may be implying, I think that there are additional barriers to Smalltalk being used more commonly, such as unusual syntax, a different workflow compared to Java/Python/Javascript/etc., lack of type safety (note that even Python and Javascript have typed versions while typed Smalltalk doesn't seem to have caught on) and the fact that it's neither considered a web technology, nor is it promoted by influential platform companies. I suspect that the Pharo people might think that Smalltalk has a bad reputation (or something) so they never say "Smalltalk." I tend to think that not calling it Smalltalk leads to a bad outcome of confusion and fragmentation.
> … lack of type safety…
Smalltalk is type safe & not statically checked.
"Type safety is the property that no primitive operation ever applies to values of the wrong type."
page 263 "Programming Languages: Application and Interpretation"
[pdf] https://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-0...
> The point here is that the human potential manifests itself in individuals.
What does this mean?
Think of "human potential" as a class, and "individuals" as instances of that class.
I think there are additional levels of human potential that express not at the individual level but at aggregates. Perhaps a MOP* for human potential?
* meta-object protocol
It is stating a simple obvious truth as if it was a profound deep discovery.
To the downvoter(s): How is the statement not an obvious trivial tautology?
(1981)
> If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.
Not true at all. For example, artists using Photoshop are typically not programmers and don’t understand the system at all. That doesn’t stop them from creating world class art. A great creative system hides all the complexity from the artist and frees them to express themselves in a way that is natural to them.
Also, understanding the complete system, from software to hardware etc. is pretty much impossible for an individual. So your “low level understanding” of a system will always be a simplified model of what is really going on.
I have seen this kind of thinking before and IMHO it leads you down the wrong track. Abstractions are there for a reason.
Smalltalk is a good example of this. Yes it allows you to manipulate lower levels of the stack (compared with most languages). But that hasn’t resulted in creative outcomes demonstrating the value of being able to do this. Smalltalk failed in the programming language market place.
In some talks, Alan Kay mentioned something like the user understanding a simplified model in his head. I believe he mentioned the user should be able to understand a modern car through the mental model of a Ford model T.
Edit: Alan Kay sometimes also mentions "slogan land", where you state things too black and white, so that management types understand the essence. Perhaps that applies to these rules too.
I am pretty sure very few people driving cars understand how a Ford T works. Can they explain how a combustion engine works? Can they even explain the run cycle of a single cylinder? I doubt it. The mental model people use for driving cars is extremely simple compared with how a Ford T model actually works.
> Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.
That would be nice but it is pretty much impossible in practice. No uniform framework exists that is optimum for all situations and special cases. There is a reason why we still have many different programming languages and programming environments.
> Purpose of Language: To provide a framework for communication.
Programming languages are tools used to solve problems. They are not “frameworks for communication”. Except in the narrow case of a programmer reading source code.
COBOL is an example of a programming language designed with this idea in mind (Readable by non-programmers). Enough said.
I think your comment is missing a crucial point or the principle, which is that "a computer can be viewed as one of the participants".
Thus writing a program is communicating your intent to the computer. I see that hard to dispute.
In that case it is a trivial obvious observation not worthy of elevating to a “principle”.
> Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
Nope. Not true. Not if you want to create a successful programming language. All successful programming languages used in the real world are multi-paradigm languages.
> Messages: Computing should be viewed as an intrinsic capability of objects that can be uniformly invoked by sending messages.
I disagree. A much simpler, and more general model is to view computing as data + data transformations. The OO thinking is a more complicated subset of this.
Indeed. Since much earlier in the article the author says,
[Edit wrong paste before sorry]
>In designing a language for use with computers, we do not have to look far to find helpful hints. Everything we know about how people think and communicate is applicable.
Taking grammatical structures as the principal guide, I'd say that functional language design is the goal.
> Storage Management: To be truly "object-oriented", a computer system must provide automatic storage management.
That’s a bad idea. A single one-size-fits-all storage solution that works for all problems in all scenarios doesn’t exist. There is a reason why we use many different storage solutions as technologies to solve problems.
For the down voter(s): please enlighten us by giving us an example of a one-size-fits-all storage solution that works in all cases in all scenarios. Good luck with that.