Lambda World 2018 - What FP can learn from Smalltalk by Aditya Siram

[@adityasiram349]

Speaker here, at 21:32 I said that the at Pharo GC was simple mark-and-sweep & not great. I have been informed by the implementor that I am wrong and due to recent work the GC has "sub-microsecond pauses from the scavenger with overhead well below 1%." Apologies.

[@josipmiskovic]

Kudos for this great talk. I got interested into Smalltalk concepts and wanted a quick overview, your talk served as excellent introduction. The part about chasing code indirections was for me most interesting, but all demos were great and very well prepared.

[@jrdougan]

Hey, you admitted your ignorance up front. Has anything come of this talk? Anyone built a better FP IDE in the Smalltalk style? When I was still running a Los Angeles ST users group, every so often someone would come by to evangelize their favorite FP programming language. My usual response was (and I meant this sincerely, though there was a slightly cynical edge) that I would absolutely try their language, if they first gave me a decent IDE in the Smalltalk style. No one ever did, but it has been quite awhile now, maybe someone has.

[@David-iq1kd]

@@jrdougan Darklang had a kind of cool IDE, but recently decided to kill it off and just program in VS Code.

[@jrdougan]

@@David-iq1kd InterestIng. I'll look for it. Is the IDE still available at all? Which is the last version that has it?

[@JamesHowe]

I was a Smalltalk developer for many years and it is definitely my favorite language and environment to program with. I think the advantage that Smalltalk has is that it doesn't store code in files. It basically has a database for its code which allows for ways to introspect that are difficult (but not impossible) to do with file based languages. I think Kent Beck once said "Source code in files, how quaint". Very interesting presentation.

[@dmitryponyatov2158]

Is it makes a problem where every developer has all the libraries he uses were modified locally and stays out of sync from the community?

[@kevinbee4617]

Can't an IDE just load the necessary files into ram when it starts and store them back in files when it's done? I assume that is more or less what Pharo does as well. When the computer is turned off, the code *has* to be in some kind of file. Code is basically graph-like in nature and text files are more list-like, so I see a mismatch, but you still have to display code "flat" in 2D on a screen, your eyes have to read each character in a linear sequence and the harddrive or a network connection also has to read code in a linear sequence. I see no reason why other programming languages couldn't have an IDE similar to Pharo or one with the same capabilities and small language changes and still be stored in text files. SVG graphics are also stored in structured text files. They can be version-controlled with git, you can create diffs and it doesn't prevent them from being editable with graphics programs. Some modern IDEs have integrated compilers to provide advanced features. Maybe that's the solution. (I'm not lecturing you, just thinking aloud. I'm just a CS student.)

[@johnkimber4027]

@@kevinbee4617 Smalltalk is a live system, you can be running a program, hit a break point, save and exit. Later restarting, everything will be as when it was saved. You can then make changes to the program without restarting and continue running.

[@kevinbee4617]

@@johnkimber4027 Some thoughts about live programming systems: I think there are two ways to go about changes of definitions: 1. Change the current state to what it would have been if the definition (of a function) had always been like this. 2. Recognize the former definition of the state. Only change the future. I like the first idea a bit more. It would for example ensure that you can ship the new version of the software to a user and it would behave the same way even if they didn't change the program halfway through the execution. There are examples online of Jump&Run type games, where the change of the jump mechanics automatically changes the position of the player character on the screen. I guess the second has some advantages too. It's definitely easier to implement. Some musicians employ live programming to create music on the stage. They probably also use the second interpretation. Question: If I program a calculator app with a graphical UI and I click the buttons "1", "+", "2", "+", "3", "=", it should display the output "6". *What should happen if I change the program code, so the positions of "+" and "-" are switched?* On the one hand you could argue, that the output should change to "-4", because that's what would have happened if the user clicked on the same pixels on the screen. On the other hand you could say that the user would have seen the "+" button and clicked on another position and still fired a "onPlusButtonClicked"-Event. Is there some established theory of live programming systems that considers this problem?

[@johnkimber4027]

@@kevinbee4617 Nothing stays simple for very long. Variations and edge cases etc turn up. Different ways and interpretations are implemented. With the calculator, behavior hinges on implementation. The click could be derived from the text on the button using some mapping. Or, there could be a linked function that could contain some mismatch. Hence, a bug. With live programming, errors often show up closely related to small changes in code. Corrections can be made without restarting and the fix tested in context. As you alluded, live programming is also good for speculative/experimental coding. These are typically dynamic systems. The best of both worlds would be to produce a typesafe version from the dynamic version. CMU and other institutions have researched some aspects of live programming.

[@MichaelYinger_Beginner]

I first encountered Smalltalk sometime around 1982 at Tektronix. It was shockingly different than C. Started doing commercial work with in the mid 80's. I've never found a language I like better. I mostly use JavaScript, C# and Python now. I still play with Smalltalk Pharo, just for fun. Good presentation. Thanks.

[@Elite7555]

The only thing I don't like so much about it is that it is so dependent on its IDE. I couldn't figure out how to just use it with a text editor. And it doesn't work on a lot of environments like Android.

[@dmitryponyatov2158]

@@Elite7555 has no clustering capabilities, and works with Git in a very strange manner

[@dbtest117]

@@Elite7555 Should be portable to android, or try squeak or some other derivative's. I also found this with a quick google medium.com/@richardeng/mobile-smalltalk-c6f0cc712909 and this joachimtuchel.wordpress.com/2012/06/14/gnu-smalltalk-on-android/

[@leonhrad]

This is the 4th talk I've seen of Aditya, and he always has such interesting topics and the talks are always just fun to listen to. Really great stuff.

[@Evan490BC]

