3 ms·
I'll leave other commenters with more parser-writing experience to critique this... but the general concept of "Write code in the simplest-to-reason-about direc
by btown 12y ago
I'll leave other commenters with more parser-writing experience to critique this... but the general concept of "Write code in the simplest-to-reason-about direction, and the system magically inverts it into a much-harder-to-reason-about algorithm" is one of my favorite patterns in computer science.
For instance, there's probabilistic programming [1], where you write a procedural program that says "if we were to fix a bunch of properties/states of the natural world and provide them as input, here's the output/reading you'd hypothetically get," and then from that, a system creates a function that, given a large number of outputs/readings, provides a posterior probability distribution over those hidden properties/states of the world. It's still far from the level of performance you'd get from hand-rolled machine learning algorithms that take advantage of all sorts of insights you have into your data... but then again, in general programming, there was a time when compiler optimizations were so naive that you had to hand-roll assembly code for almost anything. I see probabilistic programming in a similar level of infancy, and I'm excited to see where it goes, especially with the backing of a large DARPA initiative [2] to do some really exciting fundamental research.
But there's so much more to the "invertible" paradigm. SQL itself is exactly along these lines - your WHERE clause is just a filter function that works on a single-record level, but it's interpreted as highly optimized instructions to iterate along data structures, to collect all the data that satisfies that filter function. Facebook's Relay [3] is the beginning, I think, of a large push towards declaratively specifying data dependencies for web applications, and having a system that does all the heavy lifting of figuring out when to fetch data, when to push it back to the server, how to handle requests on the server, and how to handle mutations with optimistic client-side updates. All you need to think about is the easy question of "what data might I need, and if it were to exist at any given moment, how would I display it to the end user?"
Humans think generatively, whether it's about data or formatting or GUIs or the physical world. We have all these ideas in our mind, and we can visualize how we would expect them to appear. When our computer systems can let us focus on those high-value thoughts, that's what the future looks like.
So let's cut the out-of-the-box parser thinkers some slack!
[1] http://www.pl-enthusiast.net/2014/09/08/probabilistic-programming/ http://www.pl-enthusiast.net/2014/09/08/probabilistic-progra...
[2] http://www.darpa.mil/our_work/i2o/programs/probabilistic_programming_for_advanced_machine_learning_%28ppaml%29.aspx http://www.darpa.mil/our_work/i2o/programs/probabilistic_pro...
[3] https://gist.github.com/wincent/598fa75e22bdfa44cf47 https://gist.github.com/wincent/598fa75e22bdfa44cf47
- david-gudeman 12y agoAn interesting take. I've always been something of a programming-language junkie motivated by the feeling that there must be clearer, better ways to express things. Classp was motivated in large part by my dissatisfaction with having to write a recognizer and warp it into a parser and then turn the parse tree into an AST. Why can't I just express directly how the AST is represented in the target language?