vertere

And what if there is more than one way of joining two tables, or a table to itself?

A foreign key is effectively a reference to another column, but to de-reference it you have to tell the database which table and column it's a reference to. Every time. Even when this information is already specified in a foreign key constraint.

The author is talking about (not) being able to specify the "from" table and column without having specify the "to" table and column (i.e. tell the database how to de-reference it) on each query. A natural join removes the need to specify the columns, but still requires specifying both tables. So besides requiring a de facto single namespace for columns across tables and generally seeming like a footgun, it doesn't achieve the same thing.

Thanks, I did not know that about Bazaar. I wish that were the norm in Git-land.

But I can see why people might still desire more explicit constructs to handle history organization. The expectation that the commit graph should be both logical and historical causes a sort of cognitive dissonance, which these sorts of conventions don't fully resolve.

> Profitable means it has to grow faster than inflation or wages.

That is not what profitable means. Returns on investment in housing consist of: 1. rental yields, and 2. capital gains (i.e. change in price).

You cannot say whether housing is profitable or not (or affordable, for that matter) only by considering number 2.

I'm not super familiar with v2 but from what I have read it's not clear how it achieves the same thing as IPFS. Yes, the file-hashing is deterministic, which can allow deduplication across torrents, but it doesn't seem to facilitate either discovery or addressing at the file level. Trackers/DHT and magnet links still only use the info hash (torrent level) as far as I can tell.

IPFS puts file/object hashes in the DHT so they are directly discoverable, meaning people coming to the same object from different from different places can find one another. It also allows one object to be explicitly addressed via an ancestor object's hash (<hash>/path/to/object), which has various benefits.

Bittorrent also has a DHT, which you can use instead of (or as well as) tracking servers.

Perhaps the key difference is that torrents (targets for magnet links) can't link to other torrents, at least not in a way the protocol is aware of. Each torrent swarm is something of an island. IPFS is more like one big graph ("web") of documents/files.

Choosing based on whether it's in quotes seems like a better solution than using an equals sign. Not everything follows that convention admittedly, but not everything understands the '=' either. Or it could just treat everything as text until a user tells it otherwise.

But none of that is really the point. Because CSV files aren't just for importing into Excel. One of their main benefits is their portability. In other situations column types might be specified out of band, but even if not, putting equals signs before values is unconventional, so more likely to hurt than help. And in the cases it might help, i.e. when you only care about loading into Excel, then you have options other than CSV, rather than contorting CSV files for Excel's sake.

> What ever happened to process and a sense of responsibility and craft in your work?

I actually have no idea what you are on about. I'm talking about the "responsibility and craft" of not producing screwed up CSV files. Why do some people find that so offensive? Yes, it is not inconceivable that there could be some situation working with legacy systems where putting `="..."` in CSVs is, unfortunately, your best option. Sometimes you do have to put in a hack to get something done. But don't go around telling people (or yourself) that it is "the correct way".

I sure don't want to have to deal with people putting `="01"` in CSV files.

Perhaps by "correct way" you meant "dodgy hack to make Excel happy and risk breaking more sensible implementations"?

Excel may predate the RFC but AFAIK MS didn't invent or coin the term CSV, so you can't just say whatever Excel does is correct. The RFC is loose because of nonsense like this, it doesn't mean it was ever a good idea.

I don't think "normalised" is specific enough. Normalising can refer to division by values other than the maximum. I'm also not convinced it implies non-negativity.

