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

Advice to my younger self: become allergic to the churn

lambdaisland.com

Post reply on HN
Print view View original

161–170 of 221 posts

Re: Advice to my younger self: become allergic to the churn

#161

Post by henryfjordan »

conception wrote: post #88
misterman0 wrote: post #76

>> The Churn is losing a day debugging because a transitive dependency changed a function signature. The Churn is spending a week just to get a project you wrote a year ago to even run. The Churn is rewriting your front-end because a shiny new thing came around. If you think the churn is that then you're lucky. To me, the churn is working for the man. Everything I ever do is for the man. If I could ever reach a point…

There are many many organizations and Institutes that aren't the man. You don't have to work for a soulless corporation. You can do work that helps the greater good of humanity.

Under the current version of American Corporatism, no, you cannot work for a company that isn't soulless. A Corporation is legally required to work only to increase the value of a share, nothing more.

Maybe you can work for a non-profit if you're lucky, but how many are there out there that pay market rate?

Re: Advice to my younger self: become allergic to the churn

#162

Post by yellowapple »

kabdib wrote: post #75
Crinus wrote: post #41

Earlier quoted context omitted.

You may hate Make and it is certainly far from ideal (tab-based syntax was a mistake) but the thing is, Make has very simple rules that haven't changed for decades and Makefiles generally keep working (and when they break it isn't the fault of Make itself but of something else that isn't as stable/backwards compatible as Make).

Common make fail #1 The project you landed on has been using some souped-up supermake with a ton of features (which were used with wild abandon) and some subtly different semantics for (say) macro expansion and variable assignment (and these are really difficult to determine the dependency scope of). The build system has grown to a recursively gnarly Turing-complete mess. So when you go to update the tooling, you fin…

Make is the worst build system... except for all the others.

Re: Advice to my younger self: become allergic to the churn

#163

Post by marcosdumay »

kabdib wrote: post #75
Crinus wrote: post #41

Earlier quoted context omitted.

You may hate Make and it is certainly far from ideal (tab-based syntax was a mistake) but the thing is, Make has very simple rules that haven't changed for decades and Makefiles generally keep working (and when they break it isn't the fault of Make itself but of something else that isn't as stable/backwards compatible as Make).

Common make fail #1 The project you landed on has been using some souped-up supermake with a ton of features (which were used with wild abandon) and some subtly different semantics for (say) macro expansion and variable assignment (and these are really difficult to determine the dependency scope of). The build system has grown to a recursively gnarly Turing-complete mess. So when you go to update the tooling, you fin…

Well, your make failure #1 is not using make?

Also, #3 is what make excels in. I'm still to see another tool that is more fit to that kind of thing.

At the end of the day, I don't like make. It's for reason #5: there's no project introspection, you can't group tasks into high level values, update your graph on the fly, or add anything to your target except at the source level. I see this one didn't make into your list. This is one of the reasons those multi-million makefiles exist.

I'd rather deal with a small shell script, or a larger Python one if it can't be small. Yet, autotools are great for system programming.

Re: Advice to my younger self: become allergic to the churn

#164

Post by fao_ »

IggleSniggle wrote: post #96
rxhernandez wrote: post #63

Earlier quoted context omitted.

