4 ms·
> If you don't like the complexity of newer libraries and features, they're still optional aren't they? Chances are you're not programming in a vacuum. These f
by Galanwe 4y ago
> If you don't like the complexity of newer libraries and features, they're still optional aren't they?
Chances are you're not programming in a vacuum. These features will be used by third party libraries and you will have to read/understand this code.
Even in your in house codebase, there will always be co-workers that want to use these features.
The optionality of language features is not real. If they exist, they will be used, you will have to understand them, they will leak from other libraries, etc.
- Night_Thastus 4y agoIdeally if it's a library you just need to know how to use it, not how it works internally right? Maybe that's too optimistic, but that's certainly how I use libraries in C++.
- heavyset_go 4y agoYou can't always trust your libraries and you might have to fix bugs or dig in the source code to figure out how/why something works.
- bigyikes 4y agoTrusting foundations is the only way anything in computing gets done. If I’m at the point where I’m debugging 3rd party code, a little bit of unfamiliar Python syntax is the least of my problems.
- Galanwe 4y ago> Trusting foundations is the only way anything in computing gets done. Hu, says who? Says the junior developer so as not to get overwhelmed? If you've done any kind of expertise work, digging under third party layers is a very regular exercise.
- dataflow 4y agoThat's not even the case in C++ (I find myself having to step through Boost and even the standard library once in a while) but it's about 10x worse in a language that has so little static verification. If you use the library wrong then you find out via a runtime error you'll have to track down. Instead of, say, a type checker complaining about the type mismatch of your template parameter.