 Favorite introduction so far. Short and to the point. Saves me time. I guess I have time for a little story now. So I went for a walk yesterday in this town. I find this town in some ways very different from my hometown in Austin, Texas as you can imagine, but there are some ways that are very similar. For example, we saw this this big bridge and it was across one of the busiest streets that I have ever seen, right? And the guy I was walking with said we should go walk over. So we got up to the top of the bridge and there was nobody on the bridge. Then we looked down and there were all these people crossing the street in the middle of the traffic. I said I know that bridge in Austin, Texas, right? And then I also noticed that that there were trees all around. You know you have this big city with these beautiful trees and in Austin we value the same thing. So I feel quite at home here. We also have lakes in Austin. This particular lake is called Lake Travis. It is 64 miles long, but now we're in drought. So we paddled all the stuff that had water in it, which is about 42 miles. We were in these kayaks where you'd sit down and they were foot-powered and during this talk I was planning or during this paddle I was planning to talk about fear. And you can imagine if you're going to be paddling 42 miles and some of this is going to be at night. Well you have cobras here, right? We have rattlesnakes and rattlesnakes like the night and in the middle of the night we have to come come off and you know see some of these cliffs. Well we have to find a place to camp kind of climb up the cliffs with our tents and everything where the rattlesnakes are and the scorpions are. So I was thinking a little bit about fear during this during this paddle and I was planning to talk in my head. And I was thinking that fear is remarkable in ways not only does it affect us personally, but it also places a mark on places. This is the Great Wall of China. It's obviously motivated by fear and if you think about it you can actually see fear from space. That Great Wall of China. You can see fear from space and if you think about a little bit more fear and discovery have always been closely intertwined. Mostly because you have to overcome fear to discover and if you think about fear and language creation they've also been closely intertwined. So I thought maybe I'll do a talk about language creation and in fact this past year we had the first Elixir Conference and that's a language that I'm involved in mainly from the marketing side. Jose Bellum is a very close friend and he gave his keynote address and it's the first time he'd ever given this talk and it's one of the most powerful keynotes that I'd seen and one of the most deeply personal talks that I've ever seen. He actually showed most of the talk was was showing commit logs. On this day I committed this I made this many commits right on this day I made this many commits and he showed a graph of the commit logs over time and he pointed to the times that he was feeling good and he pointed to the times that he was afraid. When he was afraid his productivity went down to zero and I thought to myself I can't write that talk because I've never created a language. I can't go into that much self-discovery I don't have enough to say so I thought we're gonna take this and if you think about it there are all kinds of books that are already about already out there about fear and creation. If you're an author you know of fear is writer's block if you're an artist you know that that when you're afraid you can't create. So I thought that's already been done I can't really do a talk about fear and language creation. What I can tell you is about fear and language adoption so over the course of my career I've spent time in the development lab time as a consultant but also time in sales and marketing and in fact my current company does market research where I can make it better.com and so I spend a lot of time around customers and people talking about adoption and in fact this has been true for quite a while there was actually a guy named Jeffrey Moore back in 1991 who wrote a book called Crossing the Chasm. How many of you have ever seen this book or heard of it? A lot of you right it's a it's a famous concept and it's actually maybe the gold standard for technical marketing. This is something that we all have to understand and know if we're to get the best of ourselves as programmers because we're often caught between the place of politics and psychology right so politics meaning I don't want to adopt this new technology because maybe because I'm afraid for some kind of reason and psychology because I can see that there's a better solution right over there somewhere and this is basically the overall concept across the x-axis there is time and across the y-axis is basically the number of new adopters so when you release a new technology of the new users come trickling out and then over a while you pick up over time you start to pick up steam and then as the technology it nears the end of life you pick up very few new users and it's in the overall shape of a bell curve and more label these different sections yet the innovators early adopters early majority late majority and the laggards and there's a space between the innovators and early adopters that's called the chasm so in programming languages we see this technology adoption curve over and over and over we might not recognize it as such and it definitely isn't as regular as you see right here this looks like a sign wave but what you actually see is basically some languages with a much larger adoption curve some languages which which are much steeper at the take off in some languages that are much more shallow and some of these things overlap like Java and C sharp came out roughly the same time they had very similar looking adoption curves so if I'm at the beach and I'm looking at this and I'm surfing I might be frustrated with the frequency of the waves and if you think about it there are all kinds of factors that impact technology adoption of new languages the one that everybody thinks about first is the syntax and in fact it may be one of the things that has the most powerful impact initially for example when Java was adopted it was immediately successful because it was based on what other syntax see C plus plus right and C plus plus was adopted because it was based on what other language in fact we've had 20 30 years of a C style language because that syntax has been hard to displace but in fact there are other factors that have a significant impact on adoption like the typing structure like the available libraries and what the libraries do like the business problems that happen at the time but if you think about it against the backdrop of technology adoption there's a much more powerful adoption curve and it turns out that this one is much more regular than other adoption curves this is the programming paradigm adoption curve and it's much longer much deeper much more powerful and much regular you can almost set your clock by it every 20 years or so the old paradigm breaks down there's some kind of catalyst and the new paradigm takes off and there's a little bit of overlap but not as much as you would expect to see and because we're actually moving between one memory model and a new memory model and I'm talking this this kind of one mental model and a new mental model and I'm really talking about the way that we conceive of code the way that we understand code this is a much more difficult nut to crack so we're talking about the chasm between the early adopters and the early majority and what it takes to move a language from one side to the other side and if you're thinking about this kind of adoption this is the adoption curve that this conference should be thinking about because we're actually doing two adoptions at once right this is a functional language conference and adoptions adoptions curves for the language are important and the adoption curve for the programming paradigm is important and they're happening at the same time and it's a very difficult nut to crack and if I'm at some conferences some people would ask me why would I even care why would I even want to cross the chasm I'm able to get a competitive advantage with my functional language why do I even care if if the rest of the universe comes across with me I'm happy right well with crossing the chasm you get the political the economic advantages you get more people tools frameworks conferences like this one become more powerful and since those things are springing up then all the things that we like is developers come with them especially the beer so at this point I'd like to move from more to take so most of what we've talked about so far is about crossing the chasm but I want to talk about the role of fear and crossing the chasm so these are ideas that I've had over time that had that over the last three or four years that it began that had begun to crystallize in my mind so I want to talk about two different kinds of fear the first type of fear is a paralyzing fear right now when I say paralyzing fear these are probably the things that you think they are all the things that make it difficult to adopt any any piece of new technology especially things like programming languages and programming paradigms which are inherently difficult to adopt so the paralyzing fear becomes wider as it makes the chasm wider as it becomes greater and these are the types of questions that you think they are is this language going to be abandoned because that happens with a lot of new languages am I going to be able to find developers for the language what's it going to cost me and the biggest factor in crossing this chasm is often the way that we approach crossing the chasm the manager is thinking not just what does it take to move these three or four programmers working on this project across the chasm but what does it take to retool my whole organization so when you start thinking about things in those terms the chasm comes goes from something that you can step across to something that is much much greater especially with programming languages that shift programming paradigms and this is the new language graveyard this is where languages go to die so we also learn that this is where that that this also leads to longevity of some pretty interesting players on the on the right side of the castle right how many of you know any cobalt programmers well in the United States every room and every hand in the room would would almost be up right there's still quite a bit of cobalt there how many of you know C++ developers and of course we're already we're already in the Java world even though these castings have long had been cast have been crossed 20 years ago right so there's still some paralyzing fear that that's keeping some people on the other side of the chasm so but when we go to when we change programming paradigms the cycles are longer the chasms are deeper and that leads us and so the paralyzing fear has a bigger and bigger impact but what I'd like to talk about now is how we ever cross the chasm to begin with and that has to do with another kind of fear this is a motivating fear who can think of an example of a fear that motivated some language to cross the chasm it's still a little bit early I'll let you off this time next time I'm going to be very patient okay but basically a motivating fear makes the chasm smaller and in fact the motivating fear can get so small that the chasm disappears entirely and we see the masses rush across the chasm here's an example what's that yeah C sharp so what was the motivating fear that that got us yeah yeah so basically I have I'm gonna get left behind if I don't cross the chasm that's an excellent example right so let's talk about the chasm from Java to C plus plus right so most of us when we think about crossing the chasm we think about technical issues we think about that syntax the memory management garbage collection but it's rarely technical features that get you across the chasm there's always some type of business motivation that moves you from one side of the chasm to the other and in this case when we talk about paralyzing fear when we were moving from C plus plus to something else and what were the candidates to replace C plus plus if you were looking at an object or any language that wasn't Java what were you looking at probably small talk probably right if you were looking at a business language what would you be looking at let's say Microsoft language yeah visual basic or small talk either one of those could work right but there was also a problem of bringing the hardware along with you right if you had committed to to Unix or you had committed to Microsoft and you made a commitment to something else you might it might mean leaving all of your infrastructure behind and that was just too much to stomach but the motivating fear was a business fear called deployment that seems like a small issue today doesn't it how many of you remember the packet of discats that you got with with Windows 95 ten of them right how many of you remember installing that more than once how many of you had to install that in a business I had to do that right so do you guys recognize the thing in the United States we had these metal roller skates you kind of slap on your sneakers so basically we said that the deployment for Microsoft Windows was discats and roller skates right but it wasn't one system that you had to install those ten things onto right because you had nine registers in a store and then maybe you had five different stores so this problem became pretty massive right and then was Microsoft Windows stable no and what happened when you you got a new release I had to reinstall everything right so this is the backdrop of the of the IT this was the state of IT when it when it became time to to move to Java now there were starting to be some deployment platforms that could use the that could use the net but they weren't prevalent or reliable on the Windows side or in the business world on the OS2 side with IBM so we even had to multiply this by the number of services that you layered on top right it wasn't just Windows that you had to redeploy it was your own application code that often had to be recompiled and deployed again it was the database manager it was the land manager and the communications manager if you had a three-tier solution so you had fixed packs in a pack of diskettes for all those things where you might be installing 40 different diskettes and then that took care of the Microsoft stuff but what about all the stuff that came with it so you had multiple vendors and not all of them use the use the tried and true IBM or Microsoft development processes there were all kinds of fragile techniques like even screen scraping where you would literally load some emulator software and you would look for position 14 through 18 on line 7 and that was your value and then you plug that in somewhere else right so this this these fragile techniques led to a lot of updates and I was using a memory model that wasn't even protected from one system to the next so things were inherently unstable and you throw into all this unholy mix the idea that that business users were starting to panic because it couldn't handle all this and so they were behind and then they started writing macros and spreadsheets and these these visual basic applications with business users and then when those got out of control they went to IT and they said help us in IT got squashed under the weight of the deployment problem and then comes Java and they say hey I don't have to deploy to the client I can deploy to the internet right I have this thing magic thing called an applet well no no no a servlet and I can deploy one time to the browser and once I've deployed to the browser that cuts my deployment problem by an order of magnitude and suddenly I can manage deploying to the servers right so when people talk about the catalyst for Java there were some things that made it interesting but the business problem that was being dissolved solved was deployment and once the deployment problem was solved then everybody and it wasn't a chasm it was a stampede to the other side so here we are Java has crossed the chasm how many of you are coding job happily coding job a few hands still up you're brave you know most people looking around saying yeah my brother enjoys coding Java sometimes it's okay you can like it we've got Java parked on the other side of the chasm and this is a functional conference so I'm going to assume that a lot of you would like to be on the other side of the problem with the language of your dreams what do we do is this ever going to happen and then so no some of us have nightmares that maybe we have another 30 years 30 more years of C++ like syntax and it could happen I mean two of the things that could come across are Scala and JavaScript but but still there are some pretty promising technologies out there what do we have to do to cross the chasm well if you think about this talk it's a talk called fear and what are my two kinds of fear motivating fear and what's the other one yes so what are the paralyzing fears today I told you I was going to be patient and I'm going to be patient what are the paralyzing fears that are keeping us on this side of the chasm support yeah I've got a new language how am I going to support it right what else what's that talent yeah how do I find new talent what else ecosystem yeah community right documentation you can go on and on and on right there are all these fears we can recite them by heart because these this is what our manager is telling us every single day right and maybe and maybe here it's not even your management maybe it's the management of people across the ocean right so the paralyzing fears are the things that they always were right their adoption community cost how are we going to cross the chasm but I have a question for you what's the best way to eat an elephant one bite at a time and I'm here to tell you that we don't have to cross the chasm in one big shot this time right we don't have to cross the chasm in one big shot this time it's different this time around the motivating fears are so strong and we'll get to those in a second but the motivating fears are so strong that we just need to provide a little bit of incentive in a bunch of different different areas to turn this this chasm this hesitance to a motivating fear in a stampede it's ready to happen we are already primed so the first concept that I want to talk about is building communities why would I list so somebody mentioned that community in the ecosystem was something that was preventing us from crossing the chasm why would I say that building communities is easier now why would I put that on the other side of the ledger anybody have any theories what's that social media internet right so vincat and I are authors right we've actually reviewed each other's books and worked on books would it surprise you to hear that writing books is not as lucrative as it used to be this surprises no one right and the reason is that there's so much information that's out there already right so if I'm going to write a book I have to write a different kind of book today than I used to I am actually going to admit something at a functional conference my primary language is Ruby on rails that surprise you I've even heard some some chuckling over here and and that's that's well deserved I think but there are some things about Ruby on rails that they're pretty cool and one of the things that made it so popular so fast is the community that grew up around it so who created the language Matt's and where does he live who created Ruby on rails DHH where's he live where did he start didn't mark right who discovered Ruby in the United States where's he originally from London or England and where's he live now Dallas Texas with me right and then in the Committer team who can name the continents that rails or Ruby core committers are from Asia well United States basically everywhere but Antarctica and Australia right all of them so this is a global development effort always has been building community has never been easier anybody want to challenge that assertion so what's happening is we're starting to see languages explode at a rate that they never had before right it's you've never had more access to the people at the top of the food chain people that are willing to help you and they're willing to establish a new language because they're after the community too they're smart right when you help motivated and gifted talent then you get more contributors to the ecosystem language creators understand this the good ones make it easy the second thing that I want to talk about is the idea that when you cross the chasm if you're looking at it from a distance it looks that everything looks like everything happens at once but that's not the way things happen things happen a little bit at a time when we went from object-oriented technology or from procedural technology in languages like C and in Pascal and visual basic things like that to object-oriented technology it didn't happen all at once there were some bridging languages that happened first first there was a object a pure object-oriented language that you could play with that never got it never got adopted what was that language called small talk right and there were a couple other ones but also there were some languages with some with some object-oriented features but they weren't fully object-oriented there was one that was adopted by the United States military does anybody remember what that is at our right there was also a language that was created after C to teach us object-oriented or to provide object-oriented programming on top of C C plus plus right how many of you were C programmers that became C plus plus programmers are there any a lot of you that's surprising how many of you immediately wrote good object-oriented code so what you had was not really C plus plus it was C plus plus minus minus right this was a bridging technology this is what's happening today if you look at the agenda yesterday how many courses did you see on using object-oriented languages in a functional way then catch C sharp course session there was one on Ruby there's one on Java there was at least four or five right and for object-oriented developers using object-oriented technology in a more functional way right we're starting to learn what it means to be functional we're starting to move those for loops those explicit iterators into into routines that handle that work for us we're starting to move from from imperative to declarative right and that will continue to happen and we're starting to see ideas like closers being heck closers are even in Java now right so last time we crossed the chasm deployment was a big deal because deployment had all kinds of hardware connotations today deployment is almost a solved problem how many of you have worked with Hiroku or AWS and they are there are all kinds of options for the Java virtual machine right deployment today is a solved problem so the next thing I'd like to talk about is the idea that even when you're working with one particular project when you're not working corporate-wide when you're working with one particular project you don't have to eat the elephant all at once what are some ways that you can start to use a functional language within one application let's say it's a web app what are some ways that I can start to inject some functional languages set services right basically so when people talk about Twitter that's often held up as a as a failure scenario for the Ruby programming language I think it's a tremendous success story for the Ruby language and in fact I've built my company on Ruby on Rails specifically because I can iterate more quickly than my competition but we're getting to a point where we know that we're acquiring the types of customers that are going to need us to scale beyond Ruby on Rails so what we're doing is we're starting to build services JSON services pure web services that we can that we can access that do the most complex applications or the most complex pieces of my application this is a relatively easy thing for me to do I can do this and bits and pieces because I have the same database driver and the same drivers to my queuing systems and in my web web systems and JSON is relatively easy how many of you write test cases in a different language than then your primary development language so that's what about 5% of the room this is a great way to inject something like a functional language right so there are all kinds of sessions at conferences like these about using more dynamic languages than Java for example groovy groovy in a testing scenario you can also use functional languages to accomplish very much the same thing it's a great way to inject things like Scala because the extra abstractions give you more options than just simple stopping and mocking right so basically my point is that interfaces are cleaner than they've ever been before so two applications can talk even two different elements of the same application can talk and if you're running functional languages and the object oriented language on the same virtual machine then you can even have different pieces of the same application layer implemented in object oriented and functional languages right so next I want to talk a little bit about motivating fears what do you guys think the motivating fears are for moving from object oriented languages to functional languages concurrency is a huge one right concurrency will define this generation of developers do we solve it well or do we not solve it well that's the problem that we have to solve what are some of the other problems what's up can I say it is complexity what's that time to market yes yes time to market is is a great way is a great problem so the ones that I have if you look at every single paradigm shift in our history I believe that complexity is always the first problem that we have to solve I think that there's a reason that new programming paradigms emerge on such a regular schedule every 20 years or so I believe that the old systems can't can't scale up in terms of complexity this is happening with object oriented systems has actually been happening since 1990 since the 99 or 2000 and so right how many of you have been to a session on spring or aspect j or any anything like that and so so basically these technologies are solving a binding problem where Java frameworks were forcing you to bind more quickly than you wanted to they're also solving a structural problem of how to solve what what's called cross cutting concerns things like a person object or an employee object or a department object or easy to imagine with object oriented technologies things like logging that cut across all these concerns are less easy to imagine so there are places where the object oriented paradigm is starting to break down and in fact if you think about the problem that we are solving most often which is babysitting a big fat relational database with the with the web application neither one of those problems are particularly good as object oriented technologies in fact we've seen many many attempts at object oriented databases on the web and they are on object oriented databases and pretty much they've all failed commercially and if you look at if you look at traditional web applications what is an HTTP request but a function they can be synchronous or asynchronous but they're basically functions these are inherently functional problems and we should bring functional problems or functional technologies to bear I want to give you a couple of examples from from the elixir community which I've been involved in and from from my latest book which is seven more languages in seven weeks to kind of show you a little bit of how we're starting to control complexity so the elixir language is interesting to me because it's really the first time that we've seen the application of macros with a rich and natural syntax everybody by that so in closure you have the concept that data is is code and in elixir we have something similar but it's really the AST the syntax tree the abstract syntax tree is code so you can use macros like this use statement in the upper right that and these state statements which which expand to a bunch of different functions and and data operations right so in this case when I type use state machine and I I implement these states I get a very beautiful usage model right where I could say bid store dot rent my video or bid store dot return my video or take a video and then return and then rent it and then lose it right and this is all because I have this this beautiful macro based API that's really serving as a bit bigger building block and then I have some elixir code behind the scenes that actually takes that code and builds out the syntax tree to do what I want to okay so the second motivating fear that I want to talk about is multi-core now how many of you were coding when when y2k happened so a good chunk of you how many of you thought that y2k y2k happened the way that you expected it to so I believe that multi-core and distribution is the real y2k there's a lot of broken Java C C sharp C++ code out there that right now is failing rarely basically because there aren't enough cores to to to make the problem show up but as we start seeing more sharing and more multi-core solutions and as we have to start deploying those job applications that are thread safe to these solutions then the applications are going to break or one of the frameworks that they're based on is going to break right this is the issue that's going to define the generation the programming generation of the people in this room it's not just it's not just learning to to program concurrency in a friendlier way it's about making applications that work that we know work from the top down because the language won't allow them to break so here's another elixir application the interesting thing about the Erlang model that elixir is based on is that it gets two things right the first one is process so elixir has lightweight processes so that Erlang developers and elixir developers reach for a new process the way that you reach for a new object you can actually have millions of processes on on a single on a single system in today's hardware and that will increase you know exponentially as as we throw more power at them there's a system called OTP which had some telephony acronym open telephone protocol or something like that anybody remember okay so but this framework has been generalized to support general distribution this is the elixir version of a chat room right and what's interesting is that this solution when deployed will be completely monitorable where the monitors have a completely different communication channel than the application code and this is important because when things fail and remember in Erlang the motto is let it crash but when things fail we can let them crash and then the monitor can take action on it and what that means to you is that all of the boilerplate code to manage exceptions goes away right that's all handled at the top level of the application where I don't necessarily need to care so you don't see error checking here but this can be a surprisingly reliable and robust application but the problem with Erlang for writing things like this is that since there's no macros there's not a reuse model for it so that if I wanted to use to do this kind of thing without macros this is what the code would look like in elixir and if I wanted to expand that to the Erlang equivalent it's really too big for me to show everybody's got in the Erlang community has an OTP kit code on their editor which generates some 130 or 130 or 140 lines of boilerplate code so what I'm saying is that macros with the distribution model give us the capability to control that complexity by having actual code that writes the code so they don't have to work with a code generation type solution by the way what's the problem with a code generation solution with an emacs key that does the work what what principle does it violate dry it's the absolute nightmare for dry right don't repeat yourself well I didn't I just pressed one key right I just repeated myself a one little time with 140 lines of code right so the DSL is from Dave Thomas the example is from Peter Menten and there's a great article on it called thinking in elixir and hiding your messages and that basically expands things in more detail if you're interested you should check it out so the last example that I want to bring to your attention is Elm how many of you got to see the elm session yesterday how many were impressed it's radical isn't it so in seven languages in seven weeks I wrote the first game that I've written in maybe 20 years when I was in high school I used to write basic games for my spending money you know my neighbors were working at McDonald's and I was writing games and kind of enjoying myself but I quit writing games because it used to be that systems were so slow that I could write a game by by pre presenting something on the screen and then it was so slow that it was time to present something on the screen again right there's no timing or anything like that and then so that was with the IBM XT and when the IBM AT came out it was too fast I couldn't play any of my games and I got frustrated and I quit because I didn't want to work out all the interrupts and the timing and all that stuff with Elm the abstraction Elm abstracts all of that away it makes things like timers like mouse positions all of these things can be interpreted as signals which is really a function that's mapped onto user input right so that mouse X for example is the mouse position the X part of the mouse position with at a point in time right or you could have window dimensions which basically even as the window is is resized you get the absolute window dimensions so that for example if I'm writing a game and I need to move a paddle around what I write is essentially repeatable functions that are easy to test like this somebody who has not seen Elm before tell me what that draw a paddle function does it takes a filled black rectangle and does what moves it to some x-coordinate and then moves it to some y-coordinate right and so this takes a shape which is pipe to another shape which is pipe to another shape so we're basically transforming the same shape over and over right and it returns a transformation of a paddle right and the display function takes a collage and just presents one element and that's that's a paddle right and it uses drop paddle to present that paddle and here's the magic at the bottom so you have this lift to function which means take two signals which recall act like functions right one of those functions is the windows dimensions one of those functions is the mouse X position and I'm going to lift those values at a point in time onto display so now whenever the window dimensions or the mouse X position changes it's going to trigger this function and it's going to draw my paddle at a new location that's wicked cool right so somebody asks how many of you were at the fishbowl yesterday so do you guys recall the question where somebody asked a great question about about inherently stateful problems right like user interface design it's inherently stateful right because what I'm doing is can consistently updating mouse positions right or consistently updating window positions but if you reimagine it a little bit and you say hey really a mouse position is a function and the window position is a function and all you have to do is update when things change right then all the update can be shoved to one tiny sliver of your application and everything else is pure functional and everything else can be tested as if it were pure functional which means I don't have to worry about mutable state or anything like that it's easy to test things in application databases work exactly the same way if you think about if you imagine databases in the right way rather than updating a row in the database you're always writing a new version to the database your value in a point in time and if you want to return the latest value that's fine but you can return the value that's based on the needs of the application whether you want to want to create a consistent view at a single point in time or whether you want to want to present the user the absolute latest latest version so this is why people say that that you can dramatically control complexity with with functional languages so this is what it's going to take to move the elephant from the right side of the chasm to make some room for the languages that we all want to be writing it okay now in the past I've gotten a lot of questions on this talk and I encourage you to ask them now surely you're curious yes and you're asking the guy with with the early iPhone 5 and I had a phone 3 before I had an iPhone 5 that hasn't that never updates my OS software to the next major release I'm just it works I've updated before and it's Burmy so so I just don't so there are there are many reasons to honor fear I don't mean to say that there aren't reasons but sometimes you have to honor the motivating fear as well right so I think that we're kind of in a in a special time right now you can you can see me I've been writing about functional languages since 2010 knowing that I was going to eventually need to move in that direction but I've been staying pat until I found a language that was that I was really excited about and that had the DSL capabilities that I had with Ruby that I could read like a natural language but but where I could leave that processing model behind and I didn't move until I have one so but I think that we're all going to be writing in a functional language three or four years from now maybe even many people in this room will be writing in functional languages before then it's just the the the problems are too compelling there's there is there really is a y2k problem out there right now where I'm not going to be able to be competitive because because my competitors will be able to take advantage of multi-core and I can't because they'll be working at a higher level of abstraction and I can't and and things are really going to start to break I truly believe that more questions yes could become mainstream is functional programming paradigm but if you look at last decades or few decades back there were other promising approaches for example like aspect orientation so in future what paradigm do you think has a potential to you know replace object orientation other than the functional orientation okay so the question is what programming paradigms have the potential to replace object-oriented code other than functional programming so I believe that's that's an excellent question by the way I believe that programming paradigms don't happen overnight I believe that a lot of groundwork has to happen first before a paradigm emerges and if something something else had had had emerged then we would have seen it by now I think that there are really two primary contenders and one is a hybrid approach something that you might see in Scala or OCaml those are very different two very different versions of the same thing right Scala is more of an iterative bridging technology much like C plus was in OCaml is more of an immutable way to do object orientation and pure functional and of those two I think that pure functional is going to let us make some mistakes that object oriented or object orientation let us make actually there's a third alternative and I hesitate to mention it because I'm so afraid of it and that's JavaScript there's there's a big push to JavaScript right now I don't think it solves all the problems that it needs to solve the did I answer your question in the back corner here I can't I can hear did we have a question over here yeah okay I still write a bunch of secret okay so have we ever we have adopted new languages or new paradigms but have we ever really left something behind or really moved on right even if you see today there's a lot of C code being written a lot of Java code being written a lot of JavaScript code being written I think we are adopting new technologies but those are more for a domain fit right as a paradigm shift itself in the thought we are solving problems right if you're gonna solve something for kernel today I don't see any other better language than C today yeah so I think that there's a question or actually comment built into a question that that will never fully leave object orientation yeah yeah I completely agree with that in fact I think that that there was a question and statement here that sometimes it's important to honor the fear right to honor the paralyzing fear basically I didn't say that the paralyzing fears were irrational they're actually very important but I do believe that there are some things that will move our business critical applications forward based on competitive pressures where hardware is going I mean our world economy is based on increasing hardware and increasing performance and that can't happen basically the hardware guys when they started when they stopped doing this with chips and they started doing this when they started building up they basically said not my problem anymore software guys it's your problem now we're up right so I'm talking about line of business the mission critical applications that will need to grow and need to scale so great question thank you next question yep you talked about yeah you talked about you know crossing the chasm being never easier but one of the things is if you look about the earlier chasms that were crossed was there used to be one big problem and one major language that sold it now we have lots of potentially lots of problems being solved at the same time and lots of potential languages lots of languages wanting to solve those together so even in your last slide you had a whole number of languages each of them solved a different set of problems to a different extent and does that do you think that is making crossing the chasm easier and potentially confusing more people in terms of hey there are so many new languages attempting to solve these like this particular chasm a little bit differently I am not sure you know which wagon to hitch my you know right with and making that a difficult and slowing down crossing the chasm okay so I think that there's a question in a statement let me see if I can summarize this so basically the question or the statement is maybe we won't cross the chasm with a single language this time maybe we'll cross the chasm with multiple languages and let me make a deep personal confession that the best books that I write are written out of fear when I'm afraid my I step back and I examine what's going on and when I have an insight that I think is important I try to push that out in the form of a book I never expected seven languages to be a popular book I wrote it because I think I needed to do it my I needed to do it for myself and apparently enough of you were having the same fears and concerns that you were that you were you know basically made the book successful and thank you but basically I wrote the book because I didn't know what the winner was going to be right and that's usually not like like that like me vincat has seen me start to talk about hibernate long before hibernate was popular in spring and in ruby on rails I can generally see the winners as they emerge it's a blessing and a little bit of a curse too right I can't see what the winner is going to be or even if there will be one true winner my suspicion is that there will not be and the reason is that is the same reason that we mentioned earlier it is much easier to build community and thus much easier to build critical mass for two reasons first because we're talking about much people being much more accessible resources being much more accessible than they ever were before right and that's true for two reasons first because a lot of the languages that they were most interested in are open and not proprietary small talk remember was proprietary the digital license was very expensive right and the second reason is that we're not talking about a united states market anymore this is a world market right and that means that languages new languages are emerging in which the united states plays very little role or no role at all in fact one of those languages is elixir right now right where the lead developer is jose and jose is from holand originally from brazil and the second committer is eric meadows johnson who lives in sweden actually met him for the first time in stockholm you know we communicate a lot and and i met him for the first time this just just very very briefly right but the world market means it's much more easy to accumulate a smaller a critical mass in that basically because people are more accessible and the communities can be much smaller and there's a larger people of larger group of people to drop from so my intuition is that you can have a successful language because more people are are available to help out and build the market sorry i think the essential question sorry the essential question was is the multiplicity of languages and different problems being solved will that slow down crossing the chasm will slow down crossing the chasm i don't think so i think that right now the the motivating fear is just get is is just going to be too hot so already the you can start to see when the the early adopters move and and you start to pay attention when important people leave the room right and and we have some personal acquaintances one of them is guy named stew halloway he left the room a little while ago moved to the closure community moved from the job community to the closure community um jose valham is is a guy that um that wrote the authentication framework and the um and the integration to the web server for the ruby on rails community so he's left the room so we're starting to see the cool cats leave the room from from the obstetrician technologies and that's making people pay attention and so people are afraid and that fear is starting to drive um drive people across the chasm and when when the leaders go um you know there's there's also there's a bigger um pulling effect than there was before especially vocal leaders from the obstetrician community so excellent question and thank you more questions i think we'll have to get it shot uh we've passed the time so thanks again for all the wonderful questions keep them coming through the day bruce is going to be around uh thanks again bruce for the wonderful keynote big round of applause for bruce thank you so much