Robert Elder writes technical posts on Linux, C, hardware, and algorithms, often with interactive visualizations.
HN commenters recommend it as a Linux systems blog, praising his series on making a CPU, and link his posts on comm and signed ints.
> Use `signed char` for strings
If you're dealing with POSIX / the C stdlib, mirror it and use char* . (The string version of "Respect the integer types used by each API."; if you're coding for Windows you'll likely need to use LPWSTR or whatever they call it now.) But: if you're storing UTF-8 string data, you _want_ unsigned char (and maybe uint8_t[2]): if start trying to inspect the code units, esp. to decode them to code points, you're going to need to do comparisons and bit manipulations on them, and its too easy to write `code_unit < 0x80` or something similarly silly (e.g., while masking bits to see if it's a continuation byte). It's like the article early today called "Should I use Signed or Unsigned"[1] states: "Prefer unsigned when using bitwise operators".
> Limit recursion
Recursion is fine; you simply need to be aware of your worst case stack depth. You're looking, really, for the complexity of your stack usage, or the big-oh of your stack size. If you're doing something like recursing down an in-memory balanced binary tree, it's O(log(n)) in the worst case: ~64 stack frames on a 64-bit CPU. Can you fit that many on the stack? Certainly that's heavier than a normal function call, but it's still a finite, computable size.
If you can't compute that / prove an upper bound, then I agree.
> Aside: any language that uses keywords like public and private to determine visibility instead of placement/scoping is bad
If not with keywords, how should visibility be…
No, it's not about stuff you know.
This was posted recently, but it was so good it's worth repeating:
http://blog.robertelder.org/50-interviews-with-facebook-twitter-amazon-others/
The interesting point is the distinction between skill and talent.
Skill is close to competence. You can solve well-defined problems using standard tools and practices.
Talent is close to proficiency. You can not only improvise good solutions for novel problems, but you can also prioritise problems intelligently to achieve strategic goals, because you have a clear view of how the codebase fits into your business or project.
Without talent you can waste a lot of time by picking the wrong tools, or using tools in the wrong ways. Even though your code may be perfectly correct, the solution built with the code can still be completely wrong or useless.
In fact talent is somewhat orthogonal to skill. You can have an untrained version of that overview talent, but it's not so useful if it isn't grounded in skill.
When you have both, you have real proficiency - good code doing the right things to solve the right problems.
I just worked on a new diff algorithm for VS Code, in particular for the new merge editor (you can turn it on with "diffEditor.diffAlgorithm": "experimental").
Diffing is hard and there are many subtleties (e.g. https://github.com/microsoft/vscode/issues/164370).
The space efficient Myers diff algorithm has some problems when using it for merging, as tiny changes at the beginning of a file can cause a different path selection later on. Also, Myers doesn't minimize the number of hunks (only their total length), which sometimes leads to unnatural outcomes.
If anybody has good ideas for more advanced diffing algorithms, I'm all ears! (maybe even tree based ones, like difftastic)
It's already very difficult to objectively evaluate the quality of a diff or to see if improving the diff for a special case doesn't make the average case worse.
As for the visualization of Myers, I can recommend to have a look at https://blog.robertelder.org/diff-algorithm/.
I agree with the content of this article, but all the same my advice is usually the opposite - for reasons that its author sets out rather well in the table in his follow-up article (https://blog.robertelder.org/signed-or-unsigned-part-2/)
I wrote a little piece about this myself once (http://soundsoftware.ac.uk/c-pitfall-unsigned.html)
I suppose I would loosely characterise my view as
- if your profession is "C programmer" and you really know what you're doing, you probably want to use unsigneds most of the time
- if your profession is something else, e.g. signal processing researcher who has to translate an algorithm to C or C++, you are probably better off not using unsigneds at all.
This seems like the perfect opportunity to introduce those unfamiliar to Robert Elder. He makes cool YouTube[0] and blog content[1] and has a series on regular expressions[2] and does some quite deep dives into the differing behaviour of the different tools that implement the various versions.
His latest on the topic is cool too: https://www.youtube.com/watch?v=ys7yUyyQA-Y
He's has quite a lot of content that HN folks might be interested in I think, like the reality and woes of consulting[3]
[0] https://www.youtube.com/@RobertElderSoftware
[1] https://blog.robertelder.org/
[2] https://blog.robertelder.org/regular-expressions/
[3] https://www.youtube.com/watch?v=cK87ktENPrI
ha ha, i laughed at that one too, the "procrastinate on work until the last day" example.
csplit stand for context split, iirc.
there is also the split command. it splits on the basis of number of lines, which can be specified in various ways.
didn't know about the '--filter' flag earlier. it allows you to filter each output file through some other command. useful.
https://blog.robertelder.org/intro-to-split-command/
https://man7.org/linux/man-pages/man1/split.1.html