Incoming wall of text, because this is topic that hits close to home for me, and I've spent a lot of time in the last few years exploring it. So, knowing absolutely nothing about you or your life or how it compares to my own, I'll proceed.
I personally agree with you. I want that municipal finance nerd to speak up and tell me that as well. I think I get a little jolt of endorphins whenever I learn something new, so for me there's actually almost a physical draw to people who can give that to me. I wonder if it's the same for you.
I think you're describing a position of resignation on your part: you've almost sort of given up, and tried to convince yourself that you're ok obliging people in the surface level conversation that they seem to want. And I suspect, resigned yourself to the fact that most people you meet day-to-day won't be able to give you those little endorphin boosts.
I struggled on this path myself. First: recognizing that you seem to want more from conversations than most other people are willing/able to give. Second: finding that your mind, which naturally draws you to learning new information, is not the mind that everyone has. Third: developing almost a sort of disdain for people who you find do not meet your imagined bar. Fourth: identifying the disdain and feeling bad about it. Fifth: telling yourself that ok, you'll just give up looking for it and also you'll stop being disdainful towards others for not being able to give it.
The sixth part is the first big leap: realizing that it's not that you want more from conversations, you want different. And what is engaging for you is not necessarily engaging for someone else. And that neither of you is righter or wronger in that.
The seventh, hard part that I suspect you may not have gotten to yet. You can't expect that people can give you the kind of connection you're looking for, that they can scratch that itchy brain of yours, without first allowing yourself to truly believe that their mind is just as deep and rich as your own, and accept that it's just rich and deep in different ways. The challenge, then, is to stop asking yourself "what is it that I have that all these other people don't seem to have" and start asking "what am I missing? what are all these other people experiencing that I am not?"
If it helps, you can consider it an intellectual challenge. Try to really empathize, imagine what it's physically like to exist in their body. Force your brain to consider the fact that in this moment, in this conversation, their experience may actually be richer than yours - just in ways that you can't, by default anyway, see.
I respectfully submit that your neat categorization of interactions into those three profiles may reflect a gap in your understanding of others. Namely, that your definition of what makes a "good faith" conversation may not be the only one, nor the only correct one.
The vibe that people care about - that's the unspoken channel in any conversation. Physical, emotional, thoughts that don't get said. Perhaps to the one you're talking to, a good faith conversation is one that cares about or prioritizes the vibes.
Author here. This is an exposition on my journey trying to figure out if and/or how PDFs can have simple interactivity added in a portable way. The answer (spoiler) is ...sort of. I learned from some other discussion on this that grey-hairs may have already known this, but it was news to me, and I thought it worthwhile to write up.
> the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this.
This does not match my experience. I do a lot of AI-assisted coding at this point, and what I've seen is that when the AI is asked to extend or modify existing code, it does a much better job on clean, well-structured and well-abstracted code.
I think the reason is simple, and tracks for humans as well: well-structured code is simply easier to understand and reason about, and takes a smaller amount of working-set memory. Even as LLMs get better with coding, I expect that they would converge on the same conclusion, namely that good structure + good abstractions make for code that is more efficient to work with.
I love these optimization tales. Memory throughput bottlenecks (extremely common, perhaps moreso than they seem) are my favorite to tackle - there are frequently some juicy optimizations that can apply there.
Do model weights have any spatial locality that can be exploited? If so, there are some more general pre-compression techniques that might be interesting to try, e.g. bitshuffle is one I've worked with (https://github.com/kiyo-masui/bitshuffle).
Another fun fact: in some scenarios (depends a lot on CPU and memory characteristics), gzip+memcpy+gunzip can be faster end-to-end than just memcpy. I forget where I first heard this but my familiarity comes from the blosc compression library.
Like pretty much everything else about human beings, I expect most of us exist at a point on a spectrum rather than belonging to this type or not.
I think the engineering mindset comes from a place of curiosity. I don't agree that there is anything fundamentally different about the person who chooses to be an engineer versus not, I think everyone just has a different mix of characteristics and preferences.
For me, the act of creation is the compelling part. Sometimes that's writing code, other times it's seeing the fully-formed thing come into being. For the latter, LLMs can certainly help me do more, or at least take care of some of the menial stuff like writing test cases while I do more interesting things like think about strategy/architecture.
Just make sure you're reviewing your LLM's code as if you were a colleague's!
Well, IMO there's not much reason for an LLM to be trained to produce machine language, nor a functional binary blob appearing fully-formed from its head.
If you take your question and look into the future, you might consider the existence of an LLM specifically trained to take high-level language inputs and produce machine code. Well, we already have that technology: we call it a compiler. Compilers exist, are (frequently) deterministic, and are generally exceedingly good at their job. Leaving this behind in favor of a complete English -> binary blob black box doesn't make much sense to me, logically or economically.
I also think there is utility in humans being able to read the generated output. At the end of the day, we're the conscious ones here, we're the ones operating in meatspace, and we're driving the goals, outputs, etc. Reading and understanding the building blocks of what's driving our lives feels like a good thing to me. (I don't have many well-articulated thoughts about the concept of singularity, so I leave that to others to contemplate.)
Some random thoughts, since I've had a similar train of thought for a while now.
On one hand I also lament the amount of hardware-potential wastage that occurs with deep stacks of abstractions. On the other hand, I've evolved my perspective into feeling that the medium doesn't really matter as much as the result... and most software is about achieving a result. I still take personal joy in writing what I think is well-crafted code, and I also accept that that may become more niche as time goes on.
To me this shift from software-as-craft to software-as-bulk-product has some similarities to the "pets vs cattle" mindset change when thinking about server / process orchestration and provisioning.
Then also on the dismay of JS becoming even more entrenched as the lingua franca. There's every possibility that in a software-as-bulk-product world, LLM-driven development could land on a safer language due to efficiency gains from e.g. static type checking. Economically I wonder if an adoption of a different lingua franca could manifest by way of increasing LLM development speed / throughput.
It's been a decade+ since I used to catch the Green line at Park St, but at that time it was the noisiest, squealiest station that I regularly used. Not surprising to learn that parts of that station are left over from the 1890s.
IMHO there's no gatekeeper of what the "real" web is or should be. It grew organically - regular people building things they liked or needed. It's certainly more of a life necessity than it used to be, but that happened organically too.
I know there are strongly held opinions about this, but I for one see no reason why the "application web" can't peacefully coexist, and interlink with, the document web. In my opinion it therefore makes sense to allow for different models for the application web, ones that do not revolve around a document.
On the other hand, if we're just bashing on javascript being the lingua franca of the web, that's a train I'll happily board!
I've got a pretty large flutter app in production, using just the flutter-provided building blocks like ValueNotifier, ListenableBuilder, InheritedWidget, etc. It has scaled quite well for me.
The main issue IMHO with many of these boilerplate-reducing packages is that they feel like one-way trips. Most of them require a change to widget inheritance, and they all have slightly different syntax and semantics for wiring things up to state changes. This means if you get a few years into a project, migrating away from the package you chose at the beginning will probably be very difficult.
So while the quick example in the readme of this package looks simple and understandable, locking in to a third-party library makes me nervous, especially if the main benefit is just fewer keystrokes. Does anyone have experience or informed opinion here that would be willing to chime in?
I still haven't found a way to coax MathML into looking the way I want it... Even using the same fonts (like Computer Modern or its descendants) there's still something not quite the same as LaTeX-drawn math. It's a nitpick but noticeable for me.
Been a happy customer of Fastmail for ~10 years now. Nice web and mobile interfaces. I've never been impacted by downtime in that time (to my knowledge).
Ah, ok - thank you for elaborating on that. I don't actually have that type of interactivity at the moment, though you're right in saying all the information is there in order to make it happen. I also like your idea of changing between the states via some collapsible menu. In theory all of this could be achieved just by building on what's already here. Do you mind sharing what sorts of things you might use this for?
Glad to hear dark mode was the other issue :-). I'll investigate further, it's probably just a matter of a flag not being propagated properly during the scene change.
Thank you very much for all this feedback! I really appreciate your consideration.
For your note on different states for screens. Can you elaborate or give an example? I'm quite interested in this mode that you're describing.
The ellipse issue sounds like snapping getting in the way. It's on my list to come up with a better heuristic of when to apply snapping or not. One example of an idea I have here is to incorporate some hysteresis effect - essentially examining the local history of mouse movements when deciding to apply snapping or not. Right now each mouse movement is treated independently.
Also, were you in dark mode? It's definitely not intended that the whole screen should change color - a popup should dim the content behind. The whole screen changing color sounds like a bug and I'll investigate.
This is a great point and not one that I had considered. I suspect I am the same way - scanning back and forth while studying a diagram.
It's possible this tool may be more appropriate for e.g. presentation of info to a mixed audience. Technical people may have questions that can be answered with detail that non-technical people would find distracting, if it were visible on the main diagram. And "presentation" here could be a literal presentation in a conference room, or documenting something on a site that people visit on their own.
You could make the argument in that example that you should create two diagrams, one for each audience. I think that is a valid argument - but I can also imagine maintaining two separate diagrams that present similar information could be irritating.
If you're fond of state machines as an abstraction for system design, I highly recommend reading the Harel statechart paper. It's well-written and understandable. And, it's truly a useful extension of the type of state machine diagrams software engineers typically produce.
Get in touch at: tyler at vexlio dot com
Check out the app, no sign-in required: https://app.vexlio.com/