FWIW it's quite easy to farm karma to get to the downvote threshold. If you go to any of the energetic political HN threads, you just need to submit an enthusiastic comment that is pro the dominant position and you'll get tens of upvotes quite quickly. Do that for a week and you'll be ready to downvote. Before HN had LLM detection I had an experiment with an LLM doing that (though I approved everything it wrote by hand) and farmed karma very quickly. I stopped because I felt quite gross about it, but realize it's probably trivial to do now.
The problem isn't really the site, it's the people. People like smashing the up and down buttons on things they agree with and unfortunately a comment's score affects where it shows up on the page.
Elisp is homoiconic and has a strong culture of REPL development, but really the thing that makes elisp so nice is that it has decades of use to iterate on an editor. There's an attempt to do this with Common Lisp that's quite cool, called Lem, but the sheer amount of person-years that have gone into making emacs and elisp a conjoined system makes it a pleasure to use and iterate on. Lem, in comparison, is building up all the UX associated with a "live programming environment" that just comes out of the box with elisp (though I, personally, prefer Common Lisp as a language/environment.)
Pre-LLM I used to spend the occasional afternoon at work when I was a bit demotivated just adding new features to my emacs or fixing small papercuts in the environment. Now I largely have the LLM work on it for me, though I separate out LLM code from my own by loading them separately in my config.
I don't think this is true for most people on the big issues but do think it's true for a lot of small issues. Reddit (and HN) lead to a lot of pageant show dynamics where the people with the time to hit the buttons decide what content to boost. Small Discord communities are free from that.
I am not quite sure what the HN owners/mods are doing about it, if anything at all.
Due to non-linear effects of propaganda, a single/small-group of people working in a concerted manner can easily change group dynamics specifically its "fairness perception" and thus ultimately lead to the detriment of the group itself.
I don't know how much they can do. I don't want to speak for the mods, but most of the problems on this site come from upvotes and downvotes. I guess some cheap things you can do are increase the karma threshold required to downvote and apply a smoothing function to upvotes (like quadratic voting for vote scores, aka n votes on a comment bumps the score up by sqrt(n).)
But ultimately a site moderated by up and downvotes that wants to keep a relatively light hand on moderation is going to end up like what HN is today. Changing the voting structure on the site or the moderation POV on the site would be a radical change and could change the entire site's culture drastically.
Oh, HN owners/mods can do a lot if they wanted to. There is a lot of propaganda/influence peddling/public opinion shaping/shilling/obfuscating etc. going on here which has only increased after the AI boom.
The stock answer to the above charge is that "this is more of the individual's perception and not reality" and "HN is just representative of what is going on in the society". Also;
Humans will game everything they can to gain an advantage even if it were only for silly imaginary things like "upvotes". Add in our psychological propensity for "Tribalism" and you can see we have to be a bit paranoid when it comes to social networks. Introduce anonymity into the game and things get even more worse.
So it behooves the HN owners/mods to have some sort of system to analyze everything and do some inferences for insight even if they don't act on it immediately.
Some users have already developed some models and shared it on HN; eg:
Classifiers can require a lot of examples to train correctly. You can take a decision model's outputs and apply platt scaling to arrive at a good decision boundary a lot faster.
Eventually, yes, it makes sense to move to a pure classifier model as it's probably a lot cheaper. But then you need to learn how to serve your own classifier model correctly. Compute costs are being driven up by demand to serve models and unless you're careful it's easy to use your GPUs less effectively than a company specializing in serving a model.
I've been an emacs user for most of my life, before I even went to college. I took a brief (5 years) tour into IDEs for writing code on the job, but the moment agents became a viable way to develop code I switched back into emacs. I love reviewing changes in magit.
I'm pretty sure many folks put up with the bloat of IDEs just for the functionality they offered. Now, they're hopping back to emacs, vim, sublime, whatever their heart desires.
I used Opus 5.5 to figure out that a language model we were serving at work for internal use (we don't really serve models, we only use this internally because it processes sensitive data that we can't send to external endpoints) was being bottlenecked by CPU contention on tokenization, by having Opus run in an autoresearch style loop.
Opus's first proposal for a fix was to spawn multiple Python processes and build a load balancer between them in Python. At first I asked it why it wasn't using haproxy and it said that haproxy would be an added dependency and that the overhead for this kind of thing in Python would be negligible. I knew this was idiotic but wanted to test this out, so had Opus run two experiments in parallel. Sure enough an haproxy load balancer was much, much better on HTTP load balancing than Python code was.
This is the kind of thing that if you're unfamiliar with how networking code works, the models can autopilot into bad decisions that are verifiably correct (higher throughput than the original CPU-bottlenecked implementation) but much short of best practice.
Are you doing CPU inferencing? For small models you could check qxotic.ai which is a whole inferencing stack for many popular open models in Java, which can beat llama.cpp in speed in some cases. Its tokenizer toknroll is faster than tiktoken, which is what made me think of it for your use case.
The advantage is that you don't have issues like the GIL or whatever, so there's no need for all the complexity of load balancing between multiple pythons.
Thanks for the pointers, I'm gonna look into them.
I'm not doing CPU inferencing but I'm doing some tokenization in Python which is CPU-bound. In all honesty I started on this project to scale the model and did not build it myself so have been trying to read code and walk back the approach. I've been thinking about rewriting the Python glue in Go to avoid issues with the GIL.
Plenty of other professions were hit by computing. Part of why programmers are so emotive about this concept (other than the fact that emoting online loudly seems to be much more accepted in software than other professions) is that programming has never been threatened in the same way as other professions have been until now.
My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career; free flow of information over the internet and commodification of spreadsheets changed all of it. From my parents' generation, I know practical effects folks who became unemployable once movies went to digital effects; engineers who found their draftsmanship skills obsolete. Folks with near-photographic memories whose entire superpower was destroyed by computing. I personally grew up in a blue collar community that was income depressed because its labor became commodified, though that was due to mechanization.
FWIW, I agree with pretty much everything you've said. But I don't think it's unique to any profession or individual that they tend to care the most deeply when it hits them directly.
The only thing I don't really agree with is where you say "My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career." I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs (for MBA types anyway) there is, so I just don't know what you're talking about with this one.
> But I don't think it's unique to any profession or individual that they tend to care the most deeply when it hits them directly.
Sorry, I didn't mean to imply that. I just meant that part of the unique feelings in the air for software engineers is that this is the first time we're facing this.
> I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs
There's plenty of other jobs the MBA type could get into these days which are also high prestige and there are now many more tiers of management consultants. The elite folks at McKinsey are still high prestige with high salaries, but your average Accenture or Deloitte consultant is both pay and prestige wise about the same as an average knowledge worker. Plenty of VCs, fund managers, and investors are high prestige MBA-types. The explosion of private capital means there's a lot of opportunity to manage private capital; private capital markets were just much shallower 50 years ago.
FWIW I don't think programming changing devalues the experience you give your kid.
I grew up poor and as an adult I'm surrounded by silicon valley engineers who grew up wealthy. The biggest differences in our upbringing is their knowledge of the system and their connections within it. Their parents knew college admissions officers, knew what kind of test prep mattered and what didn't, knew the competitive clubs that their friends who were admissions officers looked for and how to get their kids into those competitive clubs. They have friends who are VCs and hedge fund managers and their kids can get high school internships working for their friends where they can learn about those industries and gain the warm connections needed to start startups or court investment. They know doctors when they need medical advice and their doctor doesn't have the time, lawyers who will give them free advice on legal issues, etc etc
And now, as a well-to-do adult in the tech industry, I have the same connections. Generally speaking the privilege you can offer your kids is the knowledge and access to highly qualified individuals.
As I like to tell others: before my job was 70% architecture & patterns and 30% coding & algorithms. Now my job is 100% architecture & patterns. While I still spend the majority of my time on architecture & patterns, and while I enjoy this aspect more than coding and algorithms, I am still working a "different job" than I was when my hands steered the code completely.
People say stuff like this all the time, but what does it actually mean? Like, isn’t the details of the code, at least at some level, part of the “architecture”? I’m so curious about what people who say this are actually making where they just sit around all day and dream up new lego structures without ever having to look at any of the bricks.
The bricks are pretty standardized? I mean, you're not reinventing singly-linked and doubly-linked lists from first principles no? When I program I think in terms of data structures, data hierarchy, and algorithms. I want to use a queue here, a lock here, a double linked list there, an array list over here, maybe a hash dictionary with linked-list chaining for collisions. It's only a few times in my career that I built a bespoke data structure from the ground up and they were all for very hot loops and one case involved working on a lock-free algorithm.
I've done a lot of functional coding in the past (in academia, in Haskell as a hobby, and Scala for a unicorn where I was an early hire.) This probably affects how I think. But I find it quite natural to organize my code this way. After all the fundamental data structures and the hierarchies relating them are what often determine core properties of your programs such as being CPU, Memory, or IO bound.
I also work as a pretty senior engineer and my tasks before agents were usually about leading a team to implement something. I would often do the v0 implementation to make sure we met customer requirements and then take a step back and help the team scale the service up. These days the team is a lot smaller and maybe just another engineer; the agents make up the rest.
Surprisingly enough, before I led teams I wrote software by hand from tickets the way any other mid level software engineer did. And also quite oddly, when I contribute to open source I still just write it by hand, from scratch, and am at the mercy of the maintainers who give my patch feedback or reject it. So somehow, I know it's crazy but somehow, I am able to use my experiences to weigh in on this.
I may have it wrong, but I think 'architecture' can include relatively low-level details: you could even design a program down to the level of what each function does, and still only be doing 'architecture', not coding, so long as you're not writing the code or specifying exactly how it should work.
> you could even design a program down to the level of what each function does, and still only be doing 'architecture', not coding, so long as you're not writing the code or specifying exactly how it should work.
So it all wishes and prayers? no wonder software quality is down.
Software is built on wishes and prayers. Programmers don't ship pixels to be installed in monitors, nor do we (mostly) work with compiler internals. We write a detailed set of instructions and hope that a bunch of systems we don't necessarily comprehend follow them well enough to get the intended results. It works because some folks got together and wrote down their wishes and prayers so good that others were able to understand and follow them later.
We can be curious about how others approach problems or we can try to find the faults. I feel like this comment is a great example of jumping to the negativity rather than trying to understand a different perspective.
I ultimately think learning how other people structure programs is an enriching task and not one that should cause you to dig in and discredit differently-shaped approaches.
> I ultimately think learning how other people structure programs is an enriching task
Learning from others is great. But there should be actually something to learn. When someone says
so long as you're not writing the code or specifying exactly how it should work.
It means they’re not creating software. They’re just playing with randomly generating something.
A software is the recipe for some process. The code is the formal version where everything is exhaustively specified. Not thinking about the code means you’ve stopped thinking about the software somewhere and no longer can say if it’s ok or not.
What's the point of leaving a comment if you're not going to change your mind and they're not going to change theirs? Is it just to advocate for your position?
As you're being very vague, I write more about my opinion, which is based on a guess of what your approach. Basically the Q of P imply Q where P is the guess (and P is the thing you're being vague). I'd like if you can prove that either P is not valid or that there's a different Q that exists.
Axiom: A software is the recipe for some process. The code is the formal version where everything is exhaustively specified.
P: Not thinking about the code
Q: means you’ve stopped thinking about the software somewhere and no longer can say if it’s ok or not.
To further go with my point, it's like explaining how to make a cake and you said that instead of a recipe, it's fine to provide just the name of the ingredients and a general instruction like: mix everything together and put it in the oven.
When we write code we sit atop a tower of abstractions. You're trusting your language's stdlib, its compilers, the syscalls offered by your kernel, the virtual memory implementation of the kernel. Your coworkers wrote code that you only interact with as a library or over an API of some sort. Let's not even think about the lossy abstraction of taking the ultimate bytecode generated and actually mapping it to the actual CPU pipeline that's running the code.
Modern computing is an exercise in trusting abstractions and then zooming into the abstractions and figuring out what went wrong when something breaks. Just because I wrote a web route doesn't mean I've audited the code behind the web framework, the event loop, the HTTP implementation, the TCP implementation and so forth. By your argument then I've already stopped thinking about my software and can't tell you if it's okay or not.
I'm sympathetic to both the perspective of sadness from the loss of hand coding and the perspective of joy from working at a higher level of abstraction, despite its costs in understanding. It actually seems very simple to me to hold both perspectives within me.
The thing you’re forgot to mention is that the trust in the layers below your code is not blind. Sure you treat it as axiomatic foundation. But when something breaks and you’re sure it’s not about your code, then you can investigate the actual part that is wrong in that foundation.
Once that’s done, there’s a matter of accountability where you can report the issue to the people responsible for that. Then because they know their own code they can repeat what you did and try to find where things went wrong.
That chain of accountability is the main issue there. We still have tower of abstraction, but no one knows about their layers. Accountability is lost and with it the trust is gone.
I never care about code, whether you wrote the majority of it or it’s just a glue that hold several library. What I care about is that the semantics of that module that I interact or build upon can be trusted, and when something wrong is an accident and not a daily event.
Even when you’re writing an application and not a library or a platform, you’re not free to write whatever. Your users depends on you, and themselves may have clients that depends on them. Being cavalier about what you write is just recklessness and in any other (real in some countries) type of engineering, it would be labelled as malpractice.
> That chain of accountability is the main issue there. We still have tower of abstraction, but no one knows about their layers. Accountability is lost and with it the trust is gone.
Right this is the main difference between our viewpoints. I don't work on completely open systems. A lot of my life I've worked on closed platforms, cloud runtimes, a mix of work that's been in my control and out of my control. I've filed my share of AWS tickets but ultimately most of them ended up not fixed by AWS. I've made peace with not having accountability for layers of the stack and am comfortable assuming that there are bugs on the foundation that I have to work around.
> Being cavalier about what you write is just recklessness and in any other (real in some countries) type of engineering, it would be labelled as malpractice.
The problem isn't really the site, it's the people. People like smashing the up and down buttons on things they agree with and unfortunately a comment's score affects where it shows up on the page.
reply