seppel

> Just putting "order-550e8400-e29b-11d4-a716-446655440000" does not make it an order id either, thats what foreign keys are for, mistakes can be made either way.

I'm not talking about the DB level here, I'm talking about what goes over the wire or ends up in logs files. And if you are handing out the uuids to your consumers, you can be reasonable sure that you only get back the uuids you handed out. So if "order-550e8400-e29b-11d4-a716-446655440000" is not an order, it an error on your side and not on your clients side.

> If your sending id via json you should be using json to encode type either:

Yes and you should also not make any mistakes.

> This is why you have column headers?

I'm not sure I can follow. You get an uuid from somewhere, probably external code that you cannot even look at. The uuid comes stringly-typed, let's say as json. Then you have no chance to know what type it is, you can only assume it is the correct type that you expect.

Just putting "550e8400-e29b-11d4-a716-446655440000" into a person colum does not make it a person id.

If you get instead "order-550e8400-e29b-11d4-a716-446655440000" as a typed-uuid, you know for sure that this is not a person id. It is an order id. Somebody made a mistake somewhere. You also know that you probably have to look in the order DB to debug what it actually refers to.

> but to use it throughout your db eats up tons of space from both text encoding the id

You dont need to put your uuid in this format into the db. You can add/remove the type before/after accessing the db.

> What kind of stupid logger logs a uuid without a clue as to what kind of object it identifies?

The code cannot know what kind of object an uuid identifies, it can only assume that it identifies what it expects. So it you might see:

"Unknown person 550e8400-e29b-11d4-a716-446655440000" in the log files. Much more helpful for debugging, however, is: "Unknown person order-550e8400-e29b-11d4-a716-446655440000". Then you know somebody accidentally put an order id where a person id belongs.

This is an easy example, in the real world you have persons, groups, representatives, accounts, acls, etc, which are easily confused. If you just have an uuid, you will have a hard time figured out what it actually is.

* You stumble upon them in log files or error messages.

* Somebody asks you why some API call is not working.

* You send around Excel files to higher management (for example in incidents).

I'd assume that there is a class of users who never ever use any keyboard short deliberately (because they are not aware or dont care about their existence). Any keyboard shortcut they trigger is pretty much by accident. I have not data how common that is, but I know such users.

Why do you have 9 factors? The classical Drake equation has 6 (and the L which is the avg. lifetime of the civilization).

Also: The Drake equation has one factor which is the avg number of planets per star, of which we are already quite confident it is above 0.1.

> However, the result is extremely different if, rather than using point estimates, we take account of our uncertainty in the parameters by treating each parameter as if it were uniformly drawn from the interval [0, 0.2]. Monte Carlo simulation shows that this actually produces an empty galaxy 21.45 % of the time.

Isn't that just elaborated way of saying that some of the parameters of the Drake equation have to be much smaller than we think?

> You mean in Munich, right? Anywhere outside of Munich €100k is a really high salary for a software engineer

These salaries are also possible in Berlin, Frankfurt, Stuttgart, Hamburg, Mannheim, Heidelberg (and more, this is where I know)

> In any case, the point is that with €100k/year you can really have way more than a decent life. More like a very, very comfortable life.

Well so what? They shouldnt pay more because it is already a decent salary and give the rest to the share holders?

It's no wonder that avarage salaries are low if people approach salary negotiations with this kind of attitude.

You can easily get into that range as a principal software engineer in Germany. E.g, finance and car industry will pay that, depending on the niche even in a startup if you negotiate properly.

100k will also not put you in the 1% of the earners if you consider the cities where the high paying jobs are.

> What's a real quicksort anyway?

A key aspect of quicksort is that it sorts the list in-place. If you dont sort in-place, you dont have quicksort and if you dont need in-place sort, then quicksort is the wrong choice anyway.

Of course, canonical Haskell does not have a concept of in-place, which makes showing quicksort in Haskell also a questionable idea.

