That's a long time hypothesis of mine as well, but I think it stems from being stung or bitten by venom. If venom is injected into the bloodstream, it is desirable to be injected as far away from the heart as possible.
Some centimeters might not sound much, but over millions of years, the cumulative effect might be that 1% of human population every 10.000 years gets genetically optimized to hold their heart at a more protective spot.
Handedness is probably not (often) captured in healthcare records, but I'm wondering if epidemiologists could mine insurance claims (or some other data rich resource) to see if there's a correlation with serious outcomes (death, hospitalization, etc.) from venom and handedness.
That's a good idea, a very good idea actually, but I wonder about it's effectiveness due to a very small total number of snake bites nowadays, compared to the past.
Hundreds of thousands years in the past, hominids lived into much more tropical areas than today and there are a lot more spiders, scorpions, lizards and snakes in these warm places. It makes sense that insects and especially reptiles pushed the evolution of mammals in certain directions and the positioning of the heart in the human body might be one of them.
Today people live a much different lifestyle than having to deal with insects and reptiles all day long. I don't know if it is possible to decipher the past from today's data.
The trick might be to put a multimodal A.I. to describe what it sees in an image, and employ another LLM to put the textual representation into code. Multimodal A.I.s are good at describing images.
Even a handwritten sketch could be a very good starting point for an image recognition from an A.I.
>I love how everything is hackable via Python APIs.
It is hackable with languages other than Python too. The Python interpreter has no restrictions to access and execute everything it likes. Contrast this with Gimp, which it's Scheme interpreter cannot access anything except objects inside Gimp.
This opens some security hole risks in Freecad, given that plugins can execute arbitrary code in the user's machine, but that means one can write C, C++, Rust and automate the gui.
Freecad btw, very unfortunately, it loads each .so external library only once, and it will load the library only with different name or version number. I lost 5 hours messing up with Python versions and .venv installations till I figured that out.
Code is so low entropy that smaller and more economical models will be up to the task the same as gigantic models from big providers are today.
No worries there, the huge improvements we see today from GPT and Claude, are at their heart just Reinforcement Learning (CoT, chain of thought and thinking tokens are just one example of many). RL is the cheapest kind of training one can perform, as far as I understand. Please correct me if that's not the case.
In the economy the invisible hand manages to produce everything cheaper and better all the time, but in the digital space the open source invisible hand makes everything completely free.
> the open source invisible hand makes everything completely free.
In this case the limitation is the compute. Very few people have the compute required for AI/LLMs locally or for free (comparable to the performance of Claude). So yes, there are plenty of Open Source models that can be used locally but you need to invest in hardware to make that happen and especially if you want the quality that is available from the commercial offerings.
Not to speak of the training of those models. It's all there to make it possible to do this locally however where's the hardware? AWS? Google? There are hidden costs of the Open Source model in this case.
I agree with most of your points, but computation can be transferred from a place where energy is cheap to a place that is expensive. Energy for cooking cannot be transferred that way.
See for example Amazon-Google datacenters in the Gulf region. We've also got a whole continent, Australia, to put as many solar panels as we desire. Australia got dark for half a day, every day? Put solar panels to the opposite side of the planet.
Energy is a concern, for cooking, transportation etc. Energy for computation is not.
> We've also got a whole continent, Australia, to put as many solar panels as we desire. Australia got dark for half a day, every day? Put solar panels to the opposite side of the planet.
That is such an incredibly simplistic view and now how anything works.
Emacs can be configured with no code written by the user and Linux can be controlled with minimal user knowledge of the command line. Still some knowledge is necessary in most cases, but nowhere near what was required a handful of years back.
In my mind I had the opposite picture than the one the article portrays.
Emacs was lagging behind common IDEs, like IntelliJ and VsCode, cause big companies put thousands of developers to combine many features into one integrated package and everything works together providing a very smooth experience compared to Emacs (and Vim probably).
Now IDEs are useless. I personally haven't felt the need to goto_definition or autocomplete variable names for almost 2 years.
Now programming becomes closer to plain text writing and editing and it levels the playing fields for all editors.
Also Emacs can run Rust plugins, the user is not limited to Elisp. Not very convenient but possible.
> Now IDEs are useless. I personally haven't felt the need to goto_definition or autocomplete variable names for almost 2 years.
So you are vibe coding? Some of us still check every line of code generated and an IDE definitely helps with that. Even more so when you need to take control.
Porting code from one programming language to another will be one of the most important tasks of code gen A.I.
Imagine doing the same with vehicle engines. Less fuel consumption, less pollution, less weight and who knows how many more benefits.
Just letting the A.I. do it by itself is sloppy though. The real benefit is derived only when the resulting port is of equal or better quality than the original. It needs a more systematic approach, with a human in the loop and good tools to index and select data from both codebases, the original and the ported one. The tools are not invented yet but we will get there.
> What developers want and what the average consumer wants/needs are two different things.
This description of average consumer is so 2021. Nowadays the average consumer can vibe code stuff and share it with his friends. So he needs a package manager not only an app store.
I personally don't hold vibe coding in any high regard, I hate not knowing and controlling what code is running on my computer/device, but I can see the value for amateurs in just playing around and occasionally destroying the OS, installing it again and so on.
>Most avg consumers don't even know what Claude is[..]
Vibe coding is very early and pretty expensive, but computers and the internet are always in an exponential curve, a curve much steeper than the rest of the economy. Give it 3 years, and you will be amazed.
Not everyone will be vibe coding. In every social circle of 10 people, 1 person will be good at that, and will develop programs for his/her friends.
>Most vibed apps suck in unpredictable ways.
Yes of course, it would be infinitely preferable for normal people to learn proper computer science, algorithms etc. We agree on that.
Some centimeters might not sound much, but over millions of years, the cumulative effect might be that 1% of human population every 10.000 years gets genetically optimized to hold their heart at a more protective spot.