Newspeak: A Principled Dynamic Language

>> BRACHA: So, thank you all for coming. And from--thank you. Yes, in particular for inviting me. You can--you can attack them later. So, yes, so, this is about what I've been working on the past few years, which is a language called Newspeak and the idea of Principled Dynamic Language is not an oxymoron, but this is actually a dynamically typed language that is geared towards software engineering and doing things the right way. So, not necessarily, you know, some people may think there are othe

r dynamic languages that are like that, I won't comment. But basically it's a class based language and what makes it interesting are two properties that are sort of defining properties that are the basic principles that everything is designed around. Basically, as you'll see, you put--state out these principles and the language more or less designs itself from that point on. So, those are, of course, the fact there's no global namespace whatsoever. And that--that has interesting properties; for

example, if there's no global space, there's no global data, there's no statics of any kind. And that's a good thing for many reasons which probably don't need to belabor and I don't have the time to go into all of them. That's all--it's all good and well to say, you don't have any statics statement, this isn't imperative. At least at this dialect is imperative the sort of we're going on--on purely functional variation of this but in imperative language, a lot of people are bothered by the quest

ion, okay. There's no static statement, but where does it really go. Obviously, it goes in objects but, you know, you have lots of state that goes in objects but the whole point of statics state is that it goes--but it's state it has to be shared among many objects and you typically don't quite have a single object where it seems to make sense to put it. And the answer for that is an old answer, it's been known for 50 years. Like most of the answers in computer science have been known for 50 yea

rs, 30 years. Basically shared lexical scope, right? This goes back to Algo 60. And in a class based language, the natural solution is nested. Nested classes and those of you who's experienced with nested classes comes from Java, just forget that. Okay. Let it heal. And, you know, if you--I don't know if there's anyone here who knows Beta. Okay. Yeah. So, they invented--well they invented objects that are in this programming and then they also invented nested classes and they were the inspiratio

n by the way. I know for a fact they were this inspiration for the nested classes in Java. However, didn't quite work out the way it was intended. Likely because simply Beta is a very uniform language and all the power comes from the compositionality that you get from this uniformity and that uniformity never existed in Java. By the time you are adding nested classes while the rules for the types and the fields and the classes and the methods and they are all different. And then what you get--wh

at becomes compositional is their regularity, right, the number instead of an explosion of power from composing things regularly which is what you aim for in software, you get an explosion of complexity when all this different rules kind of interacting also. This is wonderful because, you know, I can spend 10 years getting paid to sort it all out. It's boundless. But real nested classes done properly are wonderful work for a number of reasons. They're great for modeling because most problem doma

ins have hierarchical structure and that maps very naturally into this nesting structure of classes. And they are a natural modularity suite solution. Lots of people who look at nested classes or class base languages have the intuition that really basically we should be able to organize things using that. But in practice it, never seems to work out, right? It's not that easy to pull it off but it can be done and it is a natural modularity solution. And in Newspeak, the natural that is what happe

ns, you know, if there are no packages, templates, bundles, modules, units, you know, there's so many names for all this extraneous things. Classes are the structuring, concept in classes, top level classes act us module definitions and it all works out rather nicely in my unbiased opinion. So, the other defining property of this language is that all names are late bound. And when we say all, we really mean all. So, for example, you can think of it that every--every place you see a name, you can

think of it as a first approximation that it's a virtual method. All right. Message send here is sort of small doc terminology that predates the common association today of messages what they think of. So, you can think of having synchronized and A-synchronized message send. The synchronized ones are just virtual method calls. The A-synchronized ones are for actors and stuff like that which is something we're starting to work on only now but basically, it's a very natural fit. And a slogan to c

apture these messages, a well known slogan you probably heard a million times and is widely used in the Java world and its good advice is the program to an interface not an implementation. The difference is that in Newspeak you can really do that. In fact, you have no options because that's the only way to make it happen is because if you give people the option to do it otherwise, they will screw up. So, everything goes through an interface. An implication of this is everything is an object. Rig

ht? A lot of, you know, a lot of people, you know, among them will always advocated that, you know, an object or any language is really isn't object or ended unless really everything in the language is an object and it's a good design principle but it isn't the design principle here. Here it's simply an artifact of the--of the higher designed principled programming into an interface. By interface we mean more or less what--what you think of in Java, proceeds really interface, [INDISTINCT] proced

ures. Not exactly what do you think of in Java because, you know, java interfaces have a few quirks like classes nested in interfaces and yields an interfaces and other weird things but--but the typical real use of interfaces, right? Now, if you--if everything's an interface, well, everything is--is an object because you can't talk to anything any other way. So, it actually follows. For example, one of the artifacts--this is, right, you can't refer to variables directly because you can define va

riables but you cannot refer to them because you can only refer to things for an interface. So, in practice, when you define a variable, you get access or methods automatically. And you're really using those access or methods whenever you use the name of a variable that's actually a getter method, right? And this goes not only between objects but internally within the object. So, when you talk to self for this, all right, that too is going to an interface. So, nobody, not even the code within th

e class itself cares what its representation is, right. If you have--you want to get rid of some very instance variables which we call slots, you do that as long as you preserve the interface, you replace it, say with the getter method that computes some value for this, et cetera, then no one will be the one wiser, not in--not other objects, not even your subclasses, not even the code in the class itself, nothing needs to change. So, that's kind of a nice property but that's kind of not really e

nough to justify a language. Where things get really interesting are that you can't research classes either because you really, the only thing you can refer to is a late found names, which is basically an accessor method. So, when you define a class essentially, you define an accessor method that gives you the class. This of course implies that classes have to be first class objects. All right. This is--of the same--it's another example of the fact that programming to an interface implies that e

verything is an object. All right. It also implies interesting things like classes are virtual, always virtual. All right. You can overwrite a class in a subclass with another definition. And the nice thing is, you didn't have to do anything special here. You didn't have to say that we want virtual classes that we're going to design them in et cetera. It just happens. It is--it falls automatically from these principles, you can't have it any other way, you don't have to specify if it's virtual y

ou don't get to choose, everything is light bound. Now, because all names are clipped on this way, classes also implicitly define mixes. Again, without doing anything special because the super class that you define is also just a message sent. And so, this class--that subclass--that the body of the class the actual definition of a class can be bound to some other--it isn't statically tied into some particular place into some hierarchy because you can overwrite it, right. And we make that a littl

e more convenient it's tactical but basically that--that property is already there. And that means you can do class hierarchy inheritance. You can define an entire hierarchy of classes or library or framework whatever. And you nested in some surrounding class. And then if you decide that you need to change something, you know, one point in that hierarchy has to change, you specify that change in a subclass and the entire library has--has got this property. All right. Again, through overwriting o

r the use of virtual classes. So, these are all very nice and very powerful properties and they all fall out completely automatically from just deciding to be serious about this idea of using interfaces program. So, now I'm going to do a--yeah. >> [INDISTINCT]concepts are phenomena, I didn't... >> BRACHA: Okay. So, you might be--the only thing I've ever set the--I think, we've indicated that they--no, but that [INDISTINCT] to you; maybe the only one for which this slide that has a name that peop

le who are more into this, right. So, Beta has whole philosophical spiel about concepts and phenomena. So, the idea of being the classes where patterns really in Beta are described concepts and objects are the actual phenomenon is real thing. And much is made right, there's a whole sort of thought process and methodology that folks and all those developed around this. And this distinction is something that I've always--this is one of the points where I've disagreed with them because this doesn't

really allow them for much in the way of metaprogramming of treating programs as data all that kind of thing, right, because there is sharp line between the concepts and the phenomenon. Now, if classes are first class, right, this is much more in the list, small talk, self tradition, right. So, the point is that concepts are phenomenon too. And this maybe should take it out because it's a distraction for most people but it is a point that all needs to hear. Yeah? >> Is it related to using the c

