Live data from Hacker News

The worst kind of programmer

mikhailian.mova.org

111–120 of 137 posts

Re: The worst kind of programmer

#111

Earlier quoted context omitted.

> What big language features did Rust get in the last few years? const generics, generic associated types

Those are not new features. Those are relaxing limitations on existing features and making things more orthogonal. Rust already has had generics, now you can use them in more places consistently. Similar thing with `impl Trait` in traits.

If you know anything of the work that was required to ship those features, you know that "relaxing limitations" was not the difficult part.

I know they did ship in multiple stages, and some of those were relaxing limitations (once edge cases were accounted for), but a lot of the work was refactoring large portions of the trait solver and related machinery in order to be able to express completely new concepts (const generics are not just "generics in more places", even though monomorphization may make it seem that way).

The reason why they don't necessarily feel like new features is because they fit neatly into existing features, which is a good thing (we don't need another PHP). But they both took years to implement and were huge pain points for a very long time.

Re: The worst kind of programmer

#112
post #36

> There is broad consensus that Golang is simple to the point of being symplistic. It is in a way opposed to Rust as the means to an end and not a subject of much discussion. Golang teams strive, Rust teams… rust, because the language encourages concentration on itself, not on the outcomes of engineering projects. I'm sorry, what??!?!?!?

rust teams claim aside, having golang as primary lang in your stack is the bulletproof way to suck all the joy out of daywork. I feel like I'm golang typist, rather then programmer/engineer. coming from functional language, how come it's only in 1.21 they added `maps.contains`, relying on ugly ass assign-two-vars-check-ok construct before?

I can't help but think golang is at best in beta version now, and it's too bad companies picked it up (even without generics, lol)

Re: The worst kind of programmer

#113
The kind of anti-intellectualism that is espoused by this blog post is what sometimes makes me want to leave this profession.

Certainly, there are many people who overcomplicate solutions - for a myriad of reasons. The idea that therefore it is suspicious to be passionate about software engineering or that one should work as an interchangeable DevOps cog is deeply saddening however.

Re: The worst kind of programmer

#114

Earlier quoted context omitted.

Yeah that's not the fault of a functional approach, that's just bad code.

And perhaps the code was bad just by using a functional approach which nobody master. QED

Yes, that's a likely cause - a newbie to functional programming shoehorning a functional approach into a language actively fighting against it.

Re: The worst kind of programmer

#115

Earlier quoted context omitted.

Those are not new features. Those are relaxing limitations on existing features and making things more orthogonal. Rust already has had generics, now you can use them in more places consistently. Similar thing with `impl Trait` in traits.

