Cincom Smalltalk Blog

Cincom [1] has made the VisualWorks [2]. To my knowledge it was the best “contemporary” SmallTalk I’ve ever had played with:-) Later they killed the free personal licence so it was no joy anymore. Anyway I wonder what will the future of the Cincom SmallTalk look like. [1] https://www.cincom.com [2] https://www.cincomsmalltalk.com/main/products/visualworks/

Neither Squeak or Pharo have well maintained website and searching for documentation via google is very hit and miss. Pharo is worth downloading and playing with though. The old, main commercial implemention of Smalltalk is available through Cincom. VisualWorks was just about to take over the object world before Java was released: https://www.cincomsmalltalk.com/main/ I have been blogging about it recently here: https://smackeyacky.blogspot.com/

I made a fulltime living between 1993 - 2005 using VizualWorks which is the original descendant Smalltalk from ParcPlace which came out of Xerox PARC. Systems are still in production across industries. It was a particular favourite with banks and Wall St for decades and some like JP Morgan still use it http://www.cincomsmalltalk.com/main/successes/financial-services/

Last I looked Visual Works smalltalk had weird license schemes that involved perpetual royalties [1]. When I used to work in business/enterprise software (no longer, thank FSM) this was an instant deal killer, especially for small businesses. Any information on how this was dealt with on this project would be greatly appreciated. [1] http://www.cincomsmalltalk.com/main/products/pricing/

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…

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…

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…

My understanding is commercial Smalltalk still exists, it's just very niche. See Cincom: https://www.cincomsmalltalk.com/main/

