02:00 - Gilad Bracha Introduction

09:17 - Programming Language Evolution and Design

10:47 - Capabilities and Language Features

12:46 - Actors

16:41 - Live Programming

19:07 - Smalltalk

29:01 - Designing a Language

38:59 - Complexity

42:41 - Newspeak (Con’t)

45:58 - Smalltalk or Newspeak?

48:13 - How are programming languages like shrubberies

Picks

Stroopwafels (Chuck)
Staked: The Iron Druid Chronicles by Kevin Hearne (Chuck)
Calamity (The Reckoners) by Brandon Sanderson (Chuck)
Katrina Owen: Here be Dragons (Jessica)
The Slow Party Parrot Emoji (Jessica)
Umberto Eco (Gilad)

Special Guest: Gilad Bracha.

 

Hey everybody and welcome to episode 250 of the Ruby Rogues Podcast. This week on our panel we have Jessica Kerr.

Good morning.

I'm Charles Max Wood from DevChat.tv. I can't imagine. 250 episodes. That's awesome. We have a special guest this week and that's Gilad Bracha.

Hi.

Do you want to introduce yourself?

Sure. I, as they say in Monty Python when they say that I do shrubberies, I do programming languages. So, I've had a fairly long career doing programming languages in industry which not too many people get to do. We did a startup a developed one of the first optional type checkers for Smalltalk but more importantly it developed a virtual machine that ended up as the HotSpot virtual machine in Java. So, I landed in Sun, spent almost 10 years there working on the Java language specification, the Java Virtual Machine specification, and that's probably what I'm best known for. I've done a language of my own that I'm very proud of called Newspeak. And these days I work for Google and I work on Dart which is a programming that was developed initially for the web, now somewhat for mobile as well. And it's a general purpose programming language.

Yeah, we did an episode on JavaScript Jabber like two or three years ago. No, longer than that. Anyway, we talked to Kasper and Lars.

Oh, okay. Yeah, sure, yeah.

About Dart and it was really, really interesting. We also talked to him about V8 since they worked on both of those projects.

Right.

Yeah, really, really interesting stuff. And Dart is definitely and interesting language to fool around with and get to know a little bit and just figure out how it works and how it does what it does.

Yeah, definitely.

What's special about Dart?

Well, Dart primarily when it came out the focus was web programming. So, there's a question I guess, what's special? How do I answer that? There's the technical side and there's the pragmatic side. Pragmatically, if you want to target, to write to the web and you don't find JavaScript a joy to work with, then there are lots of people who transpile as it were. But the web is not an easy target. The web browser has all kinds of quirks and limitations and history and things that make it difficult, and security concerns and all kinds of reasons why it isn't the easiest target.

And so, you need a lot of engineering resources if you're going to get a really high-performance implementation if your language isn't basically a very thin veneer on JavaScript. So, if your semantics are basically JavaScript semantics, that's easy and you tweak the syntax. But that buys you very little. And so, if you want to clean up the semantics and have something that has industrial strength support, at Google we were in a position to do that. Most people who want to write a language for the web have just slightly less resources than Google has. [Chuckles]

Yeah.

That's right. So Dart, it runs natively on Chrome and for other browsers compiles to JavaScript?

No, okay. So, Dart has a VM that runs natively and you can run it on a server or just about anywhere. In the browser it compiles to JavaScript for all browsers.

Ah.

Yeah. Yeah, I think there are Dart plugins that you can get for Chrome or something. But, yeah.

So for development, there's a thing called Dartium which is basically based on Chromium which lets you run the VM inside of Chrome. And that gives you a great development cycle. So, you can basically write Dart code and get it to run instantly in the browser as web app by invoking that. And that cuts back on the time that otherwise if you have a sizable project and you're compiling it to JavaScript every reload cycle, that gets kind of old. We're working to improve that workflow as well but that's what you were referring to, is the Dartium thing.

Ah. What makes Dart interesting technically then?

Well, primarily I guess the most unique aspect is the optional types which a bunch of other people have now started to do. And as I said that goes back for us many years when we did this Strongtalk project in the 90s. But the idea is that you do have a type checker but it's completely optional. And that means that you don't have to write types if you don't like writing types. If you do write types, if they don't work out, if the type checker complains, it doesn't stop you from running your program. Type errors are not compilation errors. They are warnings of a sort. And so, it gives you useful information sort of like a linter. But if you decide, “No, this is too complicated to type,” or, “This doesn't actually, the type checker's complaining but I know for this particular circumstance it's going to work or at least I want to try it,” or during development, just your workflow. You don't have to play games like you do in Java where, “Okay, I haven't written this method yet but I have a path that I'm not even testing yet that calls it. And I don't want to be stuck filling out stubs just so the compiler would shut up.”

Yeah, that's frustrating.

So, the type system is there to be useful to you if you want it but to be out of the way if you don't. That's probably the most unique. And in a way other people are starting to do that in other settings as well. This idea has kind of gotten some traction.

