5 ms·

Designing a Programming Language (2015)

88 points by tmfi 6y ago

merricksb 6y ago
Original discussion in 2015, for those curious: https://news.ycombinator.com/item?id=9901282 https://news.ycombinator.com/item?id=9901282
codr7 6y ago
The most important advice in my mind would be to waste as little time as possible on the parser; Forth is trivial, Lisp a tiny bit more involved. https://github.com/codr7/liblgpp https://github.com/codr7/liblgpp
- gjm11 6y ago
  If you care at all about getting people to _use_ your language (which you might not, as with Haskell's "Avoid popularity at all costs" slogan) then I don't think this is good advice. Both Forth and Lisp have seen less adoption than their aficionados think they deserve as a result of their offputting-to-muggles syntax. In both cases, arguably the most important merits of the language actually necessitate the unusual syntax. That might mean that Lisp and Forth couldn't have done better with more conventional syntax. If so, what that means isn't that you should after all give minimal attention to the parser; it's that in some cases a syntax that's very simply parseable might be a good one -- but, unless you get very lucky, you will only discover that by thinking deeply about your syntax rather than doing something minimal and hoping it ends up having subtle merits like those of Forth and Lisp.
  - codr7 6y ago
    They're simply discrete initial steps on the way to a more elaborate syntax, it's not either or. Parsing nearly killed my interest in programming languages, it's rarely the part that get people excited.
neonological 6y ago
What's always missing from these is the type checker.
- enriquto 6y ago
  In many reasonable languages there are no types (or, equivalently, there is a single type) thus it may be perfectly OK to not have a type checker.
  - otabdeveloper4 6y ago
    You're just delegating the type checking to an ad-hoc runtime. It's always better to check types rigorously and as soon as possible.
    - enriquto 6y ago
      This is not what I meant. I mean a language such as core matlab/octave, where the only "type" to speak of is the multi-dimensional array of floats.
      - BoiledCabbage 6y ago
        Does matlab/octave prevent you from performing invalid operations on arrays of different/incompatible ranks/dimensions? If so, then it's doing runtime type checking.
        enriquto 6y ago
        Good point. Yes, not all operations are defined, and it may result in a runtime error.
      - otabdeveloper4 6y ago
        Octave has strings and they are checked at runtime: octave> strtrim(" hello world ") ans = hello world octave> strtrim([1,2,3,4]) error: strtrim: S argument must be a string or cellstring error: called from strtrim at line 79 column 5
awb 6y ago
I hope that at some point language design will become a self-contained discipline. It reminds me of back in the early days of the Internet when developers were the only web designers. Most programming languages are designed by the same people implementing them. The common critique is that language designers might create a syntax incompatible with the limitations of the computer itself, but that’s the same challenge web designers had to learn in designing something that will look great in the constraints of the browser, and not just look good in Photoshop.
- jhardy54 6y ago
  Programming language theory is its own branch of computer science, but I'm not sure whether that qualifies as a "self-contained discipline": https://en.wikipedia.org/wiki/Programming_language_theory https://en.wikipedia.org/wiki/Programming_language_theory Or, do you mean that linguists might design programming languages without ever having learned how to program?
  - seanmcdirmid 6y ago
    Programming language theory is a hugely different field from programming language design. One is a theory (lots of math and proofs), the other is much more similar to being a UX designer (a lot of usability issues to work out where theory doesn’t help). It gets confusing because many PL designers are also PL theorists, but it isn’t true in every case.
  - awb 6y ago
    > Or, do you mean that linguists might design programming languages without ever having learned how to program? Yes
- kazinator 6y ago
  Human disciplines are generally organized around something that generates a high volume of repeating work. E.g. we have civil engineering as as discipline because bridges have to be designed (or existing designs have to be adjusted and instantiated to new situations). Such a discipline is practiced everywhere; every populated region in the world has civil engineers cranking out work. We don't need similar discipline which cranks out programming languages. To some measure, we need programming languages in which regular programmers can crank out domain specific notations to suit whatever work they are doing. Engineers themselves use languages for designing and communicating their work. Civil engineers have blueprints with their notations; electrical engineers have schematics, SPICE netlists; and so on. They don't need a sub-discipline to continuously crank out new kinds of these languages, right? Similarly software engineering has languages. It has a lot more of them than electrical or civil engineering, but that's just the consequence of those languages not only being the product of software engineering as well as the production tool. Non-software engineering also produces tools which are used in engineering. We have a myriad of tools for all sorts of situations. Machinists produce tools, which can be used by machinists to produce tools; that's a bit like computing. In computing, there are tools other than languages though. For instance, there are API's and libraries. There is still a lot of work, for instance, in people who integrate platforms: bring up new systems on a chip, and move code to next generation systems. New API's are needed much more than new languages, and so the case can be made that API's are more like tools than languages. Machinists generally don't need a new design language in order to make new tools. A new tool is an adapter between a process (like construction, maintenance) and a new situation; it's like a HAL. A differenty shaped screwdriver or whatever isn't a new language.
IncRnd 6y ago
Yea. This page isn't about Designing a Programming Language. The page is about Implementing an Interpreter of a Programming Language without any actual design, just implementation.
rurban 6y ago
One huge mistake admitted very early on: "Our". This smells like design by committee. Or he thinks of himself like a kind of pope. The most important point in designing a programming language is to avoid design by committee. Use a team for feedback, tests or docs. But nothing else. He didn't even mention that principle.
- kgeist 6y ago
  It's "author's we", or "academic we". It's pretty common. We in this sense often refers to "the reader and the author".

88 points by tmfi 6y ago

Original discussion in 2015, for those curious: https://news.ycombinator.com/item?id=9901282 https://news.ycombinator.com/item?id=9901282

codr7 6y ago

The most important advice in my mind would be to waste as little time as possible on the parser; Forth is trivial, Lisp a tiny bit more involved. https://github.com/codr7/liblgpp https://github.com/codr7/liblgpp

gjm11 6y ago
If you care at all about getting people to _use_ your language (which you might not, as with Haskell's "Avoid popularity at all costs" slogan) then I don't think this is good advice. Both Forth and Lisp have seen less adoption than their aficionados think they deserve as a result of their offputting-to-muggles syntax. In both cases, arguably the most important merits of the language actually necessitate the unusual syntax. That might mean that Lisp and Forth couldn't have done better with more conventional syntax. If so, what that means isn't that you should after all give minimal attention to the parser; it's that in some cases a syntax that's very simply parseable might be a good one -- but, unless you get very lucky, you will only discover that by thinking deeply about your syntax rather than doing something minimal and hoping it ends up having subtle merits like those of Forth and Lisp.
- codr7 6y ago
  They're simply discrete initial steps on the way to a more elaborate syntax, it's not either or. Parsing nearly killed my interest in programming languages, it's rarely the part that get people excited.

neonological 6y ago

What's always missing from these is the type checker.

enriquto 6y ago
In many reasonable languages there are no types (or, equivalently, there is a single type) thus it may be perfectly OK to not have a type checker.
- otabdeveloper4 6y ago
  You're just delegating the type checking to an ad-hoc runtime. It's always better to check types rigorously and as soon as possible.
  - enriquto 6y ago
    This is not what I meant. I mean a language such as core matlab/octave, where the only "type" to speak of is the multi-dimensional array of floats.
    - BoiledCabbage 6y ago
      Does matlab/octave prevent you from performing invalid operations on arrays of different/incompatible ranks/dimensions? If so, then it's doing runtime type checking.
      - enriquto 6y ago
        Good point. Yes, not all operations are defined, and it may result in a runtime error.
    - otabdeveloper4 6y ago
      Octave has strings and they are checked at runtime: octave> strtrim(" hello world ") ans = hello world octave> strtrim([1,2,3,4]) error: strtrim: S argument must be a string or cellstring error: called from strtrim at line 79 column 5

awb 6y ago

I hope that at some point language design will become a self-contained discipline. It reminds me of back in the early days of the Internet when developers were the only web designers. Most programming languages are designed by the same people implementing them. The common critique is that language designers might create a syntax incompatible with the limitations of the computer itself, but that’s the same challenge web designers had to learn in designing something that will look great in the constraints of the browser, and not just look good in Photoshop.

jhardy54 6y ago
Programming language theory is its own branch of computer science, but I'm not sure whether that qualifies as a "self-contained discipline": https://en.wikipedia.org/wiki/Programming_language_theory https://en.wikipedia.org/wiki/Programming_language_theory Or, do you mean that linguists might design programming languages without ever having learned how to program?
- seanmcdirmid 6y ago
  Programming language theory is a hugely different field from programming language design. One is a theory (lots of math and proofs), the other is much more similar to being a UX designer (a lot of usability issues to work out where theory doesn’t help). It gets confusing because many PL designers are also PL theorists, but it isn’t true in every case.
- awb 6y ago
  > Or, do you mean that linguists might design programming languages without ever having learned how to program? Yes
kazinator 6y ago
Human disciplines are generally organized around something that generates a high volume of repeating work. E.g. we have civil engineering as as discipline because bridges have to be designed (or existing designs have to be adjusted and instantiated to new situations). Such a discipline is practiced everywhere; every populated region in the world has civil engineers cranking out work. We don't need similar discipline which cranks out programming languages. To some measure, we need programming languages in which regular programmers can crank out domain specific notations to suit whatever work they are doing. Engineers themselves use languages for designing and communicating their work. Civil engineers have blueprints with their notations; electrical engineers have schematics, SPICE netlists; and so on. They don't need a sub-discipline to continuously crank out new kinds of these languages, right? Similarly software engineering has languages. It has a lot more of them than electrical or civil engineering, but that's just the consequence of those languages not only being the product of software engineering as well as the production tool. Non-software engineering also produces tools which are used in engineering. We have a myriad of tools for all sorts of situations. Machinists produce tools, which can be used by machinists to produce tools; that's a bit like computing. In computing, there are tools other than languages though. For instance, there are API's and libraries. There is still a lot of work, for instance, in people who integrate platforms: bring up new systems on a chip, and move code to next generation systems. New API's are needed much more than new languages, and so the case can be made that API's are more like tools than languages. Machinists generally don't need a new design language in order to make new tools. A new tool is an adapter between a process (like construction, maintenance) and a new situation; it's like a HAL. A differenty shaped screwdriver or whatever isn't a new language.

IncRnd 6y ago

Yea. This page isn't about Designing a Programming Language. The page is about Implementing an Interpreter of a Programming Language without any actual design, just implementation.

rurban 6y ago

One huge mistake admitted very early on: "Our". This smells like design by committee. Or he thinks of himself like a kind of pope. The most important point in designing a programming language is to avoid design by committee. Use a team for feedback, tests or docs. But nothing else. He didn't even mention that principle.

kgeist 6y ago
It's "author's we", or "academic we". It's pretty common. We in this sense often refers to "the reader and the author".