(My vote's with "proportion" BTW.)

https://en.wikipedia.org/wiki/Normalization_(statistics)

I too am surprised "proportion" was not the obvious answer.

Here's another recent HN/Twitter discussion [0] that surprised me and made me think a lot of programmers haven't done much numerical programming.

[0]: https://news.ycombinator.com/item?id=24223033

The first statement of the problem in the wikipedia page (from "Ask Marilyn") does not state it explicitly (though it does say the host knows what's behind the doors). There is a reason wikipedia refers to them as "assumptions".

Or from [0]: "The standard annunciation of the MH problem, does not make explicit what I am assuming here: namely, that Monty will always open a door which does not contain a prize."

[0]: https://www.montyhallproblem.com/#F2

Sure you can generalize it by weighting the outcomes by their probabilities (not mentioned in the article). But how are you going to calculate those probabilities any more easily than you can solve the posed problem?

The more "intuitive" way of generalizing it (integer counting) does not work in general. I think the example is likely to be misleading to anyone who doesn't already understand this stuff.

As suggested by the footnote, the reason the given example can be solved elegantly is because of the symmetry.

This method only works because the boxes have the same number of balls. To calculate probabilities by counting outcomes you have to start with outcomes that all have equal probabilities.

> The problem is that it makes no sense to even formulate a nonlinear utility function for an ordinal scale, because there will be a linear function that represents the same preferences.

I'm afraid I don't understand your point. There won't always be a linear function representing the same preferences and anyway 'ordinal' utility functions that represent the same preference order mean the same thing, so they make as much sense.

> EU makes no sense with purely ordinal utilities either, but economists use it all the time. When they do so, they assume cardinal utilities

They use cardinal utility but they don't just assume it. The assumptions (implicit in a lot of cases, admittedly) behind Expected Utility are generally the Von Neumann-Morgenstern axioms (relating to ordinal preferences over probability distributions over outcomes) [0].

> the Principle of Diminishing Marginal Utility makes no sense with purely ordinal utilities

True, but I think very few if any economists would be confused about this. Also economists and econ text books (particularly after 101) are more likely to talk about marginal rates of substitution [1] or convex preferences [2] than diminishing utility.

[0]: https://en.wikipedia.org/wiki/Von_Neumann%E2%80%93Morgenster...

[1]: https://en.wikipedia.org/wiki/Marginal_rate_of_substitution

[2]: https://en.wikipedia.org/wiki/Convex_preferences

One time I used a system that, when setting my password, it converted all letters to lower case, but it didn't do the same when trying to log in. I figured out that's what happened when I called them and they told me to give them the password over the phone (yep) and then started giving me hints about what was 'wrong' with the password I gave them. This was a financial services company.

> The broadband market was experiencing a classic "prisoner's dilemma," where neither cable nor DSL providers felt a competitive threat from the other requiring substantial new investment, trusting in relative peace within their own market segment. Continued expansion of broadband capacity was on the verge of stalling.

I don't see how that can be viewed as a Prisoner's Dilemma.

> By being at the intersection, [JSON] turns out to be the thing that everybody can agree on, and so it's really easy to pass data back and forth. Prior data interchange formats tended to try to be the union of all the languages, and that turns out to be horrendously complex and really difficult to deal with. JSON by being so simple actually became really easy to use.

- Douglas Crockford ('discoverer' of JSON)

https://youtu.be/-C-JoyNuQJs?t=730

Seems like a good case study in poor communication then. It doesn't excuse people spreading misinformation without a decent attempt to ascertain the facts, but it seems Redis Labs mainly have themselves to blame. Their page [0] starts out: "Initiated by a coalition of top infrastructure software companies to protect their rights...". So they're trying to make it sound like a Big Deal, and beyond just for Redis. Then later we hear 'oh it's just relicensing a couple of non-core modules, what are you all carrying on about?' Even now it's not clear to me (not being particularly familiar with Redis) what direction things are changing in.

shakes head

Edit: Oh, and the confusing name. Why is it called "Commons Clause"?

[0] https://redislabs.com/community/commons-clause/

> an old fashioned bank transfer can be corrected if I transfer money and make a mistake writing the account number. Mutable history is a powerful feature.

That's not necessarily mutable history though. Such a correction will usually be made by an inverse transaction, not by wiping the original transaction from the record.

Both well-defined protocols and vaguer design/architectural principles have their place. But is it a great idea to take a bunch of such principles and bundle them up under a (confusing) name? Perhaps not.

It seems to me that the initial popularity of "REST" was largely because it wasn't SOAP (and didn't have to be XML), but it was still a name you could give what you were doing that made it sound like you were following some sort of standard.

I have some sympathy for your philosophy, but clearly it's important to have a reasonable amount of memory and preservation, and to have some degree of control over it. What we're facing seems like a rather random, senseless erosion of those things.

It is true that a lot more stuff gets kept these days. But we seem to be much more liable to losing important information. As Bret Victor [0] has pointed out, we use largely the same mechanisms for managing the most trivial to the most important information, and most people don't really understand how they work.

> a 2013 survey of law- and policy-related publications found that, at the end of six years, nearly fifty per cent of the URLs cited in those publications no longer worked. According to a 2014 study conducted at Harvard Law School, "more than 70% of the URLs within the Harvard Law Review and other journals, and 50% of the URLs within United States Supreme Court opinions, do not link to the originally cited information." [1]

I doubt that the US Supreme Court was regularly losing track of cited documents before "information technology" came along. A lot of documents may be recoverable even if the original URLs are broken, but is this really the best we can do to manage information in the information age?

[0]: http://worrydream.com/TheWebOfAlexandria/2.html

[1]: https://www.newyorker.com/magazine/2015/01/26/cobweb

> a human hair is just under 100 nanometers in diameter

Does he mean micrometres? From wikipedia[0]:

> The diameter of human hair varies from 0.017 to 0.18 millimeters (0.00067 to 0.00709 in).

[0]: https://en.wikipedia.org/wiki/Hair#Description

Yep, in other words the prior probability of a user trying to use a 'bad' password will be a lot higher than badpasses/allpasses. The whole point of checking against a list of compromised passwords is because people reuse their passwords.

R certainly has a lispish code-as-data element to it, but it seems like it has some serious flaws. Don't most lisps have functions and macros as separate constructs? R has functions, but with some mucking around you can make them do macro-type stuff. Then people write these half-function, half-macro things (e.g. "non-standard evalation") that tend to break composability, either totally or sometimes only in edge cases.

I hate it as well. And then you get people going on about "functional style" while throwing referential transparency out the window.

> It's the same if you tried to access a[0] or a[90000] (in an array that doesn't have 90000 elements).

It's not the same: `a[90000]` would be `NA` (which is a 1-element vector, not an empty vector).

You might be right. Whereas programmers tend to regard languages as something to be understood, package managers are something they just use ("if it works, it works"). Typical R users (i.e. data analysts) regard languages a bit like programmers regard package managers.

'Autonomy, mastery and purpose' is from Dan Pink [0].

I think both lists, and most if not all of the comments here, are missing a notion of status or prestige.

[0]: https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_Ab...

The namespacing drives me nuts but it doesn't get mentioned very often in these kind of threads. How are people just ok with loading everything in the same namespace? You can use ::, but then that can have a ton of overhead.