Live data from Hacker News

Ask HN: What's the best technical talk you've heard?

news.ycombinator.com

181–190 of 202 posts

Re: Ask HN: What's the best technical talk you've heard?

#181

Cliff Click on Wait-free hashtables and another one on modern Hardware and Processor Systems.

Probably this one: http://www.youtube.com/watch?v=HJ-719EGIts

Anything from Cliff Click is quite good. This guy has a very deep understanding of compilers, virtual-machines, CPUs, and their interactions.

A JVM does that? http://www.youtube.com/watch?v=uL2D3qzHtqY

Java on a 1000 Cores http://www.youtube.com/watch?v=5uljtqyBLxI

Re: Ask HN: What's the best technical talk you've heard?

#182
post #154

Earlier quoted context omitted.

This is a great talk, although maybe a little bit too precious (but this is common to a lot of [security] conference talks so I don't hold it against her). Pushing people towards using more formal methods to generate and accept protocols is always good. That said, I thought the argument against length fields was somewhat.. weak. But maybe I'm misunderstanding the context. The question at the end was not answered sati…

As I understood it, the arguments against using an unbounded length field is that it makes the language recognizing it context-sensative. When processing some inner payload of a data packet you need to carry around the state of outer context-sensative protocol layers to make sure your inputs are well formed. The fact that it is trivial to maliciously craft the length field makes it cheap for the attacker to try to ex…

Aha, that was it. I was assuming you'd bound the length. :-)

Re: Ask HN: What's the best technical talk you've heard?

#183

Cliff Click on Wait-free hashtables and another one on modern Hardware and Processor Systems.

I think the Cliff Click tech talk you are looking for was at Stanford in 2007. He covered both his wait free hash table and scaling on modern systems, specifically Azul Systems in 2007.

http://www.youtube.com/watch?v=WYXgtXWejRM

Re: Ask HN: What's the best technical talk you've heard?

#184

Earlier quoted context omitted.

"And observe that if I forget to tell the computer to save my work, it loses it!" furious scribbling in the audience as everyone takes notes I'm so glad we're finally getting away from this paradigm after four decades. For example, the iPhone notepad (and now Mac TextEdit) doesn't wait for a cue from the user to write the few dozen bytes of new input to persistent storage.

After some incidents in my shool years, I've noticed that I unconciously tend to hit ctrl-s every few dozen keystrokes without even noticing it. Good software doesn't lose anything ever, but even with "average" (i.e., unacceptably bad if you think about it critically) tools I've had sudden power cuts where I lost just a few words because of this habit.

I realised I have passed some kind of milestone - I read that and thought "search"

Thank you :-)

Re: Ask HN: What's the best technical talk you've heard?

#185
post #9

Simple Made Easy changed how I think about constructing software systems of any kind. It provided me with a strong vocabulary and mental model to identify coupling and design with a more clear separation of concerns and focus on the output rather than the ease of development. http://www.infoq.com/presentations/Simple-Made-Easy

Don't know, I like Clojure and Hickey, but I've never got much out of his talks. Seem more like a series of really obvious ideas and some platitudes thrown in for good measure.

Really, I nose-snorted coffee over this one:

  - everyone knows you cannot keep up the pace of a sprint 
  over a long distance race - so they solved it by running 
  a long distance race but just firing a starting pistol 
  every 400 yards - and we're off again!

Re: Ask HN: What's the best technical talk you've heard?

#186
post #180
post #175

Earlier quoted context omitted.

I agree with the problems, i.e. that web standards and implementations are messy, but not with the solutions. It just seems like a big pipe dream -- "oh I wish we could start over from scratch, rewrite the web, and make things clean". Will never happen. I also don't agree in 2013 that moving say HTML5 to a VM is a good idea. There's nothing stopping anyone from releasing a VM now. You could release a new VM and an ap…

Do you think HTML+CSS+JS+(...) can form the basis of all future computing? You have to apply the same standards to both sides. It's hard to be perfect, yes, but it's easy to do better than the web mess. If I had to choose between HTML+CSS+JS+(...) and either the JVM or CLR as the basis of the future of all computing, I would definitely choose one of the latter options. Both the JVM and .NET VM would work okayish, tho…

HTML and company aren't the basis of all future computing, but they or their non-Turing complete descendants absolutely will exist in 100 years. They don't exist for lack of imagination; they exist for timeless and fundamental reasons.

Do you think plain text will exist in 100 years? If so then it's not that much a stretch to say that HTML will. It astonishes me that people think that only code, and not data, will be transported over networks. That seems to be what you are claiming -- that it's preferable to transmit code than data in all circumstances?

The argument isn't symmetric because I fully believe that VMs are necessary for the web. I just don't agree with Kay that the designers of the web are idiots (he really says this) because they didn't start with a VM. VMs will come and go as hardware and devices and circumstances change. Data has much more longevity; it encodes fewer assumptions.

Assumptions that are no longer true are generally the reason a technology dies. It is pretty easy to imagine a VM (unknowingly or not) encoding preferences for keyboard and mouse input; that technology would have died with the advent of touch screens. Likewise, a VM that provides affordances for touch screens will likely be dated in 10 years when we're using some other paradigm.

HTTP and HTML are foundational to the web. They are basically the simplest thing that could possibly work. You can reimplement them in a few days using a high level language. They will be around for a LONG LONG time.

More complicated constructs like JS and VMs will have shorter lifetimes. I guarantee you that HTML will be around long after whatever comes after JavaScript, just like HTML will outlive Java Applets and Flash.

They layered architecture of the web is absolutely the right thing. Use the least powerful abstraction for the problem, which gives the client -- which necessarily has more knowledge -- more choices. You could distribute all text files as shell scripts, but there's no reason to, and a lot of reasons why you shouldn't.

Re: Ask HN: What's the best technical talk you've heard?

#187
post #186
post #180

Earlier quoted context omitted.

Do you think HTML+CSS+JS+(...) can form the basis of all future computing? You have to apply the same standards to both sides. It's hard to be perfect, yes, but it's easy to do better than the web mess. If I had to choose between HTML+CSS+JS+(...) and either the JVM or CLR as the basis of the future of all computing, I would definitely choose one of the latter options. Both the JVM and .NET VM would work okayish, tho…

HTML and company aren't the basis of all future computing, but they or their non-Turing complete descendants absolutely will exist in 100 years. They don't exist for lack of imagination; they exist for timeless and fundamental reasons. Do you think plain text will exist in 100 years? If so then it's not that much a stretch to say that HTML will. It astonishes me that people think that only code, and not data, will be…

Sure some kind of markup construct will exist in 100 years. But not HTML. I do not believe plain text will exist in 100 years, but that's another discussion. I am claiming something far weaker than what you seem to think I'm claiming. I do not think each and every website will be written from scratch on top of the VM. I'm simply claiming that the distribution mechanism for new features of the web will change.

Currently the features are mandated by the W3C, then implemented by all browser vendors. The browser vendors send out updates to all users. Instead what will happen is that some future version markup language that's better than the then current HTML will be distributed as a library, running on top of the VM. This way if you are a site owner, you can immediately start using it. You do not need to wait until (1) the W3C recognizes that this markup language is a good thing and standardizes it (2) the browser vendors have implemented it (3) your visitors have updated their browser. You simply include the library, and start using the new markup language.

Note that this is already happening in the small. Javascript libraries like knockout.js are already changing the fundamental model of building web applications. Instead of waiting for the W3C to standardize some kind of web components with data binding, people implemented it as a library. 20 years ago people would have thought such a thing impossible. They would have thought that something like that surely has to be built in to the browser. As JS gets more powerful, more and more features can be implemented this way, instead of through standardization. Note that things are still flowing over the network in markup language (in this case, knockout.js template language). A similar thing happened with form elements. Remember the xforms standardization effort? Nobody cares anymore because JS libraries offer far better rich forms elements. The thing that changed is where it's implemented: ON the web, rather than IN the web. This organic model is far more in line with the principles of the internet, rather than the centralized way it's done with the web standards. Instead of giving somebody a fish, give him the tools to fish.

> HTTP and HTML are foundational to the web. They are basically the simplest thing that could possibly work. You can reimplement them in a few days using a high level language.

