50 years Smalltalk anniversary celebration at Computer History Museum

https://computerhistory.org/events/making-smalltalk/

by pjmlp • 4 years ago

159 92 4 years ago

chasil• 4 years ago

It was interesting to learn that Smalltalk originated as a language for children, rapidly developed by Alan Kay for the Alto.

It's a shame that the more simplistic branch didn't endure, perhaps as an alternative to Logo.

chriswarbo• 4 years ago

It's a shame that the more simplistic branch didn't endure, perhaps as an alternative to Logo.

Scratch was originally built in Smalltalk (newer versions use JS)

A rival to Scratch, which is also written in Smalltalk and is 'closer' to 'proper Smalltalk' is EToys http://squeakland.org

jecel3• 4 years ago

The original name for Smalltalk was "Slogo" for "Simulation Logo" (like Simula was for simulation in Algol). It also reflected the expected performance of the first implementations.

http://worrydream.com/EarlyHistoryOfSmalltalk/

thrdbndndn2• 4 years ago

As someone who learn programming relatively late, the only thing i know about Smalltalk is it highly influenced Python. However, I just checked Wikipedia article about Python [1], it has no mention of Smalltalk. Did I just remember it wrong or there is more to it?

[1] https://en.wikipedia.org/wiki/Python_(programming_language)

pfarrell• 4 years ago

I wasn’t aware of a Python connection (not saying there isn’t one) but Smalltalk definitely influenced Ruby. I think if it as a more direct descendent with the way objects pervade it and how “everything is an expression.”

andrewl• 4 years ago

Yes, Yukihiro Matsumoto, who created Ruby, took inspiration from Smalltalk and Perl, among other languages.

bmitc• 4 years ago

I think you remembered it wrong. I personally have never heard of such a connection. Python is somewhat notorious for ignoring languages like ML, Lisp/Scheme, and Smalltalk dialects.

thrdbndndn2• 4 years ago

Thanks, probably just remembered it wrong.

Which language influenced Python most, if there is one?

noneeeed• 4 years ago

It’s Ruby that was influenced by small talk, especially its approach to OOP.

Rochus13• 4 years ago

the only thing i know about Smalltalk is it highly influenced Python

Which is wrong. See e.g. http://python-history.blogspot.com/2013/10/origin-of-metacla...: "I was only vaguely aware of Smalltalk at the time; I remember being surprised by its use of metaclasses (which is quite different from that in Python or Ruby!) when I read about them much later."

pedrow• 4 years ago

Also it influenced Objective-C[0] - it's mostly C with message passing added to it.

[0] https://en.wikipedia.org/wiki/Objective-C

zelphirkalt• 4 years ago

Ruby is the one heavily influenced by Smalltalk. Python I am not so sure.

mbrodersen2• 4 years ago

Anybody here using Smalltalk in production?

melvinroest5• 4 years ago

At Yesplan [1] we use GemStone in production, we use Pharo for development. The languages are quite alike, but we do need to have a compatibility layer between the two. For example, GemStone doesn't have dynamic arrays (arrays that evaluate expressions of each element).

Our CTO knows companies that use Pharo in production. I'm sure there are also people using VisualWorks in production. All of these languages are Smalltalk descendants.

[1] http://yesplan.be

rbanffy2• 4 years ago

Would you say Smalltalk is a competitive advantage?

jeffreygoesto• 4 years ago

These guys do:

https://www.etas.com/en/company/news-archive-2018-28208.php

Rochus13• 4 years ago

Yes, in the early nineties; learned me to appreciate static typing and avoid image based languages.

arnsholt• 4 years ago

In a previous job I worked on the case management software used by the Norwegian police. It was first put into production in ‘96, based on an earlier system from I think ‘94 (thus the Smalltalk). All criminal complaints in Norway pass through this system.

As a developer, I found the system really nice to work on, despite an antiquated Smalltalk implementation at the base (end of lifed in ‘99). Since the IDE is integrated into the running application, the development process was extremely smooth for a desktop application like that. But the process was an acquired taste, not all the developers got into the groove.

sebastianconcpt6• 4 years ago

Yes. At https://telna.com/ we have it in a backend that in last july it was helping to route half petabyte of network traffic and is expected to reach 1 PB by the end of this year.

melvinroest5• 4 years ago

Cool! I program for around 7 months in Pharo now at Yesplan [0]. We're hiring a devops engineer and a software engineer. While the Pharo website [1] avoids mentioning it, it's a Smalltalk descendant.

What I like about Pharo:

1. Programming in the debugger makes things feel much quicker

2. Evaluating expressions inside your code editor makes programming feel much quicker

3. The ability to quickly browse classes and methods makes programming feel much quicker (e.g. I type Date somewhere, select it, press CMD+B and now I browse the Date class).

Don't get me wrong, Pharo has downsides, especially when it comes to using it in production (IMO). With that said, the language feels fun to use! I definitely like it now as my first language for side projects as it is more graphical, more playful, and feels quicker for iterative development (e.g. when consuming APIs). It's why I wanted to learn it in the first place, it has shown me a different philosophy on how programmers interact with a programming language and IDE.

