This defeatism is unhelpful. I'll not simply surrender the country that I love, thanks.
795 karma · joined March 21, 2013
> Instead, we use ANTLR, a state-of-the-art, open source parser generator.
I don't agree with this (pre-AI-coding) take. Hand-rolled parsers are much easier to write well and maintain than people think. They also tend to be much faster and produce much better errors than parser generators. I guess if the language you're trying to parse is, say, C++, then you're going to have a miserable time (probably no matter what). But an SQL parser is very doable. (I say this as the author and maintainer of an in-house SQL dialect thingy at work.)
What makes building and maintaining a hand-written parser such a tractable task is:
- The code size can be large, but you can start with a core of a few well-chosen abstractions and then you add lots of parsing code for various language constructs but it's all kind of orthogonal and doesn't add compounding complexity as you go. - It's just about the most testable kind of code there is. You can cover all the various corner cases with tests and really lock in the behavior so that you can very confidently make changes. One approach I like is to make zillions of tiny test files in the target language accompanied by some golden representation of the AST.
And of course, as the author found out, these properties make writing a parser a really good task for AI coding, too. These tools are very, very good at generating a bunch of new code based on existing abstractions and covering it with lots of test cases.
So I agree with where they ended up, just not where they started :)
I'm going to place the blame on the party committing the crimes, not the person exercising free expression.
No. We need spam filters for this stuff. If it isn't obvious to you yet, it will be soon. (Or else you're one of the spammers.)
They are:
470k feet is 143 km. The altitude record for an air-breathing aircraft is 38 km. There are some very low earth orbit satellites that orbit in the sub-200 km range (https://en.wikipedia.org/wiki/Very_low_Earth_orbit). The ISS orbits at about 400 km and typical LEO is 800 km. ICBMs have an apogee altitude of 1000 km or more.
(Of course, the energy required to get up to some altitude is only a small fraction of the energy required to get into orbit at that altitude. https://what-if.xkcd.com/58/ is a relevant read.)
The alternative requires a scenario where waymo is especially likely to get into fatal accidents while being very good at avoiding non-fatal ones, right? Seems far-fetched.
I used to gvim but realized that I was getting almost no benefit (and occasionally the differences between gvim and my terminal caused minor annoyances).
Two things I do that help in this regard:
I use a tweaked config for the "editor" instance of the terminal that has a slightly different background color from my main terminal. This keeps them separate in my mind.
I use dedicated shortcuts for focusing each application I use (browser, terminal, slack, etc) and the "editor" terminal has its own shortcut. (The --class flag that the post mentions kitty has would be pretty helpful in this regard. My terminal doesn't have that so my shortcuts are based on title, which works well enough most of the time.)
I own a variety of monitors and can easily tell the difference between 60hz and 120hz. All things being equal, I of course prefer 120hz (or 165hz as some of my gaming monitors support).
I also own monitors at resolutions from 1440p to 4k.
For doing work (programming, where I'm mostly looking at text), resolution makes a huge difference. I only do coding on high DPI screens and I would upgrade to 5k or 6k or 8k displays if I were confident that my hardware and OS would support them well. (TFA was very helpful in that respect.) In these settings, high refresh rate makes only a marginal difference to my experience.
For gaming, refresh rate makes a much bigger difference, and resolution makes a somewhat smaller difference -- my hardware can't reasonably drive many of the games I play at 4k or higher anyway. So I just use cheaper, lower-resolution monitors that operate at high refresh rates for gaming.
Someday I guess I'll just be able to spend $300 for an 8k monitor at 240hz and then I won't have to make this kind of choice. (In fact, in the several years since I last bought gaming hardware I think the options for high-refresh-rate 4k monitors have gotten much better; I might use 4k for gaming if I were buying today.)
But for now, I'll always pick resolution over refresh rate for doing work, and it's not because I can't tell the difference.
Considering it again now, I do think it's essentially a bug, but it seems to be a known thing at this point. What I described is the same issue addressed by this unmerged patch: https://lkml.org/lkml/2017/9/18/739 (see discussion here: https://lwn.net/Articles/814535/). And it's mentioned in the article in this HN link:
> Those dentries still take up valuable memory, and they can create other problems (such as soft lockups) as well.
A deploy that was normally very fast would sometimes hang for a few minutes during a phase where all it had to do was delete the old application directory and move the new one into place.
Turned out that the application was writing a bunch of tempfiles into the cwd and then immediately deleting them. Nothing ever touched that directory while the negative dentries accumulated for weeks or months. When someone finally deployed, the first rmdir that came along bore the cost of deleting all those negative dentries. It hung for seconds or minutes while the kernel essentially cleared out the entire dcache, deleting linked list elements one by one. It showed up in perf as being stuck inside shrink_dcache_parent.
This is actually easy to reproduce:
$ mkdir /tmp/foo
$ touch /tmp/nodelete
# create and delete 100k files
$ for i in $(seq 1 10); do bash -c 'for i in $(seq 1 10000); do rm $(mktemp /tmp/foo/XXXXXX); done' &; done; wait
...
$ time rmdir /tmp/foo
rmdir: failed to remove '/tmp/foo': Directory not empty
rmdir /tmp/foo 0.00s user 0.02s system 91% cpu 0.024 total
$ time rmdir /tmp/foo
rmdir: failed to remove '/tmp/foo': Directory not empty
rmdir /tmp/foo 0.00s user 0.00s system 81% cpu 0.003 total
At some point we probably would've noticed the memory leak as well (I found an 18 GB slab on one host while this was happening) but the machines in question have huge amounts of ram.
I worked around the issue by making the application reuse tempfile names.
This is only true if you want the module to be publicly 'go get'-able. Private modules can be named whatever you want.
(Some tools use whether or not the first import path segment contains a '.' as a heuristic for "is this package stdlib", and those won't work correctly on a module that doesn't use a dot. There's a proposal, not yet accepted, to document this as a naming requirement for modules: https://github.com/golang/go/issues/32819 This is of course a looser requirement than "must be a domain name".)
*Well we do have an in-house job queue system that runs jobs in Linux namespaces for isolation. But it doesn't use Docker or whole-OS images at all.
In fact these exist -- if you search for "induction wok burners" you can see some pictures. (I only recently became aware of this after watching this video of a chef who uses induction cooking in a small kitchen: https://www.youtube.com/watch?v=ooNzRrHA9VY)
Perhaps in the future there will be cooktops that include a wok depression on the surface, similar to how some gas stoves today include a built-in wok ring.
This is a big reason why batch-based code review systems are great. I can quickly work through a pull request and point out every little thing that I notice because it's all a draft. Then I go back through and review my review. Sometimes things that I thought were problems are just things I didn't understand yet. Sometimes things I pointed out initially aren't even worth bringing up. And for the remaining points I can check that my feedback has the right tone and will come across well.
I really miss this cycle when I need to use something like google docs as a feedback mechanism, where all the comments I leave are immediately mailed out.
Slack is another system that encourages hasty responses. My critical feedback is better when I'm writing up an email and not participating in a realtime conversation.
Don't miss the issue report on the repo (basically, "here are two images that happen to collide???"): https://github.com/cmuratori/meow_hash/issues/80