4 ms·

This comment section just shows how so many developers are victims of group think. Here is actual evidence that at least hints that the primary paradigm is wron

This comment section just shows how so many developers are victims of group think. Here is actual evidence that at least hints that the primary paradigm is wrong, and immediately a bunch of nerds jump and attack, instead of taking the criticism in good faith. Compare this to discussions about FP, new languages like Rust, and so forth. This really demonstrates the primary vogue mindset is increasing complexity and hierarchy to the detriment of all else, and is why the supposed new paradigms of "modern software development" are not really that new but just evolutions of the current paradigms. You really touch what is a culture's sacred cows by that which attracts criticism without any real sincere rebuttal.

dsattt 4y ago
I was thinking the same thing. Everybody is so desperate to ship features fast that any hint against it triggers a mob with a bloodlust.
WA 4y ago
What are you talking about? The first comment is literally a real sincere rebuttal: "performance doesn’t matter in 99.9% of apps".
- noobermin 4y ago
  If 99% of apps are slower, that's everything I do on a computer! Yes it matters! It doesn't matter for corporate environments perhaps. It does hell of matter for consumer facing web stuff, both the front end and the backend! 99% is a lot of stuff, so yes it does matter. And the top reply (right now) is about 99% of the time is spent waiting for user input, and no, that isn't even true. A lot of that "input" is waiting on the network, and the number of requests for any application makes per unit time definitely scales with increasing code complexity. But anyway, may be that makes a tenuous argument that most code does not care about performance, but again, if it's 99% of code, then yes it matters because it's my entire computer, and that's how we have machines that are faster than they've ever been yet they struggle to edit text compared to say emacs on pentium 4.
- flumpcakes 4y ago
  > performance doesn’t matter in 99.9% of apps I don't think this is a sincere rebuttal at all. In fact, it perversely proves the point. If 99.9% of apps aren't caring about performance - that's probably why my $2000 computer is slow to open a text file. I want all of my applications to be well performant. Using the modern web is an atrocious experience most of the time. It's strange when I stumble upon a mostly-unchanged "web 2.0" era site. It loads instantly, like, shockingly fast. It doesn't have all the SPA widgets and "interactivity" but it works, loads extremely fast, and doesn't turn my computer's fans on. My computer is several orders of magnitude faster than my computer from 2001. Yet the applications I want to use feel slower. People say that programmer productivity is more important than efficiency, I don't think programmers are more productive. We've just lowered the bar.
- inkblotuniverse 4y ago
  90 percent of apps are slow and unreponsive, and harming people by being so: but software developers aren't directly harmed by the effects of their actions, so the situation continues.
ookdatnog 4y ago
I'm not sure why you're bringing up FP and Rust here. The idiomatic FP and Rust versions of the code in the article would be similar to the fast version: you use algebraic data types to represent your Shape type (which are just tagged unions under the hood, exactly like in the article) and pattern match on the type, which can be compiled to a jump table (exactly like in the article). And I think neither FP nor Rust discourage the internal-representation-dependent 10x optimization. They only discourage doing this across module boundaries, but the style of programming encouraged by FP and Rust encourages putting your datatype variants together in one module (unlike OOP). So with those languages you're much more likely to naturally arrive at a fast solution than with traditional OOP.
- brewmarche 4y ago
  Agree. Typical FP with ADTs would lead to the same kind of data-driven style. The point at which he went too far for me is probably the struct layout optimisation (every shape has two defining numbers, it feels a bit restrictive). For me that’s the point where I’d check whether it’s really warranted and if so create new types to distinguish the original domain (Shape) vs. number crunching (ShapeDefinedByTwoNumbers - needs a better name).

dsattt 4y ago

I was thinking the same thing. Everybody is so desperate to ship features fast that any hint against it triggers a mob with a bloodlust.

WA 4y ago

What are you talking about? The first comment is literally a real sincere rebuttal: "performance doesn’t matter in 99.9% of apps".

noobermin 4y ago
If 99% of apps are slower, that's everything I do on a computer! Yes it matters! It doesn't matter for corporate environments perhaps. It does hell of matter for consumer facing web stuff, both the front end and the backend! 99% is a lot of stuff, so yes it does matter. And the top reply (right now) is about 99% of the time is spent waiting for user input, and no, that isn't even true. A lot of that "input" is waiting on the network, and the number of requests for any application makes per unit time definitely scales with increasing code complexity. But anyway, may be that makes a tenuous argument that most code does not care about performance, but again, if it's 99% of code, then yes it matters because it's my entire computer, and that's how we have machines that are faster than they've ever been yet they struggle to edit text compared to say emacs on pentium 4.
flumpcakes 4y ago
> performance doesn’t matter in 99.9% of apps I don't think this is a sincere rebuttal at all. In fact, it perversely proves the point. If 99.9% of apps aren't caring about performance - that's probably why my $2000 computer is slow to open a text file. I want all of my applications to be well performant. Using the modern web is an atrocious experience most of the time. It's strange when I stumble upon a mostly-unchanged "web 2.0" era site. It loads instantly, like, shockingly fast. It doesn't have all the SPA widgets and "interactivity" but it works, loads extremely fast, and doesn't turn my computer's fans on. My computer is several orders of magnitude faster than my computer from 2001. Yet the applications I want to use feel slower. People say that programmer productivity is more important than efficiency, I don't think programmers are more productive. We've just lowered the bar.
inkblotuniverse 4y ago
90 percent of apps are slow and unreponsive, and harming people by being so: but software developers aren't directly harmed by the effects of their actions, so the situation continues.

ookdatnog 4y ago

I'm not sure why you're bringing up FP and Rust here. The idiomatic FP and Rust versions of the code in the article would be similar to the fast version: you use algebraic data types to represent your Shape type (which are just tagged unions under the hood, exactly like in the article) and pattern match on the type, which can be compiled to a jump table (exactly like in the article). And I think neither FP nor Rust discourage the internal-representation-dependent 10x optimization. They only discourage doing this across module boundaries, but the style of programming encouraged by FP and Rust encourages putting your datatype variants together in one module (unlike OOP). So with those languages you're much more likely to naturally arrive at a fast solution than with traditional OOP.

brewmarche 4y ago
Agree. Typical FP with ADTs would lead to the same kind of data-driven style. The point at which he went too far for me is probably the struct layout optimisation (every shape has two defining numbers, it feels a bit restrictive). For me that’s the point where I’d check whether it’s really warranted and if so create new types to distinguish the original domain (Shape) vs. number crunching (ShapeDefinedByTwoNumbers - needs a better name).