Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I wonβt usually need your flowcharts; theyβll be obvious.
I'd also like to point out that unlike every single horror I've ever
witnessed when looking closer at SCM products, git actually has a simple
design, with stable and reasonably well-documented data structures. In
fact, I'm a huge proponent of designing your code around the data, rather
than the other way around, and I think it's one of the reasons git has
been fairly successful (*).
So it's easy enough to just write whatever Java code or something to just
access the databases yourself. The object model of git may be smart, but
it's neither proprietary nor patented. I suspect it's often a lot easier
to integrate git into other projects _that_ way, rather than try to
actually port the code itself.
Linus
(*) I will, in fact, claim that the difference between a bad programmer
and a good one is whether he considers his code or his data structures
more important. Bad programmers worry about the code. Good programmers
worry about data structures and their relationships.
Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
Starting at 4:21: www.youtube.com/watch?v=EKWGGDXe5MA&t=261s
A computer is a, high-class, super speed, nice, streamlined filing system.
...
One of the miseries of life is that everybody names thing a little bit wrong
...
[A] computer does not primarily compute in the sense of doing arithmetic. Strange. Although they call them computers that's not what they primarily do. They primarily are filing systems. People in the computer business say they're not primarily computers, they're data handlers.