MurphyA/hacker-news huggingface dataset:
by gary_0 | 2026-01-07 07:42:04+00:00
Both questions could fill many books. But having grown up in Canada and having visited Europe, they both seem to have a fundamental disinterest in technology and futuristic-ness, and curiosity in and ambitions about it (relative to the US). There are still techies and nerds, but they are fewer and further between, and more consumerist and casual about it. From personal experience, in the 90's and 2000's, far fewer businesses were interested in websites or using the Internet for commerce, and were slow to adopt it. In Canada, broadband and cellular access lagged far behind the US, and continues to be sub-par and overpriced to this day.

If you did happen to end up with computer-related skills or education, not only was the pay vastly higher in the US, that's where the culture was a lot more enthusiastic about technology (hence why most of the world's major tech companies were founded there). And if your interest in tech extended beyond making money, you probably felt like you would meet more like-minded people in the US.
by logicchains | 2026-01-07 07:43:30+00:00
>and because immigration is what has delayed our demographic inversion that Europe and other developed nations are going through

The birthrate among the most conservative Americans is still over 2.0. From the perspective of the conservative movement in power, it makes sense to halt immigration so the population becomes more and more conservative over time (as immigrants are left-leaning on average, especially Indians).
by Eisenstein | 2026-01-07 07:43:47+00:00
This is a typical problem you see in autodidacts. They will recreate solutions to solved problems, trip over issues that could have been avoided, and generally do all of things you would expect someone to do if they are working with skill but no experience.

LLMs accelerate this and make it more visible, but they are not the cause. It is almost always a person trying to solve a problem and just not knowing what they don't know because they are learning as they go.
by mks_shuffle | 2026-01-07 07:44:00+00:00
How much Codex and Claude Code are different from each other?
I have been using Codex for few weeks doing experiments related to data analysis and training models with some architecture modifications. I wouldn't say I have used it extensively, but so far my experience has been good. Only annoying part has been not able to use GPU in the Codex without using `--sandbox danger-full-access` flag. Today, I started using Claude Code, and ran similar experiments as Codex. I find the interface is quite similar to Codex. However, I hit the limit quite quickly in Claude Code. I will be exploring its features further. I would appreciate if anyone can share their experience of using both tools.
by OdisUlises | 2026-01-07 07:45:55+00:00
I am confused... Why this so called Solid State Battery with 20.2 kWh can only achieve 350 km, while current battery that is used in "Charged Rimau" ( an electric motorcycle that is used in Indonesia) can achieve 200 km with only 5.4 kWh??? I expected more from a 20.2 kWh SSB, perhaps no less than 1500 km...
Maybe someone here can explain why?
by LucaMo | 2026-01-07 07:46:29+00:00
What I think people get wrong (especially non-coders) is that they believe the limitation of LLMs is to build a complex algorithm.
That issue in reality was fixed a long time ago. The real issue is to build a product. Think about microservices in different projects, using APIs that are not perfectly documented or whose documentation is massive, etc.

Honestly I don't know what commenters on hackernews are building, but a few months back I was hoping to use AI to build the interaction layer with Stripe to handle multiple products and delayed cancellations via subscription schedules. Everything is documented, the documentation is a bit scattered across pages, but the information is out there.
At the time there was Opus 4.1, so I used that. It wrote 1000 lines of non-functional code with 0 reusability after several prompts. I then asked something to Chat gpt to see if it was possible without using schedules, it told me yes (even if there is not) and when I told Claude to recode it, it started coding random stuff that doesn't exist.
I built everything to be functional and reusable myself, in approximately 300 lines of code.

The above is a software engineering problem. Reimplementing a JSON parser using Opus is not fun nor useful, so that should not be used as a metric
by davidbanham | 2026-01-07 07:46:39+00:00
It’s a pretty solved problem. In NSW, Australia we have automated systems for heavy vehicle noise fines. (They could of course be used for regular vehicles as well, we just don’t)

