Very interesting! Quite amusing that adding milk seems to be an unquestionable truth while adding sugar is considered destroying the flavour and adding pepper (which is not uncommon in India) appears to be unthinkable.
But I find it most surprising that the detailed rules say nothing about how long to steep the tea.
At least for some form of mechanical clocks: There is an app for that :)
E.g., for Android, the "Watch Accuracy Meter", which can be found in the Play Store or the APK source of your choice, uses the phone's microphone to measure the frequency of mechanical watches.
I would say that the benefits you get from a habit of using SMT solvers depends a lot on the kind of problems you are working on.
If your problem is rather small and self-contained, you can really win a lot with these solvers. E.g. I used an ILP solver to fairly distribute tasks to a group of people based on a heuristic of familiarity between each person and the tasks. That's only a few constraints in the solver that saved me a lot of manual or suboptimal coding work. Similarly, it was easy enough to quickly check whether two graphs satisfy a custom condition that is close to (but not quite) isomorphism that I wanted to give a try.
If you are thinking of bigger, more complex tasks, the efficiency gains you get might vary more. If your problem produces many large solver queries, the chances are good that you will wait a long time for results. Without much practice, adjusting/augmenting your specification (and specifically in the case of ILP solvers: tuning the solver parameters) to reduce your solving times is a very non-trivial task. Either way, the solver probably won't bring you to 80% of the execution speed of a custom solution: I once sped up a task by 100-200x by replacing a Gurobi LP with a dumb, theoretically exponential, but easy to optimize custom implementation (the solver was however helpful for testing that the implementation was correct).
Lastly, in my experience, once a constraint system/model reaches a certain complexity, it is a lot more difficult to debug than code in a programming language. There are useful techniques and tricks for debugging solver models, but the tooling and the sequential execution of real code make debugging of traditional code less of a head ache.
I tried to use this to ease the front end work load of students in a compiler project (building a C compiler) for a University course, so that the project could be focused on the more interesting middle and back end parts of the compiler.
However, reported bugs in the C grammar that saw no activity at all [1] made this impossible. From this small sample of experiences, I was left with the impression that Tree Sitter is great for things like syntax highlighting, where wrong results are annoying but not dramatic, but not so suitable for tools that need a really correct syntax tree.
> Right, but GPT-2 was the name of the particular ML architecture they were studying the properties of; not the name of any specific model trained on that architecture.
That sounds like it would have been a reasonable choice for naming their research, but isn't the abbreviation "GPT" short for "Generative Pre-trained Transformer"? Seems like they very specifically refer to the pre-trained model, which I would also take from the GPT-2 paper's abstract: "Our largest model, GPT-2, is a 1.5B parameter Transformer[...]" [1]
Regarding interface stability:
Indeed, the textual representation is not stable, things like added types in the representation of some instructions can happen when upgrading to a new version.
However, to be entirely honest, in the last few years of updating LLVM-based research tools to newer LLVM versions, changes in the C++ API that required me to (sometimes just slightly) change my code happened a lot more often than changes in the textual representation...
I would claim that the benefits of 'mostly functions' strongly depend on the task at hand.
For the field of compilers, I can for example see value in making program analyses pure functions that just compute information about the program and separate them from the program transformations that use this information to (impurely) manipulate code. This makes the analyses more reusable and probably makes reasoning about correctness easier.
For other tasks in the compiler, pure functions can be a pain. My favorite anecdote for this is that of a group of students in a compiler's course who insisted on writing the project (a compiler for a subset of C) in Haskell and who, when discussing their implementation in the final code review, cited a recent paper [1] that describes how you can attach type information to an abstract syntax tree (which is an obvious no-brainer in the imperative world).
AnyDSL (https://anydsl.github.io/) might be worth mentioning, it is a framework for creating domain specific languages using partial evaluation to give powerful abstractions to the user while still producing high-performance code for different target platforms.
On the website, you can find that they already have DSLs for ray tracing and image stencil codes as well as works for bioinformatics.
I consider it a fun little game to guess for each mention of "Kafka" in a HN title, whether it means the author or the software.
Definitely not trivial, since this time, I would have guessed "Kafka in Pieces" to be an introduction to the software, component by component.
Having written test cases for a similar semantic program analysis tool, I agree: Integer overflow is a very likely cause for such "obviously correct but actually wrong" program invariants. The C semantics can make this problem even worse since signed integer overflow is undefined, leaving the user of such a framework to the mercy of the design decisions of the creators of the framework regarding undefined behavior.
Well, there is the Hennessy&Patterson book, "Computer Architecture - A Quantitative Approach". The newer editions include modern features and follow industry's developments.
This will of course not be able to tell you all the black magic that is happening inside AMD's and Intel's newest designs. The software optimization manuals for these processors do include some more interesting insights, but especially the Intel ones are not the most entertaining read...
There will probably always be particular code transformations (algorithmic or target-machine-specific) that speed up your code and that your general purpose compilers will not find. (And that's good, because otherwise the compile time would be horrible!)
The good thing about compiler optimizations is not that they produce actual "optimal" binaries, but that they allow you to not care too much about performance when writing code (e.g. using abstractions that will be inlined, etc.) and still get a decent binary.
If you then require more performance (which will probably not be the case for most applications) you can still search for bottlenecks and start optimizing by hand there.
There are even more improvements (in some regard) to this, e.g. Affine Arithmetic[0, 1]. Here, error terms from different operations are accumulated symbolically so that in the case where they would cancel out (as could be useful for numerical algorithms), tighter bounds can be obtained.
There are several research groups working on improving such analyses.
You don't get quite this level of ambiguity with standard C, since it does not provide objects (in the object-oriented sense) with constructors, in contrast to C++ that is used in the Arduino environment (in C++, initialization order of global objects is indeed unspecified, inviting subtle bugs to occur).
However, many common C compilers provide methods to declare functions to run at initialization time, e.g. gcc's `constructor` attribute, opening this rabbit hole also for C programmers.
This looks really amazing! I particularly like that it makes good use of the width of an ultra-wide screen.
While I wouldn't want it to replace the actual hackernews layout, I can really see it shine for discovering interesting articles whose headlines alone do not tell me enough to identify them as interesting (seems perfect for Friday afternoons).
One suggestion: I would appreciate more visual hints to indicate which images and texts belong together. When I scroll down the site and something catches my eye, it takes me a bit of looking around to be sure where to read for the corresponding text. Slightly larger margins and/or vertical and/or horizontal lines between the articles might help to make it feel more convenient.
On the "culture of 'optimization is the root of all evil'" remark in the conclusions:
I find this to be a nice example for the full Knuth quote.
If you face an arbitrary task including parsing 64 bit integers, starting by developing/using the technique from the article (as a _premature_ optimization) is probably a bad idea since it costs time for the implementation (and even more time for debugging and understanding the code a few months later), while in most cases, it is probably not what dominates the running time of your code.
If you however have built a solution that does the job, but is just not fast enough, and profiling shows you that you spend considerable time parsing integers, this kind of optimization is the way to go.
But I find it most surprising that the detailed rules say nothing about how long to steep the tea.