4 ms·

I wouldn't called it "worse is better". Why not "less is better" or "simpler is better"? My take is that one should program in function of what the code should

by scoutt 4y ago

I wouldn't called it "worse is better". Why not "less is better" or "simpler is better"? My take is that one should program in function of what the code should do, and not in function of what it's comfortable to me (as a developer). Yes, it's a great feeling when your code fits like a jigsaw puzzle, but also more complexity = more code being executed. Behind that RAII, behind that "operator=" and that "p = new Struct", etc. there might be extra complexity for the sake of developer's readability and comfortability. There is little or no added value for the end user or the purpose of the program itself. Also the code should be written "for the now", not for "that future feature it would be awesome to have someday like making it compatible with every other library X, etc.". At the end of the day, even without realizing it, your program is slow. I remember a developer where I work did a C# implementation of an AT command parser, in which every AT command was a separate DLL. It was very complex, and super slow. But the developer argued "if I need a new AT command, I'll just add a new DLL". It might have been better for him as a developer, but it was worse for the end user and the system in general. The code died the day that guy left the job.

razorfen 4y ago
> Also the code should be written "for the now", not for "that future feature it would be awesome to have someday like making it compatible with every other library X, etc.". The folksy software adage for this is YAGNI. (You Ain’t Gonna Need It)
klik99 4y ago
> I wouldn't called it "worse is better". Why not "less is better" or "simpler is better"? The original article called 'worse is better' was pretty successful and widely read, and part of it was the title grabbed people's attention. You could argue it's a rephrasing of "less is more" or "do one thing well" concepts for the click bait zeitgeist. That's not a bad thing - an old concept wrapped up in a new way of expressing can keep the idea alive - anyway it's funny and a little confusing, which might trigger someone to engage with it differently. There's many concepts that I've heard n times expressed in different ways only to have it click on the n + 1 way of phrasing it.
- pm215 4y ago
  Also, the "PC-losering problem" presented as one of the central examples in the original 'Worse is Better' really is an example of 'worse' -- the unix approach gives a modest reduction in kernel implementation complexity at the cost of every single userspace program either taking a complexity hit (retrying on EINTR) or being buggy in corner cases. This isn't just "less" or "simpler" -- it's actively accepting "worse" in order to get a basically functioning thing out the door sooner and maybe fix the most-annoying warts later. (Minimum Viable Product, anybody?)
adwn 4y ago
> Yes, it's a great feeling when your code fits like a jigsaw puzzle, but also more complexity = more code being executed. Behind that RAII, behind that "operator=" and that "p = new Struct", etc. there might be extra complexity for the sake of developer's readability and comfortability. There is little or no added value for the end user or the purpose of the program itself. 'Yes, it's a great feeling when your code fits like a jigsaw puzzle, but also more complexity = more code being executed. Behind that function call, behind that nested expression and that "p = malloc(sizeof(*p))", etc. there might be extra complexity for the sake of developer's readability and comfortability. There is little or no added value for the end user or the purpose of the program itself.' See? The same argument can be used against C in favor of assembly. Abstractions allow us to write safer, more correct code in less time, which actually does offer a lot of added value for the end user. C makes many useful abstractions harder or downright impossible, which is one reason why software written in C is generally such a shitshow from a security perspective.
- scoutt 4y ago
  > Behind that function call, behind that nested expression and that "p = malloc(sizeof(*p))", etc. there might be extra complexity for the sake of developer's readability and comfortability. There is no way to avoid most of things you listed. It's not comfort; it's a necessity. > software written in C is generally such a shitshow Whatever language you use to code, all your calls will sooner or later pass through a function call, a nested expression or a malloc()/free() call, somewhere in the huge stack of C code your language needs, depends and relies on. There is no escape. Basically, today your preferred language exists and might be able to something just because C code exists.
  - adwn 4y ago
    > There is no way to avoid most of things you listed. Oh yes, there definitely is: There are no function calls, nested expressions, or malloc in assembly – those are abstractions provided by the language and translated by the compiler, for comfort, not necessity. In fact, you can simulate all that in C itself: use gotos and an explicitly managed memory area as stack, and manually transform nested expressions into SSA form.

by scoutt 4y ago

razorfen 4y ago

> Also the code should be written "for the now", not for "that future feature it would be awesome to have someday like making it compatible with every other library X, etc.". The folksy software adage for this is YAGNI. (You Ain’t Gonna Need It)

klik99 4y ago

> I wouldn't called it "worse is better". Why not "less is better" or "simpler is better"? The original article called 'worse is better' was pretty successful and widely read, and part of it was the title grabbed people's attention. You could argue it's a rephrasing of "less is more" or "do one thing well" concepts for the click bait zeitgeist. That's not a bad thing - an old concept wrapped up in a new way of expressing can keep the idea alive - anyway it's funny and a little confusing, which might trigger someone to engage with it differently. There's many concepts that I've heard n times expressed in different ways only to have it click on the n + 1 way of phrasing it.

pm215 4y ago
Also, the "PC-losering problem" presented as one of the central examples in the original 'Worse is Better' really is an example of 'worse' -- the unix approach gives a modest reduction in kernel implementation complexity at the cost of every single userspace program either taking a complexity hit (retrying on EINTR) or being buggy in corner cases. This isn't just "less" or "simpler" -- it's actively accepting "worse" in order to get a basically functioning thing out the door sooner and maybe fix the most-annoying warts later. (Minimum Viable Product, anybody?)

adwn 4y ago

> Yes, it's a great feeling when your code fits like a jigsaw puzzle, but also more complexity = more code being executed. Behind that RAII, behind that "operator=" and that "p = new Struct", etc. there might be extra complexity for the sake of developer's readability and comfortability. There is little or no added value for the end user or the purpose of the program itself. 'Yes, it's a great feeling when your code fits like a jigsaw puzzle, but also more complexity = more code being executed. Behind that function call, behind that nested expression and that "p = malloc(sizeof(*p))", etc. there might be extra complexity for the sake of developer's readability and comfortability. There is little or no added value for the end user or the purpose of the program itself.' See? The same argument can be used against C in favor of assembly. Abstractions allow us to write safer, more correct code in less time, which actually does offer a lot of added value for the end user. C makes many useful abstractions harder or downright impossible, which is one reason why software written in C is generally such a shitshow from a security perspective.

scoutt 4y ago
> Behind that function call, behind that nested expression and that "p = malloc(sizeof(*p))", etc. there might be extra complexity for the sake of developer's readability and comfortability. There is no way to avoid most of things you listed. It's not comfort; it's a necessity. > software written in C is generally such a shitshow Whatever language you use to code, all your calls will sooner or later pass through a function call, a nested expression or a malloc()/free() call, somewhere in the huge stack of C code your language needs, depends and relies on. There is no escape. Basically, today your preferred language exists and might be able to something just because C code exists.
- adwn 4y ago
  > There is no way to avoid most of things you listed. Oh yes, there definitely is: There are no function calls, nested expressions, or malloc in assembly – those are abstractions provided by the language and translated by the compiler, for comfort, not necessity. In fact, you can simulate all that in C itself: use gotos and an explicitly managed memory area as stack, and manually transform nested expressions into SSA form.