drainyard

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.

People just make their own food 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.

Please tell me where you find houses for under $37.000 in Denmark right now? Even outside of Aalborg you will pay at least $70.000-100.000.

But yeah if you're a tech worker and can live with living outside of a bigger city, you will do fine.

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.

Uber is not really a taxi company. They do a whole lot of general transport infrastructure not for laymen.

But 36k still seems absurd.

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.

You could spend 2 minutes looking up who you are talking about.

This video from 2015 where Casey is interviewing Mike Acton: https://www.youtube.com/watch?v=qWJpI2adCcs

Also this course where he specifically talks about Numpy and pure Python: https://www.computerenhance.com/p/python-revisited

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.

WHO recommends _up to_ 2 years. After 6 months in addition to other nutrition.

If it seems like he is implying he came up with arena allocators himself, that is definitely not intended. I didn't read it like that though.

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.

If you have children weekends are incredibly important.

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.

Something like Terminal Click? https://media.handmade-seattle.com/terminal-click/

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.

A lot of game companies don't use STL. I assume theremust be plenty of system software companies doing the same.

Unless you add a repr(C) attribute for C interop.

> (2)

Have you heard of https://dion.systems/ that was linked here recently? They are working towards going away from text as the source format.

It remains to be seen whether or not it is a good idea and/or if it will succeed if it is.

> (1)

I guess in something like Dion, you have a source format that doesn't allow syntax errors, since you are not editing something that can be in an invalid state (necessarily).

They do that to make it easier to find the bricks, make it more interesting to look at while building and because they likely produce more bricks in those basic colors (last one may be outdated).

I found this to be true for a long time, but these days you have something like Fork which is much lore user friendly and FAST! We used to use Sourcetree, which is an abomination in comparison.

I always use(d) the terminal, but Fork is the first time I am considering using a GUI as my main tool.

Granted I haven't had to do anything complicated yet with it, so I don't know if it supports it, but I love it for the basic day-to-day tasks that I do 100's of times a week.

I cannot stress enough how infuriating it is when a page loads content under my mouse cursor at such a delay that I can manage to point at a link and click on it _before_ the new content is loaded so that I click/tap an unexpected link.

This happens _all_ the time on the Twitter app search bar.

A lot of modern programmers don't practice non pessimization. Back of the envelope: what is feasibly the best this should perform? So you end up with things that take up way more resources tham necessary because anyone has at least 8GB of RAM these days.

Back when there were more extreme hardware constraints you couldn't ship if your program was going to take up all your RAM in a few minutes.

I'm guessing this and that it has a lot more features (bot necessarily necessary features) these days so automatically a lot more engineers which means a lot more inexperienced engineers because there are only so many experienced ones.

A lot of the time I see these build systems try to solve a few issues:

1. Dependency handling

2. Single script for multiple platforms

3. Easy for a new user to just "run"

But I have yet to find a build system (for C/C++) that solves all these issues better than simply having a few scripts.

I use just a build.batch, linux_build.sh and osx_build.sh usually and I have never had problems.

A new user can just download those scripts, and as long as they haven't tampered with file/library locations it just works.

If people like their build systems - fine by me - but I just think they are unnecessarily complex a lot of the time. Granted I don't have a huge project with 100's of dependencies, but even then, those dependencies don't come all at once.

> So just keep it simple and trust the compiler. This also applies to algorithms, complicated ones with lots of branching will often perform far far worse in practice than the naive one, you can’t trust the big-O alone. So profile when in doubt.

I've found that optimizing for cache is usually the biggest gain when trying to be clever with algorithms. Eliminating branches and being naive in the algorithm itself is usually a better idea than trying to be clever with special cases.

In my experience.

It should be opt-in though. A compiler-flag for debug builds or similar.

I used to agree with this, but having spent a while in a very good C++ project (by C++ standards), even if we try to always forward declare and not include any unnecessary headers in headers, we still have a clean debug build time of 30-40 minutes. Even changing a single line in a cpp file, will still take around 30-40 seconds at best with incremental builds. I think long compile times are in the eye of the beholder, but often it feels like people have just gotten used to unnecessarily long compile times because they've forgotten how fast computers are and how fast a compiler should be for most of the work except for maybe some of the more complex optimizations in -O3. It kills productivity, and should really be a much larger focus than it sometimes seems to be.

I guess that makes sense, because those people are the ones noticing the most negative effects due to overuse/oversharing.