lass that was mutual [INDISTINCT] sentence on? Does that mean that the language for it's like, this fast, efficient mechanisms that's--that does the concept or is it something you can actually program in the language out of combined classes. >> BRACHA: So, I'm not sure what you're referring to. If you're thinking of them like a sort of class or module combinators or like [INDISTINCT] like my graphic business. >> Yes. >> BRACHA: No, there's no real support for that, you could program that at the

middle level reflectively but there's a very clear separation here as we'll get to the between midline and base mirrors itself. So, that really isn't there. I mean the only real--the only real combinator is regular sub-classic. And it would be interesting to add that. Obviously I am not averse to the idea but it isn't--it doesn't do the jigsaw style operators. >> And you could [INDISTINCT] with heritage? >> BRACHA: What? No. >> You have... >> BRACHA: No. No. So, okay. Mixins in my mind subsume m

ultiple inheritance, what you need to do--the reason you want in multiple inheritance to do that, you can use mixins and that they have a lot less problems. And mixins just happen and so, no we don't have multiple inheritance. We don't want--never want to hear or to see it again. >> Fair enough. >> BRACHA: I'm not very opinionated about these things. So, I want to do a quick kind of review of the syntax because I expect that--well I don't know all of you but I think there are about two or three

people here who would otherwise be able to read the examples as we go on. So, we're just going to do a quick go through for the basics of the syntax before I sort of switch to a demo and kind of illustrate all these points more concretely. So, X space foo means X dot foo parenthesis, right. And the stuff in red, is stuff you don't need. This is no surprise to some of you but, all right, why do you need these parenthesis? Well, they're used to--you need them because you have to distinguish in mos

t languages between an access to a field or something like that and a method that takes no parameters, all right. We don't have that distinction. Everything is essentially a metaphor. We don't need to make that distinction and that has the nice property. There are no parameters, well guess what, there really aren't any. You don't need to say here is the list of parameters that don't exist. >> That state also gives you the distinction between time of evaluation. So, in a language where methods ar

e really functions, X dot foo without the bracket means getting the closure and then adding the brackets in X means evaluating. >> BRACHA: Right. You never get the closure. >> Okay. >> BRACHA: I would argue that in object or in programming it is a cardinal importance never to separate that that closure from its object. >> Okay. >> And so, you don't get the closure. It doesn't work like whatever probably Python and whatever about--you execute. If you wanted the closure, you put it in a--you start

the closure in a field and you have an accessor for the field then, right. So, but it's we don't--we don't have that distinction. Well, similarly of course, the dot. Well, the dot is the object member. Selection operators since the only operation is select the memory for an object then execute it. You don't need to say that. And as we'll see--this isn't really the main topic of this talk but the syntax actually works really well for domain specific languages. And a lot better than the potential

Syntax, so we're happy to get rid of the dot as well. Binary expressions are kind of what you'd expect. So, the thing to realize is that this three factorial binds tighter than the [INDISTINCT] plus and if you translated it into something that's more intuitive, it will look something like these dot what are actually difficult, you can't write of course but you get the idea of what's going on here, right? Then, this is the one that's probably hardest for people to digest. The so called keyword s

yntax. And yeah, you know, the binary expression here is binding tighter than the keywords. So, we're sending Windows a method call--called version colon. And the arguments to that are the result from these expressions seven plus zero I. Seven plus zero I is the way to write a complex number of course and that's--that's an example of how this syntax works better than conventional syntax because there is no special support here for complex numbers but you, you actually, can express that, but very

naturally. And so, it's equivalent to all these things right. So, let's jump to--residence of the binary is higher than the keywords and the residence of the--this is the higher method, we've already talked about. And it--that's what you would expect if you look at how you would code it in conventional syntax. And there is a-when you have multiple parameters, you have multiple keywords and the order of the keywords is significant. So, it isn't really a keyword syntax in the sense that just the

main matters and you can shuffle it about. Add one to Cobol is not the same as to Cobol add one. All right, those are those are different methods. And, the real reason that I have stucked to this syntax which, of course, goes back to sales and small talk, and it's a barrier to adoption. Well, there's two reasons. One is, yes, it works so much better for domains specific languages which in the original scenario for news people is an important news and still is. The other real advantage is that be

ing a dynamically net language, it's very useful because you [INDISTINCT]carriers unlike say JavaScript where if you get the number of arguments wrong, you know, you go to some black hole somewhere. This can happen syntactically. It's generally much better to control things through context free syntax and it is true all kinds of fancy mechanisms like time checkers. Context free syntax is one of the very few things that we actually really have a handle on that we really understand in real work. A

nd type systems are on of those, we don't and never will. But that's another one of my un-opinionated, sort of, sidelines. So, yeah, let's go back to the language. The goals of this language broadly speaking are to combine these four things; support for modularity, security, reflectivity, meaning the dynamic stuff, right? The ability of programs to change themselves while executing things like that. And as you can imagine, security and reflectivity, there's interesting tension there. And it's--a

nd still to interoperate with "real world" the nasty stuff that's out there as opposed to say small talk which tends to huddle in its beautiful little world and doesn't talk to the nasties outside which is a big problem. So, at this point, I think, I'm going to switch to demo. Now, I don't know. Can you see it or do we need to sort of zoom this in because zooming on Windows it's very flaky but... >> [INDISTINCT], it's for us, it's good. >> BRACHA: Okay. And a lot other people, people far away ha

ve muted their mics so they can't complain. So, anyway, what this particular example that you see this is, this is the Newspeak ID running here and it's showing you a class called combinatorial parsing that represents a parser combinator library. I'm not even sure if everybody knows what that is but, it doesn't really matter because we're not--I don't have time to discuss what this, this library is kind of really neat, but I don't have time to really discuss what it does. I want to illustrate so

rt of program structure here. So it's a library, right? So down here we have a whole bunch of classes nested inside. This represents classes that constitute that framework. All right, they're all nested inside this enclosing class. And, so, yes. So, for example, this class combinatorial parser that happens to be the root of this whole class hierarchy, so almost all the classes here, there maybe a couple of support classes but almost all the classes here are subclasses of combinatorial parser. Al

l right, and if we take a look at this guy, then what I wanted to show you is just this particular method and you don't really need to know what it does or anything. You just have to notice this thing that it refers to a name here, ordered collection. Now ordered collection is generally speaking a class. It's been renamed since actually but it doesn't really matter here. But it's a class that's, say, it's now called mutable list, which gives you a better idea perhaps of what it is, right? Like a

Java mutable, a ray list or something. All right, it's a collection class. It comes from the collection's library. We need to use it here for some purpose, right? We're building some structure and we need the collections. So this library doesn't define collection obviously, that's a different library. On the other hand, there's no global scope. So where does this name come from? That's kind of the issue. And if we go back to the enclosing class, then we see actually, well, here it is, it's defi

ned, this is actually a field, a slot, defined in the enclosing class. And it's being initialized here to the expression on the right-hand side. >> [INDISTINCT] mutable? >> BRACHA: What? >> That's a mutable field or not? >> BRACHA: This in particular is an immutable field. That's why it says equal. >> Okay. >> BRACHA: Equal actually means something. And there is a syntax syllable "colon colon equal" that let's you define a mutable field, right? >> Okay. >> BRACHA: Now, in fact, how--that's an in

teresting point I was going to get to. So how do we make it an immutable field there's no time checker, there's no static analysis going on to enforce any of these things. However, if you declare it this way, we will generate a getter method then we won't generate a setter. And since you can never refer to the field itself, you're really only referring to the accessor. If there is no accessor, well, you're not going to change it. And so it's pretty immutable. Now you can do all kinds of things r

