Incrementally Improving the DOM | Hacker News Reader

Incrementally Improving the DOM

blog.functorial.com

102 pointsingve13 comments

Man this entire article was hard to approach. Some internal links to some background info, or a bit deeper background introduction section would be really great. The writing style is great, but there were some real leaps for a one off article. If there is some history behind this that I was supposed to implicitly know about then I apologize for the comment.

When I was working through his Purescript book (and later watching some of his videos) I had the same problem. He strikes me as one of these very intelligent people who have difficulty explaining what he's talking about because everything is so clear to him.

What I found with the previous things I've seen from him is that if I write some code I get stuck. Then I look at what he wrote again - lo and behold, he has the answer. Rinse and repeat. I've learned a ridiculous amount from him in this fashion :-)

"He strikes me as one of these very intelligent people who have difficulty explaining what he's talking about because everything is so clear to him."

There needs to be a word for that.

Wizards. Indistinguishable from magic and all that.

Phil's brain is extraordinary. I find that I need to read and re-read his blog posts/listen and re-listen to his talks to pick up on even a small amount of what he's saying. Great content.

I'm not disagreeing that this is good content, but doesn't having to reread something or relisten to something indicate that the pedagogical approach could have been better rather than that the teacher is a good teacher? In general, for teaching (note that this is very different than resources used for reference), caeteris paribus shouldn't we prefer the teacher who is easier to understand?

EDIT: It occurs to me that possibly your first and third statement were actually intended to be unrelated to your second. In which case, please disregard this comment.

Well, I mean it might, but it also might the case that the material is genuinely difficult and no amount of pedagogy is going to get around that. (An example might be trying to explain e.g. a non-trivial theroem from point set topology to a layperson... without including a huge amount of background material that you would actually get during a math degree.)

It's also a question of density; if he's simply saying a lot in very little, or assuming you'll do the menial work like a paper will (offers a theorem, properties and consequences, but proving the theorem is left as an exercise for the reader), then itll have the same property of having to re-read it, or rather, read it very carefully, but still be very valuable.

The difference is in the goal. If its just pedagogical, then you'd want to explain it in three different ways, hoping one will stick; but if its also intended as a reference to review, and discuss, after understanding the general principles (and believing in the theorems), then conciseness is preferable. Three different explanations just makes it more difficult to figure out what you're looking for

If you are in Los Angeles and curious about PureScript, Phil (the author) is hosting a meetup at Lumi HQ tomorrow, April 9th. This will be one of the topics. We're also streaming it on YouTube. https://www.meetup.com/LA-PureScript/events/249209149/

it'd be interesting to see where the purescript impl lands in this bench [1]. there are some truly fast vdom implementations out there. i also think a lot of this type of stuff can be compiled more optimally from a custom DSL to vdom rather than JSX to vdom (e.g. https://github.com/sveltejs/svelte)

[1] https://rawgit.com/krausest/js-framework-benchmark/master/we...

Is this similar to what Svelte does, where Svelte compiles down to the right DOM transformations?

Oh lovely. I've been trying to figure out how to address this in the context of GPU shaders and here comes the perfect paper!

Someone please explain that without ADT? And with graphs?

Reply on news.ycombinator.com