Objective-Smalltalk
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Weiher, Marcel
Objective-Smalltalk is a re-imagining of Objective-C for the 21st century. Like Objective-C, it blends features from Smalltalk and C, but instead of adding some Smalltalk features to C, it adds ideas from Objective-C to Smalltalk. It is intended as a full-stack language capable of complementing or replacing Objective-C for iOS and Mac OS X programming as well as replacing most scripting language use in those environments. It is not Smalltalk-80 compatible
 For Marcel Weier, Objectus Motoc, old squeaker from a long time ago. A long, long time ago. I've seen source codes with his stimulus. Yes. You have. Okay, so I'm talking about Objectus Motoc, one of the two non-classic small talk implementations we're going to talk about today. That's my own company, MetaObject. It's been around for a while. I just recently started with Vex Winderkinder in Berlin, a startup. And I'm also attached to the Hasu Platna Institute in Potsdam doing my PhD, which is related to this stuff. So a lot of my play. And I really like small talk. But I also really like C, because it really lets me get stuff done at the low level. So I really love Objectus C. So much that actually way back when, anybody remember the Amiga? So I got my first Amiga. And the first thing I did is I implemented an Objectus C preprocessor for it. And that was a little over a quarter century ago. Scary. And then next came out and they did the job for me. And it's now lost to history. The squeak stuff, yeah, I did some VM work a long time ago. The first Coco VM, which is also lost because it wasn't very good. And the stuff that's currently still in the image, I think, is the PostScript generation. So that's sort of where I come from. And being an Objectus C programmer, it's a great language. But it does have limitations, because originally it was really meant as a stopgap measure for those situations where you couldn't use small talk. And that's really kind of changed a lot. So it would be really nice if you could simplify it back down again. On the other hand, the small talk never really caught on with me. I was in the community for quite some time, but I could never really use it for my day-to-day work, which is kind of sad. So it'd be nice if it'd be more practical, if I could actually use it for my work. And finally, I've always really been on the lookout for something to make this whole programming thing a little better, because quite frankly, programming sucks, in my opinion. I mean, we really deal with all these low-level things, and we're not really getting anywhere. And I mean, I don't think this is not going to be a huge leap, but maybe we can make it a little bit better. And so the first thing is, let's simplify Objectus C, and this is why. Objectus C has really grown over time. It used to be just a system for wrapping C, function of C programs, in little small talk like wrappers, but we've kind of stopped doing that. We're actually using the Object system. And as that, it's not really very good. I mean, if you want to have an Object number, that's N as number number with int four. Well, that's not really good. We need to score brackets. Now, recently, there's been some additions. And say, at three, and at four, but again, if we're going to do that a lot, that's just going to be really bad. Whereas, if you use just plain integers, that looks right. That's actually okay, because promise we have two syntaxes, two languages jammed together. And that's just not a really good idea in the long run. And here, this is one of my favorite examples, they added blocks recently, and that's what a block looks like that logs these two to the console. What happened here? So maybe, you know, if you could look like this, right, like small talk. And that's pretty much the same examples, except they kind of look okay now. And we still want to have both these systems, the Object system and the primitive system, because again, I like C, and we need to talk to the C world. But we can do it much simpler, because we can just do a little type annotation and say, that's an integer, and that's a C integer. And the rest, it's just objects. And so that's kind of the motivation there. And in terms of just being a more practical small talk, I mean, small talk the image, it's a great concept. But again, the world has changed since 1980, right, or even the 70s when it was created. When Xerox Park had their altos, there was really no outside world to talk to. So, you know, having an image and having your own world with you, that's fine. Are there other reasons you could have this tradition other than there's nothing to talk to you? Oh, it is a great system, right? And isn't the argument, it's not the 70s anymore a little weak, because eventually it will be three years from now, people will say it's not 24K anymore? Oh, absolutely. And it'll change, right? I mean, I think, again, it's a pragmatic thing, right? You know, if you have a world where you're comfortable in the image, that's great. But many people don't, right? Why do we have Ruby? I mean, and Python, right? I mean, small talk should be better than the systems. But I think one of the big problems that people had is, you know, they couldn't integrate with their command line tool. They can't do an SSH and run your small talk. So, you don't have to choose one of the other? It'd be nice if you didn't. It would be really nice. I mean, certainly, and it seems to me you can build a nice image, you know, on top of that. It seems to, I mean, just given history, it seems to be difficult to get a good scripting Unix shell integration on top of the image. We've been trying for a long time and we have systems, but even the fact that we have so many of them seems to indicate that maybe we don't really have a good answer. So, we want to run on the native ABI. We have a nice little object system that's very small talk oriented with Object2C. It's very small. So, we have no VM, we have no image, and we don't even have a GC, which is, of course, crazy talk. There's a Ripple. You get to do Unix scripting. Right now, the static compilation is a future thing. I'm working on it. It's not there yet. Same with Object2C. It should be equivalent. And the other part of being within these other systems is that there is just so much more other code around. There's vendors, you know, Apple does Quartz. They do all these kits. Having to recreate all that just doesn't scale. David Chisnell did a nice, he was here last year, I think, right? And he had a nice little paper where he did some numbers and they said, even if small talkers are 100 times more productive, they still couldn't match the output of just what is there in SeaWorld. So, what do we have? Let's do a little demo. And I'll pick up my cursor. Okay, so we have a small talk scripting shell. And so, you know, we can do 3 plus 4. So, yeah, it's a small talk. We can do, we can just write stuff down, right? So, hello. We can send messages to Standard Out. We can do standard string concatenation and that all sorts of works. We can do slightly more fancy stuff. So, if we, let's say, we have an interval that works, except we don't see it as, oops, and I need to remember my syntax, right? And so, all that sort of stuff works. And of course, the example we had, the Object to Sea block example, let's do that a little better. So, we had a couple of strings, maybe A and B. And we do do... So, your basic small talk works in the command line. So, I mean, new small talk is a little like that. But I think this is a really useful capability to have, especially since you can start doing real scripts. Now, for example, just to get sort of some of the syntax out of the way. What from2 does is really simply just counts. I think that's pretty trivial. And if we look at the script itself, you can see there's a normal hash bang. There's another hash bang here, doesn't it? It does an integration between what is a script and what is a method. So, it's really saying this script is a method from2 with two parameters from2, and then it just prints them. And having this type of meta information then allows me to, for example, do some error checking, completely automatically. Because I declared what I need and it's saying, well, you didn't give me what I need. And so, what you have is starting to get a softer architectural idea of adapters. Where you have this scripting world and the object's messages world, and you're starting to try and bridge the gap a little bit. The other thing you can, of course, do is... Let's see where do I have it. You can start bringing in code from your object world. The app kit is the basic GUI framework in part of Cocoa. And so, what this will do is it will load a file and it'll try to initialize an image and it'll just log that. It'll tell you what the image is. So, if I have image info... There is a JPEG somewhere here. There it is. New York City. And, well, it's telling me, yeah, I have a fitmap image rep. It's got a size 649,136 and some information about the metadata. Again, you're bridging those gaps and bringing things closer together to make it easy and just become more productive. Usually, what happens is when you have these two worlds, you need to... The bridging code tends to be so much more than the actual functionality because you're... Especially if you're doing small things that you don't do it. And then you need to write a seek, either a full program or you need to get these other packages involved. It just becomes more cumbersome. Okay, back to slides. We're just trying to be objective, see and small talk together. And now we're going to talk about a little bit, trying to go beyond small talk. And, again, the idea is something that Makas talks about a little bit. Trying to specialize the language. Because we tend to, at higher levels, when we're doing application programming, it's often the case that we're doing something very similar but just sufficiently different that we have to reinvent it from scratch. For example, a typical example that he also gave, if we have instance... Something that is conceptually really an instance variable. But we need more of them and they need to be dictionaries. Or we need some special functionality when they get called. We don't use the language anymore directly. We have to build the scaffolding on top. Similar with messaging. If we want to have the built-in messaging, we're fine. If we want asynchronous messaging or messaging applied to collections or some other form or remote messaging, we kind of have to build it ourselves, possibly go through the DNU handler. In the end, if 90% of your program is going through the DNU handler, maybe the language needs a little bit of fixing. Again, the idea is... What's the next thing? Well, actually, we just need to apply small talk to itself. We need to be able to subclass and compose the pieces that make up the basic system. Then we can build whatever language we need. Which, for example, with the scripting we just showed. The components there are polymorphic identifiers and first-class references, which generalize the idea of an identifier and an instance variable. I'll talk about that. Messaging. So we can play around with that. And finally, and that's the part that's least well-developed, that's Dataflow, which is also one of the strangest asymmetries in small talk is the assignment operator. It's kind of the one thing you can't override. There's deep reasons for that, but it would be nice if we could, for example, have custom assignment. Have constraints where it's not a one-time assignment, but we just say this should remain or have pipes saying, well, it's not that we just want to shove this one thing over here, but we actually just want to connect these two things and keep them connected. And the inspiration for solving this is really a software architectural approach. And actually, the original book by Brad Cox on Objective C talked very much about software architecture and packaging. And another fantastic one is this one, which the concept techniques and models of computer programming, although they sort of base everything on the functional model, they managed to get the relationships between different programming models in there and classify how far can you go with a particular model and when should you maybe move on to something else. Am I doing on time? Okay. And so I went and thought about things for a while and came up with this. What's that? This is a classification of small talk in terms of software architecture. You have basically, the basic fundamental construct is the connector, which is just, you know, well, when you have architecture, you need to put things together somehow. And the classification I have done here is just there is data flow. So, you know, assignment types and filters, the part of those types and filters return value, that's a data flow connector. You have access where you have instance variables, local variables, somewhere else, you know, in Unix we have environment variables. Small talk doesn't have environment variables, but they could. And then we have messaging, which I use as a sort of generalization of what a procedure call could be. Right? And a procedure call is the type of app, but we don't have that in small talk. We have small talk messages. But we could have early on messages instead, right? Which are asynchronous. We can have notifications which don't really have a receiver. And all these are types of messages, but again, we are, in small talk we have these things. That characterizes a specific language. And when we have a different language, we have the same overall picture. It's just the two different parts. This is shell script. Right? So, we still have assignment. Now we have pipes. We have local variables with a funny dollar sign usually. We have environment variables. We have files which, in small talk you can't directly connect to a file. In a shell you just write down the file. Right? And we have procedure calls, but we don't have messages. Why is this, right? It seems completely random to me, having looked at it for a while. And of course, your particular problems will therefore call for different languages. But for no really good reason. It's just somebody decided, well, we're going to split it up this way. And what if you could just decide to mix it yourself? So, one of the cornerstones of that, and it actually took me a while to figure that one out, is you have to be able to name things properly. And before you can start messing with the other parts, you need to actually make naming flexible. And that's what polymorphic identifiers are all about. And there was just a DLS paper in October. Dynamic language symposium. It's sort of part of UPSLA. And the basic idea is really just take the concept of a URI from the web and put in your program. A, you can actually also write URIs. So HTTP, something, something, something, and have that simply in identifying the program. Has NARDIF already done that? RTF. Research. It's got URIs for different types. There's no reason why you couldn't use those types that exist in NARDIF. You mean research, the subscription framework? No, it's a semantic web. Well, yes, absolutely. I mean, I could have used something else and come up with my own, but we have URIs. And they're called universal resource identifiers. Universal, come on. So I just decided to take them. Syntactically, that makes some things a little bit more difficult. But I think the pragmatics are great in this case. So yes, this is really just importing that concept into the program language, the existing concept. You can then make them user-excensible. Every scheme has a handler, and you can define your own handlers. This solves a lot of issues. For example, the property pattern where you have dictionaries. Accessing the dictionary, you use string keys. If you look for example, some of the Apple code, X code is 90% dictionaries, which seems odd. You would think that one might want to model actual objects with functionality, but no, it's dictionaries. And there's reasons for that. Again, the reasons aren't very good in the end. You can also do something which I call in-process rest. That essentially you build these file system-like entities, but you do that inside your process. And we had very good experience re-engineering our BBC system using that type of technique. Because it allows you to do the hierarchical management of data flexibly without having to have an external file system, for example. So, quick demo, out of time almost. Let's just see. Do I have a network? I do not have a network. Cross-demon dual stack. Yikes. I'll try to do some of the other stuff first. There are two other networks. Yeah, but the other ones don't seem to work with my machine for some reason. Yeah, I don't know why IPv6 is. Yeah, they're IPv6, maybe that's... Yeah, and it should work. Other Macs seem to connect just as mine doesn't like it. I noticed some of my Mac apps don't like IPv6. Okay, so, go back here. My standard example. It goes and says meow. Anybody ever looked at the source code? They have the meow at the end. I can now put that in a variable. I say, so, how long is that? Well, it's, you know, 155K. Let's put that in a file. And that just works. And I can also, of course, when I could have done that directly, right? Variables actually also have a scheme. So, let's use a different one. B doesn't exist, so let's assign it. But that's actually the same as if I say bar B. I can access environment variables. So, that's my home. Okay. I can nest them. So, if I have home, I have a listing of my home directory. And again, it's integrated, so I can just... That's, you know, there's a inconsistency there. So, I have 89 files in my home directory. Or I can just retrieve something from there. Long bash resource. Okay. I think I'm, sadly, I'm done. And of course, I wasn't... Let's see. But actually, that was my last site. I have more demo stuff if people are interested. But ST, that's where the site, there's a reference to GitHub repositories. Basic idea. We want scripting compilation. Why do these need to be distinct? Objects and unix also should look much more nicely together. And software architecture is the answer. Polymorphic identifies home or some of the techniques used to implement that. And the static compiler is in progress. But I currently don't have time. So, thank you. Well, I don't have time for questions. Short question. How hard could the app run on Linux? Because basically, object to see isn't that much limit to Apple's app. Oh, absolutely. Yeah. I've had this running on Linux. I did, I made some changes. So, I think currently it's not. But that's, it generally shouldn't. I mean, it shouldn't be limited. Yeah. So, basically you have some ifs and ifs where you just replace the one-time lookup function. Or do you depend on, for example, the little object to see is to be by David Chesner who implemented the same lookup API as Apple? Yeah. I had both versions and it just, it keeps changing around a little bit. But it's not really a big deal. The one, the thing that's currently made a bit of a problem is that I'm starting to use the same lookup stuff. And I just haven't looked at how that works. It's in the new step as far as I know. And in the new step, there's one time. That's the same API. Right. And it should work. It's just I haven't gotten run to it. So, if you want to look at that. I actually have my own one-time set rather than put it to death. Okay. Well, over that. Yeah. Short question. There is no garbage collection yet? There is no, Objective C has reference counting. Okay. And various techniques for dealing with circular dependencies that are not a full garbage collector. Used to have it. It sucked and didn't work. And so they wrapped it out again. Can we use the iPhone? Yes. This is, this is iPhone compatible. I don't think I currently have any apps in the store that use it. But it's. They also accept the apps that you spent. Yeah. So, I haven't tried this particular thing, but it should. It's designed to be compatible. And it doesn't use a chip. Thank you very much. Thank you.
 For Marcel Weier, Objectus Motoc, old squeaker from a long time ago.  A long, long time ago.  I've seen source codes with his stimulus.  Yes.  You have.  Okay, so I'm talking about Objectus Motoc, one of the two non-classic  small talk implementations we're going to talk about today.  That's my own company, MetaObject.  It's been around for a while.  I just recently started with Vex Winderkinder in Berlin, a startup.  And I'm also attached to the Hasu Platna Institute in Potsdam doing my PhD,  which is related to this stuff.  So a lot of my play.  And I really like small talk.  But I also really like C, because it really lets me get stuff done at the low level.  So I really love Objectus C.  So much that actually way back when, anybody remember the Amiga?  So I got my first Amiga.  And the first thing I did is I implemented an Objectus C preprocessor for it.  And that was a little over a quarter century ago.  Scary.  And then next came out and they did the job for me.  And it's now lost to history.  The squeak stuff, yeah, I did some VM work a long time ago.  The first Coco VM, which is also lost because it wasn't very good.  And the stuff that's currently still in the image, I think, is the PostScript generation.  So that's sort of where I come from.  And being an Objectus C programmer, it's a great language.  But it does have limitations, because originally it was really meant as a stopgap measure  for those situations where you couldn't use small talk.  And that's really kind of changed a lot.  So it would be really nice if you could simplify it back down again.  On the other hand, the small talk never really caught on with me.  I was in the community for quite some time, but I could never really use it for my day-to-day work,  which is kind of sad.  So it'd be nice if it'd be more practical, if I could actually use it for my work.  And finally, I've always really been on the lookout for something to make this whole programming thing a little better,  because quite frankly, programming sucks, in my opinion.  I mean, we really deal with all these low-level things, and we're not really getting anywhere.  And I mean, I don't think this is not going to be a huge leap, but maybe we can make it a little bit better.  And so the first thing is, let's simplify Objectus C, and this is why.  Objectus C has really grown over time.  It used to be just a system for wrapping C, function of C programs, in little small talk like wrappers,  but we've kind of stopped doing that.  We're actually using the Object system.  And as that, it's not really very good.  I mean, if you want to have an Object number, that's N as number number with int four.  Well, that's not really good.  We need to score brackets.  Now, recently, there's been some additions.  And say, at three, and at four, but again, if we're going to do that a lot, that's just going to be really bad.  Whereas, if you use just plain integers, that looks right.  That's actually okay, because promise we have two syntaxes, two languages jammed together.  And that's just not a really good idea in the long run.  And here, this is one of my favorite examples, they added blocks recently,  and that's what a block looks like that logs these two to the console.  What happened here?  So maybe, you know, if you could look like this, right, like small talk.  And that's pretty much the same examples, except they kind of look okay now.  And we still want to have both these systems, the Object system and the primitive system,  because again, I like C, and we need to talk to the C world.  But we can do it much simpler, because we can just do a little type annotation and say, that's an integer, and that's a C integer.  And the rest, it's just objects.  And so that's kind of the motivation there.  And in terms of just being a more practical small talk, I mean, small talk the image, it's a great concept.  But again, the world has changed since 1980, right, or even the 70s when it was created.  When Xerox Park had their altos, there was really no outside world to talk to.  So, you know, having an image and having your own world with you, that's fine.  Are there other reasons you could have this tradition other than there's nothing to talk to you?  Oh, it is a great system, right?  And isn't the argument, it's not the 70s anymore a little weak, because eventually it will be three years from now,  people will say it's not 24K anymore?  Oh, absolutely. And it'll change, right?  I mean, I think, again, it's a pragmatic thing, right?  You know, if you have a world where you're comfortable in the image, that's great.  But many people don't, right?  Why do we have Ruby?  I mean, and Python, right?  I mean, small talk should be better than the systems.  But I think one of the big problems that people had is, you know, they couldn't integrate with their command line tool.  They can't do an SSH and run your small talk.  So, you don't have to choose one of the other?  It'd be nice if you didn't.  It would be really nice. I mean, certainly, and it seems to me you can build a nice image, you know, on top of that.  It seems to, I mean, just given history, it seems to be difficult to get a good scripting Unix shell integration on top of the image.  We've been trying for a long time and we have systems, but even the fact that we have so many of them seems to indicate that maybe we don't really have a good answer.  So, we want to run on the native ABI.  We have a nice little object system that's very small talk oriented with Object2C.  It's very small.  So, we have no VM, we have no image, and we don't even have a GC, which is, of course, crazy talk.  There's a Ripple. You get to do Unix scripting.  Right now, the static compilation is a future thing. I'm working on it. It's not there yet.  Same with Object2C. It should be equivalent.  And the other part of being within these other systems is that there is just so much more other code around.  There's vendors, you know, Apple does Quartz. They do all these kits.  Having to recreate all that just doesn't scale.  David Chisnell did a nice, he was here last year, I think, right?  And he had a nice little paper where he did some numbers and they said,  even if small talkers are 100 times more productive, they still couldn't match the output of just what is there in SeaWorld.  So, what do we have? Let's do a little demo.  And I'll pick up my cursor. Okay, so we have a small talk scripting shell.  And so, you know, we can do 3 plus 4. So, yeah, it's a small talk.  We can do, we can just write stuff down, right?  So, hello. We can send messages to Standard Out.  We can do standard string concatenation and that all sorts of works.  We can do slightly more fancy stuff.  So, if we, let's say, we have an interval that works, except we don't see it as, oops, and I need to remember my syntax, right?  And so, all that sort of stuff works.  And of course, the example we had, the Object to Sea block example, let's do that a little better.  So, we had a couple of strings, maybe A and B.  And we do do...  So, your basic small talk works in the command line.  So, I mean, new small talk is a little like that.  But I think this is a really useful capability to have, especially since you can start doing real scripts.  Now, for example, just to get sort of some of the syntax out of the way.  What from2 does is really simply just counts.  I think that's pretty trivial.  And if we look at the script itself,  you can see there's a normal hash bang.  There's another hash bang here, doesn't it?  It does an integration between what is a script and what is a method.  So, it's really saying this script is a method from2 with two parameters from2, and then it just prints them.  And having this type of meta information then allows me to, for example, do some error checking, completely automatically.  Because I declared what I need and it's saying, well, you didn't give me what I need.  And so, what you have is starting to get a softer architectural idea of adapters.  Where you have this scripting world and the object's messages world, and you're starting to try and bridge the gap a little bit.  The other thing you can, of course, do is...  Let's see where do I have it.  You can start bringing in code from your object world.  The app kit is the basic GUI framework in part of Cocoa.  And so, what this will do is it will load a file and it'll try to initialize an image and it'll just log that.  It'll tell you what the image is. So, if I have image info...  There is a JPEG somewhere here. There it is. New York City.  And, well, it's telling me, yeah, I have a fitmap image rep. It's got a size 649,136 and some information about the metadata.  Again, you're bridging those gaps and bringing things closer together to make it easy and just become more productive.  Usually, what happens is when you have these two worlds, you need to...  The bridging code tends to be so much more than the actual functionality because you're...  Especially if you're doing small things that you don't do it.  And then you need to write a seek, either a full program or you need to get these other packages involved.  It just becomes more cumbersome.  Okay, back to slides.  We're just trying to be objective, see and small talk together.  And now we're going to talk about a little bit, trying to go beyond small talk.  And, again, the idea is something that Makas talks about a little bit.  Trying to specialize the language.  Because we tend to, at higher levels, when we're doing application programming,  it's often the case that we're doing something very similar but just sufficiently different  that we have to reinvent it from scratch.  For example, a typical example that he also gave, if we have instance...  Something that is conceptually really an instance variable.  But we need more of them and they need to be dictionaries.  Or we need some special functionality when they get called.  We don't use the language anymore directly. We have to build the scaffolding on top.  Similar with messaging. If we want to have the built-in messaging, we're fine.  If we want asynchronous messaging or messaging applied to collections or some other form or remote messaging,  we kind of have to build it ourselves, possibly go through the DNU handler.  In the end, if 90% of your program is going through the DNU handler,  maybe the language needs a little bit of fixing.  Again, the idea is...  What's the next thing? Well, actually, we just need to apply small talk to itself.  We need to be able to subclass and compose the pieces that make up the basic system.  Then we can build whatever language we need.  Which, for example, with the scripting we just showed.  The components there are polymorphic identifiers and first-class references,  which generalize the idea of an identifier and an instance variable.  I'll talk about that.  Messaging.  So we can play around with that.  And finally, and that's the part that's least well-developed, that's Dataflow,  which is also one of the strangest asymmetries in small talk is the assignment operator.  It's kind of the one thing you can't override.  There's deep reasons for that, but it would be nice if we could,  for example, have custom assignment.  Have constraints where it's not a one-time assignment,  but we just say this should remain or have pipes saying,  well, it's not that we just want to shove this one thing over here,  but we actually just want to connect these two things and keep them connected.  And the inspiration for solving this is really a software architectural approach.  And actually, the original book by Brad Cox on Objective C talked very much about  software architecture and packaging.  And another fantastic one is this one, which the concept techniques and models of computer programming,  although they sort of base everything on the functional model, they managed to get the relationships  between different programming models in there and classify how far can you go with a particular model  and when should you maybe move on to something else.  Am I doing on time?  Okay.  And so I went and thought about things for a while and came up with this.  What's that?  This is a classification of small talk in terms of software architecture.  You have basically, the basic fundamental construct is the connector,  which is just, you know, well, when you have architecture, you need to put things together somehow.  And the classification I have done here is just there is data flow.  So, you know, assignment types and filters, the part of those types and filters return value,  that's a data flow connector.  You have access where you have instance variables, local variables, somewhere else,  you know, in Unix we have environment variables.  Small talk doesn't have environment variables, but they could.  And then we have messaging, which I use as a sort of generalization of what a procedure call could be.  Right? And a procedure call is the type of app, but we don't have that in small talk.  We have small talk messages.  But we could have early on messages instead, right?  Which are asynchronous.  We can have notifications which don't really have a receiver.  And all these are types of messages, but again, we are, in small talk we have these things.  That characterizes a specific language.  And when we have a different language, we have the same overall picture.  It's just the two different parts.  This is shell script.  Right? So, we still have assignment.  Now we have pipes.  We have local variables with a funny dollar sign usually.  We have environment variables.  We have files which, in small talk you can't directly connect to a file.  In a shell you just write down the file.  Right? And we have procedure calls, but we don't have messages.  Why is this, right?  It seems completely random to me, having looked at it for a while.  And of course, your particular problems will therefore call for different languages.  But for no really good reason.  It's just somebody decided, well, we're going to split it up this way.  And what if you could just decide to mix it yourself?  So, one of the cornerstones of that, and it actually took me a while to figure that one out,  is you have to be able to name things properly.  And before you can start messing with the other parts, you need to actually make naming flexible.  And that's what polymorphic identifiers are all about.  And there was just a DLS paper in October.  Dynamic language symposium.  It's sort of part of UPSLA.  And the basic idea is really just take the concept of a URI from the web and put in your program.  A, you can actually also write URIs.  So HTTP, something, something, something, and have that simply in identifying the program.  Has NARDIF already done that?  RTF.  Research.  It's got URIs for different types.  There's no reason why you couldn't use those types that exist in NARDIF.  You mean research, the subscription framework?  No, it's a semantic web.  Well, yes, absolutely.  I mean, I could have used something else and come up with my own, but we have URIs.  And they're called universal resource identifiers.  Universal, come on.  So I just decided to take them.  Syntactically, that makes some things a little bit more difficult.  But I think the pragmatics are great in this case.  So yes, this is really just importing that concept into the program language, the existing concept.  You can then make them user-excensible.  Every scheme has a handler, and you can define your own handlers.  This solves a lot of issues.  For example, the property pattern where you have dictionaries.  Accessing the dictionary, you use string keys.  If you look for example, some of the Apple code, X code is 90% dictionaries, which seems odd.  You would think that one might want to model actual objects with functionality, but no, it's dictionaries.  And there's reasons for that.  Again, the reasons aren't very good in the end.  You can also do something which I call in-process rest.  That essentially you build these file system-like entities, but you do that inside your process.  And we had very good experience re-engineering our BBC system using that type of technique.  Because it allows you to do the hierarchical management of data flexibly without having to have an external file system, for example.  So, quick demo, out of time almost.  Let's just see.  Do I have a network? I do not have a network.  Cross-demon dual stack.  Yikes.  I'll try to do some of the other stuff first.  There are two other networks.  Yeah, but the other ones don't seem to work with my machine for some reason.  Yeah, I don't know why IPv6 is.  Yeah, they're IPv6, maybe that's...  Yeah, and it should work.  Other Macs seem to connect just as mine doesn't like it.  I noticed some of my Mac apps don't like IPv6.  Okay, so, go back here.  My standard example.  It goes and says meow.  Anybody ever looked at the source code?  They have the meow at the end.  I can now put that in a variable.  I say, so, how long is that?  Well, it's, you know, 155K.  Let's put that in a file.  And that just works.  And I can also, of course,  when I could have done that directly, right?  Variables actually also have a scheme.  So, let's use a different one.  B doesn't exist, so let's assign it.  But that's actually the same as if I say bar B.  I can access environment variables.  So, that's my home.  Okay.  I can nest them.  So, if I have home,  I have a listing of my home directory.  And again, it's integrated, so I can just...  That's, you know, there's a inconsistency there.  So, I have 89 files in my home directory.  Or I can just retrieve something from there.  Long bash resource.  Okay.  I think I'm, sadly, I'm done.  And of course, I wasn't...  Let's see.  But actually, that was my last site.  I have more demo stuff if people are interested.  But ST, that's where the site, there's a reference to GitHub repositories.  Basic idea.  We want scripting compilation.  Why do these need to be distinct?  Objects and unix also should look much more nicely together.  And software architecture is the answer.  Polymorphic identifies home or some of the techniques used to implement that.  And the static compiler is in progress.  But I currently don't have time.  So, thank you.  Well, I don't have time for questions.  Short question.  How hard could the app run on Linux?  Because basically, object to see isn't that much limit to Apple's app.  Oh, absolutely.  Yeah.  I've had this running on Linux.  I did, I made some changes.  So, I think currently it's not.  But that's, it generally shouldn't.  I mean, it shouldn't be limited.  Yeah.  So, basically you have some ifs and ifs where you just replace the one-time lookup function.  Or do you depend on, for example, the little object to see is to be by David Chesner who  implemented the same lookup API as Apple?  Yeah.  I had both versions and it just, it keeps changing around a little bit.  But it's not really a big deal.  The one, the thing that's currently made a bit of a problem is that I'm starting to use  the same lookup stuff.  And I just haven't looked at how that works.  It's in the new step as far as I know.  And in the new step, there's one time.  That's the same API.  Right.  And it should work.  It's just I haven't gotten run to it.  So, if you want to look at that.  I actually have my own one-time set rather than put it to death.  Okay.  Well, over that.  Yeah.  Short question.  There is no garbage collection yet?  There is no, Objective C has reference counting.  Okay.  And various techniques for dealing with circular dependencies that are not a full garbage  collector.  Used to have it.  It sucked and didn't work.  And so they wrapped it out again.  Can we use the iPhone?  Yes.  This is, this is iPhone compatible.  I don't think I currently have any apps in the store that use it.  But it's.  They also accept the apps that you spent.  Yeah.  So, I haven't tried this particular thing, but it should.  It's designed to be compatible.  And it doesn't use a chip.  Thank you very much.  Thank you.
_FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_0_443.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_444_6323.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_6324_7139.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_7140_12215.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_12216_12299.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_12300_14963.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_14964_15587.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_15588_15767.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_15768_18551.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_18552_22763.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_22764_24431.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_24432_25439.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_25440_25703.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_25704_31103.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_31104_32315.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_32316_32363.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_32364_33227.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_33228_33275.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_33276_33983.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_33984_34187.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_34188_35627.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_35628_35783.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_35784_35951.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_35952_36107.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_36108_36551.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_36552_36815.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_36816_36971.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_36972_37415.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_37416_37535.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_37536_38195.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_38196_39059.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_39060_39179.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_39180_39239.png _FOSDEM_2014__Objective-Smalltalk_Vo2kixCMrbA_39240_42419.png