The Early History of Smalltalk (1993)

You may find this interesting:

"Smalltalk at Tektronix" STIC13 2013

https://www.wirfs-brock.com/allen/files/tek/Tek-Smalltalk-hi...

I can recommend the book "Smalltalk Design Patterns Companion" for the purpose of - learning Design Patterns. Because of Smalltalk's simplicity the design patterns' "essence" comes through more easily than in a clunky low-level language like C++. This book also provides good examples of what good Smalltalk code looks like.

I’m not very far in yet, but three thoughts:

* thank you, thank you, thank you (that’s only one thought)

* the fact that Smalltalk is objects all the way down (methods, stack frames) is impressive

* his camo shirt (look at the chair) is quite distracting

Man, you're harshing my buzz.

I'm of a similar opinion (having been a Smalltalk developer in the 1990s boom) but I think it's worth looking at for modern programmers. I wouldn't use it for anything myself any more, but for me it's a nice way to get the flavour of the work being done in the AI community and at Xerox Parc in those days. Like a history book you can crawl into rather than just experience vicariously.

One thing I do find interesting is that the programmers who usually come up as "legendary" in this context were usually just better than average guys who ended up in the right place at the right time. A lot of their code is still running in the Cincom VisualWorks product and not all of it is gold.

maybe the best we can do is learn from smalltalk, especially the idea of being immersed in the language itself as the "os" where we can make any tools we need when we need them, right out of the environment as if it were pen and paper except its a programming system

think about how we easily make scripts and tools etc in the terminal, now imagine that for your whole os including the gui, it could be very empowering for the average person

Curiosity, mostly. I have no plans on doing anything major (let alone released to an end user) in Smalltalk, but it's a very different mode of programming than most of what I've done in my professional life (largely dominated by work in the embedded systems space and a lot of tooling around that). On the desktop side, by fiat, I've spent a lot of time with C# for new development, and a bit with some older C++ and Java systems (with the current job, more those two).

Because of the way that embedded systems work, you can't easily escape the standard build, load, test cycle (at best, on some projects, you get simulators to help speed up test), and deployment is often delayed for, sometimes, good reasons around coordination with a fleet of systems.

On the desktop software side, because I haven't convinced my employer to go with smaller batch sizes for releases, we still have big-bang releases every 3-6 months (and the first year with COVID we didn't even hit that pace with remote work growing pains). When an end user comes across a non-critical issue, this means they will be waiting months to have it addressed (if it gets put into the next release, it could be years in a worst case).

This leads to end user empowerment, at least in principle. One of the current systems I'm working on has a pretty comprehensive scripting language (a bespoke DSL) that lets end users (not formally trained as programmers, and their job isn't to work as programmers) extend the system to meet their needs without calling for help most of the time. None of the other systems do that, but most could without hitting any corporate IP issues (the customer, in our case, owns most of the source code anyways, but they aren't a software company and outsourced the development and maintenance work). Smalltalk (the system) is an extreme case of end user empowerment and I wanted to explore that concept.

It still has many cool features that are not common elsewhere, and it is still evolving (https://pharo.org/features, the list does not mention some things like object-centric debugging). And yes, it can pay your bills.

Well, I work 9-5 with it since 2006.

Some desktop apps, some fullstack web apps and lately backends.

I must disagree. Image concept is just a tool, and it only depends on how you use it. In Smalltalk, you can modify the "base-objects" and assign these changes to your package and export them with the other sources (managed by Git, for example), so there is no difference to JavaScript here. But unlike JavaScript and others, you can use the image for things like saving the system state with a debugger open on a bug that is very rare and hard to reproduce.

Let go of that meme, it's just wrong —

https://news.ycombinator.com/item?id=30917420#30939981

> … programs you develop "on it" will not run on anybody else's image.

You seem to have confused the image snapshot with the virtual machine.

As-if .class files were the JVM.

I could be wrong because I don't know much about Leibniz's monads, but aren't those a completely different thing from Haskell monads?

I don't just mean "slightly different" like how arrays in javascript are slightly different than arrays in C. I mean like they are completely different ideas/concepts that happen to share the same word. I think "Homonym" is the right word for this situation?

>Love this line as this was definitely my impression of monads when venturing into Haskell-land

Despite the name though, Leibniz monad's don't have anything to do with monads in category theory/math and Haskell.

In Leibniz the name monads is used for a philosophical concept, kinda like a blend of "atoms" in Democritus and platonic "ideas" ("https://en.wikipedia.org/wiki/Monadology")

>I started programming in 1979 and throughout my long career I have constantly been exposed to various Smalltalk articles and genuflections.

With that experience, what do you think of the state and directions of the computer industry today?

I started programming around 1972 or so, so we are likely of similar vintage. I think we tend to find what we seek. I have found much to learn from Smalltalk and Lisp in the fifty years since I first wrote FORTRAN programs on punch cards at UofT's High-Speed Job Stream, and while yes, there are various people whose enthusiasm and narrow focus rivals any religious cult...

Here's the thing. Some people will hate a thing so much they'll accuse you of professional misconduct for using it. Seriously, you can find people who say, in writing, that programming without static type-checking is professional misconduct.

Should that stop us from using JavaScript, Clojure, Ruby, Python, &c.?

No. Although hey, at least read their arguments with an open mind and decide for yourself.

On the other side, there will be people who love a thing so much that they can't imagine using anything else. We may not love it as much as they do, but should that stop us from using that thing if we like?

Also no.

Bottom line: Why judge a thing by what the most extreme opinions about the thing are, or how extreme those opinions are? Judge by its utility for you.

> Because you cannot simply call it a programming language that's for sure.

    Programming language +
    windows, icons, menus, pointer +
    editor +
    source debugger +
    source libraries (including compiler, wimp, editor, debugger) +
    graphics libraries

Back when each of those cost extra, Smalltalk/V 286 was an affordable development tool ;-)

March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."

https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&ots=...