It is, but it isn’t because of free market economy.

$6 a gallon is about €1.36 a litre - thats cheap compared to a European average of €2 per litre.

Still that makes very clear why Venezuela had to happen before Iran.

Those Euro prices are including 40%, 50%, 60% taxes in total. The US price is nowhere near those percentages. https://en.wikipedia.org/wiki/Fuel_taxes_in_the_United_State...

> $6 a gallon is about €1.36 a litre - thats cheap compared to a European average of €2 per litre.

As someone who drives a 2003 Golf TDI, I'm currently looking at CAD 2.40/L: EUR1.49/USD1.73 per L.

It’s the simulation effect - From the perspective of a interstellar travler you too are not meaning different from any other two legged quasi intelligent naked ape. :)

Dwarf fortress or rim world solves that by generating personalities.

Wow! Thanks a lot!

he’ll Yea, make it mail based with full backward comp ability to arpa!

nice :-) i'll try that! thx

Interesting read, thank you. I share your goal, and I think with AI- coding proving code right has become more relevant than ever.

What prevents that we, just move the goal post? Moving the bug from code to spec? The spec must always be simpler and more easily to understand and debug than the code. But in praxis that means it can’t be fully specific in most of the use cases?

I don’t understand - Why did they write this? It seems to add nothing to the domain?

I read the free part. Looks interesting, but the math heritage is dominant as promised.

It seems to favor the compact and efficient kind of code that is brittle in the hand of a mildly competent junior dev, or a heavy multitasking senior.

I like smart code, in fun projects, but on the job I prefer fast to read and to reason code. Don’t try to be fancy.

So I guess that’s a book to challenge my assumptions. I like that. Thx.

I know that as Kernighan's Law. Seems to be something that seniors learn over time.

https://github.com/dwmkerr/hacker-laws#kernighans-law

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

I took some time to think about why this saying bugs me, and I think I've settled on "it suggests you can't understand your limits".

I know it's explaining the joke, but you've blown past "clever" if you've reached the point where you can't debug it.

When you get into team development, doesn't it become the average? So, it's not just about your limits, it's about the team's average.

Otherwise, you're the only one who can fix your code, and becomes a whole bus factor thing.

The limits of the team, even insisting on >1 person being able to fix any code written by the team, are probably much higher than the average of the team. Furthermore, the average isn't going to improve much if code is never written above it. This isn't to say go all out with the most clever code possible, or make things difficult for the sake of difficulty, but consider that it's possible to help upskill your team by showing them better ways (even if sometimes technically "cleverer ways") to write code. It's ok if something isn't as familiar to everyone initially -- exposure helps that. Do better code reviews, code walkthroughs, lunch & learns, book clubs, consultants to come in and teach something, there's lots of ways to improve as a team.

If debugging is the art of removing bugs from programs, then programming must be the art of inserting them.

I once talk about the art of programming in a job interview and got flashed by a bachelor of biz with: but isn’t it suppose to be engineering? I died a little bit inside…

I've been a programmer for 40 years, I've never considered myself to be an engineer.

We don't have the same level of "proven solutions" and constraints and mathematical rigor that engineering has, nor do we have the legal/liability requirements of "Professional Engineers".

I hope that I qualify as the equivalent of an artisan, like a carpenter that makes furniture, that has elements of both art and craft. Even as I've moved up (and down) the hierarchy of programmer/senior/"architect"/manager.

Programmers fit the "craftsperson/journeyperson/apprentice" model much better than engineering practice.