Since I am by far the most experienced user of V, I have therefore also first-hand experience with all the different ways in which *all* implementations of V so far (v.py, v.pl, v.sh & vtools) fail in practice as soon as applied to any production code base with all its complex changes and significantly large sets of vpatches. To keep this short, I'll point out¹ just the total deal breakers for me²: the reliance on Koch's gpg, the imposition of arbitrary restrictions due to limitations of various underlying tools imported but not truly adapted to purpose³, combined for maximum damage with a non-existent, utterly and even at times worse than useless approach to "error reporting" that would be better described as "error non-reporting with a dash of retroactive error discovery"⁴.

None of the above problems have anything to do with the V paradigm itself, of course. They are all simply the problems of the v.py, v.pl and v.sh & vtools implementations and moreover, to be found exactly at the very places where these implementations depart from the V principles. So the cut is clear enough: there's nothing to salvage from the v.py, v.pl and v.sh & vtools. Sure, they have the excuse of being "just drafts", fine. That excuse tends to wear thin after these many years but sure, they are all first drafts at best and as such to be entirely discarded, indeed, so this is exactly what I'm doing, too: I'm discarding them all and I state it here publicly as I owe it to anyone who might read otherwise my equally public previous use of them - they are fine as first drafts and *nothing* more, definitely *not fine* for production use of any sort.

Moving on, I'll implement V for production use as well, with everything adapted to purpose, from cryptography to diff-ing, pressing and everything in between. There's neither need nor any bit of desire to rely on anything that is neither fit for purpose nor adaptable to it and that includes python, perl, gnupg modules of any sort, gpg etc.

1. Mainly for the benefit of anyone considering using any of these first-draft implementations. Use at your own future inconvenience and for your own future loss. ↩

2. If you really need more, go ahead and ask me in the comments section. ↩

3. Such as "can't revert a file" - note that this restriction is simply due to the limitations of the underlying diff that works with file-level hashes, nothing else, despite all the pretense that there is any higher-level reason why such limitation is even desirable. If you really mean that this is a feature and not a bug, go ahead and argue it in the comments but do make sure your argument includes the reason why reverting a function or procedure is at the same time somehow different and perfectly ok. I'll also add that if you really think that one should just know from memory, at vpatch 80 when they remove a function from a file that the result is in fact reverting that file to its version from vpatch 55 then good luck to you, enjoy the toy v implementations and more power to you. ↩

4. What this means in practice is that you are left to hunt manually for the actual source of the problem and at times this hunt is even potentially extending all the way into the past - you might find out at vpatch 90 that the V-error was introduced... somewhere before, in any of the previous vpatches, aren't you happy to go and search for it in all the tree? For example, v.py will just spit "Cyclic graph" at you and you are welcome to hunt for the 2 vpatches involved and then for the 2 (or more!) files (hashes) involved and so on. V.sh and vtools will construct the vtree correctly by looking at the vpatches as whole units but then will fail at press time because the press still looks at files individually. ↩

Category: Coding, V

Comments feed: RSS 2.0