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

321–330 of 347 posts

Re: Be Aware of the Makefile Effect

#321

Post by stefr- »

jappgar wrote: post #302

I dunno they're using copy-paste as if it's a bad thing. There's no virtue in writing something character by character. If anything these languages and systems are better for the Makefile effect. That you can't really do effective copy-pasting in imperative languages is a weakness.

The author mentions that copy-pasting code by itself is not a bad thing. The problem with the phenomena they describe is that people copy-paste files around because they _don't understand it_, and end up with stuff that works, but is inefficient and hard to debug.

Re: Be Aware of the Makefile Effect

#322

Post by BlueTemplar »

jmb99 wrote: post #298
BlueTemplar wrote: post #113

Earlier quoted context omitted.

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.

We're not talking about efficiency, we are talking about engineering developing before science.

Re: Be Aware of the Makefile Effect

#323

Post by afiori »

mianos wrote: post #29

I have an alternate theory: about 10% of developers can actually start something from scratch because they truly understand how things work (not that they always do it, but they could if needed). Another 40% can get the daily job done by copying and pasting code from local sources, Stack Overflow, GitHub, or an LLM—while kinda knowing what’s going on. That leaves 50% who don’t really know much beyond a few LeetCode p…

Being able to set up things and truly understanding how they work are quite different imo.

I agree with the idea that a lot of productive app developers would not be able to set up a new project ex novo but often it is not about particularly true understanding but rather knowing the correct set of magic rules and incantations to make many tools work well together

Re: Be Aware of the Makefile Effect

#324

Post by dfawcus »

johnnyanmac wrote: post #271
oblio wrote: post #247

Earlier quoted context omitted.

Probably slower and with more respect for existing tech. But hey, now we have npm, so who cares anymore? :-)

Most languages are much older than we think. But early adoption is a key to geting to that point of when to "trust it". D isn't that much younger than C and its variants, and older than C#. But it never quite got that adoption to really push development to the point of C#

  C (K&R) : 1972 => 53 years ago
  C++     : 1985 => 40 years ago
  D       : 2001 => 23 years ago
Also, https://www.bell-labs.com/usr/dmr/www/chist.html

So D is 30 years younger than C, so I'd disagree with "isn't that much younger".

D was really a reaction to C++, not C, so it is with C++ that it should be compared. The C like subset of D (BetterC) is much more recent.

Re: Be Aware of the Makefile Effect

#325

Post by mkrajnak »

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…

I agree. An additional perspective that I have found useful came from a presentation I saw by one of the pragmatic programmers.

They suggested thinking about investing in skills like financial investments. That is, investments run on a spectrum from low risk, low return to high risk, high return.

Low risk investments will almost always pay out, but the return is usually modest. Their example: C#

High risk investments often fail to return anything, but sometimes will yield large returns. Their example: Leaning a foreign language.

Some key ideas I took away:

- Diversify.

- Focus on low risk to stay gainfully employed.

- Put some effort into high risk, but keep expectations safe.

- Your mix may vary based on your appetite for risk.

Re: Be Aware of the Makefile Effect

#326

Post by ruuda »

rednafi wrote: post #152

This also happens with tools you have to use but don’t get much payoff from—like internal tooling. At work, we have a shitty in-house feature flag service. It breaks all the time and is super finicky. Learning it properly doesn’t really help me, so I mostly copy and paste my way through it. Another example is jq. I use it occasionally, and ChatGPT handles the syntax pretty well. For me, learning it properly just isn’…

Try https://rcl-lang.org/ instead then, it has syntax that you can write without needing ChatGPT.

Re: Be Aware of the Makefile Effect

#327

Post by registeredcorn »

Scubabear68 wrote: post #127

The best term for this is Cargo Cult Development. Cargo Cults arose in the Pacific during World War II, where native islanders would see miraculous planes bringing food, alcohol and goods to the islands and then vanishing into the blue. The islanders copied what they saw the soldiers doing, praying that their bamboo planes and coconut gadgets would impress the gods and restart the flow of cargo to the area. The issue…