eflectively, right? Once you go to the mental level of, all bits are off, but by then your ready to program, you're just--will not be able to change its field efforts and initialize those. And this code right here. Let's look at, you know, slightly different view. This code right here is, you know, this is called the instance initializer, right? This is code that gets executed when an object gets created. The way this works, the way you create an object, you send a message to its class, that too

--basically invoking a factory method. Factory method creates an instance and then invokes the initializer. How do you define the factory method? Well, this guy right here. That's a method hitter. This stuff--well, I'm off by one character, right? This is the method item. All right, it's a message called, method called using lib colon with the formal parameter platform. And the class is called combinatorial parsing. And if you actually put this in a file, the syntax would be slightly more conven

tional. There'd be class in front of it and things like that but we don't show it in the ID. Now what does this header do? This header tells us that we want to have a factory for this class called using lib colon. And so, the class object, not the not the instances, the class object will have a method called using lib colon that will create instance and invoke the instance initializer running this code. So one thing to note here is basically the factory pattern is built in, right. You never have

to work this fine factories or think about it. Classes are always. All right, and that means that I can take some arbitrary, build an arbitrary object with the using lib colon that, you know, pulls objects are with cash or instantiates a difference class, or computes it or what have you, and I can send it along and no one will be the wiser, unless they're actually trying to sub class it. But if they're using it to manufacture instances, it's in-distinguished from a factory object. Which is, aga

in, an artifact of using interfaces consistently, right? So there are no constructors because constructors don't go, places don't support constructors. Constructors violate obstruction in a really big way. Now, the former parameter platform, well, this is this is an idiom, right? It's very typical. I mean, the name here could be anything, right? We don't--we can name it any method name with any number of arguments. But very often we have--we use this idiom. Platform is supposed to be an object r

epresenting the enclosing environment of the programming platform. And, what we do here, we send platform the message collections which will--we expect it to give us the collection library back, object that is the collections library. And we can ask the collections library for the class ordered collection and that's what we're doing. And we store it in a field because platform these formal parameters are in scope only in an instance initializer. So if I actually aim to use the inner body of a cl

ass, I'm going to have to extract them, and store them somehow. >> I believe [INDISTINCT]. >> BRACHA: Yeah. >> What is it that makes it an instance initializer? >> BRACHA: It's magic. This is this is the syntax... >> Right, but how do I tell it from the syntax? And what part of, is it the... >> BRACHA: Okay, you're not really seeing the syntax, we're not--we're looking at a structured view. >> Okay. >> BRACHA: We're not seeing the file, right. But, if we look at, let's say, let's go back to here

, right. So these are the instance methods, all right? Things like this, all right? They're, they appear later on in the file. There's actually, you know, the parentheses are lined up, and they'll turn into curly braces once I get around to it. So then I have to stop explaining, stop explaining this over. But, it's--if the syntax is such--there's a section that I [INDISTINCT] twice, this is where all the slots are defined and their initialization expressions are there, and that's what makes it t

he initializer. So, all right, so when you create an instance, well, basically, extract this class from the ordered collection library which we get from this platform argument, right? The point is there's no global scope and everything I want from the world has to come to me through these parameters. Like all the names I'm using have to be defined in this class or they're abstract and they'll come from a super class. And there are no global names. >> Surely there's a bootstrap somewhere? >> BARC

HA: Yes, but we use tools. We'll get to that toward the end of the topic. Right, this is the stuff that drives people nuts. It's how--where do I start? How do--what do I stand on? Of course, that's actually, that's the conceptually tricky part, right? You--how do you really get rid of it. So you shove it into tool space basically, this is the short answer. So given that--the nice thing about the fact that there's no global scope is that I'm forced to be very explicit off all the things I'm depen

ding on. All right, they're all listed here. I know that this whole module, the only thing it cares about from the rest of the world are these two things. So they're class and the order collection class, there's no other dependencies. Strictly speaking it has no dependencies whatsoever because it's completely parametric, but it does expect to be in an exantiated and have access to these two things, so that's kind of nice from a modularly perspective. The other thing to notice is because of this,

the only way I can access the world or do any damage in particular to the world is by is by the things that I'm given here, right? So it's running in a sandbox. All right, every top level class like this that's a module definition. And it sees nothing else, everything else is plugged into it, and it is effectively its own sandbox. All right, so the arguments to the factory method are the capabilities that you get because this works with--this is a perfect fit with the Mark Miller, sort of, obje

ct capability module. I don't know how many of you are familiar with--but basically the idea there is that, right, objects represent capabilities rather than checking security by finding who's allowed to do what. The idea is that you're allowed to do anything with what you have but access is controlled by whether you actually get those things that you know. If you have an object that can do something or it can give you another object that can eventually do it, then you can do it, and if you don'

t, there's no way to do it. And so, for example, we know that this class will never use reflection. We know that this class will never call a foreign function. It will never call being primitive. There's all kinds of things, because everything is always all access to everything including those features. It's not through particular language features but through objects. Yeah? >> The whole glasses on modules? >> BRACHA: Yeah. >> Then my question would be, so the, two of your features of modules th

at this city gets--if I not only depends on other modules but the [INDISTINCT] of interface and... >> BRACHA: Types on the brain, I know. Yeah, okay. >> [INDISTINCT] mentioning the type, I was just referring how to use it in practice, if you know that--okay, a combinatorial parser object meets a platform object, but I don't really know what the requirements for the [INDISTINCT] object. >> BRACHA: Okay, so there is the long and bitter argument to be had here. But, basically, one of the points her

e is in fact the types, actually useful for defining interfaces between things for the documented one. There actually menus in documentation, right? And there are inadequate documentation because even with the fanciest type system you can name, it doesn't really tell you squat about what the thing is really going to do. Unless you really go completely insane into the curry howard land and really turn into logic. Right, so real type systems will give you some indications, some hint about what mig

ht be going on. But, really to use the--any real tool, you have to know what it is. You have to know what is to it. And you can know what it's doing even if there are no types written at all because you've read about it on the interweb thing or something, right. Documentations, someone told you what it does. You'd have to do that anyway because it takes so long it will never tell you what you need to know. So, the interfaces are there for automatically checking certain consistency things, they'r

e not for telling you what it's doing. You look, you know, you can find out what it's doing in many other ways and this is the case here. Now we actually have optional types, which aren't checked yet but which do give you some degree of documentation, but that, that's really not the point. You can really, can live without them. And as far as modularity concerns, types have been a huge obstacle to modularity. The reason that I am able to, you know, publish a paper on this in 2010 when this is act

ually a very simple and straightforward idea is that because most people doing research on modularity have been hung-up about types and that has been holding them back because types actually run counter to modular. Types propagate everywhere they're sort of essentially global. They make it really hard to do modularity. Modularity, this thing, okay, here, I'm going to do dynamic system configuration now. Okay, time to use zero, it was in, time t1 is out, okay? Every six months can do this, right?

That's why they sell these little plastic things to stock your clothes in your house if you have small children because they can configure themselves dynamically. And they may configure in a bad way and crash, and you don't want that, right? This is what actual modularity is about. This is a web effect that this box can be taken and taken away. If it was done like say a typical Ada package then I could not unplug this. This would be statically linked. And then, when I went to the airport to go

back to the U.S., I'll take this and this would--and take this, and it goes down and there's a power station somewhere at the other end. And you know what? After 9/11, they've been very harsh about people taking power stations onto the plane. It really--they'll force you to throw it out away in a bin before you get on. And I'll have to throw this with it because I can never disconnect it, right? This is what passes as modularity in most of the type world, okay? So no, okay. Yeah? >> Actually, it

