It's not too much work, although things like unquoted tokens do introduce some ambiguity (a technical term for when two productions have overlapping start symbols) in the grammar. This is usually an academic concern though, as ambiguity can be resolved through backtracking, and as long as you don't require too much of it, it's fine.
I've implemented a hand-written recursive descent parser for something that is very similar to JSON5, and it wasn't difficult overall.
But all of my services speak JSON, so if I can do a tiny bit more work to speak the same language, that's an advantage that JSON5 loses over JSON. I don't think JSON5 is enough more human-friendly to make up for that rather large disadvantage.
A lot of scientists and journalists have not moved to other platforms. I tried to use instagram instead but the algorithmic injection of content and a terrible UI make it unusable for me.
I find using Twitter in the "following" mode, as opposed to the default "for you", I get a lot of value content and almost no noise.
How do you make it easy to stay proficient? For example you say your plane will never stall, will your pilots train stall recognition and recovery regularly? How will prevent something like what happened to AF447?
We'll still encourage and require the same proficiency checks that pilots do today.
Our hope is that GA pilots will no longer need to do things like train stall recovery. We are moving into an era of aviation where aircraft (not just airplanes) will be complicated enough that computers have to be in the loop to handle things like that, because it allows us to create more interesting aerodynamic aircraft that are more efficient and have better performance.
regarding something like AF447, the immediate answer is we have the ballistic parachute as a final backup in case the pilot is unable to land the plane, for whatever reason. Realistically, it would depend entirely on the exact situation our plane was in, what systems have failed vs which haven't, and the pilots actual skill level
> Our hope is that GA pilots will no longer need to do things like train stall recovery.
I hate everything about this thought process. Every pilot should know how to handle stall recovery, for the same reason that every driver should know how to handle loss of traction whether they have traction control or not. Driving the skill bar to the bottom intentionally will just result in more and more people flying without a clue what they're doing, just like we have on the roads today.
- even with redundancy, there can be enough failures that the computer no longer has enough information to make the right decision, one thing humans seem to be good at.
- people who had been trained in stall recognition and recovery, but probably had not kept proficient at it (unlike pilot of slow airplanes like GA and glider pilots) failed to recognize it (only 1 of the 3 pilot did) and did not recover from it.
• misc: Focused on web technologies (front-end, full-stack, edge), with extensive experience in UNIX and Linux sysadmin, clouds, DevOps, and Technical Support.
Yes. He said surfing a weather system, not surfing a wave. Which is exactly what they did. As a person who does surf, his analogy was accurate and meaningful.
Surfing has a specific meaning, where you ride the forward part of a wave and the movement of the wave behind your hull propels the boat forward.
Sailing in front of a weather system to get optimal wind for your sails is not surfing.
Imprecise language is sloppy and problematic for people with a functional vocabulary. Surfing is a technique used in sailing and this isn’t the same thing.
• misc: Focused on web technologies (front-end, full-stack, edge), with extensive experience in UNIX and Linux sysadmin, clouds, DevOps, and Technical Support.
I would recommend HOL Light and Lean. HOL Light is no longer being developed. It's very self contained and the foundation is very simple to comprehend. It's great for learning ATP, not the least due to the fact that Harrison wrote a nice companion book. And OCaml these days is very easy to access. I also developed a way to run it natively (https://github.com/htzh/holnat), which, while slightly less pretty, makes loading and reloading significantly faster.
I know nothing, I am a complete beginner when it comes to formal methods. From reading about it, it seems that Isabelle/HOL is the best when it comes to automation which apparently is something you really want. It might be easier to learn (controversial, some say Lean is easier). It's been used to prove some software (including sel4 and a version of java), Apple and AWS are using it (but then I know AWS uses, or used, TLA+).
At the end of the day, I didn't want to spend more time reading about it then learning two of them (trying one and potentially switch later). The more you read about it, the more options open up (SPARK, TLA+, COQ, etc...).
I do find it ironic to read this article today given that I made that decision yesterday!
The main upside Isabelle has over other proof assistants is the existence of Sledgehammer: invoke it, and your current proof state gets handed off to a SMT solver like cvc4, veriT, z3, vampire, etc. If the SMT solver finds a solution, Isabelle then reconstructs the proof.
It's essentially a brute-force button that no other proof assistant (aside from Coq) has.
• misc: Focused on web technologies (front-end, full-stack, edge), with an extensive experience in UNIX and Linux sysadmin, clouds, DevOps, and Technical Support.
Focused on web technologies (front-end, full-stack, edge), with an extensive experience in UNIX and Linux sysadmin, clouds, DevOps, and Technical Support.
https://json5.org/