But then don't say "people"? Because if you say "has N people" and then "more than 2x Y", no-one is going to go "yes, that's 2x land area" when it was NEVER MENTIONED IN ANY CONTEXT.
I don't think they can be because "About 2/3 of Russia" -> Iran is (according to [0]) about 636k mi^2 whilst Russia is 6600k mi^2 or just over 10x the area.
(Iran is 4.5x the land area of Germany, 2.7x Ukraine, 3.7x Iraq - sure "2x" works but it's out enough that it doesn't fit with the "land area" claim.)
Also Denmark is in Europe and has a land area (including Greenland) 1.3x that of Iran which strictly breaks the "more than any country in Europe" claim.
In summary, if it's about land area, it's absolute gibberish. If it's about population, it's mostly accurate.
Ome advantage of python is that it is so slow that if you choose the wrong algorithm or data structure that soon gets obvious. And for complicated stuff this is exactly where I find the LLMs struggle. So I make a first version in Python, and only when I am happy with the results and the speed feels reasonable compared to the problem complexity, I ask Claude Code to port the critical parts to Rust.
The last part is really interesting. It feels like the whole world will soon become Python/JS because thats what LLMs are good at. Very few people will then take the pain of optimizing it
Not because they are brilliant, but because they are pretty good at throwing pretty much all known techniques at a problem. And they also don't tire of profiling and running experiments.
If there's one thing LLMs are really, really good at, it's having a target and then hitting / improving upon that target.
If you have a comprehensive test suite or a realistic benchmark, saying "make tests pass" or "make benchmark go up" works wonders.
LLMs are really good at knowing patterns, we still need programmers to know which pattern to apply when. We'll soon reach a point where you'll be able to say "X is slow, do autoresearch on X" and X will just magically get faster.
The reason we can't yet isn't because LLMs are stupid, it's because autoresearch is a relatively new (last month or so) concept and hasn't yet entered into LLM pretraining corpora. LLMs can already do this, you just need to be a little bit more explicit in explaining exactly what you need them to do.
> The reason we can't yet isn't because LLMs are stupid, it's because autoresearch is a relatively new (last month or so) concept [...]
I'm not so sure. People have been doing stuff like (hyper) parameter search for ages. And profiling and trying out lots of things systematically has been the go-to approach for performance optimisation since forever; making an LLM instead of a human do that is the obvious thing to try?
The concept of 'autoresearch' might bring with it some interesting and useful new wrinkles, but on a fundamental level it's not rocket science.
Recently I tried Codex/GPT5 with updating a bluetooth library for batteries and it was able to start capturing bluetooth packets and comparing them with the libraries other models. It was indefatigable. I didn't even know if was so easy to capture BLE packets.
I find writing by hand is the best. LLMs spit out such linked-in writing that I don’t even want to read it. ;)
But that would be a good blog post and I got some travel coming up. But honestly it was just “oh here’s a BLE python library, see if we can get it running”. I prefer Codex because it seems to do well for guiding the LLMs for complete engineering changes.
Wireshark would do that. But you need to understand low level tools because in case on some BGP attack you all LLM developers will be fired in the spot.
Flakey internet connection: most of current 'soy devs' would be useless. Even more with boosted up chatbots.
And it's partially true. Offline documentation should be mandatory everywhere. Networks can be degraded tomorrow in the current 2nd Cold War we are living.
And, yes, the states and goverments have private backbones for the military/academia/healthcare and so on, but the rest it's screwed.
When the blackout the only protocols which worked fine where IRC, Gopher and Gemini. I could resort to using IRC->Bitlbee to chat against different people of the world, read news and proxy web sites over Gemini (the proto, not the shitty AI). But, for the rest, the average folk? half an our to fetch a non-working page.
That with a newspaper, go figure with the rest. And today tons of projects use sites with tons of JS and unnecesary trackers and data. In case of a small BGP attack, most projects done with LLM's will be damned. Because they won't even have experience on coding without LLM's. Without docs it's game over.
Also tons of languages pull dependencies. Linux distros with tons of DVD's can survive offline with Python, but good luck deploying NPM, Python and the rest projects to different OSes. If you are lucky you can resort to the bundled Go dependencies in Debian and cross compile, and the same with MinGW cross compiling against Windows with some Win32, SDL, DX support but that's it.
With QT Creator and MinGW, well, yes, you could build something reliable enough -being cross platform- and with Lazarus/Free Pascal, but forget about current projects downloading 20000 dependencies.
Heh, my preferred language is Nim which has good docs for the stdlib. It also does static binaries and runs on esp32 like a dream. I’m not worried about some internet downtime, but I also enjoy what I can guide LLMs to build for me.
The BLE battery syncing was a nice-to-have for an IoT prototype. Not something I wanted to spend hours digging through wireshark to figure out but fine for some LLM hacking.
> Offline documentation should be mandatory everywhere. Networks can be degraded tomorrow in the current 2nd Cold War we are living.
Eh? It's all about trade-offs. If our infrastructure is degraded enough that the internet goes down, I have more important things to do than work through a few more Jira tickets.
Especially since a lot of the work me and a lot of other folks are doing is delivered to customers via the internet anyway.
That has not been my experience. JS/TS requires the most hand-holding, by far. LLMs are no doubt assumed to be good at JS due to the sheer amount of training data, but a lot of those inputs are of really poor quality, and even among the high quality inputs there isn't a whole lot of consistency in how they are written. That seems to trip up the LLMs. If anything, LLMs might finally be what breaks the JS camel's back. Although browser dominance still makes that unlikely.
> Very few people will then take the pain of optimizing it
Today's LLMs rarely take the initiative to write benchmarks, but if you ask it will and then will iterate on optimizing using the benchmark results as feedback. It works fairly well. There is a conceivable near future where LLMs or LLM tools will start doing this automatically.
My experience is from trying to get the React Native example to work with OpenUI. Felt Sonnet/Opus was much better at figuring out whats wrong with the current React implementation and fixing it than it was with React Native
But yes I see what you mean and I think people are trying to solve it with skills and harnesses at the application layer but its not there yet
Nope. The world runs on code written in C and C++. Including Python itself. There is a reason why there are literally millions of C/C++ programmers out there working on C/C++ code every day.
One thing with python is that usually I will use one of the many c based libraries to get reasonable speed and well thought out abstractions from the start. I architect around numpy, scipy, shapely, pandas/polars or whatever. So my code runs at reasonable speed from the start. But transpiling to rust then effectively means a complete redesign of the code, data structures, algorithms etc. And I have seen the AI tools really struggle to get it right, as my intent gets lost somewhere.
So what I do now (since Claude Code) is write really bare bones (and slow) pure python implementation (like I used to do for numba, pypy or cython ready code), with minimal dependencies. Then I use the REPL, notebooks and nice plotting tools to get a real understanding of the problem space and the intricacies of my algorithm/problem at hand. When done, I let Claude add tests and I ask it to transpile to equivalent Rust and boom! a flawless 1000x speed upgrade in a minutes.
The great thing is I don't need to do the mental gymnastics to vectorize code in a write only mode like I've had to do since my Matlab days. Instead I can write simple to read for loops that follow my intent much better, and result in much more legible code. So refreshing!
And with pyO3 i can still expose the Rust lib to python, and continue to use Python for glue and plotting
The #1 reason people use it is because it allows you to focus on the problem you're solving rather than the syntax, memory management or some other aspect.
Most people don't even know what C-API is or why it slows things down.
Compatibility is made into a bigger deal than it is. That's the COBOL argument.
I wish the python community focused more on why openclaw and opencode are getting written in typescript, not python.
Why aren't agents more efficient at translating python code into shippable end user binaries using fast interpreted -> compiled agentic loops and attempt memory safety only for binaries/libraries with a large distribution.
Some operations (downsizing already heavily compressed video with the latest and greatest compression techniques) are CPU or GPU bound, but others, like bunching thousands of high res jopg into a lightly compressed timelapse are more likely to be IO bound. So how does this tool make the trade-off? I imagine some things can best be dealt with locally, whilest for ither operations offloading to a external GPU will be beneficial. Also makes a lot of difference if your bandwidth is megabits or gigabits.
The best thing about the average speed cameras is that between the checkpoints all cars drive at almost exactly the same speed. No one trying to overtake, just 5 lanes of traffic at 1km/h below the speed limit
I love these kind of stories, and I appreciate the effort to write these histories down.
I do think the interview could use a bit more editing, it now reads more like a literal transcript and that is somewhat exhausting to read. Take this excerpt:
>> "Like it just fit my brain. It’s one of those where I don’t have to think about it, it just automatically makes sense to me. Much more than any other programming language. Even though I quite like C, I quite like all the pitfalls in C, I’m very comfortable in C and C++ and pretty comfortable in Java and PHP, but Python is just fun and it’s enjoyable and it makes sense. And this was the Usenet days, of course. I think the Python list, yeah, the email list gateway existed as well. So I think I just subscribed to Python-List and learned a lot about Python just from using it, following along."
I sometimes help out at a hobby vineyard of 0.7 hectare; weeding in the row is a lot of manual labour. Your platform seems like a good fit. I like tinkering and robotics, what kind of price point are you aiming for?
a simple ride on mower with a diy inter row disc (basically just a belt and pulley with a spring) may be enough. probably just get sonebody with a tractor and inter row disc weeder to do the job for you.
What's the plan for using an engraving laser in open air without blinding a neighbor? Does the bot fully roll over the target area before firing or something?
I fondly remember finding and exploiting a buggy slot machine on the night the Euro got introduced. A classmate (I never played slot machines) made some money but didn't understand what was going on. I observed and it became apparent (in my slightly intoxicated state) the machine would pay out 2 Euro coins where is should pay out 20 cents. And when playing a 1 Euro game, you would often "win" 80 cents. Pay-out immediately and you got 8 Euro. Of course after a few rounds, the 2 Euro coins ran out and it would do some RNG to pay out 1 Euro with 80% chance. Don't know if I tried feeding it back the 2 Euro coins, I recall just made enough to have a free new years eve
That reminds me of a vending machine ran into as a little kid. It was in a private place and it had an out of order sign posted. Being hungry and young, I plugged it back in so I could take my chances. Every time I put in a quarter, three or four would fall into the coin return. When it was time to leave, all of the pockets on my cargo shorts were bulging so much that I had to hold my shorts up.
that was possibly just some attendant accidentally messing up which hopper they refilled (or with which coins), or someone screwed up the assignment on the control board which hopper was connected to which bus identifier.
Reminds me I gotta eventually write up what I found reverse-engineering the one armed bandit in my basement LOL
The real problem is that BREP CAD kernels are hard. A few of proprietary kernels dominate the scene: Parasolid powers NX, SolidWorks, Fusion, and Onshape, while ACIS (owned by Dassault) is used by Inventor and BricsCAD. Catia uses Dassault's own CGM kernel. The open-source world relies mostly on OpenCASCADE, which is unfortunately a lot less capable than any of these.
Fillets and chamfers are a good example. They seem simple but are geometrically non-trivial, and OCC will fail on cases that Parasolid handles without complaint. You can push either kernel to its limits if you try hard enough, but OCC hits that ceiling much sooner. So any CAD tool built on top of it inherits that ceiling too.
> Fillets and chamfers are a good example. They seem simple but are geometrically non-trivial, and OCC will fail on cases that Parasolid handles without complaint.
A long time ago I interviewed at one of the large CAD companies. I remember getting an office tour and the person showing me around pointed into a corner with six desks and said "that is the team that does fillets".
Open source tools can handle some cases, but to handle the full complexity of real world problems is a huge extra step that I doubt they will manage any time soon.
That's one of the real problems. The other real problem is an active resistance to UI improvement simply because another CAD package did something similar.
FreeCAD doesn't resist those comparisons anymore. They happen regularly. Implementing change is just slow, and purely copying how xyz cad built their UI isn't always compatible with FreeCAD, so a lot of careful consideration goes into things before concepts from other software get implemented. Not to mention that developers seem to really dislike doing frontend work.
Aaaaah! No! You're doing it too! I am not talking about copying how xyz cad built their UI. I am not talking about consciously implementing concepts from other software. I'm talking about this crazy tendency to assume that the reason someone wants UI feature X is because xyz cad does it, not because it's a natural, intuitive thing to want to do. Natural, intuitive things tend to get independently invented; more than once I've made a suggestion and had "this isn't Fusion 360, you know" thrown back at me, despite the fact I've never used F360 to know what comparison they're making.
I wasn't implying you were doing that. I don't play the 'this isn't fusion or xyz cad' argument when someone brings a suggestion. I'm only stating that not every idea will work properly in the context of FreeCAD, but comparisons are considered when such suggestions are made.
The thing you are complaining about is the immediate dismissal the forum used to shoot back at people with ideas. Most likely a conditioned (and very toxic) response from receiving a lot of equally non-constructive feedback using things like F360 as their litmus.
Either way, there is the Design Working Group which evaluates ideas and feedback with a fair lens about what will work in context of FreeCAD and what is feasible to implement without causing unnecessary disruption to existing users. It is a complex social paradox to deal with.
Do you think this is why CAD software UI/UX is often so clunky? The kernels are complicated and error-prone given the incalculable number of edge-cases, which puts error reporting at a disadvantage, leads to counter-intuitive feature wizards with some having way too many parameters and others being very single-purpose?
reply