Very much, yeah. There's gradual typing now in Clojure. We talked about Crystal which is basically compiled Ruby with types the other day.

Okay, yes. So, there were earlier efforts with Ruby though. I forget exactly the history. There have been all kinds of things. There's TypeScript. Facebook is using Hack which is basically PHP slightly cleaned up and with an optional type system. So, this idea is something that I've been advocating for, for 25 years almost now. And its time is finally… which is usually the time it takes to get an idea going, sadly. So yeah, its time has come.

Right. We've been fighting over dynamic versus static languages for so long and now we finally have synthesis.

Right. So, well, there are still plenty of people eager to fight.

Really. I'm not kidding. I see this every day because this is a religious issue. But yes, I argue that you can sort of, to a large extent, have your cake and eat it too, depending which on you view as the cake and which one you view as the anti-cake. But either way, you can combine these. There are some compromises but relatively little. You can get a lot of benefits of types without a lot of the pain by taking variations on this approach. People have done slightly different things but yeah, there's no reason to have this dichotomy. It's a false dichotomy.

If there's cake and anti-cake is that like matter and anti-matter? If I eat one then eat the other, it'll annihilate in my stomach and I won't actually gain weight?

Well, if you put them together, yes they do explode.

That's when you put type fanatics and dynamic fanatics together, then yes you get this nuclear fusion and I don't know. Black holes, all kinds of things can happen. The whole time-space continuum is at risk.

Oh, we can't do that then.

Yeah.

So, I'm really curious. The topic that we have down today is programming language evolution and design. And we've kind of been talking about dynamic and static typing. But I'm really curious. What do you see coming out in languages today that you think is going to get iterated upon with the next batch of languages that come out?

Well, I think this optional typing thing is still evolving and people are creating variations. And we'll see what gets popular. What gets popular may not be what's right. But then, that's life. Another area where there's a lot of activity on functional. And I expect we're going to see more things that are a bit of a departure from the classic academic functional languages. I believe that when functional hits the big time it will not be academic languages. A good example of that would be Elm which is a really cool thing that Evan Czaplicki is doing. And if you haven't looked at it, that's kind of one of the nicest things that have come out in a long time.

Agree.

Yeah, Elm is pretty cool.

And it is very pragmatic. It's, let's take what we've learned from these more academic languages, the MLs, and make something that is beautiful for people to use.

Yeah, that's one way of putting it. Basically it's better designed. He's a very talented young man and he has a sense of reality which was lacking in [inaudible].

[Laughs] Yeah, that's one way to put it.

Yeah. So, when you're looking… let's say that you were going to write a language today. What would you be looking at as far as capabilities and language features?

Basically I'm working, when I do my more research-y side of things I work with Newspeak. And I'm pretty happy with it but obviously there's a ton of engineering to do. And in terms of language, there are some things I'd experiment. I'd like to… Newspeak is very easy to turn into a functional language because there's really only, from a language design point, there's only one construct that makes it imperative. But to actually build a working system is a very different matter because all your libraries are going to be different. And that is really the challenge. That's why I don't do it, because changing the one construct would be trivial. But actually making this workable then would be rebuilding the platform.

So, getting something functional, marrying functional and say imperative code across actor boundaries is how I would tend to do it. So again, getting actors really purist Erlang style maybe actors, or even more purist than that, non-blocking receives and things like that, getting that to be performant when it's on your local machine for example, there's a bunch of areas like that that need work.

When you say functional here are you talking about free of side-effects?

Yeah, yeah. I'm not talking about higher-order functions. That goes without saying. Smalltalk has had higher-order functions since, I don't know, at least 1976. I'm not positive about those even earlier versions. But higher-order functions are great. Again it took a ridiculous amount of time to get this into the mainstream. But that pretty much every new language has these days. But sideeffect-free is… there are advantages to that in a lot of circumstances. And making that work for real is, Elm is one attack on that. But that's something that I'd like to play with more.

You also mentioned functional/imperative boundaries at the actor boundary.

Right. So, actors, actors can communicate. And some of these actors could be written in completely different languages as long as they have some sort of, as long as the message protocol is something they both understand and have a way of accessing. And so, a natural way to do that would be to have variants of a language. Like in the case of something like Newspeak you can create very similar feeling languages or very similar syntactically. And a lot of the culture carries over and yet one can be functional and one can be imperative. And you can't mix those because the imperative part will compromise the functional part unless you get into monads and stuff which I really don't want to. And so, well actors, actors actually are of course a monad. And that's one way to deal with this, letting code combine by just gluing it together with message passing.

At this point, when you talk about actors that are in different languages, is that microservices?

Oh, I don't want to…

I don't want to get into sloganeering at that level. But I think it's just, the internet at some level is actors. Distinct computers on the internet are at some level actors, right? That's message passing.

And make it a finer grain, the question is how small can you make them, right?

Yeah.

Mmhmm.

It's a spectrum.

Yeah.

It's also these things are not opposed to each other. The actors though, you talked about functional actors. But if they're message passing to another process, isn't that itself a side-effect?

