I've had the latter with Gemini in Android Auto. In fact, my scenario was even worse.
Me: "Send a message to <wife>".
Gemini: "OK what's the message?"
Me: "Can you bring Tylenol I'm having a headache?"
Gemini: "I'm sorry, I cannot help with that. If you need medical advice..." <-- or something to that extent.
Up to this point, I thought when Gemini would prompt for a message, it would simply accept whatever I said essentially as plain text - and maybe with the new Rambler feature on Pixel phones it may cleanup my message slightly.
But now I can see scenarios where Gemini would possibly need to parse my input. And it should have been obvious since I would often say things like "cancel" and I never questioned it.
One misconception I had was that with value objects we could simply use `==` for comparison. But it looks like there's lots of gotchas with this especially if the value class has String fields for one or more fields. For example, comparing two ZonedDateTime value objects may be fine with == because I believe the JDK team ensured the Strings that represent the ZoneIds are always the same reference.
We have tons of wrapper classes in our codebase which seem ideal as value objects. For example, instead of passing around "String emailAddress", we have a wrapper class EmailAddress. While we can now make our EmailAddress class a value object, we cannot do "==". Unlike ZoneId in which there's a fixed set and you can intern all ZoneIds in the string pool, email addresses are unique and trying to intern all email addresses would be a bad idea. So it seems like using .equals is here to stay even for these types of basic classes.
There's always this comment on every Java post. I expect the average HN member to be someone on the team who is either leading their projects or plays a significant role in driving the design of the software. You set the culture for your own projects. I've lead the development of some massive Java apps and all have had simple and clean architecture. I've never seen IStatusChangeEntityCreationManagerFactory or anything like it even once in any of my projects, but perhaps that's because the last time I used Spring was ~17 years ago. Most of my recent projects are using Quarkus, which is still a relatively large framework. But our codebase is designed in such a way that we're not tightly coupled to Quarkus.
I have seen a surge of overly complicated PRs now that we're in the AI era, but it's our job to be the gatekeeper and push back on this crud from entering the codebase. And that's likely true of any language.
I wish I did something valuable. Instead I spent most of my time writing kick scripts for #warfactory pretending I was some l33t coder... I still have some of those scripts saved somewhere!
I have a feeling you're in the minority. I've been using computers for 35+ years and I feel like I still don't understand OK/Apply/Cancel buttons. I still click Apply before clicking OK even if I know it's unnecessary.
Plus, I don't believe Cancel reverts changes the user made if they clicked Apply already. So your suggestion would go against how the UX of OK/Apply/Cancel has historically worked.
Yeah, me too. The Amiga had a good idea with its Preferences programs (i.e. settings or options) - a "Use" button, which only saves to memory, separate from the "Save" button, which also saves to disk. So even if you make a mess of it, just reboot. Of course, in those days we were used to rebooting often, so that wasn't an issue. But if the idea had caught on, then by now we'd probably also have a "Revert" option that copies from disk to memory and activates it.
Back in the early dial-up era, when teachers were not tech-savvy, I went online and found a paper exactly matching what I was tasked to write about for a homework assignment. And I regrettably submitted it as-is with no changes. I guess I knew it was cheating, but I likely also thought I was being incredibly clever as I had not heard of anyone ever doing that before. However, another student in the class submitted the same exact paper. I received an A and he received a C.
The teacher likely didn't know that he used to be my best friend growing up, and at some point was more knowledgable with computers than me. He introduced me to things like IRC. But he became one of the most popular kids at school and started distancing himself from me.
After getting our papers back, he came over to brag about how he found his paper online and that's how we discovered we submitted the same exact essay. At that point in time, I thought the teacher must have assumed he copied from me. But I think your explanation is likely more plausible. I guess the teacher just skimmed the papers and graded based on our expected grade.
We have a medium sized Quarkus app (~200kLOC) and Quarkus has been fantastic. Startup in JVM mode for our app is around 10 secs. Not blazing fast - but likely much faster than a typical Java enterprise app. I'm sure a few of those secs are spent doing things like pulling authz policies from github or due to having several thousand hibernate entities.
I wish we had a dedicated InstallShield engineer! I had to design and burn my own discs for the desktop apps I built. And for some reason, the LightScribe drive was installed on the receptionist's computer. I have no idea why, but I was a new hire and I didn't question much.
I believe every UI developer that has used frameworks like Swing has reached a point where specific user interfaces, even those that look trivial, become too complex primarily due to things like event handlers. Trying to figure out a simple thing like why a radio box is enabled and is marked dirty may require long debugging sessions where one event handler for component A triggers another event handler for component B, which triggers another event handler, etc. And before you know it, 50 events were triggered just during the initial mounting of the UI. Making sense of it all is maddening.
And then said developer does what they think feels right: "I have my state and I simply want all the fields to reflect my state". So they try and rewrite the component into some sort of mini immediate-mode style component. All of the event handlers get wired up a single "layoutComponent" method that tries to call all the UI component setters based on the current state with all the problems you alluded to. I know I've done this type of things numerous times before going back all the way to my first internship, well before React was even a thing.
I think modern frameworks solve the reactivity issue this well enough, that it really doesn't matter if the underlying framework is not natively reactive. I will say though that I've primarily used Vue.js where most state is relatively local and we don't try to re-render the world on every input. I think part of the problem with modern dev is likely that React has become the default instead of a simpler framework like Vue.
That's true. Events are the WORST thing about GUI programming. They're so convenient and so undebuggable it almost feels like a trap.
Ironically, in most cases events are only used by one object, but you always want to consider the possibility that two objects will want to observe the same event, so now you need an entire event dispatching class, and then you'll want observable properties, and the nail on the coffin is going to be observable lists. When you reach that point, one event triggers another, which changes a property, triggering another event, and so on and so on. You are 5 layers deep into event callbacks. The call tree just has the same "callCallbacks()" method over and over again.
Bugs start happening because of the order in which callbacks are called becomes important, so now you need a way to give some callbacks priority over others, or make them happen after all normal callbacks were called. One callback destroys an object which has callback on the event that destroyed it, so you're going to need a wrapper around your callbacks that gets notified when callback's object is destroyed to change its reference to null in order to avoid executing code on the destroyed object if this happens while iterating the callbacks in the event dispatcher. Sometimes calling callbacks in wrong order is a performance hit, when it doesn't just get stuck into an infinite loop and you run out of stack.
I wonder if there is GUI programming paradigm that solves all of this or that you can call the "best" one. Maybe it's reactivity, maybe not. Who knows.
Me: "Send a message to <wife>".
Gemini: "OK what's the message?"
Me: "Can you bring Tylenol I'm having a headache?"
Gemini: "I'm sorry, I cannot help with that. If you need medical advice..." <-- or something to that extent.
Up to this point, I thought when Gemini would prompt for a message, it would simply accept whatever I said essentially as plain text - and maybe with the new Rambler feature on Pixel phones it may cleanup my message slightly.
But now I can see scenarios where Gemini would possibly need to parse my input. And it should have been obvious since I would often say things like "cancel" and I never questioned it.
reply