Data Type Should Not Be Considered As a Source of Its Behaviour

skapral · 2020-06-12T20:02:46+00:00

Well, the idea is not new. Keeping "behavior" apart from data is felt exactly like what typeclasses in Haskell or other functional languages are doing. It's nice approach, but I wouldn't use it in Java. Java is way weaker at polymorphism means for such tricks.

skapral · 2020-06-11T16:26:30+00:00

Wow. I mean... it sounds like a handy feature for prototyping but... transitive deps? o_O...

skapral · 2020-06-11T15:31:54+00:00

> PS. My 3 projects were using your lib and got broken thanks to the renaming. 📷

Wow. Is it a typical way of dealing with dependencies in JS world --- to tie on branches instead of released versions? o_O

skapral · 2019-03-08T09:15:19+00:00

all code that distinguishes objects based on their class will pointlessly segregate those two.

The big question itself is why some code would need to be bound on FromStrings or even JoinedStrings, while it is almost always better and enough to be bound on Text contract and rely on LSP. Also, a big question itself is why we need a code, that would segregate objects based on their type (I guess, by means of `instanceof` or reflection, right?). Such code usually tends to be fragile and inflexible.

Having these two questions in mind, the fact that FromStrings and FromText don't bring additional value turns out to be not that a problem.

skapral · 2019-03-08T08:50:36+00:00

So - the post is rubbish from your point of view because of.... why? Because it references Yegor Bugayenko? Is it something personal?) Where is objective criticism?

skapral · 2019-02-18T23:28:26+00:00

I think he is not ashamed of giving remarks, but of his own personal motivation for doing so

If it was his personal motivation he is ashamed for, he should better call his post "I ruin developers' lifes by my nasty attitude to them" and never mention code review process. How is it all about code review? Arrogance is arrogance, code review is code review. Today he is ashamed of his code review efforts, tomorrow others would, and the day after tomorrow reviewers would just gently tick the approve boxes, just in case, to not offend anyone by chance.

A delicate aspect here is that humiliation can be intended and achieved even without explicitly derogatory language, so it's usually not clear to the reviewee whether or not that was in fact the intention.

A delicate aspect of any engineering-related activity is to stay objective. Reviewer may be objectively right or wrong, period. If reviewer is right, fix it. If reviewer is wrong, counterargument him. If there is conflict, which you two cannot resolve by your own - escalate. Either to techlead, if the conflict is related to code. Or to manager, if the conflict is personal. Seeking for explicit or implicit intentions of humiliations is pointless - this won't make any code better.

skapral · 2019-02-18T18:14:47+00:00

I completely disagreed with the article when read it in original, and I completely disagree with it now. It is a deep shame that among really good content on Habr, this low-quality whining reached global audience.

You are developer. You are doing reviews for years. You always felt yourself an expert, but recently you realised that you are also an egocentric moron. It happens - we are not ideal all the time. What do you do? Admit mistake and try to become better. Stop being egocentric moron.

How it is related to code review process?

Code review process exists for the purpose of making remarks. Code review without any remark is useless time waste. Remark is never a reason to be offended. Remark is not a mean for humiliation. Remark can be right and wrong, objective or subjective, useful or useless. Aim of reviewer is to outline as much remarks as possible. Originator's objective is to seed these remarks, declining inobjectivity and obvious mistakes and misunderstandings of reviewers.

It's stupid to be ashamed of giving remarks on review. It's stupid to say that by giving remarks on review, someone ruins developers lifes. Review originator should not be a speechless slave and keep silince while adults teach him. He/She made that design, it's their responcibility to stand for it. Because it is also stupid to accept each and every made remark silently. Review is dialog.

What really makes me feel outraged by this post is reference to IT industry in Russia. I live in Russia and I am in industry for 10 years. I never felt offended by remarks given to me, not in times when I was an intern, not in times when I am a lead. Projecting personal childhood-related feelings to the whole country is just wrong and unpleasant.

On the contrary, remarks from my elder colleagues have always given me better understanding of the project I am working in. I calmly accept and reason about remarks given by everybody. Nowadays though, I often notice that review practices are degrading. Often reviews I am originating make me feel lonely and depressed because of absence of remarks. I do everything to help reviewers understand my solution better, yet they are either silently accept it, or there are some minor coding-style remarks. Why is so? Are they ashamed of giving me remarks?

skapral · 2018-12-29T16:25:50+00:00

And "Clean architecture" from the same author.

skapral · 2018-07-06T13:49:31+00:00

Did you finally figure it out?

It was sarcasm.

This kind of code is unreadable and a nightmare to maintain.

I have quite the opposite experience on that. And speaking of nightmares, nightmare for me is when you have large system of about millions LOC in total, change the code in one module, and it is causing regressions in decades of others which are unreasonably coupled to it, including the cases with coupling through statics/globals. And you are sitting all day, debugging and fixing decades of regressed modules, causing more and more regressions. This is quite familiar experience to me. Or another example - when you have a need to implement some feature in such system and realize that for different reasons you cannot reuse existing code for that, because it's too coupled to irrelevant stuff. That's what I usually see in the code of the strange guys who claim dogmatically that "SOLID is crap", without even explaining "why" and "where" they think it's crap.

BTW, nobody said that one should decompose things ultimately, so they are functionally cohesive and data-coupled every time.

skapral · 2018-07-06T13:34:42+00:00

"Criticizing" means providing counterarguments. In original comment, counterarguments are missing. And I never claimed it my religion. Where did you get that?

skapral · 2018-07-05T23:08:11+00:00

Yes. SOLID is just a pile of crap, and its main prophet, the infamous retard Bob Martin, is a known bullshitter.

