It's very heavy handed. The characters don't converse like real people, it feels like they're just vehicles for hitting you over the head with the author's message. Always with the befuddled idiot and the enlightened but exasperated one coyly dropping wisdom. Just didn't find it compelling.
Long speeches tho were really once more common. I don't have a lot of 'feel' for this tho because I don't even listen to contemporary speeches (because I much prefer being able to read a transcript much more quickly).
The speech at the end is really just a disguised essay that summarizes everything you already have figured out, but does it really slowly, in a book that's already taken its sweet time. From the point of view of structuring a story, it's a waste of the reader's time. Furthermore, it's a violation of the long standing convention that when an author writes a book about something they don't just come out and say what it's about. They paint it into the characters and setting, and let the ideas blossom over the course of the story.
I don't think you can defend it by making some sort of argument towards verisimilitude and historical speech lengths. Assuming that's what you're driving at.
I'll (mostly) grant you that the speech is "really just a disguised essay that summarizes everything you already have figured out", but I don't think there's anything wrong with that. Good rhetoric is redundant.
I also don't think it's a problem that it "does it really slowly" or that the book itself, overall, has "taken its sweet time".
Because of all of the above, I disagree that "it's a waste of the reader's time".
But of course I can defend it by arguing that it's realistic in its length or tone. Real people really do give long-winded political speeches! And the story supports it too! And look, there I went, defending that part of the book.
I'm not sure you can state that as an absolute. And certainly we can agree there's degrees of redundancy, a threshold that once crossed, is belaboring the point rather than expanding on it.
>I also don't think it's a problem that it "does it really slowly" or that the book itself, overall, has "taken its sweet time".
I've got no problem with the length of the book. I found it moved at a pretty good pace for me after the first 100 pages or so.
As for the length of the speech, how long would it take to deliver those hundred or so pages as a speech? Hours probably? Can you point to an example of a political speech that has gone on that long? It's news to me, but I'm no historian.
>I disagree that "it's a waste of the reader's time".
You're welcome to obviously. Everyone is welcome to their opinion.
>And look, there I went, defending that part of the book.
Honestly, I don't find your arguments compelling though. You made a questionable claim about rhetoric, and showed that other authors have exhibited the same pathology. Coming to defend that part of the book doesn't actually prove that it's defensible, just that you felt compelled to try (as much as any of this is possibly provable).
I think the essay could have been kept to, say, 10 pages and it would have felt like the climax to the book it was intended to be. Rather than some waffling blowhard thinking anyone in the country is going to sit and listen to his 4 hour pirate broadcast.
eh, could've condensed the whole book to about 1/3 the size. It took me about 8 months to read it cos it was so hard to keep trudging through. In hindsight I do somewhat like the gist of the book though.
... I don't share your sentiment at all. I find this relevant to the subject matter as he is, albeit indirectly, mentioning the performance of WASM. I would be surprised if you got the same performance using just plain old js on the hardware he is referencing.
The JS/WASM may be limited to 60FPS if it is being forced to draw every frame, in which case it has to wait for the browser, it may be much faster.
CA are great fun to optimise, i've found ways to make them very fast in JS alone, by using pure state machine method with TypedArrays and sliding window algorithm. When letting it skip frames (only drawing when a frame is available) it can go far beyond generations per second... when you get to larger grids the ultimate optimisation is to use FFT, but on smaller ones there is too much overhead and sliding window is way faster.
Algorithmic optimisation is always better, but this demo works for the purpose of showing basic WASM compilation which was the authors intent, there may be an order of magnitude improvement if a different implementation was used.
I'm not sure that you could load JS on the BBC Micro!
The point as that for something running safely virtualised (and standardised) in a random browser and on a much larger canvas, the WASM implementation is very impressive.
Level 1 when my window was of a small size was impossible to complete.
Level 2 was a load of | mirrors, which meant I could only reflect the laser back on itself. No angles at all, and couldn't figure how to move the angle of the mirror.
Its dhi.io
They have mentioned about the natural language part (for backend connectivity) but for visuals to convert designs to html/css they are using image processing and neural network.
And are releasing an early beta next monday.
I certainly threw in things there which I would not consider a requirement for hiring. I DO expect basic knowledge of the TCP state diagram and ability to parse and explain netstat output in actual hiring interviews. I would not expect someone to have read Schimmel's book and know how kernel locking works in great detail.
My advice is to really learn how to write some toy C programs at minimum an learn the sockets API and really have a copy of APUE and use it occasionally. I highly recommend a project where you do some kind of trivial 'hello world' patch to the actual kernel sources and things of that nature.
I have actually, on my job, seen issues that require this kind of knowledge -- like one incident with massive amounts of TCP RSTs and I've cracked open the kernel sources and tracked down where the TCP stack can issue RSTs, and found a problem with TCP Timestamps and the PAWS algorithm and the way that our layer 4 hardware loadbalancers at the time were doing packet rewriting and preserving all the random TCP timestamps from the clients which was hitting very high velocity servers and when TIME_WAIT state sockets were hit with a 'backwards in time' TCP timestamp from a different client it would issue a RST and tear down the connection because of PAWS. You might be able to find that kind of problem by studying the TCP RFCs and books like TCP/IP Illustrated instead of opening the kernel sources, but its the kind of problem that you aren't going to be able to Google. And I don't really have the ability to write a [modern, multithreaded] TCP/IP stack (although I could certainly acquire it), but I have demonstrated the ability to read the sources and get real-life work done by doing so.
For all the candidates that I interview I want to see some indication that they can work without the Google safety net and show some ability to track down problems on their own.
