 to ask questions. We will have a panel here of some of the speakers that have been around from today for today and tomorrow and we will try and get them to answer some of these questions. But just limiting it to the speakers would not be fair. One of the rules of the fish bowl is at any given point in time one chair needs to be empty. So between the two chairs if both the chairs get occupied then one of those guys will have to leave or maybe one of the speakers will have to leave. And then that allows one empty chair for anyone else from the participant to come in and sit in the chair. Why would someone come up here? Let's say someone asked a question about what is your favorite concurrency model in FP. Let's say that's a question and people want to talk about that. So we will have a few speakers over here who will give their opinion about what is their favorite concurrency model in FP. But maybe you feel that you have more insight or you don't necessarily agree with what was said or you have more to add. Then you would come up here, take the chair and share your experience or talk about your insights and then we move around. So we move to the next question. So we will take questions from the audience and then we will just kind of keep going through that. Does that make sense to people? Yeah, we will try and get it up here to answer. We could do two things. We could run it like a boss which means you form smaller groups and then you just have discussions in those groups. Or we run it like a fish ball where only the people on the stage will actually be talking. Obviously people can ask questions but people over here are the people who will be actually talking. And then if you have something to add, please come to the stage and then contribute. Let's give it a shot. Let's try for 30 minutes. This has worked really well in other conferences that we have run. So I want to try giving it a shot and then we will take it from there. Can I invite Bruce to come up please? And we have both the future people men to come up. Who else is here? Ryan, why don't you come up? Go ahead. We need four people. How about Keats? We want to come up. We could have two more people from the participants to come in, join and then you guys can feel free to circle around. So do we have anyone who has a question that they want to start with? We have one there. What's the first language as a newbie programmer that you would recommend them learning? That's a good question. I like Ruby. APL obviously. I'm going to take a little longer or someone will pass us on. Well, I was having this kind of conversation earlier with someone in the hall and I think the first language that you will, you won't pick your first language. It will be picked for you, more likely. So the question maybe is what, given a language, I don't think there is one particular language. There's probably a class of them. JavaScript comes to mind, you know, these things. But I really don't think there's an answer to that. I think there's a class of them. You need to choose whether you're, I think in 10, 20 years or maybe 85, like Venkat said, your first language will be a pure functional language. That's probably not going to happen yet. So I think that there are a number of different characteristics in a language that makes effective teaching. So if you look at it from a perspective of what would I teach my kid using, then it would probably be something like a Ruby or a Python where there's not much ceremony and it's easy to solve problems very quickly. I don't have to have all of the class and module wrappings. I can just basically say print for and it will print for, right? If I'm looking for, as somebody new to the industry, I'd like to look at what colleges in the United States have done most effectively. And you'd have to say that MIT is one of the best colleges at teaching programming. And one of the things that they do is teach multi-paradigm language lists to start everything off. And basically they've had tremendous success in people learning lists and then stepping into object oriented languages, functional languages, or even languages that are different from those paradigms. So I think that one of the things that each of us should do and the reason that if I were to start a company, I'd look around this room is we should each be learning new languages. And through conference isn't really about one language. As you see the banner, there's a whole bunch of them down there. And that's why I wrote seven languages in seven weeks, seven more languages in seven weeks of the databases. The idea is that every new spoken language expands your mind and makes you think a little bit differently. Every programming language does the same thing. It increases the number of idioms that you can use to attack the problems that you face every day. Actually, no, no, no. Oh, you're asking me about that. You know, so for me, I think it doesn't matter what programming language you pick. You know, so pick something and try to get good at it first. So if you're in this world, then pick something that is easy to practice with. So for example, I would pick to add to what you guys said, Ruby or Python, something that has a repel, for example, allows me to quickly test my ideas out. Something that doesn't require me to start up an IDE, for example, to do anything serious. So that is something I would look for and practice quite a bit. There's no substitute for that. And then again, once you're good at one, then look at something like that. I'd like to add, too, that it seems to me it just makes sense that when you start somebody learning a language, you don't give them too much at once. You don't make them learn that the ceremony was also in memory. So that's why it just strikes me as strange when I hear of universities starting people with C++ or even Java. There's just so much there that's really irrelevant to the heart of programming. I think, I mean, this may sound a little strange, but I think it depends to some extent also on what the end goal is. And it's trying to keep somebody to understand what the goal is coming to the computer. Because if it's the latter, you might actually want to start with something like Excel. And then move over into the language with a little protocol like Ruby Python. I would add a URL to that script as well, even less. So it depends on where you're trying to go. I am myself in the process of becoming an expert. I mean, I'm nowhere close to it. But my current strategy, and I failed in learning, in contributing to any functional language till now, but my current strategy is essentially take one of the classic texts, be it how to design programs, CTM, SICP, whatever. Start with the language that it uses, because it is the least. And do the book completely. The problem with a lot of us is we do the preface, learn the history of computing, go to the introduction, do the first two paragraphs, know how to write a hello world, and then jump to the next book because it got difficult. I think that is the biggest problem that I face. I have done almost all the textbooks, but almost none of all the textbooks. I have done 20% of all the textbooks, and I ended up learning 20% of what needs to be known in every single language that's out there. But that's not important. What is important is not knowing many languages, not but knowing one language well. And the current strategy is, and I've taken SICP, I'm in the third chapter, I'm solving all the exercises as I go. If I get stuck, I do go online and cheat. But, finally, I'm working through all the examples yesterday, and I think that is very important. I'd also like to say that the answer to a lot of the questions that I have in my mind is technical community. And when you're learning a new language, it really helps to have the support of other people. In fact, whenever back, the two functional languages that I studied and I did, we were relying on closure. In both cases, I was in a study group, and that just helped me tremendously. I just want to add to that. Pick people from pick languages. It's going to matter much to me. If you're in a crowd who knows Ruby, go for it. I also wanted to add, I think we're all going to learn a bunch of languages. Some things, maybe it doesn't matter so much. If you're going to program, you're going to learn a bunch of languages. I'm not saying don't be skillful about choosing a person, but maybe more of a social issue. The question. Anyone else has any other questions? I'll ask one. What's your favorite kind of team on the next week? I guess I'll give the guys a chance to think. In this past year, the past two years, I've started to work actually by accident on a line of books called 7 and 7. One of the books was 7 Conferences Models in 7 Weeks. This theme is interesting to me, the 7 and 7, because it's not about learning something for your job. At least six of them is about learning things for the sake of learning. Concurrency models is one of those things that the concept is easy to gloss over the concept. I'd like to comment about quitting when things got hard. Concurrency is likely the problem that's going to define this generation of programming. Languages that solve concurrency well and even different protocols within that language will ultimately define it. There are a lot of good ones out there. There's the closure approach, which started as a stateful transactional memory, but it's evolved to something very different. Just solving problems in terms of flow, there are data flow approaches. There's the macro-based approach. There are approaches that are good in object-oriented languages like the Acro Library that Scholar uses. But I would encourage you not to learn one concurrency model, but to learn several different ones and learn the difference between them. You are some of the most elite programmers in the world, and this is what will separate you from your competition, especially in the next five years or so. In my understanding of it, I'm working my way through the concurrency model. But I think maybe to start with a single process, another single process, but on a single box, maybe in a UI, exploring concurrency within a single kind of environment like a UI like using CSP4A sync enclosure, these kinds of things, and go language, play with that. Before you go into distributed, which is going to talk about concurrency, a lot of the effort is into distributing that concurrency, and that's where the real model starts. So I think I can start small and work it out. That's my current strategy. I don't really have an answer to this. It's really good for me to be here. I'm here to state about HL, but one of the things about HL is that I've seen people using that isolation before. So I don't know, perhaps, that the tabulation into this question is correct, but what we have elected to do in HL is something that we just think is that we can, if there are any functions that can be used to do something, Yeah, so it's interesting that we're starting to see concurrency locked on to a lot of languages that are already out there. And in some cases, that's a good idea. And in some cases, because, for example, in the areas of Java, if I looked at problems five years ago, concurrency was madness. And now with the new actor-based concurrency model, it's a little bit less so. But if I were to give you three pieces of advice, if you're looking at this problem for the first time, and with a fresh ability to apply a technology to a problem, the first step would be choose a language that supports concurrency, and not just well, but very well. That has to be in the middle of everything with that. Like a closure that helps you eliminate mutable state and really provides the careful concurrency control with a firm hand to philosophy in the places that it does. Or the Erlang concurrency model, which is basically actors with monitors. You can read the chart. It says keep calm and let it crash, right? What will let it crash is a philosophy that when things fail, I can have the monitoring protocols and the cascading failures arranged in such a way that it doesn't matter to me. It doesn't have an impact. So the first thing is to pick a language that does concurrency from the inside out. The second thing would be to make sure that you get the monitoring right. The language needs to be able to support communication channels and error channels that are outside of the scope of the language channel. That's one of the things that the author based model and Scala, which is actually based on Erlang and Erlang get right. And the third thing is to is that you have to have a framework that scales, that goes smoothly from a concurrency based model to a distribution model. That's really where most of the value is going to come in. When we go from one core to multi cores and you scale that seamlessly from multi core to the cloud. Stephen L has the next question. Difference between these many functional programming languages. So how do you know for this new space, this is the best functional programming language? So do you have any differences depending on the use cases? This use case has to be the best. Another use case, Scala is the best. So do you have that kind of differences? So is your question which use cases are the best for functional programming? Is that the question? Which use case for which functional programming language would you pick based on what you think? For the beginner, I mean it would be helpful to learn how currently I'm working on this use case. I think this functional language would be the better one to solve this problem. Yeah, so I guess I can give you a little bit of a high level view, but basically the first question that you need to ask is which scenarios and which use cases are best for the functional programming paradigm. And I think that if you look at the problems that we're solving today, they are primarily functional problems. For example, if you look at web development, web development is not an inherently object oriented problem, it's an inherently functional problem because every HTTP request is a function call. And it doesn't get, and you don't really get to the form to weigh into the back end where it really makes sense to break things down into objects at all. So we have been doing functional problems with an object oriented language for a very long time. I don't want to monopolize the mic for very much longer. And if you're looking for high performance, Ruby is not the language to use. That kind of information that I'm looking. I think practically something to consider is what is your ecosystem? Do you need to be on the JVM? That will already decide a lot for you. And then if you're on the JVM, are you going to use, do you want to use a particular thing that Scala is strong in? So let me just clarify that. If I was going to do ACA development, I would not do it in closure. Even though some people do attempt to do that, I would use Scala. If I was going to use a thing like Storm, I would use closure. And so I think that matters. So the ecosystem will narrow down your search significantly. If you need to do high performance stuff in functional programming, and you need to get close to the metal, you're going to probably head for OCaml or Haskell, such things. Okay, this is an excellent question to plug in the fishbowl. I'm going to reshape the question a little bit. So audience, I'm asking you, which particular problems have you solved that have moved your object-oriented language to a more functional language, or have moved one functional language to another functional language? And as I'm getting started, I want to see somebody out there coming up and taking one of these seats. Hopefully, too. So I am working at a company which is very small. We have the Twitter model where we started in Ruby. And we're glad we started in Ruby. We knew that we were going to have scalability problems, but we knew that the most important thing was how quickly our development team moved. Now we've signed on some fairly large clients. So if you look at our homepage, you'll see Dell, Nike, and another couple of references that are very large companies. And so we need to move things to a new level of reliability. And so with our next feature, we are starting some Elixir development. And we hope to move most of the stuff that we built in Ruby over to Elixir over time for the back end, and we'll continue to use Rails to scan the application and do some of the templating and the asset management. I work for a company called Index. I mean, if you attended a talk earlier by Kishore, we deal with a lot of data. So we're using Scala as our primary language. So one of the things we need to do is process data to multiple transformations. So we have about hundreds of jobs that run on a regular basis. And we were using Java earlier, and we moved to Scala. And we're using abstractions like Scalding that allow us to do this multiple transformations. So that's one piece. And the functional paradigm actually works because it's a series of... If you see transformation, you can actually look at them as a map, filter, and those kind of operations at the end of the day. So I mean, that's one use case. I would say a concept programming languages really helps a lot. The other use case is we also draw a lot of data. We've got about 100 odd nodes on AWS where we draw close to a billion pages a month. There, we use ACA, that's the Activate Transparency Model which is based on Activate Transparency Model. And the good thing there is that it's distributed by design which means that whatever works on your single core and multi-core also works well in the distributed scenario also. So these are the two use cases on that we've encountered and we've used Scala for this. Okay, I think there's been some degree of talk about concurrency and how important concurrency is. I still think sometimes concurrency is oversold in terms of the benefits it's offering to all of us in the short term. I don't disagree in the long term. What we've actually found is that at least my journey has been in the recent past from Java to Python and from Python to Scala. And I think one of the problems that it has really solved well is the problem of expression. Especially computationally complex code can be expressed very well and using a better quality of or higher level abstractions as I moved from Java to Python and then I actually rewrote parts of those code from Python to Scala and at each stage there was substantial improvement both in terms of brevity and in terms of the nature of abstractions used and I think that has helped a lot. So I think the benefit I have seen and real benefit I have seen is in expression. I can see that my code will do better in concurrency terms but I haven't seen that benefit because I haven't been challenged by the concurrency parts yet. So I just want to share my experience with you. So I've worked in Citrix like a few years ago where we have been doing a GZAN server which is the main to start to manage a lot of GZAN better machines and so at the beginning it was a very big piece of software returning C++ with maybe 20 people in time working on it and at the end nothing really worked correctly. So I decided to work it into OCaml instead and a few months later with like five people everything was working well. The company GZAN source was booked by Citrix with a lot of money so everyone was happy about that. And more recently we started to replace another big piece of C component which is OpenSSL which is a very big stuff which is a very important piece of code and we started to write it in OCaml probably in function code and six months later two people everything seems to work very well so I guess if you are interested into high performance OCaml is a good choice but I think that is why this partnership worked well. For me it is a function programming helps in a problem domain where the solution is not clear and the problem domain is not really defined. I found it very helpful in doing more maybe you can call it explorative programming and things like that where I define a bunch of small functions and I try to come to them in different ways and quickly try out ideas and that is how I found functions in OCaml. Say for example you take building a text editor so the problem is very well defined and you have scope for little customization they are object oriented programming science a lot because you can clearly defend the contract you can collaborate with many people you can clearly defend the contract but say recently I started working with natural language processing and the solution is not clear and the solution is also not defined so we have to try out lots of ideas so I find the function programming useful in that. I think that one of the things that starts to happen over time with any programming paradigm as we start to hit the limits just as we hit the limits we went from assembly language to the first structural languages we had to put more and more in our heads so it started to make sense to bring things up and then as we moved from procedural languages to object oriented languages we were having problems with code organization and as we are moving from object oriented code to functional code we are starting to see that object oriented code doesn't always mirror the way that the world works when it does that is really nice but when it doesn't then we start to nail down abstractions based on the frameworks that we are working with the concurrency, paradigms the natural language processing would be very much in that sphere of understanding so I think that the idea that functional programs composing with functions makes it easy to make designs that are more adaptable is actually a very good idea I wouldn't call myself really a functional programmer but I played around with the concepts and where I found it most useful is from a testability point of view when I kind of think more from a PR function point of view it's got easier for me to think from a PR point of view and think like that that's where I come there was a point when I moved from Java to Ruby where everybody wanted to write a dependency injection container in Ruby and we all found out that we were solving problems that Ruby just doesn't have the same thing is happening with functional languages many people want to write a stubbing or mocking framework for functional programs and we are starting to understand that when you do that you limit some of the benefits that you might have but we have so many other design tools and tricks that we don't have to use the stubbing or mocking and one of the things that's opened up in a highly concurrent language like Erlang or Lixer is that your test will run as fast as the number of cores that you can throw at it and there's no latency between recall and the database at all so that was interesting to me we have one more I forgot to say that we looked for one more so we were doing one integration project in which basically the integration pipe used to run so from different systems we will get the inputs and we will be posting and supplying this data in a different format to a different system so one of the things was that from those different systems the kind of thing we get is XML and we need to post it in a different format so we need to convert it into some data we need to convert it into typically for JSON mostly so the challenge was that the typical way we would do in Java is that you define from the XML schema you just create say classes and then load the parse the XML to classes and then from that create a JSON and that was the very straightforward way the challenge was that the XML structures was not well defined the basic elements would be defined but the structure would change drastically and it was not in our control it was created by some third party too so it was very hard to create come up with all possible kinds of classes to convert to JSON so what we did is that we actually but within those small elements had a logic to convert to the end JSON element so we wrote all these things as a partial function and the moment they keep adding JSONs or keep adding stuff what we did is with those partial functions we kept on creating multiple functions which will convert any kind of XML into any kind of XML so the partial function logic was in one place and it was very easy to maintain the code because we didn't have to create a lot of classes which would reflect every kind of XML config XML output that we could write also it was easy to test because it was very easy to just lift the partial function into a function and then test that single piece of code alone then does it make sense little bit at least? yeah just one question I mean I just don't want to bring that dynamic that was the problem the problem was that you had a type system which enforced that if we suppose the knowledge of the data that we got yeah fair so I used to code in Ruby before and first thing is that just let's write this piece of code in Ruby but the point was that the rest of everything was written in Scala so this one was solved in Scala it was to be on JVM and Scala helped us had it been Java we would have really really struggled so much to cover this probably I think that so I witnessed a pretty interesting conversation at the conference last year between I think it was Joe Armstrong one of the other creators of Erlang and one of the person that contributed to the Miranda language which was one of the fathers of Haskell and he said that he did not expect to see such reliable systems to be possible in a dynamic language so anyway I didn't mean to kill that conversation two standing when this is all over would you rather see a programming language evolve in terms of abstractions data modeling or would you rather see the execution platform evolve in terms of better implementation of the abstractions we currently have I didn't get the question would you rather see the programming languages like more programming languages evolve in terms of better abstractions, better data modeling or would you rather see the execution platform evolve in terms of better implementation of the abstractions we currently have so I think that the question was would I rather see the programming language abstractions evolve or would I rather see the execution platforms evolve was that the question? That's the question yes really good question you might have stumped the panel here I'll tell you what I want I would want the language to evolve because I'm a human with this brain and it's going to have to talk in that language and I don't but of course practically the execution platform of course must also evolve but as a human being I have a bias but one more thing I mean there are some people who are saying that until we've gotten rid of the virtual machines we're not done yet you know until a language has been liberated of its virtual machines we're not done so that's another perspective but I prefer one thing JavaScript programmers also the fact that their execution platform has basically liberated the language from the system I mean it happens both ways even with the execution platform you see a lot of things like thinking about completely new ways of thinking about programming I mean I have been a Ruby programmer before and now pretty much closer it's my go-to tool and mostly because of the I mean even though it's in this it has enough syntactic to it as a language to make my transition easy as a Ruby programmer to a closer programmer had it not been for those kind of things I wouldn't have picked that place I would say it's both I don't think we can live with one and not the other and the reason is I think Java is a great example I was a bit reluctant about Java I said what's the big deal why should I really care and Java proved me wrong several times over if you really look at Java it's a great example you cannot do what's possible on the JVN without the platform the environment really supported but at the same time languages are kind of the lens through which programmers exploit the platform without the language having the power it gives doesn't matter what the platform is here we can't really reach in and for an ecosystem to be really powerful I think both of them have to really evolve but there's one big challenge though and this is something that I don't have a good answer for and the challenge is when a language has been created and C Sharp is a great example of this because over the years it's turned into a kitchen sink it's everything you can do and people don't have a clue how to do it right so there's a risk in evolving languages and the risk in evolving languages is that the language becomes so broad that there are so many different ways to do things that there is no focus on exactly how to do things that can be really problematic because it doesn't give a clear direction to developers but at the same time the reason I don't have a good answer is we don't want languages to become stagnant either so I heard Dave Thomas say one time which I think is brilliant but really hard to achieve he said for every feature that you had you need to have the courage to go back and remove a feature and that's really hard to do because we care about backward compatibility the minute you touch on a feature that's already there you're going to make a mob of programmers who wants to make a mob of programmers angry so it's really a hard problem to solve so evolution is really important but evolution itself is an enemy to the language because then it becomes really hard to use that language in such a diverse and big manner so it's really a hard problem to solve there's so much goodness baked into that question thank you, thank you for that so I think that one of the interesting aspects of that question is you start looking at a broad enough perspective then what you're really asking is what's more important politics or psychology or something like that where the politics maybe even economics is basically how big groups of people interact with something so the Java virtual machine is one of the great shapers of programming languages today and it's actually out living Java but from a psychology standpoint most of the interesting developments in programming languages are in two places one is with the environment and the components of model and stuff like that but the other is how we actually see problems and take problems apart with our minds so after I wrote seven languages I thought that I would never write a book like this again because it was such a demanding process it takes so much of yourself to create something for one language and then go and learn it well enough to not be scoffed at and laughed at and apply it to another language and still another one but three or four years later I was sitting and thinking wow this is one of the golden eras of languages you have things like Elm who saw the Elm talk today did that not completely blow your mind it's completely revolutionary completely radical the functional programming guys were saying hey you can't call Elm functional or reactive basically we're even arguing about what the essence of the language actually is which is kind of cool it changes the way that we think in terms of what JavaScript can do how you can shape programs on the client side and really everything is based on HTML the JavaScript and all the way down there's another language in the book called Idris which is cool to me because I've always thought of types as things that are separate from the expressive language itself so they're integers and integers are really constraints for a spring it's really a constraint well Idris changed that way of thinking by saying well no you can actually embed the programming language into the type system itself you think well how could you actually do that well let's say that I want to have a type of things that are only in elements law so maybe a vector is a list of six so I have a vector of six integers and then let's say I want to combine two vectors together then you can add a vector of six integers so that type is a vector of six integers and a vector of four integers and the result is a vector of m plus n that little plus in there is important because now the compiler isn't just checking programming syntax it's starting to get into programming logic and intent that completely reshapes the way that you think about language I've been minded by Idris and I was saying to someone earlier I thought typing when I saw the person I thought that's sort of them and then I saw Idris we're in the stone age so it looks like typing is a great brand frontier for languages and Idris is kind of the sci-fi when it's a hit of a key and I'm sure Venkat is laughing his butt off up here because we used to have these debates on these separate panels like this one about static versus dynamic and everybody could start a debate by kind of lobbing a rock at dynamic languages and here I've introduced Idris into the seven more languages which is not just static typing but static typing with this additional constraint on it but yeah I think that the pendulum is starting to swing from dynamically typed languages to statically typed languages it results for a good long while because there's so many cool things going on in closure and gosh the electrical community, the airline community but when it swings it's going to be a powerful one so we talked about like what happens when you hit the limit and so we went from machine languages to sending languages and then we went to imperative languages we wanted a higher abstraction from machine languages and then we wanted modularity so we went to object oriented and then we are hitting the limit of concurrency so we're going to conquer the program what is after that what is the next kind of limit that we will hit say is it going to be verifiability that my program should do the right thing with like dependent type languages or would it be like search space like logic programming or something like that what would be the next option wow so if we could answer this question we would not be sitting up here we would be starting a company so most of us are kind of right on the edge of this chasm and I'm kind of getting into the keynote tomorrow but it's all about it's all about crossing a chasm right between the early adopters and then the majority it's one of the things that's interesting in traveling, going places to see conferences is you get a good sense of perspective and in one sense India is much like Japan in that there are whole rooms full of excellent and I mean purely excellent programming and whole rooms full of management that's risk averse so they're very similar places and so in those communities it's easy to see it's easy to see when the chasm is crossed because things change in a hurry right but so this kind of gets back to the psychology versus science so we all want to be talking about psychology when we move from one language to another within the same paradigm but then we kind of get into politics or economics on the grander scale when everything changes at once and so I would say we don't know what the business driver is going to be next time we can start to get a couple of hints of problems right so the business driver this time I think we can all agree is concurrency that this is right now as things are defined and as things are practiced object-oriented programming really wraps state and behavior together and in a more dangerous way it wraps mutable state and behavior together right and that's going to break the current programming paradigm this is bigger than why 2K ever was this will make more money for consultants than why 2K ever did this will cost more damage than why 2K ever did so that's this problem the next problem we're starting to see places where we can't hold the complexity in our heads so the extent that you can verify syntax with a compiler is interesting the extent that you can verify logic with a compiler is much more interesting so I'll add a second one if you look at hot pockets of great developers most of them use traditional language but there's a hot pocket of developers that use logic-based programming and I think that's one of the next paradigms that will become more and more mainstream so one of the languages that we covered in seven languages is Pro-Lawd and seven more languages was Mini-Can-Run but I think that there's a whole lot of growth to be done in the area of functional programming and even macros which is a level above functional programming as it's married to logic programming because really it's a natural language processing into logistics all of those things are logic type problems and all of those things are kind of swallowed up by the languages and tools that were grown at them now I think one of the other problems also is your concurrency is exciting but the real problem I see with where you've gone the wrong path is pollution of state and I cry every day when I look at code when people go really into this command query separation and totally get it wrong and end up really creating very heavy-weight objects and even without problems like concurrency it's a burden on the programmers to maintain code that turns into a lot of city-money-to-built applications that become heavy and more effort need to be put into maintaining this application but having said that one of the things that I see as a bit of fresh air is even when programming with objects if I can turn those more into lightweight objects that where we transform state and focus on functions it becomes easy to maintain the code but having said that I think one place where we are getting it wrong over and over is we have this desire to see that there is one way to do things and I think we are already learning that that's not true anymore I don't think we want to program in functional style I think we want to program in a mixed paradigm and I'm not defending certain languages there are places to improve but if you really look at languages that are evolving they are clearly beginning to provide a mixed paradigm and so moving forward into it I think that clearly the door is open for more mixed paradigm because the world definitely is not this black and white where we can say this is the way to do things here and that's the way to do things there I don't think as we embrace the logic programming more declarative style of programming it's really trying to shed more becoming lightweight and trying to mix better names in areas where it makes sense so if you ask me what's the next thing I think the next thing is actually unlearning quite a bit of what we have learned over the past 40-50 years and relearning a better set of practices I think it's not necessarily a new tool that we need but a better way to use the tool that's been around for a long time a better reprogramming of our minds I think is what is this really needed one area where I see that I tend to write more of procedural code just for me to write to implement functional paradigm in my course is when I'm working with UI tools for when I'm in section programming or very simply when I've been working with DPS therefore almost every line of code that you write there's a system called HACNIN so in such cases where the state changes almost every line of your course and there's so much of state to maintain how do you act implement functional paradigm in whatever language you're creating I think even in those areas rather than taking it as a state mutation we can do a great deal by thinking about state transformation one major inhibitor in our minds is we assume that state transformation is expensive we have kind of the foregone conclusion in a lot of our minds that if you really have to preserve the mutability and transform state you really are going to be inefficient but there are data structures that are proving is wrong there are data structures that do actually make very effective copy and transformation at a constant time and so if we can rethink what we do yes sure UI has to attain mutability because you're changing the state of the UI but if you really look at the data that results in the transformation so if you really think about how things work a certain action happens on the UI that gets propagated down through the system and as a result certain set of actions take place and then you surface back and you display certain results back to the user while sure the UI has to change but that doesn't mean it's got to cause enormous mutation all the way down through the layers we can actually if we rethink and we're willing to consider alternative designs we can take a certain representation of data in the UI apply a series of transformations moving forward and what we end up getting is a trend from the data that again is held by the UI and displayed so we can actually go towards a fairly good amount of mutability in the code but this is going to require that we actually program systems with a very different set of mind than what we are used to right now but we are being ingrained in that we start by mutating state and then passing it around I think it requires a lot more effort on our part I don't think there is a lack of tools there is a lack of will in my opinion and once we are willing to move forward and consider other alternatives I think the solution can work out a lot better firstly I learn so much every time I just sit down in the same room with ThinkAce one of the things that I think is exciting and cool that is going on in programming languages right now is this idea of reactive languages in support of things like user interface development so if you stop and reimagine the problem that has already been stated many times you can see where the functions might be so if you look at you can look at a mouse as mutating state you can also look at a mouse as a function of x and y with a point of time you can look at a movie as states that mutate from frame to frame or a movie as an infinite function with a time box or of a frame which can be any type that you want it to be over time and then mechanically you just have to decide what your refresh rate is and things like that and those are all functions as well and when you imagine your user interface in that way the world opens up for you I think the same thing is starting to happen in database where we have always imagined database quite rapidly as a mutation because the limitation was in stores right now we don't have a storage limitation right now most of us as we build our databases are actually writing in a mutable database and then saying oh we've got this value we're about to throw away let's log it somewhere so we build a copy and then we mutate the state so we're going out of our way from what really would be the right thing to be right is in fact new data whether it's old data or not so maybe we're writing a function of a time stamp and then what the value is at this current time stamp and that's the approach that new databases like datamacritic so sometimes when you have a problem like user interface that looks inherently object oriented it's just the lens that we're looking at the problem for other questions there are roles like programmer or tester or we sometimes say I'm spending time programming I'm spending time testing I'm very fine and yet the two things that all of you talked about quite often was A, immutability and we talked about more advanced typing systems and how some of those benefits are playing given sorry I was to ask a question where I was to move from my existing set of languages to a language which has much better support for immutability or just support immutability only and has better type systems how much do you think my time spent on testing will get influenced tomorrow and my bug counts could get influenced tomorrow I know it's a very vague question but that's likely the kind of question somebody who's wanting to invest into a migration to functional programming likely he's going to ask that question and how will my quality get impacted and is there some kind of answer you would be able to provide there so basically the question is when you move from object oriented to functional from mutable to immutable this can have a significant impact on testing how much of an impact let me interject just a small story I was in a session giving the keynote that I'm going to give tomorrow but I was giving it at a regular session and somebody asked me a question and I said wow that's a great question so I said what's your name and the gentleman said John Hughes who's one of the fathers of Haskell and was one of my idols and I didn't get another word out the whole time but John Hughes is actually working on a framework called QuickJack which based on the type system based on what it metadata based based on the metadata of the system it will throw not just well formed values but values that aren't well formed at your system and let you know where things break so this type of thing is one of the reasons that I think that type systems are going to swing from dynamic to static this kind of goes back into verification there are certain classes of problems that are difficult to prove correctness but it's not difficult to throw a real world type data set at the problem and even to inject some noise and this type of thing can revolutionize the number of tests that you write the way that you get coverage and the way that your code behaves under train I think there are two ways to look at it to answer the question you should really ask the question where do bugs come from and I can say that probably bugs come from two places one is when the code is way too cerimonious we tend to lose sight of what the code is really doing and so errors come through that more transparent then we're able to see through it more effectively than a code with a lot of cerimony this is one thing we all learned when you're a young programmer out of school what do you want to do, you want to go write code when you get experience what you do you avoid writing code that's what it's called experience you gain the wisdom not to write code because hands down the code you don't write has to be with bugs in it cerimony is one area where I would say clearly it reduces bugs one area is if you really look at just one example if you look at Scala for example when you write a function in Scala when you take a parameter you don't have to say anything by default the parameter is final it's a valve you cannot modify it how many times have you come across Java programmers who don't declare a parameter as final and they actually mutate into parameters I would say quite often and this is a practice you develop the discipline you develop and while we all can develop discipline it is so nice when the language challenges you and says quiet and these removes the burden I know from your shoulders and as a programmer that's one less thing to worry about and as a result your code becomes a lot more reliable so to say because the language makes it obvious to do the right things so to me, I call these as sensible defaults sensible defaults are defaults that fall on the side of better programming rather than defaults that fall on the side of you really need to start declaring these things so in that regard I think that programs actually get better but having said that you know a good friend Lynn Backerberg has a saying that bad programmers will move heaven and earth write bad code so just because a language does a set of right things doesn't mean programmers automatically will do them there's a bit of a governance that's needed and that's why I'm a big fan of collaborative effort if we still believe that people will write code and nobody else will look at it I don't think it's going to make a big difference because it's not just the code having bugs the code being irrelevant is a problem too how many times do we develop applications where it doesn't solve real problems and then we end up wasting time developing things right so the collaborative nature of developing software doesn't go away it is still important it's still necessary but I think these are in the right direction where it eases the pain but I don't think there's going to be a language that removes the pain completely on some more shoulders and we say here's the language in program and you don't have to worry about it I think they're in the right direction but I don't think they're going to get rid of the problems entirely so I think when you say something like what is the payoff to take them across to the other side I think the cost is enormous if you talk of a whole group of people and for me I take a more of a guerrilla warfare approach and I would rather say that if there's weight for a use case where it's either a very clear use case where you can clearly state that you should be using something with more immutability more pure functionality and so on and then over time take time to do it because I think it's a social cost this is all about our difficulty to change the sheer risk of changing everything at once so I think for me this strategy is treated like a garden if you want to change the vegetation don't chop it all down just start planting differently and give it time and never have that conversation of let's all go there all right I think you just kind of passed the time so you can call it a day if you guys want to continue we could continue for a while there is food that's ready outside people are hungry and we kind of continue but not keep the formal structure in some sense but just continue a smaller group discussion right thank you guys