means that you have a blog that all these infamous things that you have people attached to it. >> BRACHA: Right, so it depends, right. With ML, you can sort of unplug things, right. With classic modules the problem is import, right. The configuration is statically bound, it never changes. There's--you cannot do anything. You only have one configuration in a given run. That's, you know--I actually have slides about this, but they take too much time, and I figured I didn't need to go into that in

this topic. I actually talked about this at the DFL yesterday. But, you know, I may not convince you, but--sorry. >> But still can you, I refer it to the question here, can you statically [INDISTINCT] up front whether the entire instantiation--it says you start somewhere--yeah. Can you statically verify that all the codes that you have will work? That... >> BRACHA: Generally speaking, generally speaking, no. And with all the type systems in the world you cannot statically verify that the code y

ou have will work. You can verify where the type system is set-up to verify and that isn't that the code works. That's why programs crash even in the [INDISTINCT]. Now you can--the kind of things that you do statically verify, you would need a type system to verify and you can add an optional type system to this, and that's a challenge. That's a research problem because the idioms we are using are difficult to deal with in the current state of type systems research, right? There's a whole body o

f research on virtual classes that cannot express the kind of things we're doing here because they actually are kind of--their point of departure was types and they, the types, impose all kinds of restrictions that make them much less useful and prevent this. Now, I have some idea of how I would add an optional time checker to this. But, in terms of banging for the book, it's so forth far down my list in the absence of sub funding for this project as a volunteer effort, it's, who knows when it w

ill happen. But, right, this is a dynamically type language. It is not--its strength is that you can actually flexibly configure things very easily. It doesn't, you know, naturally lend itself to the desired statistically know a lot of stuff of the [INDISTINCT]. So, what else did I want to say about this? A couple of other things that are worth mentioning; so yeah, so, we have a good fit with the object capabilities security, also because this is sitting on our library with class, right? I can h

ave multiple instances of it what is called side by side deployment, right. In Java, you use something like OSGI and class loaders, and, you know, it gets rather heavy weight and complicated. It is the class you can make--obviously you can make many instances because, you know, the distinction between a module design and its instances is very important and you don't tend to see that, in hardware you have to see it right. If you have a stereo system and it has two speakers, that means you have tw

o instantiations of the same design with–if classes are your module description and objects are your module instance, that works if sort of step, you know, modules in the traditional sense is a separate construct, are your module design then typically, that doesn't work, you don't really have a good way of creating multiple instances in a given run, right? >> I just have one question to this coding here. So the code in these nested classes does it–is there an implicit look up in the outer? >> Ye

ah, right, so, if you look at the paper, there's a description of what the local codes, what are they, right? So, on principle, even the local variables and the form of parameters are conceptually, you don't actually compile them this way but then you can think of them as also being a look up into, you know, for a binding that you don't have a good way of overwriting which way you can compile them recently, efficiently but, in principle, every name even platform is being looked up with--as a fai

ry tale. So, side by side deployment is something you get obviously for free, of course you can also have alternative implementations, right, this library has an API--the whole, the library as a whole has an interface just like a conventional object, single object that has an interface; which means you can have multiple different implementations. Say, if you want to replace this implementation with a packrat parsing approach or some other approach, you can do that and the users need not be the w

iser. >> Is that interface specifically spelled out somewhere or is the fact that all bunch of methods come together? >> How about yes and no or Okay. So, basically, mainly that the whole bunch of methods come together, they're written here right? You can write up an interface because there–it happens to be a type expression in some language that is optional. There's an objector for it and therefore, it's almost certain that this language would have to change in certain ways because the language

we're using is the optional type system I built for small talk once upon a time and this language is more dynamic than that and there are issues where that will probably break down; but it's main use as I said from my perspective, the main utility of types is documentation not their checking, and therefore, the fact that I choose to write these types, that's where a lot of the benefit comes from, these documentation is important not only for people, but for machines, all the kind of clever ID t

ricks that you might want to play with re-factoring or any completion rely on the documentation aspect of types not on the formal correctness on respective types. Yeah. >> You said in the beginning it was like you said that you have to code against the interface? >> And you have a complete different idea of what an interface is? >> Yeah, I guess [INDISTINCT] >> The interface mostly is a set of the name procedures, okay, that can be laid bound. That is the interesting property of the interface, t

hat's why interface gives you flexibility, it's not about something that some tool normally analyses this, it's not the type that, that's not the interesting part about it. So, what are we talking about? Yeah, we've talked about the fact that there's been multiple side by side instances, we've talked about the fact that had been an alternative implementations, basically all kinds of things that you do with regular objects it's all lifted to the level of all libraries because these things give es

timates all for free, because we don't have to do anything, we just apply the standard, you know, protocols and features that regular objects have. And of course, each of these modules because there's no static state unless you choose when you configure them; and in this mythical place we haven't gone into where we actually tie all this together unless you actually explicitly choose to share state between them then they're re-entering it, right. They're not going to step on each other because th

ere are no static variables that they are implicitly touching. So, this is all kind of good, what else can we tell you that's interesting? Oh yes, class hierarchy inheritance. How do we put that? Right, so, this class again, it doesn't really matter what it does; what is interesting about it is that it's intended to work as a sub class of the other library and it has a combinatorial parser class. Remember, combinatorial parser was a nested class that was the root of the whole hierarchy and we've

overwritten it here, we look at what we've actually done with it, we change some methods and you'd have to understand what the library does, and the library doing that and you don't really care or it would be a more convincing if I took the time to walk through all that, but that's a whole talk. But it so happens that for instance we added a name, so now, all the parser objects in this library will have a name, right, and the way this will work is when you create an instance of the surrounding

class and asked for any of its nested classes, classes; you access them by this access, all right, you make a call. At that point, the class gets created; it's very important that in fact a nested class is a property of a surrounding object of the instance of the object of the enclosing class. This is the great number one misunderstanding that destroyed Java on nested classes, right. Now, once you do that, you'll have to compute that class; so, if we took a class, let's go back and see the origi

nal library for a moment. So here, we went to a class like alternating parser, it's a sub class of combinatorial parser. Now, Of course, combinatorial parser here is just a method call, so, what happens is when I try to create this for the sub class library, I will call it and I will get the sub class libraries version of combinatorial parser. So, as a result, the entire hierarchy basically gets bound to the over written class, right, and essentially, it's exact same mechanism you have with any

method in an object towards any program where it's calling another virtual method then it will get rebound in the sub class. Same rule, same mechanism, and you don't have to think and that's very important because, getting rules consistent in the language is very, very hard, the best way is to sort of design it, so that this all falls out because otherwise you have to go to keep checking and attempt that if a possibility of making a mistake in the element we're using where the consistencies or t

he temptation to do it deliberately. Because it's slightly more optimal when I think I know what I'm doing, trust me, nobody knows what they're doing; I've been to that movie. So, that is basically–this is a case of class hierarchy inheritance, essentially we just specified a few changes to this entire library and we get a new library with all these new properties. So, that's one thing I wanted to actually show you. What else did I want to show you here? So, where is Brave New World? So, here is

--it doesn't matter, this is a class that's a different module, it's a little application that's designed to as a demo to do browsing the file system, right, so, it just gives you a little window and lets you look at the file system. So, again, it's a module, it doesn't really matter. It has a couple of nested classes that represent the way we--you know, the view of files, the file presenter here and the Symantecs of the application which is about the subject, we don't really care about anyone w