It's not a side-effect on them. Any functional program that is going to do anything interesting had better side-effect something outside itself.

Yeah. Yes.

Otherwise we're back to the language is designed for implementing factorial…

Of which we have a number. And so, of course it's side-effecting. You want to see its output. It's side-effecting your brain when you do that, when you look at its output. If it doesn't side-effect something, it's not observably doing anything interesting. So, sure it is. And of course the point is that in a given, say if you look at the actors as running in an event loop. When they get a message and they respond, during that period they're not seeing any side-effects. So, the code can be reasoned about functionally. The next time you come back to the code when another message comes in, yes the answers to those messages might be different but it's isolated.

This ties back to Elm because Elm models that event loop with its architecture of receive an action, update your state, that state comes back to you in the next event loop.

Right, right. So, it's doing UI which obviously things are changing out there in the world. But while it's processing it, it's functional. And I know Evan is looking at actors as well. He's been looking at Erlang quite seriously recently. And so, I expect Elm to expand beyond UI at some point and do other things. So, definitely yeah, he might do something interesting. So, that's a very interesting space.

Of course, people are looking at all kinds of ideas because the overhead of real isolation, of memory isolation and so forth can be crippling for some things. And so, there are all these schemes of using linear logic things so that it is stateful but it's handed away so you won't mutate it when you hand it in a message to another actor. There are all kinds of variations for trying to get these things to be more practical and more performant for a wider range of users. And so, we're probably going to see a lot of activity in this area.

Another area that we might talk about of course is live programming, which is I think another program whose time has finally come. I expect to see a lot of that. That may be less about language in itself as about language tooling and environments and so forth. But they interact. And they shouldn't be viewed… it shouldn't always be isolated from one another.

Agree. You said live programming?

Right. So again, the term live is finally, I'm hoping I don't need to explain this too much. This is… Bret victor did a fantastic job of making the world aware of this. This is something that in some sense the Smalltalkers have been yelling from the rooftops for decades and no one paid any attention. And Bret has this gift of communication and managed to get people to understand what this is about. And so, and Elm for example is also doing this. And that's where these language design and environment may interact because making things functional makes some of these things easier. But generally we're talking about reducing the feedback loop. We're talking about the fact that you make a change in your program and you instantly see the effect that change has. You do not go through compile, edit, build cycles, et cetera, et cetera.

So, by live programming you mean making changes to the program while it's running?

Yes, that's one way to put it. The important part is that you make the changes and you see the effects immediately, right? And so, yeah. If it isn't running it's not too interesting. In theory yes, if you can recompile it from scratch, bring it to its previous state instantly, then you don't have… but effectively it is while it's running, yeah.

And the idea is that you evolve your code as you evolve your thought.

Yes. Again, it's one way of capturing. There's many ways of stating this but both of those ways are I think equally valid. As sort of, I guess from you guys are rooted in Ruby I suppose and to the extent that you are, Ruby has a lot of dynamics in it. It generally hasn't had an environment in which to leverage it in the same way as say Smalltalk does. And that gives it both advantages and disadvantages depending on what you're trying to do and what circumstances you're in. But I think we're going to see more of those because the world is starting to wake up to the usefulness of that idea.

For our listeners who don't have a background in Smalltalk, could you describe the Smalltalk environment and how it integrated with the language?

Okay. So Smalltalk, one of the things that make it unusual is that it sort of doesn't really make a very clear distinction between the language and the environment. You can make that distinction and I think it's valuable to make it and it may have been a mistake at some level that it wasn't made more clearly. But the traditional Smalltalk approach doesn't really focus on language as much as it does on this notion of call it a sea of objects. You have this set of objects that are out there and they interact by invoking methods on one another. The Smalltalkers call that message passing but it's typically synchronous. And you evolve this sea of objects over time to achieve whatever goal you want your program to do.

And yes, there's code. The code is typically inside methods of classes and so forth. But really, they're inseparable. There's this evolving process that can be mutated and changed over time and is constantly mutated, including the codebase. So, changing code involves telling a class to replace a method with another method and things like that. And you have this… and this is where and why the Smalltalkers talk of 'live'. It's this thing is a growing, changing, evolving dynamic thing. So in a sense, it's the Smalltalk image as they call it, is alive. And these concepts are separable but in the Smalltalk community they're usually not separated.

And what this gives you is an IDE where you can change your program, you can change the IDE itself from within itself and customize it and get instant feedback and debug things and do all these kinds of things of on the fly debugging. And you can change a class for example and add a field to it and all the instances of the class in your program now have that field, sort of auto-magically. And you have to work with this to, it's an experience. It's not a piece of text that you look at. It's really a thing that you experience. And if you play with it enough it becomes addictive. And you get the Smalltalk disease. [Laughter]

And then you never stop talking about it.

Oh, I have a few friends with that. [Laughs]

Smalltalk programs do not live in a file, right?

