Comment by wang_li
3 days ago
A couple of the stories where I feel I have expertise I found to be a bit objectionable. The title/headline was some clever or unexpected thing, but upon reading it turns out there is nothing supporting the headline.
E.g. "Integer Comparison is not Deterministic", in the C standard you can't do math on pointers from different allocations. The result in the article is obvious if you know that.
Also, in the Logistic Map in 8-Bit. There is a statement
> While implementing Algorithm 1 in modern systems is trivial, doing so in earlier computers and languages was not so straightforward.
Microsoft BASIC did floating point. Every 8-bit of the era was able to do this calculation easily. I did it on my Franklin ACE 1000 in 1988 in basic while reading the book Chaos.
I suppose what I'm saying is the premise of the articles seem to be click-baity and I find that off putting.
You're right.
In general when selecting articles we assume that the reader is an expert in some field(s), but not necessarily in the field covered by this article. As such, things which are simple for an expert in the specific domain, can still be surprisingly to learn for folks who aren't experts in that domain.
What I'm saying is, that we don't try to be a cutting edge scientific journal — rather than that, we publish even the smallest trick that we decide someone may not know about and find it fun/interesting to learn.
The consequence of that is that, yeah, some article have a bit clickbaity titles for some of the readers.
On the flip side, as we know from meme-t-shirts, there are only 2 things hard in computer science, and naming is first on the list ;)
P.S. Sounds like you should write some cool article btw :)
For what it's worth, I am only a mid-tier nerd and after reading this issue, I feel like I am your target audience. Nothing deep or overly-detailed, just lots of jumping-off points for me to learn more. Thanks!
I noticed that as well. Also misleading titles like “Eliminating Serialization Cost using B-trees” where the cost savings are actually for deserialization (from a custom format), and neither the self-balancing nature of B-trees isn’t actually relevant, as no insertion/deletion of nodes occurs in the (de)serialization scenario, so a single tree level is sufficient. It’s a stretch to refer to it as a B-tree.
I don't think that's fully accurate (full-disclosure: I've done the technical review for this article).
First, as for "serialization" vs "deserialization", it can be argued that the word "serialization" can be used in two ways. One is on the "low level" to denote the specific action of taking the data and serializing it. The other one is "high level", where it's just a bag where you throw in anything related (serialization, deserialization, protocols, etc) - same as it's done on Wikipedia: https://en.wikipedia.org/wiki/Serialization (note how the article is not called "Serialization and deserialization" for exactly these reasons). So yes, you can argue that the author could have written "deserialization", but you can also argue that the author used the "high level" interpretation of the word and therefore used it correctly.
As for insertion not happening and balancing stuff - my memory might be failing me, but I do remember it actually happening during serialization. I think there even was a "delete" option when constructing the "serialized buffer", but it had interesting limitations.
Anyway, not sure how deep did you go into how it works (beyond what's in the article), but it's a pretty cool and clever piece of work (and yes, it does have its limitations, but also I can see this having its applications - e.g. when sending data from a more powerful machine to a tiny embedded one).