ho was fascinated with this can look up--I gave a talk in Microsoft with the complete demo and the discussion and there's a video of it on the net. The point is again, we're using the same mechanism, right? We're using slot definitions as import system effectively, right? So, we have here a file directory and order the collection again, and maybe color, things like that, they're coming from the outside world where importing them via our platform parameter. And so, the question is again, how do w

e configure this? Where does it all get wired together? And it gets wired together via tooling and I'm going to show you some of this tooling. So, to do this wiring, we basically, we write an expression that will, you know, instantiate this Brave New World explorer object, and set it up with the right parameters and that would presume only create the object that I wanted, and this begs a couple of questions which we will eventually answer, obviously. Right, so, here, we have this method called m

ain colon, arc colon this is very much a close cousin of like main in C or main in Java; right, it's an agreed entry point by a convention. And the difference is that it not only takes a set of say, arguments that might be command lying arguments or something, but it takes a platform argument, that's what makes it different from those guys. And there's a bunch of code in here that basically sets up use Brave New World explorer, instantiates it with the platform or invent of extracts, you know, s

ome--sends us some message basically runs the application, right? So, this is your configuration code in a way and it's in the language, and it's in this class. And suspending this belief for a couple of minutes, you can see that if I have an instance of this class of Brave New World explorer app, I can send it the main method with the platform object. And so, I have a standard procedure for creating it, right? The runtime, the Newspeak runtime can take such an object pass it on an object that c

onsiders a representation of the platform's capabilities, and we will get a running system, right? The remaining several questions such as how did I get this object? But we'll get to those. But assuming you have this, then you have basically your--this object is your binary representation, it's your aid on out and you can call its main function and run the thing. Yeah. >> Is that a [INDISTINCT] Brave New World explorer app or why didn't you just nested scope for getting the access in that code?

>> You're getting a hit, you're going to get--as I said, you know, beg several important questions here, but, continue to suspend your belief just a few more minutes, and assume you have gotten this object, then yes you can create it, you've created it, you can run the program through this main interface. In particular, you could serialize such an object using basic object serialization, and your binary deployment scenario would be deserialize the object from this and colon main and colon arcs,

right, and that actually is a scenario we support. So, this is the analog of a JVM loading JAR files or something, right, except we don't need collapse files, JAR files, WAR files, OSGI, you know, the one of the points here, this is very much a minimalist philosophy, we're trying to get a lot of mileage out of a few very simple concepts, and you either buy that or you don't. So, that's how we do it, and the question–there's two questions that have to be dealt where one Mathias raised is where di

d Brave New World explorer come from again? Because again there is a scoping issue right? And the other is how did I create this object in the first place, right? Which are both related to the basic where do I stand, where do I bootstrap and start the configuration? So, Brave New World explorer is again, a slot and yeah, it got imported in some way if we look at the definition here, it turns out that this particular object, it doesn't even care about the platform, its factory method is file brow

ser class or it just wants to get the class that it supposed to work with as a parameter, okay? So that's its factory method. So, that's where Brave New World explorer came from but that's sort of one step where it came from, we're still going to kind of moving along and the question is how did we instantiate Brave New World explorer app in particular and give it, you know, appropriate parameter, right. And so, the answer to that is down here, this is where--as I said, we rely on tooling; by con

vention, we put this message back in using, and what it is supposed to get is some sort of object representing, conceptually it's the ID's namespace. It just doesn't really care if the ID's namespace it cares that this is an object that will give it access to the names it needs in order to instantiate itself, right?. And what it does it–this is a class method, so it's calling file browser classical and which is--it's a factoring method, and it is passing it, the parameter to one which is Brave N

ew World explorer and where is it getting it from, getting it from this parameter of the ID namespace. So, the ID which is the one place where you have all the pieces of your program, you may have either typed in or loaded, or gotten from than net, that tool, it's just a program, just a regular application, but that tool serves the purpose that you usually use a global namespace for that's built into your language. The advantage of that is if you don't have a global namespace in your language, a

nd therefore you do not have all these issues about people accidentally using it and requiring them to use great degrees of discipline and, you know, ignore temptations they cannot ignore to just rather by name and so fourth. >> But it also means you cannot program without the ID either? >> There are–this is one tool, you cannot actually program without say the file system and the directory system and something like make which actually goes and uses the file system as its global namespace to fin

d the different pieces that you are putting together, this is doing what make does. And I can make a really ugly stupid tool that with lots of dollar signs and stuff that you would, you know, type of command line incantation with 20 minus parameters and he'll do the same thing, and I know there are people who will prefer that. I personally in kind of, you know, a little more of GUI oriented. But it doesn't matter, there's ultimately, you are always relying on the tool even if you have a global n

amespace in your program, you still need the tool. So, getting rid of the global namespace is net benefit. Because in the end you're still going to use a tool to put the pieces together, and it's only for putting the pieces together for specifying configuration that you actually need this sort of global namespace and if it really isn't global, it's just the names of the pieces that you need to put together; and you've got them from somewhere and if the typical namespace you use is your directory

card, right? That's where you get the names ultimately for the files if you're doing conventional development. We're doing it in a slightly unconventional way, now, the nice thing is that for example, yes, so the tooling can help you here. Given that we have this method, the ID can detect that we have these methods, and it--because of that, it knows that it's, that this is likely a module--an application that needs to be instantiated, and it knows how to do it. So, it knows how to create an obj

ect and run it. So, we've added this link here, I don't know what window this will show up, and of course it showed up on the other window. But, right, so, now I'm running this little application and it lets me look at the, you know, the directory structure, and whatever garbage is in here. Right, it's a simple--it's a very simple little simple GUI demo that let's you browse the file system. The point is I created it out of these modules that do not use any global names; I did it via the tooling

system. The other thing that tooling system can do for me is since it knows how to create this object, it knows that, you know, if I wanted to deploy it, one way would be to serialize it and I can press deploy, and I have two options; one is, no offense, a Newspeak object format, that's basically a serialized object. Now unlike the typical scenario with serialized objects--one of the problems of serializing an object is you have this little object, you just want to put it out there and then you

have this 50-megabyte file because, you know, one thing points at another and you didn't realize how much garbage this thing really, really is connected to. Now the interesting things in these scenarios, again, because of the modularity properties of the language is that this object, when you serialize it, you'll really get like a couple of 100 kilobytes because what does this object refer to? Because it has no global name space. It refers to its class and in this case, it refers to brave new w

orld explorer, this parameter we sent it in because by that's the only thing field it had. And that was a class as well, a top level class which refers to nothing else. Does it--it doesn't refer to a global name space. So the only things there are the code. Yeah? >> Does it also refer to the platform? Or, or... >> BRACHA: No, because if you notice what's happening, the object got created over here, right? No platform involved. It built it by taking this class and passing it in. And if you look a

t the initializer, right, it didn't take a platform argument. Okay, let, let's... >> If that form comes in the next step... >> Right. >> Exit. >> BRACHA: So the only thing this class takes is a brave new world explorer which is a class. And that class does not refer to a platform. When you instantiate it, it refers to a platform when you give it a platform. But the class itself--top of the class never refers to anything. Okay, that's the whole point. And so all that's--is there is the pure code.

So if I go and choose the deploy option and so we also have the option of deploying it as a windows.exe. And I can show you that as well, but if I do this and where's--let's put it somewhere on the other screen. Hello. Oh, it's directory, probably, yes. So, I have this directory and, of course, I should have shown it to you earlier because this--these guys weren't there. So it actually puts it out and puts a zip version of it as well. And right, so this is 12 kilobytes. Now, to run this I need

a runtime that can load it and do that, and I can do that from the IDE. Well, of course, here I ran it, but I also have the option of--does it here--ran out--yes, okay. If I do this--ah, unfortunately, the projector was not happy when we tried to mirror the display, so. What I want to do is--and it's got to open it in a wrong place again. Right, so again, it's the same thing but what I've done something different here I've actually asked from a different window that is not following at any parti

