Have you tried using Infiltrator.jl? It’s not quite as full-featured as Debugger.jl, but it should generally run faster since your code is compiled.
4 Likes
ENVY grew like topsy. I wouldn’t recommend emulating it. The composition structure, the immutability of named configurations, being able to do bit-identical builds, and access controls were all good especially when building software products for commercial distribution.
Smalltalk is not a file-based system. Every fool that tried to use a file-based VCS got into big trouble. “I mean, source code in files; how quaint, how seventies!”
1 Like
You mean specifically with respect to Smalltalk or more generally?
Stephan, I’ll try to put together a summary, In a separate note, of what I think might be useful from ENVY.
To answer your question, mostly the file-based VCSs had a mismatch with the Smalltalk language structure.
Compiled Methods and non-global variables belonged to Classes, none of which varied with files. There were logically no source-files in Smalltalk. Just logs - with some refinements…
Files do not correspond well with Smalltalk language structures.
You could serialise some filtered collections of classes and methods as ‘changes’ files. Merging various developer’s changes for a weekly build stole your best engineer for a considerable part of their time, and in my experience produced chaos. Very smart, experienced engineers allegedly can do good work with changes files, but not in my product development experience.
In Julia I think I’d like to see my IDE allowing me to diff and load history of methods with the same signatures as matched under multiple dispatch. It seems quite reasonable to have a complete package/git-file correspondence, but it doesn’t seem to me to correspond to development or fine-grained compilation. There’s obviously a link between methods and records and some other stuff. Somehow I think an IDE focussed on types and method signatures would work nicely with Julia.
FYI here’s a link to the original ACM paper on ‘Orwell’ the conceptual model for ENVY https://dl.acm.org/doi/pdf/10.1145/62084.62096
I also spent a lot of time building stand-alone applications using ENVY/Packager which did a kind of reachability transitive-closure from some known roots, with supplementary include/exclude rules to write an image to an new file. This could build quite tiny Smalltalk Apps, given appropriate care. Some of these could be run on bare-metal, and put in ROM.
1 Like
Also there is the interesting case of Strongtalk:
http://www.strongtalk.org/index.html
Quite a few of the folks who worked on Strongtalk eventually worked on various JavaScript JITs (see the about page in Chromium or Edge).
1 Like
Yeah - Strongtalk was pretty interesting. At KSC, we were building a type-hint/inference assisted IDE for one of the Digitalk Smalltalks at the time - so we were very much paying attention. Had some Trellis/OWL guys on the team.
Self is/was very interesting, and extraordinarily influential. Still worth reading the papers. An efficient implementation of SELF a dynamically-typed object-oriented language based on prototypes
2 Likes
Craig Chambers, one of the authors of that paper, went on to do Cecil and Deisel, object oriented multiple dispatch research languages, the papers about which I read avidly back in the early to mid 2000s and were highly influential on me (and I believe @jeff.bezanson too). This Self paper also made a big impression.
5 Likes
Changes made to source and compiled in the Smalltalk debugger were first class. They were not outside normal source management. (Hope I’m not repeating myself). It was common to use the debugger as the main development tool. A favourite technique was to represent a use-case as a script of comments, one at a time convert the comments into language code. Run the script in the debugger. If the step in the use-case tried to run code that was not implemented yet, an exception was raised which the debugger (which you were already in) caught. Then we had pop-up menus on the stack that would allow you to create the missing method or class, using the metadata from the exception stack frames .
Worked really well pair-programming with end-user that had worked in developing the text of the use-cases. They usually became quite good business-level programmers.
And there it all was - in the source management system.
1 Like
I used to really enjoy tinkering with metaclass programming.
Alan Bornjng worked with OTI for a while. Thinglab was cool - in the reference trail
Programming with explicit metaclasses in Smalltalk-80
Kiczales was at OTI too. The Art of the Metaobject Protocol - Wikipedia.
I liked this paper by Jeff McAffer ( Meta-level Programming with CodA)[Meta-level Programming with CodA | SpringerLink]. I had a pre-print. The conference looked interesting.
Dave Thomas loved collecting people.
In some modern Smalltalks you could refactor in the debugger too. I think Pharo is a living example. The debugger rewinds the stack to the last frame before any code affected by the refactoring. You can then see the state, inspect anything you like, and continue debugging.
Looks like Pharo doesn’t refactor in the debugger. That was probably an add-on for IBM/OTI Smalltalk
While reading about Smalltalk is interesting, most of us here lack context because we are not familiar with the details of that language and the associated tooling.
Translating these features to concrete suggestions that could be integrated into Julia as incremental changes would help focus this discussion.
2 Likes
Apologies, I was a little surprised to find interest, and I’m treating this as informal chat. I’ve only been using Julia for a few months - so translation into the Julia context is quite difficult. I’m mostly responding to questions. I’ve been sitting at home in lock-down this year. This about as much technical conversation as I get…
The type-system of Smalltalk is usually conflated with the inheritance hierarchy. Types in Smalltalk are really to do with chains of receivers in computations ‘understanding’ the messages sent to them. Sort of a ‘single dispatch’. If the #doesNotUnderstand exception is raised - that is a type-error. Quite similar to the type errors in Julia.
Concrete suggestions:
-
Watch the Dan Ingalls video to see how integrated and uniform the Smalltalk system was 40 years ago - and ask yourself about progress in the industry.
-
Read the
Selfpapers which I referenced - they would give you the most ‘bang for the buck’ at the moment. -
Read this fairly trivial, short demo of the Pharo Smalltalk debugger:
How to use the Pharo Debugger -
If you’re committed to understanding, fire up Pharo Smalltalk
-
Don’t have an impedance mismatch between your configuration management system and your programming model. Have the granularity of version control match the compilation and reference granularity. For example, versioned methods within versioned modules. With the full history of each available for load and diff. Show this in the debugger.
P.S. I’m not really interested in programming in Smalltalk any more. I want to do numerically intensive work, and I like modern type systems. - though I miss the power of the Smalltalk environment every day.
Cheers…
P.P.S.
Alan Kay: Doing with images makes symbols](Alan Kay: Doing with Images Makes Symbols (Full Version) - YouTube)
One of the best lectures on interacting with computers ever made…
13 Likes
For what it’s worth, I found the musings very interesting. It really is amazing how advanced the environment and tooling was for these smalltalk systems.
5 Likes
My old professor in CS back in the late 90’s always spoke very highly of Smalltalk in general. That and lisp. I must admit i also enjoyed reading your posts here. Thanks for the gems. 
6 Likes
The ‘Playground’ in Pharo is a very useful tool. Sort of a cross between a repl and an inspector. Each execution of an expression pushes a new context onto a visible stack of contexts. You can back-up and inspect/edit/restart form an earlier context. Do the usual browse-the-code of anything you can see. Is definitely worth looking at.
Smalltalk Debuggers
A quick and very basic video tutorial on Debugging in Pharo - dubbed haltingly from Francais.
Personally I find it better to add a breakpoint from the debugger interface, which doesn’t alter the source code - this avoids creating a code change artefact.
Here are more exhaustive videos VisualWorks debugger overview, and Debugger Usage by the late James Robertson of Cincom.
VisualAge/IBM/OTI/Instantiations Smalltalk
VisualAge for Smalltalk Handbook Volume 1: Fundamentals - basically OTI/IBM Smalltalk manual
Current non-IBM product documentation It’s still a pretty impressive product - Though I have no love for the graphical application builder.
This is the manual for the current equivalent of the ENVY configuration management system.
Handling team software components It’s not pretty, or a tutorial. Disappointing documentation. I wouldn’t teach a class from this… If you are lucky you’ll run into screen-shots.
Mastering Envy Developer is the best book available.
The widgetKit was the only Greatest Common Denominator cross-platform widget system I have seen. Every platform supported every widget from every other platform. Looked and behaved as native widgets.
Some of the staff of OTI rescued their Eclipse project from IBM which was wanting to trash it. The chairman of the foundation, Mike Milinkovitch is ex-OTI.
4 Likes