I think I fall very much into the "beginner of beginner stages" of understanding programming. It sounds like then, if I want to avoid that "cargo cult" mindset, then a structured flow of:

education -> learning -> doing -> failing -> (repeat)

Would be needed then, right?

Does this then mean that, if someone truly wants to "escape the island, and fly the plane" as it were, it comes down to "university is the 'truest' way"?

Note: Yes, I realize it's hard to speak in absolutes, that there are plenty of exceptions to generalities, and that all people have various degrees of justifications of I-can't-do-that-itus; I'm talking more in terms of optimal theory. That, the optimal route to avoid cult-like behavior is to understand the whole thing, and that "the whole thing" comes from higher education, right?

Logically at least, it would seem that even diligent studying with books as a means to meet/surpass the "completeness" of university would still be... inadequate in some regard when compared to in-class time with learned educators. (Again, supposing that the same person worked just as hard doing either option, etc.)

Re: Be Aware of the Makefile Effect

#328

Post by znpy »

This is poor reasoning and poor argumentation.

This particular line is wrong in my opinion:

> the tool (or system) is too complicated (or annoying) to use from scratch

Unless you're doing trivial things, any tool or system will require some setup (which people call "ceremony").

Tools and systems can be easy to use from scratch only if they are either super-specialized or they impose significant constraints on what you will be doing with that tool and how you will be doing it.

Such tools are usually very tightly couple to a specific job/environment/task and are hard to keep around, keep updated and to evolve.

Make and similar tools instead are generic and can be adapted. The fact that you can reuse the previous work done is actually a feature. You can dive as deep as you want or need. They're very widely used so it's not an issue to keep updated. They're so widespread you can find people already familiar with those tools. Learning such tools is a great investment because you can keep using them over and over across project and companies.

Some of those tools are either timeless (gnu make) or have a very long life (more than a decade, which very long for this industry).

Anecdotal example: I learned a bit of apache ant while in high school because my laptop at the time (a netbook with 1GB ram and an atom processor) could not run NetBeans decently, so I had to learn a bit of apache ant and resort to writing and maintaining my own build.xml file. Fast forward 14 years and I see a build.xml file in the $FAANG codebase I was working on. That learning did pay off beautifully many years later.

The article is shortsighted, if anything it's promoting a shallow way of working. You are supposed to learn about the tools you use.

Re: Be Aware of the Makefile Effect

#329

Post by nrclark »

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.

`Just` is also popular in this space, but tbh I think Make is a better choice.

Make is included in most Linux distros, including the ones available for WSL. It's also included with Apple's developer tools. It's been used for decades by millions of people, and is very mature.

If you use it in a simple way, Make is almost identical to `Just`. And when/if you want Make's powerful features, they're there and ready for you. Make's documentation is also exceptional.

I've used a bunch of these kinds of tools over the years, and I've never found one that I like more than Make.

Re: Be Aware of the Makefile Effect

#330

Post by johnnyanmac »

dfawcus wrote: post #324
johnnyanmac wrote: post #271

Earlier quoted context omitted.

Most languages are much older than we think. But early adoption is a key to geting to that point of when to "trust it". D isn't that much younger than C and its variants, and older than C#. But it never quite got that adoption to really push development to the point of C#

C (K&R) : 1972 => 53 years ago C++ : 1985 => 40 years ago D : 2001 => 23 years ago Also, https://www.bell-labs.com/usr/dmr/www/chist.html So D is 30 years younger than C, so I'd disagree with "isn't that much younger". D was really a reaction to C++, not C, so it is with C++ that it should be compared. The C like subset of D (BetterC) is much more recent.

I was thinking more about Ansi C. But fair enough. I hope the core point that these are all still Languages old enough to drink rings through.
Post reply on HN