 Okay, so I want to talk about what Ruby can learn from Smalltalk. So to start with, I learned Ruby about 10 years ago because I told a friend of mine I wish I could get paid to write Smalltalk. And he said, well, Ruby is dynamic and OO and you would probably like a lot of what you see. So you should probably take a look at Ruby. And I did. And I still wish I could get paid to write Smalltalk, but Ruby is close enough. I gave this talk, or the opposite of this talk, Smalltalk Solutions in Las Vegas last month about what Smalltalk can learn from Ruby. And we talked a lot about community building. So first of all, I should probably talk a little bit about what Smalltalk is because I'm not certain that everybody here will maybe have heard of it, but don't know a lot of what's involved. So Smalltalk, the language is called Smalltalk 80. And the 80 refers to the year that it was perfected. And so it hasn't changed much since then. And one of the cool things about Smalltalk is that it's very, very extensible. And so there are new, the new dialects like, or new features. Some Smalltalk dialects have traits. Some have namespaces, but they're still Smalltalk because it was perfect in 1980. And so we have like 30 years of perfection. And maybe in like 40 or 45 years, Ruby can have 30 years of perfection. It'll be really nice. So Smalltalk is purely OO. Really OO. Everything is an object. There are no exceptions. And everything is an object that you send messages to, which is to say that there are no exceptions. And we'll give a few very short examples in a few minutes. So it is beautifully simple. There are five keywords, true, false, nil, super, or self. Some people claim this context. So some people say six. So we'll call it five and a half. I think Ruby has 33. Something like that, way too many. I wrote yesterday on Twitter that I like languages that you can write all the keywords. You can describe the whole language in a tweet. But I think counting on one hand is pretty good as well. So it's absolutely a beautiful language. Your methods, in Ruby we work hard to make sure that we have very small methods. We work hard for code simplicity and things like that. And in Smalltalk methods, it's almost a natural thing. And the layout of the code browser sort of really helped that as well. Message sending is one of the core parts of Smalltalk. The only form that you have in Smalltalk, aside from assignment, is to send a message to an object. And in Ruby, that's what you do most of the time. But in Smalltalk, that's what you do all the time. And there are no exceptions. This makes some really neat side effects. Like the fact that there's no special forms. There are no if statements in Smalltalk. There's no while statement. There are no loops that are special ways to write anything. You are always sending a message to an object. And that's really awesome. So Smalltalk like Ruby is also dynamic and reflective. There are no types in Smalltalk. As an interesting aside, because I like telling the story, there's a Smalltalk dialect called Strongtalk, which added type checking for the Java people that were saying that Java was better than Smalltalk. And it was really fast. And the Java people said, aha, you need types to be faster. And then when you look at Strongtalk, they actually throw away all the type information at optimization time. So a lot of the great stuff that's in Strongtalk wound up in things like V8 and other language implementations. I think some of it's actually in Rubinius as well, which is really awesome. It's a reflective language like Ruby. So Smalltalk knows about itself. You can ask if you want to know what type something, what class an object is of, then you ask it in the same way that you can do this in Ruby. The one thing that Smalltalk has as a result of this dynamic reflexive feature set are great tools. And we don't have a lot of great tools. We have RubyMind, which is fantastic, and I love it. And I tell everybody that they should use it. But RubyMind is still a static language environment for a dynamic language. So we're still missing out on a lot of the really advanced, excellent stuff that you can get if we were more like a Smalltalk environment. And I have a lot of hope for Rubinius-based tools in the future because of this. So in Rubinius, you can run your program and ask it about itself. And everything would be written in Ruby. And that makes it, you get access to the information that's built into the language instead of having to parse and index and all the hard work that RubyMind does behind the scenes that makes it really nice to use are actually things that you don't need to do if you just create an entire environment based on the language. And that's what Smalltalk is. Smalltalk includes the language and the tools and the environment and all of the objects that you ever use. And that's one thing that we, one of the things that we don't do in Ruby is to make, we don't make a lot of excellent usage of these, the reflective properties of Ruby that make it really, really excellent. So I'll give you some quick examples to show you what Smalltalk is. So the first thing you want to be able to do is declare a variable. In Smalltalk, you declare all of your variables. You don't, obviously, don't set a type, but you let it know that you're there so that the compiler can catch your typos. And you declare it by putting it between pipes, which I'm assuming is where the Ruby block local variable declaration gets the syntax from. Once you have a variable, you'll want to sign something to it. And you do it with the colon equals operator. In Ruby, or in Smalltalk, comparison is with single equals sign, not the double equals. So you get the assignment is colon equals. And then once you have an object assigned, you can send it a message. And here we're sending it the plus message, which calls the method called plus on the foo object. And that is for string concatenation. Once you have a string, you can tell the transcript object to print it. And a transcript is an object that represents a window for printing things. So what you get here is a very, very high level overview of the syntax of Smalltalk, which is not important. The syntax is really simple. And the message passing stuff is demonstrated there. So congratulations. Now everybody knows Smalltalk. It really is that simple. There are a few things to remember about Smalltalk, to keep in mind that it's the simple. One of them is that there are no special forms, which I said earlier. And to demonstrate this quickly, to do, if you want to do something with a Boolean. So instead of an if statement, you have this is the Boolean class defines the method if true colon if false. And the colon tells you where the argument goes. It's kind of like Objective C. If you've done Objective C, that's where that comes from. So basically you have a method on a Boolean called if true if false that you can pass two blocks to. And that's why you don't need an if statement. So this is your statement. There's also an if true method. And an if false method. So that covers all the cases. And it's really easy to read. It's nice. And because you already, because you learned Smalltalk in the minute and a half proceeding, you already know what this does. And you can read it. I guess the only thing I didn't cover was the blocks. Blocks are just in square brackets. And they're blocks of code, which is really great. So Smalltalk inspired a lot of other things. Objective C for the syntax for Objective C came from Smalltalk. The idea of a virtual machine for Java came from Smalltalk as well. The dynamic reflex, reflective properties of Ruby came from Smalltalk. And so a lot of the things that we love about our programming languages today came from Smalltalk. And Smalltalk had them all back then, but it was so different from what people were doing back in, you know, 1980 and in the 80s that they said, well, people said, well, VMs are slow. And that they are. Or were back then. And it doesn't matter anymore. And they said, well, Smalltalk requires a lot of memory. And I think it requires like a megabyte for a small implementation. And back then it was a lot of memory. And so now we're coming around to a time when all of the features that Smalltalk had that people complained about, they said, well, it makes it slow or it makes it cumbersome or I can't use it. All of those things have sort of come out in our languages and in our usage today. And it's really nice to see all over the place. I believe it was Kent Beck that said, I always knew that Smalltalk would win someday. I just didn't know what would be called Ruby when it did. And basically Ruby has all of the Smalltalk features and, you know, six times as many keywords. But it's basically only missing the image. So as soon as we get Ruby people to learn about the image, perhaps by using Maglev or something else, then we can all just start programming in Smalltalk, which will be really great. So at Smalltalk Solutions, we talked about a lot about community building because one of the things that Ruby does really, really well is building communities. Everybody's here. I know a lot of the people here, some of the, some people may have not been to a conference before, but a lot of the people that go to Ruby conferences go to lots of them. And we have a very strong community. Most of my best friends, I met, you know, at Ruby conferences and in the Ruby community. And it's really great that we can, that we have a community, you know, a close knit community. And that's one of the things that we did really, really well. And that Smalltalk can learn from us. But technically, Smalltalk has us beaten. And so there are a lot of great things technically and culturally that we can learn from Smalltalk. And I think that that's really important for all of us. So there were a lot of barriers to the adoption of Smalltalk. One of them was the expense. Back in, like, I think the mid-80s or so, Smalltalk cost up to $4,000 per developer to, which was a common price, to develop in Smalltalk. So to develop a team was really expensive to build a team to develop in Smalltalk. The fact that it was VM-based was also a barrier back in those days, because VMs were thought to be slow. And the fact that it was dynamic was another thing that was considered to be a barrier. And as I mentioned before, most of those things that were considered barriers for Smalltalk are gone now, except the image. And the image is another one of those barriers that we can probably help with. In Ruby, we can overcome all of those things. So we can overcome those things by having a low barrier to entry, which Rails definitely has. A lot of people are picking up Rails as their first experience programming. Ruby has proven to be a fairly easy language to learn. And so we can learn from Smalltalk by lowering the barriers to entry. And that's one of the things that will help us a lot. History is a really important thing that we can learn from Smalltalk. Smalltalk has a lot of history. Even though the language was perfected in 1980, I think it started to develop about 1975, 1977. So there is a lot of history in Smalltalk. And we can learn a lot from what the Smalltalkers have learned before us about object-oriented design and about how to write unit tests and how to write great software and modular decoupled extensible software. And so because of that history, we have a lot of experience in the Smalltalk community. It's really interesting because at a Ruby conference, people talk about Twitter as a scalability problem or Facebook or a lot of these big websites or different large applications that have scalability problems. And when you talk to a Smalltalker, as I did in Las Vegas last month, when you talk about these things that we consider to be problems in the Ruby community, Smalltalkers kind of shrugged them off because they did it 20 years ago. And so the kind of numbers that large websites are putting up today that are causing problems and things like that, people were solving with Smalltalk apps a long time ago. So it would really benefit the community to have those of us that think we're actually experiencing problems in scalability or in software design, extensibility, modularity, to find your friends that do or used to work in Smalltalk and ask them, how did you solve this problem before I was programming? And those things are... I am being a bit cheeky, but it's true. You can speak to these Smalltalkers. I've been doing it for a long time. And a lot of the things that we consider to be hard problems have been solved a long time ago. And that's something that's really important. In Ruby, we should start asking ourselves, instead of Googling for the blog post that tells you how a Ruby has solved this problem before you did, perhaps you should extend your search a little bit and look around for how did people solve this problem before people started solving this problem in Ruby? And how did Smalltalkers solve this problem? In specific, because Smalltalkers have been doing it for a long time. I met some Smalltalkers last month that have been writing Smalltalk for the last 20 years and working in nothing else. So there are some applications out there that have been running and making millions or probably even billions of dollars every year that have been running for 20 years in Smalltalk. There's a huge amount of experience that we can gain from that. And that's really important for us to learn from the people that came before us. And that's something that I'm very personally interested in. I want to learn from the people that did it before me. I want to be solving new important problems, not just solving the same old problems in a new way. So obviously, because Smalltalk is one of the first object-oriented language, we can learn a lot of things about object orientation from Smalltalk. And in Smalltalk, specifically partly because of the tools, but also because of Smalltalk, everything is an object and there's not really a way to get around that. We learn a lot about extensibility, modularity, and just overall, as a result of those things, sustainability from Smalltalk systems. In Ruby, when I'm looking at code that looks kind of messy to me, my first inclination is often to take one class and separate it into many. And that's, for me, that's a simpler solution to have three classes that work well together to solve a problem. That's a great solution to a problem. But I find that with people I've worked with often in the Rails community, they want to pack a lot of things into one class because more classes means more complexity. And that's really not the case. And I think that part of the reason for this is that in Ruby, the tools are poor. So it's not as easy unless you're using something like RubyMind, which is excellent. It's not as easy to go from the code that you're looking at to the definition or things like that. So when it's easier to navigate between your objects in a nice system, if you have, I think there are some Vim plugins and there's definitely some stuff for Emacs now, but it's really easy to navigate between class definitions. Now you can actually simplify your software by creating more classes and less complex interactions. In small talk, that's just really obvious and built in because the great tools are there. And a lot of this also comes from simplicity. You can focus on hard problems because I think it was the Python people that, the Python versus Perl when I was a Python programmer a long time ago, the Perl sort of mantra was there's more than one way to do it. And the Python people were like, eh, there's usually one better way to do it. So let's just focus on making the best way easy. And small talkers tend to be in that camp. There's always going to be more than one way to solve a problem, but there's usually going to be one that's clearly better or a few that are clearly better. And so if you have a lot of simplicity, if you don't have a lot of syntactic sugar in different ways to write things, it doesn't feel constraining. It feels liberating that you can move on to the next problem. And so in Ruby, a lot of the syntax allows us to write things in really obscure ways, or it invites us to flirt with unnecessary DSLs. DSLs can be great, but unnecessary DSLs are unnecessary. And so in small talk, it's a little bit harder to do. In small talk, when you want to have a DSL, you actually extend the compiler and build a new language from scratch. And so the things that are, you know, should be difficult are a bit more difficult. And it's kind of nice. The simplicity allows you to focus on problems in a different way. The community is something that we can teach the small talk community about. And that's something that I've definitely talked about last month specifically. But the small talk community exists. And that's something that's important for us to know. Because there's, like I said, small talks been around for a long time and there are people that have been doing it for the entire period that's been out. So we should really be tapping into learning from those people that have come before us in writing software and solving those kinds of problems. And that's something that I'm, community is really the most important thing for me. I feel very, you know, very strongly about the importance of the Ruby community. And I would like to see the things that we do well in the Ruby community pass over the small talk community because we can share ideas as well. Important ideas the other way. And so there's a lot of the cross-pollination I think would benefit both sides. So we should focus on that as well. Documentation is another thing that the small talkers have a problem with. And we want to make sure that we're focusing on documentation. I know that the, especially with the web becoming almost ubiquitous, we are focusing on, I'll release a gem with, you know, on GitHub and then write a blog post about how to use it. And I very often find that there's not a tie between the blog post that tells how to use the software and the place where you download the software. And so that's something that we should focus on. And we absolutely should not be supporting ideas. And I'm just going to get ranty for about 30 seconds. Apologize in advance. But we should absolutely not be supporting an idea to turn off documentation and say, Jim, authors, please stop shipping your documentation. So I want to see people working on the documentation and shipping the documentation. I love everybody's blog posts. I love when you write about the software on your blog. And that's a great way to get the ideas that we absolutely need to be focusing on documenting how to use this stuff. And because it leads to some other problems like reinventing the wheel, if I can't figure out how to use your gem, I'm going to reinvent my own. And that's something that I'll talk about in a few slides. Virtual machines are also really important. And Ruby's starting to get a few. A lot of people are still using Ruby 1.8, which doesn't have a virtual machine in as slow as a result and has other issues. Of course we have YAR and Rubinius and J Ruby and all the other implementations that people are moving to in Java, sorry, are following the VM things. And like we're using the Java virtual machine and we have the .NET stuff as well. So this is something that we really need to focus on is getting out there and using the implementations that are running on virtual machines. Specifically, my preference is Rubinius because it's heavily inspired by Smalltalk. So Rubinius is a great place to start with that. So I would like everybody to come away from this trying to use an implementation that has these features as well. Not invented here is one of the other things that I would like to see us learn from the Smalltalk community. In the FIRO project, which is a Smalltalk implementation that's relatively new that I'm watching the development of very closely because it's very interesting, we needed continuous integration. And so in they set up a Hudson server, which is written in evil Java, and they set that up and that's how we do the continuous integration in FIRO. And it hadn't occurred to anybody to say, hey, we need continuous integration. So we should write our own continuous integration server. And unfortunately, I've seen that happen a lot of times in the Ruby community. There must be 12 really poorly done continuous integration products that just don't work. And I mean, there are Jenkins now, formerly Hudson, is really great. If you like the commercial stuff, I really like Team City as well. I'm not a salesperson for JetBrains, but I do like their stuff. Sorry. I just realized I'm doing that. So there are options out there. You don't have to go and write your own. You can focus. Again, this comes back to the pragmatic, simple solution of solve your actual problem instead of shaving the yaks so that you can procrastinate solving the actual problems. And so that means don't write your own continuous integration server. Use one of the ones that already exists. It also means that if you want to do something in Ruby, and there's a Python library for that thing, one of the things I can think of specifically is parsing RSS feeds. Feed parser for Python is really good. Mark Pilgrim did a lot of work to get all the bugs worked out and to make it really solid. But when it came time for people to start parsing feeds in Ruby, I think there are four or five really poorly done feed parsing libraries in Ruby when really you could just write some glue to call the Python stuff because somebody's already solved that problem really well. And that allows you to focus on solving your actual problems. And I would really like to see a lot more of that. Then not invented here is a huge pet peeve of mine. Things like, you know, just when a problem is solved, it's solved. And so we can focus on real problems. And that's what I would like to see a lot more of in the Ruby community is focus on real actual problems that we have instead of resolving them differently. I mean, people accuse small talk of being insular because it doesn't really interact well with the rest of the world. And that's true. It's difficult to write a program in small talk that, you know, talks to a Ruby program and so on and so forth, unless she is maglev, which is also awesome. And I'm not the sales person for them either, but it's also great. But small talk can be really difficult to speak to, but they go out of their way to speak to the stuff that they need to use so they can focus on using, on actually solving problems. This is something else I would like to see in the Ruby community that we can pick up from the small talkers is let's solve the problems that are real problems and, you know, sort of stand on the shoulders of the people who have solved those problems before. And another thing is magic is really overrated. There are a lot of dynamic abilities in Ruby to generate code or code that writes code or just, you know, edit code that already exists and things like that. And it's, it really causes a lot of maintenance headaches. And the interesting thing is that none of these features are new. Ruby is not the first language to have the ability to, at runtime, change your code. Small talk did it. And in small talk we don't, we don't, we don't write code that writes code for us. Sometimes we might automate the generation of some simple code in the way that you might use refactoring tools in, in, you know, a tool that I'm not a sales person for to generate some code for you. So you can, you can generate some of that code. And in small talk we might generate it one time but the code is still there. Because we don't have an image in Ruby there are some of the dynamic things that we, that are actually good uses like has many and belongs to an active record are actually great uses of some of this magical metaprogramming that we can do because the code needs to be regenerated every time you run the application. That's one of the things we don't do in small talk because you work in an image when you create an object it's there forever. So we don't have, actually we, some of the ORMs do but we don't often make uses of, of class variables that generate other code because once the code generated it's already there we don't need to regenerate every time we run the software. So those uses of magic are, are kind of interesting. If you need to have code there every time and you can generate it to make it a little bit simpler in interface then that's great. But overriding method missing, extending base classes all those things should be avoided at all costs because it, it really hurts the, the maintainability and extensibility of your code. Tools are another, another thing that are, that I've talked about in small talk they have fantastic tools and it's built in. Refactoring was one of the things that was sort of invented in the small talk world. One of, you know, basically everything awesome that we do today was invented by small talkers. So refactoring is one of those things and it was sort of pioneered in small talk environments and those are the things that we need to focus on in Ruby. I know that people like Vim and, I'm an Emacs user so I'm, I'm as guilty as, as everyone else but I am making active efforts to use, you know, the tools. I don't know if the Eclipse stuff still exists or whatever but I, I use Emacs myself and I tell everybody else they should use RubyMind because I think using the good tools is important to the language. It, it helps our productivity and it really helps, helps everything get out there quickly and it helps whenever, when people have, when people have good tools that's, it comes back to the, to the point I keep, I keep saying that we can focus on solving real problems when we stop fighting with our tools, when we stop, you know, writing patches and hacks on top of these invi, editors that weren't made for writing code in Ruby and you, if you focus on, on developing tools that can do these kinds of things there was, there are some refactoring tools that are coming out that you run from the command line lately. I noticed two of them on Twitter in the last couple of weeks. I can't remember the names off the top of my head but there are some tools that use things like parse tree and, you know, the, the reflection capabilities in Ruby to do refactoring and analysis and things like that. Those are the kinds of things we should be focusing on because those are the things that will set us apart. You can write Ruby that looks like Java and if you, if you get, if you learn things from Ruby you can write Java that looks a lot better and is a lot cleaner too but by focusing on developing tools and using those tools we can actually take advantage of the, the great things, the great facilities that Ruby provides for us for learning about our code. One of the things we can also learn is don't be afraid of, of the things that the language allows us to do. I did, you know, say that we shouldn't be using a lot of magical stuff but sometimes it's reasonable to use that. So don't be afraid of those advanced language features and most importantly and the main point I would like to make is that don't be afraid of creating more classes. More classes is better than, than fewer classes. Thank you. And so we want to, we want to have more classes and you know what if, if having more classes in your software is, is a problem because it's hard to navigate then get better tools that let you look at how to interact with those classes and that's, that comes back to the previous point about tools. We need, perhaps we need tools that allow us to navigate those more classes and those, those better abstractions than, than we do, than, than we already have. So it looks like I'm a, a, a bit early so that's, that's kind of nice. To summarize I want to remind, remind everyone that you know there's a lot of things that we can learn from other communities, not specifically small talk. I mean there are other communities that haven't been perfect for 30 years that we can learn things from too. The, the small talkers, a lot of the things that we love came from the small talk community not just the language features in Ruby but extreme programming came from a small talk project. We've got the refactoring tools came out in small talk first. Unit testing was a small talk cultural thing and so those are, those are all things that we, that we use and that we love in the Ruby community and we should be looking for more of those. I'm not saying that, you know, that in the Ruby community we're, we're inventing new, new and great ideas. If 20 years from now when nobody remembers Rails then the great thing that, that we will have done is the DHH gave us convention over configuration. If we get nothing else from the experience we're developing with Rails right now convention over configuration is one of those things and I don't want people to forget that and I don't want, but more importantly I don't want us to forget the great things that we got from small talk and from the people that came, that came before us and that's the point of this talk and I, I hope that was helpful for you. So one last point I was asked to do this and I'm, I apologize in advance to the organizers. I didn't ask if I was allowed to do this but there's the European Small Talk User Group Conference is in Edinburgh. This summer is that okay Matt, Graham? Okay, good. Sorry, I got an email this morning that asked me to show this because they didn't, they were planning on sending some materials and didn't in time. So in Edinburgh this summer I will be back for that. It's, it's a great, I don't need a strong excuse to come back to this wonderful city but this is, this is an excellent one and so it's taking place from August 22nd to August 26th and Camp Small Talk takes place before. There, I believe there are, you know, the conference will be about this size. There are a lot of people there, a lot of, a lot of younger people in the European group as well, students and things like that. There are going to be a lot of industry professionals that have been doing this for a long time and if people from this, from this community could go to that community and you, we can teach them what we know about community building and about participation and, and, you know, and being nice because maths is nice and that, that's what we can help those, those guys with. And while you're there, you can learn about long-term projects and, and software that's older than five years and, and extensibility and sustainability and software and I, I think it would, it would help both sides and that's all I have. Thank you. I don't know if there's, I don't know if there's time and I'm not sure if there are a lot of questions but I can probably answer some of this time while there are some questions. Okay. Yes. Hey. It, it should, it, it really should. Okay. So the, the question is that image-based development is a bit scary and so would you like a, a brief explanation about image-based development? Yeah. You know what, I, on this machine I just set it up. I don't have any small talk. I, actually I do have a small talk. You know what, see me after and we can, we can talk about awesome small talk things. But basically the, the best description is a lot of people that are doing web applications are working in, you fire up VMWare to, to, to test an IE and if when you open VMWare and you open up your web browser in IE and you visit your web page and you've got IE open and you're at your web page and if you suspend your VM and then tomorrow open up virtual VMWare again and get IE exactly as you left it, exactly on the page where you left it, that's what happens in small talk. When you close your running program in small talk everything is, is written to disk in an image file which is a snapshot of memory. And so what, now I'm, I realize I'm, I'm simplifying a bit. There are some implementation details here. But when you close your small talk environment and you open it up again tomorrow, everything is exactly where you left it. So for instance, when I'm developing a, a seaside application and I start the web server to develop my seaside application and I leave the web server running but then I close my small talk image, the web server is no longer running. When I start the web server back up again, the web server is now running again as it's, it's the, the, the best metaphor and this is one of the reasons why the image is sort of the last thing that we don't get from, that we don't have from small talk in the rest of the industry. And I really think that the, the usage of virtual machines for running other operating systems is sort of getting people introduced to that idea. So that's the, I hope that helps a little bit. Right. That's a very valid concern and the, he's raising the concern that it's, it's a little scary that if you set some local variable somewhere it's still there and it lives on. One of the interesting things about small talk is we sort of joke about this a little bit when I'm, when we're talking to new people about implementations. There are objects in the, in some small talk images that were instantiated in 1979 that we lost the source code to and those objects are still there but we lost the source code to them. And so if you look, I think Squeak has actually gone through and removed these. It is a little bit of work. You have to do some house cleaning but the, but again back the tools, small talk has, has excellent garbage collection. I have never personally run into a problem where I instantiated some random object and it was still hanging around a few days later. I have definitely instantiated some objects and you know a list of addresses in an old format have been hanging around or whatever but really if you're not using them you don't care because they're not there they just consume a little bit of memory and if you are using them then you're aware of them and if you're not using them the garbage collector got them before you thought about it. So the tools that the language is sort of based around managing this image so we can't simply add the image to Ruby because the language, the garbage collector is not good enough but it's not as big a problem as it sounds. It really is, the image-based stuff is really the hardest thing to get your head wrapped around and it's, it's, it's definitely, definitely not easy. Yes? Yes? Okay so the question is that because you're developing directly in the image how does that tie in with version and troll? So basically everything in small talk is an, is an object and this is you know there are no exceptions to this rule. So if you create a new object, if you create a new class which is an object that represents for instance an address then how do you version your class definition and the code and the methods that you're writing in that address and there are, there are some version control things and some of the commercial small talks have their own, there's a bit of disconnect between the different small talk implementations so the commercial ones have their own stuff. I focus on the, on Faro specifically which uses Monticello which was created by Avi Bryant the guy who created Seaside and Monticello does, takes a package definition and applies versioning to that and so creates an object that you can load into your image and unload and so it's, it's not the way you would think of like versioning your software. You can't use GitHub on, on a small talk project necessarily without filing out your changes and being diligent about that and it's kind of a problem but the, the versioning tools do, do fit you're just not versioning files anymore you're versioning objects. Oh absolutely there's no Unix culture in small talk. You do have to, to you're not necessarily reinventing Unix culture in small talk and versioning control and things like that because I'm not you know this is one of the things I'm not absolutely positive the small talk invented but I do know that there was versioning, there was object versioning in small talk a long time ago and it might not predate things like RCS or whatever but it's one of those things that was sort of developed independently in two places so versioning is not specific to Unix based tools but it is definitely a different, a different, a different way to solve the problem. So there are definitely some things that coming from, coming from a file based language to, to an image based language you, you have to learn some new tools and things like that. I will make the exception, note the exception is a GNU small talk. The GNU small talk technically has an image but all of your code is stored in files. It's actually developed on GitHub and things like that and what GNU small talk does is it has a very basic image and then it applies your source code to it when you load the image and you have the option of then dumping the image or throwing it away and starting over from scratch every time you run your program. So GNU small talk is a nice stepping stone to get from a file based language to an image based language and I strongly recommend that you, that you check that out. Also for anyone that wants to learn small talk the language although what I, what I've tried to focus on here is not the, not the language so much and what we can learn from the language but what we can learn from the culture and the people but the language is also great. You should take a look at Faro which is at Faro project, faro-project.org and there's a PDF book which you can also buy from Lulu called Faro by example and it's, it's a really great introduction to learning small talk. So I don't know how much time do we have Graham do you know? Okay do you want to have another one or two questions if there are any? You have a question? Well I guess. Maglev that's, that's a great question. Graham asks why Maglev hasn't taken over the world yet and I'm, I'm, I'm going to you know start with a smug small talker answer and say that it's because the world is not ready for Maglev yet but Maglev is still under active development. I, I should also plug Maglev because I love it. Maglev is a Ruby implementation on the gemstone small talk or on a small talk vm it's done by gemstone which is now owned by vmware and they, they develop a Ruby implementation on, on small talk and what that allows you to do is create your Ruby objects, have them in the image, interact with your small talk code that you can also write at the same time. They're now running rails so you can write, have a Rails app and write small talk, write your controllers in small talk. You can have a seaside app and write some of your stuff in Ruby which is really great because small talk lacks a lot of the interacting with the rest of the world stuff. I would actually probably prefer to write in seaside and have some Ruby bits and that's, that's a great way to do it as well. The latest Maglev as of a couple weeks ago now runs seaside three so you can do seaside and have your Ruby stuff in there as well. And the, the best feature for me is the ability to use the gemstone object storage which is which you're familiar with and yeah this is a gemstone specific feature it's not necessarily a small talk thing but what gemstone basically gives you is a distributed memory store so you instantiate an object and you have 10 servers that share a whole bunch of memory that your image is sort of shared across and they solve all of you know it's acid compliant they solve all of the the synchronization issues and stuff like that so you can just when it is literally horizontally scalable when you need more objects you just add another server and it increases your stuff. The gemstone stuff has been used for I know one guy that's been working at gemstone for 29 years and he's been working on on software for managing they work on things like managing international shipping a lot of you know stock trading the insurance industry is a huge user of small talk and things like that so these are huge industries that have big sorry okay so these are huge industries that that make a lot of use of small talk and they do this because of tools like gemstone yeah I think I mostly agree with that in ruby the the thing with small talk was that testing came later in the small talk community and so it wasn't it wasn't early on now I this is going to offend some people but in small talk I don't feel the need to test as as thoroughly as I do in ruby because the tools give me the ability to look at what my code is doing a lot better than I can do in ruby so I I do still drive my I still do test drive my code I'm pedantic about testing but if I didn't have tests I would trust myself to work on the small talk code more than the ruby code because the tooling is better so tooling does take away some of the necessity for for testing and one of the things that I that I that I've always said about ruby is that the testing culture is very strong in the ruby community because it needs to be there they're the language just doesn't provide us with it you know give you know to beat the old cliche it gives us enough rope to hang ourselves and people do and so testing you know sort of solve some of those problems and I think that I think it's a it's a it's a combination of testing existed first before the sort of the resurgence of the ruby community when rails came out so testing was already there and I mean rails had a test suite built in let's not kid ourselves if rails didn't have automated tests in it you know it wouldn't be as large an uptake of testing in the ruby community as it was it was rails sort of gave us the example that we should be testing our code and we can you know argue later at the pub over whether it was a good example or not but at least it got people testing and so those are that's something that's really important but I this another thing that I think the tooling support that really helps the Ruby Wine guys were showing me cucumber running in Ruby Mine yesterday the tooling can help the testing too so we can actually beat small talk in that in that area yes absolutely you should you should write that tool these are the so the idea is that we should be using you writing tools and using tools that do do analysis on the code I've been working for the last year and a half just sort of hacking on my own personal things to analyze code and and measure things like coupling is one of the hard things to measure and and one of the things that I'm doing personally is to do things like can I quantify violations of solid and I know that of Chad Fowler and and I think Michael Feathers have been working on some tools lately that do the same sort of stuff their stuff is actually out there and usable I think it's called turbulent so those kinds of things are the kinds of things I want to see in ruby moreover I actually I actually want to see us have an environment that runs that runs your code so picture when you're in small talk you're always at run time there's no I'm editing the code now I'm running it when you're in small talk your code is running when you create a new object it's there it's it's basically like developing a Rails app in script console the whole time and that might not sound as interesting as it is but if once you experience a small talk environment if once you're in when you're in IRB or in the Rails console you have the ability to say what are all the controllers I have available and what are the methods that are defined on this controller and you don't have to parse anything you just ask and that's a great way to do it you can say what are the what are the routes that I define the things that we use rake tasks for all things that you can do programmatically inside your application if it's at run time and I would really like to I don't have the time or inclination to work on this project but I would love it if somebody else would write an environment that would be that would allow you to do development on a Rails app at run time I think that would be fantastic especially as we move towards more interactive javascript stuff when we move to more interactive javascript stuff a lot of people do their javascript development in the browser when I have to do javascript I do it in firebug and things like that so because the tooling is really great for these dynamic languages and this is one thing tooling I really can't say enough about that tooling is the important thing because dynamic languages absolutely need the tools because we can't get enough information from just reading the source code because there's some information that's not there but there's a lot of information that we have the other language environments might not have and you can't get it just from reading the code you have to get it by measuring the interactions between objects so I I absolutely want you to work on the tools that you're describing and find other people that are interested in that writing tools for ruby is is not hard ruby has the reflection capabilities built in and then there's there's also if you need to parse there's parse tree which is which is really great and things like that so yeah the tooling is paramount are we just about out of time yeah yeah all right thank you