So you are the second person who knows about ATS? (Just kidding...)

[@micknamens8659]

Another cool feature in the finder is search by example. You provide the input parameter values and the expected result value. The finder shows you all methods which pass this test in a second.

[@Kenbomp]

Data studio 27.1,backtick 40.1 rousal 37. After 2 years this talk still works at different levels. Amazin!

[@code_report]

Amazing talk.

[@ribosomerocker]

so true

[@lg2389]

Dang smalltalk is ahead of its time on DX . Once again assures me that DX is the holy grail for any language

[@NoahNobody]

I'm just discovering smalltalk and found this to be a great introduction to the environment.

[@mathieudubois3715]

This is a very interesting presentation especially because it's not about Smalltlak (it)self (which is great) but about the environment !

[@CarlGundel]

There is really no distinction between the two. You can't even have the IDE without the language.

[@lg2389]

AMEN on teaching the tricks on how to use properly the DX of the language

[@ColbyARussell]

At ~@4:00 Aditya is talking about custom visualizers for one's libraries. Around the release of Firefox 4, when some folks who had worked on Firebug were tapped to work on Firefox's new, integrated inspector and other Web Developer tools (ultimately set to displace Firebug itself-which it did-and obviate the need for the older, XUL-based DOM Inspector-which it did not), I had been maintaining the original DOM Inspector, still useful for browser extension developers and people hacking on Firefox's own UI, and I realized based on the way things were going with the work that the new devtools team who'd gotten spliced in were doing, all they were really going to achieve was to pull off Firebug-in-the-browser at best. So I set out at the time to write a replacement for the legacy DOM Inspector that both retained and highlighted some aspects of its architecture that Firebug and its clones lacked. Hewitt had done a really good job at that part, so the inspector's "framework" was basically akin to UNIX pipes, but in graphical form-with pluggable viewers that could take the output of one as the input to another-there just wasn't a lot of obvious visual affordance for it in the UI that made it clear that this was happening under the hood or that you could string them together in sequence to the nth degree (rather than a fixed, two-pane inspector layout, with the document tree on the left and e.g. the CSS viewer on the right). While I was still maintaining the legacy DOM Inspector, I started on a from-scratch rewrite that would also incorporate the sort of Miller columns-inspired design that ultimately ended up in Glamorous Toolkit. That was in 2013, 2014, though-and then the-powers-that-be at Mozilla Corp announced finally that XUL was *definitely* going to go by the wayside as the Firefox product team began chasing Chrome's tail and would implement instead its newer but unfortunately far more limited WebExtension standard. This would have completely killed the ability to install a replacement inspector, so I stopped working on it (and called it quits on my involvement with Mozilla once and for all, which I had been contributing to since 2006). Huge bummer. I'm not saying I need to have been to have done it, but we'd be way better off today (not to mention in the meantime) with an inspector that was designed to embody these principles and fostered the culture that Aditya talks about at the very top of this presentation. And there's no reason it should have needed to be constrained to the browser, either-a general purpose framework for inspecting/debugging any and every application and component on one's desktop at any given moment would have been a huge boon to system introspectability, developer productivity, end-user control, and free/open source software and computing generally. Unfortunately, we just ended up with Firebug-reimplemented-inside-the-browser instead...

[@aoeu256]

We need more live demos of people using Smalltalk, I can't believe that Smalltalk & Self lost to Python & Ruby & JavaScript... Also why create Dart and Swift when Smalltalk already exists...?

[@melvin6228]

From what I've read, back in the day Smalltalk systems were only commercially available. The biggest factor for adoption in these cases is that it has to be open-source. No open-source? Then, little adoption.

[@maxyazhbin826]

One of the best talks

[@automatescellulaires8543]

It's been 50 years from the begining of smalltalk, nearly 4 years from when this talk occured. Has anything changed ?

[@lyingcat9022]

And 1 year from this comment… I’ll go on a limb and say No, no it hasn’t;)

[@automatescellulaires8543]

@@lyingcat9022 oh boy, already 1 year.

[@David-iq1kd]

@@automatescellulaires8543 another year! Darklang had an interesting IDE, but killed it recently in favor of VS Code.

[@aoeu256]

It shouldn’t be too hard to do a Pharo for JavaScript and the web?

[@dmitryponyatov2158]

Are you kidding? Google Chrome started to kill my system every few hours every day, the last few months. JS is a cancer of CS.

[@horridohobbies]

In fact, there is a Pharo that transpiles to JS. See pharojs.github.io/.

[@johnkimber4027]

For a JS environment like Smalltalk, try the Lively Kernel lively-kernel.org/

[@micknamens8659]

@John Kimber Development for Lively-kernel seems to be stopped. Maybe it was not accepted because the page loading takes very long.

[@РайанКупер-э4о]

It's magic!

[@dengan699]

Impressive, didn't expect that

[@pbazant]

Awesome talk!

[@samuellotz8304]

You are dead on with your distinction between beginner and advanced user (most of which are gurus and not actually good programmers). 80% is just slogging through the search of where to look for how to actually use things. Most people don't have enough bandwidth or patience (rightfully so) to sacrifice that much essentially unproductive time to becoming a guru just so they can solve their *real* problem!

[@veer66]

I wish I have time to make Pharo to display Thai text properly.

[@jonathanccast]

Weird, I always thought of SmallTalk as the champion of abstraction introducing indirection

[@aoeu256]

Jonathan Cast The ide can collapse the indirection. Another way the ide could collapse the code is by allowing indented code to be shown as a one line if collapsed, in lining methods, especially from a test case.

[@johnkimber4027]

@@aoeu256 Collapse might not have been a good choice. Expand or chain indirection would have been better explanation.