No, typically they don't. Again, these are all things that I think can be, are pragmatic things that they have pros and cons and could be changed. But yes, the traditional approach in Smalltalk is again, you have this live ongoing process. You can save the entire process. You snapshot it and then you save an image. And that's a big binary file on a disk somewhere. And you can take it and bring it up and bring your program, that image may have your debugger open with a window in a certain place, with the cursor in a certain place in a certain state. And you can take that image and open it two years later on a different machine on a different operating system typically, and you're exactly where you were.

So, it has all these amazing things. But yes, the code doesn't live in a file partly because they sort of didn't have a notion of source code above the method level. So, in a traditional Smalltalk a class is basically built by a series of expressions that reflectively send it requests to add code to it. So, you send it a message to say, “Add this method,” and you have the string for that method, and you send it another one. And so, there isn't actually syntax for a class or a compilation unit of any kind. And so, it isn't clear what you'd put in a file. There are these things called file outs which are these imperative records or sort of journals of what you did. And so, that doesn't work well with source control traditionally because they're full of noise like the time you did this, all kinds of metadata that makes it very hard to compare and diff and so forth.

Now, there are systems that got around this. Smalltalk doesn't have to be this way. But your canonical Smalltalk is that way. And this is some of the things that I've worked [to] change. Newspeak is very different in that regard. But if you asked about traditional Smalltalk, that's kind of the model. And it's interesting and weird and great strengths and great weaknesses.

It's almost like the only way to program is in the REPL and only through monkey-patching.

So, that is… there's some validity to that but I think that's a very unfair… so many things wrong with it at the same time, I think that was it.

So, first of all, right. So, REPL is a notion that represents progress for some languages like Java. It is a notion so primitive compared to what Smalltalk does. Smalltalk has workspaces which are sort of, they're already much more than REPLs because it's not about… REPLs were invented circa 1965 or so in BASIC and APL and things like that, Lisp. And you had this terminal and you'd type a line and it would answer you and so forth. And that's what a REPL does. But once you have this persistent state, you can object inspectors and look at them and have multiple views on this stuff and change it and have it update automatically and have a whole bunch of expressions that you pick and choose from and evaluate dynamically and so forth. So, it's a lot more than a REPL.

The other thing is monkey-patching, there is a notion of monkey-patching in Smalltalk but that is actually something different. You are dynamically modifying the code as you edit it but that's no more monkey-patching than editing code in your editor. You are destructively taking a copy of the code and modifying it. Monkey-patching refers to having to do that outside of the definition. By going, you have this code that maybe you don't even have access to and you say, “Now, slap something into it.” You can certainly do that in Smalltalk and they sometimes do. But that's different, because that happens outside the class. I wouldn't say it's monkey-patching. It is by reflective change which is a mechanism that can enable monkey-patching or not. But that's not really different than editing a file. Because if you change something in your image, you can save copies of your image. It has a changelog and you can go back and retrieve your old versions. And it has actually fairly powerful tools to do that. So, the monkey-patching I think is unfair.

Okay, thank you. That was…

As I said, you need to experience it. There is a… and because there's such a, it's so different, there's a barrier to entry which I think is why Smalltalk didn't take over the world as it should have. But if you get past that, if you work with that a while and you kind of get to this aha moment where it clicks for you, after that yeah, you're infected. And you can't stop talking about it ever.

Historically, Smalltalk used to have the barrier of entry of you had to pay for it, right?

Right. So, Smalltalkers sitting around in a pub with beer will debate endlessly how come this wonderful thing never really got where it rightfully should. And you can only speculate, but part of that is the early Smalltalk vendors were commercial vendors. They had to make a living. And they made some probably fairly bad commercial choices because at that point they didn't understand the dynamics of open source and how you actually virally spread software and make it take hold. So yes, they charged for it. And they charged for it on a model per developer seat, or sometimes worse. Sometimes per deployed seat. So, if you were say a Swiss bank which were some of the few people who had the money to buy this stuff, and they would tell you, “Yeah, we're going to put a Smalltalk, this system in front of every teller. And you're going to pay us by deployed seat for the tellers.”

Oh, wow.

And back in late 80s, early 90s when they said, “You're going to get a PC with 32 megabytes of memory to make this run well,” and that was considered a very high-powered costly machine, and you're going to put one of these for every teller and pay us by the seat, the Swiss banks could do it but most people wouldn't. The nice thing about that was you had the development environment deployed everywhere. So, if anything ever failed in the field you could debug it just as if you were building it on your desktop as a developer. It had all the facilities to do that, which is great but also a double-edged sword because that meant that source code was exposed when people were not used to that idea.

So, there are lots of things. Being different makes you a target. That's a generic statement about life, sadly. And Smalltalk is so different that it certainly didn't fit in, in those days. Though many of the ideas eventually, it's had huge intellectual impact on the field. And those ideas keep coming, including the live programing stuff which is only coming now. But they were just mainly way ahead of their time.

Yes, Smalltalk has so many important ideas that like you said we're just now getting back to in mainstream languages.

