Post 3348929 by scarly@soc.scarly.pink
(DIR) More posts by scarly@soc.scarly.pink
(DIR) Post #3348929 by scarly@soc.scarly.pink
2019-01-25T02:52:46Z
0 likes, 0 repeats
lately, i've been reading a lot of source code where it looks like the creator thought to themselves "abstraction is good, so i will abstract as much as possible"i mean, like... everything doesn't have to be chopped into 10 functions. it's generally better to write stuff first and then abstract where it Makes Sense to avoid duplicationi mourn the demise of readable code with comments. i'm going to blame the rise of "ninja programmers" with "agile techniques"
(DIR) Post #3348930 by decis@aura.aetheri.ca
2019-01-25T02:57:24.746748Z
0 likes, 0 repeats
@scarly We've read documentation recommending that functions should be as narrowly-scoped as possible, and that entire source files should be dedicated to one type or class.That degree of abstraction is really counter-intuitive for us, so we don't do it.We do wind up with functions that are epic complex and call lots of other very complex functions asynchronously, but I don't think that can be helped when we need big parts to work together with other big parts.
(DIR) Post #3348931 by scarly@soc.scarly.pink
2019-01-25T03:04:18Z
0 likes, 0 repeats
@decis honestly, a lot of what is currently being taught is literally cargo cult nonsense. someone did it and they were successful so now the same techniques are being considered "Industry Standard"what these techniques are actually good for is making code seem almost obfuscatednarrow scope functions sounds nice, but i wonder how many have thought about the use case. ie the "Why Is This Good" question?and honestly, that's my take - and if you have a method that works for you, this is Valid
(DIR) Post #3348932 by decis@aura.aetheri.ca
2019-01-25T03:36:42.105686Z
0 likes, 0 repeats
@scarlyWe think that the principle of someone-did-a-thing-and-then-it-became-standard is silly. There are many potentially effective solutions to a problem, and many ways to reframe a problem that opens it to a whole new class of solutions. To insist on doing the conventional thing because it's conventional is no better than simply being afraid of change.If we're going to do the conventional thing, we should at least understand why it's preferable to doing it another way.Decis like to go out of their way to reframe problems, both to better understand them and to try unusual things that might just work better to address the real pain point.
(DIR) Post #3348933 by feathers@aura.aetheri.ca
2019-01-25T04:04:53.789281Z
0 likes, 0 repeats
@decis @scarly Any sort of prescriptive code design philosophy irritates me by default. I've been so annoyed with this lately, corporate code people are especially obsessed with style and structure standards.Code is art.Also you haven't lived until you've used Java and instantiated a FactoryFactoryFactoryFactory with dependency injection...
(DIR) Post #3348934 by grainloom@cybre.space
2019-01-25T05:11:12Z
0 likes, 0 repeats
@feathers @scarly @decis ok but you NEED standards when you write in something like C and imho even when you write something like Javaactually, anything where the language isn't strict enough to not require a specific style (but then you just moved the rules into the language)(also, I found having uniform formatting in a C codebase Super Nice because it let me grep for things easily)
(DIR) Post #3348967 by scarly@soc.scarly.pink
2019-01-25T05:12:59Z
0 likes, 0 repeats
@grainloom @feathers @decis tbh, i code in Python and actually read and follow PEP 8 and am actually an accountant irl so uh i'm never against standards that make sense.i think a lot of standards really need to be looked at and questioned, though.
(DIR) Post #3349021 by grainloom@cybre.space
2019-01-25T05:16:15Z
0 likes, 0 repeats
@scarly @feathers @decis tru.