lysdexic @ lysdexic @programming.dev

Posts

65

Comments

357

Joined

2 yr. ago

but if it’s not readable it’s garbage.

Readability is often in the eye of the beholder, but knowing that a component implements a design pattern is all you need to know how it's used without even having to peek at the code.

I think the most vocal critics of design patterns are those who are clueless about design patterns, and they are criticising their use just because they are scared of stuff they don't know.

but we can agree on which of two implementations is shorter.

Shortness for the sake of being short sounds like optimizing for the wrong metric. Code needs to be easy to read, but it's more important that the code is easy to change and easy to test. Inline code and function calls are renowned to render code untestable, and introducing abstract classes and handles is a renowned technique to stub out dependencies.

Duplicate code can be a code smell, but it's far better to have the same function definition or code block appear twice in the code than extracting a function that tightly couples two components that should not be coupled at all.

See Write Everything Twice (WET) principle.

I agree. The GIL and packaging woes are a good indication that it's range of applications isn't as extensive as other tech stacks.

Here’s another: most code reviews on larger companies are BS, just for show and nitpicking.

Story time.

Once I worked with a developer that just joined the company straight out of college, and had far more ambition than competency. That developer decided that code reviews where the venue where their high bar for code quality would shine, so they decided to nitpick everything that went against their poorly formed sense of taste. As luck would have it, the developer was assigned to a legacy project that was in cold storage for years and had no tests and linters, and was in a really poor state, and proceeded to leverage that to challenge each and every insignificant detail such as if a space should be at the left or at the right of a symbol. Each code review automatically received dozens of comments nitpicking whitespace changes. What a waste of time with so much noise.

I drop by the project, and noticed the churn that developer alone forced upon everyone, as that team had a rule that all code reviews should be passed by all reviewers and that reviewer made it their point to reject reviews that didn't complied to their opinion on whitespace. So the first thing I did was onboard a code formatter, and made it my point to subject the spec to an unanimous code review. That problematic developer made it their point to nitpick away each and every single setting, but it turned out some of their opinions conflicted with previous feedback.

So the code formatter tool was onboarded onto the team. Did that stopped the problematic developer from continuing their nitpicking? No. Except this time around other developers started pushing back because the opinions were contradictory and contrasted with the official code formatting style.

All it took was a couple of days for the problematic developer to go from dozens of comments per day to zero. The code formatter was still optional and not fully adopted, but the problematic developer simply ceased with the bickering.

Python is only good for short programs

Was Python designed with enterprise applications in mind?

It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.

Having fun when programming should be much more important than having correct or fast code (...)

That's only remotely reasonable if you're a weekend warrior that messes with coding as a pastime. Even so, I'm not sure what fun you can extract from dealing with slow, broken code.

HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let’s be honest, your webpage just consists of nested

<div>

tags.

My websites do not consist of nested divs. Your webpages might just consist of nested divs, but only if you are clueless about what you're doing and are oblivious to basic stuff like accessibility support.

CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it’s just terrible. It’s very clunkily integrated with HTML too in my opinion.

Being unmanageable is the output of the developer team, not the languages they use. Decoupling Presentation from the data and semantics never ceases to make sense. CSS has many issues but the way its integrated with HTML is certainly not one of them.

Frankly, you sound like you blame your tools a lot.

</div>

You don’t have guarantee nobody touched your file, we should database that keep structure information instead.

What is your definition of file and database? For example, do you think SQLite is a database, and a SQLite database file counts as a file? Do you think that editing SQLite or PostgreSQL with a third party client counts as touching a file?

I always assume all the reviews are from plants or axe grinders.

That's my expectation as well. People need to be motivated to go out of their way to provide feedback, either good or bad. It's only natural that axe grinders are highly motivated to leave organic feedback while plants are either compelled game the metrics or pressured to game the metrics.

Either way, salary is the best indicator and lots of rosy pictures are as good as bad reviews.

I can also tell you without any shred of doubt, that there are many Amazon teams that absolutely hate Java

Irrelevant. What matters is what the company uses, not what some guy's personal taste.

Amazon standardizes on Java. There is no way around this fact.

It is branching away from Java, even if it still uses it primarily.

I'm sorry to tell you, but I assure you it is not. Some small subset of teams uses non-java tech stacks but that's because they have very particular requirements, such as being android apps or running on Linux devices. The bulk of the company heavily standardized on Java and has no plans to ever move away from it.

Unusually, off the top of my head, I happen to know more .NET developers working there than Java developers, and interestingly they develop one of the services on AWS.

First of all AWS is not Amazon.

Secondly, I can tell you for a fact that C# is one of the rarest tech stacks at Amazon. Even Amazon's internal build system does not support it.

I'm afraid you're talking about stuff you know close to nothing about.

Well, in Rust, it’s a sum-type

The discussion is on to use monads in C++, and not on why is C++ different than Rust.

I repeat: you do not need sum types to implement a Result monad in C++.

I can tell you without any shred of doubt that Amazon still standardizes on Java-based frameworks, including Spring, and has absolutely no plans to switch. Each Amazon team is able to pick its own tech stack, but the ones that do not use Java or a JDK-based stack are extremely rare, and more than not are working on specialized applications such as mobile development.

The only reason Java is remotely tolerable today is because of influences from those ‘fad’ languages.

This might be your personal opinion but it is not a very informed one, or in touch with reality. Java frameworks such as Spring still dominate the backend ecosystem and some FANGs still standardize their backend development around it.

This is certainly a way to dismiss all other programming paradigms, I suppose.

My comment has nothing to do with paradigms.

In fact, your strawman is proven to be false by the fact that there is no mainstream tech stack for the web which is not object oriented and provides a request pipeline that uses inversion of control for developers to pass their event handlers. They all reimplement the exact same solution and follow the exact same pattern to handle requests.

WET is not what you think it is, or at least not originally. It’s not some alternative to DRY. It didn’t stand for Write Everything Twice. It stands for Write Every Time. It’s supposed to be a negative way to describe code that isn’t DRY. It’s also abbreviated as “Waste Everyone’s Time”.

I think you're confusing things. Write Everything Twice (WET) has no resemblance with the concept you mentioned, which makes no sense to be a standalone concept or even rule of thumb.

WET is a clear guideline to avoid usual code quality problems caused by premature specialization and tight coupling which result from DRY fundamentalisms. WET puts on hold the propencity to waste time with code churn. It's importance is clear to anyone who maintains software.

The misunderstanding since DRY’s coining is probably because, like natural language, we change meanings we with our environment.

Not really. Your comment sounds like a weak attempt at revisionism. Some reference books like Bob Martin's Clean Code explicitly cover DRY and the importance of refactoring away any duplicate code.

WET springs from this fundamentalist mindset. There is no two ways about it.

Unless I’m misreading, you brought monads into it.

You're misreading it. What do you think a 'Result' type is?

Java gets a bad reputation from proponents of FOMO/fad-driven development, but the whole Java ecosystem was built for the web. Anyone is hard-pressed to find a better tech stack than Java-based frameworks without resorting to hand waving and passing personal opinions as facts.

I love C# and the whole .NET Core ecosystem, but even I have to admit it's very hard to argue against java.

compiler support

That remark was on sum types, not monads. You do not need "compiler support" to have Result or neither monads in C++. There are already plenty of libraries that implement those. I use them in some of my projects. No compiler support needed.

As I said, sum types are not required for Return or Either monads. At best, they are convenient.