cular app, to just choose enough file from the file system and run--load this 12kilobyte little thing that does this process, right. So that's a deployment scenario. It's not a very realistic one for us because, unfortunately, the world does not grasp the wisdom of newspeak. And so, you know think, of what Java does. Java does a lobotomized version of the same thing. It does--it's a very complicated, bloated inefficient way, but they can rely on the fact that through sun's power, this thing is s

tuck everywhere on everyone's machine and there is a runtime that understands jar files and all this crap and it loads it and that. When we, we can't rely on the fact that everybody has newspeak on their machine. You know someday, right, maybe, maybe not. You know what are the odds? But, you know, if everyone was wise enough to run newspeak on their machine, then here we have 12-kilobyte deployed application. That's why we allow you to do something less, less attractive which is to run--okay, so

there are no way--how am I going to show this? I'm going to drag you over here. So this guy is, I believe a .exe, that was created earlier by the same process, right, of this application. I hope it is, because otherwise it's always embarrassing if the demo doesn't work. Let's find out. >> [INDISTINCT] >> BRACHA: Yes, right. That's a .exe. It has like the whole, the VM in it and image and it could be made smaller with more engineering. But it would still be sub--pretty substantial because, you k

now, deploying all these so, because it has to have an engine in it. >> So this is a... >> BRACHA: Well, if an engine could be a dll. There's a lot of engineering to be done. >> So this is an image based system sort of like small talk or the self [INDISTINCT] machine, it's not a source based system, right? >> BRACHA: Okay. So the answer to that is not as simple as yes or no. Currently, its implementation is based on squeak, which is very much as you describe it in the phases. Because of these mo

dularity properties, it is very easy it's relatively straightforward to get away from that. Right and, particularly, it is possible to deploy it independently of an image, right? You can--what? You basically--however, you represent the runtime in, you know, in fact, this .exe--what this .exe is, is an image inside it and linking to the VM and all this, that's why it's seven megabytes, right? But it doesn't have to be that way. Look, the point of this talking over the language is not necessarily

the specific engineering of this state, but the fact that the modularity that enables you to do a little lot more. So, maybe I haven't answered your question. So anyway, yeah, it does the same thing, right? Except that it was from a .exe, right? The really interesting option that I'm--I don't have yet. Hello? Ah, yes, of course, it, I put up a window asking whether I wanted to quit, but it was, certainly, no. That was puzzling. The interesting option would have been--we had here another menu ite

m which would say web, all right. So, I'm kind of working on that a bit, right. We can compile this--I think we can compile it to JavaScript through some hoops. I've got a translator that's pretty far long, does some stuff. You need to think about the Gooey. This is a--the whole Gooey is written in newspeak and is bound to, in this case, to the window's native APIs by, you know, there's a series of layers and at the bottom there's a mapping layer. And that mapping layer can be plugged, you know,

ideas to plug in a different one that would map, to say something like HTML files. And I'm actually started to doing that. So at some point, hopefully, in a not too distant future, we would be able to actually run at least some newspeak application. And some things that are really painful to do unless you actually implement a complete VM on top of JavaScript, right, because some of the things the system can do which you haven't shown, right. You know, its buggers written in itself and all this

fancy things. Well, it's--JavaScript just doesn't have the privilege to give you access to some of these things, but most application code, we could probably deploy this way and that's actually, the actual deployment mode of interest in today's world. And I hope to get there. So how are we doing? We're probably out of time, aren't we? >> We technically have the room for another hour. >> BRACHA: Okay, so we do--so, if people want to sit for another five minutes, maybe I'll actually finish my talk

. Okay, yeah, we--I try to avoid interactive questions and I know the time gets--your schedule goes out the window. But we can--we're almost there anyway. What did--was there anything else I wanted to show you? Yes, there is something I wanted to show you. So this is the IDE. Okay, we have a little resolution and what will I do with that? I don't know what to do with that on this? >> Okay, make the [INDISTINCT]. >> BRACHA: Wait, wait, I think I need to bring it over here, and maximizing it won't

help. It's a little bit too be too big. I need to be able to scroll down to where I want to be and I want to shrink it from the top--I want to put it back, right? So what I actually wanted to show about here, right. This is a slightly different use of nesting, which is also, which related to modeling, right? Most of domains are hierarchical. So here, this is the IDE and the nested classes here are things like browsing classes, browsing--these are browsing classes for NS, that's newspeak, these

are the small talk, this is for the IDE window. So some of these things are basically just classes that are used for grouping, they're doing what you would do with the directory or something, right. So if I go to the browsing classes, there is a set of classes in them, right. I'm structuring this and so, you know, if I want to get a high level overview of things, it's a lot nicer to be able to do that then to get this long list because the IDE is a fairly substantial application and so the nest

of classes can be used for structuring as well. And so the architecture of this thing really is in the source code and portable with it and not relying on any kind of external organizations. So that is one more thing I wanted to illustrate and I guess the rest goes to the slides if I can get PowerPoint to cooperate again. So, yeah, we know, we've talked about all of this, and talked about that. I want to talk a little about reflectivity. I just want to mention, right. So I mentioned that that ho

w do you, how do you resolve this tension between all these fancy highly dynamic, able to change the program on the slide, it changed the class of an object on the file. All these kinds of things with the, supposed to go with security. And the thing is all these mechanism called mirrors that it goes back to self and--this bought a present in a lot of systems now. I mean JDI, the Java Debugging Interface, is basically a mirror base system, not coincidental. The nice thing about that is that it's

a slightly different approach to structuring reflective APIs where the reflection isn't tied into every object. In Java, every object understands get class and then you get class and then, you know, all everything goes from there. Which means that whenever you hand someone an object, you hand them the reflective capability to do stuff with, right? And then you can start having these fancy checks that go off and stack and trying to find out if you're allowed to do that or not, right? Because it w

as mirrors you basically separate that. The object can't do reflection on itself. You have a separate factory for a reflective object called mirrors, called mirror and it can give you mirrors with different capacities. Some mirrors might let you only reflect on your, on your object. Some may only, will let you look at public API's, some of them may only like you in prospect all kinds of combinations, right. So we've been very fine with control of what this object can do and you can control wheth

er anyone has these objects or not because again the way we control things here is through actually access to objects. So, a mirror is just another capability and that means that we can support all these reflection but we can very easily control who gets to do what. Well, that sort of the short summary and there's a whole talk about mirrors on the net if anyone cares. Interop--well, you know, the fact that I've demoed all these running, it's running on real Windows, Windows. That for smalltalk i

s, of course, smalltalk lake system is non-trivial; in particular, because it's still portable. Every, all of these Gooeys specified at a very high level and doesn't really care directly about what API is running underneath and that's, that's very important. And it also illustrates that we have a really working SSI which we call them aliens. These are objects that let you talk to the outside world. So, from your perspective and the news paper and there is no, there is no construct like native me

thod or external or any of those things, right. You talk to an object, it looked like a regular object. These aliens are object that make use of a particular primitives in the VM or in some systems the aliens wouldn't be VM, right, it might be just Java objects or JavaScript objects and you hide them under this alien API. In this case, there is an alien API that takes and manages the capability to call up to see. And the capability--because it's in object, again, you can control who accesses it.

Okay, so that's kind of the highlights of--is--oh, I forgot about that. So I was going to show you better matching and I was working on a slide and then I forgot, so we're out of time anyway. And, there's a lots of related work, obviously, and the most important ones are smalltalk, self, and beta. And the closest thing to a similar approach to modularity is say [INDISTINCT] skin units. But there are important differences and I think our system is basically in a way simpler. We're just leveragin

