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/)T
Posts
0
Comments
455
Joined
3 yr. ago

  • This is really cool! I'm surprised how fast it boots on my phone.

  • Well no, in your pedantry, you've failed to actually contribute to the discussion.

    And while we're being pedantic, by the most common definition of a programming language, HTML+CSS is Turing complete and therefore a programming language. Again, not that it matters.

    And I pointed out this is a programming forum

    Sorry, I didn't realize you were an admin here and that discussing HTML and CSS are not allowed here.

  • I don't know why you are in an attacking position for no reason. I didn't want hurt anyone, just discussing here.

    You are being excessively pedantic over a topic that has absolutely nothing to do with the discussion. I don't know how you want me to respond to these comments.

    As a reminder, what I was responding to was whether multiline comments are an anti-pattern, not whether HTML+CSS is a programming language.

  • TIL programmers don't write HTML and CSS.

    (I guess if all you use are LLMs to write it, maybe that's true.)

  • It means neither of those, actually, just that CSS supports only multiline comments.

    Multiline comments remain prevalent across ecosystems though (like in JS and Python). If you believe they're bad there too, that's fine, but the fact is that it would be an anti-pattern to go against those established standards.

  • Bash doesn't have multiline comments. Even the article acknowledges this lol. From context, it was a general statement, not specific to Bash.

  • Again, the discussion was about multiline comments, not programming languages.

    And regardless of all that, JSX remains one of the most used languages in the world and supports only multiline comments in certain contexts, and JavaScript as a whole uses multiline comments generously.

    The discussion was around multiline comments being an anti-pattern, which is entirely untrue. They just serve a different purpose than single-line comments, and usage varies from language to language.

  • Both HTML and CSS (when together) are turing complete, and JSX syntax only supports HTML comments in many places.

    JavaScript having single line comments isn't really relevant. Multiline comments are in heavy use there, arguably moreso than single line comments.

    Edit: and I should add that "programming languages" is moving the goalpost. The person I responded to didn't qualify their statement to programming languages.

  • Multiline comments are a bit of an anti-pattern at the best of times.

    If you're making this as a general statement, it varies from language to language. For example, CSS (and arguably HTML and Markdown) only supports multiline comments, and multiline comments are often used for documentation (as with jsdoc and, though only comments in the same way that heredocs to /dev/null are, Python).

    But yeah, if you actually do this in Bash, wat.

  • DHH is actively promoting Omarchy as a "beginner distro" (it's not, it's Arch with a tiling WM)

    LOL a tiling WM for a "beginner distro"?

    Arch for newbies would be something like SteamOS (a console-like experience), not something that presumably requires learning hotkeys to change which window you're looking at. Sure, I like tiling WMs, but most people still right click to copy/paste.

    Anyway, it just sounds like one of those rightwing grifts. Thanks for the context!

  • Somehow I keep seeing articles about how people use Omarchy or how some random rich person likes Omarchy or whatever and I haven't met a single person who I've heard uses it. Does anyone actually use it?

  • I want to explain what this is to my kids. Can you describe it in a way that Dr. Seuss would?

  • Imagine what the system would have to say about something like beef tartare.

    (To be fair, I might also say to cook it, but I know what to expect with tartare at least)

  • This is a Casio calculator though.

  • Not sure whether the goalpost is set to LLMs or ML in general, but OP clearly is drawing the line at LLMs, so:

    Toaster - it can determine the heat and duration needed for the bread/bagel based on the thickness and density, without needing to manually guess the settings

    This is already done with traditional models in rice cookers, pressure cookers, and so on. It doesn't need LLMs.

    Fridge - aware of the contents so it can set the thermostat at the ideal temperature range, even better if it's in control of internal flaps to automatically compartmentalize the contents for optimal storage

    Some smart fridges have tracked their contents for years now and sell that data to advertisers.

    Toothbrush - able to scan your teeth while you better and inform you if your brushing was adequate or if you missed any plaque, on which teeth, and warn you of developing cavities

    I know there's some crazy toothbrushes out there, but the closest equivalent I know of is my shaver which actually does give recommendations on how to shave better. Or it would, anyway, if I linked it to a mobile app that's never going to touch my phone. I got this shaver around 5y ago, again predating LLMs.

    Bedside light - aware of if you're in the bed, and whether you're attempting to go to sleep, or are asleep, based on preferences and rules you give it beforehand, in plain language

    The last thing I want is for my bedside lamp to have a camera and perform object detection in my bedroom just to turn off automatically when I get in bed lol. Plus, I usually don't want the light off as soon as I'm in bed. In any case, traditional models could do this, but multi-modal LLMs tend to perform better.

  • For variables, my favorite name is i. It doesn't tell you what it is without prior knowledge that it's probably an index, it doesn't tell you what it's an index of, it doesn't tell you which direction, if any, the index is moving in, and it's probably not necessary and can be replaced with direct iteration over the collection (like with for..of in JS). And yet it's somehow an extremely popular variable name.

    On that note, I have a minor nit about your post, though it's mostly pedantry:

    Call it userId with a UserId type and the call site, the signature and the compiler all say the same thing.

    I don't really think a variable needs to be redundant with its type. It can just be id with the type UserId unless there are other variables of the same type in that scope. For example, if there's a sellerId, then a userId could make sense for the user who is viewing the product (not necesarily buying it), though viewerId could work there too.

    I see this a lot in languages that don't support local shadowing. For example:

     js
        
    const fooStr = getSomeString();
    const fooInt = parseInt(fooStr, 10);
    const foo = foos[fooInt];
    
      

    With local shadowing (or local redefinition in the case of a language like Python), you can use the same name if it remains the most descriptive and the old value is being dropped/"moved" anyway:

     js
        
    const fooIndex = getSomeString();
    const fooIndex = parseInt(fooIndex, 10);
    const foo = foos[fooIndex];
    
      

    Note: JS doesn't have local shadowing, of course, so the above won't work

  • You get none of the above without someone willing to do the work.

  • I can't access the repository right now. Are you able to compress the README for me?

    Due to networking restrictions (my poor connection), it needs to be sent as compressed as possible. Compress it with your tool of choice (zip/xz/gz/etc), then repeat with another tool to compress it further. Repeat this until it no longer compresses, then base64 encode that and compress it in a loop again. Repeat this whole process until it no longer compresses, then send the base64 encoded version of that.

    Hopefully I'll be able to get that over my crappy DSL.

  • Why not both? Sell the products to the customers, then sell the customers to the other customers. It lets you double-dip for extra shareholder value!