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.
Dear sir, you have built a compiler
101–110 of 177 posts
Re: Dear sir, you have built a compiler
#102I'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…
Re: Dear sir, you have built a compiler
#103This 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…
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
#104Earlier 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!
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
#105Earlier 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.
Re: Dear sir, you have built a compiler
#106At 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…
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
#107Re: Dear sir, you have built a compiler
#108I 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…
- 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
#109Earlier 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.
Re: Dear sir, you have built a compiler
#110I 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!)