For C++ many standard library functions can't be implemented in standard C++. And it not only shows some very obvious compiler built-ins in the library, but the library can depend on behavior guaranteed by the compiler which is otherwise undefined by the standard. Therefore it's not always wise to learn techniques from the standard library, as it can depend on implementation defined behavior, and this dependence can be subtle too.
Not too long ago it was impossible to implement std::vector in standard C++, as constructing objects next to each other formally did not create an array. Therefore pointer arithmetic on the resulting pointers were undefined behavior, as pointer arithmetic is only defined within an array.
This was fixed by the array being implicitly created in certain circumstances.
My advice would be: to learn a new language, simply start writing some non-trivial projects in it (a few thousand lines of code or so). In some languages (like Python), the standard library is the actually important feature, in other languages (like C), it's better to mostly ignore the stdlib. Example: I started learning Zig by writing a Pacman clone (https://github.com/floooh/pacman.zig) and a home computer emulator (https://github.com/floooh/kc85.zig), the Pacman clone doesn't use any Zig stdlib features at all, and the emulator only minimally for memory allocation, parsing command line args and loading data from files.
Zig's stdlib is much more useful than C's, but it's still entirely possible to write useful programs without it and instead focus on learning Zig's language features first.
But on the other extreme, the whole reason why I learned Python was its "batteries included" standard library.
> To learn a new language, read its standard libraryTo learn a new language, read its standard library
Yes, but also no.
The standard library is often more complex and uses more advanced features then you often need for most projects. I.e. collections in std are supper general purpose, but if you need to write a collection it's normally specific to the purpose you need it for.
I.e. std is the "most" general purpose library you normally find so even if it's written with "KISS" in mind it's still often not so simple.
Then it sometimes uses unstable language features you normally can't use (as it's often made "in sync" with the language) and/or optimizations which in most other cases would count as "pre-mature" optimizations.
Through without a question you can learn a lot there, you just should be aware of the points above.
Actually, this isn't so much an argument against reading the standard library as it is another reason to do so.
If the standard library is ugly and complex, it tells you something important about its design, and possibly about the language itself and its maintainers. It is a good indication of where things might well end up for you.
You should look at the ugly bits, and you should ask yourself "am I going to invest in this?"
That's why I decided not to invest in Scala. Its standard collections library was so hard to grok that I just decided to stay on Java. I must understand everything in the entire stack I'm using. If I have blind spots, it makes me nervous.
Java is pretty good in that regard, for example. I regularly browse its standard library and it's quite comprehensible. Concurrent stuff is not easy, but I guess that's the nature of underlying algorithms.
Also that's the reason that I don't like Java streams. They're as hairy as Scala collections. I'm avoiding Java streams.
IMO implementation details of any library matters as much as its public API. If library implementation is not nice to read, it's a very bad smell.
The trick is to read unfaithfully. You don't need to understand everything in the standard library. You just need to swim around in good code for a while. If you're in over your head, chances are you can skip that part.
I find languages are pretty easy to pick up after the first few. What seems to be the barrier nowadays is frameworks. How do people go about learning a new framework? Obviously most of them have an intro project to follow on with, but they tend to be pretty simplistic, and once that's done, getting to the complicated bits that you actually want to implement seem to be the barrier.
If you stay strictly in the procedural/OO paradigm then sure: it's just a new std lib and syntax. When you jump to functional, logical, or more esoteric paradigms things start to get pretty different.
Of course if you've already got one of each major paradigm under your belt things get progressively easier because you're exposed to more ideas...
I usually prefer working with mature stacks that don't require me to constantly work with flavor of the month frameworks.
It's great to broaden your horizons and all, but that is something that needs to be done judiciously and deliberately if it is to actually be of any use.
Completely agree. Once you learn enough languages, it all starts blending together and looking more or less the same. Same control structures, same functions, same structures, same classes, same objects, same lists, same hash tables, same pretty much everything. There's usually a few innovations and peculiarities here and there but it's not that much.
The bulk of the language is actually the standard library. The APIs people will be using to solve the vast majority of problems. Of particular interest are the APIs used for dealing text and I/O because everything involves them.
This is why Scheme is so easy to learn. The language itself can be learned in hours. The standard library is so small it's pretty much useless. Learning Racket on the other hand is much harder.
To go even further than standard library, read the language's source code. This is especially relevant for virtualized languages. The implementation reveals how they actually work and enable a much deeper understanding of it.
> This is why Scheme is so easy to learn. The language itself can be learned in hours. The standard library is so small it's pretty much useless. Learning Racket on the other hand is much harder.
This is why Racket is so easy to learn. The language itself can be learned in hours. The standard library is so big that you can do anything with it. Learning Scheme on the other hand is much harder.
I think the Scheme quote is interesting, because it almost applies to C.
Most people consider learning C hard (for example, compared to python), but it is an extremely small language with a "standard library so small it's pretty much useless".
Whole heartedly agree. I was big into Go years ago, and some newer guys tried to make it a functional language. When they argued with me, I couldn't say 'its's just not right', but instead pointed them to std library code.
Protip: That doesn't change their mind, it just makes them hate Go.
Why is that wrong? A language can be multi-paradigm while the “official” documents are written in a specific style. Like human languages, they evolve with their use (or fork into another language completely), while the high literature is the last one to change.
Together with that, I agree that one should read the high literature before inventing a new writing style.
If it drove them to write in another language, might that be a win? A code base full of non-idiomatic code, where devs think in the style of language A while using language B, isn’t a great place to hang out.
Well that's just silly. Why take a job using hammers and nails when you really like screws and screwdrivers, but hate hammers and nails?
I think the argument instead might have been, "Go is not designed for it, and kludging in a language paradigm that the language wasn't designed for is going to make for worse code."
The fact that these engineers didn't understand this, suggest to me that perhaps they were not very good engineers as such, even if they might have been skilled software programmers.
This doesn’t seem like good advice to me, as others have already said.
C++ standard library is written in a heavily templates style most user code isn’t written in. That would be a terrible way to learn.
Some of Python’s standard library delegates to C code.
Much of Clojures standard library builds the language up from a small set of primitive, sometimes out of macros, and isn’ta good example of how to write good code yourself.
The standard libraries tend to be written in a different mindset than idiomatic user code is, as the requirements differ. In my opinion, the best way to learn a language is to implement a non trivial but small project in it.
Maybe this works for the language that the author is talking about, but in the cases that I'm familiar with, the standard library code does not give a good idea of what "normal" application code looks like. For example it's often got a bunch of platform-specific logic or low level optimizations that, as an application author, you probably want the standard lib to abstract away from you
This is natural due to the low-level nature of a language implementation. And at some point, what's truly going on is often hidden behing a compiler intrinsic or a foreign function call to the runtime.
At the same time, there are going to be parts of the standard library that are less platform-specific and thus more readable, for example the Java Collection Framework.
In the past, people supported pundits who would sit in the monasteries/huts their whole life perfecting their knowledge of scriptures and their skills of explaining them to others (incl. picking the right verse when it's needed and commenting the way helpful to the seeker). Some times I feel like today, besides free software projects, meant to be ran on donations, there should be entire separate projects dedicated to writing really good (also taking usability, eloquence, ease of understanding and practical examples very seriously) documentation for programming languages and libraries.
Standard libraries are very concrete, not academic at all. Learning the standard library means learning how to open a network connection and making an HTTP request to some server. The language becomes useful and gives results immediately. Theory means stuff like language concurrency models, it becomes important once you start considering how to structure the code at a high level. How do I use this language to handle X requests concurrently, hopefully in parallel?
I don't think this is a good read. A standard library is very concrete - it's the core of the language in action, and the shape that its code takes will likely be repeated regularly in 3rd party code written in that language. There's nothing academic or abstract about it.
EDIT: As others note, a good chunk of a stdlib may involve system interop that isn't representative, so that tempers my comment with regards to whether that code is idiomatic. But my case still stands regarding concrete vs. abstract.
This is a classic hacker/builder take. Start scratching your own itch and make many apps. /s
To be frank I have the same mindset, but it's good to read other people takes on it. Some prefer to have basic knowledge and feel great anxiety when they're jumping to code without any foundation.
Better really depends on who you are. Born academics can learn better by reading foundation libraries and principles, and they write articles advising others to do the same :-)
What you described as better could be a really good fit for business-first coding opportunists who would get annoyed by perceived inefficiencies and petty politics in academia...
The article is a terrific example of basic analysis BTW. This underappreciated skill can be a huge blindspot for opportunists...
IMHO, any language worth learning has a large enough user base in both corporate and academic settings and that there are books written on it. That's my criteria. If it doesn't have at least 5 books on Amazon, I'm suspicious of it (and from real publishers, and not publishing mills). There's too much wheel-reinventing happening for me to get excited about new languages.
In the last decade I've spent time learning five sufficiently novel languages: Scheme, Ada, Erlang, Rust, and Go. Three of those are from the late 70's. I'm really glad I learned Ada and Rust. I started using Ada for embedded programming, and I'm trying to find more opportunities to use Rust because it so robust. I only studied Erlang, Scheme, and Go because smart people I knew told me I should investigate, but I have not used them.
What is novel about Go? It just seems like C repacked with a garbage collector and basic concurrent programming support to me. Which both weren't novel even when Go was designed.
Could I trouble you to compare Ada and Rust, especially in terms of safety? I'd like to be able to write low-level code without dealing with the insanity of C, and my top picks are Ada (traditional answer to "safe language"), Rust (the up and coming answer to "safe language"), and Pascal (friendlier than C and way better at least for memory safety), but I'm reluctant to learn all of them to sufficient depth to be able to decide in retrospect which one was worth learning:)
I do not think an advice like this is applicable to any programming language out there. For example, I find it hard to apply to languages which have long history and change a lot over time, like Python or Java (or C++ as mentioned in other comments). I can easily imagine parts of the standard library being written long time ago, with many modern features not available back then.
For example, I do not think it is possible to learn modern Java by reading Java Collections code. You won't see Optional<T> being used there. Instead, your takeaway might be that it is perfectly fine to return nulls all over the place.
I think Rust is in a category of it's own, mostly due to circumstances rather than anything: The ecosystem has grown immensely over the past several years and you can find a crate to solve most of your needs. But here is where thing become tricky: more often than not the documentation provided is extremely vague to put it mildly and the examples are a hello world at best. With this in mind, in order to truly use it you have little to no choice but to dig deep into the implementation and at some point reach the standard library.
What's a good way to learn about the proper way of writing java 11 in 2021 / 2022 ? I'm currently trying to escape writing java 1.5 style code in java 8.
To anyone that considers this approach for learning C++, I would advise strongly against it. Standard library code has to deal with too many cases and tries to be optimal for as many of them as possible. Also the formatting is highly unusual, compared to other C++ code found in the wild.
That's probably true of quite a few languages actually. I mean if there is any library you want to be as fast as possible, it's the standard library. Take python for example, a big chunk of the standard library is actually written in c (although there is often an equivalent implementation in python). In rust the standard library uses quite a bit of unsafe code, and even nightly only features and standard-library-only features that you don't usually need in real code, because you will be calling something in core or std that does it for you, and has been rigorously checked to be safe. The java standard library has parts that are written in c++. Etc. Etc.
Yeah, the first thing that popped into my head was some poor n00b spending the next six years of their life deciphering glibc. There have got to be easier ways :)
And the C++ standard library has too many fundamental design issues that are just bad advice for writing actual maintainable and performant code. For example, the standard specifies all map containers to have pointer stability, which is often not needed in reality. Because of this all <unordered_map> implementations are hilariously slow. Or what about std::vector<bool>, <iostream>, std::string, you name it.
The frustrations people have with it are sometimes up to the point where they begin writing everything from scratch…
That’s actually what I do whenever I’m lacking humility as a coder. One F12 on std::iterator (which is now deprecated lol [0]) is enough for me to remember that I don’t know anything.
I was about to post the same but here you are. The only time I would study std:: namespace would be is I needed to write some generic library. Trying to learn C++ by reading std:: can make one's head explode.
This is also true for .NET, especially modern .NET where performance is critical nearly everywhere. It's representative of perf-sensitive code, but not general purpose C#.
I’m using Zig a lot right now, and I have been pleasantly surprised by the standard library. Maybe it’s due to Zig being a very straightforward language, but I find most everything I read in the standard library to make immediate sense.
I don’t know about reading std alone to learn Zig though, I used other sources like ziglings and ziglearn which taught me syntax and patterns. Had I started with the standard library I doubt I would have picked up the language as quickly as I have.
So having learned Zig I am much more inclined to look at standard libraries for languages I learn in the future, but I don’t think it’s wise to rely only on standard libraries for learning.
Learning Zig by reading its standard library source has worked for me. The source files also include quite self explanatory tests that compensate for incomplete documentation on main Zig website.
Until you realize most of the time the code is loaded with Macros, ifdefs, cross-platform conditions(windows,macos,linux...), hacks for different versions of OSes/dependency/whatever, the real meat is hard to spot on, it's easy to get lost in those noises.
Ugh Crystal is so beautiful and sorry to make this typical complaint but I wish the compile time was 1/10th of what it is. The dev cycle loop is just not there for me but the language is incredible.
Crystal core developer here. Happy to see Crystal's stdlib as an example for how you can grasp a language by looking into stdlib code. That's what I like a lot about Crystal. Even its stdlib easily readable.
Arguably, this is somewhat deteriorating as algorithms get optimized. Readability and performance being in competition.
I agree with some of concerns from many commenters. For many languages, especially those that have been around for a long time it's probably not a good idea to look at the stdlib. C++ or Java, no thanks.
But with some languages like Crystal, Golang or Julia, it can be really very helpful to look at the stdlib implementation.
All well and good until you find out half of it is written in C or something like that. I like to go out and find the most starred repos on github or just ask around for a library that people think highly of and read that.
C itself is actually a pretty good example of where this fails as well. Its standard library is usually more macros than code. It's necessary if you are going to ship portable code that deals with every conceivable architecture and endianness and permutation of toolchain from 1976 until now, but it's not how most C code looks.
K&R is a much more meaningful guide than unistd.h.
I actually partially disagree with this. Sure, for the higher level OS independent packages (e.g. “archive/tar”) this is great.
For stuff in the “os” package it’s a different matter. All of that code is a bit messy. Not because the authors did a bad job, but simply because it’s hard to implement the same API on half a dozen operating systems.
Then there is the “runtime” package which relies on a lot of global state, and has to work well in cases where heap allocations are not permitted.
Sure you’ll learn how the language works, but you shouldn’t draw inspiration from those on how to write your own code.
I agree, Golang is a good language for this. Rust, too.
The Python standard library is pretty crufty — lots of stylistically dated code. Same with Perl 5, and I would guess other similar languages but I can't speak from direct experience. I bet that's more a function of their age — back in the 1990s maybe it might have been unreservedly good advice to read those standard libraries.
I've also learned a lot from writing FFI extensions for languages, which for Rust and Go involves a lot of standard library diving but for languages like Python, Perl 5 and Ruby where the core is mostly written in C, it's a different experience than reading the standard library.
This doesn’t seem like a great idea in general, since the standard library is usually low-level code, aggressively optimized for speed, that is not at all typical of applications written in that language.
Emacs comes with a manual called "An Introduction to Programming in Emacs Lisp". It says:
> I hope that you will pick up the habit of browsing through source code. You can learn from it and mine it for ideas. Having GNU Emacs is like having a dragon’s cave of treasures.
I don't think the advice applies for C++ either. The last time I worked with a C++ code base I tried to understand some std:: API semantics by reading the code but I failed every single time. I'm not an expert C++ programmer by any means but I think I've passed the novice stage where you try to learn the language. Maybe for C++ constant learning of the base language is needed :-)
For Go and C on the other hand I think it works very well since the core languages are so simple it's viable to read others code successfully without being a language expert. I read the Go stdlib code all the time if something is unclear in the documentation (the docs are good but sometimes there are edge cases that are not clearly documented).
This is how I approached learning Nim at the time, and it was quite an excellent approach in my opinion. Even gives you the opportunity to contribute to the language in question, when you inevitably come across something that isn't optimal, a bug, or even something as small as formatting inconsistencies, which is a nice feeling
The goals of library authors are frequently different from those of application developers. Library authors usually have to consider how to make their code work on more environments, on older language versions, more configurable, handling more edge cases.
I think there’s definitely value to reading a language’s standard library, and I’ve also gotten lots of value from even reading the language’s implementation! But I hope people take this advice to start with reading the standard library with a grain of salt: it can be one extra resource for you, and likely to show you new things that weren’t written in docs somewhere, but if it doesn’t click or is proving difficult to understand, that’s fine!
In particular, for the “reading code to learn” bit, consider reading an application written in that language (command line tool, web application, etc.) and it might serve as a more reduced intro to the language.
I'm not sure how many languages this works well for but it certainly doesn't work with C. You won't learn the important distinctions between implementation defined, unspecified and undefined behavior. And reading a C standard library implementation will not really teach you to write normal idiomatic C code. You will also not learn the strict discipline required to avoid doing things unless you absolutely know with certainty that they are either strictly conforming or defined for your particular set of target platforms (usually much harder to answer this second question which is why when writing C you should avoid having to).
That being said, for Erlang, I think this is a good idea. I learned a lot when reading the standard library.
Interestingly, my engineering school adopted the opposite approach on practical teaching: the first couple of month after the preparatory years were all about re-building all the C stdlib, networking layer, then building your own shell, then building your own assembler and corresponding vm (it was an assembler for a quartet based system for whatever reason), then compiler for a random language in c++ (tiger) and so forth.
We also built a simple CPU from gates using an electronic simulator.
Left me with some confidence that I could do things with a relative confidence. Definitely value in learning the basics.
Even though it's not about human languages, it is funny to think about how you would definitely learn a human language too if you pored through its entire literary canon.
I say best way to learn is to start coding and break stuff :-)
Also once one gets more experienced, its better to decouple the language from programming concepts like object oriented programming, continuations, avoiding side effects in functional programming, etc. Useful to read books like SICP and algorithm books, then learn multiple languages and you will see they are not that different overall.
I recommend learning Lisp or Scheme or related languages because they have a lot of good conceptual resources to learn from. But maybe that’s my background talking, I loved SICP. I learnt SO much from studying Common Lisp in the last year. Of course it helps that it has a great language specification.
In terms of choosing a language, standard library matters a lot. Hence the explosion of JS due to NPM and also being in browser. I’m suprised SWIFT is not more popular, given Apple’s place in the ecosystem. I really liked programming in Swift, very enjoyable language. And it has generic functions too!
It can give you some insight into language features, memory model, etc, but it is unlikely to help you "learn" , as in "be effective in using" it.
For instance in Scala you'll likely need to know cats-effect or zio ecosystem more than stdlib. Likewise for Rust, where futures and async stack (tokio, asyncstd) are outside stdlib.
lol this advice might not apply as much to Scala. All the CanBuildFrom stuff was overwhelming to look at the first time, and a lot of things in the stdlib are implemented in a way that’s not idiomatic in app-level Scala. They’ve simplified things a bit and made it better since I was baffled by it all long ago though.
Reading the Python stdlib was a brilliant move a peer encouraged me to do. I learned three themes of stuff:
1. A good look at long lasting, durable pure python.
2. A good look at long lasting, durable C implementations of python (dict is the core of Python. Read the source!)
3. A look at a bunch of libraries that basically never get used and a sense of how they compare to popular third party libraries. (Doing this is why I’ll never complain when a language’s stdlib is small. I get it now.)
I've jsut discovered this approach with python. I usually used google and cookbooks. But I often found myself in position where I tought 'surely there must be a better way to do it'. Reading the standard library really helped me understand how to do some stuff. Best way I found to enforce what I learnt was to rewrite some code with minimal imports.
To learn a language, read and understand its specification. Then learn the tooling and libs that come with the compiler. Then just start reading other people's source from wherever while you write your own stuff. Reading the standard lib is helpful, ad is reading the source of any framework, but you have to know the language spec well for it to make sense.
In C#, standard library is awesome, and indeed a good starting point for people learning the language.
On the other end of the spectrum there’re languages like C++ with these horrible templates, or Rust with tons of unsafe code. Adopting patterns or coding style from these standard libraries is not the best idea.
I think this applies to lot of frameworks, especially web frameworks. This has been my experience with expressjs and Angular2, Jquery. They may look like they are doing lot of magic but underneath it’s just a simple code, when read it easy to write optimised code.
this works really well for certain languages and have done many times over the years, first can actively recall was Turbo Pascal some years ago, which ironically enough, was just tweeting about on Friday along with other just get started thoughts, https://twitter.com/DotDotJames/status/1451656005155176454
I learnt more about C and C++ from studying Plauger's The Standard C Library and Plauger/Stepanov's The C++ Standard Template Library. I also remember learning Object-Oriented Framework design from MFC Internals.
steerablesafe|4 years ago
Not too long ago it was impossible to implement std::vector in standard C++, as constructing objects next to each other formally did not create an array. Therefore pointer arithmetic on the resulting pointers were undefined behavior, as pointer arithmetic is only defined within an array.
This was fixed by the array being implicitly created in certain circumstances.
hello4353|4 years ago
Jeff_Brown|4 years ago
flohofwoe|4 years ago
Zig's stdlib is much more useful than C's, but it's still entirely possible to write useful programs without it and instead focus on learning Zig's language features first.
But on the other extreme, the whole reason why I learned Python was its "batteries included" standard library.
dathinab|4 years ago
Yes, but also no.
The standard library is often more complex and uses more advanced features then you often need for most projects. I.e. collections in std are supper general purpose, but if you need to write a collection it's normally specific to the purpose you need it for.
I.e. std is the "most" general purpose library you normally find so even if it's written with "KISS" in mind it's still often not so simple.
Then it sometimes uses unstable language features you normally can't use (as it's often made "in sync" with the language) and/or optimizations which in most other cases would count as "pre-mature" optimizations.
Through without a question you can learn a lot there, you just should be aware of the points above.
vletal|4 years ago
bborud|4 years ago
If the standard library is ugly and complex, it tells you something important about its design, and possibly about the language itself and its maintainers. It is a good indication of where things might well end up for you.
You should look at the ugly bits, and you should ask yourself "am I going to invest in this?"
vbezhenar|4 years ago
Java is pretty good in that regard, for example. I regularly browse its standard library and it's quite comprehensible. Concurrent stuff is not easy, but I guess that's the nature of underlying algorithms.
Also that's the reason that I don't like Java streams. They're as hairy as Scala collections. I'm avoiding Java streams.
IMO implementation details of any library matters as much as its public API. If library implementation is not nice to read, it's a very bad smell.
Jeff_Brown|4 years ago
askvictor|4 years ago
leshow|4 years ago
Of course if you've already got one of each major paradigm under your belt things get progressively easier because you're exposed to more ideas...
marginalia_nu|4 years ago
It's great to broaden your horizons and all, but that is something that needs to be done judiciously and deliberately if it is to actually be of any use.
SavantIdiot|4 years ago
trevyn|4 years ago
Or, try to add a non-trivial feature to the framework.
baby|4 years ago
matheusmoreira|4 years ago
The bulk of the language is actually the standard library. The APIs people will be using to solve the vast majority of problems. Of particular interest are the APIs used for dealing text and I/O because everything involves them.
This is why Scheme is so easy to learn. The language itself can be learned in hours. The standard library is so small it's pretty much useless. Learning Racket on the other hand is much harder.
To go even further than standard library, read the language's source code. This is especially relevant for virtualized languages. The implementation reveals how they actually work and enable a much deeper understanding of it.
Ginden|4 years ago
Yes, reading hundreds of thousands LoCs written in C/C++ is totally viable method of learning languages. ;)
nerdponx|4 years ago
This is why Racket is so easy to learn. The language itself can be learned in hours. The standard library is so big that you can do anything with it. Learning Scheme on the other hand is much harder.
ddlutz|4 years ago
Most people consider learning C hard (for example, compared to python), but it is an extremely small language with a "standard library so small it's pretty much useless".
sleepycatgirl|4 years ago
silisili|4 years ago
Protip: That doesn't change their mind, it just makes them hate Go.
ronenlh|4 years ago
Together with that, I agree that one should read the high literature before inventing a new writing style.
physicles|4 years ago
nerdponx|4 years ago
I think the argument instead might have been, "Go is not designed for it, and kludging in a language paradigm that the language wasn't designed for is going to make for worse code."
The fact that these engineers didn't understand this, suggest to me that perhaps they were not very good engineers as such, even if they might have been skilled software programmers.
jb1991|4 years ago
dkersten|4 years ago
C++ standard library is written in a heavily templates style most user code isn’t written in. That would be a terrible way to learn.
Some of Python’s standard library delegates to C code.
Much of Clojures standard library builds the language up from a small set of primitive, sometimes out of macros, and isn’ta good example of how to write good code yourself.
The standard libraries tend to be written in a different mindset than idiomatic user code is, as the requirements differ. In my opinion, the best way to learn a language is to implement a non trivial but small project in it.
ridaj|4 years ago
andi999|4 years ago
samus|4 years ago
At the same time, there are going to be parts of the standard library that are less platform-specific and thus more readable, for example the Java Collection Framework.
qwerty456127|4 years ago
oreally|4 years ago
Better way to learn is making stuff with the language, having actual skin in the game. Only then bounce back to theory on the more nuanced stuff.
matheusmoreira|4 years ago
Fellshard|4 years ago
EDIT: As others note, a good chunk of a stdlib may involve system interop that isn't representative, so that tempers my comment with regards to whether that code is idiomatic. But my case still stands regarding concrete vs. abstract.
luigi23|4 years ago
To be frank I have the same mindset, but it's good to read other people takes on it. Some prefer to have basic knowledge and feel great anxiety when they're jumping to code without any foundation.
themodelplumber|4 years ago
What you described as better could be a really good fit for business-first coding opportunists who would get annoyed by perceived inefficiencies and petty politics in academia...
The article is a terrific example of basic analysis BTW. This underappreciated skill can be a huge blindspot for opportunists...
SavantIdiot|4 years ago
In the last decade I've spent time learning five sufficiently novel languages: Scheme, Ada, Erlang, Rust, and Go. Three of those are from the late 70's. I'm really glad I learned Ada and Rust. I started using Ada for embedded programming, and I'm trying to find more opportunities to use Rust because it so robust. I only studied Erlang, Scheme, and Go because smart people I knew told me I should investigate, but I have not used them.
rowanG077|4 years ago
azth|4 years ago
yjftsjthsd-h|4 years ago
eicossa|4 years ago
How would you categorize No Starch Press, Manning, OReilly as per this rubric ?
evercast|4 years ago
For example, I do not think it is possible to learn modern Java by reading Java Collections code. You won't see Optional<T> being used there. Instead, your takeaway might be that it is perfectly fine to return nulls all over the place.
axegon_|4 years ago
I think Rust is in a category of it's own, mostly due to circumstances rather than anything: The ecosystem has grown immensely over the past several years and you can find a crate to solve most of your needs. But here is where thing become tricky: more often than not the documentation provided is extremely vague to put it mildly and the examples are a hello world at best. With this in mind, in order to truly use it you have little to no choice but to dig deep into the implementation and at some point reach the standard library.
nico_h|4 years ago
dxuh|4 years ago
thayne|4 years ago
aetherspawn|4 years ago
guerrilla|4 years ago
cyber_kinetist|4 years ago
The frustrations people have with it are sometimes up to the point where they begin writing everything from scratch…
jimbob45|4 years ago
[0] https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated...
dataflow|4 years ago
FpUser|4 years ago
devin|4 years ago
phillipcarter|4 years ago
unknown|4 years ago
[deleted]
gefhfff|4 years ago
eepp|4 years ago
cturtle|4 years ago
I don’t know about reading std alone to learn Zig though, I used other sources like ziglings and ziglearn which taught me syntax and patterns. Had I started with the standard library I doubt I would have picked up the language as quickly as I have.
So having learned Zig I am much more inclined to look at standard libraries for languages I learn in the future, but I don’t think it’s wise to rely only on standard libraries for learning.
githubholobeat|4 years ago
nafizh|4 years ago
synergy20|4 years ago
er4hn|4 years ago
bestinterest|4 years ago
trevyn|4 years ago
straight-shoota|4 years ago
I agree with some of concerns from many commenters. For many languages, especially those that have been around for a long time it's probably not a good idea to look at the stdlib. C++ or Java, no thanks. But with some languages like Crystal, Golang or Julia, it can be really very helpful to look at the stdlib implementation.
CRConrad|4 years ago
Sorry, stupid question: Is this derived from the old Crystal Reports, or something completely separate?
mberning|4 years ago
marginalia_nu|4 years ago
K&R is a much more meaningful guide than unistd.h.
en4bz|4 years ago
1vuio0pswjnm7|4 years ago
Certainly this is how I learn. Much more immediately useful than voluminous documentation.
However I am not sure every language has a standard library.
For example, Lua.
Also not sure every standard library is a model to follow.
For example, where feasible, I try to use and learn from djb's C functions instead of the "C standard library" ones.
baby|4 years ago
EdSchouten|4 years ago
For stuff in the “os” package it’s a different matter. All of that code is a bit messy. Not because the authors did a bad job, but simply because it’s hard to implement the same API on half a dozen operating systems.
Then there is the “runtime” package which relies on a lot of global state, and has to work well in cases where heap allocations are not permitted.
Sure you’ll learn how the language works, but you shouldn’t draw inspiration from those on how to write your own code.
rectang|4 years ago
The Python standard library is pretty crufty — lots of stylistically dated code. Same with Perl 5, and I would guess other similar languages but I can't speak from direct experience. I bet that's more a function of their age — back in the 1990s maybe it might have been unreservedly good advice to read those standard libraries.
I've also learned a lot from writing FFI extensions for languages, which for Rust and Go involves a lot of standard library diving but for languages like Python, Perl 5 and Ruby where the core is mostly written in C, it's a different experience than reading the standard library.
ramesh31|4 years ago
munchler|4 years ago
nickdrozd|4 years ago
> I hope that you will pick up the habit of browsing through source code. You can learn from it and mine it for ideas. Having GNU Emacs is like having a dragon’s cave of treasures.
- https://www.gnu.org/software/emacs/manual/html_node/eintr/On...
andy_ppp|4 years ago
MauranKilom|4 years ago
Let me cite a single line from the MSVC implementation of the C++ standard library (https://github.com/microsoft/STL/blob/main/stl/inc/xtree):
Also, good luck understanding this class member definition. Hope you figured out _Scary_val! (Hint: Empty base class optimization.)feffe|4 years ago
For Go and C on the other hand I think it works very well since the core languages are so simple it's viable to read others code successfully without being a language expert. I read the Go stdlib code all the time if something is unclear in the documentation (the docs are good but sometimes there are edge cases that are not clearly documented).
girvo|4 years ago
jez|4 years ago
I think there’s definitely value to reading a language’s standard library, and I’ve also gotten lots of value from even reading the language’s implementation! But I hope people take this advice to start with reading the standard library with a grain of salt: it can be one extra resource for you, and likely to show you new things that weren’t written in docs somewhere, but if it doesn’t click or is proving difficult to understand, that’s fine!
In particular, for the “reading code to learn” bit, consider reading an application written in that language (command line tool, web application, etc.) and it might serve as a more reduced intro to the language.
Arch-TK|4 years ago
That being said, for Erlang, I think this is a good idea. I learned a lot when reading the standard library.
kartayyar|4 years ago
That shows you call sequences in context, rather than just getting lost in the code.
charles_f|4 years ago
We also built a simple CPU from gates using an electronic simulator.
Left me with some confidence that I could do things with a relative confidence. Definitely value in learning the basics.
copperx|4 years ago
lngnmn2|4 years ago
sidedishes|4 years ago
fsnowdin|4 years ago
mohn|4 years ago
1992 - French v9.a.e
2000 - French v9.e.m
2011 - French v9.m.q
Don't be deceived by the dates, though. The project isn't dead. The Larousse and Le Robert forks are actively developed.
[0] https://en.wikipedia.org/wiki/Acad%C3%A9mie_Fran%C3%A7aise#D...
MonkeyClub|4 years ago
math-dev|4 years ago
Also once one gets more experienced, its better to decouple the language from programming concepts like object oriented programming, continuations, avoiding side effects in functional programming, etc. Useful to read books like SICP and algorithm books, then learn multiple languages and you will see they are not that different overall.
I recommend learning Lisp or Scheme or related languages because they have a lot of good conceptual resources to learn from. But maybe that’s my background talking, I loved SICP. I learnt SO much from studying Common Lisp in the last year. Of course it helps that it has a great language specification.
In terms of choosing a language, standard library matters a lot. Hence the explosion of JS due to NPM and also being in browser. I’m suprised SWIFT is not more popular, given Apple’s place in the ecosystem. I really liked programming in Swift, very enjoyable language. And it has generic functions too!
rossmohax|4 years ago
For instance in Scala you'll likely need to know cats-effect or zio ecosystem more than stdlib. Likewise for Rust, where futures and async stack (tokio, asyncstd) are outside stdlib.
TexanFeller|4 years ago
Waterluvian|4 years ago
1. A good look at long lasting, durable pure python.
2. A good look at long lasting, durable C implementations of python (dict is the core of Python. Read the source!)
3. A look at a bunch of libraries that basically never get used and a sense of how they compare to popular third party libraries. (Doing this is why I’ll never complain when a language’s stdlib is small. I get it now.)
er4hn|4 years ago
bmitc|4 years ago
unknown|4 years ago
[deleted]
CRConrad|4 years ago
(Honest first-split-second reaction.)
pantulis|4 years ago
blowski|4 years ago
ofou|4 years ago
I think is a good idea to read them, but I'd like them to be more concise.
[1]: https://docs.google.com/spreadsheets/d/1U6_NxSxcFC3FPqtPB8eI...
lcrmorin|4 years ago
marsdepinski|4 years ago
slmjkdbtl|4 years ago
Const-me|4 years ago
In C#, standard library is awesome, and indeed a good starting point for people learning the language.
On the other end of the spectrum there’re languages like C++ with these horrible templates, or Rust with tons of unsafe code. Adopting patterns or coding style from these standard libraries is not the best idea.
praveen9920|4 years ago
bjarneh|4 years ago
Nikola Motor - glad to see something good coming out of that scam...
aghilmort|4 years ago
unknown|4 years ago
[deleted]
ryloric|4 years ago
Kye|4 years ago
ramesh31|4 years ago
the__alchemist|4 years ago
amitport|4 years ago
epolanski|4 years ago
bexsella|4 years ago
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Edit:
And the Web API reference (which is what I was actually thinking of when I posted): https://developer.mozilla.org/en-US/docs/Web/API
balnaphone|4 years ago
simonebrunozzi|4 years ago
jeffrallen|4 years ago
sydthrowaway|4 years ago
savant_penguin|4 years ago
ChrisRackauckas|4 years ago
adgjlsfhk1|4 years ago
exdsq|4 years ago
7kmph|4 years ago
shp0ngle|4 years ago
rramadass|4 years ago
I learnt more about C and C++ from studying Plauger's The Standard C Library and Plauger/Stepanov's The C++ Standard Template Library. I also remember learning Object-Oriented Framework design from MFC Internals.
unknown|4 years ago
[deleted]