prance

I agree with your reasoning. Also, particularly

> software freedom, which in turn is a tool to protect user freedom

is AFAIK an assumption, or has this ever been proven?

I mean, isn't it entirely possible that helping software startups protect their business model of whatever "near-enough" OS/free software they build will help user freedom more than taking a purist OSS stance and leaving it all up for grabs by Amazon, Alibaba etc.? Because of increased choice and competition?

Well, I care, to some extent. Like many other things, it can be used as a filter. At the least, lacking other demonstrable evidence (such as open source or industry experience which can be confirmed by referrals), a finished master or PhD shows that someone is able to finish a non-trivial project.

The thing you're missing is that in order to achieve scaling, Lightning Network sacrifices one of Bitcoin's main advantages, decentralization: https://medium.com/@jonaldfyookball/mathematical-proof-that-...

The big difference is that jpeg creation with default parameters works fine for probably > 99.9% of use cases. A jpeg encoding the picture of a car will be just as fine as that of a cat. This is not at all the case with the current state of ML, as the originator of this thread has also pointed out with their example.

But there is actually one more problematic area for jpeg: encoding of graphs, drawings etc. with a limited color palette and straight lines. Here, jpeg artifacts become more visible, and to reduce them, you can either turn up the quality, or use a better approach like svg or png. For this, at least a bit of more technical knowledge is required. How many non tech-savy people do even know about svg or png?

But an even more appropriate comparison with ML would be to ask how to improve jpeg to better deal with straight lines. For this, you clearly need to understand the maths.

Incidentally, I also installed Opera Mini on my iPhone, living in Nairobi. However not because of data concerns, but because it allows me to access Facebook private messages without having to install any of the Facebook apps.

> Patterns do fit stereotypes perfectly.

No they don't. "Stereotype" is a psychological concept, and therefore by definition incorporates human subjectivity. There are various conflicting definitions, but most include the possibility or likelihood that many overstate or even completely falsely construct generalizations.

Or, as Wikipedia[1] states,

> By the mid-1950s, Gordon Allport wrote that, "It is possible for a stereotype to grow in defiance of all evidence."

> Research on the role of illusory correlations in the formation of stereotypes suggests that stereotypes can develop because of incorrect inferences about the relationship between two events (e.g., membership in a social group and bad or good attributes). This means that at least some stereotypes are inaccurate.

[1] https://en.wikipedia.org/wiki/Stereotype#Accuracy

> accents and other similar markings changes the pronunciation and meaning of words

Yes. In some languages those are actually not "markings" but denote proper letters, like in German ä,ö,ü and ß. But even if not, like in French, it can alter the meaning of words. E.g la != là. Therefore, for most Europeans and speakers of other languages that depend on more letters than ASCII provides, it is very annoying when that is not supported properly.

However, I have made the experience in a few cases that particularly Americans have a hard time understanding this. The remark about your wife not caring seems to be in this vein, too. Recently, I decided to convert our MySQL DB tables from latin1 to UTF8. (I wasn't even aware that we didn't have some form unicode, as our DB is only few years old, and I thought some unicode is the default nowadays everywhere. But then MySQL...)

