flavious

9 ms·

1.
by flavious 4y ago
Yes, that would be amazing, full classes of approaches to problem solving would be unlocked at once and we wouldn't have to invent new languages, DSLs, transpilers, etc, but just leverage zig.
2.
by flavious 6y ago
Contracts are actually quite necessary for modularity. In OOP we have data types (interfaces, classes). As long as other paradigms provide contracts/abstractions, modularity can be achieved there also. Faked modularity doesn't cou
3.
by flavious 6y ago
I'm not your goto java guy, but the module system of java and how modules can provide implementations for interfaces is really great.
4.
by flavious 6y ago
Over-abstraction also has a non-negligeable cost.
5.
by flavious 6y ago
Fred should learn how to squeeze in his refactorings into other, related tickets. And to learn how to argue about why an user story is more points worth, without explicitly saying the R word.
6.
by flavious 6y ago
And how does the team feel about it?
7.
by flavious 6y ago
Sounds like the effects of temporal coupling, or "settism and gettism", or other principles, which are violated. People are blinded nowaways too much by SOLID, and forget about the remaining 20 principles.
8.
by flavious 6y ago
My rule scales with the scope of the dependency: "If you think that creating a wrapper around the library is too expensive, then the dependency is not worth having".
9.
by flavious 6y ago
Not questioning your decision at all, but can you explain the whole thought process which led you to the conclusion that it is a better fit?
10.
by flavious 6y ago
Linux user for 15+ years, Slack, now Arch in the past 10 years.
11.
by flavious 6y ago
Normally, bright developers acquire a new language* within a few weeks, if they already know the paradigm from another language. Hack is OOP, and so are many others, so I would expect a bright developer to learn hack in 2-3 weeks, not month
12.
by flavious 6y ago
> Rule 20: When somebody says Agile, push for Kanban, not Scrum From my experience, scrum is better. The idea is that you can measure progress and you can learn from mistakes with scrum. Kanban doesn't help in that regard. Also, a g
13.
by flavious 7y ago
Very good article, intuitively I'd say some overlap with "the pragmatic programmer".
14.
by flavious 7y ago
I've written many thousand lines of code in bash (along with way more in 15 years of programming in other languages) and I must tell you: Never again! Use xonch at least.
15.
by flavious 8y ago
Define "We".
16.
by flavious 8y ago
Who knows, maybe he has valuable things to share. It's like that with any book. It also depends on the readership.
17.
by flavious 8y ago
borgbackup.
18.
by flavious 8y ago
As a programmer, I leave a small portion of code uncommitted at the end of the day. Next day, I just look at the git diff, and I'm mentally back right where I left.
19.
by flavious 8y ago
Code monkey thinks he can help beginner become a researcher? Not so fast, tiger.
20.
by flavious 8y ago
When I was a junior, I could write my queries in SQL in 30 minutes for the report which was asked from me, but I needed two more days to figure out how to do it with the ORM. For juniors, it's best to have a less abstractions.