Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice to my younger self: become allergic to the churn

lambdaisland.com

Post reply on HN
Print view View original

111–120 of 221 posts

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

#111

Post by mighty_bander »

rxhernandez wrote: post #63
umvi wrote: 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 such a shame! JS could be a concise little language with a lot of power (in terms of being able to ignore types until they matter), but instead you end up transpiling unusable garbage with 10MB string manipulation libraries that release breaking changes as patch versions. Python is what JS is supposed to be, although I do feel like Bart Simpson in front of the blackboard every time I write `lambda x:`.

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

#112

Post by nradov »

kkarakk wrote: post #26
umvi wrote: post #20

Earlier quoted context omitted.

> Most of the ideas in use today have been discovered decades ago. The big reason for churn is that people don't bother learning about what's been done before, and keep reinventing the wheel. But on the other side of the coin, do you really want to be locked into a decades-old solution to a "solved problem" forever? Or are there still improvements that can be made to reduce friction and human error? "Machine/human re…

Your contrived example falls flat because JSON is flat out better for most use-cases and anyone having a discussion about it will probably fit into those use-cases. People don't discuss solutions in a vacuum. Ideally they'd think about what the potential fallbacks of using XML alternatives are before jumping into a new tech. Which they will, unless they're really really new

JSON is worse than XML if your use case requires namespaces.

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

#113

Post by nsilvestri »

conception wrote: post #88
misterman0 wrote: post #76

>> The Churn is losing a day debugging because a transitive dependency changed a function signature. The Churn is spending a week just to get a project you wrote a year ago to even run. The Churn is rewriting your front-end because a shiny new thing came around. If you think the churn is that then you're lucky. To me, the churn is working for the man. Everything I ever do is for the man. If I could ever reach a point…

There are many many organizations and Institutes that aren't the man. You don't have to work for a soulless corporation. You can do work that helps the greater good of humanity.

The company I work for certainly does overall good, and treats its employees well, but it's still a larger for-profit company, and the work I do isn't exactly my choice. I figure working for anyone other than myself will always have this air of being for "the man".

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

#114

Post by dwheeler »

kabdib wrote: post #75
Crinus wrote: 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…

It's true that you can screw up the use of make in multiple ways, but that is true of any programming system. I find make to be a useful tool.

The most common mistake, by far, is trying to use make recursively (where make calls other makes down a directory hierarchy). That's typically where "builds are too slow" come from, because you end up with a hairball of complex workarounds because no one make invocation actually has the correct dependency data.

I just create a single makefile and treat it like any other program: Add carefully, ensure that the text is clear, etc.

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

#115

Post by mighty_bander »

kabdib wrote: post #75
Crinus wrote: 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…

Once upon a time, .net code would just build. You had a nice list of project dependencies and references, and you could throw it all into a nice MSI installer that anyone off the street could use without being told how. It would plop debug builds in one directory and release builds in another.

Then Microsoft got rid of it because InstallShield gave them money. Now you need the super-extra-professional edition of Visual Studio to have anything but the most basic installer, and you need to hire a guy to write InstallShield scripts while he's taking a break from contemplating just how tough it would be to get by on pogey alone, and God forbid you need to change anything because the guy is on a different floor because he's not a real developer, etc. etc.

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

#116

Post by jrumbut »

March_f6 wrote: post #14

I mean, sure. But at a certain point, LISP was Javascript in terms of bleeding edge no? As someone who has built multiple things using React Native I can absolutely relate to the churn, but each time I willfully wade into it and each time I get better at handling all the pains that come along. I also can't think of a better way to improve debugging skills than to use a tech stack that gives rise to issues not easily…

Keep in mind Lisp predates the Internet by many decades.

The Lisp tradition is to leverage the expressiveness of the language to quickly create functionality that would be included as libraries in other languages. If you need an algorithm implemented, just do it and if it turns out you need it hyper-optimized and able to handle the pathological cases you look for someone who has something like that.

The JavaScript tradition (once NPM became a thing) is almost the opposite, look for a library first, and if you can't find one then consider making it yourself and posting it for others.

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

#117

Post by preordained »

daenz wrote: post #81

Accept the churn or be left behind, imo. The best thing you can do to insulate yourself from the pain described in the post (trying to remember how code worked, etc) is to brain dump important things you learn along the way. I've recently begun keeping a TiddlyWiki[0] for every major project I undertake. In it, I keep unexpected things I learned, cheat sheet items, command-line snippets, and longer form entries about…

I get what you are saying, and on a certain practical level you are right, you can't be that guy who never moved past COBOL...but I think it needs to be super clear that you can accept the churn (as necessary) but you sure as hell don't embrace it. Embracing it, IMO, is how JavaScript dev got to be what it is. Broadly speaking, a lack of nuance and temperance is the great blight on development.

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

#119

Post by [deleted] »

misterman0 wrote: post #76

>> The Churn is losing a day debugging because a transitive dependency changed a function signature. The Churn is spending a week just to get a project you wrote a year ago to even run. The Churn is rewriting your front-end because a shiny new thing came around. If you think the churn is that then you're lucky. To me, the churn is working for the man. Everything I ever do is for the man. If I could ever reach a point…

[deleted]

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

#120

Post by galangalalgol »

mighty_bander wrote: post #109
umvi wrote: 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…

Having started with the MS stack way back in the old days of their Hegemony, I always felt like make was doing something that I shouldn't have to think about. I'm curious about VSCode - why that, and not Visual Studio or another full-featured IDE? I've gone from IDE to vim and back, and I have to admit with great sadness that the various little gimmicks an IDE provides (without hand-configuring the damn thing!) make…

I have developed c++ with vim and visual studio for a couple decades. I recently made the switch to vscode from vim and i like it even better than studio. Its snappier and it integrates with my vim workflow well so i dont have to do either or.
Post reply on HN