Cincom's blog about its Smalltalk products, mainly VisualWorks, covering the language's use and its comparison with Erlang and Lisp.
HN uses it as a reference for commercial Smalltalk. Commenters recall VisualWorks fondly but criticize its licensing, including royalties and the ended free personal licence.
A few important points:
1. Breaking code is nothing specific to a language. The usual weapon also
in Smalltalk is to monitor if something breaks - for instance by using CI.
Continuous integration only makes real sense when you have tests.
One should remember that "test first", "unit testing" and "Extreme programming" (XP)
like many other things had their roots in Smalltalk. Because in dynamic
languages testing using code was and is part of the culture (ranging from lively verifying
with workspace expressions and inspectors up to fully written tests).
The first unit testing framework "SUnit" was written by Kent Beck for
Smalltalk (SUnit), later he ported it to Java with Erich Gamma on a flight
to OOPSLA OO conference. Java helped to push the popularity afterwards.
Meanwhile also static language enthusiasts have understood that it is better to
rely on tests than type checking compilers and they now hurry up to follow
what Smalltalk already had years ago.
One last thing you should try: try to query your system how many test methods were
written. When you solved this easily with a Smalltalk expression retry
this in Java ;)
2. Commercial Smalltalks which are often used in big projects provide solutions
which are repository based like the famous ENVY (written by OTI, was
in VisualAge for Smalltalk from IBM, now VAST) or Store (VisualWorks). For
more details try the commercial evaluation versions or read…
Personally I have a hard time seeing what the goal for Arc would be. "100 year language" seems pretty fuzzy. I mean, Lisp is already at least a 100 year language IMO so what could Arc do to make itself more so? What is it going to do that the other two popular Lisp-1s don't? The only differentiator I've seen so far is pg's confusion of terse for concise [1].
I think there is always more room for programming languages in the world, especially given how awful most of them are. I just think they need some clear reason to exist or their creation isn't worth the fracturing effect [2].
[1] Personally I use terse to mean "short and unreadable" and concise to mean "short and more readable" (think: "I didn't have time to write a short letter..."). The first thing that occurred to me when I saw Arc was "oh man, a bunch of cryptic one or two letter functions. Is this meant to be programmed over a 1200 baud modem or something?" Every one of those kinds of things is something that has to be memorized, and given how much more advanced IDEs are today what's lost in readability is not made up in typing savings. For me the classic example of "concisity" is Smalltalk. Most methods are just a line or two, they read almost literally as English yet so much is said with so little. No meaningless cryptic two letter sequences but yet one line is equivalent to at least 3 lines of Java [3].
[2] I.e. users becoming party of a community of this new mostly irrelevant language A instead of…
Warning: recent history lesson ahead.
> One core idea embedded in all of Bret's work is that learning happens best when students are able to explore multiple representations of a idea or aspects of an environment simultaneously. The more quickly one representation changes in reaction to the other, the stronger the learning feedback loop, and the more quickly the student builds an accurate mental model of how the thing they're interacting with works.
Bret Victor's work brings a lot of visibility to this field, but he was hardly the first one; e.g. [1]. And more to the point, I wasn't the first one either; I believe Christopher Hancock [2] was, but even that is controversial if we begin to talk about visual languages all the way from Sutherland's SketchPad, and Jonathan's work on subtext [6] was a big inspiration to my own. And even I was inspired by some piece of software called SlideShow [4].
> So, WRT your point, it's not about the fact that the documents are interactive, but that they're "reactive." The interactive bits are all related to each other, and when one part changes all the other parts change with it, in real-time. There's something in this immediacy that even the slightest delay destroys.
50 milliseconds is the max, ideally you want < 20 ms (see [1], keep in mind 15 ms is your standard frame delay).
> But, well, he's taken it to a whole 'nother level. He's actively exploring this idea on multiple fronts, from reactive documents to reactive programming…
I agree completely that the ORMs in Squeak are bad, and many abandoned, but as of six months ago, ROE still worked. ROE is not an ORM per se; rather, it's something close to LINQ on a SQL database: you write your queries in relational algebra, building up an AST. The AST is only ever compiled to SQL and sent to the database when you're finally ready to do the query. This allows easily building up a query over many methods by passing around the query object and avoids dealing with an ORM, since at the end of the day you're still just getting back the SQL model, rather than trying to cram it into an object.
A quick overview of Roe is at http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3246121322 and the current source is at http://squeaksource.com/ROE.html . Note that ROE only supports PostgreSQL, but that's okay, because that's the only meaningfully supported SQL driver in Squeak/Pharo. Supporting other databases is actually quite easy in one front, but useless on another: I ported it to SQLite and MySQL around 2005, but never shared the changes, because MySQL simply cannot meaningfully optimize the queries generated by ROE, and SQLite at the time required a very unstable FFI wrapper that crashed the image constantly. If there's interest, I think I still have that code lying around somewhere.
ParcPlace spun off from Xerox to sell the original Smalltalk in 1988 but they sold that to Cincom in the late 1990s:
http://www.cincomsmalltalk.com/main/products/visualworks/
Cincom had previously tested the waters by buying another Smalltalk called Object Studio.
IBM sold its VisualAge Smalltalk to Instanciations:
https://www.instantiations.com/products/vasmalltalk/index.html
Apple had the original PARC Smalltalk but never did anything with it until it evolved into Squeak in 1996, which was Apple's very first open source product. Later two forks went in different directions: Cuis and Pharo.
https://squeak.org/
https://cuis-smalltalk.org/
https://pharo.org/
Forking Little Smalltalk (an early open source text based Smalltalk) is a rather popular thing to do, so I won't give all the links. A bit more sophisticated is GNU Smalltalk:
https://www.gnu.org/software/smalltalk/
I consider Self to be Smalltalk, though not Smalltalk-80:
https://selflanguage.org/
There are Smalltalks based on Javascript, as well as an alternative VM for Squeak and friends:
https://www.amber-lang.net/
https://squeak.js.org/
http://u8.smalltalking.net/
There are probably a few that I missed that are still in use.
This is pretty neat, I certainly like not having a separate query language embedded as strings and manipulated with string concatenation etc. (SQL injection ...).
Similar:
- Avi Bryant's Relational Object Expressions bring relational algebra into the programming language:
courseTitlesForProfessorNamed: aString
|courses|
courses := (professors * courses
select: [[:ea | (ea lastName = aString) & (ea id = ea professorID)].
^ (courses project: #title) copyFrom: 1 to: 10.
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3246121322: and http://c2.com/cgi/wiki?RelationsAsFirstClassObjects
- The query system for the Gemstone object database evaluates query blocks against proxies that capture the messages and translate the procedural queries into logical queries:
myEmployees select: { :emp | emp.age > emp.lengthOfService }
http://community.gemstone.com/download/attachments/6816350/GS64-ProgGuide-3.0.pdf