Live data from Hacker News

The 4-chan Go programmer

dolthub.com

101–110 of 177 posts

Re: The 4-chan Go programmer

#101
post #7

As a scientist that ends up working closely with actual professional software engineers... lots of the stuff they do looks like this do me, and I can't for the life of me make sense of why you'd do it. I have seen a single line of code passed through 4 "interface functions" before it is called that call each other sequentially, and are of course in separate files in separate folders. It makes reading the code to figu…

This is actually really bad practice and a very “over eager junior engineer” way of writing software. You’re not off base at all that it seems excessive and confusing. It’s the kind of thing that seems technically complex and maybe even “elegant” (in isolation, when you first write the “interesting” code) at first but becomes a technical nightmare when used in real software that has to grow around and with it. You’re…

I get your point, but a wait group or a mutex can be removed in favor of a clean usage of channels if the proper concerns are isolated at first. And I would personally much rather reason about channels than mutexes and wait groups. Wait groups and mutexes are just begging for deadlocks and race conditions, where a proper channel, used correctly, eliminates both of those by design.

Re: The 4-chan Go programmer

#102
post #98

This is either parody or the making of someone who’s never done real work. Source: if you do this stuff or even dare to name another microservice after a Harry Potter character when 11.5 million people rely on it, I’m going to dedicate the rest of my life to having you fired from everywhere.

Google is chock full of services with whimsical names. I’m not a fan either but I think in this industry you’re fighting a losing battle.

Tbh, I would rather a whimsical but unique and memorable name than another “tax-pool-cache-service” type of name to try and reason about.

Re: The 4-chan Go programmer

#103
post #88
post #62

Sending channels over channels (i.e. chan chan) is a common pattern for publish-subscribe systems, e.g. https://github.com/twpayne/go-pubsub/blob/master/pubsub.go

That’s some pretty Go code, I like it. Just out of interest, why have a channel for subscribe/unsubscribe? Did you want to avoid a mutex on the subscriber map?

Not the OP but yeah, that’s usually the reason I reach for a channel in this case. A mutex or wait group is just begging for a deadlock to rise up when you least expect.

Re: The 4-chan Go programmer

#104

Earlier quoted context omitted.

Twain? https://news.ycombinator.com/item?id=769624

Had a math teach full of pithy, paradoxical, sardonic and witty quotes. Told us that if we only take away one from his class is that you can never go wrong attributing an unknown quote to Mark Twain or Benjamin Franklin.

I believe you'll find that's a direct quote from Winston Churchill. Or was it Dorothy Parker?

Re: The 4-chan Go programmer

#105
post #7

As a scientist that ends up working closely with actual professional software engineers... lots of the stuff they do looks like this do me, and I can't for the life of me make sense of why you'd do it. I have seen a single line of code passed through 4 "interface functions" before it is called that call each other sequentially, and are of course in separate files in separate folders. It makes reading the code to figu…

This is actually really bad practice and a very “over eager junior engineer” way of writing software. You’re not off base at all that it seems excessive and confusing. It’s the kind of thing that seems technically complex and maybe even “elegant” (in isolation, when you first write the “interesting” code) at first but becomes a technical nightmare when used in real software that has to grow around and with it. You’re…

Back at uni, we had a 200-level ‘software engineering’ unit, largely introducing everyone to a variety of ‘patterns’. Reading the Gang of Four book, blah blah blah. You get the idea.

Our final assignment for this unit was to build a piece of software, following some provided specification, and to write some supplementary document justifying the patterns that we used. A mature-aged student that had a little bit of industry experience under his belt didn’t use a single pattern we learned about the entire semester. His code was much more simple as a result. He put less effort in, even when taking into account his prior experience. His justifying documentation simply said something to the effect of “when considering the overall complexity of this problem, and the circumstances under which this software is being written, I don’t see any net benefit to using any of the patterns we learned about”.

