> 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?”).
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.
Granted the workflow is probably the same in any language: clean data, model data, graph data.
The bulk of this article is more about creating your own programming language to solve a particular problem or set of problems. Less about choosing between general purpose programming languages. Does your code often require the same boilerplate to get going? Do you have common tasks which are error-prone? There are syntactic or programming design reasons to use a particular language, or maybe the reason could be performance. Think of tensorflow for example, maybe it's familiar for some R programmers. Code written in a language designed for a particular purpose can be very elegant. I like [1] as an example.
A big drawback of R is that you can't embed it into a commercial application due to the GPL licensing (without releasing your source code). It's a fantastic language ecosystem though.
> Diving deeper into program language theory is a great way to grow as a developer.
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.
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.
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?
As someone who also just wrote toy compilers/interpreters:
I think it is a valuable thing to just dive into a subject that quite obviously interests you so much as long as you are humble about it.
At some point you change/tweak/break something. Then your humble instinct will say: "I bet this is a common problem, let me research it". And so you get deeper understanding of what you do in a fun and tangible way.
If that at some point means you get to read PLT about type theory and formal semantics, then so be it. But at this point you'll know much more about the 'why' and can assess/relativize the purpose, importance and relevance of a particular subject.
> But does anything in this article really count as programming language theory?
It's a casual magazine - give it a break.
> I’ve been put off designing a programming language, even a dynamically-typed scripting language, because I’m just not that interested in PLT.
Many (most) successful languages were designed by people who either don't know anything about theory, or who do but don't chose to employ it. It doesn't seem to be a showstopper in practice.
I think PLT is generally broad enough to include anything related to making (vs using) programming languages — the more practical topics like compiler/interpreter construction, VM implementation etc seem to obviously qualify despite not necessarily being very formal.
Concretely, you can definitely design and implement your own dynamically-typed scripting language without knowing anything about type systems or formal semantics.
Yes, it's possible. You'll reach diminishing returns in the language value much quicker without some background in types and semantics. But that point might come long after you achieved your goal. So, have at it and enjoy exploring.
Oh, goodness, yes. Remember: BASIC was successful!
It depends on your criteria for "success," of course, but creating languages has been one of the most rewarding aspects of my interaction with computers over my life, don't miss out!
Programming language design for humans is a completely different thing from PLT. It's more about usability, HCI, psychology. And if by success you mean popularity or any metric that includes productivity of the language, understanding of usability will definitely help you there, but knowledge of PLT will almost certainly hurt it, since it makes you think that a lot of PLT ideas are acceptable and usable.
The idea of a software magazine is very cool. We need to go back to 70's era when magazines were extremely high quality (atleast the ones we remember - BYTE magazine, for e.g.).
I find the excessive design a bit offputting. It's beautiful, nevertheless.
There’s a wonderful software magazine in Japan called “Software Design” that is complete with code examples and tutorials on various topics, including web programming (both front-end and backend), Python development, Linux system administration, databases, and much more. It’s issued monthly and has been published since 1990, constantly keeping up to date with the latest technologies. The latest edition features AWS, storage, and containers.
I remember poring over BYTE issues desperate for any technical detail! Issues that stood out: one on data compression and the one about the Taos Operating system.
MSJ (Microsoft Systems Journal) was another good one!
Likewise; and it looks nicely put together. The article just skims the surface — classic magazine-style, I suppose — but I’m tempted to subscribe if it covers a wide range of software engineering topics.
If anyone here reads this regularly, is it worth it?
I think so. Even if it's a little watered down at times, it's nice to have the strong focus on a given topic every time. It's also just nice to be able to go back to specific issues. I like to think of them as discussion starters: you can share them with your team, and do a little bit of a deeper dive into any of the given topics. It's really helpful to see some companies of various size's opinions/organization on specific issues(the architecture issue has a great example: https://increment.com/software-architecture/architecture-at-...).
It's also pretty spread out between issues(quarterly) so it's not very spammy.
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.
They're really good books specially if you want to program in a "modern" language but I personally couldn't stomach the code style nor the TDD focus. I'm probably being really unfair to the author, so please don't let this be a deterrent!
I personally enjoyed `Modern Compiler Implementation in ML` and Crenshaw's tutorial [0] There's also a Forth translation [1] if you're into that :)
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.
A significant chunk of what the Dragon book covers is state machine theory, what you need to know if you're writing a compiler-compiler like yacc. The state of the art in code generation had moved on even for the edition I read in college back in 2004 or so, so the tail end of the book isn't super relevant. IMO it was never a good book for practical compiler implementation. It's better as an academic reference for compiler theory, especially DFA, NFA, PDA etc. construction.
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."
I took cs143 at Stanford (so not the online version) and found it incredibly satisfying and enriching. Not only did I gain an understanding of well compilers, but programming languages, parsers, and real, applied uses of CS theory.
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.
Granted the workflow is probably the same in any language: clean data, model data, graph data.