Yeah, because it takes a generation or so to get to that. Because for various reasons, people can only absorb so much innovation.

Mm.

And programming is a cultural artifact. And so, that's why people get so religious about it. That's why people get so conservative about it. You can only teach radically new concepts at a certain stage. After that developers tend to lock into what they're used to and it's very hard to convince them to do something different.

So, if somebody were to actually go and design their own language, I'm curious. What considerations do you actually have to make?

Oh, boy. Well, it all depends. For starters, today we've gotten to the point where it's relatively easy to build a language because there's so much tooling. You need less expertise than you used to. And it depends what your goals are. Do you expect this to be something real? And in that case you better understand what the application space that it's well-suited to is. You need to understand where hardware is and where hardware will be in terms of what's, if you're going to compile it efficiently. If you're not too concerned with efficiency, that's much less important.

One of the things I think that has been historically neglected and people are starting to catch onto and should pay attention is that programming is an experience much more than… we look at languages as these narrowly defined things. Here's a syntax. If we're not too shallow we think about the semantics. Many people don't get past the syntax. But if you do, there's the semantics to it. And it's a piece of text. And it means something and you think you could put it in a file and compile it and whatever. And that is how it's been since Fortran in 1955. But in reality when you choose a language for real as a developer, you think about the tooling. You think about the libraries. You think about the culture and the community and what support is there. You think about whether there are vendors supporting it and things like that. So, there's this whole ecosystem that you have to consider.

And Smalltalk is an example of somewhere where they didn't make this separation of language and tooling. And it's good to keep the separation aware because you don't want to force people to have your tooling, your preferred tooling, because people have different choices about tooling. On the other hand, thinking about how the ideal path of tooling with work and how that experience will work together, because you're not just writing text in pencil and paper. You're always working with something, even if it's just your most basic text editor. Being aware of that and how these things might interact, what makes things easier to debug or to trace or all kinds of things like that, is really important nowadays.

Right. We don't program in languages. We program in systems.

Right. So, it's about PX, program experience, not PL. That's a change that I think certainly the academic community as usual has been totally blind to. They'll be the last to know, I'm afraid. [Inaudible] [Laughter]

And because computer science has its roots in mathematics. Well, electrical engineering and mathematics, but certainly programming languages primarily in mathematics. And the outlook is about text and meanings of equations or expressions or things like that. And they just ignore tooling. It's looked down upon as not publishable, not academically viable, all of which is completely bogus. But if you're an academic and you spend your time on tooling, you'll have a hard life. You might not get tenure because people will not publish you or because they'll say, “Oh, this isn't fundamental,” or something. There's a bias there. And it's going to change largely by the example of industry over time, because they'll follow rather than lead I'm afraid in this area.

But you do, if you're actually interested in making a good language you have to be aware of that. Look at Swift in the playground. That's something that there's also been influence by the live programming tradition. You have to think of all of these things. You should be able to think of the language as a thing that you can isolate and reason about and prove things about if you can and put it in a file so that it will be compatible with a lot of tooling that's standard. There, the text is the lowest common denominator. But you should also think of how that experience will work at a different level.

Ah, be able to record it in a text file. Yes, Smalltalk didn't have that and Smalltalk was actually going for lock-in for pricing model reasons.

Yeah, I don't know how conscious the… they got lock-in almost immediately even without trying. They didn't have to scheme to do it. Their model was inherently that. What locked you in was the fact that each vendor had slightly different libraries, more or less by accident I think, more than the… because the image model, all of them had the image model. And you're no more locked in, in that sense, than you are with a language. Once you chose Smalltalk, okay. But the thing is you couldn't easily… it wasn't trivial to take your Smalltalk from one vendor to another.

Mm.

Because of library differences. Some of the libraries were kind of well standardized. But because it relied so much on reflection, literally the code that created your class when you filed it out was slightly different because the reflective library was slightly different. So, it caused the basic code to not be immediately portable. And so, yes there was lock-in. But less by, usually conspiracy theories… never attribute to malice what you can to incompetence.

It's just an accident that… they weren't scheming. Of course I'm sure once they had the lock-in and they thought there were making good money off this which they were for a while, they didn't mind it. No vendor minds it if, “Oh, we have a lock-in. That's too bad. How can you get rid of that?”

That doesn't tend to happen. But I don't think it was that deliberate. It just happened by virtue of the model.

And they didn't yet value portability and standards the way that a lot of people do now when you've got your abstractions of, what's the example? In Java, [chuckles] you don't want to lock-in your database. No, so you're going to use an ORM. And then you don't even want to lock-in your ORM so you're going to use the Java Standard API version of the Hibernate interface. And even though you never actually change your ORM and I hope you never change your database, because that's incredibly painful, people really like that feeling of retaining choice.

Right. They may actually be in a cell but they like it with big windows that give them a feeling that they can get out. [Laughter]

