Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 4-chan Go programmer

dolthub.com

Post reply on HN
Print view View original

131–140 of 177 posts

Re: The 4-chan Go programmer

#131

Post by bionsystem »

cqqxo4zV46cp wrote: post #105
weitendorf wrote: post #30

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…

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 ind…

So Grug was right all this time ?

Joke apart this is a really interesting example. In a job interview I've been asked once if I ever regretted something I did and I couldn't quite word it on the spot, but definitely my first project included extra complexity just so that it "looked good" and in the end would have been more reliable had I kept it simple.

Re: The 4-chan Go programmer

#132

Post by pwdisswordfishz »

devjab wrote: post #76
_yb2s wrote: 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…

It’s called Clean Architecture, Clean Code or SOLID and it’s extremely stupid. It’s widely used because the man behind it, and a lot of other grifters, are extremely good at selling their bullshit. You also have crazy things like the Agile Manifesto to thank “Uncle Bob” for. What is the most hilarious, however, is that these things are sold by people who sometimes haven’t coded professionally since 15-20 years before…

Nah, instead you’d have them invoke that Donald Knuth quote saying you should never attempt any optimization ever.

Re: The 4-chan Go programmer

#133

Post by bionsystem »

Groxx wrote: post #125
_yb2s wrote: 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…

Contrary to the "over-engineering" claims, I'll put this explanation up for consideration: it's a result of fighting the system without understanding the details. Over-engineering absolutely exists and can look just like this, but I think it's mostly a lack of thought instead of too much bad thinking. You see the same thing with e.g. Java programmers adding `try { } catch (Exception e) { log(e) }` until it shuts up a…

How would you describe a path to learn this kind of things ? (Even just dropping a link would be appreciated).

Indeed typical education is about algos and programing paradigm (like procedural, functional, OO, etc) and context (system, native apps, web, data), but I don't remember/understand much about what you describe (but definitely faced it on toy projects and reacted like the "junior way" you describe). Heck we even did some deep stuff like language grammar / compiler design / and this thing with the petri boxes but it's a lot less practical and actionable I find.

Re: The 4-chan Go programmer

#134

Post by devjab »

vundercind wrote: post #90
devjab wrote: post #76

Earlier quoted context omitted.

It’s called Clean Architecture, Clean Code or SOLID and it’s extremely stupid. It’s widely used because the man behind it, and a lot of other grifters, are extremely good at selling their bullshit. You also have crazy things like the Agile Manifesto to thank “Uncle Bob” for. What is the most hilarious, however, is that these things are sold by people who sometimes haven’t coded professionally since 15-20 years before…

> Anyway, if you want to fuck with them ask them how they avoid L1/L2/L3 chance misses with all that code separation. They obviously don’t but you’re very likely to get a puzzled look as nobody ever taught them how a computer actually works. It hardly even matters now because each major function will have to wait on the scheduler queue until the cluster manages to assign it a container, then incur a dozen kinds of ne…

So why would you want to add to that? A loop in which you change a few attributes on a thousand entities will run 20 times slower when you cause cache misses, even worse if your cloud provider isn’t using fast ram. Then add to that your exponential slowness as your vtable class hierarchy grows and you’re adding a load of poor performance to your already poor performance.

Which might made sense if spreading your code out over 20 files in 5 projects gave you something in return. But I’d argue that it didn’t just cause your CPU, but also your brain, to have memory issues while working on the code.

Re: The 4-chan Go programmer

#135

Post by patrulek »

eddd-ddde wrote: post #22
_yb2s wrote: 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…

The coder spectrum, scientists on one end, software engineers on the other. Only balance can save us. I have read code used in research papers. The theoretical math usually goes beyond my comprehension, so I always dive into the code to better understand the logic, only to find... it's way worse... unintelligible. At the end of the day we are used to what we do, and anything different will be foreign to us.

No kidding. Most of the academic/scientist's code is such a mess i would rather go through the paper and reimplement algorithm by myself :P

Re: The 4-chan Go programmer

#136

Post by makapuf »

lowbloodsugar wrote: post #51
_yb2s wrote: 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…

I mean we are in “midwit meme” territory here. 4 levels of indirection look fine to an idiot. A “midwit” hates them and cleans them up. But a very seasoned engineer, thinking about the entire system, will happily have 4 layers of indirection. Like anyone using a HashSet in Rust is already doing four layers of indirection: rusts HashSet is actually wrapping a hashbrown::HashSet. That set is wrapping a HashTable and th…

Most of the midwit memes I see on programming are :

- beginner "lets write simple, to the point code" - midwit: noo let's have many layers of abstraction just in case - jedi: let's write simple, to the point code

Re: The 4-chan Go programmer

#137

Post by beautron »

Kamq wrote: post #128
zachmu wrote: post #42

Earlier quoted context omitted.

when I was learning Go, I read a guide that told you to fire off a goroutine to walk a tree and send the values back to the main goroutine via a channel. I think about that "just an example" guide a lot when I see bad channel code. For me the biggest red flag is somebody using a channel as part of an exported library function signature, either as a param or a return value. Almost never the right call.

The only time I've seen it work with channels in the API is when it's something you'd realistically want to be async (say, some sort of heavy computation, network request, etc). The kind of thing that would probably already be a future/promise/etc in other languages. And it doesn't really color the function because you can trivially make it sync again.

> And it doesn't really color the function because you can trivially make it sync again.

Yes, but this goes both ways: You can trivially make the sync function async (assuming it's documented as safe for concurrent use).

So I would argue that the sync API design is simpler and more natural. Callers can easily set up their own goroutine and channels around the function call if they need or want that. But if they don't need or want that, everything is simpler and they don't even need to think about channels.

Re: The 4-chan Go programmer

#138

Post by mook »

distortionfield wrote: post #102
enneff wrote: 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.

I've had the displeasure of depending on one such project, which means I'd need to look at it once every few months. Need to page all the vocabulary back every time.

(Actually it was a project with multiple subprojects done by different teams. So I'd need to page a different set of vocabulary every time.)

Re: The 4-chan Go programmer

#139

Post by carlmr »

cqqxo4zV46cp wrote: post #106
SomeCallMeTim wrote: post #73

Earlier quoted context omitted.

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 spa…

>nudge the junior toward seeing the errors in their ways.

At least plant a seed of doubt early on.

Re: The 4-chan Go programmer

#140

Post by mdructor »

devjab wrote: post #79
diarrhea wrote: post #48

Earlier quoted context omitted.

Do you have a concrete example by any chance?

Most C# education will teach you to always make an interface for everything for some reason. Even in academia they’ll teach CS students to do this and well… it means there is an entire industry of people who think that over-engineering everything with needless abstractions is best practice. It is what it is though. At least it’s fairly contained within the C# community in my part of the world.

Isn't that "for some reason" in C# being it's the standard way of doing dependency injection and being able to unit test/mock objects?

I've found it easier to work in C# codebases that just drank the Microsoft Kool-Aid with "Clean architecture" instead of Frankenstein-esque C# projects that decidedly could do it better or didn't care or know better.

Abstraction/design patterns can be abused, but in C#, "too many interfaces" doesn't seem that problematic.

Post reply on HN