Hacker News Reader

> To go even further than standard library, read the language's source code. This is especially relevant for virtualized languages.

Yes, reading hundreds of thousands LoCs written in C/C++ is totally viable method of learning languages. ;)

Yes. I learned so much after I started reading source code. I discovered the history and implementation of many language features, including the more obscure ones which are the subject of many fun stackoverflow questions. I obtained a deeper understanding of the threading model. I developed a good sense for the performance cost of my code as well as the optimizations I can expect from the implementation. I was able to create libraries in C that can be loaded at runtime by the language. I was able to embed the language in C projects.

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 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".

What makes C somewhat hard to learn is pointers and strings. Apart from that it's so small that most fulltime C developers will touch upon the entire language on a regular basis.

C is hard because despite being a "small" language, it's full of all kinds of unintuitive rules and behaviour for beginners to stumble upon, and the language provides next to no assistance in avoiding the pitfalls. People have to learn C by making potentially dangerous mistakes, hopefully in code where they don't matter.

I'd recommend then read musl though and not that atrocity that is glibc

I also recommend musl. The code is just much more readable. I couldn't even find what I was looking for in glibc source code.

Out of curiosity, Blending together, even different paradigms, like APL, or Haskell?