Live data from Hacker News

Advice to my younger self: become allergic to the churn

lambdaisland.com

121–130 of 221 posts

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

#121

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…

Have you tried ShareLaTeX/Overleaf? I have had better luck maintaining header compatibility with it.

https://en.wikipedia.org/wiki/ShareLaTeX

https://www.overleaf.com

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

#122
post #75
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…

Common make fail #0

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

#123
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…

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…

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.

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

#124
Clojure's reduced churn is a consequence of sitting at a local maxima in programming language design. If it were not a local maxima, there would be churn as we search for it.

UI 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

#125

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

Your CI pipeline should be simple, relatively unchanging and therefore trusted. When shit breaks (and it will) you should get a signal much earlier. This signal should strongly relate to your most recent changes -- and your changes should be small because you commit early and often, right?

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

#126
post #28

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

What an awesome compliment for our team. Thank you!

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

#127

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?

No but your mom does.

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

#128
post #107
post #36

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

That’s part of my point.

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.

Post reply on HN