If you know anything of the work that was required to ship those features, you know that "relaxing limitations" was not the difficult part. I know they did ship in multiple stages, and some of those were relaxing limitations (once edge cases were accounted for), but a lot of the work was refactoring large portions of the trait solver and related machinery in order to be able to express completely new concepts (const…

I’m not saying it was trivial to implement internally. But from the perspective of developers this is not a new feature, but a new ability to compose existing features.

Also, their existence does not change how you write idiomatic code. Existing code still compiles and doesn’t need changes. Those features are pretty niche.

Re: The worst kind of programmer

#116
post #4

Yeah. Functional programming happened to be trending again and our lead service bus developers decided to write Java like it’s Haskell. Now their garbage keeps crashing with stack overflows, and they complain when files are bigger than a few hundred lines. We accidentally pushed a 10,000 line file once and it brought the entire bus to a crawl for an hour. TEN THOUSAND LINES. One day, these twerps pushing this stupidi…

The semantics of Java aren't really optimised for FP the way they are in Haskell (e.g. no TCO, no guaranteed immutability prevents certain optimisations), but if you write FP code in Java that leads to stack overflow, you're still just doing it wrong.

You need to be careful about stack overflows when you use manual recursion, but in most cases (even in Haskell) you don't write explicitly recursive functions, you call higher-order functions like map, reduce, etc. instead that are written so they don't run into those problems (those are implemented with tail recursion in Haskell, which is eliminated, but in Java, I assume they're implemented with iteration).

Re: The worst kind of programmer

#117
Let's refine the archetype: the pseudo-talented jerk, cowboy coder, workaholic snob.

Demographics doesn't have anything to do with it; it's an attitude problem leading to all manner of manageability and team morale problems. These types of people are unwilling to listen to others and don't consider the needs or abilities of others on the team. They just do their own thing, overengineer things, and knowledge hoard with little or no documentation. It's sad to say but many Ruby developers circa 2011 fit this stereotype because they drank their own KoolAid.

Re: The worst kind of programmer

#118
post #84

Earlier quoted context omitted.

What big language features did Rust get in the last few years? What big changes have you seen that changed codebases directly? Cause I code in Rust and my Rust code these days looks very similar to what I was writing a few years ago. The biggest change to the language was async/await, which was introduced almost 5 years ago. What if you compare it to Go that fairly recently got a massive new feature that can change h…

> What big language features did Rust get in the last few years? const generics, generic associated types

Neither of these features change much in how you code in Rust. Personally I have never used either of those since they came out and I'd expect that you rarely find them in most of the user facing apps. It's definitely super useful for library authors for designing APIs that are easier to use, but it's nowhere near the paradigm change of introducing generics as a whole new concept.

Re: The worst kind of programmer

#119
post #79
post #49

Earlier quoted context omitted.

It sounds like he's overfitting to one or two programmers he knows. It seems ironic to me because rust is clearly designed much more pragmatically than golang. The whole article is also ironic because a hallmark of bad programmers is overgeneralizing their bad experiences.

> It seems ironic to me because rust is clearly designed much more pragmatically than golang. That’s a big “citation needed”. Why is it clear and what do _you_ mean when you say pragmatic?

Unused variables in Rust are warnings, but in Go they are errors. Warnings are way more pragmatical - you can still get the code to compile when prototyping, but you get a chance to fix them before shipping. Go’s resistance to introduce warnings is ideological, not pragmatical. It makes it more frustrating to use for no benefit elsewhere.

Re: The worst kind of programmer

#120
post #36

> There is broad consensus that Golang is simple to the point of being symplistic. It is in a way opposed to Rust as the means to an end and not a subject of much discussion. Golang teams strive, Rust teams… rust, because the language encourages concentration on itself, not on the outcomes of engineering projects. I'm sorry, what??!?!?!?

rust teams claim aside, having golang as primary lang in your stack is the bulletproof way to suck all the joy out of daywork. I feel like I'm golang typist, rather then programmer/engineer. coming from functional language, how come it's only in 1.21 they added `maps.contains`, relying on ugly ass assign-two-vars-check-ok construct before? I can't help but think golang is at best in beta version now, and it's too bad…

> having golang as primary lang in your stack is the bulletproof way to suck all the joy out of daywork

Huge disagree. Working with Golang is amazing to me: you actually get to spend time thinking high level instead of low level unless it’s needed for business reasons. And when you need to think low level, there’s no 100 ways to do, everything is reasonable.

I get shit done fast, efficiently, and writing good code (easy to read, maintain, test refactor and extend) is easy as hell. Whenever I go back to a Go code base I’ve not touched in years, I’m impressed at how everything still works with no trouble at all and how fast it it is to dig in and be productive.

In comparison I’ve recently picked up a React code base from 2 years ago that I was pretty proud of, and… it doesn’t even build anymore. I spent a day trying to fix the dependencies but wasn’t able to succeed yet. I’ve had similar experiences with Python code bases too.

You’re talking about maps.contains as an example and I used to agree with the sentiment, but in the end it doesn’t matter. I sometimes spend 2 minutes writing a contains method, so what? It’s never been a real issue in my experience.

Post reply on HN