doty

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something.

I'm sorry to say that this argument is not even wrong.

As programmers, it is not useful to us to think about that 99.9% of time. The 0.1% of the time is literally our entire job.

"Most of the universe is not Earth, so why do we spend so much time thinking about things on Earth?"

Am i mis-reading this article?

BESIDES not having any particular way to validate a token without asking the service, making the rate a hell of a lot slower than 2^64 tokens per second (lol wut) doesn’t it also assume that you have 2^46 valid tokens in existence? Isn’t that 70 TRILLION valid tokens, or nearly 9000 tokens per human on earth?

From the post:

> The same doesn't apply to the player sprite, as Aseprite takes minutes to compile the atlas for the nearly 1000 frames we have.

Why does compiling a sprite atlas for the player take 60ms/frame?

I say- it’s like they hooked a computer to a car. At first I thought “oh man, look! They hooked a computer to a car! Think of all the cool things you can do!”

A few months later I had learned how to reboot the drivers side door latch because of a software failure, somewhere… and I thought “oh yeah, right. It’s like they hooked a computer to a car.”

BTW that code has a security vulnerability in it: the size computation can overflow and you can end up shrinking your buffer, and you will end up smashing your heap, and then bad things.

If you are subscribed, the footer of the page reads as follows:

You can share this article! This URL can be posted anywhere you like, including in public. Anyone clicking on it can read the article without logging in. The URL is specific to your subscribed account, but no one outside of Destroy All Software can identify your account simply from the URL.

Don't the tuples with named values do that for you?

    (string first, string middle, string last) LookupName(long id)

