emporas

I am experimenting with using A.I. to see an image, and generate TinyScheme code to draw it on Gimp. As soon as I got the code for a 2D representation, then I bring out the heavy weaponry, Rust and Freecad, and with some more information added I generate the 3D representation of a building.

A.I. generally shines when the steps are small and incremental. I would add that, when A.I. is used properly, generating code and hopping from one code to another, it should be better than any human already.

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.

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.

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.

Does the same scan is happening on firefox? Random websites invoking extensions do seem to be a security hole to me.

>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.

>In this case the limitation is the compute.

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.

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.

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.

That's superb. A very good literature story could be written based on that.

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.

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.

>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.

> 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.

In some other news, new accounts on MoltBook use em-dashes a lot less than normal. Bots are tricked by humans posing as intelligent machines!

Not all code qualities are free. Good quality code, still expensive.

> Destructive static charges are induced on nearby conductors, such as human skin, and delivered in the form of sparks passing between conductors, such as when the surface of printed board assembly is touched by a person having a static charge potential. [..] It is important to note that usually the static damage level for components cannot be felt by humans. (Less than 3,000 volts.)

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

There is also 3d printing origami shapes [1]. But 3D printing is still plastic(usually).

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

Aider's repomap is a great idea. I remember participating in the discussion back then.

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.

You don't need a workflow. The agent is the workflow. That's the idea at least. Probably not a great idea IMHO, because producing high quality code is the main difficulty of programming. Everything else, committing to git, deploying etc, pale in comparison.

Vibe coding is entertainment. Nothing wrong about entertainment, but when totally clueless people connect to their bank account, or control their devices with vibe coded programs, someone will be entertained for sure.

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.

Context learning means learning facts or rules without pre-training. They are two distinct phases.

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?

Not true. They want to talk to their secretary, and the secretary do it for them.

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.

I am writing a Context Retrieval and Context Minimization program for Rust code. I am trying to automate my own workflow in how I use LLMs.

The program is gonna do, what I am currently doing by hand, opening files and copying function/method signatures usually, from files all over the place.

The key here is to fetch into the context window only what is needed for one-question/one-answer and no more, hence the Context Minimization. Context fetched is gonna be specified by the programmer, for example sig(function) fetches only the signature, while @function captures the whole body. sig(Struct) is gonna fetch the fields and signatures of all of it's methods. sig(Trait) similarly.

In my view, giving the A.I. more information than needed, only confuses it and accuracy degrades. It is also slower and more expensive but that's a side effect.

The project is in early stages, for the moment it calls ast-grep under the hood, but eventually, if it works as it is supposed to, I plan to move to tree-sitter queries.

If there is a similar project somewhere I would appreciate a pointer to it, but I am not interested in implementations of agents. My program does not give the A.I. a whole view of the codebase, only the necessary points specified by the programmer.

I use Linux exclusively for almost 20 years. I can tackle any tinkering of almost anything in a Linux environment, alongside of heavy use of Vim and Emacs.

Nowadays every time I want to run a non-trivial command of a program, configure a file somewhere, customize using code Emacs or anything else, I always put the LLMs to do it. I do almost nothing by myself, except check if said file is indeed there, open the file and copy paste the new configuration, restart the program, copy paste code here and there and so on.

No need to be a nerd to use Linux, that's so 2021. LLMs are the ultimate nerds when it comes to digging into manuals, scour the internet and github for workarounds, or tips and tricks and so on.

When a bank eventually requires a more recent phone to work, they will carry three phones, one for that one bank, one more for the rest of the banks, and a personal one.

Then they might move somewhere else with different banks and different hardware requirements, they will carry 5 phones.

Linux is valuable, because very difficult bugs got fixed over time, by talented programmers. Bugs which would cause terrible security problems of external attacks, or corrupted databases and many more.

All difficult problems are solved, by solving simple problems first and combining the simple solutions to solve more difficult problems etc etc.

Claude can do that, but you seriously overestimate it's capabilities by a factor of a thousand or a million.

Code that works but it is buggy, is not what Linux is.

>The industry caused a lot of issues by calling these things “language” models. They’re not, they’re word models.

I agree 100%. Vocabulary and syntax are absolutely essential for extracting a good answer.

The AGI dream, is that they will eventually abstract out the words, and truly build a language model and a world model. Till that moment, they are a word model.