To learn a new language, read its standard library
patshaughnessy.net
patshaughnessy.net
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.
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.
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.
Optimizations in standard libraries are generally good ones, and reading it can give a good idea of what is or isn't worth it.
(And if the standard library doesn't represent idiomatic use of the language, that's a red flag).
If emptiness is something that is so important you add extra branchpoints inside collections to check for it, there ought to be some way of disallowing emptiness or {nil,null}ness in the language itself.
Sure, it is nice for people who use the standard library, but it points to things in the language that perhaps should have been given some more thought.
Weather people have the skill to figure it out also doesn't matter as they normally don't have time to figure it out.
And even experienced programmers can get confused about bit hacks, sure temporary but that already a step price to pay which is seldomly worth it. It always comes with the risk of accidentally introduce a bug, even if your team only consists of senior devs. And it always hampers productivity.
If you think bit hacks are bug prone, needlessly complex, and not worth it, don't use them. But if your only argument is "junior may not understand", then no.
Newbies need to learn, if they always face newbie friendly code, they will be newbies forever. So yes, it takes time understanding a new technique, but it is an investment.
Later, when not-junior-anymore has to decide on an implementation, he then can chose the most appropriate among the many he saw, including bit hacks. It doesn't mean bit hacks are the best, or that he will use them, but because of his experience, he will make a more informed decision.
Note that I assumed code intended for professional developers. The situation is different if you are targeting non-specialists (ex: macros for end users) or if you are making example code.
If flipping the Nth bit inside an integer or a byte array is an "advanced" technique, unfit for "application programmers" then I'm not sure I want to work with "application programmers".
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?"
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.
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.
Or, try to add a non-trivial feature to the framework.
It seems to me like you've already solved the issue of "learning the framework" if your mental model of the framework is that solid.
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...
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.
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".
Yes, reading hundreds of thousands LoCs written in C/C++ is totally viable method of learning languages. ;)
This isn't something beginners should do, of course. It is a fact that it does lead to a much deeper understanding of things.
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.
Protip: That doesn't change their mind, it just makes them hate Go.
One was a JS guru who literally threatened 'I can walk across the street and get another job, you know.' And we let him, and both of us are happier for it.
So I do agree, don't join a team writing a language you hate.
Together with that, I agree that one should read the high literature before inventing a new writing style.
If you don't like language X, don't take a job writing language X.
JavaScript used to be a messy language "not fit for professional use" (see popular JS books from the year 2000 :shudder:), but it turns out most of the problem was how people were using it.
JS code being written today looks like an entirely different language compared to early idiomatic "JavaScripts" one could use to make pages "more dynamic".
People thought VBScript was more powerful. JavaScript was like that attention-seeking red-headed stepchild that you see at family reunions.
There's a good reason Douglas Crockford re-introduced JavaScript as "the wwwrld's most misunderstood programming language." He saw beauty within that others didn't.
Common Lisp, OTOH, has not... But styles of CL do change as do libraries, making your statement as applied to CL much more plausible.
Oh, and Python 3 should've been a new language.
The elite language in Rome was Greek.
gee, they didn't have go?
Sure that empire was doomed.
It's like saying, because an artist is using watercolors for this painting, they should therefore never do pencil drawings on other projects.
if that's "textbook java oop" with runtime polymorphism then that should definitely be avoided and is pretty much considered an anti-pattern nowadays
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.
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.
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.
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.
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...
> The article is a terrific example of basic analysis BTW.
Hahaha. It's some cherry picked examples and you're already claiming it's 'a terrific example of basic analysis'. The hyperbole is real in software.
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.
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.
https://github.com/llvm-mirror/libcxx/blob/master/include/ve...
I would not recommend anyone ever look through that as a way to learn C++. Heck just something as basic as a struct that stores two member variables is a 200 line of code horror show in C++:
https://github.com/llvm-mirror/libcxx/blob/78d6a7767ed57b501...
But, if choosing C++, at some point you will have to write code like that as a project matures and must target different compiler versions and platforms.
To the extent that one can learn how to write cross-platform efficient and generic C++ code, there is always a better example to learn from than the standard library.
struct foo { int a; int b; };
That's all. The thing you refer to is not a 'basic struct', it's complex standard library component.
C++ has enough complexity already, there's no need for you to add additional false claims. The thing you pointed to is the standard library version of std::pair, written to be as platform-independent, performant and correct as possible. But if, as a programmer, you need a 'simple struct with two elements', as you described it, you just define a struct and add the two elements, and that's it. Or you just declare it as std::pair<int, int>.
Your statement that declaring a struct with two members in C++ takes 200 lines is just completely false.
If one wishes to learn how to represent a pair of values in a generic, cross platform and efficient manner, one should NOT consult the standard library to learn such a thing precisely because the standard library includes incredibly irrelevant and archaic details that are entirely unneeded to understand how to idiomatically represent a pair of values.
Your claim that the standard library is written to be cross platform couldn't be further from the truth. The standard library is written to work with a specific compiler, and often times only with a specific version of a compiler on a specific platform. While it's possible to use libstdc++ with clang, it's not possible to use libc++ with GCC. Furthermore no compiler other than MSVC fully supports MSSTL.
The idea that the C++ standard library is a good way to understand in concrete and idiomatic terms how to represent a generic pair of values is simply bad advice.
If you wish to counter that position then you are welcome to do so, but so far you are arguing something entirely different from the actual topic at hand. The argument I'm making isn't that you need 200 lines of code to represent a pair of values, it's that if you tried to understand how to represent a pair of values by consulting the standard library, you'd need to sift through 200 lines of code because the standard library is written in an incredibly complex manner that is entirely unnecessary in order to learn or understand idiomatic C++.
In short, the statement " To learn a new language, read its standard library", is bad advice for someone who is new to learning C++.
Reading C++ standard library gives you headache, and doesn't really teach you how to write C++ in a normal application. For a beginner, this is an impossible approach.
Reading Python standard library means reading C half of the time. Useful for some seasoned Python developers, but not for new comers who want to read Python.
At the end of the day, standard libraries aren't written to teach, and some being a good teacher is a coincident. When you are learning a new language, you really have no idea whether the standard library is a good source for beginners.
I'd suggest a less poetic, more pragmatic approach to learning a new language: ask the most active forum of the language, and use the most common learning materials.
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.
I am most familiar with scientific computing and GIS applications — python is miles ahead of golang in ecosystem support in those domains.
I mean, I still write a lot of Perl, but everyone else would be too.
It's like a modernized C with a good implementation and out-of-the-box no-nonsense tooling, and the tricky bits left out. Nothing really new to see, but there was nothing really like it when it took off. Very utilitarian. Rust, Java, C#, C++ - those are all very 'complex' or 'bloated' in many different ways to an avid Go programmer.
I'm not promoting Go (I personally don't like it), I'm just trying to understand it's appeal and popularity and what is different about it. Quality and completeness of implementation, tooling, etc. by having a big company behind it also helps of lot of course - but it isn't sufficient.
Maybe my "most of the time" was too strong and I ignored big domains that I don't know. But for the part that I relatively know (web stuff mostly), safety and speed together matters a lot. The thing is, since unsafety tends to be viral (an unsafe part of your stack can compromise everything), people get very paranoid about "unsafe languages".
Garbage collection and bounds checking is big sticking point for systems / high performance programming, and to an extent real-time programming.
As far as I can tell, Rust should be about the limit of what's possible if you want to have your cake and eat it too. But I'll doubt it'll ever replace C for speed-critical applications.
I'd recommend starting with Pascal, because of the comprehensive and high quality standard libraries (or "frameworks" -- see related recent HN discussion...) in Free Pascal and Delphi, and because Free Pascal can target a lot of different OSes. OTOH, a downside might be that you learn (to rely on) too much of the FCL/VCL in stead of just syntax, so you get confused at the lack of those libraries in Ada; that could speak for taking it the other way around.
TL;DR: IMO, in a way that's perhaps closer to two new languages to learn than three.
How would you categorize No Starch Press, Manning, OReilly as per this rubric ?
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.
In general, I'd heavily recommend studying the usage of lambdas & streams. And Optional<T>. ;)
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.
[0] https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated...
To a decent extent yeah, though I would emphasize the issue isn't quite being as fast as possible (although in some cases it is, but also see I/O streams...), but rather having near-absolute correctness, and achieving high performance as a secondary goal. You can usually find a faster third-party implementation of anything in the C++ standard library. The problem is third-party implementations always cut corners somewhere, whether it's strong exception-safety, proper trait/concept handling, thorough testing of rare edge cases, extensibility/customizability, or other stuff. Even the syntactic complexity rises as a result, let alone the complexity of the actual semantics. (Even minor stuff like using difference_type/size_type instead of ptrdiff_t/size_t makes things more verbose and harder to read in the standard library; third-party implementations would often opt for the latter.)
I have found the Rust std lib to be a great resource. Much of the unsafe is necessary because there is literally no other way to build up abstractions like Box or certain data structures without it. Obviously once those are written though, you want to build on top of them where possible and not use unsafe.
It's probably important to delineate between a good example of application code vs library code also. The std lib is not going to help much with application code.
Thanks for the list
The frustrations people have with it are sometimes up to the point where they begin writing everything from scratch…
([a b c d])
([a b & more])
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.
At the moment since Zig isn't complete you aren't going to find documentation that is either. Particularly for newcomers.
I admittedly know C very well, but assuming you already know a language with a C-like syntax (C++, Java, JavaScript, C#, Rust, etc.) most things like functions, control flow, variables, statements map to Zig with only small syntactic differences.
One thing that may be difficult to learn not knowing C is working with strings, since they are just arrays of bytes. Most other languages have a string type, but Zig is much more like C in that strings are null-terminated fixed-sized arrays of bytes.
For instance, I imagine the x86_64 register allocation does some variant on graph coloring for register allocation, with an additional pass to assign lettered registers (rax, rbx, etc.) to the most heavily used registers, since using higher numbered registers requires a REX prefix byte. In addition, many instructions have more compact encodings when eax/rax is the destination register. At a minimum, excess REX prefixes take up instruction cache space. There's no parallel for aarch64, so there's no sense in implementing logic to try and make sure the low-numbered aarch64 registers are used more. (Though, on 32-bit ARM with Thumb/Thumb2, only a subset of registers are available, so there is a similar optimization for 32-bit ARM targets that support Thumb/Thumb2 when optimizing for space.)
I imagine there are better examples, but my point is that some optimizations are useless on some architectures.
Oh, of course! That must be what was meant. Sorry.
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.
Sorry, stupid question: Is this derived from the old Crystal Reports, or something completely separate?
K&R is a much more meaningful guide than unistd.h.
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.
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.
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 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...
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):
using _Scary_val = _Tree_val<conditional_t<_Is_simple_alloc_v<_Alnode>, _Tree_simple_types<value_type>,
_Tree_iter_types<value_type, typename _Alty_traits::size_type, typename _Alty_traits::difference_type,
typename _Alty_traits::pointer, typename _Alty_traits::const_pointer, value_type&, const value_type&,
_Nodeptr>>>;
_Compressed_pair<key_compare, _Compressed_pair<_Alnode, _Scary_val>> _Mypair;
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).
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.
That being said, for Erlang, I think this is a good idea. I learned a lot when reading the standard library.
That shows you call sequences in context, rather than just getting lost in the code.
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.
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...
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!
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.
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 don't think stdlibs should be barren, but I completely get the ideas of languages like Rust that want to include only the most obvious of candidates and leave the rest for the community to organically evolve.
(Honest first-split-second reaction.)
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...
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.
Nikola Motor - glad to see something good coming out of that scam...
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
JS is a bit odd here, possibly for good reasons (ubiquity + dynamic nature of the lang itself might mean runtime considerations override any degree of self-hosting), but it basically means it's not possible for standard definitions of standard library. So the question becomes... what are some masterful libraries written in JS?
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.