He got full marks. Not in a “I tricked the lecturer!” way. I was, and still am, a massive fan of the academic that ran the unit. The feedback the student received was very much “you are 100% correct, at the end of the day, I couldn’t come up with an assignment that didn’t involve an unreasonable amount of work and ALSO enough complexity to ever truly justify doing any of the stuff I’ve taught you”. All these years later, I still tell this story to my team. I think it’s such a compelling illustration of “everything in moderation”, and it’s fun enough to stick with people.

Re: The 4-chan Go programmer

#106

Earlier quoted context omitted.

This is actually really bad practice and a very “over eager junior engineer” way of writing software. You’re not off base at all that it seems excessive and confusing. It’s the kind of thing that seems technically complex and maybe even “elegant” (in isolation, when you first write the “interesting” code) at first but becomes a technical nightmare when used in real software that has to grow around and with it. You’re…

I saw some code in a job I was just starting where they had added several abstractions that I found...confusing. After taking an extra long time to understand what the code actually did, I realized that some junior engineer had been using some design pattern they didn't really understand, and that added zero actual value to the routine. After deleting all of that code and refactoring it to use completely different ab…

As someone in leadership, my ‘strong opinion held loosely’ on this, is that there’s absolutely no way to meaningfully build this skill in people, in a theoretical setting.

You can, at best, make them aware that there is such thing as “too much”, and “the right tool for the job”, and keep reminding them.

But nothing, nothing, comes remotely close to the real-world experience of needing to work with over-engineered spaghetti, and getting frustrated by it. Especially if it’s code that you wrote 6 months prior.

Juniors will always do this. It’ll always be the senior’s job to…let it happen, so the junior learns, but to still reduce the blast radius to a manageable amount, and, at the right moment, nudge the junior toward seeing the errors in their ways.

Re: The 4-chan Go programmer

#107
post #7

As a scientist that ends up working closely with actual professional software engineers... lots of the stuff they do looks like this do me, and I can't for the life of me make sense of why you'd do it. I have seen a single line of code passed through 4 "interface functions" before it is called that call each other sequentially, and are of course in separate files in separate folders. It makes reading the code to figu…

There's an element of what you might call "taste" in choosing abstractions in software. Like all matters of taste, there are at least two things to keep in mind: (1) You can't develop good taste until you have some experience. It's hard to learn software abstractions, and we want engineers to learn about and practice them. Mistakes are crucial to learning, so we should expect some number of abstraction mistakes from…

A crucial thing to remember in a shared code base is that taste is ultimately subjective, and to let it go when people do something different from you so long as the code is understandable and not objectively incorrect. Remember you're making something functional at the end of the day, not ASCII art.

Re: The 4-chan Go programmer

#108

Earlier quoted context omitted.

There is also the fact it’s much easier to write something when you know where you are going. When you start you often just make lots of items general in nature to improve later on.

I mean... some do, some don't. With experience comes appreciation for simplicity and flexibility.

yep. good judgment comes from experience. experience comes from bad judgment.

Re: The 4-chan Go programmer

#109
post #98

Earlier quoted context omitted.

Google is chock full of services with whimsical names. I’m not a fan either but I think in this industry you’re fighting a losing battle.

Tbh, I would rather a whimsical but unique and memorable name than another “tax-pool-cache-service” type of name to try and reason about.

Especially when the repo gets contorted into some other TPS service.

Re: The 4-chan Go programmer

#110

Earlier quoted context omitted.

This is actually my preferred approach. If you want to put a 4gb base64 as your phone number, go right on ahead; best believe I will truncate it to a sensible length before I store it, but sure. Who am I to question your reality. Sadly, people abuse shit like that to pass messages (like naming Spotify playlists with messages to loved/friends/colleagues while in jail) and maybe we have to assert a tiny bit of sanity o…

How do prisoners have access to Spotify?

Presumably some feature/jailbreak of JPay (and the like) tablets.

https://offers.jpay.com/jp5-tablets/

Post reply on HN