[codeflo]

Everything about which people tell you to “not invent your own” must be invented by someone.

[twodai]

I guess it's more about priorities, if you want to build a web app don't reinvent the underlying protocols. If you want to build an embedded system for monitoring room temperature don't invent your own locks.

But if you want to make a lock by all means make a lock, just don't go and reinvent the chip architecture...

[pornel]

You're taking a saying too literally.

People who take on task of writing such library, and develop it to the point it's a language-wide standard, usually know what they're doing (or learn on the job :)

Popularity of such library helps test it thoroughly on many platforms in various conditions, so there's a high chance the bugs will be spotted and fixed.

[oriki]

I mean, that's too literal of an interpretation.

It's more like "if you don't need to, don't invent your own [x]." People who like to invent [x] are usually smart enough to understand why that warning is there to begin with, and don't tend to argue with it.

[JulianMorrison]

It's not "don't invent it".

It's "be competent before you invent it, because it's hard". And if you aren't, then let someone who is do the inventing.

[convolvatron]

the best way to _get_ competent is to try

so yes - invent your own synchronization primitives. please.

just dont believe they are correct without being serious about trying to prove they are. and dont hold up your whole project for self-enrichment.

but try to layer as much in as you can.

developers these days are so productive, until they fall down and cant get up. and then they are completely useless.

[JulianMorrison]

Disagreed. There are some problems, and low level hardware is one of them, where you need understanding and not just experience.

[convolvatron]

so what would qualify one to do this kind of work? a graduate class in parallel programming?

[JulianMorrison]

Depends which thing.

- For low level hardware grovelling, you need a sufficient understanding of the workings of modern chip internals.

- For crypto, another "don't invent your own" thing, probably a specialised degree in cryptography and a lot of practical experience.

The bar is simply higher than "I have access to a programming language and think my idea would work".

[convolvatron]

not going to argue about core crypto primitives - i have no idea what it takes to be able to contribute meaningfully there.

but I have no formal education. and when I started there were no gatekeepers. I mean there were, the MIT grads got to work on much cooler stuff than everyone else.

since then I've collaborated on chip designs and written a metric shitton of low level software - including microcode and alot of parallel synchronization primitives. and when I work with new grads (incl phds), I don't expect them to know any of that really - and we teach them. some of them get it and some of them don't.

not only do I find your emphasis on the 'proper training' misguided - I think its counter productive. unless you're working with a very rare professor, they aren't going to really have a very adequate notion of what new designs are like at all. most of them have had only the most casual experience with industry. your utility to me as a future systems programmer has alot more to do with your general level of talent and your interest in the topic than whether or not someone made you do dining philosophers.

[gpderetta]

Don't invent anything unless your job is to invent it. Of course you might not know what your job is until you are in the middle of it.

[api]

In that case you should never run any software. Go live as a hunter-gatherer in the wilderness.