g the object paradigm all the way. My argument here is if you actually, if you actually understood object orientation the way I think it should be understood, correct way then you don't need all these extra. Objects and glasses will do it all for you and it worked very well. You know some scholar and lots and lots of distant decades of research on this, right. We're opensource, Apache 2.0. You know, we're basically a volunteer, unfunded effort at this point and basically all works very well toge

ther. All these things are of a piece, it's synergizes, whether it's this idea of late, this late binding, virtual glasses mix since modularity, it works really well for actor based concurrency as well, mirror based reflection and types system, pluggable type system actually fit in very well here. Though there is a real challenge of actually figuring out what the rules will be to properly digest this. You know this is beyond the state of the art. We can push that. So, yeah, these are some of the

people who worked on this. Well, these are all people that have worked on this well, except for some open source volunteers who have done some important work since, but the people who worked on it when it was a real project and me. And these two guys actually worked for this, this web company called Google; Peters and Denmark and [INDISTINCT] view and, you know, they did a fabulous job obviously. And that's my story and I'm sticking to it. Yeah. >> In the green slide it said that [INDISTINCT] b

ased of currency, [INDISTINCT]. Could you elaborate, [INDISTINCT] >> BRACHA: Okay, so our view is that an actor would be an object which would be bound to a thread of control and beyond bound to it, right. So, the particular model we're looking for is we're looking at a re-link is the E-model. Capital E, Mark Miller's language which--so it is different from example from Erlang or [INDISTINCT] actors. It is in a way closer to the original actor model as [INDISTINCT] described it. But it elaborate

s some of it in some ways, right? So the big difference actually is that there is no blocking received, right. So Erlang actors and [INDISTINCT] actors are basically real actors written in stock. I have this idea of a received construct that pattern matches on the message cue of that actor and this was not in the original actor model which is more, sort of, dynamically oriented in a way and let actors specify replacement behaviors and things like that. And so the effect of doing it the other way

is that, again, we kind of unify actors and objects in a deeper way because we don't have the messages that actors process are defined directly by their methods, okay. So, you know, and we don't have the blocking receive which I think is an important issue. I just have this debate with [INDISTINCT]. What are the strong arguments of but, but I... >> They're sending a message to an external [INDISTINCT] end up in the thread of control that [INDISTINCT]... >> BRACHA: You would eventually end up wi

th executing the method of that name with those arguments in that--with that actor running on some thread of control with the heat that was associated with it. Yeah, I'll go this way, still figuring it out. >> And you didn't mention imperative program, you know. How much of this is actually... >> BRACHA: Imperative? >> Yeah. >> BRACHA: So, this--so the nice--this is an imperative language as it stands. But the nice thing, it's very easy from--at the language level to turn it into a purely functi

onal one because the only place that you actually define mutable state is when you define a mutable slot. All right, because the axis doesn't care, right? So there's basically this one construct in the initializer or in any actually method where you define your slots. And if you define them as mutable - then a mutable state and if you define them as immutable, you don't have a mutable state. And this a bit of a lie because the other thing about it is of course that you can observe the order, rig

ht, because they're nil initially. Now, what should be added very soon is a simultaneous slot definition which is sort of a glorified literate, they're a bit more than literate. But basically, you will not be able to observe the order. And then if you'll only use immutables, it will basically--it will also handle mutual recursion because basically what we'll do is every slot will be initialized to a future for the expression that's actually written there. And then you can do, and this is importa

nt for, say, a mutually recursive module definitions and stuff like that. At that point, you can basically define with changing that one construct or essentially we'd added and so you'd actually take out the immutable slots. And then you would have a purely functional language. Of course, there's a whole quite--interesting questions arise like, what about all these reflection stuff? So you can you change--can you change the program or does that have to go, or is it only functional language at th

e base level but not at the meta level, which is kind of where I'm leaning, right? And the real work is of course that because it's an imperative language, all these libraries, you know, they're in a pretty good style but they have--they certainly have imperative parts to them and we'd have to redo them, right. We have to redo the collection libraries. There's a good way to redo the collection libraries. You take Martin's code and translate. It will work just fine. It will be a lot easier becaus

e we won't need to find the higher kind of types and all that rubbish but it will just work. So, that would be an interesting project. Again, here and there, I get volunteers who are interested in--we do a little removing but it's frustrating, right, because without money, life is hard. But, yeah, and the other idea is of course to go further and say, "Well, let's change the semantics and we'll hope it's functional, dial light and make it lazy." And then you have sort of an objectory that's Hask

ell. That's kind of an interesting--though, I don't think were going to need it because I actually think that going to--if I wanted to do that, I'll go a pure actor-based language like Hewitt said. Like, where every expression is theoretically it's all a little actor, and it's--on optimization probably. But then you don't need monads, it all goes away. Basically, what he said in 1973, takes another 10 years but we're going to get there. So, okay, you're--we're getting there and I don't use to--y

eah, okay. >> Can you talk a bit about unpluggable types, like do you envision one program that would adhere to many type systems? Do you see type orientations like what is it? >> BRACHA: Okay, yes. I can talk ad nauseam. So, in fact, I have talked and there are talks of--I hope these are recorded to their slides on the web and so forth. So the basic pluggable types--the idea of pluggable types is, again, you have to be very careful about the discipline. You know, you have to avoid temptations.

So the key idea about my definition of optional pluggable types is they do not perturb the run time semantics, right, which is not true of any mainstream type system. In fact, you would be hard pressed to find a statically-typed language where they have been able to avoid that temptation, right? Every language that has types, those types change what the program does, all right? Now, the only exception to that that I know of is not a real executable language because lambda calculus, the whole the

ory of types, that's clean. There, lambda calculus doesn't sting, the types are purely a mechanism that can tell you if something might go wrong, but they will not change what it does, all right? That's because the theory is actually--and another thing about lambda calculus, is no global names. All right. The theory is beautiful. The theory knows what it's doing. The implementations are garbage. But we'll--so it's very important to do that because if you let the type system perturb the run time

semantics, for example, overloading in job, all right? That means which method you actually get to run depends on what the type signatures statically were of your arguments. That's one example of things like that. Any temptation to do what, say, the Adobe folks did where, you know, their optional type annotations introduce a cast or dynamic checks, all of that perturbs things. If you want to--pluggable type system, yes, you want to be able to add multiple type systems for different--they're basi

cally like a lead. They're optional static analysis. It's important that they do not interact. If they perturb the semantics, they're all perturbing a common--there's some common state that they're all messing with and, therefore, they interact in there, then everything collapses. There's no way you're going to sort it out. So it doesn't change the semantics at all. The language does what it does, all the type system will do is tell you, "According to my rules, this could be a problem." And that

's what all it ever should do. And you could do this, you know, for various purposes of, you know, the conventional type of checking or other kind of information flow, there are, you know, things like that. So that started the shortest expansion on pluggable types I can do. >> So popular dynamics type language applications [INDISTINCT]. >> BRACHA: Sorry, I didn't catch that last half of your sentence. Popular dynamic language do what? >> Where missing from the date it were assigned like Python o

r Ruby. >> BRACHA: Okay. So, yes, that's not a coincidence. Related work means that there really is a deep relationship either in the history of the ideas or something like that, right? If Python never existed, it would not change what I know or think about dynamic language as one dot, right? These languages are not noted for their intellectual contribution to the state of the art of programming languages. They are particular implementations of ideas that have been successful in the marketplace

