HN user

bradtgmurray

55 karma

CTO Beeper (S21)

Formerly: Firmware Lead at Pebble (W11) Director, Embedded Software at Fitbit Engineering Manager at Faire (W17)

Waterloo, Ontario, Canada

Posts0
Comments15
View on HN
No posts found.

It is a net positive, I just wish they would focus more on their core users. Their basic code diff tool could use a lot of love to make it on par with the diffs generated from other tools.

Half the speed of native, but you're not comparing apples to apples. This slower code is also run in an environment where it's safe to download a random blob from the internet and just start running. This comes at some cost.

I wish they just put more effort into making their web interfaces more responsive. Trying to use Campfire from the browser on my Galaxy Nexus is nearly impossible.

This is a really good point actually. Hulu actually uses the encrypted variant of RTMP to deliver content, and decodes the stream in their flash player. If they were to deliver just raw h.264 through html5, they wouldn't be able to do this anymore.

Vevo (the music video people on youtube) are actually doing the same thing. You can't watch the videos without using the special flash player.

Perhaps their allocator only allocated and free'd memory in 4-byte aligned blocks, and would mask out the lower bits to make pointers align to those blocks before freeing them?

If you had an allocator like this, you could use the addresses 0 through 3, and presumably the deallocator would mask these all down to zero, and then do a check to make sure it doesn't free 0, and end up doing nothing.

Jeff is not quite on the ball with his reference to the "Shlemiel" algorithm.

Joel originally described the "Shlemiel" case when referring to strings in C not having a length stored in them, and needing to use strlen to walk the string to find the length. The Shlemiel problem comes up when you use strcat in a loop, since each strcat call needs to recalculate the length of the loop, which takes longer as the string gets longer.

The problem with concatenating strings is not a length issue, but a memory issue. In order to concatenate a string in C# or C++ using built in string classes, the location to store the new resulting string has to be allocated and the two strings have to copied into this new location. The allocation does not take up a trivial amount of time, and reallocating memory over and over again for each time you concatenate a string is bad practice. There is still a bit of "Shlemiel" since you have to keep copying your existing string, which takes a larger amount of time as the string gets longer, but you have to take in consideration the allocation, which wasn't present in the original problem that the "Shlemiel" story described.