Hacker News Reader

Comment by Zababa | Hacker News Reader

I wonder if sometimes always telling people to not do anything themselves and use already made libraries is robbing the industry (and especially juniors) of lots of opportunities to learn. Instead of being in control of what you do, you learn to use something made by other people to simplify things. This is a bit like cooking where in the last 10-20 years I've seen appliances appearing everywhere. Some are very good (I love my slow cooker), some I'm more perplexed about (A stand mixer? I usually get by either with my hand for dense doughs like pizza or bread or a hand mixer for more liquid/light doughs). If everybody uses libraries, how are we training new libraries writers? Maybe part of the solution would be to tell people to use libraries, and then read the code, try to understand them and contribute.

View on HN

I feel like one of the unintended consequence of discouraging people from "rolling their own crypto" is that developers who obey that rule will never be able to learn what good crypto is and isn't. This I believe will lead to more insecure software in the long run.

I think a pretty reasonable compromise is to reserve custom implementations of potentially dangerous things like crypto for personal projects. As an end user I'd rather run software that just uses sodium, but as a developer I agree that it's necessary that we get experience doing it ourselves.

At the risk of being overly opinionated, I think that developers do not learn what is good or bad cryptography from writing it. We learn what is good or bad code from writing and maintaining it. People learn what is good or bad cryptography from studying the mathematics of cryptography and listening to cryptographers. However, it's very possible for good code to be terrible cryptography for reasons you are very unlikely to learn by writing the code.

The catch with trying the reasonable compromises that are acceptable in other specialist areas often backfire in cryptography. "It's fine, this isn't serious, we'll fix it later" is something you can live with when it just results in a half-baked ORM, but much less fine when it results in seriously flawed cryptography that endangers people.

Cryptocat - and decryptocat - is a good example on both points.

I wonder if sometimes always telling people to not do anything themselves and use already made libraries is robbing the industry (and especially juniors) of lots of opportunities to learn.

In an ideal world, that is what university should be for. I rolled a whole bunch of my own numerical code while working on my degree, and got to learn in a 'safe' environment how hard it actually can be and all the pitfalls there are. When people say don't roll your own crypto, what they really mean is don't roll your own crypto and use it in production.

Completely off topic. If I was forced to choose between a slow cooker and a stand mixer, I would keep my stand mixer every time.

> In an ideal world, that is what university should be for.

That's true, but since we're supposed to be learning our whole career, this could work for CS fundamentals but not for new things that appear after.

> Completely off topic. If I was forced to choose between a slow cooker and a stand mixer, I would keep my stand mixer every time.

A big reason that makes me love my slow cooker is that I only have a small induction plate that can either burn food or not cook it at all.

Reply on news.ycombinator.com