Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Your "rethinking" is "let's AI write and version control the code."

Very deep.

AI, for the moment, cannot write anything outside of what is already written. It just so happen that my interests are in the very strange problems where no code has been written thus far, except by me and for me. AI is not helpful there at all.

I am not even starting on the tasks that are formulated like "DUZ BY ... WITH KUMAJ is not supported" that has to be solved in code base that is a million LOC or so (50 million bytes) and is itself a part (and user of) of much, much larger code base.

Finally, git was a de-improvement on darcs, which predates git by two years, if I remember correctly. Darcs was way ahead of git in everything but speed, including an attempt to view text as structure (darcs has a Rename change where one identifier gets renamed into other). Pijul is contemporary rethinking of what darcs offer.

So, pijul is not an iterative improvement upon git. It is improvement upon darcs which represents a start of separate lineage of DVCS, that tried to include many things you mentioned.

Except using AI, of course.



> Your "rethinking" is "let's AI write and version control the code."

It's not. There are several semantic diffing tools that do a much better job at showing relevant changes than simple line-based diffs. This is all done without AI.

My point is that a VCS written from the ground up with this knowledge would offer a much better UX than current tools.

My second point mentions AI as the next step in the progression, since it's clear that it will affect how humans write code in the very near future.

> Very deep.

I don't appreciate the snark.

This is not some deeply unique line of thinking.

> AI, for the moment, cannot write anything outside of what is already written.

You're underestimating the power of combining written chunks of code to produce a unique solution. Most software is written by glueing existing code together and using libraries. AI can do this reasonably well today. What do you think it will be capable of in 5 years? 10?

> It just so happen that my interests are in the very strange problems where no code has been written thus far, except by me and for me. AI is not helpful there at all.

I think you're overestimating the uniqueness of your code. Is it really all original? You're writing everything from scratch with novel, never before seen approaches? I doubt that very much.

There's a reason why design patterns exist. Many solutions can benefit from following existing patterns. AI today can help automate with writing common patterns, and also with any chore work like writing tests. It's helpful even if it's not writing those novel solutions you still have to do yourself.

Besides, none of this is relevant for a VCS. AI doesn't need to have superhuman programming skills to manage versions. It would just be foolish to not use its current capabilities to understand changes better, and help us take the chore out of dealing with version management.


>Most software is written by glueing existing code together and using libraries. AI can do this reasonably well today.

>I think you're overestimating the uniqueness of your code. Is it really all original? You're writing everything from scratch with novel, never before seen approaches? I doubt that very much.

You can doubt that. Yes, of course.

One kind gentleman here introduced me to worst-case optimal join algorithms and I designed one myself. It uses Bloom filters represented as binary decision diagrams, really nothing fancy.

You can try asking AI to write you a Bloom filter represented as binary decision diagrams. I doubt you will get anything interesting and/or useful.

>There's a reason why design patterns exist. Many solutions can benefit from following existing patterns.

This is history repeating itself.

Functional languages do not require that much of design patterns. In fact, functional programming can hide complexity so well that uncovering it can produce exponential blow up in code size. And type systems greatly benefit writing complex systems. I know because I programmed in almost all kind of languages (typed, untyped, dynamic, static, Turing-complete, total, etc) and programing paradigms existing (including term rewriting systems).

I doubt you use Haskell for your work, which is functional and has rich and powerful type system.

The same will be with AI. You can proclaim it will change the world, but similar tools readily available for quite some time did not.

Returning to AI and VCS, the presentation that started our discussion shows a principal problem with VCS, at 7:06 or so. We can make a changeset that will provoke any merging/conflict-resolution algorithms into making a silent mistake. Pijul postpones this problem, I think, not rids of it.

AI does not report a problem, it hides it, and lies. Nobody, to my knowledge, was able to make any AI to admit it does not have a clue about thing it clearly has no clue about.

So if we certainly will have a mistake in our merging process, AI will certainly lie about it. The code after merging-with-AI shall be tested and reviewed, there is no short-cuts there.

So, why bother?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: