13 ms·

So You Want to Write Your Own Language (2014)

173 points by rspivak 11y ago

talles 11y ago
> My career has been all about designing programming languages and writing compilers for them. Anyone knows which languages/compilers the author has worked on? (I'm not trying to validate its arguments, it's just out of curiousity)
- anewhnaccount 11y ago
  Digital Mars C, C++ and D compilers
  - stevoo 11y ago
    To add more context to that https://en.wikipedia.org/wiki/Walter_Bright https://en.wikipedia.org/wiki/Walter_Bright Although i have never though of actually write a language i can agree on those. Especially Minimizing keystrokes. I want the language to be verbose and easy to understand. Dealing with thousands of line trying to figure out what is going on there it is essential to easily pick up what is going on !
    - _Codemonkeyism 11y ago
      Write once, read often.
    - dozzie 11y ago
      > I want the language to be verbose and easy to understand. So, you basically want to write in assembler, which printed is very verbose, and it's very easy to understand each separate instruction. What I want is the language to minimize language entities used to do a task (from parser's perspective those would be AST nodes), and I want those tasks to be general and high-level. This is what makes source code comprehensible, not verbosity.
      - Jtsummers 11y ago
        Each instruction may be easy to understand, but the programs are not easy to understand at scale. So that's probably not what stevoo wants.
        dozzie 11y ago
        Of course it's not (or rather, I would be surprised if it was), but he phrased it in very wrong way.
      - ternaryoperator 11y ago
        >> I want the language to be verbose and easy to understand. > So, you basically want to write in assembler, which printed is very verbose, and it's very easy to understand each separate instruction. Please don't do that: You took what he said, jumped to the most extreme case, and then attributed it back to him. He never implied that he wanted to write in assembler. In fact, based on the part you didn't quote, I think he would not want to work in assembler.
        dozzie 11y ago
        You may dislike this form, but it shows exactly why stevoo's opinion is formed on wrong basis. > In fact, based on the part you didn't quote, I think he would not want to work in assembler. I have hard time to understand what he meant in this sentence: > Dealing with thousands of line trying to figure out what is going on there it is essential to easily pick up what is going on ! Is it a praise of having plenty of code for a simple thing? Or is it a rant?
    - dwc 11y ago
      For an analogy, before there was anything like modern math notation people would write out the problem and solution in plain language. On one hand, that made it very accessible as long as you knew a few terms like "sum". On the other hand, the reader has to build a relatively small mental model out of a lot of words. Is it better to concentrate hard on a system of equations taking 1/4 of a page (with lots of whitespace) until you grok it, or read five pages of prose at fairly normal speed and try to build a mental model of it? Which better confers the ability to quickly come to the realization of something like "that's a parabola" or "the minimum of that function is obviously seven" or whatever? Analogies are only so useful, but I think there are enough parallels there to shed some light.
      - Jtsummers 11y ago
        Right, but your verbose example reduces ease of use. It's two axes. J is not verbose, but is impenetrable (certainly to a novice, others more familiar see a lot of benefits to it). Ada is fairly verbose, but is pretty easy to understand. A page of Ada code is probably a handful of lines, mostly to aid in clarity, of J code. Though the Ada code has type safety that the J code lacks. Assembly, as someone else referenced, is very verbose, but hard to understand once you get beyond a certain scale.
- melling 11y ago
  Did you try using Google before asking? I didn't get to hit return on my iPad before I had the answer since he had a Wikipedia entry: https://en.m.wikipedia.org/wiki/Walter_Bright https://en.m.wikipedia.org/wiki/Walter_Bright
- noblethrasher 11y ago
  The author is also an HN denizen: https://news.ycombinator.com/user?id=WalterBright https://news.ycombinator.com/user?id=WalterBright
scriptproof 11y ago
Do not know why this old page is revived again, but a better title would be "So you want to write you C or C++ like own language?". Among other points is the trailing semicolon. If this is so good, then the authors of Go and Swift must be wrong.
- Randgalt 11y ago
  I don't think you can say one is objectively right or wrong. However, as someone who's programmed for nearly 40 years, the entire issue seems like a fetish. Would anyone choose a language solely based on whether separators were required or not? Is your productivity dramatically increased by the choice of required separators? Of course not. In functional languages there are some reasonable needs that make not requiring a separator useful. But, it does make the code harder to parse and harder to read. Go, for instance, is not a functional language. Making separators optional (sometimes) seems capricious. But, then, Go is rife with capricious choices.
  - astrobe_ 11y ago
    > Would anyone choose a language solely based on whether separators were required or not? Is your productivity dramatically increased by the choice of required separators? Of course not. It may if you have to switch between languages. Getting syntax errors because of dummy separators can be quite frustrating at times. So the choice is mandatory separator or optional separators. I designed a language once in which most punctuation characters where treated as blanks.
    - Randgalt 11y ago
      Every day I write in bash, Javascript, XML, JSON, Java, Scala and probably a few others. Trivial differences don't matter.
  - jerf 11y ago
    Go uses semi-colon insertion like Javascript does, albeit with the benefit of Javascript's experience to fix up the edges. Calling "adopting some of the syntax of arguably the most popular language" capricious is probably stretching a bit.
