Are you familiar with Java? If you use just `"foo"`, then the string will be interned and reused. If you use `new String("foo")`, each call creates a new copy on the heap. This call was inside a very hot loop, thus eating almost all the application's runtime.
What if functions are first class? Then imagine a function gets passed in as an argument and called. You won't know what function you're calling until runtime.
What are you talking about? Without further details I'm under the impression that you're just invoking the mystery of quantum computing. "Anything I don't understand is a threat."
Much of modern crypto is based on the assumption that integer factorization and discrete logarithms are difficult problems. With quantum computers, this is known not to be the case.
Known not to be the case if they actually worked in real life, that is. We're still waiting for a solid demonstration of quantum supremacy to prove that though.
A practical quantum computer would be capable of breaking almost all modern public key cryptography.
There's an entire field of research dedicated to figuring out what we'll replace those algorithms with if quantum computing does become practical on a significant scale: https://en.wikipedia.org/wiki/Post-quantum_cryptography
Most side-channel attacks have mainly been a threat to the implementation of cryptographic systems and algorithms. Now
Specter and Meltdown have brought that concern to all systems.
The gist of the parent post is, create complex systems and these things will bite.
Yes. Something you don't know about can and may well kill you. These are the lessons of geography, astronomy, and physics. Crypto and computer security may well have the same properties.
It's definitely a possibility (not sure how likely though).
"In the comments section of the Antonoupolos’s talk, reddit user @cfromknecht explains that there are flaws to the Elliptic Curve Digital Signature Algorithm (ECDSA), and it is very possible that quantum computers will be able to work faster than the transactions, therefore beating the encryption. “Whenever you spend bitcoins, you must include a signature that approves the spend, which is done using ECDSA” they explain, “If these signatures can be broken faster than transactions can be confirmed, an attacker could sign a different transaction that spends your coins before the original transaction is ever accepted.”
Seriously though, I'm talking about something qualitative here. When I read about these side-channel attacks yesterday I had this crazy gut feeling about how exposed our technologies are to those who learn to understand them deeply.
There's an complementary kind of arrogance to the one you're suggested: "anything I don't understand couldn't possibly be a threat... since I could never easily exploit it, it'd be way too hard for someone else to."
But have you listened to the radiolab about the z-cash cryptography ritual? It's very enjoyable and has a spooky surprise ending:
Yes, definitely, that's the kind of thing I'm thinking about, especially #2. Whereas a lot of exploits are happening with updateable software, it's rare that hardware gets hit so hard. This stuff hit on a deeper level.
I hope I don't offend anyone too badly here with this medical analogy, but it's like finding out you have a bad flu vs. finding out you have Parkinson's.
Or, it's like seeing someone in a different light for the first time... maybe you've known them for decades, but all of the sudden, you see them in this completely different way.
To me this entire argument "woe us if we run out of work to do" is directly self-contradictory. If people are miserable because they don't have the necessities of life, then, by definition, there's work left to do. On the other hand if there really is no work left to do, then everybody should be perfectly content with their material wealth.
The problem is automation could conceivably create a (sufficiently) closed system wherein a capitalist class can fulfil their desires for material wealth with minimal need for labor, while the masses lack access to the means of creating wealth (i.e. the tools of automation) or even fulfilling the basic necessities of life.
I don't see how a better understanding of the generated parser helps improving those things. Either you can't improve these, or you improve these by modifying the grammar.
Having used ANTLR recently I would tend to not only agree, but say most cases of disagreement are circle jerking instead of getting to a quick solution and shipping. I just updated our grammar 2 weeks ago. Effort? Update the *.g4 grammar file and run a build target in ANT. Done. Next problem. Performance wise it's parsing deeply nested SQL queries in sub millisecond time which meets our need. If someone requires better performance than that I'd be curious what they're doing.
This is true ideally, but there are several factors which make it not always true in practice.
(1) Often your grammar admits inputs which are not in your language. Less often, it forbids some inputs which are actually valid. This is usually because an accurate grammar would be extremely complex to write and inefficient to parse using a generic algorithm. Languages which combine a context-free grammar with parsing decisions based on semantic information fall into this category (think C++); the "true" grammar would usually be context sensitive and quite hard to work with.
(2) You are sometimes compiling a layered language. Again, consider C++. The program you're compiling is generally actually written in the C preprocessor language! Conceptually, it's translated to C++, and then the C++ code is compiled in a separate phase. In practice, that layering will make it difficult to produce good error messages, and a formal grammar for the combined language would be a mess to say the least.
(3) The structure of the grammar may just be awkward for producing good error messages, and refactoring it to eliminate the problem may not be possible, or it may only be possible by making problem (1) even worse.
In general, the decision of what goes in the lexer, what goes in the grammar, what is handled in semantic actions, and what is dealt with at a later semantic layer is always a trade off. Each layer has different characteristics in terms of computational power, performance, static analyzability, programming flexibility, composability, modularity, and maintainability. It doesn't make sense to insist that you solve all problems at one particular layer. You look at the problem you need to solve and decide how it'll be partitioned between these different layers to maximally benefit from their strengths and minimize their weaknesses.
In ANTLR4, they are most definitely not part of the grammar which they were in previous ANTLRs. That makes the grammar easier to read/change/reuse/... Everything else is listener and visitor methods which are easy to write, debug, error check, ....
You could theoretically put all kinds of meta-information into the grammar, even arbitrary code snippets that are pasted into the generated parser. I'm not saying that that's a good idea - it undermines much of the value of a parser generator - but generally speaking it can be done.
Also, are you planning to write another book at some point?