Apanatshka

Heh, Randstad advocating candor, who could have guessed. It's a Dutch company, and straight-to-the-point, no-BS candor is one of those Dutch culture things. Of course you need to strike a careful balance, as Kim Scott aptly defines according to the article: candor = "giving criticism while showing genuine concern".

Doesn't work for me. Does this trick require JavaScript execution or cookies?

There are also newer editions of this book: http://papl.cs.brown.edu/2015/

I've been meaning to read more of this book. The first chapters are great. Now of only I had time...

It took me a while, but I solved it without any guessing+backtracking.

It really depends on the kind of parsing that you're doing.

Full context-free grammar are supported by "generalised parsing". The older stuff is GLR by Tomita, Early parsing, the CYK algorithm. The newer stuff based on Tomita is the particular rabbit hole I stuck with for a while. I read about SGLR which eliminates lexers, GLL which is GLR but based on the LL algorithm. The people who do GLL research also did improvements on SGLR with improved speed on right-nulled grammars. Then there is the SGLR improvements with disambiguation filters, automatic derivation of error recovery with island grammars, etc. The disambiguation filters include a kind of negation, making the current implementation of SGLR for SDF capable to parsing Boolean Grammars, which are a superset of context-free grammars.

Anyway, there's more than context-free grammars. Definitely look into data-dependant grammars! It's able to define a lot of interesting things, like network protocol formats where you parse the length of the payload, then based on that length you know how much to interpret as the payload before you read the footer of the message. And you write all of that in a more declarative way and get a nice parser generated from it.

There is so much more, but I think I should to stop now :)

You could try applying The Elm Architecture [1]. It's developed for the Elm programming language [2], but I've seen more than one framework outside of the Elm ecosystem cite it as inspiration for their structure.

[1] https://github.com/evancz/elm-architecture-tutorial/ [2] http://elm-lang.org/

This sounds a lot like auto-completion in a good IDE.

I've only read a little bit in Optimizing Compilers for Modern Architectures, but it seems a pretty complete introduction: http://www.amazon.com/Optimizing-Compilers-Modern-Architectu...

Another space you can look for interesting things (not necessarily optimising compilation) is the compilation of functional programming languages. They usually take a slightly different approach compared to imperative languages, though there's clearly a lot of overlap. I really enjoy reading in an old book called The Implementation of Functional Programming Languages from 1987, which is available online: http://research.microsoft.com/en-us/um/people/simonpj/papers...

I'm not sure if it was [0] or [1]..

[0]: https://groups.google.com/d/topic/elm-discuss/NJCZFIYxshE/di...

[1]: https://groups.google.com/d/topic/elm-discuss/ZJ6lkfPimW8/di...

hehe, I see this every time on an HN post about a new Elm release. At some point I'll have to look into that old email client, I'm curious what people are talking about.

I think there simply needs to be more exploration in the area. I only know of one person who tried something truly different than the Elm Architecture who wrote about it on the mailing list. Anyone interested and with time to spend should just try different things, be critical of their attempt's ease of use and ease of abuse and see what works.

I think eventually there might be a performance problem with scaling, and yes each components seems to have a bit of boilerplate. But overall the pattern is very reusable and predictable, so if it really becomes the standard (instead of the experiment that it is now!) there could be compiler support for less boilerplate/ better performance.

For now I haven't seen enough people with actual experience using this architecture to really buy any complaints. I've seen more unintuitive things come around in Elm that seem weird (perhaps even wrong) at first, but by really trying it out, I've found that more of those things work really well!

Long anticipated, and now finally here :) I <3 the type diffs, exhaustiveness checks and TCO. Not completely sure about the removed syntax, but it's not like I used it a lot, so I guess simpler is better.

No, Unsafe is not blacklisted from JIT afaik. Although be careful that a helper method using Unsafe usually doesn't get inlined. The problem in this case is the loop. It ranges over a long, and where int loops get a lot of optimisations, long loops don't (yet, they're aware of the issue)

For those who don't want to google it: http://elm-lang.org/

I agree. But don't forget that it took years of hard work to build up enough of "Java the platform". Things that help there is having traditional man-power, which costs money, and having a strong community, which takes lobbying/evangelising/advertising. In a way, all those "luminaries" you mention may or may not miss the point individually, but the buzz it creates is necessary to build the community that makes the platform, and that in turn makes the language succeed. Developers, developers, developers, developers, developers...

Given that type inference can be expressed in the form of constraints, could this be used to speed up type inference on huge programs?

Hmm. Someone beat me to it. Interesting though, very cool.