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.

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.

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.

Comments URL: https://news.ycombinator.com/item?id=47512028

Points: 3

# Comments: 0

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.

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.

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.

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.

Less than 3000 volts cannot be felt by humans? Should be 3000 millivolts right? i.e. 3 volts...

The idea of origami steel sheets has stuck on my mind ever since I found out about laser welding. Cutting thin 2mm sheets of steel, stitching them back together in different shapes, and holding tons of weight? That sounds very compelling to me.

[1]https://www.youtube.com/watch?v=FNVBK7-h9Fs

The unfortunate thing for Python that the repomap mentions, and untyped/duck-typed languages, is that function signatures do not mean a lot.

When it comes to Rust, it's a totally different story, function and method signatures convey a lot of important information. As a general rule, in every LLM query I include maximum one function/method implementation and everything else is function/method signatures.

By not giving mindlessly LLMs whole files and implementations, I have never used more than 200.000 tokens/day, counting input and output. This counts as 30 queries for a whole day of programming, and costs less than a dollar per day not matter which model I use.

Anyway, putting the agent to build the repomap doesn't sound such a great idea. Agents are horribly inefficient. It is better to build the repomap deterministically using something like ast-grep, and then let the agent read the resulting repomap.

Large language models and small language models are very strong for solving problems, when the problem is narrow enough.

They are above human average for solving almost any narrow problem, independent of time, but when time is a factor, let's say less than a minute, they are better than experts.

An OS kernel is exactly a problem, that everyone prefers to be solved as correct as possible, even if arriving at the solution takes longer.

The author mentions stability and correctness of CCC, these are properties of Rust and not of vibe coding. Still impressive feat of claude code though.

Ironically, if they populated the repo first with objects, functions and methods with just todo! bodies, be sure the architecture compiles and it is sane, and only then let the agent fill the bodies with implementations most features would work correctly.

I am writing a program to do exactly that for Rust, but even then, how the user/programmer would know beforehand how many architectural details to specify using todo!, to be sure that the problem the agent tries to solve is narrow enough? That's impossible to know! If the problem is not narrow enough, then the implementation is gonna be a mess.

An interesting question is, if pre-trained specialized models are available for a thousand or ten thousand most common tasks humans do every day, of what use a general model could be?

Go around, and ask people if they want a free secretary, see if someone doesn't want one.

They will not ask a computer program to do stuff. They will talk to the secretary, and the secretary will do any computer stuff necessary. For the moment the secretary cannot click buttons and menus as well as manipulate language. The secretary will have realistic skin and lips, and a dress as short as required by the job description.

Language AI is the king of AIs, and the gap will only get bigger. Everything will be tied to language going forward, driving, surgeries and so on.