The 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…
Advice to my younger self: become allergic to the churn
41–50 of 221 posts
Re: Advice to my younger self: become allergic to the churn
#42I think ruby has actually gotten a LOT better at minimizing the churn (both core/stdlib, and the ecosystem, specifically including Rails itself), as a result of people learning from the experience. The ecosystem still doesn't prioritize it as much as I'd like.
I also think this points out the benefit of sticking with a platform/ecosystem for a while. Many people didn't realize the danger of backwards-incompat churn until they saw it through experience over years.
You notice it when you work with the same code for a while -- if you are always abandoning a codebase and coming to a new one, you abandon before it gets painful, and either have a new one that isn't yet painful or a legacy one where you can blame the pain on your predecessors making bad decisions.
If you are always abandoning a platform for a new one -- the dangers of 'churn' aren't apparently in a less mature platform, you never pay the price at version 1.0, only after it's been around a while. But they will be if it lasts long enough and you stick with it long enough -- if when it starts hurting you abandon it for some other new thing thinking the other new thing will be better and not realizing it's better in that respect only cause it's newer... you never learn.
Re: Advice to my younger self: become allergic to the churn
#43“Examples: Clojure, Common Lisp, HTML, Make Counter-examples: JavaScript, Ruby, React-Preact-Vue-Angular-“ OP does not give any reason as to why these are churn and why stop them ? This makes no sense...basically to op’s point we should just never adopt new technology because it’s just a new shiny thing. This makes no sense at all.
I do not know about Ruby nor about React-Preact-Vue-Angular to judge, though based on what i've heard the latter pile does sound made up of things that expect you do waste your time ensuring your software keeps working.
Re: Advice to my younger self: become allergic to the churn
#44Just this morning I've spent an hour trying to get a well-known Http library to work in my project, cos the developers keep completely refactoring all the classes and methods. Stop it!!
But how do you want to avoid that? Staying with old libraries forever? In some areas this is possible but in others you have to use newer stuff. I always envy people who work on stuff that’s mainly their own code and not cobbled together from other systems with their questionable APIs.
Well, one way would be those libraries to have backwards compatible APIs so that your code keeps working yet still using the same APIs. Some actually do try that (or at least they claim so), e.g. curl.
Re: Advice to my younger self: become allergic to the churn
#45I'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).
Re: Advice to my younger self: become allergic to the churn
#46The 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…
Where do you see that?
My point being: I imagine you could avoid this just fine with javascript. I don’t see this as a technical issue so much as a cultural one—we gave up on vetting our dep trees.
Re: Advice to my younger self: become allergic to the churn
#47I'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).
Re: Advice to my younger self: become allergic to the churn
#48Earlier quoted context omitted.
>I personally hate Make, it's burned me too many times. I’d be interested in hearing about the problems Make has caused you— Whenever I’ve needed to write or edit a makefile, it’s been a pain looking up the relevant details in the manual, but nothing as severe as what you seem to be implying. Have I just been lucky, working with less complicated projects, or something else?
> I’d be interested in hearing about the problems Make has caused you The main problem that kept burning me was that I'd have a "dirty" build when I thought I had a clean one or an incorrect one when I thought I had a correct one. It was super hard to get the dependency graph correct because developers were creating files left and right but would only update the Makefile just enough to get it building (and forget to…
This is why gcc/clang have the option to generate Makefiles for the header dependencies for you. Maintaining these yourself is a hopeless effort.
Re: Advice to my younger self: become allergic to the churn
#49Earlier quoted context omitted.
> I’d be interested in hearing about the problems Make has caused you The main problem that kept burning me was that I'd have a "dirty" build when I thought I had a clean one or an incorrect one when I thought I had a correct one. It was super hard to get the dependency graph correct because developers were creating files left and right but would only update the Makefile just enough to get it building (and forget to…
That makes a lot of sense. Setting up automatic dependency detection is what finally made Make click for me, and it’s not the most straightforward process to get right. How does CMake detect the files that a given product depends on; does it have language-specific dependency detection or something else?
Well actually, CMake is a build system generator - and the default build system it generates is Unix Makefiles. So I assume CMake generates Makefiles with the appropriate automatic dependency detection baked in, I'm not sure.
The important part was that it eliminated human error on our team and we haven't had dependency graph problems since.
Re: Advice to my younger self: become allergic to the churn
#50That 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 my computer but not on a colleague's (still not sure why); the order of macro expansion and character class redefinition in some packages causes hard to track down bugs ...
80% of what I need to do, I can do in markdown and then run through one of many document-generating tools. Currently for some projects I'm using gitbook-cli and I'm both more productive and much happier. I even wonder whether I want to make a fork of gitbook-cli, it's something I'd trust myself to be able to contribute to.
For the other 20%, I use word. Yes it's a WYSIWYG interface but for short documents (max 20 pages) where layout and design is important to get right, I've found myself being able to save time and frustration compared to TeX.
Editor-wise, I use vim or vscode depending on the task. I've tried emacs, we two are not really compatible.