"We ran out of columns" • Hacker News Board

Re: "We ran out of columns"

#271

Post by mewpmewp2 » Sat, Aug 03, 2024, 10:02 PM UTC

gumby wrote: post #211

fouronnes3 wrote: post #130

Earlier quoted context omitted.

This is amazing. I can so well imagine a bright young hire joining that team, helpfully offering to "setup this thing called git" only to be laughed out of the meeting by all the "senior" staff.

Astonishingly, It took a long time for revision control to become widespread. Around 1991 when Cygnus had 6-7 employees and was based in the apartment complex where I lived, none of the GNU codebase was hosted in any sort of revision control. Everything was FTPed around as obscurely named tarballs. We had gathered something like 27 different forks of gdb floating around the net, for example. This was back when forkin…

Why is it astonishingly?

Git is not a natural development at all. Obviously, it is a standard right now.

But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point.

I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out professionally.

Obviously now that I have over a decade of professional experience I think it's a no brainer, but I don't think it's natural to understand it as it's suggested to you. I at least kind of had to go along with it and trust that it's good. It felt frustrating at first as many other things are. Git as a thing was FAR more difficult for me to understand in my 20s than PHP and how to do anything with it was for me at teens. Coding is raw logic, Git is about imagining teamwork at scale, which is a whole other thing.

The funny thing is that I feel like I was overall still more productive when I was at my teens building stuff solo with FileZilla and PHP, compared to a corporate environment now with all the processes and 1000s of engineers.

Re: "We ran out of columns"

#272

Post by fragmede » Sat, Aug 03, 2024, 10:05 PM UTC

alt227 wrote: post #180

bdcravens wrote: post #87

A couple of weeks ago I had a flat on the way to the airport. It was a total blowout, and my car doesn't include a spare. We were already over budget on our trip, so I had the car towed to the closest tire shop and had them put on the cheapest tire that could get me to the airport. I know I'll need to replace other tires, as it's an AWD, and I know it's not a tire I really want. I made a calculated choice to make tha…

Aside - the fact that cars dont include spares these days is infuriating. IMO its a classic example of real world enshittification

that's not enshittification!

it sucks, yes, but when coined, the term referred to a platform extracting value from its users by degrading their experience, forcing them to upgrade to a premium plan. your car not having a spare isn't an example of that!

https://en.wikipedia.org/wiki/Enshittification

Re: "We ran out of columns"

#273

Post by Klonoar » Sat, Aug 03, 2024, 10:05 PM UTC

bartekpacia wrote: post #253

grishka wrote: post #237

The worst codebase I've ever worked on was the Telegram client for Android. I mean just look at this file, it's so huge GitHub gives up rendering it: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/... Or this one, it implements EVERYTHING for rendering and interacting with a message in a single class, all non-service message types, all drawn manually on a canvas "for performance", and all input processed…

It’s even more crazy because Telegram is by far the smoothest messenger app on Android. BTW, would you mind sharing how you got that job?

They didn't specify it was their job, the project is open source after all.

Re: "We ran out of columns"

#274

Post by tsujamin » Sat, Aug 03, 2024, 10:10 PM UTC

vertis wrote: post #181

deathanatos wrote: post #154

Two early databases I worked on. The first contained monetary values. These were split over two columns, a decimal column holding the magnitude of the value, and a string column, containing an ISO currency code. Sounds good so far, right? Well, I learned much later (after, of course, having relied on the data) that the currency code column had only been added after expanding into Europe … but not before expanding int…

Reminds me of a date column where half the dates were MM/DD/YYYY and the rest DD/MM/YYYY. I did manage to eventually find the point in time when it changed and normalise the database. For those wondering about DD/MM, Australia.

And most countries :)

https://en.wikipedia.org/wiki/List_of_date_formats_by_countr...

Re: "We ran out of columns"

#275

Post by paulddraper » Sat, Aug 03, 2024, 10:16 PM UTC

djbusby wrote: post #247

cyberax wrote: post #184

Earlier quoted context omitted.

> And the blame went to...CVS somehow. CVS was notorious for doing "text/binary" conversions (CR/LF line endings to CR and vice versa), sometimes inappropriately. More than once, it resulted in files where every other line was empty. I can very well see this happening several times, resulting in exponential growth of whitespaces.

Yep, that bit me/my teams more than once. But this case we had the commit from CVS showing it was just a fat-finger. But the seniors on the team pointed to CVS. Not the individual, not the "test" process, not the deploy checks. Nobody noticed it slow cause everything ran on LAN. Only noticed the issue on 56k