So, that's true. Now, back in those days I don't think… they thought about portability in different terms. Like one of the things is that only Smalltalk systems, well not all of them but some of them were some of the most portable software you could write in terms of, could you take it to a different operating system? Or Park Place ran on almost anything from Sun to PCs to Macs to whatever.

And you would take it and it would run bit-identical because it was running in this image and very much isolated. It's a double-edged sword. All these things have pros and cons. And they were very portable but they were not portable across Smalltalk vendors. They were portable across machines and stuff and in a way that is still hard to replicate. But yeah, they definitely… biggest problem is they were ahead of their time in some ways, in the technical ways. But they didn't see the future in terms of how the culture and business side of things really went. They were thinking in terms of software is something you sell and so forth.

When you say that programming is an experience, I agree with you. I think this is very important. And part of the reason is that a program can't be changed until it's alive in a programmer's head. I have to have a model of how the program works, how the pieces fit together, what the purpose of each is, in order to change it. And that sort of interdependence of the program and the programmer is described by that experience.

Sure. And the programmer will actually actuate those changes by some sort of tooling, right? These are all electrons in some machine. We're not able to manipulate them very directly. It isn't like stone tablets. And so, even [inaudible] though I haven't personally programmed that way.

Though sometimes it feel still that I'm still doing that. But the tools, the text editors, whatever, this is how it feels. This is how, what the activity really is like. It's different from skiing or working in construction. There is an experience to it. And it really does matter. And it matters how frustrating it is to debug something. What happens when something goes wrong? What kind of error messages do I get? How can I see really the state of what went wrong? Do I have to simulate it all in my head and try and figure out, “Oh, where did I go wrong here”? Or can I use the computer which is actually really good at that to do that for me? That's why the liveness is so important, because there's no reason we have to keep it, so much of this in our heads working. We have machines for that. And they can do a much better job of it than we can and they usually do with commonplace tooling.

Right, right.

And the thing is once you get used to the machine doing it for you it's really hard to go back to the Stone Age. Smalltalk or Smalltalk-like systems, they give you in certain ways the life of luxury. It's so nice that you can, when something goes wrong you can always find out exactly what the state of the objects were and say, “Oh, this is wrong.” And I don't have to restart things to get back there if I figured out what's wrong or I have a hunch what's wrong. I can just change it and tweak it and go forward a lot of times, which is something that again you have to experience because people tend to not believe that. But you usually can not only make the change but you can very often keep going even though the program was wrong. You can adjust its state now a bit and say, “Okay, let's assume that this is now consistent. I can keep moving and see what happens.” And you get so comfortable with that and it's so much more pleasant that after that yeah, you ramble on about it like I do.

Do you think that that kind of power, that kind of visibility maybe lets you write more complex code that's harder for someone else to figure out later?

Every improvement in productivity will eventually be cancelled out by the fact that people take advantage of it to write more complicated things.

And the answer to that is let's shut down all the machines and go back to pencil and paper, where things will be a lot simpler.

Woohoo! Let's do it.

Yeah, right.

Of course it could. Now in practice, Smalltalk code is usually not more complicated. It's usually a lot simpler because the language itself has its own merits. The language and the culture and the tooling, they all encourage programs that are actually in a way a lot easier to read. For example, Smalltalkers typically write very short methods. I think an average method is probably four or five lines. And partly it's because the way the tooling works, because you're not using a conventional text editor; partly because the culture is yes, you're always delegating to something. You're sending what they call messages. You're invoking methods and objects are very well encapsulated and you keep top-down, passing the buck as to who's doing that. And the syntax, it all plays together in a way that encourages that. So, I don't think… of course people have written and do write and will write horrible code in whatever language you give them. Or they may write glorious code that is very hard to read. Look at Haskell.

It is very brilliant. People are writing very brilliant things. Or take it further. Look at APL, the final frontier. The whole game there was to write the most concise, clever, brilliant algorithms you could except that god help you if you had to read it later. So, there…

So, complexity…

Yeah, go ahead.

Oh, so complexity isn't a consequence of the tooling but of the culture?

No, it's a consequence of all those things. Culture can help by fighting it or by encouraging it, depending on your culture. The tooling, the better the tooling is… if the tooling is very well designed it might actually encourage you to structure things right and simplify things. But by and large if you can make… it becomes easy to do something, people will just do more of it until it becomes complicated. That's a sad fact of life. But hopefully in the process they'll do something more useful. That's why we have this whole mess of software that everyone complains about. As I said, you can throw it all away. I don't think anyone's about to do that even though it is complicated. So, surely it doesn't have to be as complicated. It shouldn't be as complicated. But certainly some people will mess it up, for sure.

That's a very helpful way of looking at it. Thanks.

That some people will mess it up. Yeah, it's an optimistic thought, isn't it?

Well [chuckles] actually you're inspiring me to use IntelliJ more.

Okay.

Because sometimes, I'm writing Scala mostly and IntelliJ is the best tooling that we have for that. But sometimes I'll switch to vim just to encourage me to organize my code better. Because IntelliJ makes it really easy to just throw things everywhere and I can still find them in the IDE.

