lysdexic
Is it just me or is this a nightmare implementation in terms of software maintenance and operations? Each state transition requires a database trip, state machine transitions are determined at runtime and there’s no simple way to reproduce them locally, and in the case of the state machine database going down the system simply cannot work.
What exactly is the selling point of this approach?
This was the first time I saw someone refer to Python’s type hints as a performance tool. Up until now, I only saw references to type hints as a way to help static code analyzer tools verify that objects and invocations comply with contracts.
I guess that having additional info at hand to determine how some calls are expected to be made is helpful to gather info to drive optimization steps, but PEP 484 is clear in stating that it’s goal is to help type checkers, and that code generation using type hints might be limited to some contexts.
This sounds like yet another example supporting the old law of interfaces, where all it takes for an interface to be abused is for it to exist.
From the article:
(…) but recently, another type of criticism seems to be on the rise.
The code that I suggest is too verbose. It involves too much typing.
This reads like a one-sentence strawman. Describing code as “too verbose” is really not about the risk of carpal tunnel syndrome. It’s about readability and cognitive load.
The blogger seems to almost get the point when he writes the following:
In short, the purpose of source code is to communicate the workings of a piece of software to the next programmer who comes along. This could easily include your future self.
The purpose of source code is to communicate (…) to the next programmer who comes along.
If you make the mistake of going the “enterprise quality java code” meme approach, you’re making the next programmer’s life needlessly harder.
The blogger then tries to make his case with verbose code, and makes the following statement:
Which alternative is better? The short version is eight lines of code, including the curly brackets. The longer version is 78 lines of code. That’s ten times as much.
I prefer the longer version. While it takes longer to type, it comes with several benefits. (…)
This is yet another strawman. The longer version is awful code, not because it’s longer but because it’s needlessly jam-packed of boilerplate code. Ignorign basic things like interfaces and contracts, It’s been proven already that bugs in code are directly proportional to the number of lines of code, and thus the code the author prefers is likely to pack ten times more bugs.
The shorter code in this case would not be the 78-loc mess that the author picked as the thing he prefers. The shorter code in this case would be something like onboarding the project onto Project Lombok to handle all-args constructors, property methods, and even throw a builder in for free. This requires onboarding Lombok to the project, and add two annotations to the short example. Two lines of code, done.
After the blogger fails to make his case, he doubles down on the typing non-sequitur:
Perhaps you’re now convinced that typing speed may not be the bottleneck (…)
This is a blog post that fails to justify a click. It’s in the territory of “not even wrong”.
For those who want a ready-made set of .gitattribute files you can simply drop on your project, here’s this fancy GitHub link.
https://github.com/gitattributes/gitattributes
Once you add a .gitattributes file to your project, make sure you push a commit that re-normalizes all relevant files:
git rm --cached -r .
git reset --hard
What really helped me get better as a software engineer was going out of my way to progressively learn as many software design patterns as I could and iterate over pet projects to refactor them to apply them in practice. It helped me write cleaner code that’s far easier to maintain and extend, it helped me be far more efficient at onboarding onto projects, it helped me greatly improve my skills as a software architect.
I’d love to see benchmarks testing the two, and out of curiosity also including compressed JSON docs to take into account the impact of payload volume.
Nevertheless, I think there are two major features that differentiate protobuff and fleece, which are:
- fleece is implemented as an appendable data structure, which might open the door to some usages,
- protobuf supports more data types than the ones supported by JSON, which may be a good or bad thing depending on the perspective.
In the end, if the world survived with XML for so long, I’d guess we can live with minor gains just as easily.
Specifically, do you worry that Microsoft is going to eventually do the Microsoft thing and horribly fuck it up for everyone?
I’m not sure you are aware, but Microsoft created TypeScript.
https://devblogs.microsoft.com/typescript/announcing-typescript-1-0/
Without Microsoft, TypeScript would not exist.
FYI, there’s a TypeScript community in Lemmy.
I’m sure that any non-trolling/flamebait discussion over TypeScript is welcomed in there.
If GitHub changes terms of use to pay for basic stuff, or starts breaking compatibility or adding egregious bugs, I would start looking for alternatives.
A while ago I had all my personal projects on GitLab. I was a GitLab fanboy and advocated it everywhere to the point I convinced the project manager of a previous job to migrate the team’s projects to it and pay for GitLab ultimate. Without going into details, that goodwill ended the moment I stumbled upon a regression introduced by GitLab which affected my personal projects, and their customer support essentially said the issue was won’t fix but it was fixed in premium customers. I simply unblocked myself by moving all projects to GitHub, disabled GitLab CICD and shut down my GitLab runners, and onboarded onto a mix of GitHub Actions and CircleCI. I could still stick with GitLab, but why bother?
I would do the same to GitHub if I experienced anything remotely similar.
I get it that the project isn’t getting work done on features, but it bothers me how the author tried to criticize basic code quality improvements such as fixing typos. I don’t know if the author is an active contributor to the project, but I think he shouldn’t really be criticizing the ones that actually contribute, wether their contributions are big or small.
