Hacker News Reader

Comment by etchalon | Hacker News Reader

It is such a ridiculously cool thing that we're reaching an era where the programming language you chose is as temporary a choice as the name of a variable.

View on HN

That's.. not..

How can that signal anything other than improper planning. You prefer a changing codebase over something that has evolved and is being tested over a long period of time?

New languages do in fact come out, and old languages get better, and old codebases are thing some people have to maintain.

It can also signal very good planning. If a program is properly specified and all the business logic correct then implementation language is basically as afterthought.

I'm reminded of the software for the Gemini spacecraft. Does it still exist? We don't have any assembly or machine code. But much like today in the '60s the designers of the flight software, considered the assembly output to be an intermediate stage - a kind of temporary mapping from the real program. The real program was designed in "Math Flow 7" - a visual flowchart language for expressing logic. We still have the charts. Does that mean we still have the software? Is the set of charts the software?

Yes, and, many many billions (trillions?) of dollars have been lost because the programming language couldn't be changed. Both things can be true.

This is equivalent to arguing that tech debt signals poor planning

I would much prefer it to be easy to change a codebase and for people to make lots of changes to their codebase than for people to stick with whatever they built up front

Yes but can you plan anything properly in advance? How many unknown unknowns aren't being accounted for? Maybe it's best to plan for improper planning. What to do when (not if) critical decisions start falling apart?

You go back to the design. A few critical changes in the requirements, that's expected. A codebase in which the critical parts change often, that's a red flag

I can think of many reasons.... "we were using python to quickly explore the space and rewrote to rust once we figured out the interface and started to focus on speed and safety", or "the original authors wrote this software in smalltalk but we'd rather it be golang because this simplifies deployment"

> You prefer a changing codebase over something that has evolved and is being tested over a long period of time?

As long as the test-cases are there, why would I care what language software is written in?

If you see magazines and computing TV shows from the 1980s, this is exactly what people expected computers to be able to do by the year 2000: Everyone would have a computer and write their own app for whatever they needed in a language close to plain English.

The fragmentation between programming languages and proprietary operating systems is exactly what hindered that optimism from coming true.

That is expected. We already throw away a lot of "don't do". NIH ? In this company we(claude) invent everything, DRY ? Who care, as long as it work.

As it should be. Foundational principles between languages are the same, I don’t understand why positions are gatekeeped based on implementation trivia.

+1 ! We might actually have to rethink what are costly decisions for the post Agentic world. Truly sci-fi stuff

Except for platform constraints, like needing to use JS or Swift/Kotlin, why would I use anything else than Rust? I can’t even properly read it, but the agents somehow make it work well and the code doesn’t look particularly cluttered; and it’s so fast.

I believe these words capture the zeitgeist of the 2020s.

> why would I use anything else than Rust?

Because you don’t have an infrastructure to test all platforms and want to actually execute your code instead of waiting a decade until compiler is done?

Y'all are going to cause some big disasters

Reply on news.ycombinator.com