Live data from Hacker News

Advice to my younger self: become allergic to the churn

lambdaisland.com

91–100 of 221 posts

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

#91
post #77
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…

Hm, I'm not a fan of Cmake. I like how simple and clean Make is. In my experience it works more often than Cmake, and if not, I can usually debug it. Cmake seems like an overengineered beast to me. But I probably haven't 'grokked' it yet.

I'm not a huge fan of CMake's syntax, but the thing that sold me (i.e. the "killer feature") was how easy it was to setup out-of-source builds[1].

The ability to have the entire build/build artifacts in a directory completely standalone from the source directories was a huge win.

Because for me, that meant I could have 3 separate build directories - one for my optimized ARM builds, one for my debug (-g -O0) ARM builds, and one for my x86 unit test/coverage builds.

If I modified one file, I didn't need to re-spin 3 clean builds - I just could hop into the one or more build directory I was interested in and incrementally update the builds. Plus, out-of-source builds make building clean as easy as `rm -rf build/` instead of hoping that `make clean` has all the right pattern matching and subdirectory listings to truly scrub the build artifacts.

[1] https://cgold.readthedocs.io/en/latest/tutorials/out-of-sour...

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

#92
post #78
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…

It feels like most every build system is either super over engineered or just arcane. I like that Go keeps its build system integrated with the language and that its build system is overall pretty simple and easy to grok.

Make is also very easy to grok though, at its core is just a series of "i want this file, it depends on these files, use these shell commands to produce it".

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

#93
post #85
post #53

Earlier quoted context omitted.

+1 where I live the jobs with the highest pay grade are for some fancy frameworks. If I've been doing PHP for 5 years on an 10yo framework in a company that didn't feel the need to upgrade to anything. The day I want to find an other job I'm going to be confronted with opportunities that required mastering the latest technologies and I won't find something within my pay range because of this. That is the reality wher…

Aren’t personal projects how most people learn new technologies?

I used to do that. But right now I am in a high pressure job that sucks up a lot of energy but I don't learn anything new. When I come home these days the last thing I want to do is to spend more time on the computer. I need to do something active or just sleep to maintain my health.

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

#94
post #92
post #78

Earlier quoted context omitted.

It feels like most every build system is either super over engineered or just arcane. I like that Go keeps its build system integrated with the language and that its build system is overall pretty simple and easy to grok.

Make is also very easy to grok though, at its core is just a series of "i want this file, it depends on these files, use these shell commands to produce it".

I’ve seen a lot more monstrosities created with Make, but if it’s controlled then yes, it’s not too complex.

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

#95
post #86

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'm a JS dev and I love it, but JavaScript is to programming languages what the electric guitar is to musical instruments.

It's the thing that attracts a lot of new beginners who may or may not be interested in the more serious theory that makes programming what it is.

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

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

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 Python code, and a fair bit better than the Frankenstein monsters of dev-ops code that often has a different convention for each line of bash (with attendant third-party applications) mixed in with inscrutable environment states as you shift in and out of various orchestration layers that have zero sense of application hierarchy or even running processes.

I've seen scientific codebases too, but the thing you're getting there is an authorship that is often small-team (1 or 2) and very slow to shift, with highly enculturated domain context. Of course JavaScript code is going to be a mess in organizations where you have devs coming from vastly different contexts and staying a max of 2 years with a team where all you care about is getting the pretty graphic on the screen.

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

#97
post #57
post #43

Earlier quoted context omitted.

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

Plain JS, yes. The modern JS ecosystem, however, has an enormous amount of churn. The hot way to do things in JS world five years ago is hopelessly obsolete now.

Well, the list says "JavaScript" so i took it as plain JavaScript. If you care about avoiding churn you can stick with stuff that have proven to remain backwards compatible and plain JavaScript fits the bill.

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

#98
“Churn” is definitely an issue. And JavaScript does have its own complexities. It feels weird singling out Ruby and JavaScript (and any other individual technologies), though.

I wonder if part of this is a human instinct to “other” people who are different. Someone feels superior because they use Lisp, and looks down on people using JavaScript. Or vice versa.

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

#99
post #86

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…

[deleted]

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

#100
post #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.

Linux as narrowly defined as the kernel is very good at not breaking things. Linux as used in common speech to mean a Linux distribution and associated libraries undergoes constant churn.

I maintain a cross platform desktop app for Windows, macOS and Linux.

Windows is the best, 32 bit versions going back 15 years still work no issues. macOS is next, 32 bit don't no longer work, but 64 bit versions still work going back 5+ years. Ubuntu is by far the worst, some library I depend on changes it's API pretty much every year, and the old version is removed, breaking my app.

The solution appears to be Flatpak which bundle up the app with all it's required libraries. However I'm not sure how to make this work for plugins. Would each plugin need to be in it's own Flatpak? It's insane.

Post reply on HN