qwertyuiop924 11y ago
I actually think that easy parsing is something you should try for. the easier your language is to parse, the less edge cases there are, and simpler it is for programmers to understand. In short, I'd rather have Scheme than Ruby. But I seem to be in the minority...
- martincmartin 11y ago
  Also tools become much easier. There are few good refactoring tools for C++ because the language is almost impossible to parse. In fact, even generating tags for vim/emacs is nearly impossible.
  - pldrnt 11y ago
    My thoughts exactly, as someone who has spent quite some time creating a (usable and readable) LALR syntax that can do everything modern C++ does (plus named arguments, a null-coalescing operator and extension methods) and is currently writing a transpiler based on it, I hope more people share your concern :)
    - nickpsecurity 11y ago
      Anyone who used Modula-3... https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 ...knows that one can have key features of C++ for systems programming with an easy-to-parse, safer, and [for a time] more efficient language. The SPIN OS team even modified it with type-safe linking so one could hotload code into the OS. What I saw there was "hotload code into running system" w/ associated benefits during updates. Or safer, better JIT. ;) Anyway, combined with LISP-style macros & irritating parts removed (eg uppercase, verbosity), you get a system language that blows C++ away in productivity (esp w/ DSL's), compiler efficiency, maintenance, and possibly run-time efficiency. The world might have went in a different direction but they better be honest about parsing pain they created. And all the productivity opportunities lost due to that.
      - msie 11y ago
david927 11y ago
One thing abundantly clear is that syntax matters. I feel this is like reading 100 years ago about how to make your own new type of horse & buggy, with tips like "make sure the reigns are well-fitted," when what you want to invent is a car. The future doesn't belong to syntax because the future isn't text. The same people that would blanch at sending a string argument of "ONE" or "TWO" are indifferent about the fact that they send in "IF" to start a condition. The reason you wouldn't send in "ONE" or "TWO" is because it makes it stiffer, more brittle and harder to manage. What can we say about the software we write? That it's stiff, brittle and hard to manage. It's not that the future has no textual syntax at all, of course. An expression of 3+4*5 will always be easiest to express just that way. But we need to pull back from our gregarious, wide-mouthed babbling into something more meta, or I should say, more data, than text.
- bmm6o 11y ago
  To be fair, Dr Dobbs' audience is working engineers, not PL researchers, and even researchers haven't had much success in non-text languages.
  - david927 11y ago
    To be fair, if Dr. Dobbs doesn't have the audience for PLR, their article on "Write Your Own Language" should consist of two words: Please don't
- pjc50 11y ago
  Writing is approximately five thousand years old. Symbolic algebra is about a thousand. Text will be with us for our lifetimes.
- commentzorro 11y ago
  This is the ??? (I don't know what to describe it as) post here. You took the one sentence I just loved from the article and pooped on it. Then tried to tie it in with details of a non syntax related item and process. Next, you said a two character syntax for describing something as complex as an if statement was somehow too much burden?! Not sure what the future of programming languages is. But if humans are involved I suspect there will be a visual representation. And that means syntax. And that syntax will matter then just as it does now.
nickpsecurity 11y ago
It's a decent list but not enough. The real trick is being general purpose enough to handle low-level up to programming in the large while being comprehensible and easy for compiler to work with. In my field, highly-assured INFOSEC, you also want correctness and traceability for security purposes. I wrote an essay on a layered, bottom-up approach to constructing such a language here if anyone is interested: https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_423.html#c5828584 https://www.schneier.com/blog/archives/2014/05/friday_squid_... I'm also interested in feedback on my approach. It tries to solve probably a dozen problems at once with some basic principles and three, compatible languages.
- restalis 11y ago
  I'm not sure I understand the value of having tools to "downgrade" something to a lower level. I compare this "downgrading" with "compiling to C" - a feature that enables some languages to become useful on more than one platform just by riding on the back of the C language. Was it about this idea of having different layers so that one may care to really port only the lowest level when it comes to it? But then the scope you get on the lower levels is simply inferior compared to the one you get on higher level/layer in terms of optimization possibilities, partly because you are now forced to get from point A (source code) to point B (binary code) not directly but through a 3rd point - C (a lower level source code), which may hurt performance and other things. Did I misunderstood something?
  - nickpsecurity 11y ago
    It's an exploration so I was throwing "downgrading" out there. You almost guessed it all with portability and bringing on new programmers. Both arguments for that technique. Another, esp if compiler is written in an ML, is that code used to analyze, optimize, or translate lower layers of language can be re-used in compiler for high-level. Matter of fact, I think my default was to go to ASM with plugins for other stuff. That should prevent missed opportunities in optimization.
pjc50 11y ago
My own opinion about PL research is that programming is concept serialisation: the programmer has a model of the system (or part thereof) in their head, and the role of the language is to turn that into a byte sequence that is amenable to both being turned into machine instructions and being de-serialised into the heads of other programmers. But different programmers have different abstractions in their heads, and find different things intuitive. That's why things like ColorForth and APL exist; to a tiny fraction of people and problem sets they're intuitive, to the rest obtuse. I suspect this is why people keep thinking Lisp is going to take over the world despite 30+ years of this not happening.
auggierose 11y ago
He got the thing about using context-free grammars right. The final comment about not using generators is currently right, but will hopefully be wrong by the end of this year. :-)
toolslive 11y ago
Minimizing key strokes is seen as 'false', but it has actually been proven that one can write (debug, maintain,...) about 10 lines of code per hour. Those 10 lines can be 10 lines of assembly, 10 lines of c++ or 10 lines of haskell. Of course, you can do much more in 10 lines of haskell than you can do in 10 lines of assembly. It basically means you want to be work on the highest level of abstraction that you can afford. It also means that economy of expression is important. source: https://vimeo.com/9270320 https://vimeo.com/9270320
- Jtsummers 11y ago
  Probably more a warning against pre-mature optimization. If you can eliminate all ; in most, or even all, circumstances in otherwise C-like syntax, what do you gain? And most of the savings you see there are from having greater levels of abstraction available. Assembly = arithmetic. You have to explicitly state each step, and on its own there's no understanding of what you're operating on, they're all bits (numbers). C++ (ok, more C) = algebra. You have a bit more understanding of your structure, better names and concepts behind things (types = units, for instance). You're still operating on bits, but now most of those bits have a specifically, language encoded, meaning. Haskell = calculus. Not only are your bits typed, so are your functions (ok, technically also typed in C and kin syntaxes, but not usually as useful) and you can pass them around and modify them. EDIT: I'm more picking on the class of syntax available. When you include semantics OO languages offer a great deal more expressive power than most procedural languages. Probably should've just had C and not C++, but it is what I wrote. More generally what I should have written was towards language classes: assembly (as most primitive procedural language), structured procedural languages (C, Go, Algol, Ada, etc.), OO languages (Java, C++, Smalltalk, etc.) and functional languages (lisps, Haskell, ML-family, etc.). But then you have to break it down further. OO is not inherently more or less expressive than functional languages, it depends on the feature set of the OO and functional languages. Smalltalk is very expressive, easily comparable to the more expressive functional languages. Java, as it used to be, not familiar with developments post adding generics so I'm really rusty on it, was not so expressive. So a comparison between Smalltalk and Common Lisp would put them on a similar level of abstraction. But Common Lisp versus Java (again, with my outdated knowledge), Common Lisp is at a higher level of abstraction (both syntactically and semantically).
yongjik 11y ago
For my project, I found sticking to LALR(1) quite beneficial. Not that there's anything special about LALR(1): you could use LL(k) instead if you prefer. However, by sticking to a small, deterministic syntax (and making the parser generator complain loudly in case of ambiguity), I can easily find edge cases I've never thought about before it comes around to bite me. And, in most cases, it's trivial to slightly modify the syntax so that the undesirable ambiguity does not arise. It's the equivalent of static typing for syntax: it takes effort to make bison run successfully, but when it does, I know that my grammar is free of ambiguity.
StephenFalken 11y ago
LinuxWorld.com: What is your advice to designers of new programming languages? Dennis Ritchie: At least for the people who send me mail about a new language that they're designing, the general advice is: do it to learn about how to write a compiler. Don't have any expectations that anyone will use it, unless you hook up with some sort of organization in a position to push it hard. It's a lottery, and some can buy a lot of the tickets. There are plenty of beautiful languages (more beautiful than C) that didn't catch on. But someone does win the lottery, and doing a language at least teaches you something. Oh, by the way, if your new language does begin to grow in usage, it can become really hard to fix early mistakes.[0] [0] http://www.itworld.com/article/2826125/development/the-future-according-to-dennis-ritchie--a-2000-interview-.html?page=2 http://www.itworld.com/article/2826125/development/the-futur...
tikhonj 11y ago
I've always found it unfortunate how he, and others, implicitly define the success of a programming language as its popularity. A programming language can be incredibly interesting and useful to you and others without ever becoming fashionable—and that doesn't mean it has failed! I think there should be other metrics for success: a programming language can be useful to a dedicated community of experts, it can be useful to a single company, it can be great for a single use-case or even just great for you, it can push novel ideas or showcase a novel design philosophy, all without massive popularity or market success. (And it's not like most languages directly make lots of money anyhow.) Popularity is a poor proxy for quality, and quality matters all on its own. Keeping this in mind changes a lot of his suggestions, I think. Completely unrelated note: what the article calls "lowering" I've more commonly seen called "desugaring" and is, indeed, a powerful technique both in terms of implementation but also in terms of understanding a language—if a piece of syntax is pure sugar, you don't have to understand anything new, just how the syntax it desugars to works.
- kazinator 11y ago
  > "lowering" ... "desugaring" "expansion"? ".... syntax it expands to"
  - kibwen 11y ago
    In a language with macros that might be ambiguous, since there will usually be a phase called "macro expansion".
    - kazinator 11y ago
      That is correct. Expansion isn't necessarily macro expansion. But it's the same kind of thing and may even be be done in the same code walking pass (and possibly have to). (Since the constructs being expanded could be generated by macros, then if the expansions also use macros in their syntax, the two have to be interleaved.) The difference is minor: it's basically "does the code walker specially recognize this construct and invoke some code to expand it" versus "does the code walker recognize a macro call and invoke it to expand it".
krig 11y ago
I disagree with several of these. But I guess that's why 1) I am working on my own language, and 2) Walter Bright is a lot more successful at that than me. So yeah. He's probably right, and I'm probably wrong. However: I'm doing this entirely for my own pleasure, and I don't want success as he defines it (popularity means having to cater to the whims of others). Disagreements: I think minimizing keystrokes is important, and I think the notion that code is primarily read, not written, is idealistic but completely wrong. The purpose of programming languages is to be writable by humans and readable by machines. There is value in making them readable by humans and writable by machines, but only secondary value. I think there is value in easy parsing, if nothing else because every single editor out there can highlight your language even if it isn't popular. I think the focus on popularity as the measure of success is wrong. Tried and true is overrated. There are plenty of examples of programming languages that break the tried and true rules and are successful either because of this or despite this. Either way, it doesn't seem to matter as much as people seem to think, but staring too hard at the success of Java might make you think it does. Anyway, feel free to disagree with me, go ahead and design your own language. I sincerely hope you are successful, regardless of what your definition of success is.
- deleted 11y ago
  [deleted]
- kazagistar 11y ago
  In practice, writing code consists mostly of reading; either to (re)understand how some other part of a large system works, or to figure out why the code is incorrect.
  - PeCaN 11y ago
    I would argue that it's easier to understand short, even excessively terse, code than it is to understand long code. I can look at a few lines of Haskell and even though deciphering it may take me some time, the cognitive overhead of anything other than working out what the code is doing is very low (the most I'd have to do is look up some operators). I can see a significant chunk of logic all at once and piece together the system as a whole. Meanwhile I could look at 3 files full of Java and have no idea what the system is actually doing.
musesum 11y ago
> Regex is just the wrong tool for lexing and parsing Funny; I recently wrote an Island parser that extends Regex to create a token stream: https://github.com/musesum/Par https://github.com/musesum/Par Quoting the link to Rob Pike's post: > Consider finding alphanumeric identifiers. It's not too hard to write the regexp (something like "[a-ZA-Z_][a-ZA-Z_0-9]*"), but really not much harder to write as a simple loop Maybe I'm missing something, but does this suggest replacing a declaration with a procedure? Oh the horror!
andrewchambers 11y ago
The level of dedication is required is really high. I stumbled upon https://github.com/oridb/mc https://github.com/oridb/mc and found my new favourite language written entirely by one person over the course of many years.

173 points by rspivak 11y ago

> My career has been all about designing programming languages and writing compilers for them. Anyone knows which languages/compilers the author has worked on? (I'm not trying to validate its arguments, it's just out of curiousity)

anewhnaccount 11y ago
Digital Mars C, C++ and D compilers
- stevoo 11y ago
  To add more context to that https://en.wikipedia.org/wiki/Walter_Bright https://en.wikipedia.org/wiki/Walter_Bright Although i have never though of actually write a language i can agree on those. Especially Minimizing keystrokes. I want the language to be verbose and easy to understand. Dealing with thousands of line trying to figure out what is going on there it is essential to easily pick up what is going on !
  - _Codemonkeyism 11y ago
    Write once, read often.
  - dozzie 11y ago
    > I want the language to be verbose and easy to understand. So, you basically want to write in assembler, which printed is very verbose, and it's very easy to understand each separate instruction. What I want is the language to minimize language entities used to do a task (from parser's perspective those would be AST nodes), and I want those tasks to be general and high-level. This is what makes source code comprehensible, not verbosity.
    - Jtsummers 11y ago
      Each instruction may be easy to understand, but the programs are not easy to understand at scale. So that's probably not what stevoo wants.
      - dozzie 11y ago
        Of course it's not (or rather, I would be surprised if it was), but he phrased it in very wrong way.
    - ternaryoperator 11y ago
      >> I want the language to be verbose and easy to understand. > So, you basically want to write in assembler, which printed is very verbose, and it's very easy to understand each separate instruction. Please don't do that: You took what he said, jumped to the most extreme case, and then attributed it back to him. He never implied that he wanted to write in assembler. In fact, based on the part you didn't quote, I think he would not want to work in assembler.
      - dozzie 11y ago
        You may dislike this form, but it shows exactly why stevoo's opinion is formed on wrong basis. > In fact, based on the part you didn't quote, I think he would not want to work in assembler. I have hard time to understand what he meant in this sentence: > Dealing with thousands of line trying to figure out what is going on there it is essential to easily pick up what is going on ! Is it a praise of having plenty of code for a simple thing? Or is it a rant?
  - dwc 11y ago
    For an analogy, before there was anything like modern math notation people would write out the problem and solution in plain language. On one hand, that made it very accessible as long as you knew a few terms like "sum". On the other hand, the reader has to build a relatively small mental model out of a lot of words. Is it better to concentrate hard on a system of equations taking 1/4 of a page (with lots of whitespace) until you grok it, or read five pages of prose at fairly normal speed and try to build a mental model of it? Which better confers the ability to quickly come to the realization of something like "that's a parabola" or "the minimum of that function is obviously seven" or whatever? Analogies are only so useful, but I think there are enough parallels there to shed some light.
    - Jtsummers 11y ago
      Right, but your verbose example reduces ease of use. It's two axes. J is not verbose, but is impenetrable (certainly to a novice, others more familiar see a lot of benefits to it). Ada is fairly verbose, but is pretty easy to understand. A page of Ada code is probably a handful of lines, mostly to aid in clarity, of J code. Though the Ada code has type safety that the J code lacks. Assembly, as someone else referenced, is very verbose, but hard to understand once you get beyond a certain scale.
