Live data from Hacker News

Dear sir, you have built a compiler

rachitnigam.com

101–110 of 177 posts

Re: Dear sir, you have built a compiler

#101

Earlier quoted context omitted.

does it affect how you code other kinds of apps too ? knowing how to think about a program interpretation space gives quite a broader view IMO

I'd argue the idea of an "interpreter" is one of the most foundational concepts of CS. It sounds really basic, but the idea of being handed a description, and doing/creating something based on that is everywhere . It is really quite beautiful.

To me it was the recursive mapping over a closed set of types, whatever you do you should end up with an element of your type/grammar. That and the graph walk space of the AST.

Re: Dear sir, you have built a compiler

#102

I'm always surprised by the lack of "easy" parser/compiler toolkit for more or less complete DSL... It looks like there's only - either full blown programming language for IT guys - "natural language" AI toolkits (not really usable yet for just simple automation by users) - graphical language like State Machine or "no code", missing loops and requiring mouse and boxes However, most of the time, user simply need some…

JetBrains has a MPS (Meta Programming System) [1] that I believe is for knocking up DSLs. At a lower level, I've used ANTLR [2] a bunch of times, and its StringTemplate even more often.

[1] https://www.jetbrains.com/mps/

[2] https://www.antlr.org

Re: Dear sir, you have built a compiler

#103
post #78

This reminds me of a great post about the typical software evolution going from hard coded values, through configuration and rules engines to a DSL, only to be back where you started. I have seen it happen on multiple projects, it’s hard to spot it at the time as all the changes seem sensible but hindsight is a wonderful thing http://mikehadlow.blogspot.com/2012/05/configuration-complex...

This line really struck me: “They will have to change at some point, and you don’t want to recompile and redeploy your application just to change the VAT tax rate.” Continuous deployment has changed this for me. I'm still not going to leave tunable constants in the middle of random if statements. But nowadays instead of trying to avoid recompiling and redeploying, I'd rather invest that time into making that very eas…

Yeah, CD is a big game changer here. Managing config separately from code is a big pain (as that piece points out in colorful detail), and as the countervailing painfulness of a deploy drops toward zero, it becomes better and better to just hardcode some consts. "Business rules" just become "code you write". Easier to change, test, and reason about. At my last job we moved to CD and it was fun to see everyone (haltingly, sometimes unwillingly) change their approach to this.

There's still a place for configs and even DSLs (multiple deployments, on-prem software, biz logic written by non-programmers, etc) but CD eliminates the huge class of "this is too expensive to deploy changes to" cases.

Re: Dear sir, you have built a compiler

#104
post #84

Earlier quoted context omitted.

I think I might have used the expression "do want" to vaguely here. Same as you, I have very little desire to write any of those systems, and still try to avoid them as much as possible (as those endeavors usually require more time/energy, etc. and come with higher risks). Maybe it's better put as "But sometimes all your product requirements strongly suggest that you have to build X and there isn't really a way to av…

Thanks for the clarification (even for some rando on the internet), that makes a lot more sense... I think I'll implement a rule for myself where I won't comment on HN posts after first waking up anymore. Agreed that could totally happen!

'Put self into read only mode until after the first pint of coffee' is a policy that has significantly reduced the number of times I look back at a comment I've made somewhere and judge myself for its quality.

I mean, even fully caffeinated, I still manage to beclown myself on a semi-regular basis, but the 'semi' part is still a net win.

Re: Dear sir, you have built a compiler

#105

Earlier quoted context omitted.

does it affect how you code other kinds of apps too ? knowing how to think about a program interpretation space gives quite a broader view IMO

I'd argue the idea of an "interpreter" is one of the most foundational concepts of CS. It sounds really basic, but the idea of being handed a description, and doing/creating something based on that is everywhere . It is really quite beautiful.

It comes up often too. A few month ago I wanted to make a part of the code I was working on more declarative, so I had it take a javascript object that described a layout, and make actions depending on that object. That's a form of interpreter in a way.

Re: Dear sir, you have built a compiler

#106

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-batch code paths.

(because yeah, it -so- does hurt trying to retrofit that later on, so 'finding a way to trick myself into -wanting- to build it in early' was rather a win for me ;)

Re: Dear sir, you have built a compiler

#108
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…

Don't forget the paramount of the Mountain of Shit:

- a billing system

There's a reason why there are b2b companies that specialize in billing. When people branch out it's often billing and X, not X and billing. And even then sometimes they pull back. ADP bought a bunch of companies outside their wheelhouse and then spun them back out.

Re: Dear sir, you have built a compiler

#109

Earlier quoted context omitted.

I'd argue the idea of an "interpreter" is one of the most foundational concepts of CS. It sounds really basic, but the idea of being handed a description, and doing/creating something based on that is everywhere . It is really quite beautiful.

To me it was the recursive mapping over a closed set of types, whatever you do you should end up with an element of your type/grammar. That and the graph walk space of the AST.

I'm currently writing a compiler so I'm not new to this, but I've no idea what you just said. Have you any links to explain it? TIA

Re: Dear sir, you have built a compiler

#110
post #55
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!)

Look at the bright side. At least Hell is always warm, and plenty of interesting people to talk to.
Post reply on HN