Live data from Hacker News

Advice to my younger self: become allergic to the churn

lambdaisland.com

41–50 of 221 posts

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

#41
post #17

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…

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).

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

#42
Agreed. And I'm a rubyist!

I 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'd put JavaScript in the "Examples" section as, like HTML, any change it gets is fully backwards compatible so you do not have to play catch-up with the latest stuff just to keep your existing code working.

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

#44

Just 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.

> But how do you want to avoid that? Staying with old libraries forever?

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

#45

I'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 are you referring to? Linux never intentionally breaks userspace code.

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

#46
post #17

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…

> don't just rip on random scripting languages that have been around for 25 years

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

#47

I'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

#48
post #34
post #27

Earlier 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…

> and forget to add new header files to the list of headers

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

#49
post #38
post #34

Earlier 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?

> 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

#50
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 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.

Post reply on HN