for whatever reasons, and one can speculate, but they do not bring new ideas to the table. I'm sorry. Everything that you can do in Python, you could do and list decades before and do better at Python. So, they're not--they're not there for a reason. They aren't really going to work. >> [INDISTINCT] actually have similar state [INDISTINCT] implementations. >> BRACHA: They may agree with that. So as far as I know of the whole optional type thing, there's a quite a lot of history to this research

and I don't believe that, again, in sort of academic--in scientific research, you know, who said something first matters, right? I don't--I agree with the Python folks on a lot of things. I disagree with some things but there's a lot of them, probably more--I agree more with the Python folks and probably, than, say, the Ruby folks or whatever because the Python folks are much more software engineering-oriented than some of these other communities. The question in related work is whether they ori

ginated an idea that is--or have made an important variation with novelty to it on these ideas. And, no, they haven't. They've engineered a solution and it's very popular and very successful largely because some of these properties exist and others don't. But they're not--they're not an inspiration for any us. >> Yup, which is strange to, like, contrast this language with Java. Their utterly different and those contrasted with Python that has some similarities and then you just explained why [IN

DISTINCT] disregard than this is. You don't disregard Java excesses, although that [INDISTINCT]. >> BRACHA: Okay. So I have to see more of a relation because in Java there is the notion of--nested classes in Python really don't do anything. They don't really nest in a semantically interesting way. They don't scope properly unless you--you can change it because you can change everything in Python but, by default, don't actually do anything that--because there's no reason for them to be there in a

sense. Nested classes in Java attempted to do something. They do have a semantics. They're kind of screwed up but, you know, I see more of a connection. Now, maybe you see it differently. I do not see a connection really between Python or Ruby, or Pearl, or any of these things. [INDISTINCT], they're dynamically typed and not in the history of the ideas. Do you have something to say or...? Yeah. >> Yeah, that's it. To the practice of developing libraries now, I see that you--I seem to have more

options how to structure my program. I can depend on another module or request that someone pass me another module, or pass me classes directly and did you--could you find that confusing or did you come up with a good way to...? >> BRACHA: Okay. So, actually--let me restate that because at least I think what you said was inaccurate, right? The choice you tend to have is whether you get passed a--how many of you said it right? Maybe I [INDISTINCT]. You have a choice between getting passed a modul

e definition sometimes or [INDISTINCT] in deciding to instantiate it once you get the module, you know, you can choose that. That sort of a design choice to some extent just like anything else in a software program because we'd reduced it from a fixed menu of very limited things that is hardwired into the language to using the general facilities of objects of instantiation and broad capacities. And then you have a greater variety of, you know, that these tools can be used in a wide way. We--you

know, we've had some experience with this, right, so we've come up with these idioms of how we do things. But that choice may vary depending on what it is. It's also--it's always the big choice of what are your module boundaries? Where do I--one set of choice is involved, do I really structure it as a big giant monolithic class or do I have a number of small classes and then, have some intermediary class where I pull them together and stuff? And some of that was historical because, you know, som

e things were done earlier and then something was done later by a different developer and things like that. So, you know, you have choices of how to do this. If it's a very large module, you probably don't want to end up with a single thing that's, you know, 28,000 or 50,000 lines long. If it's 5,000, that's sort of okay. You know, so partly, it's a matter of size and we probably need more experience on these kind of questions. But we haven't been able to, you know--the entire ID is an applicati

on structure like that like I showed to all, the GUI, the whole GUI framework which is portable retaining graphics than a higher application level area. Each of this is, you know, fairly sizable modules and they do a fair amount. So, obviously, our experience is limited but it's not trivial. >> I just have a question regarding the S Package stuff. So that, it gets the IDE environment. Now that comes from the virtual machine. So, say, if you wanted to... >> BRACHA: No, it doesn't come from the vi

rtual machine. It comes from the IDE. It is an application. >> Okay. >> BRACHA: It just has a map and you ask me to load a class and then it can read it, and then call a compiler and so forth, right? Whatever it does, it's just an application. >> So, in a hypothetical world, if you are working with, sort of, where you wanted to do--you're editing an Emax and then, run the program in the end. How would that benefit...? >> BRACHA: Okay. So, how would I do--so I could edit. There's a syntax and you

can edit it in Emax or in vi if you want cold dead fingers or whatever. And then the question there would be what tooling would you choose to use, all right? So you could imagine like I suggested earlier. If you really want it, you could imagine having, you know, NS make or something and you've put all--every module in a file and do you write--you know, you write a method in which just an expression in glue code and it calls a compiler, and it compiles, and feeds it to self. They read from a fi

le [INDISTINCT] and write it. It's--there's an interesting mechanics there but there's nothing really different. It reduces--the key observation is you're always going to end up using some tool for the configurations. That's how it's done in every instance. And the only thing is if you're serious about using that tool, then you realize you don't need the language to glue itself with a global names space as a crutch to it to do that. >> But, wherever the--if we want all the id name space [INDISTI

NCT]. So that's kind of--effectively, I find it a global [INDISTINCT]. Implicitly, it's a--you know, it's not really global because it [INDISTINCT] but an ultimately. >> BRACHA: So you could imagine--so this make duo would read files and match, you know, names of files to maintenance classes. Read them in, produce a dictionary, stick them in, or an object really that answers these messages because it's dynamic. It's very easy to do these sorts of things to have it forward to a dictionary look up

, right? And it would then pass that objective, you know, to this method, right? >> So it would defend the constructed to what the name specs? >> BRACHA: Yeah, yeah. >> All right. >> BRACHA: Well, okay. >> Look I'm going make sure I understand how the IDE have to update its class definition so that if you have some method in the platform objects with an [INDISTINCT]. >> BRACHA: It all works through reflection, all right? This is real reflection. It's not just in for inspection. That's why it's a

dynamic language that--it's a misnomer, right? With dynamic and dynamic languages is the fact that the programs can dynamically modify their definition. That's what makes a dynamic language dynamic. Not by coincidence they're all dynamically typed because it's just incredibly painful to figure out the type system to do that. But then--basically, yeah. Then it goes through an API and says, "Okay. Add a method, remove a method, create a [INDISTINCT]." And you have... >> I just wanted to know, all

things can go wrong. If you are experiencing [INDISTINCT] or do you debug things or do you develop [INDISTINCT]? >> BRACHA: I will ignore the temptation to say that they don't go wrong, of course they go wrong. They go wrong in much the same way as they do saying and something like small talk except less because there's more structure here because we do have modularity, things like that. But, basically, you can get a message not understood. The actual--the thing that for type people is hard to

understand is that that is not the end of the world. Again, using an interactive IDE, most of these actually crop up with some very basic testing and you fix them as you go along and it doesn't take you any more time than it does to battle the hassle type of check. So that's--the most common one of course is simply when you have nails, right? The equivalent of--that's the most common actual problem that might--that might stay in the system after this very initial debugging. And the right answer

to that is to have a version where you initialize everything and you never have nails like the functional, right? But that's basic. There is a full symbolic debugger you can modify. I mean, I can demo all this but we're kind of running late. I can show it to you later, right? If there's a debugger that shows you the stack and let's you modify programs on the fly and do fix, and continue debugging, and all that kind of stuff, all right? All--it's all in the id. >> Does nil have to inhabit every t

ype? So, if the suits keep having every outdoors and very request... >> BRACHA: Yes, yes, yes. Now, of course, there's a reason the type system but there is--in the sense, since we don't have a formal type system, we don't have to confront this logical inconsistency. But nil is basically an instance of a class called undefined object. And we--and it is by--everything and that was--you can stick anything in anywhere, right? Variables [INDISTINCT] types, right? But if you add a type system to it,

it will have that property. Have I exhausted you finally? Good. Thank you for coming. >> Thank you.