4 ms·

> Stack Overflow Its blessing and a curse. I think software would be better if coders read mans and other documentation more often (and standards like RFC wher

> Stack Overflow Its blessing and a curse. I think software would be better if coders read mans and other documentation more often (and standards like RFC where it is applicable). > git - Revision control that is low enough overhead that you need to have a reason not to use it. RCS - 1982 CVS - 1990 They are limited compare to git, but they perform the main function - track changes in text files allowing to see previous versions, a diff for each change, commit messages. CVS compare to tarballs for each release (or worse to a mess of files .bak, .bak2 e. t. c.) is a breakthrough. Subversion, Mercurial, git is IMHO just evolution of earlier VCS. > Package managers - By making it easy to include other peoples code we lower the bar to doing so. CPAN - 1993 FreeBSD pkg_add - 1993 > Open-source software as a commodity Here I fully agree. Opensource started to get some traction 20ish years ago (probably thanks to more widely available Internet and support from corporations like IBM), but its use is still growing. When I look back it seems to me that 1990s were very fruitful and the next 20 years progress in software was somewhat slower, but progress in hardware enabled previously impossible stuff without revolutionary changes in software.

wmanley 5y ago
The point was that these were either dismissed or weren't considered by Kay when describing breakthroughs in computer programming. They aren't breakthroughs in computer programming languages, but IMO are breakthroughs in computer programming. > RCS - 1982 CVS - 1990 I don't accept CVS as a breakthrough in the same way as git has been. Back in 2000 - 10 years after CVS - using source control wasn't a given. We had articles like "The Joel Test"[1] encouraging teams to use source control. CVS was a pain to set up and limited once you did. Thanks to git (and DVCS in general) using source control is the default for 1 person throwaway projects up to projects with thousands of contributors and million lines of code. [1]: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
- setpatchaddress 5y ago
  SVN fixed a lot of the issues with CVS, FWIW; setup, maintenance, robustness were much improved. But, yes, git was a major breakthrough. Even if you ignore the advantages of a DVCS and git's raw speed, git provides the ability to branch freely, with reasonable confidence that you can merge without spending days reconstructing your divergent source ("merge hell").
- citrin_ru 5y ago
  > We had articles like "The Joel Test"[1] encouraging teams to use source control. IMHO source control used more widely nowadays not thanks to git per se, but thanks to availability of free VCS hosting platforms like github.com Subversion IMHO is more beginner friendly than git, but we AFAIR didn't have good subversion platforms (with cheap of free private repos). Sourceforge added SVN in 2006 (which is late), but sourceforge GUI is an abomination and there are reasons not to trust it: https://en.wikipedia.org/wiki/SourceForge#Controversies https://en.wikipedia.org/wiki/SourceForge#Controversies
  - hnfong 5y ago
    I suspect this has a lot to do with the architecture of git allowing relatively "dumb" servers. To run a git server, you only need the capacity to receive, serve and compare git hashes and blobs. For SVN at least (last I used it), the server is expected to perform all sorts of potentially expensive operations (esp. for large repos): diffs, merges, branches, etc. since the client does not have the full repo/history. Given at the time computing power was less cheap, it would mean that hosting SVN services incurred a non-trivial cost. (And IIRC CVS was so bad that I don't think anyone in their right mind should actually try to host a free/cheap service around it.) Also, initial versions of SVN was released around 2004, while git 1.0 was technically in 2005. It took a while for people to get used to git, but given its technical superiority (and its momentum given Linus' approval) and being less demanding on the server side to host, hosting for git was a correct decision to make anyways.
cambaceres 5y ago
> I think software would be better if coders read mans and other documentation more often (and standards like RFC where it is applicable). MAYBE the quality on average would increase, but less software would definitely be created.

wmanley 5y ago

The point was that these were either dismissed or weren't considered by Kay when describing breakthroughs in computer programming. They aren't breakthroughs in computer programming languages, but IMO are breakthroughs in computer programming. > RCS - 1982 CVS - 1990 I don't accept CVS as a breakthrough in the same way as git has been. Back in 2000 - 10 years after CVS - using source control wasn't a given. We had articles like "The Joel Test"[1] encouraging teams to use source control. CVS was a pain to set up and limited once you did. Thanks to git (and DVCS in general) using source control is the default for 1 person throwaway projects up to projects with thousands of contributors and million lines of code. [1]: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

setpatchaddress 5y ago
SVN fixed a lot of the issues with CVS, FWIW; setup, maintenance, robustness were much improved. But, yes, git was a major breakthrough. Even if you ignore the advantages of a DVCS and git's raw speed, git provides the ability to branch freely, with reasonable confidence that you can merge without spending days reconstructing your divergent source ("merge hell").
citrin_ru 5y ago
> We had articles like "The Joel Test"[1] encouraging teams to use source control. IMHO source control used more widely nowadays not thanks to git per se, but thanks to availability of free VCS hosting platforms like github.com Subversion IMHO is more beginner friendly than git, but we AFAIR didn't have good subversion platforms (with cheap of free private repos). Sourceforge added SVN in 2006 (which is late), but sourceforge GUI is an abomination and there are reasons not to trust it: https://en.wikipedia.org/wiki/SourceForge#Controversies https://en.wikipedia.org/wiki/SourceForge#Controversies
- hnfong 5y ago
  I suspect this has a lot to do with the architecture of git allowing relatively "dumb" servers. To run a git server, you only need the capacity to receive, serve and compare git hashes and blobs. For SVN at least (last I used it), the server is expected to perform all sorts of potentially expensive operations (esp. for large repos): diffs, merges, branches, etc. since the client does not have the full repo/history. Given at the time computing power was less cheap, it would mean that hosting SVN services incurred a non-trivial cost. (And IIRC CVS was so bad that I don't think anyone in their right mind should actually try to host a free/cheap service around it.) Also, initial versions of SVN was released around 2004, while git 1.0 was technically in 2005. It took a while for people to get used to git, but given its technical superiority (and its momentum given Linus' approval) and being less demanding on the server side to host, hosting for git was a correct decision to make anyways.

cambaceres 5y ago

> I think software would be better if coders read mans and other documentation more often (and standards like RFC where it is applicable). MAYBE the quality on average would increase, but less software would definitely be created.