I don't think it's that people online need to have more unstructured discussion, or "not get to the point" -- it's that there's no real sense of community in a lot of online spaces. Why would I spend a bunch of time idly having Seinfeldian conversations with strangers with whom I have no rapport or continuity? The vast majority of people who will read my social media comments will be completely invisible to me. All the years of commenting and interacting online have predictably resulted in precisely zero lasting relationships.
If the point of not getting to the point is to build trust, then there has to be a relationship in which that trust is invested. Otherwise, not getting to the point is just more invitation for someone to take issue or dismiss what you're saying, to divert the discussion, or to completely miss the actual points you want to discuss.
The trick though is to gravitate towards places where there is a community and where you end up talking to a few of the same people. HN's probably not going to be it, an IRC channel, Discord, forum, etc, where you keep talking to the same dozen regulars is much better.
I had so many good times doing this when I was younger, on IRC and Forums back in the late 90s, early 00s. I haven't had much luck since then though unfortunately.
Any advice for finding the smaller communities? I've been trying to join larger more public communities to make the initial connections with people but mostly I find that they are either ghost towns with thousands of people but no one is active, or they are so active it's just noise that no one is really keeping up with
I think this is both true and untrue. For a long time, I was an AI skeptic, perhaps even a hater. A chauvinist for writing code by 'hand.' But it's become very difficult, as I've gradually migrated to AI-authoring of code, to go back to writing code by hand and retain the same velocity.
Part of this is certainly that my hand-authoring code skills have atrophied, sure, but my workflow has also radically changed. Previously, I would spent a lot of time and focus on a single work item, and only context switch to other tasks whenever I would wait on CI or a long build. It meant that I spent a lot of time understanding one thing at a time, and interruptions (forced context switches) incurred a massive switching cost.
Now, having moved to largely AI-authored code, I find myself necessarily working on multiple threads at the same time. This means I can meaningfully progress each of those threads in parallel, with a much-reduced overhead on context switching, since I don't have my head down focusing on all the details of the work. And if the task really demands it, I can still stop and focus on one thread to sketch out the code manually, think about the concepts more deeply, etc.
It's a very different workflow, and there are certainly downsides, but the upside is that the rate of which I've been able to put up good-quality PRs has measurably increased. It's not quite 2x, and it's certainly not 10x, but it's definitely noticeable. I do understand a bit less, but there was always more work than time to understand things in full detail. I guess only time will tell if that missing understanding was actually vital to the long-term success of my work.
yes that's fine, i have a similar experience. but there is a difference between saying what you did, and the type of AI religious fundamentalism where you got "converted" when truely good AI coding models revealed themselves to you, and then you go around trying to save those who would otherwise be "left behind".
Yeah, the problem with "not fighting it" is that you'll naturally do what feels the best in the moment, and having fun will always feel the best in the moment over doing something boring.
The fall only comes later when all your having fun leads to a lot of not having fun (work piles up, relationships sever, projects fail etc.) I find living in a certain amount of fear of fun is healthy. If I feel like I've been having fun for too long, I've probably been neglecting something important that is going to really ruin my fun later.
I say all this, as I scroll through HackerNews looking for hits of dopamine instead of continuing trying to fix the CI issues that have been paralyzing my work for almost a day now. That's not good to be a fun conversation in my 1-1 if I ignore it for much longer...
pretty sure Krugman himself said his prediction was intentionally pessimistic to counter the hyper-optimism of his peers. and in fairness, he wrote that at the height of the dot-com bubble.
actually, thinking about it more, I wonder if we'll see something similar with LLMs where, the bubble will eventually pop, but the technology won't disappear, and we'll see it quietly improve and integrate further into our lives over time. probably not that wild of a prediction to make, but I do wonder still
Yup, and every time it breaks, you've got to pester someone whose job probably isn't maintaining that thing actively.
I worked at a startup with massive NIH syndrome, once. We even used our own in-house programming language, because it was "better than anything else out there on the market." It did have a lot of nifty features that others don't have: a pretty novel type system, programmatic macros, a built-in build system and other fun bells and whistles -- but also not-so-fun ones like having no syntax highlighter, LSP, or debugger, and having to constantly shuffle around your code to avoid ICEs in the compiler.
The compiler wasn't the product, but we found ourselves fighting that thing more actively than any of the real problems our custom programming language was supposed to solve. The CTO found himself spending all his nights and weekends mostly trying to get the compiler to not explode.
A few years later, after I had long left (for that reason, among many) I heard they switched to Python. Can't imagine how long it took them to get that all rewritten.
> e even used our own in-house programming language, because it was "better than anything else out there on the market." It did have a lot of nifty features that others don't have: a pretty novel type system, programmatic macros, a built-in build system and other fun bells and whistles
A DSL can work, but not for the features you list. Those features you already get from existing languages anyway!
If you need general programming language features like excellent type system, programmatic macros, a build system (doesn't need to be built into the language), etc... then use a general purpose programming language.
I have a DSL for backend/endpoints, and exactly none of those are in my feature list. What it has are things like easy way to specify access-control directives[1], the SQL query to execute, mapping request variables to SQL parameters, mapping SQL results-sets to response fields, etc.
I have another DSL for a test program. Both of those DSLs have specs that's literally 2x screens of bullet points and examples. LLMs can output those DSL programs because the spec for the DSL is so small.
For general purpose programming stuff (while loops, conditionals, etc) my DSLs break out to Python.
A good indicator that you shouldn't be creating a new language for production is when you find yourself implementing conditionals, loops, etc.
===========================
[1] Limit endpoint to specific roles, or members of the same team, or both, or even to the user itself - someone calling `/user/profile/update` should only be allowed if the profile they are updating is theirs, for example.
Ah, but you see, it was a general purpose programming language. A general purpose, functional, optionally-typed programming language, with its own optimizing compiler and build system. In fairness, it wasn't originally developed to be our in-house language, but it was the creation of the CTO.
It was fun while it lasted and I had a lot of fun working on it. But it was really not a good business fit. The programmatic macro system was supposed to allow us to build customer-facing DSLs on top of it, but everybody just wanted Python anyways.
I agree, and I very strongly dislike it, to be polite about it. It contributes absolutely nothing and is an excellent way of hand-waving away literally anything an AI model does. Saying "well people do this too" is a great way to rationalize away anything you can imagine that an AI model would be capable of, because "humans do it too so what's the big deal, guys?"
I can just immagine the response to a headline "LLM chooses mass death: thousands killed in horrific AI accident" being something like "lots of humans have caused mass death too."
Maybe we can think up a (personal) rule we can follow?
A naked "natural intelligences do this too" might be a bit too short to be useful. But if we can add when/where, cite papers, or show ways in which the parallel operates, then it might be useful.
Compare, eg, talking about a robot arm, and someone goes "a natural arm does this too". You can tell about the fact that it has the same degrees of freedom in the same places, or how this pertains to inverse kinematics, or etc...
Same way here, "this happens to be how natural intelligences seem to solve this too! According to Foo, Bar, Baz et al (2026) the gadget is always twiddled beforehand in macaque apes. " or "Same for natural intelligence: I've noticed I use the same general algorithm myself. I've always considered this the correct way to do translation between languages".
--
A more concrete example of a useful answer here.
Natural intelligence does this too! When given the question "explain your reasoning" humans are indeed quite prone to post-hoc confabulation. [1]
It's the grounded portion of a feedback loop searching for the 'why is this happening' thinking. I'd imagine most of my own comments in this area boil down to "GIGO" most of the time.
It's a relevant comment in this instance because we're discussing concepts you need to be both trained and practiced in to reason about, and that our discipline has traditionally been blind to. Plenty of people working with LLM context issues who've never been exposed to the idea of 'subtext' or could tell you why it would matter to their direction of effort.
If the point of not getting to the point is to build trust, then there has to be a relationship in which that trust is invested. Otherwise, not getting to the point is just more invitation for someone to take issue or dismiss what you're saying, to divert the discussion, or to completely miss the actual points you want to discuss.