[HN Gopher] So you want to design a programming language (2017)
___________________________________________________________________
So you want to design a programming language (2017)
Author : behnamoh
Score : 73 points
Date : 2022-02-26 19:38 UTC (3 hours ago)
(HTM) web link (cs.lmu.edu)
(TXT) w3m dump (cs.lmu.edu)
| teddyh wrote:
| See also _Growing a Language_ by Guy L. Steele Jr. in 1998:
|
| https://www.youtube.com/watch?v=lw6TaiXzHAE
|
| http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
| hardwaregeek wrote:
| Or do none of that. I understand that this article is meant to
| encourage people to learn some cool stuff within programming
| languages, but it's also discouraging. The better answer in my
| view is to learn how to build a tree walking interpreter with
| Crafting Interpreters, then build whatever comes to mind. Want
| functional programming? Add immutability and first class
| functions. How about concurrency? Add an event queue. Then try to
| make a bytecode interpreter or a compiler. Sure these ideas
| require some of the knowledge detailed in the article, but you
| can learn that info JIT. Don't try to learn it all before you get
| started. Just start and see what happens.
| the-smug-one wrote:
| Or just write your own operational semantics and grammar in
| Racket's Redex :). Lots of ways to Rome.
| brokencode wrote:
| There's a difference between building a toy language and
| designing something people would actually use.
|
| I think the article is more aimed at the latter, whereas if you
| just want to get something working and have fun, your approach
| makes more sense.
| agumonkey wrote:
| More than a programming language, what about new paradigms :)
| J253 wrote:
| This is a great resource for pointing out the things you need to
| think about in designing a language.
|
| To see the nitty gritty line-by-line walkthrough of everything
| that goes into actually building a language (all the way down to
| writing your own VM) I HIGHLY recommend reading Crafting
| Interpreters[1] by Bob Nystrom. I'm not a language hacker but
| found everything about this book worthwhile and very interesting.
|
| [1] https://craftinginterpreters.com/
| Decabytes wrote:
| If you want to design a programming language, and are okay with
| building off of an existing language, I suggest giving Racket a
| try. It can do more than just create DSLs and compile down to
| Racket code. I recently learned about sham* which allows
| interfacing with LLVM. I've linked some examples and references
| below
|
| References 1. https://docs.racket-lang.org/guide/languages.html
| 2. https://docs.racket-lang.org/turnstile/
|
| Examples 1. https://github.com/soegaard/urlang 2.
| https://github.com/rjnw/sham 3. https://github.com/ShawSumma/lure
| 4. https://github.com/racket/rhombus-prototype 5.
| https://github.com/lexi-lambda/hackett
| open-source-ux wrote:
| One of the sections in the article is headed "study existing
| languages", but why not also study languages that shaped
| programming language history? No mention of the Pascal-family of
| languages (Pascal, Modula-2, Oberon), no mention of Ada. Even
| Algol 68 is full of ideas that would reward study.
|
| Also, the language descriptions are too brief to be helpful (
| _Java and C# for being enterprisey_ , _C++ and Rust for pointers
| and other system constructs_ )
| goodpoint wrote:
| ...and no mention of Nim, which shares a lot with Pascal,
| Python, C and Ada and is more innovative.
| jonsen wrote:
| The wiki page is rather informative in the sense of choosing
| which historical languages may be worth a closer look:
|
| https://en.m.wikipedia.org/wiki/History_of_programming_langu...
| ModernMech wrote:
| I think it's even more important to study history of PLs if you
| want to make a new one. The history of programming languages
| was shaped heavily by Moore's law, and the fact that if you
| waited 18 months, your previous slow program would likely be
| twice as fast on newer chips. The result was that programming
| languages rose to the top by riding this exponential wave
| through mechanical sympathy.
|
| Today, however, Moore's law has stalled, and a different kind
| of power law is on the rise: core counts. Languages which
| previously saw success by being imperative and optimized for
| single core execution are falling over trying to keep up. We
| see increased efforts to harness the power of multiprocessing
| through asynchrony and parallelism being first-class citizens
| in newer languages, while others struggle to stay relevant.
|
| Languages of the future will be built from the ground up to
| harness massive CPU core counts that will be available on
| consumer desktop machines in the near future. My advice to any
| budding language designer is stop looking to reinvent C and
| C++. There's currently a wave of programming languages that
| came of age circa 2010 - 2020 which are focused on just that
| (Go/Rust/Zig etc.), but if you're just looking to get into that
| space now you're late to the party. Instead look back to Erlang
| and the original promise of Object Oriented programming as the
| basis for a new language in 2022.
| tomcam wrote:
| Yeah that list is glib. To include Brainfuck but not Pascal is
| telling.
___________________________________________________________________
(page generated 2022-02-26 23:00 UTC)