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

51–60 of 221 posts

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

#51

Post by cjfd »

vinceguidry wrote: post #23
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…

Rake, the Ruby version of Make, is rock-solid, dependable, and crazy-powerful. Don't want a Turing-complete language in your build automation? Don't use it, the rule syntax works just fine. But it's there if you want it, and oh god is it great.

There is something extremely weird about the idea of having a build system for a particular language. It is not uncommon for a project to have multiple languages and it is also possible that some of the source code in one language is generated by an executable in another language. Because of this and because of compatibility issues the correct number of build systems to exist is 1. If there is more than 1 in a single project it will be the case that sometimes more is rebuilt than necessary.

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

#52

Post by breatheoften »

Thinking you can label the churn as something it’s possible to avoid by single choice upfront about dependencies is not realistic enough to be useful. Churn is not just about the dependencies- but also about the project ...

Projects which are updated often have a forcing function on them - they need to become updateable ... that can mean tests, that can mean reasonable build tools, and that can mean dropping individual dependencies that are too painful to update.

Obviously some ecosystems make all these things easier than others — typed languages with reasonable consistent build processes help more than anything. Good codebases that isolate and wrap usage of most dependencies next and reasonable automated tests probably next most useful.

It is definitely the case that some codebases are easier to update than others even given the same ecosystem/dependencies. When is the pain of “churn” most reasonably considered my fault instead of yours? Those are the situations can be fixed and they can get you pretty far — much further than “ahh, this codebase has javascript and webpack i shall rewrite with make and closure” can get you on average ...

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

#53

Post by oreglio »

Ididntdothis wrote: post #25
yogthos wrote: post #12

Earlier quoted context omitted.

The reality is that there is very little actual innovation happening in programming. 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. You don't see in other disciplines such as physics or chemistry where people spend years learning about existing research before actually startin…

I totally agree. But how do you balance this with the need for looking good on the job market? If you want to stay employable you are almost forced to participate in this craziness.

+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 where I live Futhermore, how am I supposed to learn and practice all this new stuff when my company doesn't allow time to learn anything ? Is home projects enough to fill professionnal requirements for mastering a technology ? It's not easy to stay away

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

#54

Post by tonyedgecombe »

danesparza wrote: post #13
SteveSmith16384 wrote: post #6

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

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

The problem is you don't have CI

Having CI won't stop the developer of the dependency changing the interface.

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

#55

Post by yogthos »

Ididntdothis wrote: post #25
yogthos wrote: post #12

Earlier quoted context omitted.

The reality is that there is very little actual innovation happening in programming. 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. You don't see in other disciplines such as physics or chemistry where people spend years learning about existing research before actually startin…

I totally agree. But how do you balance this with the need for looking good on the job market? If you want to stay employable you are almost forced to participate in this craziness.

I've been working with Clojure for the past decade, and haven't had to deal with any of the craziness.

The job market is smaller, but so is the pool of developers. Companies tend to be more flexible because of that and are often open to remote work. I'd much rather work in a sane niche market than deal with the mainstream churn.

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

#56

Post by tonyedgecombe »

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

The funny thing is there are developers[1][2][3] out there who would like to turn JSON into XML.

[1] https://json-schema.org [2] http://www.jsoniq.org [3] https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-j...

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

#57

Post by jefftk »

Crinus wrote: post #43
cryptozeus wrote: post #39

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

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

#58

Post by yogthos »

umvi wrote: post #20
yogthos wrote: post #12

Earlier quoted context omitted.

The reality is that there is very little actual innovation happening in programming. 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. You don't see in other disciplines such as physics or chemistry where people spend years learning about existing research before actually startin…

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

XML and JSON are both examples of the problem actually. S-expressions have existed since the 50s, and they solve all the same problems with a much saner syntax. In fact, if Mozilla marketing execs didn't insist on Java style syntax for Js, and it kept Scheme style syntax we wouldn't even need HTML and CSS today. We'd have a single syntax that would cleanly express code, styling, and layout.

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

#59

Post by deng »

umvi wrote: post #49
kd5bjo wrote: post #38

Earlier quoted context omitted.

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…

CMake has its own dependency scanner for C/C++. Look for a file 'depend.make' and you'll see the header dependencies that CMake has detected, minus the headers that CMake thinks are system headers.

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

#60

Post by waterhouse »

rout39574 wrote: post #37
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…

Lisp was theory before it was code. Javascript was a fashionable imitation of another popular language dialect.

> In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.[16] Before he could get started, Netscape Communications collaborated with Sun Microsystems to include Sun's more static programming language, Java, in Netscape Navigator so as to compete with Microsoft for user adoption of Web technologies and platforms.[17] Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax, which excluded adopting other languages such as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against competing proposals, the company needed a prototype. Eich wrote one in 10 days, in May 1995.
Post reply on HN