Scale By The Bay 2018: Panel I: Thoughtful Software Engineering
Recording: Scale By The Bay 2018: Panel I: Thoughtful Software Engineering
you and it's always fun to watch the next generation come up and see what kind of cool stuff they're doing and understand you know how the world is different from where I was at and you know what's important and what's not and and you know how we're gonna move the ball for it so today I have a full panel of people done exciting things themselves some have more or less gray hair I look at you and and they each have their own exciting story to say so I'll let them do it okay so I'm Martin I didn't know what a compiler was until I was 23 I thought it was a little computer that would sort of past my transform my programs and push it to a big computer because the T has always said it didn't pass the compiler so I thought about the machine once I found out what it was I was hooked and I wrote quite a bunch of them and nowadays I'm mostly about disrupting this color language I'm Mars Eriksen I guess I also a formative story about compilers which is you know the advanced compilers class and in school is kind of what got me hooked into doing also a lot of computing and things that's very exciting field I think I most recently I've been working at a company called Braille where we apply really large-scale data processing and machine learning to detect cancer at a very early stage yeah my name is Renard I'm one of the authors of the red book functional programming is gone so it tries to give all read/write exercises too yeah I'm also co-founder of the company called unison computing we're making a new perturbing language which is awesome and yeah so I'm Julie and I got to know Alexi when I showed up at a Scala jazz hackathon a few years ago and for some reason he keeps inviting me back to these events but lately I've been in the machine learning infrastructure space which has nothing to do with Scala hey I'm Brian it's great to be on such an August panel I am NOT a programming languages person I'm not a PL person I'm a systems person and I'm slightly nervous that this is all a trap and I am gonna be held hostage and ransomed back to the system's community in exchange for god knows what so I'm buying the exits that's why so my whole career has been in in operating systems development systems development a lot of us kernel development a lot of see a lot of assembly and recently maybe it's always why I'm here I have fallen in love with rust you know it's a geek conference when you're in love with a new program okay I'm gonna get started here and I'm gonna pick on people intern and then we'll just tell it the conversation flow after that and so for Martin here I guess sort of the first comment or question is basically you know Scala reminds me of sort of like the C++ of Java it's got every possible bell and whistle on the planet and if you use them all you can't even read with your router so [Music] well if you if you look at the the language size is actually not true this Gala is about half the size of Java you would be surprised but if you if you count language feature now that nice piece of it so just just to give you an example Java has two language features for conditionals it has an if-then-else and the conditional expression Scala is only one and there are many other examples of that so actually the grammar of Scala is significantly smaller than the grammar of Java or a lot of other industrial languages that's I would believe it's a good academic heritage okay academics like to do small languages and essentially not to put a lot of bells and whistles in your language what might look like as the bristles are that Scala is very orthogonal so you can combine things infinitely many ways and yes that has been misused and we are looking at ways to make to reduce that both by essentially teaching people not to overuse with say symbolic operators and stuff like that and by putting more restrictions in the language and thinking of implicit conversions are there any features you're wishing you hadn't put in maybe you're thinking taken out yeah we're taking out quite a few so the one thing we're going to take out this xml literals which were all the rage when Scala got very mental you do that soon what what made me do that so he said yeah it's not here I did what he said you have to put xml literals in the language xml is the future so everybody will and all that you can just cut and paste webpages into your program and it's cool so so we're gonna take them out again we can take out quite a few other things procedure syntax you can restrict implicit conversions existential types so the new language will be slimmer and meaner than once burned twice shy so Marcus what I even forgot your intro what were you talking about large scale that are processing cancer early detection previous Evan I'm more known for RPC systems and micro servos micro services so micro service has always struck me as a thing for people who didn't have a program keys or something what is it how is it useful over just writing your code well this is code is different with packaging it right so so I mean I do agree that most of the time when people do employ micro services is not necessarily for a good reason and to be better off just you know writing more monoliths instead but it is a very useful tool for companies like you know large companies like Twitter and Google and then many others that are operating at large scales to sort of produce a system that where individual teams have much more intelligent than they otherwise might come so an old colleague of mine Jake Dhanam actually had this reason talk where he sort of made the argument that the main trade-offs that micro services presents is to give sort of a new point than this set of trade-offs between autonomy of leverage right and and what it's meant by that and I find this to be very nice distillation I think of why we perceive micro-service architectures in the first place and what effectively meant by that is that as a product scales and as a system scale in terms of developers at some point you know it becomes kind of intractable to even make small changes to large code bases and so you have to either invest very very heavily in development infrastructure or perhaps fragment your you know your large model that's up into smaller pieces that that do kind of retain tractability of doing engineering and deployment and an autonomy on the other hand you lose a lot of leverage which is sort of you know everything from the fact that you know introducing these network boundaries where none existed before right which is a huge source of complexity to the fact that it's harder to share code across them you have to coordinate now and deal with you know serialization concerns and you're introducing a lot of complex that didn't exist before right but you're able to make independent progress in these sort of individual islands and so I think the interesting thing about micro services that as we sort of initially split things out we gained back all that autonomy and was able to make progress and and have sort of slowly been recovering a lot of the leverage sense by you know by introducing the abstractions new libraries new ways of sort of thinking about how to deploy and operate the systems sounds like a better way to scale out people that's exactly right yeah I don't think I don't think you should even think about micro services until you have a people problem okay yeah yeah okay so I have a functional programming question for you okay why are they so slow that's very thoughtful question so so functional programming it's slow and Scala depends on it depends on how you how you do things I think that you have to be thoughtful about how you how you do things how you implement things functionally and yeah it's you have to pay attention to like real-world physical concerns yeah you do it like you have to pay attention to whether you're going to run out of stack or whether you're going to generate a lot of garbage you're running on the JVM things like that or you know you might choose your language very carefully like you might want to choose like what's like high school or US tip you're going to be heavily into functional programming and and you want to be fast but you don't always want to be fast so sometimes that's not what you are optimizing for sometimes what you're optimizing for is compositionality and comprehensibility rather than like running really fast are you saying that if you come back to a project in three months you want to be able to understand it without three weeks of untangling the code that's exactly right Julie I mean because spending three months over three weeks or whatever on understanding you know your C++ program or whatever it's not fast you can write unreadable code in any language that's true okay so for Julie you know you've been doing some ML stuff recently is that what I got okay um God where to go with this one there's so many directions so the MLS currently touted as the savior of the planets or maybe the killer of all the robots are going to take us all over or something where is the hi meet reality actually I think they're in parallel dimensions to be honest huh unrelated tracks going off in space and different ways and let me give you an example and then I'm gonna pick on either Lexi or whoever put together the blog I did an interview for the the scale by the Fae blog and I said something about before I learned anything about machine learning it seemed like magic and so I wanted to kind of unpack that and the headline was machine learning is magic was out of that blog post and so even at a tech conference it's easy to get carried away at like it's gonna be this magic bullet that solves problems now it's all very specific subsets of problems where it's really hard to write a program for and that's most more or less the extent of the state of the art so it solves a very narrow domain would you say it looks something like maybe a better microscope to looking at your data a better way to understand and look at some piles of data I mean I would say it's better at looking at predictions that you wouldn't otherwise be able to make based on data that you haven't yet seen so it's not it's not that narrow right I don't want that sort of under smelvin but it helps you understand sort of latent properties of some sort of domain that you might not otherwise understand so I mean at the end of the day it's it's more or less applied math all right thanks okay we got Brian down in here and you've been doing stuff and rust and I guess the easy question here is witness rescue did you see the day before I stopped using it so you know rust has made actually very interesting bargain where you get the the power of a I think they even the distinction between a functional language and an imperative language I think all these things are drifting together but rust you get a lot of the power of a functional language you can allow the power of a modern language but you actually do that in a way that is as memory explicit as see and actually what I found the thing that's been really interesting for me is that it actually outperforms say that's been really surprising and in part because you can actually be because you can compose things so much more easily than you can even say you can actually get super high performing data structures in that kind of core library and but you can then and then you can use them really easily and so what we end up with the one I've ended up with it's kind of like knucklehead and rust outperforming my hand optimized City which is a very crushing experience by the way to think like I we spent a lot of time on the sea and this rust that I just kind of threw together is outperforming it for the same task but the reason for that is because it's actually able to build your constructor so it's rust I mean it is a bargain you have to that you're making and that you are having to think a lot more about it and you know it uses a half line types which is not something you've seen in a lot of other languages I mean I think there are the languages I I made the mistake of saying that rust was the first programming language to do this of course which is almost never the case right anytime you like something in a programming language and you want to talk about its novelty someone has to come out of the woodwork probably sporting more gray hair than you have I'm telling you that no no no Sydney what did this and Oberon did this it's like all right Jesus Christ no but and I think I know a lot of programming languages and I do feel like the like the ownership model like okay I know I'm gonna regret saying this but I haven't actually seen this another programming language so I'm not a PL person but this is I haven't seen it immediately so I was like no no clean did this years ago and what the hell is clean it's a terrible name for a programming language but clean is and I'm sorry I'm sure I'm mortally offending everybody but and the end so glaring font clean did this but the very few programming language that have done this and it's a really interesting bargain that has made its it's really intriguing it does allowed actually systems programmers to now get a really powerful model language why can't I have our cake and eat it too why no TC well I just think it if you need GC like this is not the right language honestly I mean I wouldn't you think that I'm because I think that I mean we're always exactly right that you don't always want a high-performing artifact is not the primary goal always and you don't always want the bargain that rust hasn't but the bargain that Russell's gonna make is like look you are going to think a lot about this artifact upfront more than you would for other programming languages in return I'm going to give you an artifact that is higher performing more durable that's not necessarily a bargain you want to always make you want to do spectate of software engineering you want to be able to kind of quickly concept things on the fly and so you don't always want that and if what you need is garbage collection there are lots of great languages that are gonna allow you to get I want both I do big data with all kind of complicated infrastructure rabbit and I do coronal loops I run over terabytes and I want those core knowledge to run fast so I actually learned well so I think the thing about rust though is you can't have but I mean with rasta effectively are doing both because you're doing mental GC as you're writing your code it's the other way around I I let the GC pick up all the crappy code that I don't think about but in the court of loops I do the hand generated a flying function thinking about what the hell is an object and when is it live on what installations because that's where it matters for performance does it matter everywhere so I don't want it everywhere so I what I found is that the that in languages that are GC that when you have this idea that like a part of my software I'm gonna really care about it and the other part that's a frog I just don't care about it and like you know we can just like poop all over it the the poopy software always ends up overwhelming what was a cuter we the high-performing software and a stupid mistake somewhere in the software that you're just kind of like blathering out ends up actually holding that optic reference that actually causes your heap to explode or that that's the that's the coup that actually doesn't it being in the loop and it wasn't intended to be and you end up spending a lot of time debugging that and so Russ and again the position that you know to agree with Russell position but you kinda have to admire it for for it how unilateral it is Russ is like I'm stuck I'll let you write crappy code ever like I'm gonna be up in your grill like every time you want to do something I'm gonna make you write it correctly or as correctly as I the compiler know how to enforce but it is to a remarkable degree there are a number of kinds of software defects that are very hard to actually make and rust I mean the it is so I mean run a run signed extension and arithmetic overflow for example I mean it's ridiculous how up in your grill it is okay I think we got that you're passionate about rotate the panel to a different topic and maybe they weren't speaker and ask the questions about well it's thoughtful engineering and in like you know thirty seconds or less what is thoughtful engineering mean to you and we'll just wrote on the list again here I think it's being able to think in many different abstraction layers so - at the same time and she write your software to a high level of abstraction to a high level of correctness and know what it maps to when you have to and essentially not mix up the two abstraction layers I think that's that's a key element of thoughtful soft engineering for me it's hard to disagree with out of anything to sort of add on to that there's a certain art to knowing when you should erect sort of an abstraction and introduce one and when you should tear it down it seems like actually most sort of software innovation it's either one of those two things either kind of tearing down abstractions that exist and finding a way to simplify things or introducing an abstraction that gives you kind of more leverage on top of it and to add to that it also say that you know one thing that I sort of associated with with thoughtful software engineer is to sweat a lot of the small stuff because it adds up right so we think a lot about like sort of high-minded architecture stuff but really just like being very very persistent about sort of sweating out small details getting everything correct and and being being persistent about that is something that pays off in heaps in spades usually yeah to me thoughtful software engineering means sort of taking a long-term perspective or taking about a higher level view of things you know like thinking and thinking about what what are your goals really like are the are the short-term goals that of the business immediately are those really the goals I question that and then think about like the total cost of ownership of the software that we're building because I think that software engineers we're actually really bad at this at estimating this sort of total cost of ownership and so making sure that at the end of the day we're creating an artifact that is an asset rather than that I think's thoughtful software engineering is caring about the person that has to deal with your code when you're gone you know thinking about how can how can you make that code better you know my first time as an engineer at Netflix was the first time that I had to do code reviews and I had a very thoughtful panel of code reviewers and so it what it taught me to do was think about what is that most thoughtful person gonna say about my PR before I submit it so that I don't have to like hear it all of their you know comments so so at the end of the day you know if you leave a company and you encounter one of your former colleagues and they're not like sort of like face-palming over all the you know mess you left behind that's probably a good sign that you've been thoughtful yeah I would echo exactly what Julie said but I take it up to another level of magnitude because software or I think we kind of lose track of us in how easy it is to create software or destroy it but software is mathematical machine and software unlike everything else we build unlike everything else we engineer software can survive in perpetuity was you could writing software with your artist GCD I'd rather if your answer is no you get you're gonna get wrapped around the axle on some really nasty paradoxes your answer is gonna have to be yes that you could was writing software even though he's running at several thousand years before the computer we all of us in this room will probably write software that at some point in our lives that will survive us and perhaps survive us by millennia we may be living in in the ancient Athens of software right now and so I think that it's an it sounds heady and ridiculous but you look at how much software we are still running from the Big Bang of software in the early 70s and it's entirely reasonable thing we'll survive in perpetuity so thoughtful it's our engineering is thinking about not just the person that comes next but actually the generation that comes next and designing software for timeless correctness I will add that software over 30 years ago come back to me after 30 years and say hey we're still using this yeah so I didn't hear anyone say tech debt elimination I didn't hear anyone say running a continuous integration process I didn't hear me say J unit testing I didn't hear anyone say well there was some code review comments it happened but no one said hey cook reviews so is there something about thoughtful software engineering that includes the process by which we make code anyone want to you know take that up process by which we write bytes I mean I guess maybe when when it comes to process I mean maybe my overall theme was that sort of thoughtful software engineering involves people so not sort of over-rotating on you know the actual tech or the actual code you write but actually how do people in her face with that software and I think it includes considering you know where where it's gonna go down the line which means you need to have a process so absolutely thinking in terms of you know well this is we're getting something into you know production environment let's say it has to have a it has to have a life what are we going to do when there's you know failures how how are the teams interacting around this software so that's absolutely including so this software is a team sport yes you mention the long term I mean you mentioned the testing and I think it's part of this sort of locked our perspective that like tests communicate to people far far in the future or maybe in the new future maybe millennia in the future what it means for your software to function correctly so testing it has documentation of expected behavior as a contract exactly actually I totally gave you that actually I'll also add to the sort of femur on code reviews I feel like clearly you serve a number of different purposes so one is obviously to kind of vet the correctness of the code and to make sure that it fits in with the other code that you might have around it but I think it's also a huge vector for education both ways right so it's a great way to sort of indoctrinate people into a particular project and teach them about the abstractions that exist and how things have done what the local idioms are and things like this and I think I find this to actually be one of the most effective ways to sort of introduce people to the both the local vernacular as well as just sort of general engineering practices and so you know and the theme of working with people I think this is one of those sort of greatly underappreciated aspects of code review that is used I think quite extensively in the industry is here worked on certain larger projects where code reviews were not the norm as opposed to were the norm so I certainly created all like coding standards of every possible kind and companies were not the norm and the jump to code reviews was a hard one but it definitely a highly valuable one when was that job in terms of wiki because I mean when I came into I cited for tensor scroll development and I came into the mid nineties and Cody was already very well and documented their first time I saw was probably mid 90s yeah yeah and but it was not everywhere because I left there moved on and didn't have code reviews again for a while and did did not and then finally did regularly after her early 2000s but it was really there was a five to ten year window where some companies did it and some did not it's one of things I've missed about those days of code review is that they were all printed out you would I know I sound like a pizza you know but you the printing out there's something about actually printing out the diffs sitting in a conference room and actually going through it with for me at the time going through it more senior engineers to your point about it about education I also think that that what I found is that the most important code reviewer is yourself you've got the you have the best contacts on the code you wrote and just do to your point about reviewing your own code before it is actually reviewed by others it's amazing what you can find when you actually look at the code you wrote I find it's very helpful to talk to another person about my code without them actually having to like look at it really because the act of having another person makes me quit skipping over all the little steps I skip in my head and I do the actual logical thinking process and then all the holes of my thinking come out like oh yeah yeah okay spoke blah comments because I'm like I definitely I believe that like blah comments are free from a compiler perspective so we should err on the side of writing novels as we are explaining our code totally there but you should go first well I'll just say that there's when it is resolving uncertainty when it's providing clarity yes there's there's wrong ways to do it I had worked with an engineer who would literally copy and paste emails threads into Vanessa didn't didn't help at all I have so many follow-up questions yeah so I personally enjoy people who write in bigger chunks to do a bigger problem and then they have to comment a bigger chunk to describe hey this next couple stanzas are going to solve blah blah blah and so there's a high-level review once they understand how overview for me having a sort of a line by line comments like less helpful I don't need the long variable names and I don't need by one understand the big picture and then everything looks like it's in this we call these big theory statements this is the key new Jeff on look at sunbong oak was was infamous for famous for these big theory statements that would explain the entire subsystem and then you didn't need the line by line Tamas does anyone want to jump in on coding styles before I read consistency that's my biggest thing just don't have five styles I think pretty much we make a language from two thousand or even 2016 and on it should have not a formatter and that should be the only thing that matters for me the most important part is really naming so basically name every immediately intermediate result that you have and I think I believe in name but it's kinda that's a lot of abuse that people write like expressions that go over ten twenty lines because they can just compose a map with a flat map and so on it's hard work to find good names but it pays and one should insist on that that's one thing with all its restrictions that pythons son of God right so bison didn't want to give you lambdas because they would link to that so they said well you have to and she has a named function and that forces you to fight to give a name to that immediately I'm not advocating that we should go back to that and I I like that that's where they are but I wish people would use more names because that's that's really underused right now if I said one thing on style okay just I can we I totally agree desistance city-style have a tool that forces it but for the love of God can we stop in the 80th column please I've worked a lot of teams where no one every norton coding style and then when they did and they believed if they love and they hated it and what I found is the number one rule about coding styles is that I've never seen a coding style make a project or save a company but I have totally seen coding style Wars break teams apart and cause them to be dysfunctional and so they start to hate on each other and then it's not safe to talk what's really important because your comments are wrong or your camel case is not underscores or your past the 80s column sorry I do that and you know it's important that people agree that it's okay to disagree and what looks like wonderful code to me you look like Horrible's to you but maybe vice versa and not one coding style rules them all and get used to reading somebody else's code and then when it comes time to go hack in their code oh there's an ownership of code notion their honor their style but if you're going to replace it it's time to tech that replacement yanking your whip replace kind of things it's your code now you're an opponent so you should write it in this style that lets you write most efficiently as possible and then for somebody else still have to take a little bit of work to understand that code and I've lived by that mantra for quite a long time now and ultimately for me it has paid off and all the teams I've worked with I don't know I think Richard from that show Silicon Valley would disagree with you he broke up with his girlfriend over tabs versus spaces so I think I is like horrible - totally I do think it's what I've experimented with all this stuff and we went to all the states rights model where they was exactly were describing where you kind of have a consistent style within a file the the the Civil War over white space didn't actually end though that doesn't actually and it will all became very passive-aggressive one person making hard tabs appear as poop emojis and their own editor is to make it public and announce that that's what it is and we can agree to disagree well you don't let the thing Fester I find that proxy wars over white space are usually like like a marriage where you're arguing over the toothpaste it's usually a symptom of something deeper absolutely and and if that's it if there is an ardent disagreement over that there's probably something deeper going on and I think you've got to address that that deeper fracture does anyone want to like stand up and volunteer that goes doing the right thing with their a14 meant to rule them all I heard a lot of applause audience will definitely stand up do that I think for that so there's one white coding style and they got it right and that's it there's one right code formatting which is not as soon as I was coding style owners cannot be enforced really but but yes it's it resolves all these arguments nobody there's been we at Grail we work primarily and go there's zero arguments about anything to do with formatting the kiss tour is just one so why doesn't the compiler just enforce it as a as a style as a part of the compiler Planck's language Bank I mean I guess it could okay I it's unnecessary because I have a tool that forces are forming which is not the compiler but it does the compilers job I'll point out that in the Unison the language I'm building once you submit your source file to the codebase it gets erased and so formatting is is enforced you can retrieve your code base in enforce formatting but you can you can never get back the formatting that you wrote it in never met a formatter that didn't screw up at least one of my block comments so a lot side a little bit too I think one interesting I think side of side effect I don't know you know which direction of causality this actually happened but because go has very strict requirements around this code format that you know it's always correct and so on and so forth that has you know created a very good sort of ecosystem or other tool that can ride off of that and as a result it's very very simple to write tooling over go source code right because it's been kind of first-class to sign principal or constraint and you actually see that in a lot of very rich you know tools for go that are also very simple I guess it's a long time Kampala gated that that's sort of the easiest piece to take advantage of and the actual for many well it really matter to having a rich code base but a lot of good engineers from Google a little bit so because go has a pretty printer that retains that has a canonical representation and retains formatting of comments and everything else cleaning if they're in the middle of stuff including in the middle of stuff all those details are already sweated and it's a you know part of the standard go library building tools that does source code transformation is just extremely simple and standard and it always outputs the same thing goes this in code back I'll still claim it's not nothing to do with the formatting but you can get a tool kit that does that well well well what one thing that does help though is that goes grammar is unambiguous to know ship reduce conflicts things like this right and so there aren't you know everything is very unambiguous and simple right so I guess that's where the language design aspect of this comes and language design is a hard thing there's no doubt about that so on the in here I saw you like dancing come down were you about to say something no I was probably still reflecting on your coments MBI I think it's just a fighter fighting action Emax join us all right floors open somebody say something you know obnoxious well I just wanted to think one of the dangers if you're asking about go and the the kind of mandated formatting I think one of the the danger actually an NGO is a kind of tradition of intellectual autocracy that has that has grown into the language well although than you think and it's millat of decisions that are that are kind of fickle and the the way those decisions are made is there not very broad-based decisions and I I think that the so you and there's all sorts of strange just innocence of the Java GCP process clearly in optics radar right clean opposition but I do think one of the dangers is that I mean ie the number of people that told me that dough should never have generics and would and would repeat the liturgy about why generics are absolutely inappropriate for go and then are now I have thrown that liturgy out and replace it with new liturgy about how generics are coming to go I think the best that is actually a problem and I don't think I think the formatting much more reflects that that it does from on high or the flip flop from the massive football pretty much on high right I mean the the the the Pope has changed his position on generics so now it's like that now we can we can have all our sins okay right and which I again I think it's I mean I think it's great that the Pope changes mind that's nice but and and I and I it's great that generics are coming to go but I think the next gay marriage well well and I I and there are analogs for that and go right I mean I think that the I mean that would be you know the death of CEO I think would be that the actual but III think that that I do think is corrosive to that particular community I do contrast it to rust and I think that the one of the things I think is interesting about rust is that you've got a very broad-based community making very directed decisions and they are doing it because there are unified by their values and they tend to look at every programming language that's ever done anything when they want to do something and try to figure out all these lessons things other languages I think part of the frustration that I personally have with go is sometimes it feels like it's not looking at languages that came before it or ask again rusty see I think but but I think that Russ's principles are around being fast it is a it's a blazingly fast modern language with me an ending creep RFC for that we honestly if you wanted to do that you would create an RFC for that and you'd start that conversation with the community much more thank you stay on stage and why not so actually this observations is I think highlights are sort of interesting aspects also related thoughtful stopped in an area which is there's often this sort of trade-off that exists between what you call you know an electoral intellectual autocracy very hockey and and and sort of you know there's more broad-based decision making and so on I would say one you know one aspect of that I think NGO has handled very well is to really focus on simplicity right and I think that's something that would really be difficult to do and a different model of authorship and the sign decisions and things like this because it's it's it's always so tempting to you know add features here and there and sort of cater for all these cases that may or may might not be so important so yes you definitely do you know you definitely do open it in a different place and I'm not necessarily making a judgement about what's what better or worse but that isn't sort of interesting part of the this design spectrum and sort of it's interesting to see how different designs end up just sort of based on the social and technical hierarchy of house you know that artifact is created ok I think we're running low on time does anyone want to add any last-minute here's what I think's wrong in the world and I'll add to begin with open the door no modern programming language talks about time you cannot reason about the speed of execution of your code with a compiler to back you up and support you you don't get an SLA on any function however trivial it is is it running one nanosecond one millisecond one year you don't know and the compiler is not gonna help you at all so the act of writing code that has performance guarantees becomes a freaking trial and error becomes a try and test and load balance and optimize and just hope that it's actually going to give me five nines what I need it or not and you just don't know and it's high time to get a programming language that mentions time as part of a first class first class actually like Oberon did that in the 80s [Applause] it looks actually that like this modern computer hardware this is ever ever more difficult because it's actually the hardware already that becomes unpredictable with caching and things like that so I don't really see how a compiler could give you hard guarantees without going to a much simpler hardware model how about an SLA where I get like a bell curve with statistics even take that and do side-channel vulnerabilities make that more more difficult to offer the programmer I said that I think that 2018 has been a very difficult year our Anna's horriblest in terms of writing secure software and now it's like a high resolution time but suddenly it's pretty bold about it turns out statistically speaking you don't need a very high resolution timer for spectrum l that or you can use a very low resolution timer and still have them be reliable they started with high res but once you apply some stats don't need very high that's a different whole different ballgame we're all living an age where vulnerabilities are being newly discovered every day and even our core hardware we use every everywhere all the time freaking x86 is but anybody any processor with caching is vulnerable to specter meltdown style attacks and what do we do about it and you know are we even now getting robbed blind by somebody in China god knows what I don't want to pick on but you know you just don't know and and there's a room for people to go think through how security works and why it works and when it fails and what is the crook do when he's looking to go rob somebody there's a certain mindset involved there so I think there's room for a lot of room for growth in a lot of different directions are just new challenges for the new generation to go to going on I think I'm being told to wrap it up right now and I'm actually wrapping it up right now so I guess we've got two minutes so let's go around what do you see as the new town that you would find useful for people to look at and do it like 30 seconds so we can complete this job in two minutes area anyone can go first I think as software has become a pretty mature discipline we now have folks who need to interact with software that are not engineers so of course top of mind for me is data scientists so how do we allow data scientists to do the equivalent of software engineering in their world so I think that's kind of a big challenges is thinking about the second-order effects yeah I'm going to second that and that that I think that software creation is going to become an increasingly more important medium of communication for people and making it easier to understand software making it easier to learn how to program I think it's a challenge that we need to need to rise up do I think like you know pretty much my entire career been super frustrated by the fact that we spent 98 percent of our time doing things that seem unrelated to the task at hand and shaving away at that I think is a noble goal and something look at the I think the challenge still remains how to get to a level of high correctness to verify correctness without getting bogged down in detail so if you want to go to correctness - to the end again you write code in conquer act our Theory improver like that but for most often it's just incredibly hard to do incredibly tedious so question is how can we scale it up would be a big challenge for me yeah it's a say the exact same thing how can we force the programmer up front to bear more of the intellectual burden of correct software such that burden is not being born those and operations of a production or stuck to bucking code Wow thank you very much I guess this will be into the panel and I I think everyone here deserves a wonderful round of applause [Applause]