> The decision to adopt or avoid a language is always a mix of their perceived formal power (“Does this language even have this particular feature?”), employability (“Will this language get me a job?”), and popularity (“Does anyone important use this language anymore?”).<p>I'm a statistician. I've always wondered what it's like to grapple with the question of what programming language to use. In statistics, the choice is very obvious: use R. If that's not fast enough, use Rcpp. This is definitely a good thing, because all academic statisticians in a certain age range speak R, so interfacing work is not so painful, but maybe a bad thing because statisticians don't really understand the pros and cons of many languages? If Julia blows up, maybe we will have to get smart on these differences.<p>Granted the workflow is probably the same in any language: clean data, model data, graph data.
This article’s introduction includes:<p>> Diving deeper into program language theory is a great way to grow as a developer.<p>But does anything in this article really count as programming language theory? I’ve always considered PLT to mean things like type theory and formal semantics, which are quite separate from the practical implementation of compilers.<p>I’ve been put off designing a programming language, even a dynamically-typed scripting language, because I’m just not that interested in PLT. I’m much more interested in the subject of this article (the implementation of compilers and interpreters) than in the math behind type systems.<p>Do you think it’s possible to design a successful language without knowledge of PLT? Or should I stick to working on compilers for existing languages?
This is the first time I've heard of Increment. Is there a way to financially support them without having dead trees sent to me? Really impressed by the quality and thought that's gone into these articles.
I'm almost done with "Writing an interpreter in Go"[0] which I highly recommend. Even though it's less theoretical than the usual books in this area I learned a ton of practical stuff and a lot of things I "knew" from more theoretical sources make now much more sense. Looking forward to work through the second book of the series [1] which is aimed at compilers.<p>[0]:<a href="https://interpreterbook.com/" rel="nofollow">https://interpreterbook.com/</a><p>[1]: <a href="https://compilerbook.com/" rel="nofollow">https://compilerbook.com/</a>
Good stuff. One minor issue I had was that the GitHub links don't point to specific commits, so they've decayed: either they point at different code now, or the files they referred to are gone now :(
I think this is exactly what people need. That is, something quick and a bit humorous yet informative; something that gives you a high-level overview, so that you don't get baffled by the 1000-page thick Dragon book or whatnot.
I'm thoroughly entertained by seeing "ALSO IN THIS ISSUE: It doesn’t have to be Turing complete to be useful" right next to "The decisive factor in what makes something a programming language (or not) is known as Turing completeness."