melling 11y ago
Did you try using Google before asking? I didn't get to hit return on my iPad before I had the answer since he had a Wikipedia entry: https://en.m.wikipedia.org/wiki/Walter_Bright https://en.m.wikipedia.org/wiki/Walter_Bright
noblethrasher 11y ago
The author is also an HN denizen: https://news.ycombinator.com/user?id=WalterBright https://news.ycombinator.com/user?id=WalterBright

scriptproof 11y ago

Do not know why this old page is revived again, but a better title would be "So you want to write you C or C++ like own language?". Among other points is the trailing semicolon. If this is so good, then the authors of Go and Swift must be wrong.

Randgalt 11y ago
I don't think you can say one is objectively right or wrong. However, as someone who's programmed for nearly 40 years, the entire issue seems like a fetish. Would anyone choose a language solely based on whether separators were required or not? Is your productivity dramatically increased by the choice of required separators? Of course not. In functional languages there are some reasonable needs that make not requiring a separator useful. But, it does make the code harder to parse and harder to read. Go, for instance, is not a functional language. Making separators optional (sometimes) seems capricious. But, then, Go is rife with capricious choices.
- astrobe_ 11y ago
  > Would anyone choose a language solely based on whether separators were required or not? Is your productivity dramatically increased by the choice of required separators? Of course not. It may if you have to switch between languages. Getting syntax errors because of dummy separators can be quite frustrating at times. So the choice is mandatory separator or optional separators. I designed a language once in which most punctuation characters where treated as blanks.
  - Randgalt 11y ago
    Every day I write in bash, Javascript, XML, JSON, Java, Scala and probably a few others. Trivial differences don't matter.
