Is reading someone else's source code a good way to learn programming?

you realise how retarded your comment is, right?

Actually, I am interested in how drivers work, but I hear Python is a good language. I think he is right though.

Do people write exploits in Python?

it depends on who's code you are reading

In C somepeople elses code is a good way to learn how not to program.
For example, look at the Python C API, lex/yacc API and C and POSIX standard library and identify all global state and ponder how that could be better but itsn't and now everthing sucks.

>C and POSIX standard library
For the most part, they're fine. Some of the weirder/shittier stuff in there was considered good practice at the time they were designed, and have not aged well, but can't be removed for compatibility reasons.

You can't make such sweeping statements over just a couple of examples.

This

Posts like these remind me why I should stop coming here. Fuck Jow Forums, nobody here even bother to try to do something. If you want to know how drivers work, then try to fucking make one. It's not like there aren't thousands of guides and tutorials how to make a kernel module or Windows driver, and stuff like Ethernet interfaces have open and available datasheets, everything you need to know is literally a couple of search terms away.

>For the most part, they're fine.
Look at what alone setlocale influences: en.cppreference.com/w/c/locale/setlocale

You certainly could have picked a better example than locales.
Sure it's global state, but it's a lot more sane that needing to pass a locale struct fucking everywhere.
It's one of those things you set once at the start of the program and forget about it.

I believe the problem is people don't know where to begin. It seems overwhelming when you think you're going in the right direction but get blindsided by something you were completely unaware of. That makes even more people hesitant to even try.

>It seems overwhelming when you think you're going in the right direction but get blindsided by something you were completely unaware of
While I agree that it might be the case that it is overwhelming, in general, getting blindsided by something you don't know is an opportunity to learn something.

I agree, just a lot of people find it discouraging instead of being antifragile about it.

That's not how reality works. See: stream_libarchive: workaround various types of locale braindeath
Obviously the right way would be C supporting function overloading or default arguments. These functions should then default to 'english for morons (US english)' because that's what everyone expects.

>These functions should then default to 'english for morons (US english)' because that's what everyone expects.
Why would they not default to the system default instead?

Because it's the default anyone expects. What matters is that it doesn't change depending on where you live, because in C dealing with natural language is something rare compared to building a parser that is supposed to parse the same grammar everywhere.

ofc it would be better to leave that stuff to an external library anyway

If default to something else than the system default, you're doing it wrong. If you're making a natural language parser that doesn't account for other languages than US english, you're clearly doing it wrong.

The default locale is the "C" locale though, which everyone is familiar with.
It's extremely rare that you'd mix locales together, and most programs don't give a shit about them anyway.

>ofc it would be better to leave that stuff to an external library anyway
Like POSIX, right?

No you fucko. The fact that C is even dealing with that kind of garbage is wrong.
Natural language parsers are not a common use case,
Local settings and stuff like encoding should not be built-in in the standard library.

No, like something similar to ICU that is optional and doesn't influence global state.

>Local settings and stuff like encoding should not be built-in in the standard library.
Where the hell else would it go?

>The fact that C is even dealing with that kind of garbage is wrong. Natural language parsers are not a common use case,
But the point is character sets and encodings, not the actual language.

>Local settings and stuff like encoding should not be built-in in the standard library.
But it has to, because the Americans that designed C were retarded and thought everyone would use their extremely small subset of the Latin Alphabet for all eternity.

>muh global state
Thread-local state isn't global state IMO. Global state would be system-wide state. Nothing in POSIX alters that.

see >But it has to, because the Americans that designed C were retarded
That's the problem all along.

>Global state would be system-wide state.
>muh processes are a good abstraction meme
That's also a problem with UNIXoid faggotry.

Who the hell cares about global state that is literally set once at the start of the program, and not touched again?
The type of shit that locales affect isn't particularly important for most programs.

it isn't see

While I agree with you that UNIX design probably was a mistake to begin with, I don't see the issue with states being contained in their own processes.

It's not fine-grained enough for some things, like having multiple instances of state.

That depends entirely on what the state is, though. Also, a lot in POSIX is actually per-thread, not per process, which is a common misconception you see with newbies trying to protect errno with a mutex.

Bump

Is reading a book a good way to to learn how to write a novel?

If you read enough books, then yeah.