> The article describes affixing the word "await" to methods in a programming language as a "postfix" and explicitly contrasts it with a "prefix", which is a linguistic term for affixing words, commonly contrasted with the term "suffix".
I'm not getting your point. I don't think you are summarizing the language accurately. Perhaps you could quote the section of the article at length.
Here is one quote from the article: "The lang team proposes to add the await operator to Rust using this syntax: `expression.await` This is what’s called the “dot await” syntax: a postfix operator formed by the combination of a period and the await keyword. We will not include any other syntax for the await operator."
Here is another quote: "Our previous summary of the discussion focused most of our attention on the prefix vs postfix question. In resolving this question, there was a strong majority in the language team that preferred postfix syntax. To be concrete: I am the only member of the language team that prefers a prefix syntax. The primary argument in favor of postfix was its better composability with methods and the ? operator."
These usages of "prefix" and "postfix" are consistent and idiomatic.
I don't want to name any particular people or groups, because everyone makes mistakes and has limitations.
I will say this: in my personal experience, I've been a part of groups that struggle in dealing with complex decisions. Many times they get bogged down when they don't find a clear answer that satisfies everyone or all criteria. In many cases, such groups don't have a clear leader or the leader lacks the skills, experience, and character to do what is necessary; namely, choose (and communicate) the least-worst decision that keeps the ball moving forward.
In such cases, it is not necessary (and unrealistic to expect) that everyone agree with every aspect of every decision. A leader needs confidence and persistence to make tough decisions, as opposed to abdicating leadership. Some examples of the latter include (1) ignoring a choice until some default decision is made implicitly or (2) simply choosing the idea from the most vocal person.
Put more broadly, in this context, leaders must balance four aspects: (a) scoping and framing a decision; (b) gathering diverse points of view; (c) building some degree of consensus or buy-in; and (d) making a decision. It appears to me that the Rust language team handled all four comprehensively.
RPN and postfix notation refer to the same core idea. From Wikipedia: "Reverse Polish notation (RPN), also known as Polish postfix notation or simply postfix notation, is a mathematical notation in which operators follow their operands, in contrast to Polish notation (PN), in which operators precede their operands."
Can you please explain why you wrote "Reverse polish notation is an entirely different usage"? With a citation, preferably.
I am unfazed by this observation. When it comes to design, sometimes ‘perfection’ isn’t available.
By the way, the idea you mention may also be true for democracy: the quote goes something like “Democracy is the worst form of government except for all the others.”
If you have a design option that has not already been considered, I’m all ears.
I appreciate your opinion, but I want to point out that our definitions of fairness and simplicity may vary. Much of scholarly work around elections systems strives to ground itself on particular formal criteria.
Arrow’s Impossibility Theorem, as I understand it, applies quite broadly to voting systems. To put it simply, you can’t avoid it. You just decide what trade offs you want to live with.
Enlightened morality often means being mindful of tradeoffs.
Not doing an exhaustive search of academic literature because it is prohibitively expensive or time-consuming is a clear negative -- doing so may result in lower-quality research.
I personally see many good reasons to distinguish general intellectual property theft from using SciHub for academic research.
Perhaps it is accurate to say the most mobile, unattached people tend to go first.
Perhaps the more loyal people stick around longer -- this puts a positive spin on it.
But you could also say that the most opportunistic people go first -- putting a negative spin on it.
Also, I think it depends heavily on what you mean by "bad". As a company culture deteriorates, sometimes it is the people who have been there the longest that don't notice the decline (see https://en.wikipedia.org/wiki/Boiling_frog)
1. I'm skeptical of a claim such as "But the actual medium doesn't matter as much as the practice you follow". I recall hearing about studies that show tactile experience (physical writing for example or being physically present during a lecture) forms better memories, at least in many people.
2. I strongly disagree that the best way to store your ideas is to memorize them. First, memorization isn't feasible, information-wise. Second, memorization is not most people's general goal. I would suggest a more general goal is to recall the salient features of your ideas and connect them to your task at hand. This suggests a mix of storage mechanisms: some memorization (i.e. for indexing, summarization, and connecting) with other higher-bandwidth, less-error-prone storages.
To prove my second point with a counterexample: I highly doubt that visual artists can remember every brush stroke on their favorite canvases. It is more important, arguably, that they organize their work in a way that they can refer to it. And, for the purposes of creating future work, I doubt that memorizing exact details of previous work is the most important. Remembering the inspiration and the techniques is probably more important.
It all comes down to your definition of "we". In short, this is either a collective preference problem (e.g. not enough people care or pay attention) or a collective action problem (if you believe that at least collective intent exists).
More specifically, a common theme in public policy analysis is agenda setting. Unfortunately, in many situations, the agenda is so crowded with priorities that only crises cut through. For more context, see "The Public Policy Primer: Managing the Policy Process" (https://www.goodreads.com/book/show/8727263-the-public-polic...)
50? That would be nice. For any given forward-thinking issue, I consider us lucky to have a handful of innovators at the state level. Now, when a crisis of some sort comes around, lawmakers from others states will start to pay attention. Ideally, at that point, they will evaluate and adapt other state experiments. In practice, it depends on the timing, committees, etc. Sorry to sound a bit cynical, but really my take-away message is this: if you care about an issue, get involved one way or the other in lobbying for your cause (I'm assuming here that HN people are well-informed, even if we have different policy prescriptions).
Sometimes people use "compete" in a casual way that overlooks key economic connections. Competition is a force that is always present, even if it is not currently the "most obvious" factor in play at a given time.
I think any definition of competition must be relative to the sphere of economic activity. So, when it comes to transportation in general, rail and trucks do compete -- by this I mean they offer services with varying prices and characteristics.
Just because rail and trucking have different sweet spots at a particular point in time does not mean that they don't compete. Both (a) think about how and why customers choose them over the other, (b) seek opportunities (for investment or growth) that lead to a competitive edge, and (c) therefore, influence each other.
Think of shipping as an optimization problem where various modes are selected for different parts of the path. You have to run the optimization problem to see what mix makes the most sense -- and don't expect it to necessarily be simple or obvious.
Logistics is complex; you'll also need to factor many things into the optimization:
* both fixed and marginal costs of each mode (e.g. maintaining track, monitoring safety, wear and tear on vehicles, varying fuel costs)
* constraints (due to technology, personnel, regulations, etc)
* fluctuations in demand and shipping objectives
* lots more
If you want to focus on only one slice of the problem... Sure, for the exact same route (meaning that a particular track has already been built), one would expect that trains are more efficient. The data shows that; e.g. https://en.wikipedia.org/wiki/Energy_efficiency_in_transport...
I interpret this comment as saying: if you find yourself in that kind of situation, look around and try to find other opportunities. In other words, life is too short.
I also can see the other side: life is often not fair, particularly in the short-run. Life constraints such as geography are real barriers for many people.
Some of these probably don't come to everyone's minds right away. Please share your favorites.
The behavior(s) that a particular language guarantees is a design question. Once those guarantees are specified, we can objectively evaluate a particular language in terms of how well it does according to its own standards.
Again, RPN and postfix notation mean the same thing.
Here are some more references that show how these terms are commonly used:
1. https://en.wikipedia.org/wiki/Infix_notation
2. https://en.wikipedia.org/wiki/Polish_notation
3. https://en.wikipedia.org/wiki/Postfix_notation (which redirects to a page on RPN, which is very strong evidence that your claim is incorrect)
Ok, onto the next thing. You wrote:
> The article describes affixing the word "await" to methods in a programming language as a "postfix" and explicitly contrasts it with a "prefix", which is a linguistic term for affixing words, commonly contrasted with the term "suffix".
I'm not getting your point. I don't think you are summarizing the language accurately. Perhaps you could quote the section of the article at length.
Here is one quote from the article: "The lang team proposes to add the await operator to Rust using this syntax: `expression.await` This is what’s called the “dot await” syntax: a postfix operator formed by the combination of a period and the await keyword. We will not include any other syntax for the await operator."
Here is another quote: "Our previous summary of the discussion focused most of our attention on the prefix vs postfix question. In resolving this question, there was a strong majority in the language team that preferred postfix syntax. To be concrete: I am the only member of the language team that prefers a prefix syntax. The primary argument in favor of postfix was its better composability with methods and the ? operator."
These usages of "prefix" and "postfix" are consistent and idiomatic.
I hope this clears it up.