- jerf 11y ago
  Go uses semi-colon insertion like Javascript does, albeit with the benefit of Javascript's experience to fix up the edges. Calling "adopting some of the syntax of arguably the most popular language" capricious is probably stretching a bit.

qwertyuiop924 11y ago

I actually think that easy parsing is something you should try for. the easier your language is to parse, the less edge cases there are, and simpler it is for programmers to understand. In short, I'd rather have Scheme than Ruby. But I seem to be in the minority...

martincmartin 11y ago
Also tools become much easier. There are few good refactoring tools for C++ because the language is almost impossible to parse. In fact, even generating tags for vim/emacs is nearly impossible.
- pldrnt 11y ago
  My thoughts exactly, as someone who has spent quite some time creating a (usable and readable) LALR syntax that can do everything modern C++ does (plus named arguments, a null-coalescing operator and extension methods) and is currently writing a transpiler based on it, I hope more people share your concern :)
  - nickpsecurity 11y ago
    Anyone who used Modula-3... https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 ...knows that one can have key features of C++ for systems programming with an easy-to-parse, safer, and [for a time] more efficient language. The SPIN OS team even modified it with type-safe linking so one could hotload code into the OS. What I saw there was "hotload code into running system" w/ associated benefits during updates. Or safer, better JIT. ;) Anyway, combined with LISP-style macros & irritating parts removed (eg uppercase, verbosity), you get a system language that blows C++ away in productivity (esp w/ DSL's), compiler efficiency, maintenance, and possibly run-time efficiency. The world might have went in a different direction but they better be honest about parsing pain they created. And all the productivity opportunities lost due to that.
    - msie 11y ago

david927 11y ago

One thing abundantly clear is that syntax matters. I feel this is like reading 100 years ago about how to make your own new type of horse & buggy, with tips like "make sure the reigns are well-fitted," when what you want to invent is a car. The future doesn't belong to syntax because the future isn't text. The same people that would blanch at sending a string argument of "ONE" or "TWO" are indifferent about the fact that they send in "IF" to start a condition. The reason you wouldn't send in "ONE" or "TWO" is because it makes it stiffer, more brittle and harder to manage. What can we say about the software we write? That it's stiff, brittle and hard to manage. It's not that the future has no textual syntax at all, of course. An expression of 3+4*5 will always be easiest to express just that way. But we need to pull back from our gregarious, wide-mouthed babbling into something more meta, or I should say, more data, than text.

bmm6o 11y ago
To be fair, Dr Dobbs' audience is working engineers, not PL researchers, and even researchers haven't had much success in non-text languages.
- david927 11y ago
  To be fair, if Dr. Dobbs doesn't have the audience for PLR, their article on "Write Your Own Language" should consist of two words: Please don't
pjc50 11y ago
Writing is approximately five thousand years old. Symbolic algebra is about a thousand. Text will be with us for our lifetimes.
commentzorro 11y ago
This is the ??? (I don't know what to describe it as) post here. You took the one sentence I just loved from the article and pooped on it. Then tried to tie it in with details of a non syntax related item and process. Next, you said a two character syntax for describing something as complex as an if statement was somehow too much burden?! Not sure what the future of programming languages is. But if humans are involved I suspect there will be a visual representation. And that means syntax. And that syntax will matter then just as it does now.

nickpsecurity 11y ago

It's a decent list but not enough. The real trick is being general purpose enough to handle low-level up to programming in the large while being comprehensible and easy for compiler to work with. In my field, highly-assured INFOSEC, you also want correctness and traceability for security purposes. I wrote an essay on a layered, bottom-up approach to constructing such a language here if anyone is interested: https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_423.html#c5828584 https://www.schneier.com/blog/archives/2014/05/friday_squid_... I'm also interested in feedback on my approach. It tries to solve probably a dozen problems at once with some basic principles and three, compatible languages.

restalis 11y ago
I'm not sure I understand the value of having tools to "downgrade" something to a lower level. I compare this "downgrading" with "compiling to C" - a feature that enables some languages to become useful on more than one platform just by riding on the back of the C language. Was it about this idea of having different layers so that one may care to really port only the lowest level when it comes to it? But then the scope you get on the lower levels is simply inferior compared to the one you get on higher level/layer in terms of optimization possibilities, partly because you are now forced to get from point A (source code) to point B (binary code) not directly but through a 3rd point - C (a lower level source code), which may hurt performance and other things. Did I misunderstood something?
- nickpsecurity 11y ago
  It's an exploration so I was throwing "downgrading" out there. You almost guessed it all with portability and bringing on new programmers. Both arguments for that technique. Another, esp if compiler is written in an ML, is that code used to analyze, optimize, or translate lower layers of language can be re-used in compiler for high-level. Matter of fact, I think my default was to go to ASM with plugins for other stuff. That should prevent missed opportunities in optimization.

pjc50 11y ago

My own opinion about PL research is that programming is concept serialisation: the programmer has a model of the system (or part thereof) in their head, and the role of the language is to turn that into a byte sequence that is amenable to both being turned into machine instructions and being de-serialised into the heads of other programmers. But different programmers have different abstractions in their heads, and find different things intuitive. That's why things like ColorForth and APL exist; to a tiny fraction of people and problem sets they're intuitive, to the rest obtuse. I suspect this is why people keep thinking Lisp is going to take over the world despite 30+ years of this not happening.

auggierose 11y ago

He got the thing about using context-free grammars right. The final comment about not using generators is currently right, but will hopefully be wrong by the end of this year. :-)

toolslive 11y ago

Minimizing key strokes is seen as 'false', but it has actually been proven that one can write (debug, maintain,...) about 10 lines of code per hour. Those 10 lines can be 10 lines of assembly, 10 lines of c++ or 10 lines of haskell. Of course, you can do much more in 10 lines of haskell than you can do in 10 lines of assembly. It basically means you want to be work on the highest level of abstraction that you can afford. It also means that economy of expression is important. source: https://vimeo.com/9270320 https://vimeo.com/9270320

Jtsummers 11y ago
Probably more a warning against pre-mature optimization. If you can eliminate all ; in most, or even all, circumstances in otherwise C-like syntax, what do you gain? And most of the savings you see there are from having greater levels of abstraction available. Assembly = arithmetic. You have to explicitly state each step, and on its own there's no understanding of what you're operating on, they're all bits (numbers). C++ (ok, more C) = algebra. You have a bit more understanding of your structure, better names and concepts behind things (types = units, for instance). You're still operating on bits, but now most of those bits have a specifically, language encoded, meaning. Haskell = calculus. Not only are your bits typed, so are your functions (ok, technically also typed in C and kin syntaxes, but not usually as useful) and you can pass them around and modify them. EDIT: I'm more picking on the class of syntax available. When you include semantics OO languages offer a great deal more expressive power than most procedural languages. Probably should've just had C and not C++, but it is what I wrote. More generally what I should have written was towards language classes: assembly (as most primitive procedural language), structured procedural languages (C, Go, Algol, Ada, etc.), OO languages (Java, C++, Smalltalk, etc.) and functional languages (lisps, Haskell, ML-family, etc.). But then you have to break it down further. OO is not inherently more or less expressive than functional languages, it depends on the feature set of the OO and functional languages. Smalltalk is very expressive, easily comparable to the more expressive functional languages. Java, as it used to be, not familiar with developments post adding generics so I'm really rusty on it, was not so expressive. So a comparison between Smalltalk and Common Lisp would put them on a similar level of abstraction. But Common Lisp versus Java (again, with my outdated knowledge), Common Lisp is at a higher level of abstraction (both syntactically and semantically).

yongjik 11y ago

For my project, I found sticking to LALR(1) quite beneficial. Not that there's anything special about LALR(1): you could use LL(k) instead if you prefer. However, by sticking to a small, deterministic syntax (and making the parser generator complain loudly in case of ambiguity), I can easily find edge cases I've never thought about before it comes around to bite me. And, in most cases, it's trivial to slightly modify the syntax so that the undesirable ambiguity does not arise. It's the equivalent of static typing for syntax: it takes effort to make bison run successfully, but when it does, I know that my grammar is free of ambiguity.

StephenFalken 11y ago

LinuxWorld.com: What is your advice to designers of new programming languages? Dennis Ritchie: At least for the people who send me mail about a new language that they're designing, the general advice is: do it to learn about how to write a compiler. Don't have any expectations that anyone will use it, unless you hook up with some sort of organization in a position to push it hard. It's a lottery, and some can buy a lot of the tickets. There are plenty of beautiful languages (more beautiful than C) that didn't catch on. But someone does win the lottery, and doing a language at least teaches you something. Oh, by the way, if your new language does begin to grow in usage, it can become really hard to fix early mistakes.[0] [0] http://www.itworld.com/article/2826125/development/the-future-according-to-dennis-ritchie--a-2000-interview-.html?page=2 http://www.itworld.com/article/2826125/development/the-futur...

tikhonj 11y ago

I've always found it unfortunate how he, and others, implicitly define the success of a programming language as its popularity. A programming language can be incredibly interesting and useful to you and others without ever becoming fashionable—and that doesn't mean it has failed! I think there should be other metrics for success: a programming language can be useful to a dedicated community of experts, it can be useful to a single company, it can be great for a single use-case or even just great for you, it can push novel ideas or showcase a novel design philosophy, all without massive popularity or market success. (And it's not like most languages directly make lots of money anyhow.) Popularity is a poor proxy for quality, and quality matters all on its own. Keeping this in mind changes a lot of his suggestions, I think. Completely unrelated note: what the article calls "lowering" I've more commonly seen called "desugaring" and is, indeed, a powerful technique both in terms of implementation but also in terms of understanding a language—if a piece of syntax is pure sugar, you don't have to understand anything new, just how the syntax it desugars to works.

kazinator 11y ago
> "lowering" ... "desugaring" "expansion"? ".... syntax it expands to"
- kibwen 11y ago
  In a language with macros that might be ambiguous, since there will usually be a phase called "macro expansion".
  - kazinator 11y ago
    That is correct. Expansion isn't necessarily macro expansion. But it's the same kind of thing and may even be be done in the same code walking pass (and possibly have to). (Since the constructs being expanded could be generated by macros, then if the expansions also use macros in their syntax, the two have to be interleaved.) The difference is minor: it's basically "does the code walker specially recognize this construct and invoke some code to expand it" versus "does the code walker recognize a macro call and invoke it to expand it".

krig 11y ago

I disagree with several of these. But I guess that's why 1) I am working on my own language, and 2) Walter Bright is a lot more successful at that than me. So yeah. He's probably right, and I'm probably wrong. However: I'm doing this entirely for my own pleasure, and I don't want success as he defines it (popularity means having to cater to the whims of others). Disagreements: I think minimizing keystrokes is important, and I think the notion that code is primarily read, not written, is idealistic but completely wrong. The purpose of programming languages is to be writable by humans and readable by machines. There is value in making them readable by humans and writable by machines, but only secondary value. I think there is value in easy parsing, if nothing else because every single editor out there can highlight your language even if it isn't popular. I think the focus on popularity as the measure of success is wrong. Tried and true is overrated. There are plenty of examples of programming languages that break the tried and true rules and are successful either because of this or despite this. Either way, it doesn't seem to matter as much as people seem to think, but staring too hard at the success of Java might make you think it does. Anyway, feel free to disagree with me, go ahead and design your own language. I sincerely hope you are successful, regardless of what your definition of success is.

deleted 11y ago
[deleted]
kazagistar 11y ago
In practice, writing code consists mostly of reading; either to (re)understand how some other part of a large system works, or to figure out why the code is incorrect.
- PeCaN 11y ago
  I would argue that it's easier to understand short, even excessively terse, code than it is to understand long code. I can look at a few lines of Haskell and even though deciphering it may take me some time, the cognitive overhead of anything other than working out what the code is doing is very low (the most I'd have to do is look up some operators). I can see a significant chunk of logic all at once and piece together the system as a whole. Meanwhile I could look at 3 files full of Java and have no idea what the system is actually doing.

musesum 11y ago

> Regex is just the wrong tool for lexing and parsing Funny; I recently wrote an Island parser that extends Regex to create a token stream: https://github.com/musesum/Par https://github.com/musesum/Par Quoting the link to Rob Pike's post: > Consider finding alphanumeric identifiers. It's not too hard to write the regexp (something like "[a-ZA-Z_][a-ZA-Z_0-9]*"), but really not much harder to write as a simple loop Maybe I'm missing something, but does this suggest replacing a declaration with a procedure? Oh the horror!

andrewchambers 11y ago

The level of dedication is required is really high. I stumbled upon https://github.com/oridb/mc https://github.com/oridb/mc and found my new favourite language written entirely by one person over the course of many years.