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.<p>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.<p>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 (<a href="https://github.com/floooh/pacman.zig" rel="nofollow">https://github.com/floooh/pacman.zig</a>) and a home computer emulator (<a href="https://github.com/floooh/kc85.zig" rel="nofollow">https://github.com/floooh/kc85.zig</a>), 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.<p>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.<p>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<p>Yes, but also no.<p>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.<p>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.<p>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.<p>Through without a question you can learn a lot there, you just should be aware of the points above.
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.
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.<p>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.<p>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.<p>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.
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.<p>Protip: That doesn't change their mind, it just makes them hate Go.
This doesn’t seem like good advice to me, as others have already said.<p>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.<p>Some of Python’s standard library delegates to C code.<p>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.<p>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
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.
This is a classic academia-ish take. Consume a bunch of theory and regurgitate whatever you've read.<p>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.
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.<p>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 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.<p>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.
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.
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.<p>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.<p>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.
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.<p>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.
"The best way to learn a new programming language, just like a human language, is from example."<p>Certainly this is how I learn. Much more immediately useful than voluminous documentation.<p>However I am not sure every language has a standard library.<p>For example, Lua.<p>Also not sure every standard library is a model to follow.<p>For example, where feasible, I try to use and learn from djb's C functions instead of the "C standard library" ones.
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:<p>> 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.<p>- <a href="https://www.gnu.org/software/emacs/manual/html_node/eintr/On-Reading-this-Text.html" rel="nofollow">https://www.gnu.org/software/emacs/manual/html_node/eintr/On...</a>
The advice really only applies for very specific definitions of "learn".<p>Let me cite a single line from the MSVC implementation of the C++ standard library (<a href="https://github.com/microsoft/STL/blob/main/stl/inc/xtree" rel="nofollow">https://github.com/microsoft/STL/blob/main/stl/inc/xtree</a>):<p><pre><code> 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>>>;
</code></pre>
Also, good luck understanding this class member definition. Hope you figured out _Scary_val!<p><pre><code> _Compressed_pair<key_compare, _Compressed_pair<_Alnode, _Scary_val>> _Mypair;
</code></pre>
(Hint: Empty base class optimization.)
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.<p>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!<p>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).<p>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.<p>We also built a simple CPU from gates using an electronic simulator.<p>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 :-)<p>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.<p>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.<p>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.<p>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:<p>1. A good look at long lasting, durable pure python.<p>2. A good look at long lasting, durable C implementations of python (dict is the core of Python. Read the source!)<p>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.)
"Standard library" is a funny way of putting it; it's usually called a "literary canon"... Oh, <i>that</i> kind of language!<p>(Honest first-split-second reaction.)
I had a friend who said he enjoyed reading the PickAxe Book ("Programming Ruby") from end to end <i>each year</i>. That includes the whole Ruby stdlib!
The Docs of the standard library of Python equals approx. to a 1000 pages book. [1]<p>I think is a good idea to read them, but I'd like them to be more concise.<p>[1]: <a href="https://docs.google.com/spreadsheets/d/1U6_NxSxcFC3FPqtPB8eIm7BFV_bE25cFwLwF0TIsTJU/edit#gid=1659266541" rel="nofollow">https://docs.google.com/spreadsheets/d/1U6_NxSxcFC3FPqtPB8eI...</a>
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.
This depends on the language.<p>In C#, standard library is awesome, and indeed a good starting point for people learning the language.<p>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.
> The development is possible thanks to the community's effort and the continued support of 84codes, Nikola Motor Company...<p>Nikola Motor - glad to see something good coming out of that scam...
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, <a href="https://twitter.com/DotDotJames/status/1451656005155176454" rel="nofollow">https://twitter.com/DotDotJames/status/1451656005155176454</a>
I'd change the title to "To learn a new programming language..." - we shouldn't assume that "language" implies "programming", at least not in titles.