HN user
I came here to pretty much make the same comment. If you have a business that can get away with OTS software, more power to you. But complicated things are complicated and complex billing rules can be make-or-break for a company. Whether you start with 3rd party or start home grown, billing systems often need humans and there really isn't a substitute.
Somebody mentioned this in a reply, but it deserves to be a top level comment. A good chunk of this year's unusual heat may be attributable to a reduction in SO2 emissions from shipping. Article cites other factors as well, but this implies that 2023 is the new normal.
https://www.carbonbrief.org/analysis-how-low-sulphur-shippin...
It's true that they are still there, but I think loyalty is really soft. Musk seems to make some antagonizing change at least once a month that results in defections, the whole Substack thing being the latest. I follow Rex Chapman who seems to be one of those people that just does not want to have to rebuild his following somewhere else. He just recently signed up at Spoutible.
There is a bit of a forest / trees problem here. Python's simplicity is all about the barrier to computing. Because the barrier to use of Python is so much lower than for Rust, et al. you can get to a point where you've automated some human activity much more quickly or, indeed, even bothered to automate it at all. Someone knocking out a Python tool so that a manager doesn't have to gather spreadsheets every month to monitor progress is better than it not happening because Rust doesn't have the higher level libraries to make it a 5 day, 1 person project.
This article really just reads like there is some internal griping about not using Python.
About 20 years ago, I was at a pharmaceutical company and, to put together a web application, - we had to buy a prod and a dev database server - we had to buy a prod and a dev application server - we needed Oracle as a database - we needed a DBA, a sysadmin, and a hardware team - we needed Tomcat / Java and Oracle development expertise
The idea of developing and running this application with a single person would have been laughable.
Today, because tools are soooo accessible, I can, and do, routinely spin up my own VM, apply Puppet, drop my MySQL and Django containers onto that VM, and pull https certificates in addition to doing the front and back end software development.
Life would be waaay simpler if I could just write server side web application code and wait around for database developers, sys admins, and front-end folks to do their thing. Imagine not having to learn a testing harness because there are actually people testing the software!
I think this is really the crux of the matter. More generally, STABLE management that drives software quality. Even if you're lucky enough to be part of a team that starts of with good management, reorgs, mergers, and turnover are just way too frequent to provide the year-over-year improvements needed for really good, efficient code.
For something like this to be successful, I think it has to have some kind of domain focus. I've been working in bioinformatics-adjacent jobs for the last couple decades and I've seen things like this get used when there were a lot of integrated, domain-specific tools. Even then, the users were a curious slice of the population that could think like a programmer, but had not bothered to learn a language.
It also has to have a lot of buy-in and support. As everyone here is fully aware, a lot of problems get solved by Googling for a Stack Overflow answer. That's tough to do with a niche-y tool.
Not saying this isn't a good thing; it's just that it'll be difficult to be successful as a general purpose tool.
I think the whole value of the Unix tool ecosystem is that you don't need to build large pieces of software. If you look at all the GUI tools that Microsoft had to build for Windows administration in the earlier days and how they eventually came out with PowerShell because of the inadequacy of those tools, you can see how successful Unix tools have been by the --lack-- of big software that does their job.
Thank you.
You're not totally wrong; I'm getting into that age range.
It's not that I prefer those tools; they are really obtuse. It's just that I can't handle the moving target of JavaScript. I'm sure I can figure out esbuild just fine, but in a year or two it could be abandoned in favor of swc or Vite or a Vite-esbuild-swc uber package.
Indeed
I think CMake is a real pain and Autotools is an older pain. But I can figure them out and things I learned two blue moons ago are still basically true. The churn in JS makes it really hard for me to accumulate knowledge and solutions.
I know it's just piling on at this point, but I've been doing a lot of software builds and deployment over the last 20 years, mostly in a scientific computing context. Nothing I've dealt with is as bad as JavaScript.
I've generated and hacked dozens of autotools builds and written m4 macros of my own; I've hacked CMake builds; written RPM spec files; fixed Rcpp package installs; written and modified innumerable Makefiles; setup Tomcat webapps; and use Python for most of my daily work. I've even hacked around with Boost's build thing.
Complexity is not the issue with JavaScript. Stability is the problem.
Most devs do not want to "know" build systems. You want it to work most of the time and when it doesn't, you want to be able to find the answer to a problem. You want that knowledge to accumulate over time so that the answer you found the last time still works.
Autotools is an insane system, but it's been the same insane for 30 years.
Currently using vue-cli with Vue 2 and Vuetify, a configuration depending on a lot of precisely pinned versions to get functional. There is a pile of deprecated library warnings during the lengthy build process that I have no idea how long it will take me to address. Could be a couple of hours, could be several days, could be impossible.
Would like to try Vite or esbuild because God knows we could use the speed up, but after investing a couple of weeks to figure out the precise balance of versions that will work and propagating to our 8 or 9 applications, where are we going to be next year? I saw a Tweet yesterday about vite on swc. Is that going to be the winner?
I half wish Richard Stallman would take over. How desperate is that?
A small internal software group like mine would almost certainly be a casualty of any real increase in software liability.
On the other hand, the inevitable slowing of technology change and consolidation of libraries, languages, and frameworks would be kinda nice. Hard won, deep knowledge of technology that is 20 years old would be worthwhile. And I could finally stop yelling at JavaScript frameworks to get off my lawn.
Putting two kids through college on it.
> Tech debt, unlike financial debt, is an asset to no one, it’s only a diminishment of value.
A lot of the technical debt discussions I've read are very development team focused. What is often missing is the value to the user. Assuming your software is meant to make some group of users more efficient, over certain time periods, the user is getting value regardless of the cleanness of the code (within certain reasonable limits).
For most of my career, I've done small team internal software projects. The value of those projects is the improved efficiency of the users minus the amount of developer hours put in. Time spent refactoring can absolutely be worthwhile, but code improvements that don't add to user efficiency have to be carefully chosen, otherwise you're cutting into the value the organization is accumulating.
Please, people. If Google wanted to make a statement about imperialists and white overlordship, there are more impactful ways to do so than hiding Churchill's picture.
This is just a glitch
Ooh. This is good. When I write my best selling Management Genetics(R) book filled with cellular jargon to describe The Business Double Helix(R), I am totally using this. With attribution, of course.
This is a wonderful comment. I think someone on this site said that coding is the process of understanding the solution. This is what that means.
Really well said. If you think of it as a --social-- capital enterprise, every part of the chain can benefit. Like other social entanglements, though, there is a need to break them up from time to time.
It changes the likelihood of the veracity of the document. If HN has done some sort of vetting, great. But there is no reason to take at face value anything that comes from Veritas.
A discussion on censorship is a great thing to have. Just not starting with this guy.
This "blacklist" comes from James O'Keefe's Project Veritas. They have a long history of staged "expose"s around the current Republican "bad guy of the day"; ACORN, voter fraud, etc. Regardless of whether this is legit, I'm surprised it showed up on HN.
Thank you all for giving this article the treatment it deserves.