For all vehicles the police can issue a defect notice to anything that seems too loud. The owner then has to present to an inspection station and prove that they’re compliant. If they don’t show up or don’t test as compliant their registration is voided and they’re fined. Of course, they can remove the modification before visiting the induction station then reinstall it afterwards, but that gets pretty time consuming pretty fast and people largely stay within the bounds of reason as a result. The system isn’t perfect but it works fine.
by TheRoque | 2026-01-07 07:47:26+00:00
For people with astigmatism, black in white is generally easier to read than the other way around: https://graphicdesign.stackexchange.com/questions/15142/whic...

Of your criteria is battery life, dark mode is most likely better

If your criteria is eye damage/strain, then IIRC the research is divided on this topic
Show HN: MotionPoster – static poster to animated poster
by kuzej | 2026-01-07 07:48:25+00:00
Hi Hacker News,

I built MotionPoster (https://motionposter.org/) to help people make short animated posters quickly, without spending a lot of time inside heavyweight editing software.

What it does:
- Upload a poster image (or start from a blank)
- Add text overlays
- Pick simple motion styles (for example: pan/zoom, subtle movement)
- Export as a short video you can post on social platforms

Why I built it:
I often needed “a little motion” for posters, but a full motion workflow felt slow for small tasks. I wanted something that gets to a usable result in minutes.

What I want feedback on:
- Does the motion look natural enough, or does it feel “template-like”?
- Which export formats and sizes matter most to you?
- What is the biggest missing feature for your workflow?

Thanks, and I will reply to every comment.
by bonesss | 2026-01-07 07:48:38+00:00
In addition to the underlying domain (and I agree, it’s no coincidence that windowed GUI widgets are common in in OOP textbooks), there’s also overlapping spectrums of language expressiveness and object-orientedness to consider.

The principle of least surprise, bad evil and scary techniques in general might be the orthodox, efficient and intuitive for maintainers in context. Templates in GUI frameworks versus business apps, for example.
by zamadatix | 2026-01-07 07:48:55+00:00
I just went through a CSCI degree program after a long time in the field (figured I'd have some fun + try to catch a few things I may not have had a chance to mess with much over the years, like databases) and I gave myself a pretty decent lean on C++ programming courses where I could.

The introduction to class inheritance started with the classic "Dog extends Animal" example. Honestly though, that was actually really good for new programmers in the course for exactly the reasons you point out: it's completely abstract and meaningless without immediately inviting urges of "well, why wouldn't I just do something like <x> instead" yet is also relatively straightforward way to learn "well, what the hell even IS class composition?" before you move on to the "more practical" examples where it can start to be better to dive into "well, when and why would I USE inheritance over something else?" type probing.

The course actually did pretty good with both halves of that around the Dog/Animal example... and then it all fell off the rails a bit as inheritance was given far too much weight in the content of that and the following courses. I think even my last C++ final project still had using inheritance as a design requirement, and by that point the things the projects were about weren't really great fits for inheritance so you had to just shove it in anyways.

To me it seems exactly like how implementing "uint32_t factorial(uint32_t x)" is a GOD AWFUL practical example of when to use recursion but a FANTASTIC way to introduce what a recursive function is, because that's exactly how you already learned about it in math classes. In the same way, once recursive functions are introduced with a basic understanding of what it is, it's good to move to more practical examples and poke at "why was that actually not a great way to implement factorial but it was great for traversing trees or..." type exploration/questioning.
by ponco | 2026-01-07 07:49:43+00:00
I agree. I'm imagining a large software team with hundreds of tickets "ready to be worked on" might support this workflow - but even then, surely you're going to start running into unnecessary conflicts.

The max Claude instances I've run is 2 because beyond that, I'm - as you say - unable to actually determine the next best course during the processing time. I could spend the entire day planning / designing prompts - and perhaps that will be the most efficient software development practise in the future. And/or perhaps there it is a sign I'm doing insufficient design up front.
by 4ggr0 | 2026-01-07 07:50:48+00:00
i think it's the by now internet-meme worthy difference between walls in the US compared to most of Europe. i've never lived somewhere which didn't have thick brick or concrete walls. 30cm was a bit high, more like 20cm.

i've seen tons of americans making holes in their walls by punching or falling into them. could never relate myself, i'd have a broken hand or concussion :D

my phone is not very powerful, maybe that's a factor.
by gdiamos | 2026-01-07 07:50:49+00:00
It was an interesting read Sara, thanks for sharing it.

I especially agree with your point that scaling laws really killed open research. That's a shame and I personally think we could benefit from more research.

I originally didn't like calling them scaling laws.

In addition to the law part seeming a bit much, I've found that researchers often overemphasize the scale part. If scaling is predictable, then you don't need to do most experiments at very large scale. However, that doesn't seem to stop researchers from starting there.

Once you find something good, and you understand how it scales, then you can pour system resources into it. So I originally thought it would encourage research. I find it sad that it seems to have had the opposite effect.
by stingraycharles | 2026-01-07 07:51:12+00:00
I hope self-promotion isn't frowned upon, but I've been spending the past months figuring out a workflow [1] that helps tackle the "more complicated problems" and ensure long-term maintainability of projects when done purely through Claude Code.

Effectively, I try to:

- Do not allow the LLM to make any implicit decisions, but instead confirm with the user.

- Ensure code is written in such a way that it's easy to understand for LLMs;

- Capture all "invisible knowledge" around decisions and architecture that's difficult to infer from code alone.

It's based entirely on Claude Code sub-agents + skills. The skills almost all invoke a Python script that guides the agents through workflows.

It's not a fast workflow: it frequently takes more than 1 hour just for the planning phase. Execution is significantly faster, as (typically) most issues have been discovered during the planning phase already (otherwise it would be considered a bug and I'd improve the workflow based on that).

I'm under the impression that the creator of Claude Code's post is also intended to raise awareness of certain features of Claude Code, such as hand-offs to the cloud and back. Their workflow only works for small features.

[1] https://github.com/solatis/claude-config/
by willvarfar | 2026-01-07 07:51:14+00:00
This is going to be an interesting take but I think it is plausible that we'll see a quiet growth in American tech companies having even bigger offshore campuses instead. Google Zurich or Google London could grow, Google does hardware in Taiwan and Apple and Intel do hardware in Israel, and pretty much all the big tech companies have the biggest chunk in Hyperbad.

The withdrawal of the H1B means companies can't compete on offering them to attract talent, but that talent still wants to work somewhere and companies can instead complete on the perks they offer at those offshore places.

Things will get interesting if Europe can become the place that US tech companies offer visa support for people to move to though.
by seanmcdirmid | 2026-01-07 07:51:47+00:00
Only a special group of conservatives largely in Utah have the ambition and brains to do much tech work. The rest aren’t very promising, and with the current birth rate, future tech jobs will mostly not get done and the work will move abroad.

Indians and even Chinese, not to mention most of the non-European immigrants, are relatively conservative (socially reserved, self reliant, lots of self responsibility) and are only seen as left leaning in the toxic form of nationalistic conservatism that dominates the USA.
by neilv | 2026-01-07 07:52:35+00:00
I fully agree about the labor rights concerns.

(In my head at 2am, I was (wrongly) taking that as a given, understood by everyone, and then remarking on a tangent from there. About the implications of 60hr/wk at Google specifically. And then going from there, about how maybe it didn't have to be like that. Moot for Google in reality, but it makes a good example for what-if thinking or daydreaming about how we'd like the next good tech employer to be.)
by Terr_ | 2026-01-07 07:52:45+00:00
There are two things being blurred together here that we need to separate:

1. Maintenance tasks needed to ensure continued original behavior and capability.

2. Renovations and alterations needed to maintain enough utility as environments and needs change.

A big truck that carries thousands of pounds of cargo is an asset, even if you have to replace the oil... But what happens when the water rises and you have to choose between junking it entirely versus welding on pontoons to make it float?

Trucks mainly have problem #1, while software mainly has problem #2.
by coldtea | 2026-01-07 07:52:52+00:00
>What bothers me about posts like this is: mid-level engineers are not tasked with atomic, greenfield projects

They get those ocassionally all the time though too. Depends on the company. In some software houses it's constant "greenfield projects", one after another. And even in companies with 1-2 pieces of main established software to maintain, there are all kinds of smaller utilities or pipelines needed.

>But day to day, when I ask it "build me this feature" it uses strange abstractions, and often requires several attempts on my part to do it in the way I consider "right".

In some cases that's legit. In other cases it's just "it did it well, but not how I'd done it", which is often needless stickness to some particular style (often a contention between 2 human programmers too).

Basically, what FloorEgg says in this thread: "There are two types of right/wrong ways to build: the context specific right/wrong way to build something and an overly generalized engineer specific right/wrong way to build things."

And you can always not just tell it "build me this feature", but tell it (high level way) how to do it, and give it a generic context about such preferences too.
by dijit | 2026-01-07 07:53:03+00:00
This is a totally fair point to make.

As mentioned though, the irony is in that, once upon a time, the lords and landed gentry were the "bland, soulless overlords" and so buying things would improve their profits... and nobody could become them.

Then the idea of fractional ownership came about and the common man could buy in to an enterprise.

Now of course, everyone is correct that this has been weaponised- but it's often interesting to go back to the original intent (or idea) of something to see how warped it has become.
by Pooge | 2026-01-07 07:53:49+00:00
It's hard to put my thoughts into words. Those who are tired of social media are those that are not addicted to the never-ending dopamine injections (i.e. doomscrolling).

I don't have kids yet but I hope "social" media will be banned until at least 18 years old before they're born.

The human brain is wired to be lazy; it's much easier to doomscroll and get your dopamine than spend 40 hours reading a book. We want to be fit but we don't take the time to exercise; we want the candy but don't tolerate any effort to get it whatsoever.

It's always been the case during history but our ancestors didn't have access to those kinds of addicting tools.

It's an anecdote but I have long hair and there's a period where you cannot get a good haircut (too long to have a "short" haircut and too short to have a "long" haircut); I know some people who couldn't put up with the few months it takes to grow into a good-looking style and cut their hair back to short. Life is not Instagram, you cannot change something instantly. Everything that is worth the "candy" takes time. A hell of a lot of time. Of which we're losing track.

Very badly worded but maybe it resonated with some of you.
by itake | 2026-01-07 07:54:36+00:00
I think the US should prioritize training permanent residence over temporary residents that may take their skills (and wealth) back to their home country.

If the h1b program was a perm residence visa, then your argument holds water. When they return home, they will take their 15 years of experience and offshore their capital.

Whereas if a perm resident had that same job, they would keep their money invested in American businesses (and real estate).

If our goal is to brain drain the world, lets replace the h1b visa program with a program with a clear attainable path to perm residency.
by omnicognate | 2026-01-07 07:54:38+00:00
I tried Claude Code a while back when I decided to give "vibe-coding" a go. That was was actually quite successful, producing a little utility that I use to this day, completely without looking at the code. (Well, I did briefly glance at it after completion and it made my eyeballs melt.) I concluded the value of this to me personally was nowhere near the price I was charged so I didn't continue using it, but I was impressed nonetheless.

This brief use of Claude Code was done mostly on a train using my mobile phone's wi-fi hotspot. Since the connection would be lost whenever the train went through a tunnel, I encountered a bug in Claude Code [1]. The result of it was that whenever the connection dropped and came up again I had to edit an internal json file it used to track the state of its tool use, which had become corrupt.

The issue had been open for months then, and still is. The discussion under it is truly remarkable, and includes this comment from the devs:

> While we are always monitoring instances of this error and and looking to fix them, it's unlikely we will ever completely eliminate it due to how tricky concurrency problems are in general.

Claude Code is, in principle, a simple command-line utility. I am very confident that (given the backend and model, ofc) I could implement the functionality of it that I used in (generously!) at most a few thousand lines of python or javascript. I am very confident that I could do so without introducing concurrency bugs, and I am extremely confident I could do so without messing up the design so badly that concurrency issues crop up continually and I have to admit to being powerless to fix them all.

Programming is hard, concurrency problems are tricky and I don't like to cast aspersions on other developers, but we're being told this is the future of programming and we'd better get on board or be left behind and it looks like we're being told this by people who, with presumably unlimited access to all this wonderful tooling, don't appear to be able to write decent software.

[1] https://github.com/anthropics/claude-code/issues/6836
by weatherlite | 2026-01-07 07:54:42+00:00
I'm seeing this as well. Not huge codebases but not tiny - 4 year old startup. I'm new there and it would have been impossible for me to deliver any value this soon.
12 years experience; this thing is definitely amazing. Combined with a human it can be phenomenal. It also helped me tons with lots of external tools, understand what data/marketing teams are doing and even providing pretty crucial insights to our leadership that Gemini have noticed.
I wouldn't try to completely automate the humans out of the loop though just yet, but this tech for sure is gonna downsize team numbers (and at the same time - allow many new startups to come to life with little capital that eventually might grow and hire people. So unclear how this is gonna affect jobs.)
by misja111 | 2026-01-07 07:55:49+00:00
I see the author fighting really hard against a paradigm that was already well known to be suboptimal 20 years ago ..
"Favor composition over inheritance" is a phrase that became common knowledge in e.g. the Java world half way during the 2000's.

It was even already mentioned in the famous Design Patterns book from the GOF in 1994.
by zerosizedweasle | 2026-01-07 07:56:23+00:00
The Shiller P/E compares the price of a broad market index, such as the S&P 500 (SNPINDEX: ^GSPC), to its average inflation-adjusted earnings per share over the past 10 years. Its purpose is to give investors a long-term sense of whether the index looks expensive (or cheap) by smoothing out short-term profit swings.

The CAPE ratio was one of the metrics that helped Shiller identify the dot-com bubble just before it popped in March 2000. Now, in December 2025, the market is back in the same range, which has some investors feeling very, very uneasy.

The CAPE ratio may be flashing a warning sign

Since the early 1870s, the Shiller P/E has historically been in the double-digit range, yet only twice has it exceeded 40.

The first was during the dot-com bubble, when the Shiller P/E reached as high as 44 before the market crumbled.

The second is happening right now. After a strong 2025 performance, fueled by artificial intelligence and the Magnificent Seven, the S&P 500's Shiller P/E has been hovering around 39 to 40.
by dyigitpolat | 2026-01-07 07:56:28+00:00
just vibe-coded an optimizer for the game enclose.horse that takes in the screenshot of the grid and the number of walls as input, and spits out the optimal wall configuration (supports cherries too!)

algorithm:

1. infer grid dimensions

2. color histogram analysis to designate grasses, water, cherries and horse

3.0. register game mechanics as optimization constraints (cannot place on cherries, cannot move over walls and waters etc.)

3.1. apply mixed-integer linear programming to determine optimized wall placements

4. profit!

try: https://dyigitpolat.github.io/enclose-horse-solver

source: https://github.com/dyigitpolat/enclose-horse-solver
by bostik | 2026-01-07 07:56:29+00:00
That sounds like it would make one hell of a tech talk. I have a gut feeling many readers (especially lurkers) of this very thread would gladly watch the recording.

Common and/or various ways the two groups misunderstand each other, and how you help them to anchor to the underlying base concepts? Yes please. For example, we know that interest accrues over time, but we still use shorthand for the annual interest as a step function because it makes intuitively more sense.