[–] 1 point 5 days ago

Make is fine unless you want to build on Windows. Then you kind of need something else.

I agree, you kind of need something else instead of Windows if you want to build software.

It is the very slow process creation infrastructure that kills Make as a tool on Windows.

s/Make as a tool on //

  • source
  • parent
  • context
  • [–] 1 point 5 days ago*

    Give me a Make that

    • properly handles filenames with arbitrary names (Make today breaks if filenames contain whitespace)
    • uses space-based indentation level (Make today depends on the invisible difference between U+0008 TAB versus other whitespace, and refuses to process any other indentation)

    Give me that, and... well, I'd probably still stick to current-day Make, because those improvements would cause my Makefiles to be backward incompatible. Make is just reliably available on pretty much any arbitrary system, unlike any candidate replacement.

  • source
  • [–] 6 points 6 days ago* (last edited 5 days ago)

    Now I definitely know you haven’t seen a real professional codebase.

    Extremely wrong. So much for your assumptions.

    Professional git repos are full of one sentence commit messages with little to no explanation of what’s in the change set.

    Yes, humans can communicate poorly, of course. But people letting the LLMs do it do not understand what is in the change, and the LLM certainly doesn't. There's no one at all to ask because no one understands what was changed or why.

    I'll take “sometimes lazy but they wrote it and their understanding of it can be interrogated”, all week.

  • source
  • parent
  • context
  • [–] 9 points 6 days ago* (3 children)

    Working professionals are, if at all competent to be committing code to a professional code base, entirely capable of writing their own commit messages.

    If they can't write the commit message, they can't sufficiently explain in writing the commit they just made to anyone. So, they should not be working professionally on a code base.

    If they are capable of writing the commit message with their own understanding in their own words, but they choose not to communicate their understanding in the commit message? Also disqualifying, they should not be working professionally on a code base. Human communication is essential to this work.

    That this is a controversial position, is a clear sign of the Slopocalypse.

  • source
  • parent
  • context
  • [–] 2 points 1 week ago* (last edited 1 week ago) (2 children)

    But that has the same effect like DB_HOST="${DB_HOST:-localhost} (use the string if not set), which is more readable.

    I disagree that the duplicate reference would be more readable. Instead, the reader needs (if they care about the meaning of the code) to double-check whether the two duplicate names are exactly the same, or whether they are subtly different. At which point the reader needs to wonder why the code isn't written using the form without the repeated name. So, that's not a readability improvement.

    Related to that: Code with duplicate references in a single expression or statement leaves open the likelihood that one or more of them will contain a typo or an easily-overlooked difference, leading to bugs. DRY is a good principle to avoid that.

  • source
  • [–] 8 points 3 weeks ago

    In the workplaces where I've been pressured to use LLMs for coding, this would not faze them. Management would just say “See, waiting for reviews is taking longer, we can't afford it any more. No reviews, just productivity.”

    Plummeting quality of the result is no barrier to a boss that just wants higher numbers to please their boss.

  • source
  • [–] 5 points 3 weeks ago* (last edited 3 weeks ago)

    It may depend where the project is and what you want to bring with you.

    If you're asking solely about the Git repository: you need to find exactly which commit is the latest one you want to bring, and specify that commit identifier (the hash of that commit) as the “starting point” when you create a new branch.

    git branch […] []

    https://git-scm.com/docs/git-branch

    So, clone the repository locally however you need to do that. Then, in your local repository, modify what the branches point to:

    e.g. If you determined the latest commit you want to bring, has commit identifier “deadbeefbad1dea”, you can create the branch named “before-the-slop”:

    git branch before-the-slop deadbeefbad1dea

    Now the new branch “before-the-slop” has all the commits up to that, and no further. That's what you'll base your fork on.

    git branch before-the-slop

    git rev-parse HEAD # → deadbeefbad1dea

    Then rename the old “main” or whatever branch, to something like “sloppified-project-main” that gets it out of the way; rename your “before-the-slop” branch to “main”; and set “main” as the default branch in your repository.

    git branch --move main sloppified-project-main

    git branch --move before-the-slop main

    git config set --local init.defaultBranch main

    Some time later, when you've confirmed your repository is how you like it, delete the “sloppified-project-main” branch:

    git branch --delete sloppified-project-main

    and breathe easy.

  • source
  • [–] [S] 11 points 3 weeks ago (14 children)

    What world are they living in that 1.5MiB is huge?

    That depends. Am I buying the SSD last year, or today?

    The RAMpocalypse is going to make “this doesn't run on a low-powered low-capacity device” a much more relevant issue.

  • source
  • parent
  • context
  • [–] 5 points 4 weeks ago* (1 child)

    jfc is that a thing now, people just ignoring the enormous theft that’s wrapped up in LLMs and calling it clean?

    It really is a thing. Far too many conversations lead to the moronic “no no it's cool, I heard in the USA they say it can't be copyrighted”, as though that addresses the concern at all.

    I'm here for the end of copyright, but if someone believes copyright will be just poofed out of existence because an LLM washed the code? They are not paying attention to how many lawyer hours these corporations are willing to drop on your head for daring to challenge their monopoly.

  • source
  • parent
  • context
  • [–] 4 points 1 month ago*

    This is the correct answer.

    Anything a computer is doing, the software that does it is doing that because someone(s) programmed it.

    You're not looking for a programming language specific to a task; those exist, of course, but it's better to know how systems are programmed, and what APIs are used to program the system you're interested to control. Choosing which programming language to use should come after knowing what you want the computer system to do.

  • source
  • parent
  • context
  • [–] 6 points 1 month ago* (last edited 1 month ago) (1 child)

    While I want everyone to freely choose to end their Meta accounts, and while I agree that one should never be in a position where a unilateral decision can block access to one's personal data and contacts, we must not be smug about what's happened here.

    Meta is like any monopoly platform: They actively and aggressively get as many people as possible to put as much of their life as possible onto the platform, and deliberately make it difficult to leave. Not to mention that they also effectively dominate so much of the “share with your friends and colleagues and customers” capacity, that any competitor would have an enormous disadvantage and therefore these people cannot leave Meta easily.

    The solution here is not to shame people for still using the dominant platform, when that platform's switching costs make it immensely difficult to leave with one's data and connections intact. We must instead agitate for change so that there can never be any profit-motivated dominant platform. This will carve out the room for a rabble of competitors that are each small enough they cannot dominate, and must treat their users with respect in order to keep them.

  • source
  • [–] 6 points 1 month ago* (3 children)

    A Git repository is primarily for tracking the human-readable source code of your project, tracking changes to those text files over time. In the past few hours you appear to have deleted all of that.

    If you are publishing only binary build artefacts and not the source to build them? You will not get much interest from programmers.

  • source
  • [–] 1 point 1 month ago* (last edited 5 days ago)

    I seriously feel like I’m going crazy since it seems to me like I’m the only one who isn’t satisfied with the “capabilities” of LLMs.

    This is an unsurprising impression to form. But it's false.

    You are seeing a lot of people boosting the LLM's capabilities, for many reasons.

    Some of them are sincere, to a degree: they feel like they are doing more, because they're churning out code so much faster! But they're discounting or ignoring the downsides: They have far less comprehension of that code, they can't possibly review it effectively, they don't perceive the lost time trying to work the extruded output into something they can use; etc.

    Some of them are insincere, because they're grifting: hoping to hype others into committing more to this technology and to their apparent experience, for clout or money. Those people can die in a hole.

    A lot of them are insincere, because they perceive it will hurt their short-term career to not spout enthusiastically about using LLMs for coding. Their bosses demand it be used, measure its use and rank employees based on token burn, and job adverts overwhelmingly seem to require use of LLMs. People pretend to love this stuff just to stay employed.

    Don't believe it just because people say it. Believe your own experience: you have seen how godawful is the code extruded from these slop machines. You have seen how voluminous and ignorant of context it all is, making it worse than useless to try integrating into an existing project. You have seen how the LLM can't effectively maintain its own code medium-, let along long-term. It's all a colossal waste of effort and resources, a dead end.

    Let people use the LLM for their own code if it makes them happy. But don't accept it into your project if you don't want it; and definitely don't trust their self-reported productivity unless they bring the code, and you independently assess it. You'll find very few claimed successes survive that simple scrutiny.

  • source
  • parent
  • context
  • [–] 1 point 1 month ago

    Thanks for coming back to report this. I'm sure others here were, like me, hoping we could reach you with positive messages and give you the confidence in yourself you deserve.

    Stay strong and find your way. Write more articles here if you like. We're wishing you well.

  • source
  • parent
  • context
  • view more: next ›