Maxime Chevalier-Boisvert, a compiler researcher, writes about JIT compilers, YJIT, software bugs, and programming projects.
HN commenters link it for basic block versioning, the software bugs that cause real-world harm post, and her Turing Drawings project.
I once, a long time ago, had a similar argument (somewhere online) with a bunch of Java coders. I asked them to create a library for solving quadratic equations. Asking to create a library itself was a trap of course.
Everybody came up with some solver classes in Java, some stateful, some stateless. One guy presented the most monstrous solution with 100+ lines of code where you could individually assign the coefficients, individually modify them, trigger recalculation, get the number of roots, get the roots. That guy was very proud of what he did.
Oh, I found bugs in his code. But that was considered normal. People make mistakes, right?
I showed them a two-line solution with a single function (where you'd try hard to make a mistake) and nobody liked it. I was ridiculed right there, for not solving the problem "properly".
It struck me how someone can overengineer a solution to the simplest problem and be proud of it. I thought at the time this industry is screwed if this is the norm.
In fact probably some 90% of so called library code on GitHub is overenginnered crap. 90% is arbitrary but from my experience every time I look for some solution let's say for some GUI effect on iOS, find a library or a framework, take the source, analyze it, start simplifying it and I end up with a version that is orders of magnitude shorter and can be just copied into my project it's so trivial.
You realize that it was so trivial that there was no need for a library in the first place.
I…
I have certainly given this a great deal of thought. What is needed? How could we get from here to there?
People have often called for a ByteCode vm. This has been rejected over and over again. Bendan Eich in particular has repeatedly argued against bytecode in ways I found to be quite disingenuous. He has variously used Java to imply one bytecode being unsuitable means all bytecodes are unsuitable, or suggested if you want bytecode to make a bytecode VM in JavaScript (even using DCPU16 as an example), or that it is too late for a new standard, or that. No bytecode would be accepted by all browser makers (which I took to mean 'not on my watch'). I have yet to find the arguments against a bytecode VM to be convincing.
I think it would be well worth making a few different candidate bytecode VMs to give the platform a chance in the field. Such VMs are not hard. In the case of the DCPU16 (A imaginary CPU created for a project Notch was working on) it took less than 48 hours for emulators to appear and just under a week for the first compiler. A VM that occupies a similar space to Javascript has its own particular needs.
In a different direction Maxime Chevalier-Boisvert argues for a Control Flow Graph representation http://pointersgonewild.com/2015/08/02/javascript-is-the-c-of-the-web/ Which if the Webassembly approach is to be taken this does seem more sensible than a AST.
The cooperative multitasking aspect of JavaScript has been a bugbear for all too long. …
Concerning your critique of the in your opinion overly hard scientific review process. According to her blog the paper was rejected because: "Reviewers at conferences [...] have been very skeptical, and pressed us multiple times to produce some kind of comparison of basic block versioning against tracing."[1] I think this is a very valid concern. When you describe a new scientific approach (Basic Block Versioning) you should compare to the state of the art. Otherwise it is very hard for the reader to judge the merit of the new approach. However I agree with your sentiment that a new approach should not only be judged by performance numbers (there is actually a nice article going deeper on this topic on databasearchitects[2]). But there should at least be a more thorough theoretical discussion than only 3-4 sentences. Benchmarks comparing to existing approaches in this case can help to show pathological cases which might indicate weaknesses of the approach or to empirically demonstrate the feasibility of the new approach.
[1] http://pointersgonewild.wordpress.com/2014/11/14/the-fastest-for-in-loops-in-the-whole-wide-web/
[2] http://databasearchitects.blogspot.de/2014/09/experiments-hurt-review-process.html
EDIT: Many conferences also allow publishing papers without a deep comparison to exisiting research in the industrial session. This allows demonstrations of interesting implementation variants or system choices
EDIT 2: The review critisim in older blog posts "Conference…
To get access to a wealth of libraries, support, documentation and tools, that D is sorely lacking in. To be able to use a state of the art garbage collector that provides some degree of guarantee about runtime performance as opposed to D's very poor garbage collector that provides basically no guarantees and is known to sometimes block an application for upwards of dozens of seconds at a time [1].
And most importantly, to be able to use a platform that has pretty strong guarantees about backwards compatibility and that is able to run code from 10 years ago without modification, as opposed to D where even a minor version update can end up breaking D's own standard library.
Certainly D has a niche of users who are very passionate about it and for those guys, all the power to you guys and don't bother listening to me... but for most of us, well after 20 years it really hasn't established itself as a reliable language to use beyond that niche. It's no longer 2005, a time when C++ was stagnating and there was a lot of opportunity for a new programming language to sit some where between Java and C. Instead of being released with a roadmap, some promising libraries and frameworks that establish a clear use case where D could shine, and a license that allowed broader community involvement in the implementation of the language and its standard library, it was released as a proprietary compiler that ended up quickly resulting a very fragmented community with a lot of infighting,…
Query strings break unpredictably, and that alone is enough to ban them by third parties, especially for something as minor as referral tracking.
Example: The Browser is a well known link aggregation paid periodical. I subscribe, and every 1 in 10 or 20 links I clicked, it'd just break outright and I'd have to tediously edit the URL to fix it (assuming the website didn't do a silent ninja URL edit and make it impossible for me to remember what URL I opened possibly days or weeks ago in a tab and potentially fix it). This was annoying enough to bother me regularly, but not enough to figure out a workaround.
Why? ...Because TB was injecting a '?referrer=The_Browser' or something, and the receiving website server got confused by an invalid query and errored out. 'Wow, how careless of The Browser! Are they really so incompetent as to not even check their URLs before mailing an issue out to paying subscribers?'
I wondered the same thing, and I eventually complained to them. It turns out, they did check all their URLs carefully before emailing them out... emphasis on 'before', which meant that they were checking the query-string-free versions, which of course worked fine. (This is a good example of a testing failure due to not testing end-to-end or integration testing: they should have been testing draft emails sent to a testing account, to check for all possible issues like MIME mangling, not just query string shenanigans.)
After that they fixed it by making sure they…
Hey, thanks for your comment! I'm a big fan of DIY "implementers" like yourself and am happy to hear some of these ideas resounded with you. I come from a similar background, and agree we need better tools for thinking and working with complex software systems.
> I would consider adding to your system is physical units.
Totally agree. This is high up there on my priority list. Kennedy (2006) did some early work on dimension and unit types that I was quite inspired by:
http://typesatwork.imm.dtu.dk/material/TaW_Paper_TypesAtWork_Kennedy.pdf
> I independently discovered that physics units (Ohms, inerita, etc.) can be described as a vector.
Interesting! I guess that makes sense. Do you have any links describing this perspective a bit? I would be interested in reading about it.
> I have been undertaking experiments in real-time compiling. Please contact me if you're looking or a co-conspirator!
Sounds cool! One of the things I'm interested in is REPLs and interactive programming environments. Do you have anywhere I can read about this project in more detail?
edit: I noticed you were interested in musical instruments and DSPs. One of my colleagues, Maxime, is also working on synthesizers and music production, which I thought you might be interested in reading about:
https://pointersgonewild.com/2019/10/06/zupiter-a-web-based-modular-synthesizer/