4 ms·

> a recurring need in the software world for teams to convert a codebase from one language to another Really? I've only seen that twice in my career, and it wa

> a recurring need in the software world for teams to convert a codebase from one language to another Really? I've only seen that twice in my career, and it was due to being written in the most obsolete tech ever. I have the same comment for the "patterns" that GPT-bros seem to be stuck in all the time. What kind of software are they writing that needs 80% of duplicated/useless code, and 20% of business code? They should first read Refactoring by Martin Fowler, and try to avoid those mistakes in the future because it's bad to rely on a AI for what should be their job, i.e. engineering software. > the database querying layer was quite verbose and greatly exceeded an LLM’s output token limit No technical details as usual, only high-level stories. And how is it possible nowadays to have that kind of issue where most languages have their own SQL or REST library to do everything in, at most, 500 lines of code (if the code is duplicated)? Last but not least, the main web site is a very pretty empty page if JS it disabled. They should fix that with an LLM and write a blog post, that would be more interesting.

blowski 2y ago
I've found it to be more common in organisations with an immature microservices culture, where developers seem to think there are awards for most number of languages used. At some point, sanity takes hold, and there is a process to standardise - involving lots of rewrites of small codebases.
joshuanapoli 2y ago
The JavaScript ecosystem historically had a lot of turnover. Probably there are a lot of applications that repeatedly ported over the years: Ruby to JavaScript, to coffescript, to flow types (for React), to Typescript. I think that these language ports aren’t as disruptive as architecture changes (waffling on microservices), and they’re driven by availability of talent. Porting to follow the trend makes it easier and much more pleasant to onboard new developers. It usually has a practical benefit to users, because the latest tooling usually has a performance edge, but doesn’t support the old language.
- blowski 2y ago
  Yes, good point. Even within React, there's been a big change from class components to functional components and hooks. I imagine LLMs could help with some of that.
  - cjonas 2y ago
    I just ported 10k loc of react classes to function components using gpt-4o. The changes are mostly trivial, but would be fairly time consuming and tedious to make. It took me a few hours instead of a few days.
    - bavell 2y ago
      Isn't this already possible with codemods?
      - _f9cu 2y ago
        No. Nobody can understand how to use code mods. I could not. But I'm not sure about others. My view is that those engineers in fb are no longer there to promote and support that project. Or they would have migrated to learning ai ml
        deleted 2y ago
        [deleted]
        bavell 2y ago
        Fair enough, I've never used them either!
    - _f9cu 2y ago
      How much did it cost?
- JTyQZSnP3cQGa8B 2y ago
  I forget "JS and the web" all the time because I've been actively avoiding it for the past 20 years. It happens in other environments but the web seems to encourage "following the trend" and that would make me crazy if I had to do this every day.
fhd2 2y ago
That's a concern I have: The pain of writing boilerplate used to make people improve their architecture and frameworks. If the Java ecosystem hadn't been so painful in the early 2000s, would better languages and frameworks have gained traction? Would good refactoring practices have gained traction? Sometimes refactoring doesn't even cut it, unfortunately. When stuck with a language and/or framework that simply requires lots of boilerplate, there's only two options: Migrate to something else or use/build code generation tools. I've done both with good success. Not sure I'd use a non-deterministic tool (like an LLM) for this, but since deterministic tools are harder to build, we might be looking at a future where a lot of working code is rewritten with automation that introduces subtle problems. I'm optimistic though. There's always been a lot of terrible software somehow kept under control with high development/testing resources. And then there's always been carefully built good software. I suspect we'll continue to have both. We'll probably have good software because some managers manage to hire good devs _and_ give them the right direction and support to do good work. We'll probably have lots of bad software for the same reasons as in the past: Incompetent management, competent management pragmatically sacrificing software quality and/or maintainability, incompetent (or really just impatient/rushed) developers. I don't think LLMs change the equation that much. Good devs will use them well (or perhaps not at all). Bad devs will use them badly. Good software can give startups an edge, bad (enough) software can bring down incumbents.
onion2k 2y ago
I've seen it a lot. Mostly things like moving from PHP 3 to PHP 5, or Python 2 to Python 3, or React 12 to React 17. A language change doesn't have to be between completely different languages to be a pain.

blowski 2y ago

I've found it to be more common in organisations with an immature microservices culture, where developers seem to think there are awards for most number of languages used. At some point, sanity takes hold, and there is a process to standardise - involving lots of rewrites of small codebases.

joshuanapoli 2y ago

The JavaScript ecosystem historically had a lot of turnover. Probably there are a lot of applications that repeatedly ported over the years: Ruby to JavaScript, to coffescript, to flow types (for React), to Typescript. I think that these language ports aren’t as disruptive as architecture changes (waffling on microservices), and they’re driven by availability of talent. Porting to follow the trend makes it easier and much more pleasant to onboard new developers. It usually has a practical benefit to users, because the latest tooling usually has a performance edge, but doesn’t support the old language.

blowski 2y ago
Yes, good point. Even within React, there's been a big change from class components to functional components and hooks. I imagine LLMs could help with some of that.
- cjonas 2y ago
  I just ported 10k loc of react classes to function components using gpt-4o. The changes are mostly trivial, but would be fairly time consuming and tedious to make. It took me a few hours instead of a few days.
  - bavell 2y ago
    Isn't this already possible with codemods?
    - _f9cu 2y ago
      No. Nobody can understand how to use code mods. I could not. But I'm not sure about others. My view is that those engineers in fb are no longer there to promote and support that project. Or they would have migrated to learning ai ml
      - deleted 2y ago
        [deleted]
      - bavell 2y ago
        Fair enough, I've never used them either!
  - _f9cu 2y ago
    How much did it cost?
JTyQZSnP3cQGa8B 2y ago
I forget "JS and the web" all the time because I've been actively avoiding it for the past 20 years. It happens in other environments but the web seems to encourage "following the trend" and that would make me crazy if I had to do this every day.

fhd2 2y ago

That's a concern I have: The pain of writing boilerplate used to make people improve their architecture and frameworks. If the Java ecosystem hadn't been so painful in the early 2000s, would better languages and frameworks have gained traction? Would good refactoring practices have gained traction? Sometimes refactoring doesn't even cut it, unfortunately. When stuck with a language and/or framework that simply requires lots of boilerplate, there's only two options: Migrate to something else or use/build code generation tools. I've done both with good success. Not sure I'd use a non-deterministic tool (like an LLM) for this, but since deterministic tools are harder to build, we might be looking at a future where a lot of working code is rewritten with automation that introduces subtle problems. I'm optimistic though. There's always been a lot of terrible software somehow kept under control with high development/testing resources. And then there's always been carefully built good software. I suspect we'll continue to have both. We'll probably have good software because some managers manage to hire good devs _and_ give them the right direction and support to do good work. We'll probably have lots of bad software for the same reasons as in the past: Incompetent management, competent management pragmatically sacrificing software quality and/or maintainability, incompetent (or really just impatient/rushed) developers. I don't think LLMs change the equation that much. Good devs will use them well (or perhaps not at all). Bad devs will use them badly. Good software can give startups an edge, bad (enough) software can bring down incumbents.

onion2k 2y ago

I've seen it a lot. Mostly things like moving from PHP 3 to PHP 5, or Python 2 to Python 3, or React 12 to React 17. A language change doesn't have to be between completely different languages to be a pain.