> You could argue that a reasonably fast implementation of quicksort is much more convoluted, which it most certainly is, but that doesn't make this implementation any less real.

A reasonably fast implementation of quicksort is straight-forward in any language that has arrays/vectors with destructive updates. This implementation will have issues with pathological cases, but that's a problem of the quicksort algorithm, not of the implementation (whereas the Haskell one shown above has problems in the implementation).

> The Haskell quicksort is the classic example of this:

The Haskell quicksort is also classic example of something that is small, beautiful and still misses the point. Yes, it contains the core idea of quicksort (partion the list and divide and conquer) but it completely fails on the quick part, because the Haskell lists are are leaky abstraction of real computer memory.

A real quicksort in Haskell is much more convoluted.

> This has never been the case, except for string fields where std::string forces us to allocate.

I'm was quite surprised you didnt offer your own stringview implementation (or something similar) the last time I looked at protobuf. I'd naively assume that inside Google this could be quite a low-efford high-reward optimization.

> chances are at least a few zillion base their unit of time on periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom

Of exactly 9192631770 Hz...

Unless you mean something specific, at least Mercedes, BMW, Audi and Volvo offer very good ACC with lane assist in their SUVs.

Ah, this makes sense (not necessarily that this is public information, but why the scanning works)

Why does BMW even store the license plate? Is the warranty tied to a license plate? And if so, why?

> It seems like market orders are, and always have been, for chumps.

Note that for a limit order to be executed, you need someone else doing a market order (or a limit order with price below market).

You can use sqlite with zstd compression (which can be extremely efficient with a shared compression dictionary).

But why would it go down in USD in the demand increases?

Let's assume tether is a scam (not backed by enough USD) and at some point would start to loses it peg to the USD. Wouldnt that increase the demand of BTC? Everyone holding tether would start buying BTC (or other coins) because this is the only thing you can do with tether.

> The paper's only in review

You submit a final version for review. You cannot change a paper significantly after it was accepted.

> Alcohol is quite chemically reactive:

All food is quite chemically reactive; that is one of the main points of eating.

> Bryan Caplan in his book The Case Against Education suggests that employers value college degrees partly as a signal of conformism, and that that's the reason college is so hard to replace.

That is such an interesting book that I'm surprised there is any HN discussion about it.

So there is no tether printing scam in the first place? (If there was a scam, I'd love to understand how it works)

Sorry, I'm slow and I really don't understand this.

> Retail people seeking to get into bitcoin in the middle of this bubble are getting scammed because tether is being used to artificially inflate its value.

But how? Let's say I have one BTC. You offer me 15k USD to buy it, I say no. You say, ok, what about 18k USDT (that you just printed)? I reconsider and say, yeah, ok. So you inflated the price ok, but then what?

I now have 18k USDT, but I can't spend them on blackjack and hookers. In fact, I can buy nothing with the 18k USDT except crypto!

So I have two options:

* I keep the 18k USDT. But why should I do that?

* I buy back my BTC. But then somebody else has the problem of spending the 18k USDT! Where do they eventually end up? I dont get that part.

> People who believe (in varying degrees) that 1 USDT == 1 USD.

I totally get that part. But then what? With USD I can buy, e.g, a house or a yacht. With USDT I can buy what? I guess only other crypto currencies. So what is the endgame here?

> The people that printed tether now sell their btc for a profit and can now cover their tether obligations to keep the illusion going that tether is 1:1 backed with usd. They can now repeat the tether printing cycle.

And who is getting scamed here? Who is sitting on the tether at the end of the day?

I see. And these traders are responsible for the increased demand of tether?

> A number of exchanges like bitfinex are in on the scam and are just holding the tether in cold storage

But how can that be a scam if they hold the tether? It can only be a scam if someone else now has the tether and they have the real money. I'm trying to understand who is getting scammed here.

Moreover, why are they printing tether if they already have too much?

Yes but then someone else has the tether.