Why was 'can a user request a different email' not literally the first test that comes to mind when making something like this? Do they not test anything because the scale is too big?
The nature of the invention is for people to relieve themselves of the burden of having to use their minds. And while there will be exceptions, (including, I'm sure you: the person reading this comment,) the vast majority of people are hungry to use AI in that spirit of being able to be lazy.
Lazy can be a good thing. Since time and attention are finite and not fungible, it allows you to do something else. There's a reason we're all too lazy to do long arithmetic with pen and paper, instead relieving the burden of using our minds by outsourcing to spreadsheets and calculators. Not only does it allow us to think at a higher level of abstraction, but it also means we can take our kids to the park more often.
> The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone’s) future time, and will happily dump more and more onto a layercake of garbage.
which I think is interesting, albeit somewhat tangential to the current discussion.
Unforseen side effect: I used AI to write so much code that now I struggle to have a good mental map of it, so I became lazy without having an intention to do so. Fun times!
Because software professionals are conflating simplicity of user experience with simplicity of dev experience.
During development they were likely not thinking of the user experience, nor even the support agent experience, but on their development experience, they asked the LLM to develop the chatbot, and it worked, and the speed was documented and reported upstream so that shareholders invest, if there is any forethought it would go against the narrative of AI becoming the engineer or 100xing productivity.
Ironic to use AI writing to complain about AI search results to advertise your product. But to the point, being an old school firefox user I still have separate address and search bars. My main search engine on my PC is 'google (web only)' which opens directly to the web tab which only has result links. I'm dreading the day they remove it as a feature.
We have been getting a ton of LLM generated essays talking about how bad LLMs are. It happens so much that it feels like a new kind of engagement bait.
I haven't kept up with cljs in a long time but I remember it originally being pitched as just clojure on js--at least I think that's how Rich originally described it. My impression was it was just supposed to be, as much as possible, another runtime. This change seems to add in features that are exclusive to cljs and actually conflict with clojure itself as await is already a keyword in clojure.core. Have the two impls diverged over time, or was this feature specifically important enough to the users to overcome the differences?
Amazon sidewalk and related technologies will likely allow devices to bypass needing your network at all in the future. The last TV that doesnt support these features will probably be my last.
It does seem to introduce a lot of complexity for its own sake. This kind of workflow only survives on the absorb command and like you said it doesn't really cover all the interplay of changes when separated. It's a more independent version of stacked diffs, with worse conceptual complexity.
After hearing about a workflow that used absorb I wrote a simple git version I called 'squash-index' in about 15 lines of bash in a few minutes. Since git allows subcommand extension I just made an executable 'git-squash-index' and everything worked as if it was a builtin subcommand. I get that initial ergonomics are important for new tools but if the only novel feature is reified merge conflicts it doesn't really seem worth making the switch. No one needed to evangelize git to people like myself who had worked with a variety of old version control systems (cvs, svn, etc). It was just obviously much, much better. jj seems like it streamlines certain things, and might be worth learning for new users who have no git experience, but doesn't really differentiate itself enough for people who've been using git for a long time.
I miss the text only reading era. This is a blog and should not need to have JavaScript enabled to render text to a page. I would rather not have to be annoyed by flavor of the month duplicate scroll bars, cookie banners, newsletter pop-ups 5 seconds in, scroll to the top pop-ups, idle overlays, highlight helper bars that break copy paste, etc. This blog didn't have all of those but had some. I'm sure the metrics look great because I had to load this page four times. First initially, and then disabling JavaScript and realizing it doesn't load anything at all. A third time re-enabling JavaScript and then deleting all the annoying elements, and then a fourth time to make sure my cosmetic filter is applied correctly. 4x the interactions! Must be doing something right.
I appreciate the sentiment, but this remark is far too common here. It does not address the content of the post and could apply to any submission from LessWrong. The author of the post has made none of those technical choices.
You are not alone! There is in fact a whole dedicated rule about this on hn:
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Clearly doesn't really move the needle much but sometimes it helps to tap the sign at people.
Charitably, we are all on our own timelines of getting to HTML zen, and its hard not to shout from the rooftops when it clicks for you and you have your plain text RSS setup on Gnus all chugging along nicely.
Funny, I assumed it was a subtle critique of how change always elicits haters. Though now I realize it was an honest non-sequiter to complain about his pet issue?
Agreed. When I redid my portfolio site recently, I specifically sought out a static site generator that wouldn't require JS, and picked a basic no-frills prebuilt theme. But I found out the theme didn't handle disabled JS gracefully.
The fussiest part of the whole site setup was getting light/dark mode to work in what I thought was the most obvious way. To me, if a website has light and dark modes, it should default the user's device's preferred color scheme, and as an added bonus for users with JS enabled, you might also have a toggle button. But by default, the theme just started in light mode no matter what until you clicked the toggle button, and they also didn't bother to make the button hidden if JS is disabled.
Same with the button for the built-in search feature; it would be visible even if it couldn't work. It's not that it was terribly hard to modify the theme and fix this – add `class="nojs"` to the body HTML, add a JS one-liner to remove nojs, and add a CSS rule to hide the buttons if they're inside `body.nojs`. It was just disheartening to see that this was the theme's default. Anyone making a website these days has to make extra effort to support what should be considered normal browser behavior.
A benefit to using the currying style is that you can do work in the intermediate steps and use that later. It is not simply a 'cool' way to define functions. Imagine a logging framework:
After each partial application step you can do more and more work narrowing the scope of what you return from subsequent functions.
;; Preprocessing the configuration is possible
;; Imagine all logging is turned off, now you can return a noop
(partial log conf)
;; You can look up the identifier in the configuration to determine what the logger function should look like
(partial log conf id)
;; You could return a noop function if the level is not enabled for the particular id
(partial log config id level)
;; Pre-parsing the format string is now possible
(partial log conf id level "%time - %id")
In many codebases I've seen a large amount of code is literally just to emulate this process with multiple classes, where you're performing work and then caching it somewhere. In simpler cases you can consolidate all of that in a function call and use partial application. Without some heroic work by the compiler you simply cannot do that in an imperative style.
I asked gemini a few months ago if getopt shifts the argument list. It replied 'no, ...' with some detail and then asked at the end if I would like a code example. I replied simply 'yes'. It thought I was disagreeing with its original response and reiterated in BOLD that 'NO, the command getopt does not shift the argument list'.
Gemini by default will produce a bunch of fluff / junk towards the very end of its response text, and usually have a follow-up question for the user.
I usually skip reading that part altogether. I wonder if most users do, and the model's training set ended up with examples where it wouldn't pay attention to those tail ends
Google had a feature in gmail for a long time that automatically sorts your email into categories like Promotions, Social, Updates, Forums, etc. It was automated and fairly effective imo. If you try to disable the 'smart' features they will then disable this categorization retroactively and dump thousands of emails in your inbox and then nag you about turning it back on.
reply