[0] https://yesplan.be/en/vacancies

[1] https://pharo.org

codesnik2• 4 years ago

I always wondered, how do you deploy it? Are you able to use git or other VCS? Are there other developers working on the same image?

melvinroest5• 4 years ago

I don't know much about deployment. In terms of version control, we use git. I find it a bit tricky though as there's a git repo inside the Pharo image, and then there's the file based git repo and they need to be kept in sync. I've gotten used to that though, but it's not ideal.

Every developer has their own image. It's easy to set up an image (though I always need to check the company docs on how to exactly do it), but then you download your own image. These images can be different from each other as well, as only the code checked in to git is the same.

0x4454424• 4 years ago

The image is just an in memory representation of the code. At any point one can export the code representation in the image to an external text file in a number of different formats. These external text files can be version controlled with Git or any other VCS. In turn the the text files can be imported into an image as well. I never worked with Smalltalk professionally but I imagine deployment works in a very similar way to the deployment pipelines you might be used to.

Start with a base image, import code pulled from the VCS repo, start the image, run some test verifications and copy the image to its designated virtual insurance host.

sebastianconcpt6• 4 years ago

The way I like to deploy a Smalltalk backend service is when developers have their cloned git repos and follow gitflow, one new directory for a new branch, so they can:

1. Build a local image intended to help with 1 branch (branched out of fresh cloned develop).

2. Add changes, unit and system tests for TDD/regression defense/coverage.

3. Commit and push code to share with the teammates.

4. Open PR to develop when ready/PR's approved

5. Eventually merge develop into master and version bump for release

6. The PRs running CI/CD pipelines with the full battery of tests and

7. The final docker image that devops can consume at will for deployment under their load balancer or whatever architecture they had setup.

In this style, images generated by work on bugfix or feature branches are optionally disposable after its PR. The dev can choose to archive or not.

O_H_E• 4 years ago

Hi, do you think you guys would be open to hiring an 8 months paid internship?

noSyncCloud• 4 years ago

Interesting, thanks. It does mention the Smalltalk influence on the cheat sheet [0], interestingly enough.

0. http://files.pharo.org/media/pharoCheatSheet.pdf

thedracle• 4 years ago

AFAIK Pharo is a fork of Squeak, which is much more open about it being a smalltalk programming system implementation.

https://squeak.org/

Qem2• 4 years ago

Sometimes Pharo is criticized for not displaying more prominently its Smalltalk roots on its site and promotional materials. IMHO, I think the Pharo team has good reason to do so. So far it is mostly compatible with Squeak, but breaking backward compatibility is left on the table as a possibility in the future. So they applied the lesson Perl folks had to learn the hard way, until they perceived it was better to recognize Perl6 as a new language and rename it to Raku. When developing new things, calling them by old names sets expectations and causes people to make lots of implicit assumptions.

hazelnut-tree• 4 years ago

I posted a talk on HN recently about four programming languages from the 1970s - Smalltalk was one of the languages discussed.

Smalltalk has a object-oriented programming model (OOP) with notable differences to the more familiar OOP model from languages like Java and C#. Smalltalk also has an windowing IDE (eschews separate text files), a consistent model, and minimal syntax (just 3 keywords). It's a very interesting language.

Here's a Smalltalk demo from the talk: Four Languages from Forty Years Ago (2018) (44min mark): https://youtu.be/0fpDlAEQio4?t=2641

Rochus13• 4 years ago

with notable differences to the more familiar OOP model from languages like Java and C#.

This only applies to Smalltalk-72 (which is celebrated this year). The Smalltalk we know today started with Smalltalk-76; like Simula or Java it has inheritance and compiled virtual methods (i.e. no longer passing tokens to objects for interpretation). Smalltalk-80 celebrated its 40 years in 2020 on which occasion I implemented a couple of tools and VMs to study its inner workings, see https://github.com/rochus-keller/Smalltalk.

a consistent model, and minimal syntax

Which is mostly beneficial for the parser writer; implementing an efficient VM for Smalltalk is still an art today, because nearly everything is a closure and the control flow has to be guessed; in any case Smalltalk can at least pride itself on having initiated a development that led e.g. to Java Hotspot and the V8 engine.

santiagobasulto• 4 years ago

Smalltalk is one of my favorite languages and definitively a great one to teach real Object Oriented Programming.

Off topic: the documentary seems interesting, but I hate the narrative: basically, "Jobs/Gates stole" and "we were the rightful knights inventing computing, but now it's used for Games/Porn/Chat/Leisure ergo it's bad". Kind of gatekeeping. Computers evolved and they're everywhere. Sequencing protein chains and also behind Candy Crush.

iamwil• 4 years ago

For another take on Smalltalk, we covered it as a retro-future episode on our podcast. https://www.youtube.com/watch?v=FZNqOFAhM8o

Some of what we covered:

  - OOP is message passing
  - The interactive environment
  - Surprising things about Smalltalk
  - Did Smalltalk achieve its goals?
  - Failure of Enterprise Smalltalk

