Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)H
Posts
139
Comments
505
Joined
1 yr. ago

  • The first sightings of such phenomens were called ELIZA effect. In 1966.

  • Yeah, this is what the "(2022)" in the title was trying to tell you.

  • It is interesting - and scary - how shallow the roots of our common sense can be.

  • Speaking of things that robots should do:

    Those things, Pinker says, include dangerous and boring occupations, and tasks around the house, from cleaning to child care.

    I have the feeling that people paying more attention to their addictive-by-design smartphone than to their baby might have really negative consequences.

  • This reminds me on the reports that some native American people thought that taking a photography of them would rob them of their soul.

    Or that many things that doctors do today as a matter of routine would have left them being burned as a witch in earlier times.

  • Good names matter.

    If you don't refactor codebases continuously and consistently(!), the'll become a total mess over time. I've worked recently with code bases that still use DOS character encodings common before 2000 or so.

    If something is purely local, in a single process, it is easy to change. But the more stuff it touches, the more difficult and laborious it gets. On the extreme end, there are things like network protocols like IPv4 which are almost impossible to get rid of.

  • Scheme does not demands immutability like Clojure, but it prefers it

    I'm not sure what "prefers" means in this context; do you mean it "defaults" to? Rust in example doesn't "demand" immutability, it just defaults to it.

    In Clojure, all standard data types are immutable. (Except Java arrays, which are accesible; Clojure's vector type is immutable too). If you need mutable containers, there are transients, which do have methods for mutating access. But these need to be "frozen" into normal collections before they are e.g. returned from a function; their scope is strictly local to a function.

    Schemes are a bit more liberal, you can modify variables in Scheme but it is not idiomatic. Like in Clojure, recursion is often used over iteration. Also, e.g. in Racket, you have a lot of things like list conprehensions or dictionary comprehensions in Python.

    Common Lisp is even more liberal; one can use a purely functional style but it wholly depends on own discipline.

    I had looked into Clojure for a while, but I don't like Lisp.

    So, Lisps might not be your cup of tea; Scala is pretty close in these aspects.

    But Lisps are fantastic languages; Minimalist, very expressive, very performant implementations like SBCL or Guile, and run on many kinds of substrate, like the JVM (Clojure, Kawa, Armed Bear), native/POSIX(SBCL, Guile and many more), JavaScript (ClojureScript), GraalVM (babashka), the Python bytecode machine (basilisp), and so on.

  • I linked to the top search result.

  • It has for strings and tuples, which are immutable.

    If you want your mind blown a lot more, try a bit of Clojure, with its persistent data types for collections like lists, vectors and dictionaries, and fantastic concurrency support. It is a class of its own.

    And if you want to combine these principles for calling Rust, using Racket or Guile might be nice - Scheme does not demands immutability like Clojure, but it prefers it, and the lispy languages have a close relationship with Rust's predecessor OCaml. And they can call into Rust code via its C ABI.

    (Also Guile and Racket have a bit less library support than Python, but Guile has a great package manager, Guix, and good access to POSIX interfaces.)

  • nobody is recommending to do everything the LLM says.

    In theory, people ought to check every LLM output. This collides with reality in different points;

    • people are lazy and being diligent just passively checking results is hard - and can be very tiring
    • people are under pressure to work faster
    • if they really check everything, the result is often slower.

    As a result, careful checks of each result won't happen.

    I know that by experience because I have a coworker who uses LLMs heavily. I am relying on interfaces he should provide and he is often not able to describe them in an usable way. Thinks that should take a day or two often take many weeks.

    You could argue it is a competence problem, so maybe yes but LLMs apparently augment such problems.

    Do you think you can’t recognize whether a solution would be a better or worse fit when recommended by either an LLM or a person if done “confidently”?

    We evaluate suggestions from people differently. For example, we use cues like use of language, certificates, reputation, personality, prior experience with them, and insitutions to evaluate their competence - and we trust then, with a reason. You won't go to a barber shop and ask a random person working there for a stomach surgery.

    LLMs are more like a surgeon with fake certificates, using language from medical textbooks.

  • It’s much less limited than you are in its range of knowledge about algorithms and design.

    You can't use AI for things you do not know well. It will happily suggest total bullshit in the most confident tone.

  • But it can generate rather complex parts of an application quite well and much faster than you can.

    Do you mean just the typing, or including thinking, designing, writing up, inolementing, testing and so on? Human developers spend less than 10% of their time typing. I think for a kernel it are less than 5%.

    The thing is - you get your code faster, but need more time for testing.

  • Not all LLM generated code is slop. There are certainly good ways to use LLMs and that seems to be what this talk is about - responsible LLM usage.

    Iff you check and revise the generated code carefully. But if you have ever worked with legacy code, you'll know it is more effort than to write the code yourself. So, I just doubt people will do that, if it only means more work to get the same result.

    So, people won't check the LLM output.

    And because of that, it will have more errors.

  • I’m also interested into some D alternatives that’s not Rust (🤮🤮🤮🤮🤮 - no I’m not a Lunduke fan, but a gamedev, also no “const by default” languages!),

    "Const by default" is good style BTW.

  • That's actually a disadvantage of Rust: Because the Rust compiler is written in Rust, it is hard to bootstrap on new platforms. Which is for a systems language used to build kernel device drivers a serious limitation, and also makes it harder to tackle Thompon's "Trusting Trust" problem.

    Better to compile the new language to C first, which compiles and runs even on a smart lightbulb.

    This does work well. It is how C++ was created, and even some Lisp implementations go this way.

  • What the hell are they doing in bugfixing an UI bug, when they are “not qualified” to write a test for it. Anyhow, not competent enough for the codebase you’re working on - check.

    Does the name "Dan Luu" say anything to you? Do you know his blog ?

    In general, for Dan Luu I wouldn't assume he is not competent enough.

    And besides that, what is the point of LLMs / GenAI if you need to be an expert in everything it touches to handle it correctly? If you are an expert, you can already do it yourself.

    Also, if one needs to be an expert in every topic to get good or even acceptable results, this creates more doubt that the "intelligence", "reasoning", and "capabilities" of these things are in reality the intelligence of the user, since he does the real work of discerning fabrication and accidental good output.

    Reminds me on that old story of the smart horse "Hans" which could do math, indicating the result with is hooves. But it turned out he could do it only when his owner was around - the horse had learned when his owner agreed with the result and indicated that unconciously.

  • The mistake is in assuming the AI is perfect and will be correct all the time.

    If you’re relying on it to be correct and not verifying its output, you’re doing it wrong.

    I think unless you are a total beginner, proper verification will frequently take about as long, or longer than writing it yourself.

    Like it's harder to read even good and correct legacy code, than to write new code.

  • Europe @feddit.org

    Leaked Car Industry Paper: Carmakers’ EU Demands Would Cut EV Sales In Half

    cleantechnica.com /2025/10/09/leaked-car-industry-paper-carmakers-eu-demands-would-cut-ev-sales-in-half/
  • Europe @feddit.org

    Trove of surveillance data challenges what we thought we knew about location tracking tools, who they target and how far they have spread

    www.lighthousereports.com /investigation/surveillance-secrets/
  • Programming @programming.dev

    Beyond the AI Hype: Guido van Rossum on Python’s Philosophy, Simplicity, and the Future of Programming.

    www.odbms.org /blog/2025/10/beyond-the-ai-hype-guido-van-rossum-on-pythons-philosophy-simplicity-and-the-future-of-programming/
  • Programming @programming.dev

    What's Functional Programming All About?

    www.lihaoyi.com /post/WhatsFunctionalProgrammingAllAbout.html
  • Programming @programming.dev

    Software Quality Collapse

    techtrenches.substack.com /p/the-great-software-quality-collapse
  • Programming @programming.dev

    Microsoft 365 Copilot's commercial failure

    www.perspectives.plus /p/microsoft-365-copilot-commercial-failure
  • Programming @programming.dev

    Wine 10.16 released - run Windows applications under Linux

    gitlab.winehq.org /wine/wine/-/releases/wine-10.16
  • Programming @programming.dev

    Inside the Volkswagen emissions cheating software

    lwn.net /Articles/670488/
  • Programming @programming.dev

    Discussion between John Ousterhout and Robert Martin ("Uncle Bob") on "A Philosophy of Software Design" and "Clean Code"

    github.com /johnousterhout/aposd-vs-clean-code/blob/main/README.md
  • Programming @programming.dev

    AI Coding Is Massively Overhyped, Report Finds

    futurism.com /artificial-intelligence/new-findings-ai-coding-overhyped
  • Programming @programming.dev

    Kroah-Hartman explains EU Cyber Resilience Act for open source

    www.theregister.com /2025/09/30/cyber_reiliance_act_opinion_column/
  • Linux @lemmy.ml

    Kroah-Hartman explains Cyber Resilience Act for open source

    www.theregister.com /2025/09/30/cyber_reiliance_act_opinion_column/
  • Europe @feddit.org

    Polish Train Maker Is Suing the Hackers Who Exposed Its Anti-Repair Tricks

    www.ifixit.com /News/112008/polish-train-maker-is-suing-the-hackers-who-exposed-its-anti-repair-tricks
  • Programming @programming.dev

    Linus Torvalds on how and when to maintain a clean git history (2009)

    www.mail-archive.com /dri-devel@lists.sourceforge.net/msg39091.html
  • Programming @programming.dev

    Madeleine Mortensen: Jujutsu For Busy Devs (Part 1)

    maddie.wtf /posts/2025-07-21-jujutsu-for-busy-devs
  • Programming @programming.dev

    We Asked 100+ AI Models to Write Code. The Results: AI-generated Code That Works, But Isn’t Safe

    www.veracode.com /blog/genai-code-security-report/
  • Programming @programming.dev

    Daniele Procida: My favourite German word (On documentation and knowledge organization)

    vurt.org /articles/my-favourite-german-word/
  • Programming @programming.dev

    Old Code Gets Younger Every Year. The threat of decaying technology looms, by Marianne Bellotti

    medium.com /the-technical-archaeologist/old-code-gets-younger-every-year-3bd24c7f2262
  • Programming @programming.dev

    Introduction - Steve's Tutorial on jujutsu, an alternative front-end to git

    steveklabnik.github.io /jujutsu-tutorial/introduction/introduction.html
  • Programming @programming.dev

    Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

    metr.org /blog/2025-07-10-early-2025-ai-experienced-os-dev-study/