For most of the algorithms even if the supplied algorithm is a naive approach it's harmless, maybe some people learn from it, and some don't, nobody is harmed so it's net good.
Unfortunately this has cryptographic algorithms, and while they're initially quite simple like XOR, eventually we have what look at a glance like more substantial and useful primitives such as RSA encryption†. The authors doubtless know not to use these, but to a student it all seems to work as supplied, but of course it doesn't.
I think the simplification needed to make RSA explicable in this setting makes it so useless and abstracted from reality that it's net harmful, and I'd recommend against providing any of the cryptographic algorithms for that reason.
† Yes I'm aware that RSA encryption is obsolete. Does this site feel like the right pitch to explain that to students ?
RSA encryption is still very widely used (for example SSH keys with 4096 bit RSA keys). To call it obsolete would need solid basis of argument, I think. Perhaps you mean that specific implementation or way of implementing it?
> RSA encryption is still very widely used (for example SSH keys with 4096 bit RSA keys)
That's not RSA encryption. Which is fascinating, and my cough got even worse and I have a fever and my demo worked in the presentation anyway, and so I won't be doing any further productive work today...
SSHv2 (You don't use SSHv1, if you're younger you may never have used SSHv1) goes roughly like this
1. SSH client connects to SSH server (TCP stuff happens) they agree that they both speak SSHv2
3. SSH client says it can do certain types of cryptographic operation, the server says what it is willing to do, they should overlap or else no progress can be made.
4. A Diffie Hellman Key Exchange is performed based on the shared information from above, now the Client and the Server know a set of fresh unique keys for this session, all further data is encrypted with a symmetric algorithm using these keys.
5a. Now the client should explain how it intends to authenticate as a specific user. It probably wants to prove it has a private key corresponding to a public key that the server already knows (but it could use old-fashioned Unix passwords if that's enabled).
5a. For pubkey auth, the client says "I can prove I have the private key for this 4096 bit RSA key you know"
6. The server can say either "Fine, I know that RSA key, prove it" or "No good, what else can you do?"
7. Assuming the server said "Fine" the client performs RSA signing not encryption to demonstrate that it does have the private key. The signed message is a witness to the above unique conversation and thus cannot be re-played or re-used for any purpose.
No, encryption. SSH doesn't use RSA encryption it only uses the RSA signature scheme. The unfortunate naming of this SHA1 based algorithm is not relevant.
Can you tell how many extra memory allocations we are making to solve this problem? And how many are really needed? We could solve this with a for loop by directly comparing the characters and skipping non-alphabetical ones. This would be simpler to read and more efficient.
We should be careful with what we call "best practices for beginners", as they can sometimes lead to unnecessary complexity and inefficiency.
The highly overused "best practices" marketing term should really be called "most-likely good practice for most but not all situations highly dependent on context".
I think the problem is people want to know "Hey what's the right way to do this?". Turns out IEEE does publish some actual standards[0][1] related to software, but being completely honest I've never actually read it. I'm assuming I'm not in the minority.
This is the problem with an experienced dev writing a "Best practices for beginners" article. The beginner will read it as literally the best practice and commit it to memory as dogma, not considering suitable applicability and variations.
I would say that beginners shouldn't be writing core algorithms as performance often matters. The post should be called beginner-friendly implementations of algorithms in Go, or something to that effect. The point being to learn about the algorithms rather than learning the right way to code algorithms.
> Can you tell how many extra memory allocations we are making to solve this problem?
What suggests that the "best practice" is sliced down the efficiency lane? The intent could be to "best" demonstrate how to structure a collection of algorithms and data structures into packages, for example.
Just an example. Why should complexity and over-engineering be considered best practices for a beginner? In the example I've given, it turns out that a for loop and an if conditional are the simplest and most efficient solutions.
Additionally, from a beginner's point of view, it's important to learn algorithms that are language-agnostic. In this case, Go handles the allocations, copies, and memory management for you. However, this code would be much harder to implement in C. In any language, the algorithm I've provided would still be the best solution.
As others have commented, the terms "best practices" and "beginner" are sometimes used as clickbait to attract interactions and GitHub stars.
> Why should complexity and over-engineering be considered best practices for a beginner?
I'm still not clear on where the idea that this is a "best practice" is coming from. Is there some context I am missing?
Aside from the editorialized title, all I can find is an assertion of "following best practices", which does not even imply that it is trying to establish best practices (of any sort, let alone around efficiency or complexity), merely that the author tried to follow
some best practices established elsewhere. It is understood that to follow opens the possibility of veering off course, so unless the beginner is also a beginner with spoken language, it would not be taken to mean that this demonstrates best practices.
Unfortunately this has cryptographic algorithms, and while they're initially quite simple like XOR, eventually we have what look at a glance like more substantial and useful primitives such as RSA encryption†. The authors doubtless know not to use these, but to a student it all seems to work as supplied, but of course it doesn't.
I think the simplification needed to make RSA explicable in this setting makes it so useless and abstracted from reality that it's net harmful, and I'd recommend against providing any of the cryptographic algorithms for that reason.
† Yes I'm aware that RSA encryption is obsolete. Does this site feel like the right pitch to explain that to students ?