Mm, I see. Okay. Well, sure. So yeah, that's probably an example of that. And yeah, sometimes it's a matter of discipline. You have to balance that. And it depends how much you like the tool and overall, what does it buy you? But yeah, with Scala in particular you have to be careful with complexity I think.

Yes. Gilad, tell us about Newspeak. It sounded from something you said earlier that it's a language for building languages?

No, it isn't. It's a general purpose language. It's basically, you could think of it as a Smalltalk derivative but it's enough of a… it's a different language in multiple ways. Essentially, the hubris of this is not lost on me. But I set out to fix a number of things I thought were wrong with Smalltalk. And as someone who really loves Smalltalk, and the closer you look at the details of how well designed and how well thought out a lot of it was and how easy it is to screw it up, then you realize how arrogant that sounds to try and improve on that. But I think that after using it for many years I could see some of the weaknesses.

So for example, yes, the biggest weakness was that Smalltalk didn't have a strong concept of modularity, partly because it was designed at the dawn of when these things were being actually researched. And so, having a strong concept for modularity which fits very naturally with a model is what we did in Newspeak. So Newspeak, A, it has a syntax for classes, for like a regular language which means we can use standard source control. But that syntax includes class declarations that nest. But they don't nest like in Java. I have to emphasize that. It's not the same model. And the top-level classes are totally modular. There's no global namespace, unlike Smalltalk or unlike most languages you're used to. Basically that top-level class can only get at anything if it's passed to it as a parameter to its constructor, as it were.

And so, it's naturally sand-boxed which gives you a very strong notion on modularity, a very strong notion of security. Essentially object capability security falls out of that. And basically let us get around Smalltalk's security and modularity problems. And also we addressed the issue of having source code. There are a number of other things we wanted to do which we've never gotten around to. But its real strongest point, the thing that makes it most unique, is modularity. Another way of saying that is you could think of, I don't like to say it that way but it communicates something to people, you could think of it as having dependency injection built into the language.

Mm. So, are people…

Constructor.

Are people using this for stuff in production? Or…

So, Cadence where we developed this still uses it for production, yes. But I don't think anyone else is using it in production sadly. But hope springs eternal.

For a while Cadence had funding for this. And when the great recession came, that funding was lost. And so after that, it's been a labor of love. And as a result, we've done some interesting things but we don't quite have the bandwidth to keep it at a production quality that we'd like. So, Cadence uses what they need and things that they don't need, we have a harder time keeping it at top quality. But it's out there. It's open source. And research is done with it. And hopefully some more people will pick it up.

If someone wanted to experience the Smalltalk style programming experience with that live coding and immersion, would you recommend that they look at Smalltalk or could they use Newspeak for that?

They could use Newspeak. Newspeak might have a few rougher edges because it is a small open source system and there's not a vendor building it. So, there are multiple… there's an amazing amount of Smalltalks available for people to choose from, oddly enough, unlike most languages. Maybe that's actually a problem. But usually having multiple sources was considered a good thing. There are, I don't know, one, two, three, four, I don't know. There are probably half a dozen options you could choose, which Smalltalk to use. Or you could use Newspeak. And yeah, the thing is you have to be willing to learn something new. But any of those will work. If you want me to name names, I can do that, too.

Yeah, why don't you name names and then we'll make sure we get, we'll get stuff in the show notes.

Okay. So, Smalltalk's… probably there are open source versions. There's Squeak. There's Pharo, P-H-A-R-O, which is essentially forked off of Squeak and is sort of more production-oriented I guess I'd say. There is Dolphin Smalltalk. There is a commercial Smalltalk. There's Visual Works and they actually have two products which are descended from two distinct systems that when they merged they kept both product lines because they had, there are lots of customers using that that didn't want to migrate. Or have tried to migrate to Java and had disasters in the process because they find out it wasn't as easy to do that, to do what Smalltalk does. So, that's about five. There's Newspeak. There are probably others. There are a couple of efforts to do Smalltalk on the web. Newspeak to a limited degree runs on the web as well as in its own environment. But if you want the live experience, you want the original thing which kind of runs embedded in a variant of Squeak, the Newspeak on Smalltalk. So, that's more choices than you have for most language implementations, really. Perhaps that's the problem. I don't know.

Everybody's got that Smalltalk bug. [Chuckles]

Well, I would like them to have the Smalltalk bug. I think that it's enlightening. They'll learn a lot that they didn't know before.

I have one finishing question. Harkening back to your introduction, how are programming languages like shrubberies?

How are programming languages like strawberries? Well, they could…

Shrubberies.

Oh, shrubberies. Oh, shrubberies. Oh, shrubberies, yeah. So, that's a reference to Monty Python. The Knights who say Ni I think.

Mmhmm.

Somewhere there's someone who says, “I design and build shrubberies.” And he's very proud of that. And it's a rather exotic occupation which is why Monty Python had a field day doing this. But in that sense, programming languages, someone who does programming languages in industry full-time for design as opposed to compiler implementation or things like that, there aren't too many of us that do that. There is probably a handful. And so yeah, it's like that. I can always still tell you why they're like strawberries or like…

