3 ms·

I hate to sound negative, but things won't get better. OK, this month has been a shocker, but next year might be just as bad. The real fundamentals of computin

by wisty 15y ago

I hate to sound negative, but things won't get better. OK, this month has been a shocker, but next year might be just as bad. The real fundamentals of computing happened a long time ago. Hero of Alexandria, some Chinese and Islamic scholars, Albertus Magnus, Roger Bacon, Charles Babbage, Ada Lovelace, Joseph Marie Jacquard, Turing, non Neumann. But progress was linear, not exponential - the tools they made were so impractical that they didn't make further tools easier. You used a computer as a curiosity, or to solve a specific problem, not to build a better computer. Then the singularity hit. Computers got faster, IO got richer, and you could practically write computer programs that would help you write computer programs. It's hard to say exactly when that happened, but the inventions of C, UNIX, and Lisp were certainly part of that critical period in history. This shift started around the mid-1960s to early 70s. The people who were working on it are now in their 60s and 70s. The next generation (who are in their 50s and 60s) wasn't just inspired by them, they were given very useful tools, which made later advancements easier. It's easier to write a C++ compiler if you already have a C compiler. It's easier to write git if you have a CVS repo to store your work in. People no longer had to bootstrap using nothing but assembly, they started with a sound foundation, and could iterate. Because of the work of these founders, I think there's a lot more icons left.

bad_user 15y ago
It's easier to write git if you have a CVS repo to store your work in Not to diminish your point or anything, but regarding Git, I'll just quote Linus Tolvards: For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is Basically Git started as a bunch of scripts written by Linux for dealing with "tarballs and patches" and nobody starts something like this unless there's lots of hatred involved. What you get if you're a CVS user and want something better is SVN. You get Git when you consider CVS such an abomination that you'd rather do without any existing VCS altogether. And I really think the world needs more people like Linus, as some wheels are worth reinventing. The real fundamentals of computing happened a long time ago. In the words of Alan Kay: The computer revolution hasn't happened yet ... http://video.google.com/videoplay?docid=-2950949730059754521 http://video.google.com/videoplay?docid=-2950949730059754521 (listen to this talk because it's great).
- scott_s 15y ago
  I think it's worth noting that git did not replace tarballs and patches. Git replaced Bitkeeper. Bitkeeper, as far as I know, replaced tarballs and patches. And as far as I know, git did not start as a bunch of scripts for dealing with tarballs and patches. The design was inspired by his knowledge of and experience with Bitkeeper.
  - bad_user 15y ago
    The workflow was indeed inspired by Bitkeeper, nothing is truly revolutionary, but Bitkeeper itself was not the status quo in a world dominated by CVS, SVN and Perforce. On "tarballs and patches", I was referring to this famous quote from http://marc.info/?l=linux-kernel&m=111288700902396 http://marc.info/?l=linux-kernel&m=111288700902396 ... So I'm writing some scripts to try to track things a whole lot faster. Initial indications are that I should be able to do it almost as quickly as I can just apply the patch, but quite frankly, I'm at most half done, and if I hit a snag maybe that's not true at all. Anyway, the reason I can do it quickly is that my scripts will _not_ be an SCM, they'll be a very specific "log Linus' state" kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible.
    - scott_s 15y ago
      Bitkeeper was not the status quo, but I don't think that's important in the overall point. The original point was that git was inspired by previous software. The original software pointed at, cvs, was wrong, but I don't think the original point changes when we put the correct software, Bitkeeper, in its place in the sentence.
      - bad_user 15y ago
        Yes, but I included a "not to diminish your point" right in the first sentence. This was just a facts correction because I find the story of Git being fascinating.

by wisty 15y ago

bad_user 15y ago

It's easier to write git if you have a CVS repo to store your work in Not to diminish your point or anything, but regarding Git, I'll just quote Linus Tolvards: For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is Basically Git started as a bunch of scripts written by Linux for dealing with "tarballs and patches" and nobody starts something like this unless there's lots of hatred involved. What you get if you're a CVS user and want something better is SVN. You get Git when you consider CVS such an abomination that you'd rather do without any existing VCS altogether. And I really think the world needs more people like Linus, as some wheels are worth reinventing. The real fundamentals of computing happened a long time ago. In the words of Alan Kay: The computer revolution hasn't happened yet ... http://video.google.com/videoplay?docid=-2950949730059754521 http://video.google.com/videoplay?docid=-2950949730059754521 (listen to this talk because it's great).

scott_s 15y ago
I think it's worth noting that git did not replace tarballs and patches. Git replaced Bitkeeper. Bitkeeper, as far as I know, replaced tarballs and patches. And as far as I know, git did not start as a bunch of scripts for dealing with tarballs and patches. The design was inspired by his knowledge of and experience with Bitkeeper.
- bad_user 15y ago
  The workflow was indeed inspired by Bitkeeper, nothing is truly revolutionary, but Bitkeeper itself was not the status quo in a world dominated by CVS, SVN and Perforce. On "tarballs and patches", I was referring to this famous quote from http://marc.info/?l=linux-kernel&m=111288700902396 http://marc.info/?l=linux-kernel&m=111288700902396 ... So I'm writing some scripts to try to track things a whole lot faster. Initial indications are that I should be able to do it almost as quickly as I can just apply the patch, but quite frankly, I'm at most half done, and if I hit a snag maybe that's not true at all. Anyway, the reason I can do it quickly is that my scripts will _not_ be an SCM, they'll be a very specific "log Linus' state" kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible.
  - scott_s 15y ago
    Bitkeeper was not the status quo, but I don't think that's important in the overall point. The original point was that git was inspired by previous software. The original software pointed at, cvs, was wrong, but I don't think the original point changes when we put the correct software, Bitkeeper, in its place in the sentence.
    - bad_user 15y ago
      Yes, but I included a "not to diminish your point" right in the first sentence. This was just a facts correction because I find the story of Git being fascinating.