I really appreciate you taking the time to look into this! I don't have much more to say right now than what I said to this person: https://news.ycombinator.com/item?id=30742704. I need to dig into it and see. What you've written will help. I might introduce unit tests (with visuals) for this so I can sure it works in a lot of different scenarios.
I think your piece is very much on point although I only read 50% so far I will finish it and go through the code as well. It is well written and your arguments are solid.
The only thing is I disagree on one thing for server side code I think .NET will evolve and adapt.
On the client the war is over JavaScript has won, and its given us what .NET and Java promised all those years ago; true cross platform UI/client apps.
This was discussed a bit in the original post [1] but I believe this comes down to the problem being sufficiently deep in the stack that there was an assumption that this wasn't something that could be improved on. I'm sure the loading code looked good.
It took someone who didn't know what that code looked like being curious about what was actually happening.
I never said you wouldn't have to dereference and check the implementation. That's debugging. I said that it would make my intent clear. That I wrote the code below that line with the assumption that url is absolute and not specifically only the 'http://' case. The abstraction here is about encapsulating and communicating my intentions.
Edit: done now. I can't shake the feeling that we've been through all this before, and that's why I ended up resorting to whitespace tricks in https://news.ycombinator.com/item?id=20352144. But let's wait and see what's broken now...
On https://news.ycombinator.com/item?id=12483698 I wrote a better idea how this might be implemented without causing this problem. Nevertheless even if we use my first, worse interface this should not be a problem: Spawn a thread that does the lowlevel stuff, sync it and after that run the JITted code.
reply