I think this PYNQ is Python Productivity for ZYNC (http://www.pynq.io/), not "Python Implementation of Linq" (https://github.com/heynemann/pynq), as suggested by the title.

From http://number-none.com/blow/blog/programming/2016/07/07/brai...:

The game Braid originally shipped to the world in 2008, and after some ports in 2009, I have only worked significantly with the code on a few occasions. But I want to maintain this game indefinitely into the future; in the back of my mind, there have always been some clean-ups that I have wanted to perform on the code. Often when shipping a game, the best answer to a problem isn’t evident, and we are under time pressure, so we solve the problem in some way that is sufficient but sub-optimal. Other times, we need to design the game to meet technical constraints of systems we want to deploy on, but as the years go on, these systems become irrelevant, so the code can be cleaned up. I figured it would be interesting to talk about some of these things in a blog (and the blog will help motivate me to think about these situations and clean some of them up!)

I am reminded of JWZ's "On Toolkits" (https://www.jwz.org/xscreensaver/toolkits.html):

"Let's suppose that down in the bowels of some particular version of some particular toolkit library, there lurks a bug. Let's suppose that the nature of this bug is something relatively obscure: say that it's something like, if you hold down 5 keys on the keyboard for 10 seconds then drag the middle mouse button, the text entry widget gets a SEGV. (In fact, I'm not making this up: I saw this very bug once, years ago.)

Now, that's the sort of bug that is not likely to be noticed or fixed, because it's the sort of thing that people "never" do. If that bug was reported against, say, a web browser, nobody would much care: User: "I can crash my web browser by doing this crazy thing!" Developer: "Uh, don't do that then." And that's not a totally unreasonable response.

However, in the context of security software, it matters, because then it's not merely a cute trick that crashes the program: now it's a backdoor password that unlocks the screen."

> "Fuck it. Can someone just mirror their laptop screen up here?"

(Scene repeats.)

What's interesting to me is that if you read the summary (http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-s...), most of the recommendations are exactly the same as when programming against a traditional spinning-oxide hard drive: read and write entire blocks if you can, combine block writes, &c.

It's nice to know that all that work on high-performance IO in databases doesn't need to be thrown away just yet.

I think Mr. Armstrong would approve, given his comments near the end of https://www.youtube.com/watch?v=lKXe3HUG2l4, where he opines that the web would be great if, instead of URLs, every published document were just named with a hash of its content.

I thought this was satire-- a statement about advertisement-funded games and the way they afflict us in our modern times.

I was about to come over here and say "ha ha, nice work guys" before I read the comments and realized that the pop-ups were not ads, but were in fact supposed to be teaching me something.

Still, though, nice satire.

It's interesting to me that people seem to be trying to bridge Promises with CSP. Why aren't more people investigating the more straightforward async/await transformation that the C# compiler does? CSP just seems like one transformation too far.

I'm sure that I don't need to tell you that there are many things in this world that look easy, but are in fact very hard. Even things that are very simple at the core turn out to be very difficult in practice.

I mean, to be a little flippant, all you need is abstraction and application, and you can compute all computable problems, right?

More to the point: what I was trying to do was to point out the irony of saying "building a garbage collector is easy" and then, only a few sentences later, saying "this code may have subtle bugs." Saying "this code is not fast enough for production" would be one thing, saying "this code is not correct" seems to put lie to the assertion that building it is "easy."

I personally have never built a garbage collector in anger. But I suspect that the problem of building a passable garbage collector (that is, one that somebody else would be willing to use) is quite a bit harder than it is made out to be in this article.

"People seem to think that writing a garbage collector is really hard [...] Well it's not. In fact, it's rather straight forward."

[...]

"Thirdly. Please don't use this code. I did not intend for it to be wholly correct and there may be subtle bugs I did not catch."

I have used the "HTML Agility Pack" in the past with fair success, and it's available on nuget.

http://htmlagilitypack.codeplex.com/

While F&VD does a great job covering many different aspects of image generation, for this kind of work Real-Time Rending[1] is probably more useful. It is firmly grounded in a world of programmable GPUs (shaders & the like), and wastes little time talking about rendering techniques that are not relevant to modern graphics hardware.

[1] http://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenin...

Out of curiosity, how many of your apps have had this curve? (I'm assuming you've done this more than once, given your point #4.)

I worked on a language once (now dead) which even had a syntactically valid form for parse errors, which allowed a structured editor to record a valid AST at all times. The "parse error" expression just raised a "parse error" exception at runtime, so you could even execute ill-formed expressions.

It turns out to be fantastically empowering.

Her attractiveness may have to do with her recent marriage, but what did her recent marriage have to do with anything?

They weren't at her wedding reception, or at a private party, or in any other social situation where that topic might be appropriate. Instead, they were in a professional setting, about to discuss a professional topic, about which she had many credentials. Why is it at all appropriate to bring up her recent marriage?

I don't know where you get "less functionality and worse performance in the same or half as much space"- the point of the link was to show that 256 byte demos actually demonstrate more functionality. What makes you think you have more functionality in 1k of JS?

As you said, "if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos." I believe that's exactly the point. Even if there is all this theoretical power in our JS environments, we aren't using our environment nearly as efficiently as the 256 byte demos used theirs.

It's also worth noting that those 256b demos ran on the standard platforms of their day, which yes, required MS-DOS, but then could run on any intel compatible processor, with any standard motherboard, with any standard bios, with any standard video card. And I would be surprised if they actually called into MS-DOS at all, and didn't just talk to the hardware directly.

If a generalization is true, can it be "racist"?

That would require these various teams at Microsoft to act as if they were a single organization. This has historically been difficult for teams at Microsoft.

This doesn't look much simpler to me, and I suspect the problem with this approach will wind up being incomplete or overconstrained specifications, rather than incorrect programs.

To use the language of the op, it will be composed of many discrete simple assertions that excruciatingly specify the output.

Interesting. It's easy to pattern match this against the old "media company wants control and doesn't get the modern world" chestnut.

On the other hand, try pattern matching this against the "band decides to put work directly on internet rather than going through a label" or "writer decides to self-publish rather than go through a publisher" story. Why wouldn't a direct-sales model work for them?

Admittedly, they aren't quite doing the direct-sales model, since they only grant access to HBO GO through some sort of premium TV subscription. But if they offered direct subscriptions to HBO GO...

Sure I can. The argument was challenging the merits of the statement based on some quality of the entity that made the statement, not based on the statement itself. It's the very definition of "ad hominem".

You can argue that the sentiment expressed by the fictional character is impractical, as you do in the last part of your comment. I disagree with you, but that's neither here nor there.

It's an interesting and eloquent statement, and worth thinking about. There's no need to resort to ad-hominem attacks against whoever said it, no matter how fictional they might be.