I've submitted this link because the topic is interesting to me, and !functional_programming@programming.dev is practically dead, with the last post dating back over 10 days.
For those who are down voting the contribution, be my guest and do better: submit interesting content.
Yes. Multiple historical layers (...)
This is reaching a level of idiocy that's completely unheard of.
Just say you know nothing about what you're saying and you're completely oblivious, and sit out the rest of the discussion.
If Google were to start over, all of that would be thrown out. It just can’t be done.
To stress the importance of this very basic fact, people need to understand that even Google, a company with virtually limitless resources to rearchitect and rewrite any and all type of software project, made the call to avoid using major features offered by some programming languages, such as C++'s exceptions, because it could have unintended consequences on the company's legacy code base which they could not rewrite.
And here we are, reading fantastic claims over how complete rewrites are reasonable things while flipping compiler flags to harden legacy projects is unheard of.
Most software is built under non-ideal circumstances. Especially in the beginning there’s often tight deadlines involved.
Exactly this.
I think a bunch of people commenting in this thread on the virtues of rewriting things from scratch using the flavour of the month are instead showing the world they have zero professional experience working on commercial software projects. They are clearly oblivious to very basic and pervasive constraints that anyone working on software for a living is very well aware.
Things like prioritizing how a button is laid out over fixing a rarely occurring race condition is the norm in professional settings. You are paid to deliver value to your employer, and small things like paying technical debt are very hard sells for project managers running tight schedules.
Yet, here we are, seeing people advocating complete rewrites and adding piles of complexity while throwing out major features, and doing so with a straight face.
Unbelievable.
You have a point. Thanks for taking the time to go through this. Good job.
Yet the world is full of code that was replaced with less work than it would take to fix a single bug on the broken original.
Can you point out a concrete example? Because you're commenting on a discussion on an essay that documents several notorious examples that demonstrate the opposite point.
Doesn’t create symlinks or mess with global NPM packages.
That's hardly relevant for those who need to run node on Windows and WSL is not an option.
Also, nvm is only supported on windows through WSL or cygwin, just like n, not sure where you are getting nvm for windows.
Just yesterday I installed it through chocolatey on a Windows box without WSL.
Also, it seems you failed to notice that nvm makes references to cygwin and git-bash, the later of which everyone who installs Git ends up having in their system.
It’s not to pretend there’s no good advice in the book, but that the bad advice is really bad and very prominent.
Care to point out what you think is he absolute best example that supports your point?
A single example will do.
Otherwise all you have to show is an unsupported personal observation which contrasts with what's written on the book.
The core principle of computer-science is to continue moving forward with tech, and to leave behind the stuff that doesn’t work.
I'm not sure you realize you're proving OP's point.
Rewriting projects from scratch by definition represent big step backwards because you're wasting resources to deliver barely working projects that have a fraction of the features that the legacy production code already delivered and reached a stable state.
And you are yet to present a single upside, if there is even one.
At this point it’s literally easier to slowly port to a better language than it is to try and ‘fix’ C/C++.
You are just showing the world you failed to read the article.
Also, it's telling that you opt to frame the problem as "a project is written in C instead of instead of actually secure and harden existing projects.
A random guy going through the trouble of putting together a site to subjectively rate other people's work is hardly something that's language-specific.
I'd wager that adding a single tag/field to represent the programming language is all it takes to make the system universal.
Also, that's not even language-specific. It's package-centric.
I get it, joining bandwagons is fun. That's not a substitute for thinking things through, though.
By the way, npm even supports package auditing, warnings, and autopromoting packages and its dependencies. You don't hear people constantly parroting switching projects to Node.js over this, though.