Note that depending on what parsing lib you use, it may produce nodes of your own custom AST type
Personally I love the (Rust) combo of logos for lexing, chumsky for parsing, and ariadne for error reporting. Chumsky has options for error recovery and good performance, ariadne is gorgeous (there is another alternative for Rust, miette, both are good).
The only thing chumsky is lacking is incremental parsing. There is a chumsky-inspired library for incremental parsing called incpa though
If you’re interested to read something on that topic I highly recommend the essay "That's About the Size of It" by Isaac Asimov (in his book "View from a Height").
He argues that human perception of animal size is skewed because humans use themselves as a benchmark.
He takes a logarithmic approach to illustrate where humans actually fit within the overall scale of the animal kingdom. We are way larger than we think we are!
Besides the sociological problems listed, we must always be conscious of how counterintuitive and difficult statistical inference itself can be. Good things to search for are statistical fallacies, probabilistic paradoxes and books like Counterexamples in Probability.
And it is not sufficient to read about them once or twice; researchers who use statistical inference regularly must revisit these caveats at least as regularly.
Myself, I have taught Probability and Statistics many times, discussed and dispelled many misconceptions by students. Would I be 100% sure I will not be caught up in a fallacy while informally thinking about probability? I wouldn't even be 10% sure; any intuition I conjure up, I would triple check as rigorously as possible.
I've been feeling lately that as computers have become more advanced and software has become more inscrutable, our relationship with our computers has changed, for the worse. This essay hit home for me: https://explaining.software/archive/transparent-like-frosted...
These old-school computers viewed their users as creators, as developers. Modern computers (read: smartphones) _are_ the users, and the "used" are just ad-watching revenue cows. I passionately hate this arrangement.
When I have children, I want them to know what computing should feel like---empowering, creative and stimulating, not controlled, consumptive, compulsive and mindless. I want to give them a computer that builds up their spirit, rather than grinding it down.
I think this computer should have several qualities:
0. The computer should be about _creation_ and not consumption.
1. The computer should be _local_, not global. Intranet should be prioritized over Internet.
1.5 A corollary, the computer should be _personal_. It should encourage and reward in-person interaction, physical sharing of information and programs, and short-range connection between computers.
2. The computer should be _limited_. Because the medium is the message, we have to restrict the capabilities of our media to better promote the messages we value.
2.5. A corollary, the computer should be _text-oriented_. Graphics shouldn't be impossible, but text should be primary. The computer should cultivate a typographic mind, not a graphic mind (in Marshall McLuhan's terminology).
3. The computer should be _focused_. It should never distract you from what you want to work on.
4. The computer should be _reactive_, not proactive. It should never give you a notification. You should be in charge of retrieving all information yourself, like a library, not a call center.
5. The computer should be _physical_. It should be oriented around physical media.
6. The computer should be _modifiable_. It should encourage and reward inspection into its internals, and be easy to change.
7. The computer should be _simple_, understandable by a single person in its entirety with time and study.
The Mega65 is amazing and checks these boxes, but unfortunately it's a tad expensive for me. What other machines are out there like this?
Veins of heavy metals are created by the chemistry of hydrothermal systems. High-pressure super-heated water is a great solvent and will leach many things out of the surrounding rocks in a chemistry and temperature/pressure dependent way.
These hydrothermal systems can be structurally enormous and form gradients e.g. due to differences in rocks and temperature at different depths. This acts a bit like a distillation column. Every metal has different characteristic solubility and will precipitate out of solution in boundary areas where amount of metal in solution exceeds the solubility under those conditions. Since these are fluids, the solution is circulating, bringing fresh saturated solution to the boundary area.
In some regions like Nevada, there are places where very large and diverse gradients are exposed e.g. you will find copper, silver, gold, tin, mercury, lead, uranium, etc veins of various quality distributed across the same very local geological formation as different metals were deposited in different places within the same hydrothermal system.
A limitation on formation is that it typically requires a relatively large hydrothermal system with stable properties and appropriate chemistry over millions of years. The kinds of places that have large hydrothermal systems also tend to be geologically unstable.
> (1) Hue was not a good dimension for encoding magnitude information, i.e. rainbow color maps are bad.
This is very good advice. Generally, hue expresses difference in kind whilst lightness and saturation expresses difference in degree. This is beautifully demonstrated in Nault's study of how children read maps.
Nault, W.H.: Children’s Map Reading Abilities. Geographic Society of Chicago, Newsletter, III (1967)
"If I'm doing my job right, you'll see me come up with solutions so obvious and clear, you'll wonder why they took so long." It is hard to come up with really good answers to questions. To make sure that the obvious, is really correct, etc.
I've given code reviews where I've told people to remove 100's of lines of code and use a module we already use.
My way is not the easy way today. My way is the easy way over the years.
Some time ago, an article made me rethink my view on the speed differences between cars and bicycles. Here, too, you have to pay twice with your own lifetime, because ultimately the time it takes to get from A to B is not simply the driving time, but you have to add to it the (proportionate) working time to earn the money you need to acquire, operate and maintain the vehicle: speed = (working time + driving time) / distance. Of course, the outcome of this calculation varies depending on the specific situation. I recommend everyone to estimate this once for their personal situation. In any case, I was amazed at what came out for me.
Key insight. One annoying thing in many workflows is different programs and file environments (GUI or CLI) bein gout of sync with the patterns of the work I'm doing; why (I ask myself) am I having to traverse the same routes around my directory tree like a squirrel carrying nuts and and berries back and forth?
There's no flow between the OS and application UI in most instances.
I once took a class in college, “Cars and Culture”. I never forgot a line from that class - that “cars provided an extension of our legs”.
Ever since then, I have told many people and thought to myself many times, that tools, take Google for instance (search and indexing), knowledge management systems (Wiki and other techniques) - these are all extensions of our brains.
We evolve with technology, and it evolves with us. We might be losing our ability to remember, but if it is because we don’t “need” to remember because technology has augmented us... Well, this is why I also am fond of telling people that I have a difficult time separating technology from nature. Even though the two don’t seem like the same thing, technology too becomes part of the natural ecosystem as organisms invent and rely on it.
Also, another way of thinking about this is, maybe the ability to recall small detailed facts was evolutionarily less important than building models in our brains. So, we offloaded recording small facts, while I think we still ingest and build/train our neural nets just fine in our brains.
Then the only problem I see is, if life becomes all about mental models, when our ability to form new mental models degrades with age, what then? Especially with the rate of technological change, I do see a real likelihood that old mental models get left behind and without the ability to adapt, organisms (i.e.) us could be hosed.
Edit: ..and the last sentence could be why the big push for AI and machine learning too - to ensure the models get encoded into the technology too... and be discovered faster, changed more fluidly, etc. Another evolutionary tool.
I like the "different kings" metaphor. An archive has to think long-term. To do its job unimpeded it has to remain inconspicuous and unobjectionable, otherwise it may lose access to information altogether. Kings and cultures will come and go, but as long as they have the data then their mission is substantially fulfilled. At some point in the future even the most radical material will become innocuous and safe to publish.
For example, this is why the archive obeys robots.txt policies retrospectively. I can't access my personal web pages from 20+ years because at some point the university changed it's robots.txt policy. (The domain no longer exists, freezing that policy quasi-permanently.) But at least they're archived. Maybe at some point before I die I'll get to see them again, but at least it's a possibility. More importantly, my "sacrifice" (such as it is) is a small price to pay to help ensure that archive.org preserved access to material that would have been cut off if websites felt that they didn't have control of availability once archived.
We can't expect archive.org to fight our battles for us, whether regarding censorship, copyright overreach, or other issues. It's great that they do to the extent that they do, but their success is partly a consequence of them picking their fights and emphasizing their character of being a quiet, harmless archiver. It would be counter-productive to ask them to risk that credibility and power. And it's entirely unnecessary.
As soon as a patch is released, it should be presumed that bad guys know all the fixes in it. Once a patch is released, people with bad intentions study all the changes (source code for open source, and decompiling for closed-source) and find all the changes that were made, looking for opportunities to exploit.
This happens to 100% of MS Windows Patch Tuesday patches, and happens to less well known products as well. These examinations happen even on changes that aren't known to be security problems when they are fixed: the recent EXIM worm problem was actually fixed by the EXIM team as a minor bugfix, and they didn't categorize it as a security flaw. It was only when outsiders at Qualys [1] saw the change that they realized it was possible to do a remote command execution.
In essence, the bad guys are patient, smart, and observant. They will notice all of these code changes. So disclosing the problem after it is patched serves to encourage users to patch, because it boosts and amplifies the "get updated" signal for the good guys, and the bad guys already are paying attention.
I don't see the value in lamenting the old days of a few machines where you could actually name them as Middle Earth characters, install individually, log in to one single machine to debug a site issue. The problems were smaller and individual server capacity in respect to demand was in meaningful fractions. Now the demand is so high and set of functions these big companies need to offer are so large, it's unrealistic to expect solutions that doesn't require distributed computing. It comes with "necessary evils", like but not limited to configuration management--i.e. ability to push configuration, near real time, without redeploying and restarting--, and service discovery--i.e. turning logical service names to a set of actual network and transport layer addresses, optionally with RPC protocol specifics. I refer to them as necessary evils because the logical system image of these are in fact single points of failures. Isn't it paradoxical? Not really. We then work on making these systems more resilient to the very nature of distributed systems, machine errors. Then again, we're intentionally building very powerful tools that can also enable us to take everything down with very little effort because they're all mighty powerful. Like the SPoF line above, isn't it paradoxical? Not really :) We then work on making these more resilient to human errors. We work on better developer/operator experience. Think about automated canarying of configuration, availability aware service discovery systems, simulating impact before committing these real time changes, etc. It's a lot of work and absolutely not a "solved problem" in a way single solution will work for any scale operation. We may be great at building sharp tools but we still suck at ergonomics. When I was at Twitter, a common knee-jerk comment at HN was "WTF? Why do they need 3000 engineers. I wrote a Twitter clone over the weekend". A sizable chunk of that many people work on tooling. It's hard.
You're pondering if hiring practices and turnover might be related? The answer is an absolute yes. On the other hand, these are the realities of life in large tech companies. Hiring practices change over years because there's a limited supply of of candidates experienced in such large reliability operations and industry doesn't mint many of them either. We hire people from all backgrounds and work hard on turning them to SREs or PEs. It's great for the much needed diversity (race, gender, background, everything) and I'm certain the results will be terrific but we need many more years of progress to declare success and pose in front of a mission accomplished banner on an aircraft carrier ;)
You are also wisely questioning if turnover might be contributing to these outages and prolonged recovery times. Without a single doubt, again the answer is yes but it's not the root cause. Similar to how hiring changes as company grows, tactics for handling turnover has to change too. It's not like people leave the company, but within the same company they move on and work on something else. The onus is on everyone, not just managers, directors, VPs to make sure we're building things where ownership transfer us 1) possible 2) relatively easy. This in mind, veterans in these companies approach code reviews differently. If you have tooling to remove the duty of nitpicking about frigging coding style, and applying lints, then humans can indeed give actually important feedback on complexity of operations, self describing nature of code, or even committing things along with changes to operations manual living in the same repo.
I think you're spot on with your questions but what I'm trying to say with this many words and examples is, nothing alone is the sole perpetrator of outages. A lot of issues come together and brew over time. Good news, we're getting better.
Why did I move around? Change is what makes life bearable. Joining Twitter was among the best decisions in my career. Learned a lot, made lifelong friends. They started leaving because they were yearning a change Twitter couldn't offer. I wasn't any different. Facebook was a new challenge, I met people I'd love to work with and decided give it a try. I truly enjoy life there even though I'm working on higher stress stuff. Facebook is a great place to work but I'm sure I can't convince even %1 of HN user base, so please save your keyboards' remaining butterfly switch lifetime, don't reply to tell me how much my employer sucks :) I really hope you do enjoy your startup jobs (I guess?) as much as I do my big company one.
Personally I love the (Rust) combo of logos for lexing, chumsky for parsing, and ariadne for error reporting. Chumsky has options for error recovery and good performance, ariadne is gorgeous (there is another alternative for Rust, miette, both are good).
The only thing chumsky is lacking is incremental parsing. There is a chumsky-inspired library for incremental parsing called incpa though