> The biggest benefit of being a single language is massive parallelism, especially if you're process/message oriented as Smalltalk or Elixir. Most modern software, unless really pushed (e.g., game engines) still do not use all cores available. Ummm most Smalltalks don't use all cores available, they time-slice a single OS process, aka green threads? (Exceptions: SmalltalkMT and VisualWorks Matrix framework https://www.cincomsmalltalk.com/main/products/foundation/matrix/ .) Also iirc Erlang originally did not take advantage of multi-core cpus or multiple processors for performance. The point of the massive parallelism was "process" isolation for high availability systems.

https://franz.com/support/documentation/10.1/doc/smp.htm https://www.lispworks.com/documentation/lw80/lw/lw-multiprocessing-ug.… https://www.cincomsmalltalk.com/main/products/foundation/matrix/

> There isn't one. https://github.com/pharo-open-documentation/pharo-wiki/blob/master/Gen… https://despotadesdibujau.github.io/southsmalltalks/how-to-deploy-in-p… https://book.huihoo.com/smalltalk/pharo/enterprise-pharo/book-result/D… Also, not generally available unfortunately: https://richardeng.medium.com/mobile-smalltalk-c6f0cc712909 Both cinecom and vast should allow deployment/distribution: https://www.cincomsmalltalk.com/ https://www.instantiations.com/vast-platform/

> According to some studies, Smalltalk seems to be very productive: https://www.cincomsmalltalk.com/main/2022/07/need-productivi... In fairness however, Cincom develops and dells a commercial/proprietary Smalltalk implementation... you'll hardly see somebody saying "yeah our software is a pile of garbage" in their product/company website.

Well, he probably is an Smalltalk evangelist but I don't see this as something bad. "The secret weapon" I think makes reference to Paul Graham's essay Beating the average: http://www.paulgraham.com/avg.html and he probably thinks that Smalltalk gives the same kind of "unfair advantage" as Lisp did in Paul Graham's article. According to some studies, Smalltalk seems to be very productive: https://www.cincomsmalltalk.com/main/2022/07/need-productivity-smallta… http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-…

Regarding VisualWorks: https://www.cincomsmalltalk.com/main/ If you scroll down to the bottom/footer, under "Get started" you can click "Buy Cincom Smalltalk": https://www.cincomsmalltalk.com/main/product/cincom-smalltalk-rev-9-1/ Ok, you can't (page not found), but the link above is "Try Cincom Smalltalk": https://www.cincomsmalltalk.com/main/try/ there you can download a "personal edition". Well, you have to fill out a form and provide some information to get the download link. Perhaps this is an option for you.

I believe an influence was actually an old system that used smalltalk in the 90ies at JPM. That system you're thinking of was Kapital. http://www.cincomsmalltalk.com/main/successes/financial-services/jpmor… It's the only Smalltalk usage at JPM I believe, they could have doubled-down on it but instead went to Python and as you say, tried reinventing the wheel in it.

I know one very large corporation that uses it. I think that is the general pattern of it, that big companies who are very interested in not telling you what they use, use it. You probably can get the case studies from http://www.cincomsmalltalk.com/main/

It's on this page in the shipping section [1]. I remember it had something to do with live object databases too, back when Avi Bryant of DabbleDB [2] was heavily pushing the Ruby world towards Smalltalk in the 2007-2010 timeframe with Maglev [3]. [1] http://www.cincomsmalltalk.com/main/successes/ [2] https://techcrunch.com/2006/03/11/dabbledb-online-app-building-for-eve… [3] http://pragmati.st/2007/05/19/avi-bryant-keynote/

I'm curious, is Smalltalk especially good for any particular task? Or especially easy to use for something? Have a read of http://www.cincomsmalltalk.com/main/successes/financial-services/jpmor… But then consider that they didn't choose Smalltalk for the next project...

The "response by Ralph Johnson" link is dead: http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entry=33358033… :/

Wolfpack programming! http://www.cincomsmalltalk.com/main/2010/10/wolf_pack_programming/

I think the reason why for-loops are rejected in Ruby is because of it's Smalltalk heritage. In smalltalk there are no loops and no ifs... just methods that are executed on a condition. So 'each:' isn't any more complicated than a 'whileTrue:'. Just take a look at this Smalltalk examples[1]: ----- [ condition ] whileFalse: [ statements ] [ condition ] ifTrue: [ statements ] aCollection do: [ :var1 :var2 | statements ] ---- [1] http://www.cincomsmalltalk.com/tutorials/version7/tutorial1/vwloops1.h…

I'm not going to make any assertions about anyone's experience. If you would like to see the Smalltalk debugger in action without trying the environment, have a look at the videos here (each is in the 2-5 minute range): http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=small…

In one of his talks [1], Alex Warth (the author of OMeta [2]) points out that JS might be the "assembly of the web" - in the sense that future languages will compile to it. OMeta makes this surprisingly easy: 1. http://www.cincomsmalltalk.com/video/2008/sts/ometa_keynote_large.mp4 2. http://tinlizzie.org/ometa/

i like the parts where he equates estrogen with insipidness. nice ranty take on that at: http://gilesbowkett.blogspot.com/2009/05/what-killed-smalltalk-my-ball… and a response that isn't so ranty ( and addresses other parts ) at: http://www.cincomsmalltalk.com/blog/blogView?showComments=true&pri…

James Robertson wrote something very similar in 2006: http://www.cincomsmalltalk.com/blog/blogView?showComments=true&ent…

To me that reads like gibberish. Common Lisp is used in large-scale commercial and industrial applications, why isn't it "as popular as" Java? Pharo and other Smalltalks are used in ERP and similar systems. It's attractive if your business requirements change a lot and you either don't want or can't afford to employ a legion of Java developers. You could write to https://www.cincomsmalltalk.com/main/products/visualworks/ and ask why those logos are at the bottom of that page, now that Smalltalk isn't as popular as it would be if it was any good. As a CTO I don't really care whether a programming language and toolchain "sells today" or whether it is "competitive" in some general, presumably universal, sense. I want tooling that fits the problem domain really well, and sometimes niche tools outperform general tools by a large margin for certain problems. They might require fewer developers, allow faster development or better scaling than e.g. Java.

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=tru… 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-ProgGu…

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=tru… 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.