Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be Aware of the Makefile Effect

blog.yossarian.net

Post reply on HN
Print view View original

291–300 of 347 posts

Re: Be Aware of the Makefile Effect

#291

Post by aragilar »

remus wrote: post #166
kragen wrote: post #99

Earlier quoted context omitted.

If you spend 80% of your time (and mental energy) applying the knowledge you already have and 20% learning new things, you will very quickly be able to win more battles per day than someone who spends 1% of their time learning new things. Specifically for the examples at hand: - at 20%, you will be able to write a Makefile from scratch within the first day of picking up the manual, rather than two or three weeks if y…

You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time. Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10…

There's always the option of asking coworkers/friends/mentors/etc. what they found useful.

Re: Be Aware of the Makefile Effect

#292

Post by kragen »

PaulHoule wrote: post #289
kragen wrote: post #284

Earlier quoted context omitted.

There is some truth in what you say. Though steam engines still power most of the power grid (especially in the "developed world") their capital costs are indeed too high to be economically competitive. However, there are also some errors. In 02022 24% of total US electrical power generation capacity was combined-cycle gas turbines (CCGT), https://www.eia.gov/todayinenergy/detail.php?id=54539 which run the exhaust fr…

Yeah, and people are talking about renewables as if the storage is free. Or people quote case 17 out of https://www.eia.gov/analysis/studies/powerplants/capitalcost... as if 1.5 hours of storage was going to cut it. I've been looking for a detailed analysis of what the generation + storage + transmission costs of a reliable renewable grid is that's less than 20 years old covering a whole year and I haven't seen one y…

I haven't seen one either.

To be honest, I don't think anyone has any idea yet (other than crude upper bounds) because it depends a lot on things like how much demand response can help. Demand response doesn't have to mean "rolling blackouts"; it could mean "running the freezer during the day when electricity is free". Will people heat their houses in the winter with sand batteries? Will desiccant air conditioning pan out? Can nickel–iron batteries compete economically with BYD's gigafactories? What about sodium-ion? Nobody has any idea.

I was pleased to calculate recently that the EV transition, if it looks something like replacing each ICE vehicle with the BYD equivalent of a Tesla Model Y, would add several hours of distributed grid-scale storage, if car owners choose to sell it back to the grid. But that's still a far cry from what you need for a calm, cloudy week. Maybe HVDC will be the key, because it's never cloudy across all of China.

Sensible-heat seasonal thermal stores for domestic climate control (in some sense the most critical application) have been demonstrated to be economically feasible at the neighborhood scale. PCM or TCES could be an order of magnitude lower mass, but would the cost be low enough?

Re: Be Aware of the Makefile Effect

#293

Post by kragen »

aragilar wrote: post #291
remus wrote: post #166

Earlier quoted context omitted.

You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time. Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10…

There's always the option of asking coworkers/friends/mentors/etc. what they found useful.

I'm embarrassed I didn't mention this. Yes, collective mental effort can be orders of magnitude better than individual.

Re: Be Aware of the Makefile Effect

#294

Post by skydhash »

kragen wrote: post #171
remus wrote: post #166

Earlier quoted context omitted.

You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time. Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10…

I agree. And there's no infallible algorithm. I think there are some good heuristics, though: - invest more of your time in learning more about the things you are currently finding useful than in things that sound like they could potentially be useful - invest more of your time in learning skills that have been useful for a long time (C, Make) than in skills of more recent vintage (MobX, Kubernetes), because of the L…

> spend some time every day thinking about what you've been doing. Pull up a level and put it in perspective

That's the most useful point. Sometimes just a few why-s can give you a clearer view on your activities and a direction for your efforts.

Re: Be Aware of the Makefile Effect

#295

Post by compumetrika »

myhf wrote: post #204

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." – John Gall (1975) Systemantics: How Systems Really Work and How They Fail https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

Great quote, commenting just to 'bookmark' it.

Re: Be Aware of the Makefile Effect

#296

Post by tantalor »

compumetrika wrote: post #295
myhf wrote: post #204

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." – John Gall (1975) Systemantics: How Systems Really Work and How They Fail https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

Great quote, commenting just to 'bookmark' it.

You can "favorite" comments

Re: Be Aware of the Makefile Effect

#297

Post by moregrist »

kragen wrote: post #171
remus wrote: post #166

Earlier quoted context omitted.

You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time. Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10…

I agree. And there's no infallible algorithm. I think there are some good heuristics, though: - invest more of your time in learning more about the things you are currently finding useful than in things that sound like they could potentially be useful - invest more of your time in learning skills that have been useful for a long time (C, Make) than in skills of more recent vintage (MobX, Kubernetes), because of the L…

> invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff.

The think you have a solid point with Postgres v Oracle and I haven’t followed game dev in a while, but your FreeCAD recommendation is so far from industry standard that I don’t think it’s good advice.

If you need to touch CAD design in a professional setting, learn SolidWorks or OnShape. They’re what every MechE I’ve ever worked with knows and uses, and they integrate product lifecycle aspects that FreeCAD does not.

Re: Be Aware of the Makefile Effect

#298

Post by jmb99 »

BlueTemplar wrote: post #113
silver_silver wrote: post #109

Earlier quoted context omitted.

Yes and they’re far less efficient and require far more maintenance than an equivalent electric or even diesel engine, where equivalent power is even possible

Why do you assume that the same doesn't apply to electric and diesel engines ?

We don’t have to assume, because we know. We can calculate and measure the efficiency of gasoline and diesel engines, and electric motors. We know that electric motors are highly efficient, and ICE engines are not.

Re: Be Aware of the Makefile Effect

#299

Post by ori_b »

mianos wrote: post #110
adrian_b wrote: post #79

Earlier quoted context omitted.

Actually it is trivial to write a very simple Makefile for a 10,000 file project, despite the fact that almost all Makefiles that I have ever seen in open-source projects are ridiculously complicated, far more complicated than a good Makefile would be. In my opinion, it is a mistake almost always when you see in a Makefile an individual rule for making a single file. Normally, there should be only generic building ru…

If everything in your tree is similar, yes. I agree that's going to be a very small Makefile. While this is true, for much larger projects, that have lived for a long time, you will have many parts, all with slight differences. For example, over time the language flavour of the day comes and goes. Structure changes in new code. Often different subtrees are there for different platforms or environments. The Linux kern…

Engineering is deciding that everything in your source tree will be designed to be similar, so you can have a small makefile.

Re: Be Aware of the Makefile Effect

#300

Post by ori_b »

dwaltrip wrote: post #230
nrclark wrote: post #177

Earlier quoted context omitted.

(not the parent) Make is - at its core - a tool for expressing and running short shell-scripts ("recipes", in Make parlance) with optional dependency relationships between each other. Why would I want to spread out my build logic across a bunch of shell scripts that I have to stitch together, when Make is a nicely integrated solution to this exact problem?

Any modern attempts to do this better than make? I often write small “infra” bash scripts in my projects, maybe I could use a tool like that.

That depends. Why do think make does this poorly?
Post reply on HN