| ▲ | etchalon 4 hours ago |
| 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. |
|
| ▲ | 4b11b4 3 hours ago | parent | next [-] |
| That's.. not.. |
|
| ▲ | srivarun96 3 hours ago | parent | prev | next [-] |
| +1 ! We might actually have to rethink what are costly decisions for the post Agentic world. Truly sci-fi stuff |
|
| ▲ | gonzalohm 3 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | retrac 3 hours ago | parent | next [-] | | 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? | |
| ▲ | gchamonlive 2 hours ago | parent | prev | next [-] | | 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? | | |
| ▲ | gonzalohm 23 minutes ago | parent [-] | | 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 |
| |
| ▲ | malisper 3 hours ago | parent | prev | next [-] | | 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 | |
| ▲ | awongh 3 hours ago | parent | prev | next [-] | | Yes, and, many many billions (trillions?) of dollars have been lost because the programming language couldn't be changed. Both things can be true. | |
| ▲ | etchalon 3 hours ago | parent | prev [-] | | New languages do in fact come out, and old languages get better, and old codebases are thing some people have to maintain. |
|
|
| ▲ | wiseowise 2 hours ago | parent | prev | next [-] |
| As it should be. Foundational principles between languages are the same, I don’t understand why positions are gatekeeped based on implementation trivia. |
|
| ▲ | Razengan 2 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | manmal 3 hours ago | parent | prev [-] |
| 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. |
| |
| ▲ | wiseowise 2 hours ago | parent | next [-] | | > 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? | |
| ▲ | Procrastes 2 hours ago | parent | prev [-] | | I believe these words capture the zeitgeist of the 2020s. |
|