No links, tips, or picks this week
No links, tips, or picks this week
And, cool, so during the show, if you're watching live, you can go to Twitter and if you have any questions, use the hashtag #jsAirQuestion and we'll address your questions at the end of the show -- live during the show.
KENT: And Brian Lonsdorf.
KENT: Kyle Simpson. [Chuckles] He made a finger gesture. I'm not quite sure what it was but I'm sure it was awesome.
BRENDAN: No gang signs, please.
KENT: And then we've got Lin Clark.
LIN: Hey there!
KENT: And Matt Zabriskie.
KENT: And Pam Selle.
KENT: And Tyler McGinnis.
KENT: Do you mind talking about that startup? I have not heard of that before.
BRENDAN: [Chuckles] We're still stealthy so you'll have to wait. But there's a MailChimp form you can enter your email into there. And there's an Easter egg, if you are diligent about view source.
KENT: Oh, snap. I'm pretty sure that we're going to get a lot of those Easter eggs uncovered. [Chuckles] That's interesting to me.
BRENDAN: Who knew? [Chuckles]
BRENDAN: Sure. So I'd have to go back a little bit in time. I was at Silicon Graphics (SGI) in their glory days from 1985 (before their IPO) to 1992 when they become very big company. And I left but I knew some of the early people and the Founder, Jim Clark. And so when he did Netscape, he and one of the SGI people, he picked up, Kip Hickman tried to recruit me in the spring of 1994. And like a big idiot, I said, "no, I've got to keep working on my start up," that I did in between SGI and Netscape called MicroUnity, which you might find made some references to. George Gilder wrote about it in Forbes ASAP. It was one of those early mid-nineties, do-everything rock band startups that was trying to innovate in semiconductors to software to beyond.
And of course, as Clark pointed out to me, when I joined Netscape, it was likely to fail because when you do ten hard things and the odds ratio for each of those ten hard things is independent, the total odds ratio of success by the multiplication principle, is the product of all those fractions. So one in ten odds for each of those things: semiconductor, new micro kernel, new instruction set architecture, new digital signal processing, analog and digital circuits on the same chip, new user code model for doing what we now think of as superscalar and SIMD, that's like one in tenth of the seventh or tenth of the eight odds of success. So MicroUnity was not going to work. It had a lot of patents so it still made a lot of money for some people -- not for me. But I stayed there in 1994, like an idiot. And when Netscape friends called again in 1995, I went.
And the reason I went was because they said, "Come out to the coast! Do Scheme in the browser." (I was already out in coast actually but I wanted to refer to Die Hard there.) [Chuckles] So I came to Netscape to do Scheme in the browser but when I got there, they said two things to me. They said, one, "Oh, we can't hire you into the client, into the Netscape navigator team because we're short of head count and we'll hire you into the server team instead so you can work on HTTP/1.1" (or what they hoped became 1.1). Second, "Oh, we're doing a deal with Sun Microsystems to integrate Java into Netscape, so we're not sure we want to do Scheme in the browser anymore." And that was kind of a drag.
And critically, Bill Joy of Sun Microsystems and Marc Andreessen, co-founder of Netscape said, "Yes, they will understand because it's like what Visual Basic was to Microsoft Visual C++" in the Windows stack at the time. We need a more accessible, easy-to-use language you can buy by the yard, you can start using line by line. You know, anybody can program in it, you don't even need to be a programmer. It's very approachable. That's for the order of magnitude of too large a population of designers and amateur programmers who are critical in an ecosystem to building, let's say apps or web pages.
And so Mark and Bill Joy got it. And that's why I did the ten days of crazy implementation to prove that it was a viable idea. They also gave me another constraint which was "Oh, we want to have this in the server side for our LiveWire (sort of PHP-like thing)." So I'm thinking that it's programmable in the Netscape's sever the HTTP::Daemon then that can hit a database, put some data through a template and generate some HTML, have a little bit of scripting on the server as well as the client side. They wanted an engine for that and that's what the Mocha engine was. And particularly, that's why I wrote a bytecode interpreter and compiled all the bytecode from source.
KENT: Awesome. [Chuckles]
PAM: So I have a question, Brendan. Hi.
PAM: So like many functional programmers, you wanted to write Lisp and then they wouldn't let you. So what do you think about ClojureScript and bringing Lisp into the browser?
BRIAN: I have a question too. I was wondering if this was your first crack at writing like a bytecode interpreter. I heard you had hung around Stanford reading white papers on the subject. But you know, is this your first try and it just worked?[Chuckles]
BRENDAN: No, I was a Physics major for three years at Santa Clara University. And I was frustrated because this was 1979 through ë82 and it was an awesome time in computing, right? The Apple II was born in the late seventies. There were still a lot of people building computers from scratch. And yet I was doing physics and my department chairman would say, when I asked him about summer job options, he would say, "Have fun mowing lawns" [chuckles]. So also, physics, I think stagnated a bit. It's a different topic I won't get into here.
So I ended up being a lab assistant on DEC-2060 and VAX systems (which I loved) and UNIX. And I switched to Math Computer Science in my fourth year and I started writing, immediately I loved the theory of formal languages, parsing regular languages, regular expressions, lexical analysis and parsing and compiling. So I started writing my own parsers, compilers, parser generators. At the time, in the early eighties, there was a sort of an arms race to generate efficient parsers from certain kinds of grammars, the LALR(1) grammar in particular were hot. And I wrote the parser generator. And I did a lot of hobby implementation of programming languages.
And I was inspired throughout the eighties by Brian Kernighan and P.J. Plauger (I think his name is pronounced). And Kernighan and Pike did a book on UNIX where they had a little toy language called HAWK, a classic Rob Pike language. And even before Hawk, there was AWK, A-W-K (Aho-Weinberger-Kernighan, I believe). And I had the source through academic or later through SGI commercial UNIX licenses. So I studied all these things. I studied all the ugly C code [chuckles] that was used to implement these things. I was a C programmer. I was a kernel hacker as well as a programming language buff. So I have implemented a lot of hobby languages.
And then at SGI at some point, after doing a lot of kernel hacking, we realized you could do a network management software stack on Ethernet (10 megabit Ethernet at the time), and one of the things you wanted was to turn on promiscuous mode catching packets on the net and dumping them. So I wrote a packet filter language that could be efficiently compiled with the kernel. It was a Berkeley Packet Filer in Berkeley Unix that used bytecode. I wrote something simpler with to behest one of my mentors and colleagues that compiled a general expression language over the header fields of the IP protocol, the TCP protocol or UDP into a short set of Mask and Match sort of bitwise filters. And that was fun. And that turned into a product the SGI sold. And I ended up running another compiler for that that took a general protocol description language that I designed that could express TCP/IP or AppleTalk or DECnet. And that allowed my colleagues at SGI to write protocol descriptions in a higher level, declarative language. And my compiler would turn those into decompilers, pretty-printers and packet filters for those languages, those protocols. So this turned into a network management product.
BRIAN: Right on.
KENT: Brendan, you're on a totally different plane from where I am. I feel like so low right now [laughs]
PAM: Kent, I mean, running a compiler is within your reach. [chuckles] You can do it.
BRIAN: Actually, you end up getting to be a popular design pattern these days with all the functional stuff like DSLs coming back and everything. It's exciting.
PAM: Yeah. We're going to write you a DSL.
BRENDAN: That's right. The people who use Scheme for pedagogy encourage people who learned it to early on, write their own language processors. And I think it's great.
LIN: So I have a question. If there were a parallel universe where you were able to have done Scheme in the browser, where would the web be in that parallel universe today?
BRENDAN: So I don't know. I mean, there's so many variables but it might not be that far from where it is. The syntax may not matter as much. Scheme, you know, is beautiful and minimal and a very few special forms. And the flip side of that is you end up writing a lot of industrial Scheme code using macros. So you need a hygienic macro system and then you end up writing macros in a way that may not be portable to other environments where they don't load the same macro libraries. So you have to include macros I think in order to get the full effect.
Things like call/cc (call-with-current-continuation) which is like functional go-to, it is where you capture your current program state and then reify it as a function that can be called to jump back to that state. That's awesome but it's often to low-level, so people write macros and Scheme on top of call/cc, and those macros become much more understandable and easy to use correctly across a large scheme of programmers. And then because Scheme is not sufficiently standardized, let's say, (there are standards, obviously but different industrial uses of Scheme I've heard about. I've never worked directly with Scheme) end up reinventing the wheel differently. And it's sort of like C in the early days; you had to have a standard library, stdio, stdlib, what became stdlib and you had to have them well-implementedÖ and they sometimes didn't agree. Back in the 80s, it was rough. Things were different. Things did not agree.
BRENDAN: Oh, [chuckles] so, first of all, there were clearly mistakes. I worked for ten days without much sleep. And even then, I made mistakes afterwards based on early inside Netscape user testing. So I've talked about this a lot in my writing and speaking. There were mistakes for sure. And you know, you readÖ Dennis Ritchie wrote a very humble and educational history of the C language and he admitted there were mistakes and sort of path-dependent errors or consequences of evolution, like I mentioned the bitwise and logical operators being adjacent in precedence. And you just can't help some of these things, so it's the kind of absurd to say no language should have mistakes. All languages have mistakes, including our fine English language; a Germanic languages that's heavily been influenced by of Norman Conquest of 1066, right? English is an ongoing mash up between different languages. And it has irregularities and what look like mistakes to people who speak other languages.
So you're right, there was some intentional design and there were some mistakes. I mean, the one I talked about rather explicitly like on Stack Overflow is that the double equals operator will, given two operators of different types, will try coercing one or the other or both to a comparable type. And that can lead to trouble; it makes that double equal operator not be an equivalence relation in the mathematical sense, it's intransitive in particular. There were other problems to do with NaNs that I won't get into but that's kind of corner case; you know, signed zero, negative and positive zero.
But it remains, that you know the "1" == 1. And that's intentional but not in my original design. That was after the ten days, this team that was doing LiveWire, the server side embedding of my engine were dealing with a lot HTTP headers and form data in HTML forms that had numeric strings and they wanted to make it easy for the programmer to compare "1" to 1. And like an idiot, I gave them what they wanted. And that's why I changed from my original design which was very C-like, that said, "if the types differ, the thing is not equal. Forget it." And that's what led to the triple equal operator.
KENT: So Brendan I think that you called yourself an idiot at least three times on this podcast. [chuckles] That makes me feel a lot better, I guess, about myself, but [chuckles] I don't think you're an idiot.
BRENDAN: I don't mean to be pretending to be humble. I think what I did then in particular was trying to please people by doing things that turned out not to be sound. And you know, maybe in the long run, they were the right decisions but I think it's better to be strict than sloppy. And it's better to make people write type conversions explicitly than implicitly. So in that case I was an idiot [chuckles]. Otherwise, not.
KENT: Makes sense. It's actually very interesting.
PAM: Yeah. Well, I wonder about you said you did some early user testing and it sounds like a few things might have been going on there, in that, you know, classically in end user testing, you give people what they want; it's not necessarily what they need. And then the secondary thing of oh, how enterprises can destroy the best-laid plans with, you know, everyone's opinion in the opinion wars.
KYLE: Since you're specifically on the topic of strings to numbers, I wonder if you remember or could recount for us one specific case which is that the empty string, when coerced to a number, becomes zero. Do you know what the genesis for that or the reasoning behind that was?
BRENDAN: Yeah, I think as I mentioned, Perl does that too. And a lot of languages that deal with form field input do with do that because they want to allow the shortest possible input to turn into the number zero without an error or without nagging the user to type zero. And so you end up, in a lot of cases, with a defaulting sort of a union type where it's a specific kind of refinement type where it's either number or the empty string which means zero. Obviously, I went further and I let any string to convert to a number and I say that's a problem. But that particular case, it was quite popular and it remains in a lot of languages.
BRENDAN: Great question. I've talked about this at least since this past summer in Prague. I talked about some early single page applications built in 1995 and 1996. Netscape 2 was a real platform push as a browser. It wasn't just a browser; it was a platform that scared Microsoft. Microsoft had already offered too little money (I think $100 million or something) to Netscape in late 1994 and then Netscape principals like Jim Clark and Jim Barksdale said, "Get out of here." And then they knew that Microsoft was coming after them, especially when they launched Netscape 1 later in fall of 1994 and started getting huge traction. And it had [chuckles] you know, what in hindsight, was very insecure Secure Sockets Layer for ecommerce. But it was obvious that what the web was going to sweep aside proprietary systems like AOL, CompuServe and Microsoft's prototype sort of knock off those system codenamed Blackbird.
So people like, somebody named Bill Dortch who I've recently reconnected with on Twitter, he had a company called hIdaho Design designs (like Idaho with the ëh' in front) and he built single page applications. And the one I showed this summer in a talk, it's in the web archive from 1996, webarchive.org, it's an art gallery of I think mostly Idaho-resident artists' sort of western art. And it's totally a single-page application like what we would build today except it's frames and framesets which we do not use, now we use iframes or divs or whatever, table layout. And it had its own data that it downloaded that was a catalog of the artists' works. There was no JSON then because I didn't have time until '96 to start doing JSON or what became JSON, which became standardized later in ES3. But you could call "new catalog" or "new artists" to call your own constructor, which would then assign to "this.title" and "this.year" and "this.price" and "this.(whatever description)" to create a catalog of artists' works, including the images that showed the works. And so there was this entire downloaded data set for the art gallery and the single-page application allowed them to navigate through it. And that was all in 1995 and 1996. So it didn't start with Ajax in 2005; this stuff was actually prototyped in ë95-ë96.
TYLER: So going back to those first days, did youÖ I've always wondered, as someone who's kind of doing something that's going to, like, fundamentally change the world, did you realize that this was gonna to be big? Did you have like any thoughts that this was going to be big or was this something that's kind of like something that you were doing to fulfill like a job task or something?
And Walter Smith, you know, did it and the Newton failed, right? It was the joke in the Simpsons episode where the bullies at the school assembly hear the nerd, Martin, asked some suck-up question to Principal Skinner and one of them says, "Take a note on your Newton: ëHit Martin later.'" And the Newton's handwriting recognition was so bad, the Simpson authors were joking about it because he writes, "Hit Martin later" and it gets translated to "hi Martha bake" [chuckles] And then the bully gets so mad, he chucks his Newton at Martin the nerd and hits him on the head with the Newton. Newton failed and Walter Smith went on to work at Microsoft, I think. I don't know what he's done. He's probably done very well. But he didn't keep working on it.
KENT: Well, I'm glad that you're here. [Laughs]
KYLE: Since you're talking about transpilation, so, we saw with ES6 that most of the features in ES6 were expressed in terms where they could be pretty directly transpiled to ES5 equivalent. But I've seen several proposals for ES2016 and beyond that are suggesting features which are basically whole new primitives that can't really be transpiled to older versions. I'm curious your perspective on the direction the language ought to takeÖ
PAM: Can you give an example of such a primitive?
BRENDAN: Sure. So by the way, in ES6, there are also not just proxies but modules have aspects that can't be expressed in ES5. And things like super in classes, class hierarchies. But you know, in every language, there is what you might think of as the kernel semantics; the irreducible set of primitives. And then are affordances built around those primitives that are composite or you know, composed of primitives together. That's natural. You need a language to be usable. If it only has the primitives like Scheme without macros, it's pretty hard to use. And that's why macros are used (like I said early on) to make affordances usable, APIs, veneers on top of things like call/cc in Scheme.
But I didn't do that. I did functions and they were big fat composite, pseudo-primitives, quasi-primitives. And I did it because I was in a mad rush. And I did objects similarly too. Objects could be like dictionaries in Python but they also had a prototype chain, so you could get dictionary namespace pollution from the prototype, which everyone knows about. And that was powerful on the flip side because you could use the prototype to add methods and share constants (mostly methods) and do sort of classy or even purely selfish prototypal programming.
KENT: But how do you draw the line then between saying like you're saying adding those features in the language for those that, you know, those language affordances for various use cases like the self-hosting and the WebAssembly stuff. (So I'm jumping forward now because I know we're going to talk about that.) How do you draw the line and say, "It ought to be added to the language" or "here we have this other side door, maybe some of that stuff should come in through that door instead."
DAN: I have a question about the future. Can you imagine how an application might look in ten years' time? Like, what is it able to do with threads and so on? How does that fit together?
BRENDAN: Yeah, some things are immortal; like UNIX is immortal. In the old days, UNIX was processes, not threads but we had this pool of threads. And threads get overused but they have some uses and I'm thinking of game engines that you know, have to have a big scene graph that's shared among threads that pragmatically farm out the work across cores. And there's no a priori, no declarative way to say to say, "This part of the screen graph is for this thread and this part is for that thread or this core and that core." You end up doing it dynamically on the fly. You use sort of work-stealing schedule and other techniques. And then you parallelize using SIMD and of course, GPU through OpenGL or WebGL.
And a friend in Mozilla said, "WebAssembly is going to be in the hardware, man." And that I believe. So in twenty years, I bet we'll see some kind of flattening of WebAssembly, optimizing, I don't know if it will be ARM or Intel. I don't want to speculate that far or their licensees. But this stuff is going to be here for the long run and it's going to map to all the hardware features ñ which means threads, SIMD, GPU, you know. Even OpenGL 4.5 or whatever, as powerful as it is, it doesn't quite get all the computational power in the GPU, the teraflops of parallel floating point units to things like SPIR-V and Vulkan coming out of the Khronos group that are worth looking at that go well beyond the OpenGL or the subset that is WebGL, which is itself is trying to move to WebGL 2.0 based in OpenGL ES3. Just extrapolate that conservatively and you'll see a world where portable safe code that doesn't have array buffer overflows or stack overflows or obvious security problems can [?] the entire functionality of your awesome hardware.
KENT: Hey, Brendan, thank you so much. I think we are winding down on our time and we wanna be respectful to you, the panelists and our viewers, so I think we're going to start wrapping things up. We do have quite a few questions on Twitter for you, so the discussion is not over [chuckles]. So the first question that hasn't been discussed necessarily during the show is from Jason Trill he asks, "What are your thoughts on static typing in JS? Will we ever get static typing in the runtime?"
The other thing I would say (and I said this in dotJS) is we might end up writing for a standard type system but it might not be in the browser, it might be a Tool Time type system just like TypeScript and Flow. And that might be enough because it will tell you when you misspell a property name. It will tell you when you made other obvious errors. It will find even more sophisticated errors using its more sophisticated control flow analysis. And that could be a separate spec from ECMA 262 and that could be enough.
So it isn't clear that we can actually benefit by putting the static checker into the browser into the runtime. It might be best at tool time. It's also the case that when you add the static checker, just like when you add other static metaprogramming like macro processing into the browser, you're going to slow down the browser on certain benchmarks. And no browser vendor wants to slow down on the benchmarks, so it's going to be hard to add the static checker or I would say even macros like SweetJS to the browser, but they might end up being viable Tool Time standards.
KENT: Absolutely, yeah. And it's totally enabled all these cool tools that we use that have totally changed the face of frontend and backend web development, so I'm excited too. Next question, I'm so sorry I can't pronounce his name "shaneckel" he asks, "Do you have any opinions on Swift lang or more generally how you think the divide between apps/browser will go?"
KENT: Cool. I am really sorry, there a couple more questions. I just don't know if we're really going to be able to get to them all and still wrap things up. [chuckles]
BRENDAN: Three more minutes. I have three more minutes.
KENT: [Chuckles] If you don't mind staying on, I don't mind keeping it. Anybody can jump off at anytime if they'd like to but I really would like to respect everybody's time. So I'll just askÖ I think there's a question somebody asked on Google+ Hangout page that I think would be really interesting to hear you answer. The question is "Where do you see JS in the next five, ten or twenty years?"
BRENDAN: So you know just getting ES6 done and still not implement it fully, though with Chakra which is open sourcing Chakra Core is like +90% done. It's going to be a big deal and it will take time for people to absorb that. But every time I go to conferences more and more hands go up when I ask who's using BabelJS. That's going to go for a while, you know, ES7 async function, async await, great affordances that people want. Maybe the private data stuff, we'll see. We'll make sure it isn't the wrong thing.
KENT: Cool. That's a good tip. Thanks, Kyle, for bringing that up. And I think that's probably a good one for us to wrap up on. So we're going to go ahead and we're going to speed through these tips and picks. So if you have more than one tip or pick, just pick your favorite and we're just going to do one. And then in the show notes in the audio podcast, I'll put all of your picks so don't delete them from the doc but just on the show, just pick one. So, Brendan, why don't we go ahead and go with you. I hope we've prepared you for this a little bit but do you have anything in particular that you'd like to pick or any tip that you'd like to give to people?
BRENDAN: That's a good question. I mean ESLint is a huge and we're using it and there's a great talk by Elijah Manor about how to use it well that's on YouTube.
KENT: Sweet. If you can maybe find that link, we'll add it to the show notes. ESLint is the bomb. Cool. Lin, I think you're up next.
LIN: Sure. So this week, I was working with some folks who were using web pack for the first time. And they were looking at a larger-than-expected file size coming out of webpack. And I suggested using dead code elimination, which was new to them and that reduced their file size in half. And so I just wanted to make sure that people know that there is a thing called "dead code elimination." It basically eliminates the code that your program is never going to touch anyways. So check that out to see if your tool has dead code elimination. And my pick is actually Dan Abramov's series on Redux on egghead.io. We are using redux on Firefox dev tools, and so there are a lot of people who are new to it on that team and those videos are going to be great for them. So thanks, Dan.
DAN: Thank you!
KENT: Awesome. Brian, why don't we have you go next?
BRIAN: All right, I guess I have an obligation to shout out to ForwardJS in February. You know, Kent, you're speaking, right? [chuckles] And we got Kyle coming and I think Tyler will be there and you know, everybody else should show up. So we should do one of these there. That's all I got, ForwardJS in February.
KENT: Cool, thanks. Dan, what do you have for us?
KENT: Nice. So was that like an anti-pick for Mercurial? [chuckles]
DAN: Yeah. [chuckles]
KENT: Nice. Kyle, do you have any picks for us?
KYLE: Yeah, just one and it's very timely. It's happening like maybe even today in some of your cities. Hour of Code. If you're not aware of that, you should go check out, go look up Hour of Code. It's an initiative to teach mostly targeted to high school students but to teach people about coding, an opportunity to volunteer your time to help somebody else learn. So I think everybody should to take that. I especially would remind you that you don't really know something until you've taught somebody else. So that's a great way to do it.
KENT: That's awesome. Really solid advice. Matt Zabriskie, what do you got for us?
KENT: Awesome. Thanks. Pam, what do you have for us?
KENT: Cool, thanks. Tyler?
TYLER: Two picks: I just added my second one. So, the first one is going to be Matt Zabriskie's beard because it is looking really good today. Second one is this really cool game called Flexbox F4oggy. Basically, it allows you to learn Flexbox as you're playing this cool game. So I don't know who made it, but it's awesome. So who ever made it, thank you.