A few days?! This is absolute nonsense. You can't even read the spec in a few days, let alone all the specs it depends on, like PNG, JPG, etc. Maybe you can implement some tiny subset of HTML in a few days, but the whole thing is massively complicated. In comparison a VM is far far simpler.

100 years is a very long time. The web is 23 years old.

Re: Ask HN: What's the best technical talk you've heard?

#188
post #9

Simple Made Easy changed how I think about constructing software systems of any kind. It provided me with a strong vocabulary and mental model to identify coupling and design with a more clear separation of concerns and focus on the output rather than the ease of development. http://www.infoq.com/presentations/Simple-Made-Easy

Kind of off-topic: I can't manage to see any video, is it slides and mp3 only ?

Re: Ask HN: What's the best technical talk you've heard?

#190
post #187
post #186

Earlier quoted context omitted.

HTML and company aren't the basis of all future computing, but they or their non-Turing complete descendants absolutely will exist in 100 years. They don't exist for lack of imagination; they exist for timeless and fundamental reasons. Do you think plain text will exist in 100 years? If so then it's not that much a stretch to say that HTML will. It astonishes me that people think that only code, and not data, will be…

Sure some kind of markup construct will exist in 100 years. But not HTML. I do not believe plain text will exist in 100 years, but that's another discussion. I am claiming something far weaker than what you seem to think I'm claiming. I do not think each and every website will be written from scratch on top of the VM. I'm simply claiming that the distribution mechanism for new features of the web will change. Current…

So either TBL is an idiot for designing HTML instead of a VM, or he's not and Alan Kay is an idiot for calling him such. Which is true? Maybe you are not defending Alan Kay's stance, but you haven't said that.

Plain text has existed for 50+ years; I'm sure it will exist in 100. I'm pretty surprised you don't think so. Actually Taleb's Antifragile talks about this exact fact -- things that have stood the test of time will tend to stick around. For example, shoes, chairs, and drinking glasses have been around for thousands of years; they likely will be around for thousands more. An iPad has maybe another decade. HTML has already stood the test of time, because it has gone through drastic evolution and remained intact.

Your knowledge of how web standards are developed isn't quite correct. The W3C didn't invent SSL, JavaScript, XmlHttpRequest, HTML5, or HTTP 2 (SPDY), to name a few. Browser vendors generally implement proprietary extensions, and then they are standardized afer the fact.

I agree that the JS developments you list are interesting. JavaScript is certainly necessary for the web because it lets it evolve in unexpected directions. AJAX itself is a great example of that.

I'm talking about HTTP and HTML 1.0 -- they are conceptually dead simple, and both specs still use the exact same concepts and nothing more. I don't know if HTML 1.0 had forms -- if it did not then you could certainly implement HTTP + HTML in a couple days. I'm talking something like Lynx -- that is a valid web browser that people still use.

Lynx can still view billions of web pages because the web degrades gracefully, because semantic information is conveyed at a high level. The problem with VMs is they don't degrade. Suppose everyone gets sick of CSS. You can throw out all your CSS tomorrow, and write MyStyleLanguage, but your HTML will still be useful. If you encode everything in a VM, then the whole page breaks. It's all or nothing.

An analogy is that HTML vs VMs is similar to compiler IR vs assembly language. You can't perform a lot of optimizations on raw assembly code. The information isn't there anymore; it's been "lowered" in to the details of machine code. Likewise the client is able to do interesting things with non-Turing languages, because it can understand them. Once it's lowered into a VM language, the client can't do anything but slavishly execute the instructions. The semantic info that enables flexibility is gone by that point.

If you think markup will still exist in 100 years, then it's not too much more of a claim to say that markup will be transmitted by web servers and browsers. Do you agree with that? If that is true then TBL is not an idiot. Alan Kay's claim is basically ridiculous. A weaker version of it is still untrue.

I would say that in 100 years, HTML will still exist -- i.e. a thing that lets you separate plain text in to paragraphs, make it bold, etc. In contrast, we will have already gone through dozens of more VMs like the JVM, Flash, JS, Dart, etc. Certainly the JVM and Flash will be gone long before that point. They will have lived and died, but HTML will still be there.

Post reply on HN