Live data from Hacker News

"We ran out of columns"

jimmyhmiller.github.io

361–370 of 588 posts

Re: "We ran out of columns"

#361
post #277

Earlier quoted context omitted.

> Git is not a natural development at all. Obviously, it is a standard right now. Git is actually an unnatural development. Its UI is atrocious. And it worked like crap on Windows for forever. Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got…

git didn't win because of GitHub. Sure, GitHub helped a lot. But actually, it's because its a DVCS, and it does branching and merging way better than anything I've seen so far. You can thank BitKeeper for all of this, and Andrew Tridgwell for forcing Linus Torvalds into creating git.

Yes, git has solved a big problem with version control: it has made transactional atomic changesets (commits in the git parlance) mainstream. A git repository is a tree of atomic changesets that group changes into meaningful chunks as opposed to a versioned tree of files where changes to each file are harder to trace back to the intent, i.e. whether or not they are related.

Atomic commits can also easily be moved around (since the repository is a tree of commits with the commits being leaves), and they also make merging simpler in many scenarios.

Larry McVoy was famously wont to engage in trolling upon the Linux Kernel Mailing List, whereupon he did boast of his BitKeeper, which possessed atomic changesets. Concurrently, he did deride Subversion for its lack of the same. Thus, a great drama did ensue, one which ultimately bestowed upon us the creation of git.

git has also succeeded as a DVCS where others have faltered, for various reasons. For there have been monotone, darcs and other such systems; yet, it is chiefly git that has endured.

Re: "We ran out of columns"

#362
post #290

Earlier quoted context omitted.

When I started my recent job the team kept referring to a box running "weird linux". After getting on-boarded and accessing the box it turned out to be running a very old version of OpenBSD. To this day I'm curious who had the wherewithall to install OpenBSD in prod but was seemingly ignorant of the 1yr support cycle.

I started reading and was hoping someone had installed one of the Linux distros that were popular at the turn of the millennium, like Mandrake, Slackware, etc. and it was still trucking along 25 years later.

Oldest boxes running are RHEL5 and Win Server 2008. I was trying to explain to the IT Director that both were released when I was in elementary school so I'd have to brush up on them.

Re: "We ran out of columns"

#363
post #360

When I started at my first company, they had a very complex VB application running on dozens of customers around the country, each having some particular needs of course. There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was ob…

These type of stories are a humbling reminder that PMF always beats engineering excellence

Well that depends entirely on what you consider to be the goal - as a software engineer, your role is entirely concerned with engineering excellence. As a member of a team, especially a team of extremely highly paid and highly educated individuals, it is your duty to spend your time (and thus, the company’s resources) efficiently by doing what you’re educated, qualified, and hired to do.

Re: "We ran out of columns"

#364
post #16

Earlier quoted context omitted.

> These days, my go-to solution is SQLite with two fields (well, three, if you count the implicit ROWID, which is invaluable for paging!): ID and Data, the latter being a JSONB blob. Really!? Are you building applications by chance or something else? Are you doing raw sql mostly or an ORM/ORM-like library? This surprises me because my experience dabbling in json fields for CRUD apps has been mostly trouble stemming f…

> my experience dabbling in json fields for CRUD apps has been mostly trouble stemming from the lack of typechecks Well, you move the type checks from the database to the app, effectively, which is not a new idea by any means (and a bad idea in many cases), but with JSON, it can actually work out nicely-ish, as long as there are no significant relationships between tables. Practical example: I recently wrote my own S…

“Without the need for any migrations” seems like a weird one to me. Of all of the things I don’t like having to do, migrations are pretty low on my list - far below any scripting-in-prod or applying hacks or even just rudimentary business logic changes. Granted, I used to fear them a lot back when I was expected to apply them by hand rather than use CICD and testing to validate/apply them

Re: "We ran out of columns"

#365
post #96

Earlier quoted context omitted.