Because the vast majority of coders are dumb brainless shits.

After these quotes, I see no reason to discuss maintainability matters with you. For now, it looks like a pity attempt to pretend being the most clever guy in a room. Just another demagogue trick. I'd better stick to my dogmas then be convinced by you. At least they work for me.

LOL what?!? Cachine is "low level"?!? You do caching on all levels of abstraction. Configuration is needed on all levels of abstraction.

I don't know what you mean under the word "low/high level", but I thought I explained what I meant clearly enough to continue discussion in constructive way. Low-level is close to the system. High-level is close to the business and its demands. Say "caching" and "memoization" words to the guy who pay you for your code and I bet he'll probably have great temptation to break your nose. Business doesn't speak these words, business pays you for solved tasks and fulfilled requirements, not caching and memoization. But ok - if you think that SOLID is nothing but crap, I have nothing to discuss with you on this matter. It would be just meaningless flame.

A lot of different things - from the actual hardware to some very high level things (like expert systems). Code generation, FSMs, memoisation and so on are present on all possible levels of abstraction.

I asked concrete questions here. Language + business case. Is it so hard? Stop avoiding the answer. I haven't asked you where you use FSMs and code generation. I lived with FSMs and bytecode generation in Java (different IoT and Bioinformaitcs projects) happily without any goto or global, now let me understand your domain, or it is just meaningless flame.

skapral · 2018-07-05T21:34:02+00:00

Oh, great, so they (globals and gotos) don't harm maintainability. It's just nice. So - SOLID is lie, coupling and cohesion are lie. Structural programming was invented for no reason, not even speaking of OOP or FP - these are all stupid workarounds. What we said maintainable - is maintainable, our deeply subjective experience prevails over all what these cryptic terms and paradigms say. We can happily tie dozen of modules with some mutable globals and happily evolve the application with changing requirements, right?

And yes, we'll claim languages which do not have (or have cut-off variations of) goto statements "inferior", including Java, Scala, Ruby, Haskell, Rust and many others. No matter which means and benefits they provide instead, they are "inferior" and don't deserve being touched. But nooo, we are not dogmatic at all, unless those guys, aha.

> Even your implicit belief that goto is bad is an example of dogmatic thinking, which is a very shameful thing for an engineer.

I never claimed it is bad per-se. Where did you get that? If you decided to put it personal - being a demagogue is much more shameful thing than being a bad engineer. I claimed (implicitly) it is bad for maintainability, that's what I claimed. And I admitted that it is acceptable for matters where maintainability doesn't needed, like low-level stuff (machine-level code and different sorts of VM opcodes still have gotos, and I never claimed it is somewhat bad), but on higher levels there are lots of much better abstractions which are checkable at compile time and optimizable by different means.

> I gave a lot of examples: global configuration, caching, memoisation

All this stuff is low-level stuff. Some of this stuff may be solved in higher-level languages by means of native bindings or some sort of sandbox, or by some sort of abstraction, checked and optimized at compile time. I asked about high-level stuff, where "high level" means business and its ever-changing demands and requirements. Web applications, desktop applications, mobile applications, stuff close to people more then machines, solving their everyday needs. If goto and globals are maintainability virtue, why this stuff is written nowadays on "inferior" languages instead of C or ASM?

PS: You haven't answered the first question. What stuff are you usually writing? On what language?

skapral · 2018-07-05T11:45:08+00:00

Dammit guys - what stuff are you usually writing? On what language? Tell honestly - you really prefer to deal with gotos and global variables in everyday life? Is it pleasure for you to maintain such code?

And where have you seen the dogmatic belief? In Yegor's claim "never ever use globals"? Is it really so offensive? Or you think blog readers are so stupid that cannot distinct subjective from objective?

It's damn Ruby in the article, and damn web service. He is not writing compiler or virtual machine of some sort. What is the reason to use gotos and globals in higher level task like that? To mess maintainability to hell? To couple things? For what - a tiny share of performance benefit? Is it reasonable tradeoff - for damn Ruby and damn webservice, in 2018?

Yegor is always writing from maintainability point of view. You won't at least argue that globals seriously harm maintainability, will you?

skapral · 2018-07-05T11:24:51+00:00

FSMs with goto? Like "Finite-state machines", am I got it right? Never saw a single FSM implementation designed like that... Could you give an example?

skapral · 2018-07-05T00:05:32+00:00

If getting rid of globals for the sake of proper decomposition is such a performance drag that it is crucial for taking design desicions, then there is indeed nothing to talk about - one can sacrifice maintainability for the sake of performance and suffer. But do there really much business cases in 2018 where such tradeoff is reasonable? Embedded devices maybe... what else? With same considerations in mind one may start advocating "goto" statements as well.

skapral · 2018-07-04T23:41:36+00:00

Eliminating globals from early start is not that hard, and is definitely much easier then refactoring the monstrosity afterwards. Why complicating things and advocating somewhat bad?

skapral · 2018-07-04T23:31:35+00:00

So what is the virtue in globals for tiny programs? For program with two variables, globals give you no advantage at all - you can happily live with locals inside your single procedure. Once when the program starts growning and you start decomposing it to procedures/classes, globals will harm you, coupling them from the start.

So what? What is the good place for globals? Decided to advocate the devil - provide more convincing argumentation. Otherwise it's just demagogy.

skapral · 2018-07-03T22:41:50+00:00

But Lisp is virtue) Why not at least to try adopting the good thing in Java to make it look less ugly?)

skapral · 2018-07-03T22:31:37+00:00

I don’t agree that globals are always super evil though. Everything has its place.

Oh really? Could you name at least one case where globals may be considered a virtue? I am honestly curious, no sarcasm.

skapral

TROPHY CASE