Pharo, the Modern Smalltalk
medium.com
medium.com
Today, there are hundreds of programming languages competing for attention. It is in your interest to put an example front and center of why one should spend time looking into yet another programming language.
Like this clock[0]:
Time now asValueHolder in: [ :clock |
[ [
1 second asDelay wait.
clock value: Time now ] repeat ] fork.
clock inspect ]
There's no excuse for not having any examples of a programming language on that programming language's home page. Here are some languages that do it right:
https://www.rust-lang.org/en-US/
Notice there at least one example (often executable!) on the home page of each site.
I'm actually pleasantly surprised how well all those sites do. Most smaller programming languages get this bit horribly wrong.
I see examples on their home page.
Then there is a textual example consisting of two lines of Posix shell, embedded in which is indeed a tiny Pharo program in a string.
The parent's point mostly stands.
(Oh, and there is a frickin' popup for a frickin' email newsletter hiding the content.)
Why would you copy and paste code before you'd done anything more than glance at a language home page?
Perhaps the better comparison is with some other languge IDE:
I haven't been able to find a clear statement of language differences between Pharo and other Smalltalks. The closest thing I've come across is this statement of intent:
"We want to stress the fact that Pharo will certainly derive from ANSI and other Smalltalks. We will not change for the sake of change. What we want to say is that if there is something that can be improved but does not conform the ANSI Smalltalk, we will do it anyway."
Perhaps a Pharo expert can clarify?
However one novel thing Pharo has added is Slots... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.653...
2. Image that you can download (30Mb) and test easily. The installation consists in unzipping the damn thing, that's all you need to run Pharo right away. If you don't like it, you delete the folder. That's the un-install procedure.
3. If you actually do test it for yourself, you'll find plenty of examples in the image itself, ready to copy/paste... OR NOT! Because actually, most of the times you don't even have to copy/paste; you can just select, right click and execute those examples.
The article might be a little too dithyrambic, but your criticism on this particular point shows more your own laziness than anything. Where is the adventurous programmer that bravely goes off the beaten tracks in order to discover new exciting things?
Over the last 15 years or so, I have regularly played around with Squeak and Pharo, and I have not found this to be the case. I mean, yes, there is code, but that's like saying "Oh, you wanna learn C? Here is the Linux source code."
Maybe I just didn't manage to find these great examples because the Pharo community's approach is "it's there, but I won't tell you where exactly; if you can't find it yourself, you are lazy/dumb/not a real programmer".
Now, your program also has state. If you want, you can also save the state of the program (i.e. by using the "save-lisp-and-die" command). This can create large files, because this allows you not only to quickly "run" the program again, but to also run it with the same state that it had when you did the save.
The runtime makes possible having the condition-restart system, and the full power of macros (your program can compile lisp code at runtime if needed, thanks to the runtime.)
From what I understand, none of this applies to Smalltalk. You always modify code on the fly, so you may end up with properties which exists, but no current code ever sets them. Or your program ends up in the invalid state, and you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete?
Repeat daily or weekly as you please.
> You always modify code on the fly
Since back in the '70s when Smalltalk was being created at Xerox PARC and used there for experimental systems development, changes were automagically recorded in a changes .cha text file.
For more information on the primitive techniques from back in those days see -- "Managing the Evolution of Smalltalk-80 Systems" in Smalltalk-80: Bits of History, Words of Advice
http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOf...
Really? So we're back to "MyImage.img.bak.2.old.works", "MyImage.img.bak.3.works", "MyImage.img.bak.2.test"?
Now that is an experience I do not want to ever have to experience again.
No, that's a bizarre suggestion you just invented, it has nothing to do with what I wrote.
So it doesn't get lost in the mass of other comments, here again is some info on Pharo's bootstrap process... http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...
That's what I loved best about Smalltalk. You could just hard quit out of the image, then go back to the Change Log and replay all but the last few changes. If you save off an image every day or so, you're always back in minutes, no matter how dangerously you've been coding.
There are a variety of utilities which let you load code quickly. Most often, deployment was done using one of these loading onto a clean or a stripped image. You can certainly control changes to your environment. In fact, I'd say you can often control them more easily than in other environments.
you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete?
The Change Log makes it very easy to figure that out. All of your ad-hoc "command-line" (do-it) state changes to the image are recorded there as well.
Somewhat related, you can use unit tests of as-yet unimplemented functionality as a jumping-off point for live-coding your way towards the right implementation, with the debugger acting as a combined code editor and REPL (since the formal parameter names in the code will have real, evaluatable values behind them - as supplied by the test case).
Were I a major Test Driven Development adherent, I might claim that this is the non-cargo-cult way of doing TDD.
http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...
" this sends a message to the transcript "
Transcript show: 'hello world '.
" compute 10 factorial and send the result to the Transcript "
Transcript show: 10 factorial.
" now, try this: "
Transcript show: 100 factorial.
" a loop (the timesRepeat-method evaluates its argument n-times)"
10 timesRepeat: [
Transcript show:'hello'.
Transcript cr.
].
" another loop "
1 to: 10 do:[ :i |
Transcript show:i.
Transcript show:' '.
Transcript show:i sqt.
Transcript cr.
].
" looping over a collection "
#('a' 'b' 'c' ) do:[:each |
Transcript show: each.
Transcript cr.
].As such, C++, Java and C#, which constitute a significant chunk of OO programming, are probably better thought of as descended from Simula (and C).
There's a clearer lineage to the likes of Ruby and Objective-C, and to a lesser extent Javascript and Python.
I would definitely concur regarding looking into it, it definitely makes you think about things in a different way.
Whether or not it makes one a better programmer, I can't say. I only programmed professionally in it for a relatively brief time and it was a hugely frustrating experience. I was glad to get out of it.
In the sense that it made me understand that a programming environment has a big influence on how well a codebase can scale then, yes, I learnt loads. But that was because it really wasn't very good at scaling without an awful lot of TLC. I moved onto a Java application which was bliss by comparison (ironically, given its reputation for classpath hell etc).
This was some years ago mind so the state of the art of Smalltalk has, I'm sure, moved on.
True, what is often called object oriented is often more about classes and inheritance, and less about (instantiated) objects communicating via messages.
It's really rather odd how Smalltalk, Strongtalk and Self could be major influences behind the jvm, jre and java - when you look at were java ended up...
[ed: on the other hand if you start with Self and add Algol syntax you get javascript - maybe it makes sense that Strongtalk and Algol makes java...]
C# is a Java clone so I need only address your Java misstatement, Java was far more influenced by Objective C and Smalltalk than by C++ as far as OO goes; it looked to C++ only for syntax. Java is semantically a direct descendant of Smalltalk and was inspired directly by Smalltalk as both of its creators knew Smalltalk and Objective C (another Smalltalk derivative). [1] Direct from the co-creator of java not to mention that Gosling himself was a Smalltalker.
So no, what we know as modern OO came directly from Smalltalk.
The difference between the two is that Smalltalk methods semantics are message passing. In Simula, method calls are just that, function calls generalized to have a receiver. And Java follows that pattern.
If Java was a direct descendant of Smalltalk, it would look a lot different. For one thing, it would have a lot less syntax baked into the language, and a lot more closures, from the get go.
And I quote..
> When I left Sun to go to NeXT, I thought Objective-C was the coolest thing since sliced bread, and I hated C++. So, naturally when I stayed to start the eventually) Java project, Obj-C had a big influence. James Gosling, being much older than I was, he had lots of experience with SmallTalk and Simula68, which we also borrowed from liberally.
A relatively simple mental exercise to prove the point is to look at various Simula and Smalltalk constructs, and see how well they map to Java (1.0) constructs. For Simula, you'll find a nearly 1:1 correspondence on syntax alone, with nested functions being the primary pain point. With Smalltalk, you'd stumble as soon as you run into the first block.
Objective-C is message-passing, Java and C++ are not.
To start Java's interfaces are loosey based on Objective-C protocols.
As for the rest,
https://i.pinimg.com/564x/b9/45/71/b9457106d7a5d602a2923597d...
https://ccrma.stanford.edu/courses/250a-fall-2005/docs/Compu...
Not really, I just assumed the one I posted was trying to highlight syntax similarity. The ones you posted are just as terse, there's no way I can figure out if the Lisp arrow to Java in your first link is something about the type system or how it handles reference or the like
[source code] -> [interpreter] -> [running program]
[running program] + [auto persistence] + [editing tools]
The syntax of Smalltlak is interesting (can be seen here https://en.wikipedia.org/wiki/Smalltalk#Syntax). But the more interesting aspects of the experience are the live editing, working with network of objects, hybrid text/non-text ways of modifying these objects, etc.
How do you use TDD when coding like this?
There were some utilities that let you run the tests at the push of a button.
You first extend the environment with tests, then add the code to make them green. All without ever having to restart the "program".
Pharo: https://youtu.be/ymITEeAOtEA
Cinecom Smalltalk: https://youtu.be/mXoxfmcDDJM
Basically you write a test first, say it calls an undefined method `x.somemethod()`. You push a button to run the test, as soon as the method call fails, the environment shows you a popup which lets you define the method right then and there, while you have all the details of the suspended execution. You can write the method and the 'resume' the execution from where it excepted.
http://files.pharo.org/books-pdfs/updated-pharo-by-example/2...
There are pictures :-)
Slightly longer discussion here: https://pharo.fogbugz.com/default.asp?W78
Really, not much different than any interpreted language, where you do source + runtime; the image just replaces the source.
For MS Windows based Dolphin Smalltalk -- "The Lagoon Deployment Wizard strips out redundant components from your image and shrinks your code down to a tight, single click EXE file. Alternatively, you can choose to additively compose your application by building it up from the raw Dolphin boot image."
So, based on these slides about Pharo 6[0], it seems that they use multiple things. First, they have a tool called Epicea, which is a more modern way of tracking changes to an image[1]. Then, for git integration, they have a bunch of tools at pharo-vcs, specifically Iceberg[2].
[0] https://www.slideshare.net/pharoproject/pharo-6
[1] http://smalltalkhub.com/#!/~MartinDias/Epicea
[2] https://github.com/pharo-vcs, https://github.com/pharo-vcs/iceberg
Typically with Smalltalk you would have an Image live on and on and maybe forget how to create it from scratch. And depending on your audience, you may have wanted to strip out development tools, something like this old example for Squeak... http://squeak.preeminent.org/tut2007/html/205.html
Pharo has put a lot of effort into "bootstrapping" the Image via CI to address this weakness of Image based systems. So you only need to load the parts you want in a reproducible way.
I'll take "powerful" versus "cleanest and purest" any day, thank you very much. Sorry but i'm staying with CLOS whenever i want to do object-oriented programming without feeling limited.
The author is on a pro-Smalltalk crusade (which I find just fine, Smalltalk is a great lang, and in a perfect world, it would be as popular as Javascript is today), but does so at the expense of constantly deriding Clojure, Common Lisp and Racket, which I find silly.
whenever i am in the process of picking a language for a project, i check if there is a library for what i want to do
Every time I need to get something done of any magnitude, it reminds me why I prefer Clojure to Common Lisp.
So... What "systems" said. Truly, Clojure is a Lisp for Getting Stuff Done, as it has access to an astounding number of libraries targeting the JVM, largely allowing you to focus on your product's core.
He has factually pointed out that most people are turned off by Lisp syntax. This is not an insult, simply a statement of fact.
One interesting "killer app" might be the Moose platform [0]. It's basically an interactive environment for the analysis of software. Writing a parser is rather straight-forward and turning the AST into a visualization is also quite easy. This sort of feels like how I imagine a good IDE should be.
[0] http://www.moosetechnology.org/
update spelling.
https://www.fun-mooc.fr/courses/course-v1:inria+41010+sessio...
Edit: Actually, the course starts on October 16.
Something like:
ProfStef go.
And right-click do after highlighting. Stefan Decasse is a French professor that does a lot for the project.
I think there are ways around this, but you may have to dig deep to find out how.
GNU Smalltalk is different: It doesn't have this traditional interaction mode. Many Smalltalk fans will probably find that that's a disadvantage.
Actually, the standard end-user experience is to launch an application which interacts on the console or opens some windows.
(There'll be some system startup methods which define what happens when the image launches -- don't open the development environment windows, open the application windows).
https://www.youtube.com/watch?v=WLoXXFxU8lw
The images on the current website look very similar, so I don't it's changed much in this regard. This has been my typical experience with Smalltalk languages, with the exception of GNU Smalltalk whose specific goal is to integrate with POSIX instead of creating a walled garden.
I don't recognize whatever operating system the demo was done on, so if the Pharo system is not using native widgets I would not know, you'll have to explicitly state if this is the case.
I don't think you can draw a general conclusion about Smalltalk from a specific example, especially like this one.
This is a misleading claim often made by the author of this Medium article. Smalltalk code does reside in text files and the IDE keeps them. This is apart of the "image" that is also kept by the environment to enable faster loading and store state.
However, you completely miss the point of smalltalk by doing this.
Their UNIX versions are handicapped versions of themselves.
Languages with rich runtimes and developer tooling are always shoehorned into POSIX model to "feel UNIX".
They provide a rich graphical developer experience, with many features that are the genesis of modern IDEs, and nothing on their standard library and runtime depends on anything POSIX related.
The Lisps that "integrate well" with UNIX, like SBCL, do so by providing a UNIX text based repl without that graphical power, while using Emacs, an editor based on Lisp Machines, that even with SLIME is not quite like the commercial Lisps.
Same applies to any other language with a rich runtime, that makes the underlying OS irrelevant.
Instead, in a Lisp on Unix, I'll call mmap and either have to manually check for an error or use a wrapper which does that for me. If there is an error, I'll have to re-call mmap.
It's not terrible, and it's still a lot better than using e.g. C — but it's not as good as it could be in a Lisp-all-the-way-down system.
PLT Scheme (language) → Racket
DrScheme (environment) → DrRacket
Yes, Pharo (and Smalltalk) is a world unto itself but that's the price you pay for a highly productive, easy-to-program software development environment. How are you going to achieve this by retrofitting to an archaic methodology based on text files and over-engineered IDEs like Visual Studio and Eclipse? Java and C++ impose severe constraints and compromises in this respect.
At the end of the day, it's all about a programmer's ability to adapt to new methodologies. If they remain rigid and stick to old, familiar ways, there can be no great improvement in the way we create software.
That's good news that does not appear in official documentation (last time I checked).
> Yes, Pharo (and Smalltalk) is a world unto itself but that's the price you pay for a highly productive, easy-to-program software development environment.
Users want standalone software. They don't want to be forced to run programs in your highly productive IDE. If your IDE is marketed to programmers as "a shiny IDE you will never be able to escape from", programmers won't use it for fear of not being able to deploy software in a way that users would accept.
> remain rigid and stick to old, familiar ways
You know what has never ever worked for promoting programming languages? Insulting people who don't use your language.
> Insulting people who don't use your language.
How am I insulting people??? I'm making a factual assertion, completely devoid of judgment.
"GNU Smalltalk -- The Smalltalk for those who can type"
http://smalltalk.gnu.org/As I mentioned above, Smalltalk is also file-based; when you distribute a smalltalk program source, you distribute a set of source text files.
Just like any other typical programming language.
What Smalltalk does is not remotely what you do in other languages and when we say file based we're referring to that difference, file oriented programming vs image oriented programming.
A Smalltalk program is not a collection of files one works with, it doesn't fit into the standard file based workflow, you cannot without jumping through many hoops, work on a Smalltalk program from your standard editor using your standard unix tools and file based workflow. So when we say file based, it's this we're referring to, do not lie to people and claim Smalltalk is file based, it is not. Smalltalk is image based, you work with its dev tools on a running object model in an image; having the option to export that to a file after the fact is not remotely the same as being file based; that the image stores source code in a changes file, or that we share code between each other with st exports does not a file based language make.
St files by the way are a serialization format, they are not meant to be hand editable and are not treated as such and contain all kinds of non-Smalltalk stuff related to the serialization format; we don't edit st files and compile them, we edit in the image and import/export st files to share code between images.
I'm a Lisper, i do know what Image-based development is, because that's what I use*
You're misunderstanding Smalltalk, probably because of hype mongers like the author of this article. Source is text files as usual. This is not the same as the image. Your environment, and the compiled classes, are contained in the image, but the IDE also keeps the source, text files.
>St files by the way are a serialization format, they are not meant to be hand editable and are not treated as such and contain all kinds
.st __source__ files are text files. You are confusing them with the image files.
Don't tell me what I'm thinking and because of who, I make my living with Smalltalk (Squeak and now Pharo) and have for well over a decade and have done hundreds of millions in revenue through my Smalltalk apps.
> .st source files are text files.
I didn't say they weren't, they're still a plain text serialization format that is not directly what Smalltalk looks like and we still don't work on code by editing those files.
> You are confusing them with the image files.
No I'm not, if you actually read what I wrote, you'd see that.
Lisp is not Smalltalk, do not confuse how Lisp does image based development with how Smalltalk does it; they are not the same. When you have a few years experience actually working with Smalltalk doing production level stuff, then come talk to me, right now you're repeating nonsense that you're inferring based on apparently some light reading and no actual experience in the culture of and use of an actual Smalltalk.
If your image crashes it gets reconstructed from those two files.
It would be great if you Smalltalk fans would explain its source handling in these terms above, instead of promoting "image based" as some sort of magic where there aren't any text files, because in this forum some programmers are getting (needlessly) scared about the image-based system and (needlessly) fearing it.
The .changes and .sources text files are maintained in-the-background by the IDE and kept in-sync with the image file.
With that comment, you lost any good will I had for you. Despite that, I tried to explain to you anyway what we mean by file based and you simply ignored it and chose to argue with me about st files being plain text which is entirely irrelevant to the conversation. What more do you want? You're wrong, Smalltalk isn't file based, but you don't seem to know what Smalltalk'ers mean by that term, and you refuse to admit you're wrong despite you not even being a Smalltalker. That's willful ignorance, I have no patience for willful ignorance nor do I have any duty to the Smalltalk community, something I know vastly more about than you as I've been a member of it for a very very long time.
The object inspector is really nice, also being able to redefine methods in the debugger and continue the current computation is super cool. Beats poring over Java stack traces.
It would be nice if there were more open source libraries available, but SmalltalkHub is getting better: http://smalltalkhub.com/list
I learned Racket and Smalltalk to be a better problem solver. I ended up becoming a MUCH better programmer due to these two. Racket stuck and I use it for all my personal projects but Pharo is a great learning tool at the very least.
Having said that, the PharoJS website mentioned in the article could use some love, I just get an unstyled webpage[0]. Now, I love avoiding website bloat as much as the next guy, but from the point of view of a web developer who might be interested in exploring what Pharo and Smalltalk in general might have to offer, that seems a bit too minimal.
Amber, by comparison, runs a full SmallTalk on the website itself, which is pretty cool[1]. Doesn't seem to have maintained momentum beyond 2014 though.
This seems to be you maligning Capes Jones without evidence.
Does anyone understand what this is talking about? I may not understand exactly what is meant by "live coding", but I think I do it in Common Lisp (via SLIME) all the time. How is it better in Smalltalk?
JavaScript Time-Travel Debugger
https://www.microsoft.com/en-us/research/project/javascript-...
https://channel9.msdn.com/blogs/Marron/Time-Travel-Debugging...
Programming in Pharo is usually done either in the class browser or the debugger so that you're only ever seeing the code for one method (called a message in Pharo) at a time. Pharo and other Smalltalk variants tout simplicity of syntax but leave off the fairly complicated class hierarchy and message coupling semantics ergo the necessity for an extremely powerful browser. In the browser, messages for each class are further separated into 'protocols' such as methods for 'accessing' or 'initialization' (these are not part of the Smalltalk syntax, just a convenient layer of organization). At each level in the hierarchy, the Pharo code browser gives you a nice template to edit when you want to make a new package, class, or message. The overall effect is that you're only ever working with a handful of lines at a time and, indeed, Pharo will warn you if it thinks your message is too complex. Doing things this way actually makes everything quite manageable. One of the nice features of being pure OO is that everything is a pure black box so you just need to know that a class exists and take a peek at its interface to use it effectively.
To that end, Pharo actually has an excellent search tool that's not present in other Smalltalk variants like Squeak or Cuis. It does some kind of intelligent voodoo and can find anything from definitions to instantiated objects to senders and receivers of a certain message and so on. You can also open up a playground window to experiment with whatever code in the REPL style. But it's actually a little bit more robust than a traditional REPL because of the pure OO nature of Smalltalk. The thing you get back from evaluation isn't just some text. It's an object with all the associated possibility of reflection and manipulation (which can all be done from a UI, not just from evaluating more code).
One of the things Pharo does better than almost every other language is debugger integration. Pharo is like LISP in the sense that you can start an application, have it encounter an error (or just pause execution at will), drop into the debugger and change some stuff, reify whichever execution stack frame, then resume the program as if nothing ever happened. This is the essence of the other common Pharo workflow: write some partial code and then fill it in incrementally in the debugger until you have a fully functional and bug-free application. In addition, Pharo has its own robust unit testing system called Sunit that, coupled with the debugger workflow, creates a fantastically ergonomic TDD experience.
No matter where you are in the Pharo environment, Smalltalk code gets full treatment (E.G. syntax highlighting, code completion). So what does the syntax look like? Well, it actually has that concatenative elegance of Forth plus a few other constructs. Pretty much everything is a message send. Message sends come in three flavors: unary, binary, and keyword. Constructs like conditionals are also just message sends. In addition, there are first-class lambdas (called blocks in Smalltalk). Here's the canonical factorial program:
"Factorial function" fac := [ :n | (n = 0) ifTrue: 1 ifFalse: [ n * (fac value: (n - 1)) ] ].
where " ... " is a comment, ':=' is assignment, '[ ... ]' is a block, ':n' is the block's argument, arithmetic operators are actually binary message sends, things like 'ifTrue:' are keyword message sends (unary message sends are similar but don't have colons or parameters e.g. 'SomeObject new.'), and the statement is terminated with a period. Apparent recursion is fine because Smalltalk uses late binding. Aside from some syntax for strings and class declaration, that's basically it.
Pharo also has a lot of other nice features such as keeping a log of code changes in case of program crash or power outage, an integrated package manager/version control system, and optional git integration. It's all pretty easy to use and overall the system is quite impressive with a high degree of polish and decent performance (comes close to or exceeds node in my experience). However, as others have stated, it's a walled garden. All UI interaction happens within the Pharo environment with no option for native. If you want to break out on UNIX, you have write some kind of server and use sockets or the filesystem (which isn't a huge handicap in the grand scheme of things). On the other hand, application deployment is a little iffy. There's no readily apparent scheme to pare an image down to just what your project uses and then distribute that; users would have to install your package from within their own Pharo environment.
This way of developing, called by some as "Living in the Debugger", is strangely not promoted all that much by the Pharo community as far as I can see. It is quite astounding for productivity. In essence, you write some very high level code in a space, "do it", and Pharo will prompt you all the way for what it needs to make that high level code work. So you end up with code you need and no more. I have changed my whole thinking about writing software according to this pattern, even when writing in other languages (Guile, Erlang, Ada, Lua...). My Pharo remains my favourite.
1.) How fast are programs written in Pharao?
2.) Is it possible to write complete and halfway modern looking desktop end-consumer GUI applications in Pharao?
3.) How good is it at parallel programming (i.e. multicore support, not just concurrency with green threads)?
I'm always interested in learning a new language, if not just for fun. Currently my new language on the Todo list is Nim. However, I do not want to take a look at a language for which the answer to all of the above questions is "Meh".
2) Yes, but ou will not use native widgets. The way you write applications is: you write code by modifying the behaviour of objects in the Pharo application (which is your editor, debugger, GUI, version control system and so on), then you strip off the parts you don't need (such as what you used to write the application in the first place). Hence you will probably use the default Pharo widget system (take a look at some Pharo screenshots to get an idea)
3) Last time I checked it was planned, but there was nothing yet
However, I've looked at screenshots and the default widget system seems fairly reasonable. So I'll check it out anyway.
Thanks a lot for the replies, they were helpful!
If this is true, then it's much slower than LuaJIT, Lisp (SBCL) and probably Chez Scheme: Three great dynamic programming languages worth checking out, by the way.
[1] http://files.pharo.org/books/spec-tutorial/ [2] http://books.pharo.org
To understand Smalltalk in general one neeeds to understand the impetus; and behind it is Alan Kay. What we do today isn’t really “computing” as envisioned and then created in the 70s. Lots of those terms used back then are used now, but the meaning has been transformed into something entirely different.
It’s unfortunate that most of the things we call “state of the art” are bastardized and horrible versions of those from the 60s and 70s. Yet here we are in 2017 and we can’t have the majority of “computer users” create an essay defending his/her views on climate change with an actual editable running model upon which a civil discussion could be based on. But hey, we will have an iPhone X, so who cares?
Smalltalk is like a gem, a remnant from a magical world that existed and went away - but still possible - if we just took a look way, way back as to where it all originated.
For the CS students out there, get your money’s worth and start asking where all this stuff we have now came from and more importantly, why.
Here’s a good start:
A Personal Computer for Children of All Ages: https://www.mprove.de/diplom/gui/kay72.html “The basic idea is to exploit the duality between functions and tables (or processes and memory). English has nouns which refer to "objects", and verbs which refer to "actors" and "relators". This is a Newtonian epistemology. Modern physics and philosophy tend towards the idea that both "objects" and "actors" are just different aspects of the notion of process. A process has state (a set of relations having only to do with it) which changes as time (defined as interactions with other objects) passes. Using this view "data" is a process which changes "slowly", "function" is a process which changes more rapidly. Each process has the logical attributes of a complete "micro" computer: they can have inputs, give back outputs, act as a memory on file system, perform computations, be interrupted, etc. Since a "computer" can simulate all other computers (modulo time and space), having the notion of a process in a language allows useful idea such as arrays, records, recursive procedures, etc., to be added to the the repertoire at any time.”
(I can only go on tangents since I saw the nag screen and bounced.)
I think some system of anonymous digital micropayments, integrated with the browser, is the only thing that's going to save us from paywall/adwall hell.