We should use the Antarctic highlands as a prison colony for people found guilty of writing Stringly Typed Code. Siberia isn’t awful enough for them. I thought people who stuffed multiple independent values into a single database column were the worst and then I saw what people can accomplish without even touching a database.

No we should reserve the antarctic highlands for type system fetischists who write abstract protocol adaptor factory repositories for every damn simple piece of functionality.

That sounds more like an OOP thing than a type system thing - functional languages make excellent use of type systems without mention of anything remotely sounding like a “Design Pattern (tm)”

Re: "We ran out of columns"

#366
post #236

Earlier quoted context omitted.

I use CVS, RCS and Subversion on my personal projects for several years before I learned git. I don’t remember any of them being a pain to setup for small projects and Sourceforge provided free CVS hosting for small projects.

I've never actually set up CVS myself, so I suppose I can't accurately say how easy or not easy it is. The "nobody" might deserve an asterisk - I'm sure it's not literally not a single person, but it seems to be pretty rare in my impression. Nevertheless, AFAIK, the non-distributed nature seems pretty limiting. In Git, I can just create a local repo for anything, and I don't have to decide where I want it. I could ne…

I don’t think so, it’s been a while, but I think there were tools for copying history between cvs servers. I don’t remember CVS being particularly difficult to manage.

Re: "We ran out of columns"

#367
post #316

Earlier quoted context omitted.

You don’t think if the company behind GitHub went all-in on mercurial that might have emerged as the winner? There were plenty of companies using either. Git wasn’t the only distributed game in town. I definitely think GitHub had a lot to do with it.

Before there was GitHub there was Sourceforge. Sourceforge supported several different protocols and git still won. Gits internals can be confusing at first, but once you understand them there's really nothing you can't do. Being distributed by design also helps.

Sourceforge wasn't the only offering at the time.

Lots of companies were doing Git and Mercurial "forges" at the time. Many of them were better than Github.

Everything was evolving nicely (including Git and Github) until Github used VC money to offer everything for free to blow everybody out in order to lock people into their product (for example--export of anything other than code is still hit or miss on Github).

At which point, everything in the source control space completely collapsed.

Re: "We ran out of columns"

#368
post #277

Earlier quoted context omitted.

> Git is not a natural development at all. Obviously, it is a standard right now. Git is actually an unnatural development. Its UI is atrocious. And it worked like crap on Windows for forever. Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got…

GitHub won because it was good. SourceForge had a messy interface and frankly I hated it. Google Code was like frozen in time, like most Google projects. Microsoft’s thing — I don’t even remember the name — felt half assed and like they were going to abandon it… and they abandoned it. There were also others… none of which I even think were serious enough. Also Git won because SVN and CVS were centralized VCSes and yo…

You either meant Visual SourceSafe or Team Foundation Server for the Microsoft product.

SourceSafe did get abandoned... because your source wasn't actually safe in it.

Its replacement, Team Foundation Server got rebranded as Azure DevOps; but the product's still around, 19 years later.

Re: "We ran out of columns"

#370
post #316

Earlier quoted context omitted.

Before there was GitHub there was Sourceforge. Sourceforge supported several different protocols and git still won. Gits internals can be confusing at first, but once you understand them there's really nothing you can't do. Being distributed by design also helps.

Sourceforge was complete garbage though. I hated, hated when projects were hosted on it. It was slow, full of ads, impossible to find what you need to download.. GitHub is to sourceforge what Facebook was to MySpace. MySpace was first but it was buggy as hell.

That comparison is pretty harsh and really underemphasizes how awful sourceforge was. Myspace was mostly fine, death by feature creep. Sourceforge was a flaming pile of garbage that was poorly designed, ad laden, AND silently bundled in ad/spyware to normal downloads.

A more apt comparison would be comparing Facebook to a hypothetical social media site that when you click on a thumbnail of a user's image, you get a fullsize image of something like goatse...which thankfully doesn't exist(yet).

Post reply on HN