I recently cut a technology out of my life that was causing a lot of churn, and I'm much happier as a result. That technology was TeX, even though it's on the author's "good" list. It's somehow got to a point where every time two people got together to work on a document, we had three different incompatible header files; package X doesn't work with version Y of package Z; what order you import packages in matters on…
Advice to my younger self: become allergic to the churn
121–130 of 221 posts
Re: Advice to my younger self: become allergic to the churn
#122Earlier 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…
Not starting by reading the manual, and then writing an idiomatic make file.
Once you understand how to use auto generated .d files, you’ll never have a multimillion line make file.
Once you understand the built in lex and yacc rules, you can generalize them to whatever code generator you are using.
The remaining thing (not spelled out in the manual) is to avoid recursive sub make, and to use the include directive instead. “Recursive submake considered harmful” is a helpful paper, but it should have had the subtitle “a practical alternative”, because people cite the title without reading the whole paper.
Re: Advice to my younger self: become allergic to the churn
#123The piece reads like a Unix pastor's pulpit preaching "Great nutritious technologies to use: Make, Emacs, Lisp, CLI" "Bad unwholesome technologies to use: JavaScript, Ruby, IDEs, Graphical User Interfaces" I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years. And is it candy or an olive that I like VSCode and not Emacs (not that I've ever tried Emacs, I just don't…
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 like if someone took the BASIC my calculator offered back in the day and turned it into a general purpose programming language.
Re: Advice to my younger self: become allergic to the churn
#124UI has no such minority consensus for local maxima and is very much not solved, which is why React-Preact-Vue-Angular is churning while the humanity hivemind iterates towards a solution.
Here is the relevant Rich Hickey quote: http://www.dustingetz.com/:rich-hickey-web-frameworks/
Re: Advice to my younger self: become allergic to the churn
#125Earlier quoted context omitted.
The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready
Until your CI pipeline causes churn because something doesn’t work anymore....
Re: Advice to my younger self: become allergic to the churn
#126Earlier quoted context omitted.
Until your CI pipeline causes churn because something doesn’t work anymore....
We use GitLab CI, and it's been working maintenance free for 3 years now. We configured the test runners in 2016, and haven't touched them since and they have never randomly broken - even across GitLab updates (of course, YMMV depending on if you like to be on the bleeding edge all the time; we are always 1 cycle behind the bleeding edge).
Re: Advice to my younger self: become allergic to the churn
#127I'm sorry -- you lost me at UNIX, LISP, The Web, Emacs, TeX. There is a reason UNIX and Linux is so fragmented - it was the thing that was churning for so long! In some respects, it continues to churn (I'm looking at you, Linus Torvalds).
What do you own your own time sharing mainframe?
Re: Advice to my younger self: become allergic to the churn
#128> The Churn is spending a week just to get a project you wrote a year ago to even run. How much effort would it be worth avoiding to spend a week every year ? Sure the weeks can add up, but so does the time spent on low level abstraction, and refusing to adopt better tools when the whole environment in changing around (e.g. there is no mention of native mobile environments. Would it be churn use to Swift instead of n…
I find Swift very bad for churn. Swift has had 5 versions in 5 years, with breaking api changes each time. Every answer on Stackoverflow about Swift has several answers, one for each api version. Any time you grab some Swift code from the web or an older project, it's not going to work. Avoiding the churn isn't an option since new Xcode versions drop support for old Swift versions. And only the two latest Xcodes will…
Cutting yourself from new frameworks and hardware features just to cut churn would be a horrible tradeoff in most cases.
There are some niches where churn can be mostly avoided, but I think churn is usually a fact of life we could just embrace at a healthy pace.
From the opposite angle, a field with extremely low churn would seem suspicious to me. For instance I would expect any language with no significant update in the last 10 years to have abysmal unicode support.