Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear sir, you have built a compiler

rachitnigam.com

Post reply on HN
Print view View original

121–130 of 177 posts

Re: Dear sir, you have built a compiler

#121

Post by m-hilgendorf »

mst wrote: post #106
m-hilgendorf wrote: post #97

At my company (JITX) we've fully committed to compiler architectures in our stack, which makes sense since we're developing an embedded DSL for circuit boards. It's remarkable how many problems are easier when you just accept it's some kind of compiler problem that needs parsing into a tree you can walk with a pass to spit out the required data. For example in audio networks, you can write a buffer allocation and lat…

Something I've found useful when perpetrating custom languages is to, as early as possible, bring up a REPL that handles multiline expressions sensibly. This (a) requires me to build stream/incremental parsing (b) gives me a tangible feature out of doing so that makes my life better (c) means from then on even if the production uses of the language are all batch shaped to begin with I'm regularly dogfooding the non-b…

Lucky for us, the language we embed the DSL(1) within has a REPL!

(1) http://lbstanza.org/

Re: Dear sir, you have built a compiler

#122

Post by pklausler »

hobofan wrote: post #31

I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…

In situations of mutual dependence between software components in a big project, implementing a quick "scaffolding" solution for one of them can get development moving on all components independently. A long time ago, I was working on a new incompatible instruction set architecture at a specialized computer systems vendor, and had written a simulator and assembler for it. The O/S group was ready to start porting our UNIX variant, but there was no C compiler. So I wrote one; ANS C89 is a pretty small language. That got everybody unstuck, and the O/S guys could do their port while the compiler group could move at their own pace (and had a partial O/S on which to run compiler test suites). I guess my point is that there can be times when quick "scaffolding" components are reasonable.

Re: Dear sir, you have built a compiler

#123

Post by crdrost »

munificent wrote: post #120
hobofan wrote: post #31

I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…

I would also add a build system to that list, a tarpit many engineers have fallen into. > not sure that there is a difference to compiler as stated in the article It's hugely different. If you're building a compiler for an existing language, you inadvertently signed yourself up for implementing and supporting the entire language, which is a pretty large engineering task. But if you design a new language, you signed u…

Note that this also happens pretty much whenever anybody has any sort of template system that they want to support substitution into. You decide that you want to support substitution and suddenly you are building static analysis and documenting and writing syntax highlighting and all this mess.

So for example when you want to create a validation system for something, and then you realize that you want to have generics/type-variables/polymorphism, you want validation containers. Bam, the complexity suddenly shoots up! Or maybe you just want to let someone configure with yaml, and then you find yourself with substitutions and substitutions in substitutions and all that mess. Why?

The abstract reason is that the underlying mathematics of template substitution is lambda calculus, which is Turing complete. It's hard to learn lambda calculus because it's very abstract, it takes place in a mathematical ideal realm where nothing happens, but this also means that the same pattern reappears in a whole bunch of different contexts, and it is best if we just regard it as a design pattern and conscientiously adopt it. “Oh, this is a Lisp, I have seen the 20 line lisp-in-lisp evaluator, let's just code that in whatever host language and someone else will have thought of the details.”

Re: Dear sir, you have built a compiler

#124

Post by Mister_Snuggles »

mamcx wrote: post #55
hobofan wrote: post #31

I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…

You wanna get crazy? When you hit: - a ERP You start to build all the others! (This is where I'm now!)

I work on a commercial ERP and this is 100% accurate. It features:

* A proprietary language

* A compiler for said proprietary language

* A way to define tables and views and turn these definitions into real tables and views that live in an SQL database. There is also a custom SQL dialect that gets translated to real SQL on the fly. I'm counting this as having its own database even though it offloads the actual database work to a real database.

* One of the products in this ERP suite includes a CMS built on all of the above.

Re: Dear sir, you have built a compiler

#125

Post by seanw444 »

alexjplant wrote: post #57
hobofan wrote: post #31

I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…

IMHO "programming language" would refer specifically to the grammar, type system, semantics, keywords, etc. and "compiler" would refer to the implementation that takes something written in that representation and outputs some type of executable. A pedantic distinction but probably a useful one, especially given how some languages have multiple implementations of their standard. The Programming Languages course I took…

"And so Forth"

Nice unintentional pun.

Re: Dear sir, you have built a compiler

#126

Post by jhgb »

shadowgovt wrote: post #73
lupire wrote: post #37

https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." (Same applies to popular languages after the original quote.)

What often goes unsaid is the corollary: "Any Common Lisp implementation people use contains an ad-hoc, informally-specified, bug-ridden optimizing compiler written in C or Fortran."

That makes no sense. Which Common Lisp implementations contain a compiler written in C or Fortran?

Re: Dear sir, you have built a compiler

#127

Post by shadowgovt »

jhgb wrote: post #126
shadowgovt wrote: post #73

Earlier quoted context omitted.

What often goes unsaid is the corollary: "Any Common Lisp implementation people use contains an ad-hoc, informally-specified, bug-ridden optimizing compiler written in C or Fortran."

That makes no sense. Which Common Lisp implementations contain a compiler written in C or Fortran?

I should have been clearer: written partially in C or Fortran.

SBCL, for example, has C bindings in the /runtime subdirectory.

Re: Dear sir, you have built a compiler

#128

Post by cbsmith »

hobofan wrote: post #31

I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…

These aren't "big scary things", they are "technical debt you didn't need to take on".

...and the alternate course of action is clear: use the tools you already have.

Re: Dear sir, you have built a compiler

#129

Post by cbsmith »

Karunamon wrote: post #41
jimmaswell wrote: post #38

Earlier quoted context omitted.

Implementing a small domain-specific language is fairly easy. Why avoid it?

Because the complexity of the problem tends to scale to your willingness to address said complexity. In other words, it likely won't stay small for long if it gets any users, and now you're the maintainer for a tool used by others.

That principle is not specific to a DSL, so that hardly seems like a reason to avoid a DSL.

Re: Dear sir, you have built a compiler

#130

Post by prionassembly »

cjbgkagh wrote: post #116
hobofan wrote: post #31

I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…

Lol, I’ve built all those things. I think the main thing is having respect for the mountain of engineering that went into existing solutions and not rolling your own unless you really really have to. I think an Embedded DSL with post compilation constraint solver based analyzers could take the place of restricted mini-languages while taking advantage of the existing engineering and tooling available for modern langua…

So like a restricted subset? That's a really neat idea; you should develop it into a paper or something.

This restricted subset concept has the huge advantage that you can slip out of the harness in a pinch. So you can reuse a relatively developed Float-less Python program in Full Python and later walk back removing floats.

That's really clever. It essentially obviates the whole configuration DSL tango; it also gets people started where the rubber hits the road -- not with syntax and parsing, but with why the DSL exists and what it's supposed to do and not do.

Post reply on HN