I like recursive functions tho
this post was submitted on 05 May 2024
823 points (99.0% liked)
Programmer Humor
19623 readers
2 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
Yet I have not met a CS grad without a trauma.
I've had 7 traumas this week and counting *rocks back and forth*
I have a production bug... it only happens on Saturdays ever our ops folks have no idea - this can be replicated on a test server that gets no traffic.
Saturday why!
If we reject the theory that it could be someone's elaborate revenge, Saturday may be the first day of the week that may become workday or non-workday because of incorrect assumption about the first day of the week. If everywhere but one place in your software the day numeration is correct it would be a hard bug to spot.
Also, if it is in Java, I vaguely remember there being a lot of ways to express weekday, so a lot of ways to shoot off your foot (solely on Saturday)
For bonus points, this failure is in a cron job that sends out recently queued messages. It runs once every ten minutes - last weekend we had 12 failures: four were in a cluster on their own, one was in a run of two, and six were in a single continuous run.
Please note that this server is unused by our business so no messages ever get naturally queued. Every day we sync the live production server to this server at about 9 PM - assuming an employee was queuing up a message before the snapshot is taken there might be a number of unsent messages in the snapshot - those messages will all be sent by the first cron job after the sync.
It is a wonderfully awful problem that has me wanting to pull out my luscious locks.
I wish you luck. Also, maybe you could get someone else to get a fresh view of an issue
Yup, luck is appreciated and I'm trying to get more eyes but unfortunately I'm a senior dev that has the second highest seniority at the company so I feel guilty dragging others into it.
Lots of logging to triangulate when it fails and what variables it has at the time.
Please tell me it doesn't still happen when you emulate a different day of the week. Or is that non-trivial to even do because of technical debt? Either way, RIP weekends.
load more comments
(1 replies)
Nah Hanoi was easy stuff, first year. Definitely more traumatizing practice problems.
Hanoi […] practice problems.
Like you come to the exam and there's a 64 piece Tower of Hanoi you need to solve manually to pass the exam
Assuming 1 second per swap, a 64 disk tower of hanoi would take 585 billion years to solve - it has 2^64 -1 swaps.
And that makes It good enough for an exam
Calm down, satan
Yea, get back to me when you get to parallel programming.
Or even just try to understand pthreads.
You’re doing it again
Writing kernels for parallel execution with OPENCL gives me flashbacks every time I remember them
Tis' not hard, just add some sleeps to make sure other thread reads data before it is destroyed 🌚
I didn't have to program this, thankfully. The code was used as an example of recursion but the explanation was lacking so I ended up writing out each frame by end until I understood it. Took a few pages and a couple of hours.
I am grateful that I learned what I did going through it but I'd rather not do it again.
Fuck all programming puzzles. I refuse them.
True hommies hate them too.
Replacing "Programmers:" with "Program:" is more accurate.
spoiler
Tower of Hanoi is actually easy to write program for. Executing it on the other hand...
It'd be a trick if you didn't already know the answer. Or at least, it would be for me. It's also hard to actually visualise.
I didn't know the answer either, but usually you can compose solution from solutions of smaller problems.
solution(0): There are no disks. Nothing to do. solution(n): Let's see if I can use solution(n-1) here. I'll use solution(n-1) to move all but last disk A->B, just need to rename the pins. Then move the largest disk A->C. Then use solution(n-1) to move disks B->C by renaming the pins. There we go, we have a stack based solution running in exponential time.
It's one of the easiest problem in algorithm design, but running the solution by hand would give you a PTSD.
load more comments
(1 replies)
Is this a hard problem to solve? I've not attempted it yet myself.
I seem to remember this was a problem in Advent of Code one year?
I'm imagining there are plenty of algorithms to solve this already, right? With varying numbers of towers and plates? A general solution for solvable amounts of each? Maybe?
This is not a hard problem once you wrap your head around it. It is the earliest that some programmers learn about recursion which has a lot of pitfalls and can be frustrating at times.
Ah okay, that's where the trauma comes from then, perhaps? 😅 Just being new to a concept and perhaps starting out with a problem that is a little too big while at the same time learning the concept?
I feel like it's maybe a bit too much to say that it's a trauma. The Vietnam-flashback picture is just very fitting, because the puzzle is called "Towers of Hanoi" (Hanoi is the capital of Vietnam).
A lot of programmer memes seem to be about first-year compsci students that just want to build video games, and don't really like math. For those people, sure, algorithms could be a bit of a rude awakening.
I was once that first year compsci student. Hanoi kicked my ass, I had to go recruit help from my smarter friends. Though to be fair the teacher didn't explain it that well and just sort of threw it at us to see which of us would sink or swim. After we all complained about it he gave us a proper lesson on recursion and it was a little easier after that but I still struggled a lot on that project. We also implemented Conway's Game of Life that semester and I preferred that project by a lot.
Ah right. 😁
See, when I was a comp sci undergrad 20-odd years ago our department wanted to do a programming competition for the local high schools. We set some ground rules that were similar to ACS programming competition rules, but a bit more lax - the big ones were that it had to run in command line, it had to take the problem dataset filename as the first parameter and it had to be able to solve all datasets attempted by the judges in less that 2 minutes per dataset, noting that the judgement datasets would be larger than example ones.
Some of the students were asked to come up with problem ideas. I was told mine was unfair, but mine was entirely about choosing the right algorithm for the job.
It went like this - the file would contain a pyramid of numbers. You were supposed to think of each number as connecting to the two numbers diagonally below it and all paths could only proceed down. The goal was to calculate the largest sum of any possible path down.
load more comments
(3 replies)
load more comments
(3 replies)
It's an easy problem to solve... eventually - it's more annoying to solve optimally and that's what programmers usually get handed as a play problem within a year or two of starting to tinker.
Hanoi flashbacks
In myuniversity, we used to play with these to find the fastest path in AI (A*, first depth etc)
Y'all need to play some Dr. Nim. That's a REAL programmer's board game https://boardgamegeek.com/boardgame/23630/the-amazing-dr-nim
Amazing, an analogue computer from 60-s dedicated solely to one task. This is what steampunk ASIC looks like
Vsauce just made a short form about these except a much bigger one
God I can't remember how to do this something about moving tower a to spare pin recursively.
Pretty much. If you can solve it with like 4 then you can solve it with any amount.
Yeah I remember it being an exponential amount of movements tho.
"You mean I just made a very complicated array-manipulating way of calculating (2^n)-1?"
Lettme introduce you to ackermann's function:
int ack(int m, int n) {
if (m == 0) {
return n+1;
} else if((m > 0) && (n == 0)){
return ack(m-1, 1);
} else if((m > 0) && (n > 0)) {
return ack(m-1, ack(m, n-1));
}
}
You won't run out of stackoverflows any time soon.
Towers of Hanoi? I don't think so.
Petah?
view more: next ›