• 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle


  • Or your example, how would we have processed ore into metal without coal (on any significant scale).

    We have been processing ore into metal with coal for thousands of years. It sounds like you are arguing that the industrial revolution has been happening for thousands of years. Which it has not.

    We also made bread in the industrial revolution which is needed to feed the workers. Without feeding the workforce we could not access certain advancements. Is bread a corner stone technology of the industrial revolution? No it is not. It in no way defines what the industrial revolution was. Just like coal or oil.

    You can run a steam engine off of coal, wood, oil, nuclear, basically anything that creates a lot of heat. Coal is more convenient in a lot of ways but it did not unlock anything special. If not for coal we could use wood or charcoal. That was the steam engine, not the fuel it runs on.

    And if the advancements were because of these fuels that why did it not happen 1000s of years ago when we had access to them?







  • The known unknowns and especially the unknown unknowns never get factored into an estimate. People only ever think about the happy path, if everything goes right. But that rarely every happens so estimates are always widely off.

    The book How Big Things Get Done describes a much better way to factor in everything without knowing all the unknowns though - Just look a previous similar projects and look how long they took, take the average and bounds then adjust up or down if you have good reason to do so. Your project will very likely take a similar amount of time if your samples are similar in nature to your current task. And the actual time already factors in all the issues and problems encountered and even if you don’t hit all the same issues your problems will likely take a similar amount of time. And the more previous examples you have the better these estimates get.

    But instead of that we just pluck numbers out of the air and wonder why we never hit them.


  • A water central heating system is a closed loop system that is under pressure. This means the water in it is circulated around and around the system and is cut off from other water supplies under normal operation. Naturally, slow leaks happen and gas can enter the system in various ways so occasionally this needs to be released from the system. Any gas in the system naturally collects at the highest points along the path - which tend to be the radiators.

    When you bleed a radiator you are opening the system to the outside and hopefully where the gas has accumulated. Since the system is under pressure it forces the gas out of the system to equalize the pressure with the outside. This will cause the pressure of the system to drop and eventually it will stop.

    However there should be a control valve somewhere, typically on/near the boiler that connects the central heating system up to the mains water supply. You can open this valve to cause water to flow into the central heating system and pressurize it and really this should be done every time you bleed the radiator a significant amount.

    In apartments though you might find that you are on a building wide circuit, or you might have one isolated for your apartment. If you have a boiler in your apartment then you are likely on a closed system and should be able to equalize the pressure yourself. If it is building wide you need to talk with your building manager.

    Note that you should not need to bleed your radiators that often. Once every several years should be more than enough. If you are doing it frequently then you likely have a large leak in your system and likely want to get someone to check that out.


  • I believe that either gender has a genetic disposition towards the feminine form.

    I am not sure you can conclude that. Environmental factors likely play a large role here as well as genetic factors. I feel we tend to idolize and sexualize the female form far more then the male form these days. But if you look back and different cultures that did the same with the male form I suspect you would see an opposite trend to both genders preferring the male form more often.


  • They can write good short bits of code. But they also often produce bad and even incorrect code. I find it more effort to read and debug its code then just writing it myself to begin with the vast majority of the time and find overall it just wastes more of my time overall.

    Maybe in a couple of years they might be good enough. But it looks like their growth is starting to flatten off so it is up for debate as to if they will get there in that time.





  • While being accurate about it is hard outside the lab it is very easy to tell where you are on the balance and how much out you are. Just count the calories you consume and weight yourself regularly. If you are gaining weight then you are eating too much, so lower the number of calories you are consuming, if you are losing weight then you are eating less than you are burning. If you weight remains stable then you are in balance. And the amount you are gaining/losing tells you how much of a surplus or deficit you are in.

    Over time you can then change the amount you eat by I few hundred calories at a time and you will see yourself move on that balance point. If anything else changes but your intake remains the same then it is likely your calories out that has changed. But even if technically you are digesting less for some reason it does not really matter - the bigger/easier leaver you have to pull is the number you are eating.

    Because you are measuring the final output - your weight - it is fairly accurate over time and helps you track actual progress. There is no need to get super accurate about how much your body adobes, shits out or you burn off at rest or through exercise - those might be important in the lab but in real life the far easier to measure weight and how much you are eating is more important.


  • You cannot accurately measure just that. But measuring calories you eat is a good enough approximation to help you control how much you eat. You can estimate you calories out by your weight, if you are gaining weight you are eating (and adsorbing) more then you are using, if you are losing weight then you are eating less - and that is the most important part.

    There is also water weight to account for, but realistically there is an upper and lower bound to that and over several weeks you can get a pretty good idea for what level of calories you ingest leads to weight gain or loss. And if that changes for any reason you can adjust the amount you eat in correspondence. We are just looking for averages over time and the overall balance here, no need to be super accurate with exactly what you adsorb and what you have accurately used during an exercise. I never even measure calories burnt as it does not give much value vs just weighting your self over time.


  • While strictly speaking calories in < calories out is the most important factor in weight loss, what you eat can drastically affect your hunger and thus indirectly affect your calories in - or at least make you far more miserable in sticking to lower calories. Eating more protein can help but I also find blander food helps as well - which typically means avoiding sugars and sweet foods. You are going to find it extremely hard to stick to a calorie limit eating nothing bot oreos and hostess snack cakes.


  • This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:

    Here is a new feature modern languages are starting to adopt.

    You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.

    The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?

    And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them…

    It makes no sense.


  • But no one actually pulls that rule through, do they?

    They do though. Loads of new people to programming read that book and create unreadable messes of a code base that follow all of his advice. I have lost count of the number of times I have inlined functions, removed layers of abstraction and generally duplicated code to get a actual understanding of what is going on only to realize there is a vastly simpler way to structure the code that I could not see until all the layers and indirection are removed. Then to refactor again to remove redundant code and apply more useful layers again that actually made sense.

    And that is the problem we have with his book. People that need it take up as many bad habits as they do good ones leading to an overall decline in their code quality. It is not until years of experience that you can understand the bad bits and ignore them. So overall his book is a net negative on the programming world. Not all his advice is bad, but if you can tell that then you likely don’t need his advice.

    But on the layers of abstractions specifically, he takes this too far. Largely because of the 4 line limit he has. There is a good level of abstraction and I generally find more than 2 or 3 levels of abstraction is where I start to loose any sense of what is going on. He always seems to jump on abstraction as soon as he can, but I find waiting a while and abstraction when you need to to lead to fewer and vastly better layers of abstraction overall.

    And adding more abstraction does not help the people of people doing too many things inside a function - they just move it to sub functions rather than extracting the behavior for the caller to deal with. I have never seen him give advice on what that is appropriate, only keeps the functionality of the original function the same and move the logic into a nested function instead and that only covers up the issue of the function doing too much.