I mean I haven't been a professional for multiple decades but I've written professionally in a very wide range of fields in C, Matlab, Java, Python, Verilog, Assembly, Fortran, and Javascript, and, there is no language that I've seen that has more hair pulling, braindead I just learned to program yesterday type programming nearly as much as I've seen in Javascript. (I've worked intimately with decades old scientific…

It's all about who is writing it and why they are writing it, not the language. Well ok JavaScript has some legacy warts, but ECMAScript 2019 enables a variety of very well written code in a variety of styles, and TypeScript is icing. As for me, I've only recently entered the JavaScript game, but the php I've seen has been much, much worse. I find the quality of JavaScript I typically encounter is on-par with typical…

> It's all about who is writing it and why they are writing it, not the language.

But who is writing it and why they are writing it are inextricably linked with the language. Every language has a culture and a reason for existing, those are pressures that bear as much on the person writing the language and the code produced as much as the person writing the code does on the code and the language.

Whether or not say, modern Java encourages good code is neither here nor there, as not only is there resistance to learning new things there is resistance to using the new things properly. Java has a history of bloated, inefficient code for a reason, and when you use Java, the abstractions you use will alter the code that you write. It's impossible to get away from 'bad code' without rewriting things, and then you're not coding your new project you're rewriting someone else's. It's also 'good practice' to use x y z language idioms, but there are cases when such idioms make the code much harder to read and much less clean.

As an example from C: I like POSIX, but dirname and basename are two ridiculously shit functions. If I choose to use them, the rot starts infesting my code, and everything that deals with them has to account for that, which itself causes a bias towards more obtuse code.

Re: Advice to my younger self: become allergic to the churn

#165

Post by andrewprock »

heavenlyblue wrote: post #136
vinceguidry wrote: post #123

Earlier quoted context omitted.

The only thing JavaScript was ever even barely good for was that which it was designed to do, be the programmable interface for a browser. Why anyone would want to do anything else with it simply boggles my mind. It's like if someone took the BASIC my calculator offered back in the day and turned it into a general purpose programming language.

But JavaScript's got asynchronous!

So was Windows 95.

Re: Advice to my younger self: become allergic to the churn

#166

Post by fao_ »

kabdib wrote: post #147
Crinus wrote: post #90

Earlier quoted context omitted.

Sorry i do not understand, is this post a joke? I mean it literally because of the "never happened to me", then the multimillion line makefile doesn't sound real but then you do write something that sounds like someone who has issues with makefiles could say (build order, though common that isn't make's fault - at least as much as isn't a programming language's fault that a program has bugs). So i'm not sure how to t…

The multi-million line makefile is real. I wish it hadn't been. That was a terrible time. I guess my point is that make doesn't scale, and unavoidably gets messy over time as each project solves the same problems over and over in different, buggy ways. make solves problems you get early in a project ("let's get this handful of files automatically built") and doesn't even try to address issues of modern software devel…

> make solves problems you get early in a project ("let's get this handful of files automatically built") and doesn't even try to address issues of modern software development, like build parallelism and dependency management. Its facilities for debugging problems are laughable.

Go look up plan9's mk. It's a remake of the program written by the designers a few decades later with everything they learned from it. Not only are the variables idiomatic, and the spaces problem fixed, but you can ask for output at each stage and (IIRC) view the graph that it builds.

Re: Advice to my younger self: become allergic to the churn

#167

Post by imesh »

tomgp wrote: post #86
rxhernandez wrote: post #63

Earlier quoted context omitted.

I mean I haven't been a professional for multiple decades but I've written professionally in a very wide range of fields in C, Matlab, Java, Python, Verilog, Assembly, Fortran, and Javascript, and, there is no language that I've seen that has more hair pulling, braindead I just learned to program yesterday type programming nearly as much as I've seen in Javascript. (I've worked intimately with decades old scientific…

I have a similar set of experiences but have a feeling that it's at least partly down to the sheer number of people writing Javascript and the very public nature of much of that code that so much of it is a mess. I don't think there's anything inherent in JS that make is produce messy code other than the fact that it's easy for amateurs to get results (thanks to the fact it runs in a browser and there's lots of easil…

I have made a few Wordpress sites for customers that required me writing Javascript and PHP code as I learned them for quick features and fixes. In other words, I had to write Javascript and PHP code before I even considered myself a programmer, I basically copy-pasted and edited until it worked.

I imagine that accounts for a lot of bad Javascript and PHP code. By the time I wrote any C++ or Python professionally I had a CS degree and a decade of programing experience.

Re: Advice to my younger self: become allergic to the churn

#168

Post by deng »

kabdib wrote: post #147
Crinus wrote: post #90

Earlier quoted context omitted.

Sorry i do not understand, is this post a joke? I mean it literally because of the "never happened to me", then the multimillion line makefile doesn't sound real but then you do write something that sounds like someone who has issues with makefiles could say (build order, though common that isn't make's fault - at least as much as isn't a programming language's fault that a program has bugs). So i'm not sure how to t…

The multi-million line makefile is real. I wish it hadn't been. That was a terrible time. I guess my point is that make doesn't scale, and unavoidably gets messy over time as each project solves the same problems over and over in different, buggy ways. make solves problems you get early in a project ("let's get this handful of files automatically built") and doesn't even try to address issues of modern software devel…

> The multi-million line makefile is real

Of course you quickly get to million-line Makefiles in bigger projects. In C++, if you depend on stuff like Boost, a single file can easily depend on thousands of header files, and every single one must be tracked by Make.

But of course, nobody in his right mind would write these dependencies by hand. At my dayjob, the core Makefile is 700 lines. These 700 lines do cross-compilation with gcc/clang for various platforms, unit testing, valgrind, cppcheck, clang-tidy, coverage, and several other things. It is completely non-recursive, runs in parallel without problems, tracks all dependencies, and also works on Windows.

Of course this stuff is complicated. Make is very low-level compared to a build-generator like CMake. But if you want a bespoke build system for your project which lets you control every last detail of your build, it is still a good choice.

Re: Advice to my younger self: become allergic to the churn

#169

Post by Gibbon1 »

penagwin wrote: post #79
kabdib wrote: post #75

Earlier quoted context omitted.

Common make fail #1 The project you landed on has been using some souped-up supermake with a ton of features (which were used with wild abandon) and some subtly different semantics for (say) macro expansion and variable assignment (and these are really difficult to determine the dependency scope of). The build system has grown to a recursively gnarly Turing-complete mess. So when you go to update the tooling, you fin…

>I was regularly dealing with bugs in multi-million-line makefiles. I've personally only used make for a few projects, and might not be "in the know" about how to best use make, but isn't a multi million (!?) line makefile a sign you should probably break it into peices, or use a different solution? Multi-million just seems insane to me

It sounds like something that was auto generated by a brain dead script at one time. And then later hand modified to 'get things to work' which then meant there eventually was no way to regenerate it from scratch.

Personal feeling is you should have a way of regenerating makefiles.

Post reply on HN