Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

Lots of things happened fast during WWII.

One of the big reasons, was that regulatory hurdles were removed.

The result:

Long Island is one big Superfund site, and our cancer rates are through the roof. I know of at least six women, in my immediate orbit, that are currently being, or have recently been, treated for breast cancer.

Before I moved here, thirty-two years ago, I had never met anyone that had cancer. Since moving here, I have known at least one person per year (often more), that had/have cancer.

Part of that is probably age, as I've gotten older, so too, has my peer group, but I wasn't that old, in 1990, when I moved here.

The difference is that they died a lot more frequently, back then.

View on HN

Not to knock the success of git, or the amazing effort under pressure, but the cohesiveness / understandability could be better.

That's a good point.

But Git was initially written by one cranky Finn, in ten days.

It totally changed the way we all work.

JavaScript was also famously built in 10 days.

I'd say that internally git is more consistent %)

JS on the list is quite interesting, since it being rushed and a prototype ending up getting shipped often gets cited as an explanation for why JS has issues. Given how widespread it is, this is a project I wish had gotten a lot more time. An argument could be made that it succeeded, so it must be good, but given it's the only built-in, full language in the browser just says that it was good enough and now we are kinda stuck with it.

Indeed, there was no choice.

Good thing we ended up with a small language that has easy objects, first-class functions, and compact syntax. We could have got something like ABAP were we really unlucky.

As much as I couldn't live without complaining about Javascript's shortcomings, I have to agree with this. At the time, many of the features you mention were hardly necessary - no one was considering using it to build giant web apps, let alone servers! The fact that people decided they could do those things and the language was sufficiently flexible to grow along those lines would probably be very surprising to the original developer. For having such a chaotic evolution, it's becoming a much better language than anyone would have a right to expect.

Kind of like English, which is also a terrible choice for a global language, it's shown a fairly powerful ability to incorporate new idioms.

I don't believe this. Someone who knows how to design and implement a language with real closures, prototype-based inheritance, a garbage collector, etc. also knows the value and power of those things, used them before extensively and knows how far they can go. Also, the shortcomings that everybody loves to talk about are mostly misunderstood features (yes, even == which everybody loves to hate), and mostly by programmers who wouldn't even know where to start designing a language.

True, as much as JS sucks, some of its fundamentals are really good

Deity helps us if it was really Javascript with complete disregard for first order functions and verbosity through the roof

> JavaScript was also famously built in 10 days

And boy does it show!

> But Git was initially written by one cranky Finn, in ten days. It totally changed the way we all work.

To be fair, Linus was trying to replace Bitkeeper, a proprietary DVCS which he'd been using to maintain the kernel for several years at that point. Mercurial, which runs on similar principles, was around at the time too. He didn't just make a quantum conceptual leap straight from SVM to git on his own in 10 days; he had a pretty good idea what he wanted to build (probably even ideas about the architecture) before he started.

It's still darned impressive; just not supernaturally impressive. :-)

I see this as kinda the flipside of "how to draw an owl" [1]. A smarter programmer than me once described software as "do 90%, then do the other 90%" - the mvp, first functional prototype, heck, even the first deliverable is great and all, but then it's time for the thing to live and breathe and go out in the real world and learn all about what it'll become someday. Thus was born semantic versioning.

On the other end of that, like what you're talking about, you have the artist who answers "how long did it take you to paint that?" with: "my whole life". I think this holds true in most disciplines and especially in software. The actual code that makes a thing work is trivial - but you have to know which of the 9 gazillion ways of doing it is the one you want, which only comes from experience.

1 - https://imgur.com/RadSf

https://xkcd.com/2730/

I've also read that Linus was pretty influential in BitKeeper design too. As in Larry McVoy would sit down with Linus to talk about the design of it. Git's core data structures had probably been bouncing around in Linus's head for months before first line of code was written.

If you know both BitKeeper and Git internals, you can think of their data models as near identical, with BitKeeper implementation using text files and SCCS, and Git using from-scratch data structures.

Just want to mention this because this parable gets thrown around a lot.

The delta between what git is now and what it was when first released is massive. Junio Hamano has been a absolute force of a maintainer and steward over the interim 18 years (!!) since 2005.

This story often gets tossed around, as if to imply all of what git is today was put out by Linus in 2 weeks, but I think it suffers from a bit of a hero worship problem. It was no doubt impressive and should be recognized, but I just want to make it clear: Git was made by many people over many years.

I think that’s mostly understood. It’s up there with “JS was implemented in a week.” Yet in both cases, the skeleton defined the rest of the animal; git and JS are still recognizable from that initial version, even if the diff is massive.

Maintainers should get more credit, but the hero worship isn’t entirely misplaced. It’s not often that someone gets to change the world.

Twice.

That's par for the course, these days.

I was the original author of multiple systems that have lasted decades, but I'll bet that you'd be hard-pressed to find much of my original code, in the current iterations.

Most of the inconsistencies, like "checkout" having three different functions, were added much later, in attempts to make UX niftier locally, without thinking about the product as a whole.

Checkout can move your head to different commit and it can copy files to your working tree from a non-checked-out commit. What's it's third function?

It can create a branch with -b, based on a branch of your choice (not necessarily current).

I constantly use this, having created an alias:

  [some other branch]$ git cob feature/foo123 main

Eh, I can squint and see that as a special-case of moving your head to another ref - the `-b` merely flagging "if this branch doesn't exist, create it instead of erroring".

It's a bit like building a train station is a special case of arriving to it :)

maybe like mkdir + chdir

It's arriving at it with trucks and bulldozers and other equipment repeatedly, but essentially yes.

For what it’s worth, this is now being separated out a bit to be clearer. You can use `git switch <branch>` to switch to an existing branch, `git switch --create <branch>` to create a new branch and switch to it, and `git restore <file>` or `git restore --source <ref> file` to restore a version of a file to your working directory.

Reply on news.ycombinator.com