kpmah

Very nice! I've recently tried covering some similar ground for a side project (https://forkjam.com/new) so I have an idea of how much work this is.

I take it you took the approach of using WASM for audio decoders?

Except now we have a scientific consensus that the Earth's carrying capacity will decrease. I don't think that's been true before.

Expecting technological advancement to bail us out every time is wishful thinking.

> Normalization was built for a world with very different assumptions. In the data centers of the 1980s, storage was at a premium and compute was relatively cheap. But the times have changed. Storage is cheap as can be, while compute is at a premium.

Normalisation isn't primarily about about saving storage, it's about avoiding update anomalies i.e. correctness.

I don't believe for a second that your question is 'honest', because I think you're smart enough to be able to type it in to Google and find the answer if you were actually interested in it.

Read the IPCC report if you actually want to know (Spoiler: yes and yes).

Yeah, I think I'm confusing storing things as UTC with storing things as UTC+0 - I forgot it stores the offset.

Am I right in thinking that if you always store in UTC, when the clocks go back you will get overlapping data?

e.g. if you store your logs with a UTC date you'll see interleaving logs for the extra hour, or if you read sensor data or something like that you'll get double readings?

The difference is interpreted vs compiled, not dynamic vs typed. You can use a C interpreter to instantly run C code without compilation.

Looks correct to me. What issue do you have with it?

They're saying injection attacks come from dynamically building strings, so if you prevent that you stop the vulnerabilities.

This is a really good way of explaining monads. Generally, when people ask about monads, they're not really asking 'what' monads are - they're asking 'why' and 'how' you use them.

The advantage shown here is that Haskell has special syntax for monads, and this single abstraction can be used for multiple features that many other languages have specialised syntax for.

Types can turn all runtime exceptions in to compile time errors. See: https://www.infoq.com/news/2017/05/elm-zero-runtime-exceptio...

I assume you're not claiming that experienced developers never have runtime exceptions, or that they're always easy to solve.

I'm learning dutch, and this was a fun way to learn some words!

It always bothers me that developers who are working with a team they can't trust to build a disciplined, modular application advocate moving to a more technically challenging architecture as a solution.

Forgive me for getting political, but I think Trump was a good non-tech example of 'good because it's new'. Without a voting record and few concrete policies people were free to project their hopes on to him.

I have also noticed the 'dangerous/frightening because it's new' bias. I don't understand why it flips one way or the other. People are weird! :)

I'm not arguing against using your gut feeling, it is more that if those coders examined why they do things they way they do they could probably come up with some good reasons.

And then if you want to convince other people to do it your way it is better to say "do this because X, Y, Z" than "do this because I think it's better."

Not sure how much this will help, but a couple of years ago I wrote about using event sourcing for a simple blog application in PostgreSQL: http://kevinmahoney.co.uk/articles/immutable-data/

I wasn't aware of the term 'event sourcing' at the time though.

Haskellers tend to be fond of their type system.

I think most are pragmatic and admit you may have to do denormalise for performance (e.g. I've read this in C.J. Date's books). I interpret their point as the need for denormalisation is not a flaw with the relational model, but a flaw in its implementation. The relational model does not specify an on-disk format.

It depends on the use case you want it for. Unless you're at massive scale, I don't think non-ACID databases are ever really appropriate as a general purpose store.

There are niches though. Graph databases, search indexes, databases for logging, time series databases, mapreduce, etc.

I would say code for the scale you'll have in the near future, not for the scale you want to have in 5 years.

Transitioning database is painful, but dealing with the extra complexity of non-ACID stores can inhibit your growth. If you reach the scale where you need to change, you'll probably be able to afford more developers to help you.

In my opinion, the major reason to leave behind ACID databases is if you have reached the point where they can't scale up any more. If you have reached this point, you're probably a company with 20+ developers. There might also be very specific use cases where specialised databases are useful, such as a search index.

ACID gives you a lot of nice guarantees and it's silly to give it up if you have the choice.

As for MongoDB in particular, I would never use it for anything. It doesn't seem to do anything particularly well. There are better specialist 'NoSQL' databases that have actual benefits to fit your problem.

Well, we're playing make believe with the requirements. In fairyland the user and the profile need to exist together. Only the fairies know why!

If you can relax the requirements, you can relax the constraints.

Do you (or anyone) know of a better example than the bank account? I wouldn't be against changing it.

I wanted to communicate through a fairly succinct and understandable example that there are potentially high stakes, and I wanted to show a 'NoSQL' example rather than a micro-services one. It was the first one that came to mind.

Banks are forced to be eventually consistent because of their distributed nature. If it was practical to have a big central ACID database I'm sure that's what they'd use. There is an extra layer of complexity with distributed systems.

That said, if the problem has been thought about, I'm happy. My frustration is with people not understanding the trade-offs.

Yes, be aware of the transactional capabilities of your database. Some ACID databases in their default configuration don't provide all transactional guarantees!

I'm not actually that familiar with event sourcing. I'd be interested in reading more if you have a pointer to some resources!

Edit: I wasn't familiar with the terminology, but it sounds like what I have written about here: http://kevinmahoney.co.uk/articles/immutable-data/

I think it's a good example because this should not be the way to develop this kind of system - and yet people do it this way! :)

Oh, in addition to my other reply I should point out that the 'C' in CAP is not the same thing as the 'C' in ACID. Be careful with that one, it can cause confusion! http://blog.thislongrun.com/2015/03/the-confusing-cap-and-ac...

Well, they're eventually consistent. It's not like it hasn't been thought through. :)

It's a useful example because it shows how there can be serious consequences for getting it wrong.

So is your comment metametametaprogramming?

I wrote a little article, which has been posted here before, that shows the power of different type systems and what kind of bugs you can expect to prevent: http://kevinmahoney.co.uk/articles/tests-vs-types/