Anyway, my CEO (also an American incidentally) was trying to keep me from it because he thought it's not high priority. However, we're about to go live in a French-speaking region, but which also has other indigenous languages (and therefore names), with their own "special" characters (I put "special" in quotes because for those languages, they're not "special" at all -- but I guess you get my gist by now).

Also, in previous jobs I have converted legacy systems to unicode and know what a pain it is down the road. Not to mention all the hard-to-find bugs if you don't do it, because some strings don't compare as they should, or people are just annoyed because their name is not shown correctly.

So I went ahead with the conversion anyway. We may never know for sure, but I'm convinced that I saved us some major customer frustrations, days of bug hunting and weeks of converting everything later, when existing data would need to be migrated.

So please everyone, just use UTF8 or some other unicode variant from the get-go. The few bits you might save otherwise are just not worth it.

This reasoning is probably behind some the OP's cases...

> One is with macros, which you can change the definition of when necessary.

I concur on this. In my phd thesis, I defined macros for all frequently used mathematical terms and expressions. This way, many places got almost as readable as the rendered formula.

For example, "\tfuzzy(1,2,3)", denoting a triangular fuzzy number with min. support 1, modal value 2 and max. support 3, is pretty clear after using it once or twice. We can then decide later how exactly to render it by changing the macro definition.

Similarly, when citing a lot of names (just using the names here, not actually paper references) wich characters which are not in my commonly used alphabet, I frequently define macros for them too. Then I can use e.g. "\Mares" in the text instead of "Mare{\v{s}}". Much easier, also when compared to hunting those special chars in a character map in a WYSIWYG word processor, or copy-pasting all the time.

However, I find this use of macros really only really pays off when working on larger documents, or living documents that keep changing, like CVs. For shorter and short-lived docs, I'd use Latex only if they have at least some math or special layouting requirements. I tried using Word's formula editor, but even though one can sort of get used to it, I find Latex much easier to use, especially with amstex. But for shorter documents without math, I find a word processor just much more convenient.

I don't agree with the view that a component doesn't need a prop "itself" if it "only" passes it on to a child component. That child component is a part of the parent. If one decided that e.g. the child is too simple to warrant to be its own component and inlined its render() content in the parent instead, suddenly its used props would be needed by the parent "itself".

Another thing to consider is that one tightly couples components to stores when connecting. So reusability of these components is hampered.

Thank you for giving your perspective on this, I for one appreciate it.

I also don't see how you've violated the guidelines (which btw. are called "guidelines" and not "rules", but that's another issue). Where you mentioned politics, you were merely stating facts or personal experience.

> instead of returning something semantically like a function, std::bind returns something that might be better described as a partial syntax tree that happens to be something you can call as a function

Indeed. std::bind seems to work more like a Lisp-ish macro than a function in this regard.

> Well, let’s look at that. People who work in schools, higher ed, public institutions of education — they are government employees.” And they represent almost half of the 24 million, his data shows.

> “And you say, O.K., what are the other big blocks?” Mr. Ballmer continued. “Well, active-duty military, war fighters. Government hospitals. Really? I didn’t know that.”

I'm really surprised if this really surprised him. I mean, the ex-CEO of one of the most powerful and influential corporates on Earth didn't know that soldiers, public teachers, medical personnel etc. are employed by government?? If that's true, I don't even know what to say. I would find it ridiculous, laughable, if it wasn't so sad.

Problem with the skeumorphic design is that it's only approachable by people who are already familiar with the hardware, as dperfect already said. I share their frustration with such interfaces.

Also, non-skeumorphic doesn't have to maximize flexibility. It could just as well be designed for ease-of-use.

> Unfortunately, Sun decided that almost all Java errors must be recoverable, which results in lazy error handling like the above.

Not quite: Java insists that all (checked) Exceptions be handled or passed up explicitly. One can argue that this design decision is bad, as has been done extensively elsewhere.

However, in the particular example given, I'd argue that it would have made much more sense to display a user-understandable error message to the user (e.g. "Required gun resource file is missing, please re-download the game here: (...)"), and then just System.exit() if it's non-recoverable. Maybe print a stacktrace if the game was started in debug mode.

>The set of all possible assembly instructions is bigger than the set of all possible assembly instructions that haskell can compile to.

No it's not. The Haskell compiler is free to use whatever assembly instructions that it sees fit to compile the Haskell program.

Maybe you mean that effectively, the set of assembly programs (i.e. sequences of assembly instructions) which existing Haskell compilers happen to produce is limited. This is true. But it is also true that you can find an equivalent Haskell program for every possible assembly program, where equivalent means they exhibit the same behavior with respect to inputs and outputs. This is because both are Turing equivalent.

Now, it's also true that the way two equivalent programs get to their results may differ. For example, the assembly program might be faster. However, these are non-functional properties of the programs. And you were talking explicitly about functionality, so this point doesn't count towards your argument.

I would go further: is "Axioms exist" true? You don't find them lying around in nature. They exist only in people's minds. I would argue that this is an inherent metaphysical question.

The scientismist's (?) standpoint could be that it exists because it is manifested as a concept in human brains. But by the same argument, wouldn't they then need to acknowledge that God exists?

The crux of the matter is to do science, you need formalism to express your theories, to interpret measurement results etc. Those formalisms are what we usually call "math". But any mathematical system has axioms, i.e. something we need to just "believe" in in the first place, and those believes are not themselves provable by science.

I guess "not applicable" because the op's list is clearly referring to the US only. You'd need a whole new list for those licenses as applicable in the EU or other places.

In German we have "Fachidiot", which is not pronounced like the Dutch 'vakidioot' at all, but many English speakers would do so nevertheless. You're free to rescind your own abomination of that word :D

> That could lead to overcrowding in the federal court in Delaware, he said, given the large numbers of corporations incorporated in the state.

Wouldn't that actually be fair? As it is now, it seems that Delaware can give all those tax breaks, and not bear any consequences.

> Except you cannot have static signs from one direction, where the other directions have traffic signals.

I don't know about such a rule. There are some intersections in Germany where there are red and orange lights, but no green for e.g. just one direction. At such a place, when no light is on, rules according to the static signs apply, while other directions still show some light. So what you're saying doesn't hold at least temporarily there.

> This solution is neat

I don't think so. Someone unfamiliar with the place might think the light will turn eventually green, even if it's unclear where one could go if it did. It will at least cause confusion and unnecessarily draw attention away from actual traffic. And of course there's the maintenance and power cost.

> Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there.

That is not what is usually meant by "expressiveness" of a language. You seem to be talking about types of languages (as in the Chomsky hierarchy), by implying that there are problems you can solve in assembler but not in Haskell. That is not the case, as both are Turing-complete (Type-0).

In contrast, "expressiveness" usually refers to the "ease" (one may substitute conciseness in most cases) with which higher level concepts (abstractions) are expressible in the language, and here Haskell clearly wins against assembler, and many other popular languages.

As a researcher in multiagent systems, I know this problem very well. Which is, I believe, exactly the point the article makes. But it goes on to say that this might be possible to overcome by embodiment and developmental psychology. Not new arguments for sure, but valid ones, and brought at the right time (a year ago) of a new AI hype.

That light is totally redundant. The white-on-blue right arrow as well as the solid line in the middle of the street already mandate that only right turning is allowed there.