Rochus13• 4 years ago

OOP is message passing

No longer true since Smalltalk-76, which has virtual method dispatch like Java. What you refer to is probably Kay's philosophy which is something else than the Smalltalk implementation we know today.

0x4454424• 4 years ago

Can you elaborate on this because this has been bugging me for some time. I’ve heard Kay’s comment many times but I have never heard him give an explanation as to what practical difference it would make in the day to day task of software development, specifically with respect to Smalltalk 80. When I think of message passing I think of things like Kafka, message queues, ESBs etc. Where the producers and consumers of the messages are completely decoupled and the processing is asynchronous. But I’m not sure how this maps to a thread/proc local context where a caller of a function or method or the sender of a “message” expects a response.

coldtea3• 4 years ago

You're talking about the internals and optimizations. Smalltalk still uses message passing as the concept, even if it doesn't send an actual a message for the recipient to parse under the covers.

That's how you can trivially have distributed objects, instances responsing to methods they don't directly declare and know about, etc.

frou_dh• 4 years ago

I was happily surprised that the Lively Kernel project (https://lively-next.org/) still seems to be being worked on some years later, at least according to GitHub activity: https://github.com/orgs/LivelyKernel/repositories

Though, from the outside, it's not particularly clear what's what amongst all the differently named versions, and which direction it's being driven in these days.

scroot• 4 years ago

There is also the Smalltalk Zoo [1], where you can try several of the old systems which have been reimplemented in Lively:

[1] https://smalltalkzoo.thechm.org/

nanna• 4 years ago

Recommendations for a Smalltalk intro?

Qem2• 4 years ago

My introduction to the Smalltalk family of languages was through the Pharo MOOC: https://mooc.pharo.org/

Pharo is a descendant of Smalltalk, forked from Squeak. Free books are available at https://books.pharo.org/

mikro2nd• 4 years ago

Download Pharo or Squeak and start playing with it. Both (iirc) come with tutorial stuff. Or, if your feeling more adventurous, try Glamorous Toolkit (gtoolkit.com) which comes with has tons of teaching material (in the tool itself) -- also well worth investing some hours in watching some of their videos.

peatmoss• 4 years ago

This article is a painful reminder of the demise of the Living Computer Museum in Seattle, where one used to be able to play with an actual Parc Alto :-(

robbrawkly2• 4 years ago

But they did develop the only real emulator.

https://livingcomputers.org/Computer-Collection/Vintage-Comp...

robbrawkly2• 4 years ago

When is that film coming out? I'm ready to buy now!

Decabytes• 4 years ago

I would love to see a modern Operating System built off of SmallTalk. I tried out Pharo recently and I was amazed at its ability to introspect (reflect?) into any ui element in the running image and see/change the code for that element. I think building an entire Operating System on this concept would be really cool. The level of extensibility we would get combined with the ease of extending the OS would lead to some pretty awesome changes.

To get around some of the common pitfalls of new Oses it could use a rump kernel and leverage the drivers from Netbsd, and it could be developed on an SBC making it easily accessible to people to run on actual hardware

linguae• 4 years ago

I agree with you. One “what if” possibility that I think about from time to time is an open source community back in the 1990s rallying behind an OS built from Smalltalk or a language environment offering similar capabilities such as Self or Common Lisp. I figure a Pentium or PowerPC personal computer from circa 1994 should have enough power to drive an entire ecosystem of applications around Smalltalk, especially with the compiler and virtual machine innovations the Stanford/Sun researchers working on Self made. The environment’s introspection and metaprogramming capabilities would have resulted in a highly flexible, extensible system, but with a simpler and cleaner design than contemporary Windows and Unix desktops, which have many layers of complexity.

Recently I’ve thought about making a Smalltalk- or Common Lisp-based operating system with the features you mentioned, but I ended up changing direction when dealing with the problem of interoperability among different languages. As appealing as Smalltalk and Common Lisp are, many people prefer different languages, and unfortunately different languages have different semantics, making interoperability difficult. I prefer a protocol-based approach to interoperability. I’m right now experimenting with Plan 9, an operating system designed by many of the same people who worked on Unix at Bell Labs, and seeing how I can implement reflection and metaprogramming through Plan 9’s “everything is a file” facilities, and also how I can take advantage of the 9P protocol to enable component-based software design. Some more of my ideas can be found at www.mallowos.com.

jonjacky• 4 years ago

A recent start on this could be the NopSys/CogNos project, which built a standalone Smalltalk system on x86 a few years ago. There are GitHub repos[1,2,3] and a paper [4] where the authors write "there would certainly be much more work needed before one could consider deploying our system." The project seems to be inactive now.

1. https://github.com/nopsys/nopsys

2. https://github.com/nopsys/CogNOS

3. https://github.com/nopsys/SmalltalkNOS

4. https://charig.github.io/assets/papers/SCDE-DLS.pdf

morphle• 4 years ago

I still have a free ticket for the live event left over

50 years Smalltalk anniversary celebration at Computer History Museum

Related Stories