Syntaxation • Douglas Crockford • GOTO 2013

good morning I'm gonna be talking about syntax about why we love syntax and our programming languages why we probably shouldn't and how you can get it anyway and take advantage of it the motivation for this talk is the new role that JavaScript has suddenly unexpectedly found itself in JavaScript is now the universal virtual machine languages are being translated into JavaScript in order to allow them to run everywhere well the first languages to do that was Java Google translates Java into JavaScript so it can run everywhere amazing people are now translating C into JavaScript and running at near native speeds nobody ever thought JavaScript would be used this way we're also saying new languages being developed specifically to translate into JavaScript so it's become a universal virtual machine I would contend the first language designed to run as one of these JavaScript languages was jslint jslint could be thought of as a compiler for a language called the good parts and so it was the first it was released in about 2000 and as you know jslint comes with a warning jaelyn would hurt your feelings because it complains about people's syntax and people have a deep emotional connection to their syntax so when you tell them how they can improve their their programs in order to make them less likely to be buggy and more maintainable more readable and all of that they start to cry which is surprising because it's just syntax why should anybody care about that so I contend that syntax is the least important aspect of a programming language design and I mean that in the same sense as fashion is the least important aspect of clothing design which sounds like a radical statement but you know if you look at what clothing is and what it should do it should protect us from the Sun and from the cold and from injury protect our our modesty but but that's not what we consider when we buy clothes in particular in things like shoes people will buy shoes without asking can I walk in them can I run in them will they prove save my foot from injury people will buy shoes that are likely to cause injury in the name of fashion so we forget what's really important and as programmers we think we're smarter than that that we would not you know you look at the completely unfashionable shoes that we're all wearing we would not make that mistake but when it comes to programming languages syntax we make exactly the same mistakes for the same reasons we're totally irrational and emotional in our love for syntax so I'll offer as evidence an amazing book by Samuel caiman came out in 1990 so it's a bit dated but it's still a really good book programming languages an interpreter based approach in this book he writes interpreters for seven programming languages and then he writes programs for each of those languages to show how they work and for these seven languages he doesn't implement to the entire language because that would be too much work to do in a book so he only implements the good parts of each of these languages and for most of the languages that does not include their syntax so it's really surprising when you look at a language like a PLO which is famous for the way it looks it looks radically unlike any other language he writes it with the same notation as the other six languages in order to get an apples-to-apples comparison so it's surprising that you can write in a language without using its syntax but usually when we're reviewing languages syntax is all we look at we look at the most superficial aspect of it and often it could be years before we discover what's in the deeper layers by stripping away all of the syntax camon shows us what these languages are actually doing so the language he uses is a minimal syntax and there a number of languages which have fairly minimal syntaxes these languages are well regarded by designers but are rejected by the mainstream most professional programmers can't stand these languages so Lisp has a minimal syntax it has as expressions and as expression is just a sequence of symbols wrapped in parentheses usually they represent function indications and expressions but they could contain data or any other kind of structure and it's really simple you could take any of those arguments replace it with another s expression and nest as deep as you want this is maybe the most minimal syntax the Lisp community and scheme community love this stuff the rest of us hate this stuff we if we find it offensive to even look at it small talk could be considered a minimal syntax although it's significantly more complicated than s expressions the method invocation in small talk is brilliant you have something representing an object then you have the name of the parameters separating the values of the parameters we rejected this even though it's brilliant instead we took C++ s approach which is you have a list of things wrapped in parentheses separated by commas with absolutely no indication as to what they are and what order they go in which makes it much easier to substitute the wrong value or to get them out of order and we like that we like that it's easier to get it wrong so that we rejected this one which is much harder to get wrong in favor of the one that's much easier to get wrong that's the sort of emotionalism that's wrapped up in our appreciation of syntax so let me take you through the years and look at the evolution of the if statement we start with Fortran here we have a Fortran computer go-to statement so if if the difference between a and B is negative will or zero will jump to statement 20 which does nothing otherwise will jump to statement 10 the parentheses around the condition are absolutely necessary in most languages they're just decoration but in Fortran spaces were not significant so it could not see the difference between if a and if they both look the same to Fortran so it needed the parentheses to separate so it could tell what was an if statement Fortran gets a little better with Fortran for the left sign hadn't been invented yet but it could substitute a dot le dot expression you can see what it does we can also see here the go-to statement demonstrated the go-to of course was the inspiration for this conference and most people wrote go-to as two words even though it's a single word in Fortran again because of this ability to insert spaces anywhere spaces aren't significant so Fortran actually got something right that everybody's gotten wrong since then which is how do you write a variable name which contains a space now so we're all arguing and we've been arguing for years should we use underbars or camel case and it's hard to get consensus because both are the wrong answer Fortran actually got it right but we haven't figured out how to do that unambiguously in future languages so maybe someday we'll figure that out and we'll be able to use spaces appropriately this is Algol 60 the maybe the best design by committee in the history of programming languages alcohol 60 gave us the block statement so you see that begin and end and that introduces a scope if you're declaring variables there and we've seen that brilliant idea carried in to virtually all languages today alcohol also gave us the semicolon there are earlier languages that try to use periods to end a statement because that's how we end statements in our in our writing but that turned out to be problematic because it looks like a decimal point and sometimes it wasn't clear his is at the end of a statement or is it just a number so we went to semicolons instead and we've seen that Convention copied into a lot of other languages this is BCPL BCPL is the good parts of a much larger language called Cpl Cpl like Ada and pl one was and ten was intended to be one of those Universal languages which could be used for everything that turns out to generally not be a good idea that smaller specialized languages are usually better and dcpl was a very successful language and was highly influential in at least two ways the first was that it came with a virtual machine that used byte codes that was written in BCPL so that virtual machine was very easily ported to other machines and so bc up BCPL showed up in lots of places and that byte code architecture found its way into the pascal p system and then into the java JVM but it was also very influential in its syntax BCPL was the first curly-brace language and the curly brace thing has taken off and we see it virtually everywhere now it's basically the same idea that we had in alcohol except instead of beginning and it's curly brace and we really liked that we really liked that economy this is the B language this was Ken Thompson's reinterpretation of BCPL his idea of the good parts he tried to make BCL BCPL a little bit smaller and to make the syntax better suited to ken thompson one of the things he did was in my view a regression he put the parentheses back in in this case the parentheses are not needed that here solely for decorate and it's something that's harkening back to Fortran they're not needed here but he wanted them and so they went into B and they went in to C into C++ and a Java into c-sharp and virtually every language since then has these unnecessary parentheses in it and we think they look sharp they serve no purpose at all and I often find people doing stupid things in order to avoid keystrokes but they like these keystrokes and there is no explanation for why that is this is ADA one of the things I like about ADA is the way it says comments I think the - - things introduced a comment is just really nice-looking it of all the comment conventions it seems to conform most closely to what we do and it's also using the annotated end so instead of alcohol which would just say and it says and if which is a little verbose but it's clear as to what's going on here I think the best if statement I've ever seen is in Algol 68 this was another attempt to make a huge universal language and there's a lot of stuff in ll that I don't like including its comment convention using a sent a sign to both end and began comments starting and ending comments with the same character is asking for trouble the the line comment to the end of the line convention seems to work a lot better but I love its if statement it replaces the end if with Phi so you very quickly learned that you know that two character digraph closes the other thing we got rid of the blocks it's just so elegant I love this I think it's very nice and also it's using : equal there's been a battle in in syntax design for a long time as to his assignment equal or is it : equal in Fortran it was equal but equal looks like equality which it isn't and that's confusing and particularly the mathematicians have trouble with that some languages like alcohol started : equal and we still have this argument going on and right now the equal sign guys are winning and I think that's unfortunate too so what we really like is emotional style we could have minimal syntax but we don't we want the emotional syntax instead and in particular what we're looking for is fashionable tolerance of some syntactic ambiguity ambiguity is bad in programming languages because ambiguity causes confusion confusion causes errors and we want zero errors in our programs but we love syntax which makes it more likely and in fact enables errors to occur which couldn't occur otherwise so I'll give you an example so here we have a made-up programming language with two operators cloud and heart and I've got three variables a b and c and so how do you interpret the expression a cloud be hard to see there are a number of ways you could do it one is you could read it from left to right so you do a cloud B and then you do heart C or you could read it from right to left and so that would be B C cloud and then you our DC heart than you cloud that with a there are languages which do strictly left-to-right like small talk did that and there are languages that go strictly right-to-left APL did that which is right I don't know but you know you pick a direction and you say that's how we do it and that makes it pretty easy to read programs written in those languages you just have to know the rule and once you know that rule one rule it's that way or that way then you can correctly read programs but that's not what we want because that's not complicated enough and that doesn't produce enough opportunities to make mistakes so what we instead want is operator precedence where we want a rule which is more complicated which describes which one you do first and so depending on with the relative precedence is between cloud and heart that will finally determine how that expression gets interpreted so the way we deal with that is with binding powers we can give each operator a number and operators which are associated with a higher binding power bind more tightly or bind first and operators with looser binding powers will bind more loosely and later so basically if you're working in a language you have to memorize this list you have to know the relative rankings of all of these and it can that can be a difficult thing to remember so for example at power 40 I've got logical and and logical or and in this language that I'm going to create here they have the same precedence but in a lot of other languages they don't one of them will bind more tightly than the other so I will ask a question to you right now for your favorite programming language which binds more tightly and or or do they have the same precedence so who knows for sure how their language works I'm seeing a very small number of hands go up so what that means is if your hand didn't go up if you ever see both of these operators in the same expression it's likely you're going to misunderstand what it does and if you did raise your hand and if you put both of these into an expression it's very likely the next person to read your code will not understand what your code does in introduce an error you know and it amazes me that most of the people writing programs professionally won't know the answer to that and it and there's really no reason to expect that they would another example on line 60 in mathematical notation multiplication is generally tighter than division so we can write things like ax over B Y in some programming languages that's also true but in some programming languages they have the same precedence as I showed here so again who knows for certain in their favorite programming language whether multiplication and division have the same precedence can a few hands go up but most of the hands don't because most of us don't know so we like that we like that we put rules into our languages which most of us don't know which are opportunities for creating bugs another source of ambiguity that we like is the overloading of words so we can use a word to indicate a variable a statement keyword an operator or a special form and sometimes it's really important what a word is in some languages there will be lists of reserved words that cannot be used for other purposes because they may conflict with some of these special uses and most people working in those languages do not have a fully memorized recollection of what that list is so that's also introducing other opportunities for making errors we have overloading of operators so in most of our languages we'll use parentheses to do function definition and invocation we'll also use them to do grouping within expressions and we'll also use them for separation and decoration so using the same operator to do all of those things can often also introduce ambiguities which can cause errors we but we like overloading in fact we like it so much that some of our language languages specifically allow us to do overloading which increases our ability to create confusion within the programs that we develop so the way we deal with with ambiguity in language is parsing and we have wonderful formal theories of formal languages which allow us to automatically generate parsers parsing is a very complicated subject there are a lot of amazing books and a lot of papers about it a lot of machinery has been constructed around it so I'm gonna write for you today a parser other language we're gonna see the whole thing so we're gonna start with tokens but you can take all the source elements of a program and divide them into tokens and each of those will be represented by an object we'll have a prototyper token which will be the token that everything is going to inherit from and then we'll have a set of symbols which will inherit from those prototypes and then we'll have the final tokens which will inherit from those symbols we'll have an advanced method which will fetch the next token for us and put it in a variable called token and if we pass an ID then it will guarantee that the token that we're skipping over is that kind of a token so if we're looking for a plus sign we can say advance Plus and that'll guarantee that the next token is a plus sign if it's not it'll produce an error so in parsing what we want to do is to take a tree or to produce a tree so we'll take a list of tokens and we'll weave them into a structure and once we have the structure we can then pass it to an analyzer or to a code generator or an interpreter and it'll cause work to happen so the whole effort of parsing is to produce this structure I'm gonna show you a technique called top-down operator precedence this was invented by von prat when he was at MIT he's teaching at Stanford now he presented it at the Popple conference in 73 he designed it for providing Lisp or high-level languages syntax into a lisp environment he claimed that the technique was simple to understand trivial to implement easy to use extremely efficient very flexible and I will also claim that it is beautiful I think this is one of the most beautiful elegant things I've ever seen so why have you never heard of this if it's such a good thing why is this completely unknown to you Pratt in his paper tells you why it's going to be rejected first is the preoccupation with B&F grammars and they're very soft Springs Pratt loved automata theory and all of that stuff but he found a way to completely avoid that stuff and much more quickly solve the problem it requires a functional programming language and in his paper he used Lisp and the problem with that is that most languages at least at that time were not functional programming languages and the Lisp community had no use for syntax they were had found so much value in the minimal syntax of s expressions they didn't want anything else even if it came at very low cost but the JavaScript community is a community that has a functional language and it's a community that likes emotional syntax so this algorithm is really well suited to that community so prep takes parsing which is a really complicated thing and reduces it to one simple question what do we expect to see to the left of a token there are some things that don't look that that want to see something to the left for example an infix operator will take something that's to its left and then something to its bright and then there are things like variables and constants and unary operators that don't expect to see anything to the left so just those two cases and so he calls something that is expecting to see something on the left a left and annotation or a LED in something that doesn't he calls a nulled annotation or a nut so let in matter Pratt's terms but I'm going to use those so there are some symbols which will have only nuts so exclamation point in JavaScript or tilde and JavaScript those are unary operators only so they will have nuts variables will have nuts then plus dot assignment operators relational operators those are LEDs because they expect to see something on the left side of the operator and they're to make things maximally confusion confusing we have some which have both so plus in JavaScript is both an infix operator and a prefix operator Perrin is both when it's grouping is a prefix operator when it's invoking it's an infix operator so here is the prototype token this is where our tokens are going to start it will have the default nod and lead functions which will just cause errors if you get to this and and these methods haven't been overridden with and the default is to produce an error you'll also have an error method which will produce error messages so if we find an errors we're parsing we can call the error method of the particular token that causes the error and that will give us a proper message and it will also have the default left binding power so this is the precedence of this thing so something which doesn't already have a specific power will inherit to zero then we'll produce our symbol table and that's where we'll keep all of the symbols of the language and we'll have a symbol function which will help us to populate to that table so the simple function will take an ID and a binding power we'll look up the current symbol in the symbol table and if we find it then we'll use it otherwise we will construct a new one and stick it into the table having this we can now start declaring our language so I'm going to specify that all of these things are symbols now and it's going to look declarative even though this is all procedural this is all functional it starts to look like declarations so I'm declaring that these specific things are symbols I'm adding two special symbols of here the end represents the end of the program so I want something to indicate when we get there and because of the rules of tokens of tokenization these are guaranteed to not match anything that actually gets spread in and then I'll also have a special symbol which represents words that we don't have in the symbol table this is going to be where our variables show up so now let's start defining operators so plus is a symbol it's going to have a binding power of 60 and it will have a lead and its lead will take its first member as whatever was on the left and then call the expression function to get whatever is on the right and we'll set the arity of this of the token to binary and return it we can do asterisk exactly the same way we still have a you know the only difference is it's asterisk instead of plus at 70 instead of 60 but otherwise they're exactly the same whenever we have things that are that similar we know we there's a chance to do something smarter so I'm going to create an infix operator or an infix function which I'll use to define my infix operators so it's going to take an ID a binding power and an optional LED function if we're not passed a LED function then it'll take a it'll create a default LED function which is the one which takes the thing on the Left calls expression and takes the thing on the right so having this infix function I can now start defining my infix operators and again it's looking declarative but it's it's actually functional so I this says that my Plus operator is looser than my multiply operator but tighter than my comparison operators by the way I all my comparison operators are the same level of precedence in your favorite programming language do they all have the same precedence anybody know they probably don't in most languages the inequality operators you know less-than and greater-than don't have the same tightness as equality again another opportunity for error the ternary operator is a special infix operator because it takes an additional thing afterwards so we specify that by passing in a function which will parse those which looks like the others it will take the thing on the left get an expression to get the second thing will then match the colon and then get the expression for the third thing and set the arity to ternary in most of our languages we'll have some things which associate left to right but that's not confusing enough so we'll also have things that associate right to left so if you have a number of operators with the same precedence level the tie gets broken by a directionality and some will go one way and some will go the other so an example of things which go the other way our assignments assignments always get evaluated from right to left so we'll create an assignment function which will help us to specify those things and we can also do some deeper checking here so it can make sure that what's on the left of the assignment is an L value that can be a difficult thing to determine syntactically because the l value rules are more complicated than the regular expression rules but i adding special cases in this system is really easy so I can just do that checking here instead of trying to do it chromatically and then once I have that I can then go ahead and create or specify my assignment operators I do prefixes the same way prefix uses an odd because there's nothing of interest on the left of a prefix so having that I can now specify plus minus and so on my prefix operators the parent operator for grouping is slightly special so we pass in passing a function so it will parse an expression look for the closing brace and then return the expression when Pratt wrote his paper he was thinking about expression languages and expression languages are great but we don't like those they're not emotional enough we prefer to have statement languages we want to have statements and expressions and his language didn't allow for statements but it was easy to adapt the system to do that so I came up with a first null day notation if the in the statement position you can have a there are certain nods which only make sense in that position and so I call those things Fudd's or first Naldi notation and I can have a statement function which will allow me to declare artistís to create the symbols that will be used for statements it will first look to see if the token has a FUD and if it does it will call it otherwise it will assume it's an expression statement and then I'll look to see what kind of expression I got in most of our languages any expression can be a statement which is crazy I think the only two expressions that make sense in statement position are assignments and invocations and anything else is likely to be an error but since B at least we've allowed that but I think we shouldn't and then finally it'll match the semicolon and it's done very often will want to have more than one statement so statements allows us to parse a list of statements and put them in array and we can tell if a token is likely to be the next statement if it has a nod or a thud if it does that it's probably a statement if it doesn't then it probably isn't we can then parse blocks a block starts with a curly brace and then will contain some statements and then a closing curly brace okay and then we can match we can start defining our statements so a statement will take an ID and a fudge function and we and so we'll get a symbol for that for that statement and assign the fund statement to it so here's an example of an if statement we first skip the decorative curly brace or decorative pairen we parse the condition we match the closing brace or closing perón we parse a block then we look to see if there's an else if there is then we get the the other consequence and then we set the arity to statement and then we're done so in the box is an if statement that is the statement that this expression or that this function is going to match but to show you some of the flexibility we have in the scheme suppose I want to parse or have a language which looks like BCPL at least in its if statements so this is the code for parsing BCPL like if statements and in the box is an example of such an if statement basically taking the parents off this is sometimes called Paran free and at various times it looks like this might make it into a future addition to vecna script but so far it hasn't mostly because public response has been so vocal people love that parent and it looks like we can't remove it Oh or if we want to make it look like Algol 68 you know in the box is an algal 68 if statement and this is a code which will match that style of this if statement basically just by matching on the Phi then this is the key to the whole thing this is the expression statement you call this with a binding power and that gift returns a tree which represents that expression and this is the single most brilliant function I've ever seen in my whole career in this Pratt has taken all of the theory of parsing and all of its complexity and reduced it to a simple loop so when we enter this we first call the nod of the current token and then as long as the binding power of the next token is greater than the right binding power that we passed in we call Leeds and we keep doing that until we're done that's it all of the complexity of parsing is in this simplest of functions so when we are doing stuff right it's when we've taken a whole lot of complexity and removed it all and just come up with a simple thing and I have never seen a better example of replacing complexity with simplicity than this I love this this is my most favorite function in the whole world and all this works so we want to take that statement and produce that tree from it and what I showed you will do that and in fact we could look at it as you know this is the data structure that will produce and we could then take that data structure and give it to a code generator and give it to an optimizer give it to an interpreter that an interpreter can execute this stuff directly um and this is the trace that that codes going to to do and so you've seen every one of those functions and those functions weren't doing anything very complex there's not much code going on so this technique is really fast because it it's hardly doing anything it's just going around comparing numbers and building trees this is another example of a statement this one because of the difference in precedence that tree is balanced in the other other way this is the data structure that represents that tree and this is the parse that generated that one and again it's really simple that it's really fast there's hardly anything going on so let's top-down operator precedence it is easy to build parsers with it it is really fast because it does almost nothing it's in fact fast enough to use as an interpreter um it's dynamic you can build dsls with this in fact you can build dsl x' inside of another application because it's really lightweight you could also build extensible languages you can add you could have functions in your system which add new capability to the structures that you're using to build your language as you're running the language so you can add stuff so one view of application development is you should first design the language which is the ideal language for writing your application and then write your application in that language this allows you to easily do that we can also get rid of reserved words reserved words are bad for programmers because you have to remember this list and sometimes that gets in the way of the things you're trying to express and it's bad for language designers because if you discover later is something that you needed to add to the language very often you can't because people are already using the best word so because this technique is so dynamic you're not freezing all of this complexity into static data structures it's all dynamic you can have policies like any word can be used as a variable name but if you use a variable name and a function that name cannot be used for any other purpose of the function and having such rule means you don't need reserved words anymore so it's good for programmers because they don't need to know or care what the reserved word list is it doesn't exist and it's good for the language designers because they can add new stuff to the language at anytime and never have to worry about conflict because anyone who's already using the name is not going to be using the new feature so who cares um finally I have some advice for language designers I think we should all be designing programming languages I think it's a great thing it's a lot of fun it's the earliest of arts and it's something that we can all enjoy so first I'd recommend that you try to embrace minimalism in your language try to have conceptual minimalism also notational minimalism as much as possible but don't get cryptic try to provide as much clarity and error resistance as you can one of your primary goals should be to try to make your language confusion free confusion is the source of all errors and so if we can avoid sources of confusion our languages we're going to have an easier time try to make it readable and I find there is a huge amount of misunderstanding as to what readable means I think readable means that it can easily and correctly be understood by a reader most people understand readability to mean I like the way it looks and that that's a completely different thing innovate we already have a lot of Java like languages so if you find yourself writing coke bottle coke bottle equals new coke bottle walk away from the machine we've already been there that grounds been really well covered try to find some other dimension on which to innovate select your features very carefully don't just take every feature you ever saw and try to put it into your language even if they're all really good beware or beware of the idea that some something is sometimes useful you know this feature is sometimes useful so I want to put it in my language I defy anybody to suggest anything real or imaginary which is not sometimes useful even things which are ridiculous in dangerous and nasty those things are sometimes useful so if that's the only criteria you have for new features you don't have a criteria so try to come up with better reasons for why you're including things avoid universality there have been a lot of attempts at making the one universal language the language that's good for everything that doesn't work what seems to work better is design a language which does one specific thing really well and chances are there are a lot of other things that we'll also do really well but at least you'll do one thing really well and that's better than a lot of other languages can claim help people to manage complexity dealing with complexity is the most difficult thing that we do so finding the structures for leverage which allows us to do that is really important and promote quality as much as possible we want to make programs that are really good make new mistakes don't make the old mistakes again inevitably you're going to have to make some old mistakes because you can't innovate on every dimension at the same time but be really cautious as to what old mistakes you cannot propagate for example Ken Thompson I think is one of the smartest guys to have ever lived he has pushed our art so far ahead but I think he had terrible to taste as a syntax designer but he understood how we think or maybe we've been so influenced by how he thinks that we cannot see the many mistakes that he put in to see and those mistakes been propagated into virtually everything that's happened ever since when we don't have to keep doing that anymore the thing that I like best about CoffeeScript is one of the new JavaScript variants it's basically exactly the same language as JavaScript except it doesn't have the beef-flavored syntax it has a different kind of syntax instead and it's great it used to be said that if a new language didn't look exactly like C it had no chance of catching on and that doesn't seem to be true anymore we're finally breaking that after so many years so you know do that let the language teach you I recommend to people learn as many languages as you can because when you get deep in a language it can teach you and your language can teach you to embrace Unicode so most of our languages are stuck with the ASCII set you know we have the ASCII operators Unicode is full of thousands of amazing special characters which could be really good ineffective for communicating what we want to do in our programs we're not using those because it's can it's believed that most programmers are not smart enough to be able to get codes onto the screen unless there's a picture I let on a button that they can push I don't think that's true I think we can actually puzzle that stuff out so consider that you certainly don't want to go crazy and you can certainly go crazy if you start putting away too many goofy characters in but we don't have enough bracketing characters you know we've gone to using angle brackets which was maybe a mistake because we don't have enough other things but you know there are those wonderful Japanese corner brackets which are great and and the the brackets that look like that there's a lot of opportunity in for our languages leap forward of course don't be doing the same thing and they're forgotten treasures you know we've we're very good at reinventing the same basic sequential language we're not our new languages are not that different from Fortran in terms of how they're organized and what they do but there are things that we left along the way which are not well represented in our current languages which are worth revisiting like state machines and constraint engines other ways of thinking about how you do things that go beyond just one thing after another exploit parallelism one of the biggest challenges we have is what to do with all of the computing capability that's in front of us we're stuck with all these sequential programming languages but as we go more and more parallel they become less and less effective for what we're having to do in particularly in distributed programming we now have clouds and we've got lots of cores and we don't know what to do with them so I think that's going to be the next interesting thing for our languages to deal with is how do we take full advantage of big big parallelism and then finally have fun it really is a nice hobby and I think everybody should be doing it oh and one last thing let's get rid of these and don't do it the way JavaScript did the way JavaScript did it was it left these in the grammar but allowed you to leave them out by using an inner recovery mechanism so if it goes parsing it gets an error it'll take a nearby line feed turn it into a semicolon and then back up and try again it's like yeah don't do that it's pretty easy to come up with a semicolon free grammar do that instead finally if you want to know more about top-down operator precedence there are two projects on github which are both freely available the first one is a simple top-down operator precedence parser for simplified JavaScript written in simplified JavaScript the other is chess lint which is complicated javascript trying to do just the good parts which is bigger than simplified JavaScript and then for more explanation as to how it works there's a chapter in beautiful code which describes its operation so that's what I have for you this morning thank you and good night exciting talk I was I I struggled to type in a question trying to follow the talk I stood at the same time but we nonetheless do have three questions that you guys put in and given that we have very little time I let Douglas choose one of the questions maybe two or depending on along the answers are isn't language designed just a special case of API design no I don't think so I think with API design you generally have a more specific idea as to what's going to happen and how it's going to be used whereas programming languages are a much more general abstract tool the challenge for programming design is with each generation we want to level up you know so with Moore's Law the hardware gets the level up every two years or so right they double we only do it every twenty years or so so we are much slower in figuring it out and most of that slowness is due to our own stubbornness and addiction to style you know it took us a long time to decide to get rid of go twos because a lot of people thought go twos looked really good and didn't understand that go twos we're making programming harder and we're at a similar place today I think with classes and some other concepts so classes are great they've pushed the state-of-the-art ahead tremendously but have also locked us in place and so they're preventing us from going on to the next thing which is going to be even better so those are issues that you don't have at 8:00 in API design that's a completely different space you

Channel: GOTO Conferences

Views: 15,850

Rating: 4.8974357 out of 5

Keywords: Programming Language, Syntaxation, Douglas Crockford, GOTO, GOTOcon, GOTO Conference

Id: Nlqv6NtBXcA

Length: 49min 39sec (2979 seconds)

Published: Tue Oct 27 2015