The JetBrains Developer Recognition Program is expanding! Recognized #GitHub Stars can now enjoy free access to all JetBrains IDEs.
Learn more ⬇️

https://blog.jetbrains.com/blog/2024/10/08/github-stars-join-the-jetbrains-developer-recognition-program/

@khalidabuhakmeh I was expecting this toot from you 🕺 I still wonder which one is the real jetbrains account below, anyway it would not hurt mentioning more accounts, this is a good news

#jetbrains @jetbrains@programming.dev @jetbrains@mast.socialspill.com

  • smooth_tea@lemmy.world
    link
    fedilink
    arrow-up
    1
    arrow-down
    2
    ·
    2 months ago

    No, code is not imprecise. It does exactly what you tell it to every time.

    And that is exactly why it is imprecise, because it’s a human conceiving it. You don’t want code to do what you type, you want code to do what you define. It is easy to define what a program needs to do, it is not as easy to then translate that to something a machine understands. You are doing the interpretation for the machine, that is all that coding is and we will look back on this approach as comical. Now that machines have the ability to understand what we define, we can skip the harder steps and focus on building things instead of playing Rosetta stone and beating ourselves on the chest because we consider ourselves to be champions at it.

    What you are doing is comparing the perfect coder with LLM’s in their infancy and then conclude that the former makes less mistakes, I’m not sure why I have to point out that that is an unfair comparison.

    I can make the same broken comparison about AI generating images. Will a Picasso produce beter art? Of course, for the time being, but the AI generates in seconds what we humans do in hours or days. And for a very wide base of what we do, the AI is already sufficient in its job even though the technology is young.

    I’m sure you’ll agree that everywhere a form of AI has been implemented, from playing chess, go and StarCraft, to medical imaging, folding proteins… whatever, it quickly surpassed the quality of its human counterpart. Compared to those examples, generating code is a relatively easy task. And yes I understand that those use different “AI” than LLM’s.

    The study you’re linking completely ignores code quality.

    The study shows that your claim about productivity is false, now you’re moving the goalposts. You’ve made a lot of claims, but it all stems from a narrow distaste in how LLM’s function and you haven’t backed anything up.

    • conciselyverbose@sh.itjust.works
      link
      fedilink
      arrow-up
      2
      ·
      2 months ago

      Code and “defining what you want” are exactly identical. Natural language is not capable of doing so.

      LLMs aren’t “in their infancy”. They’re tapped out.

      You can’t decouple quality and productivity, because code that isn’t of sufficient quality is not useful, and the debt of bad code costs many, many more times more work than doing code correctly. Low quality code isn’t “doing the job”.

      • smooth_tea@lemmy.world
        link
        fedilink
        arrow-up
        1
        arrow-down
        2
        ·
        2 months ago

        No, you define what you want in project planning and briefs, coding is the interpretation of your definition. It is quickly becoming far easier and definitely faster for a machine to interpret what we define than for us to translate our definition into what a machine can interpret.

        LLMs aren’t “in their infancy”. They’re tapped out.

        And 64k oughta be enough for everyone.

        You switch to LLM’s at your convenience but you tripped over the term “AI”. We’ve been over this a few times already and I hate repeating myself.

        We can boil the issue down to a very simple question, do you think in time AI will play a significant role in how we generate code?

        If the answer is no, then I’ll see you in ten years, if the answer is yes, then you should admit that GitHub choosing that term is not out of place and it is only self evident that they use what is currently the best approach to produce code/assistance while putting it under the “AI” banner for their long term vision and because it wants and needs to ride the hype train.

        All the arguments I hear are largely pedantry and contrarianism. You see this every time something new and exciting pops up, people will huff and puff about small issues while losing track of the larger picture. The way you choose your words makes it obvious that this is just another case of that. No nuance, no, just “this is trash”, as if completely oblivious to the fact that in the time it took you to type those 3 words, a million people received an answer from an LLM that would otherwise take them 5 minutes to Google.

        You can’t decouple quality and productivity, because code that isn’t of sufficient quality is not useful, and the debt of bad code costs many, many more times more work than doing code correctly. Low quality code isn’t “doing the job”.

        But you have no idea whether the code generated is of such low quality that it offsets the time it took to produce it. That is just another assertion. For someone who is so adamant about the precision of code, you sure do throw around a lot of unfounded beliefs.

        the debt of bad code costs many, many more times more work than doing code correctly

        Like this gem for instance. Not only do you build on the unfounded premise that AI generates bad code, it also assumes a coder does not. On top of that, how much bad code? How many more times? Shouldn’t there be some quantification in all this rhetoric?