Bit late to reply to this, but my point was that it's strange to complain that specific types of food is unavailable, when the people that would make that food aren't here.
I can still appreciate that someone coming from the US might not find the food as good and affordable as back home.
Also, there are barely any Chinese people here or Mexican people, why do you expect there to be mexican food?
Look for Vietnamese, Syrian, Turkish etc. and you'll find plenty of good stuff.
Right ok, I see if you're looking for something non-European you'll likely not find anything as good as the good stuff in the US.
But that seems like you're looking for the wrong thing.
I understand the point in the article now though, it just seemed far more general than what you're saying here.
I really don't agree with this
> Eating out is a big part of your life; there are restaurants, but they're expensive and for the most part unimpressive. If someone who worked at Noma owns it, then it's probably great, but otherwise often meh.
You must have extremely high standards or have different expecations.
I guess it depends where you moved from, but if you live in Copenhagen there are a lot of great restaurants.
Well I guess there is kommuneskat, which differs between kommuner. So you can pay anything between 37 to 39 depending on where you live.
But the 15% base tax doesn't make sense to me either.
While I agree with your point, the map example is not entirely well represented in your comment.
The idea is not to just store keys and values in separate arrays, the idea is to look at your use case and model your data after the transformation you need.
So if you have a case where storing keys and values as pairs because of your access pattern, then do that, if you have a case where you do a lot of searches through keys, then store them in separate arrays.
The point of DoD is to look at the data you have and the data you need it transformed into and then structure your data after.
Part of the point of Casey's videos (Previous one https://news.ycombinator.com/item?id=34966137) is that it _doesn't_ take more time because very often the simple thing is the fast thing.
So if most people unlearned the _more complex_ way of programming, they might end up with simpler _and_ faster code.
It seems like you may be assuming that Casey is arguing against writing clear code, which he is not.
He is arguing that you should just write the simple thing and usually that is also the most clear, readable and "maintainable" code because it is easy to get an overview of.
So what he is arguing for does not fit your coffee shop example, because of course no one should write unreadable code.
The argument is that sometimes taking a step back from how you were taught to write clean code, could be simplified in a way that is _also_ performant by default.
That's a good point.
My daughter is in daycare so I could take her home anytime I want if I'm home.
If I (and my partner) had the opportunity to work less during weekdays and more in the weekends I'm still not sure we would do it.
There is something mental about it for me at least.
Besides she's a nurse, so she works every third weekend anyway. In that case weekends become really important for me.
Are you suggesting that 100 LOC is a lot to maintain?
If the implementation was something like several thousands it would be a different story, but 100 LOC is a few functions as seen in the article.
I think there is a lot of merit to not using libraries. It might be a bit too strong to have a principle to never use libraries, but there are many libraries that provide way more than most projects need.
Also, who cares about future proofing for some unknow future. Write what solved the problem and then if another problem arises in the future - solve it then.
I assume a lot of people roll their own containers and use STL algorithms, which makes a lot of sense if you need control over allocations but still want to utilise the STL.
I can still appreciate that someone coming from the US might not find the food as good and affordable as back home.