Yeah, why are they like strawberries?

They can be sweet, they can be sour.

They can be spoiled rotten. They have a great deal of variability in the same way.

They have the seeds on the outside? [Laughs]

Yeah, I don't know. Yeah, if we could pursue this perhaps we shouldn't pursue it too far.

Do you have to put your programming languages in the refrigerator?

Some of them you should put in the freezer.

Mm.

But yeah, we [chuckles] I won't say which necessarily.

Alrighty. Well, let's go ahead and get to some picks. So, the first one I'm going to pick is, so last week I was in Amsterdam. And then I was in St. George, Utah. And in Amsterdam they had these, they're kind of like cookies except they have, they're stamped like a waffle. They're called stroopwafel and they were delicious. I brought some home for my family and it was a lot of fun. So, I'm going to pick those.

I've also got two book series that I've been reading that just came out with the next books in the series. So, I'm going to pick those. The first one is The Iron Druid Chronicles. The next book is 'Staked'. It's kind of just a fun and clever take on… it's fantasy and the premise is that due to people believing in them, all of the different belief systems actually exist including the gods and other creatures. So, you have the Greek mythology and the main character's a druid. And he worships the old Celtic gods. They've got the Norse gods and all of that. Jesus and Buddha. And anyway, it's a really, really fun storyline. So, I'm going to pick those. Just a really lighthearted book series. If you're into fantasy and you're into that kind of stuff, it's fun.

The next book series that I'm going to pick is The Reckoners series by Brandon Sanderson. The book 'Calamity' just came out which I think is the last book in the series. And anyway, it's really awesome as well. And I'm not really going to explain the premise of that. It's kind of, it's a magical world overlaid with the future of this one. So anyway, it's really fun, a really great series. A little bit darker I guess than The Iron Druid Chronicles. But anyway, I really enjoy those as well.

One other thing I'm just going to mention of The Iron Druid Chronicles is there is a little bit of language. Not so much that it really bothered me but I know that some people are more sensitive about that than I am. So, if that bugs you then don't read those books. But yeah, so those are my picks.

Jessica, do you have some picks for us?

Yes. I have two picks. One is a Katrina Owen talk from BathRuby last year called 'Here be Dragons', something like that. And she goes through some rather scary Ruby code giving you a lot of pointers about, maybe we should work on this coding style here and there. And then she compares writing careful code to participating in prisoner's dilemma. It's a really interesting talk and it's 20 minutes. And I'll put the link in the show notes.

be kind to the other people on your Slack channel. And don't do the super flashy complementary colors. Stick with the slow party parrot because it's extra awesome.

Those are my picks.

Alright. Gilad, what are your picks?

Okay. So, I probably completely misunderstood the concept of picks when you sent me the invite. But I'll invent one now anyway. So, the author Umberto Eco died on Friday. And he wrote a lot of books that I don't know how much they're going to appeal to the podcasters. But again, I encourage them to try something different. Look at some of his titles. The most famous one is the oldest one. It's his first novel 'The Name of the Rose' which was even made into a movie. It's kind of a detective story set in the middle ages. The thing about his books, he was a Professor of Semiotics at the University of Bologna. And so, immense scholarship. There are references to almost obscure things you never knew about and quotes in Latin and whatever. So, it isn't easygoing but it's also, he combines an interesting story with a lot of historical and philosophical setting.

Then there's a whole bunch of other ones, some of which are better than others or more readable than others. I think one of the newer ones, you might go with 'The Prague Cemetery' which is relatively easygoing and fun. Or there's 'Foucault's Pendulum' which is great but it's probably a bit of a challenge. So, check him out, Umberto Eco with a U, if you guys don't know of him. And E-C-O I think is… anyway, Google will correct your spelling in any case. So, that's a suggestion that since it seems that picks are really not very closely related to computing, that it's a good suggestion.

Thank you.

Alright.

Although we often have a lot of very computing related picks.

Yes. Yeah, I was just being lazy this week because I was traveling and didn't have a chance to really look stuff up.

Yeah. Oh, another one would be Stanislaw Lem of course. Science fiction, if you're into that. He's, well he's dead. But he was a Polish writer. Wrote many, many science fiction books in very different styles. Some of them are like fairy tales. Some of them are very dark and serious. And again, if people are looking to… and he really understood computing way, way back. There are a lot of references to computing in those books.

Alright. Well, we'll go ahead and wrap up the show. Thank you again for coming, Gilad.

Thank you for having me. It was fun.

If people want to follow you on Twitter or connect with you in some other way, what are the best ways to do that?

They search on Google and they find my blog and my web page. And yeah, there's a Twitter thing and there's even a G+ thing. But do I remember the handles? Do I care? Let them search. There are search engines.

Alright. Well, we'll go ahead and wrap up the show and we'll catch you all next week.