Skip to content
HomeVideosBooks
AllTopicsTrends
BlogsPodcasts
HistoryListsWatch laterLiked videosFollowing

The videos, books, blogs and podcasts Hacker News keeps recommending, all in one place.

VideosBooksBlogsPodcastsAboutPrivacySettings

Data from Hacker News, HackerTube, HackerBooks, HackerBlogs and Open Library. Credits · Not affiliated with Y Combinator.

HomeVideosBooksBlogsPodcasts
Ctrl K
    Cover of Writing interactive compilers and interpreters

    Writing interactive compilers and interpreters

    Peter John Brown · 1979

    ProgrammingComputer Science
    Open LibraryAmazon
    Stats for nerds
    1recommend
    3mentions
    2people
    2022–2024years
    67% recommend33% neutral

    Mentions per year

    202220232024

    What Hacker News says

    1. wrpAug 2022
      Writing Interactive Compilers and Interpreters by Peter John Brown (1979) is quirky in the sense that he paid unusual attention to the literary quality of his prose.

      Among his admonitions for writing user manuals is this:

      Read. Books on overall style are a matter of personal taste. Our own favourite is Strunk (1959). As examples of good writing on technical matters, we especially like the works of D. E. Knuth and of M. V. Wilkes, and also the book "Software Tools" (Kernighan and Plauger, 1976). Perhaps the most pleasant of all writing on technical matters is in the field of gardening, not computing; read "The Small Garden" by Lucas Phillips (1952) and not only your turnips but also you writing will improve.

      thread
    2. wrpJun 2022
      The literature on interpreters (vs. compilers) is pretty thin. I enjoyed reading these:

      1. Peter John Brown. 1979. Writing Interactive Compilers and Interpreters.

      2. Timothy Budd. 1987. A Little Smalltalk.

      3. Ralph E. Griswold. 2000. The Icon Programming Language, 3e.

      4. Pat Shaughnessy. 2013. Ruby Under a Microscope: An Illustrated Guide to Ruby Internals.

      This is a new one I haven't read yet, but it looks very practical:

      5. Clinton L. Jeffery. 2021. Build Your Own Programming Language: A Programmer's Guide to Designing Compilers, Interpreters, and DSLs for Solving Modern Computing Problems.

      I don't know anything about this one, but people have told me they prefer the first edition:

      6. Ronald Mak. 1991. Writing Compilers and Interpreters: An Applied Approach.

      thread
    3. gregjorSep 2024
      At the time, in the context of other software development environments (like submitting decks of punch cards) the HP 2000 timeshared BASIC environment would count as an IDE. Compared to Turbo Pascal or any modern IDE it falls short.

      HP TSB did not have a REPL. If your program crashed or stopped you could not examine variables from the terminal. You could not peek or poke memory locations as you could with microcomputer BASICs (which didn't support multiple users, so didn't have the security concern). You had to insert PRINT statements to debug the code. TSB BASIC didn't have compile/link steps, it tokenized the code as you entered the lines, and the interpreter amounted to a big switch statements on the tokens. P. J Brown's book Writing Interactive Compilers and Interpreters (1981) describes how TSB works. Eventually I got the source code to TSB (written in assembler) and figured it out for myself.

      Other BASIC implementations that popped up around the same time had richer feature sets. In my senior year at high school I got (unauthorized) access to a couple of Unix systems in Portland, ordered the Bell Labs Technical Journal issues that described Unix and C, and taught myself from those. I didn't get paid to work on a Unix system until several years later (detours into RSTS-11, TOPS-20, VMS, Microdata, Pr1me, others) but I caught the Unix and C bugs young and I still work with those tools every day.

      Some programmer friends and more than a few colleagues over the years have made fun of my continued use of what they call obsolete and arcane tools. I don't mind, I have never felt like I did less or sloppier work than my co-workers, and my freelance customers don't care what I use as long as I can solve their problems. Most of the work in programming doesn't happen at the keyboard anyway. I do pay attention and experiment with all kinds of tools but I usually end up going back to the Unix tools I have long familiarity with. That said I did spend many years in Visual Studio, MPW, CodeWarrior, and MPW writing C and C++ code, and I do think those tools (well, maybe not MPW) offered a lot of benefits over coding with vim and grep, for the projects I did back then.

      Maybe ironically I use an iPad Pro, I don't have a desktop or laptop anymore. So I have the most modern hardware and a touch-based (soon) AI-assisted operating system that runs a terminal emulator during my work time.

      thread

    Related

    Cover of Compiler construction
    2016

    Compiler construction

    Kenneth C. Louden
    1 recommend · 2
    Cover of Crafting Interpreters
    2017–2026

    Crafting Interpreters

    Robert Nystrom
    295 recommend · 521
    Cover of Engineering a compiler
    2007–2026

    Engineering a compiler

    Keith D. Cooper
    39 recommend · 91
    Cover of Code Complete
    2007–2026

    Code Complete

    Steve McConnell
    393 recommend · 894
    Cover of Writing compilers and interpreters
    2010–2022

    Writing compilers and interpreters

    Ronald Mak
    4 recommend · 7
    Cover of The C Programming Language
    2007–2026

    The C Programming Language

    Brian W. Kernighan
    246 recommend · 604
    Cover of Writing An Interpreter In Go
    2016–2026

    Writing An Interpreter In Go

    Thorsten Ball
    73 recommend · 107
    Cover of Code
    2008–2026

    Code

    Charles Petzold
    243 recommend · 385