That's a really fat finger

Re: "We ran out of columns"

#276

Post by [deleted] » Sat, Aug 03, 2024, 10:17 PM UTC

xpressvideoz wrote: post #243

Elasticsearch and OpenSearch have a similar issue. They have a soft limit on the number of "searchable" fields (called "mapping") a table can have (by the way, a table is called an "index" in their terminology. How confusing!), which is 1000. We ran into this problem because we tried to jam all the logs in every single microservice into a single table. Each microservice had a different log format, so after combining…

[deleted]

Re: "We ran out of columns"

#277

Post by bsder » Sat, Aug 03, 2024, 10:19 PM UTC

mewpmewp2 wrote: post #271

gumby wrote: post #211

Earlier quoted context omitted.

Astonishingly, It took a long time for revision control to become widespread. Around 1991 when Cygnus had 6-7 employees and was based in the apartment complex where I lived, none of the GNU codebase was hosted in any sort of revision control. Everything was FTPed around as obscurely named tarballs. We had gathered something like 27 different forks of gdb floating around the net, for example. This was back when forkin…

Why is it astonishingly? Git is not a natural development at all. Obviously, it is a standard right now. But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point. I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out…

> 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 out of their way and was generally fine.

Then Github won due to VC cash dumping and foisted Git on all of us. Source control was no longer fine.

Thankfully, there is now Jujutsu(jj) which works on top of the Git storage layer so you can forget about the craptastic UI of Git. Source control is now fine again.

Re: "We ran out of columns"

#278

Post by jiggawatts » Sat, Aug 03, 2024, 10:19 PM UTC

lemme_tell_ya wrote: post #83

My first day at my first full-time programming gig, I was asked to look at some reporting job that had been failing to run for months. I logged in, found the error logs, found that it needed a bit more memory assigned to the script (just a tweak in the php.ini) and let the team lead know it should run fine that night. He was shocked, "Dude, if you just fixed that report you probably just got a promotion, no one has b…

The reverse also applies, where people that like Linux just totally ignore Windows maintenance. They’ll look down their noses at it and say that it’s insecure when they spend their time patching Linux and leaving Windows to fend for itself against attackers.

Re: "We ran out of columns"

#279

Post by arghnoname » Sat, Aug 03, 2024, 10:19 PM UTC

dmd wrote: post #77

Probably some of the worst code I ever worked on was a 12k+ line single file Perl script for dealing with Human Genome Project data, at Bristol-Myers Squibb, in the late 1990s. The primary author of it didn't know about arrays. I'm not sure if he didn't know about them being something that had already been invented, or whether he just didn't know Perl supported them, but either way, he reimplemented them himself on t…

If I were being charitable (sometimes I try), I'd guess he was concerned that an array of scalars is going to have a high per scalar size overhead and perhaps worse cache locality, whereas the non-unicode perl string implementation at the time probably just stored the string as a large char* with a length prefix.

In a similar vein, an alternate explanation may just be that a lot of bioinformatics algorithms are described as string algorithms. It would be a pity if that was just taken too literally, but I've seen a lot of bioinformatics perl that works on strings in this way.

While trying to be charitable though, it's almost impossible to come up with a rationalization for the three character offsets string. Sometimes I think when people really go wrong is when they hear of some problem or are trying to be too clever and end up going beyond their abilities and stray into farce.

Re: "We ran out of columns"

#280

Post by dave7 » Sat, Aug 03, 2024, 10:21 PM UTC

For online Poker, one of the current database tools runs in to this issue - PokerTracker 4 (PT4).

These tracker databases are usually used to generate a HUD - numerical readouts surrounding each player shown on the table. PT allows for custom HUDs to be saved/exported/shared, and there is a cottage industry building and selling such HUDS. These HUDs can often bundle hundreds of custom stats - basically a subset of SQL queries, a simple example would be "times_raised / opportunities_to_raise WHERE position= 'button'", that sort of thing.

For performance reasons these custom stats are cached, which obviously makes some sense. However, each cached stat creates a new column in the custom_cache table of PT4's current database, a PostgreSQL 9.0 backend. If you play mostly Heads-Up SNG or the 3-handed Spins, it's actually quite easy to go over the (IIRC) 4096 column limit there by purchasing and importing one too many fancy HU HUD packages!

This completely borks PT4, it can no longer open - and players can no longer make money! In my previous work, I've supported many a player and fixed this "too many columns" error numerous times (by deleting enough custom HUDs from their account until the PT4 can start up correctly once more). Funny to see this pop up elsewhere!