5 ms·

>What about React? They say right on their front page: “Build encapsulated components that manage their own state, then compose them to make complex UIs.” That’

>What about React? They say right on their front page: “Build encapsulated components that manage their own state, then compose them to make complex UIs.” That’s a textbook definition of OOP. I made a mistake here. Not react. Redux. Basically the DOM update loop that's popularly associated with languages like elm and frameworks like react. That world changes so fast I'm not even sure if Redux is relevant anymore. >My primary focus is meeting requirements and budget. All technical decisions about reusability, modularity, performance, and the rest of them, are driven by these two. Then do what you need just know that OOP doesn't contribute to reusability. I actually don't see any benefit to is over just procedural programming. >Almost everything has a performance budget. For a web app difference between 1ns and 1ms doesn’t matter at all, but difference between 100ms and 1 seconds still matters, users will complain, search engines will downrank. Desktop apps ideally need to respond within 17ms because mainstream displays render at 60Hz. Performance cost of immutability is huge, can be 1-2 orders of magnitude, for 2 reasons. (1) memory allocations are relatively expensive (2) CPUs have cache hierarchy, main memory is like 20-40 times slower than L1D cache, each time you allocating a new immutable object it’s pretty much guaranteed to be out of caches. Nah most CPU stuff is so fast none of this matters anymore. For web development, (I'm a web developer) They use languages like python with garbage collectors to handle stuff. The reason is because the bottlneck lies in IO. Python is slow but the database is slower and that's where they use a procedural language like C. For browser stuff they use javascript now and the DOM and the redux pattern so pure performance is no longer as critical because stuff is so fast anyway. I mean really when the browser is loading you're waiting on IO, not on rendering or javascript. >Also CAD/CAM/CAE, realtime multimedia, some projects in embedded esp. real-time stuff. By the way, these areas are what I mostly do for a living. That's similar to gaming right? Graphics. So essentially yes you do work in an area where FP is probably not the best choice. However the majority of programming nowadays is Web sites. Even so JS and functional programming is powerful enough to drive 3D graphics on web browsers. >However, the real value of OOP is when you have to deal with complex mutable state. Every single time mutable state is essential to the problem (rich GUI is just one area where it’s the case, there’re others), OOP has no good alternatives. What's the difference between a function that modifies state and a method that modifies it's own internal state? Almost none except the method is tied to context. The method cannot be used outside of that context. You have to instantiate state and irrelevant context to use a method and that is the problem. The alternative to OOP is to just use procedural programming because literally there is only one single difference that separates the two paradigms: Methods are tied to context, functions are not. In knowing this you will know that basically with OOP you're tying your hands together for no good reason. You can write those exact same methods as separate procedural functions to get the same functionality without the downsides. > I disagree that OOP promotes mutable state for cases when it’s not needed, it all depend on the language. JavaScript or Python don’t support immutable properties of their objects, but C# and (to lesser extent, but still) C++ do. It promotes it by virtue of being the only feature that separates a class from a namespace. If you're not using a mutable variable in your class you're not doing OOP because what you're doing is isomorphic to writing a namespace with functions. (You can have private functions in namespaces for certain languages to btw.) As I side note to easily about the FRP pattern you should just checkout ELM. https://elm-lang.org/examples/first-person https://elm-lang.org/examples/first-person. It's a batteries included functional programming framework that you can program right in the browser. In the example I gave you the first person 3D program is written by a user without the user ever writing a procedure or a method that modifies state. All the functions minus the shader stuff are strictly pure and therefore reusable.

Const-me 6y ago
> Basically the DOM update loop that's popularly associated with languages like elm and frameworks like react Have very little idea, I don’t do web development. > That's similar to gaming right? There’re differences e.g. games render at 60Hz, games don’t run CPU-bound jobs which load all cores of all CPUs for minutes to hours. But overall, indeed it’s much more similar to games than to web. > Graphics I would estimate graphics is 25% of code complexity in games (however most modern games are using off the shelf engines who implement major parts of that), and 10% of complexity of CAD/CAM. > the majority of programming nowadays is Web sites I think the majority of programmers nowadays, and have been for decades, working on internal line of business applications. No reason to generalize their experience over the rest of the software development. > Even so JS and functional programming is powerful enough to drive 3D graphics on web browsers. JS is merely passing data to WebGL APIs. These APIs are implemented in web browsers, and underneath browsers in GPU drivers. Both modern browsers and GPU drivers have millions of lines of code written in C or C++, and JS is not performant enough to replace these, not even close. > What's the difference between a function that modifies state and a method that modifies it's own internal state? Visibility of that state. Usability of the API. Composability of the overall thing. > The method cannot be used outside of that context. Yes, and that’s usually a good thing. Here’s a method: https://docs.microsoft.com/en-us/uwp/api/windows.storage.streams.ioutputstream.writeasync?view=winrt-19041#Windows_Storage_Streams_IOutputStream_WriteAsync_Windows_Storage_Streams_IBuffer_ https://docs.microsoft.com/en-us/uwp/api/windows.storage.str... You can’t write bytes to a stream without the stream. From API design perspective that’s a feature, not a bug. > What's the difference between a function that modifies state and a method that modifies it's own internal state? For some cases, runtime polymorphism helps a lot. In that case, neither you nor compiler knows what’s in the state or how’s that implemented, it only determined in runtime. Take a look at this toy API in C#: https://gist.github.com/Const-me/0745e09695e8e8615c14b18fc3fbe028 https://gist.github.com/Const-me/0745e09695e8e8615c14b18fc3f... The internal state of the object returned from setupConnection method can be just the TCP socket, or it can be a socket + AES decryption + a decompressor. The decrypt, decompressGzip and decompressLz4 functions are usable for any streams not just TCP sockets, you can pass them a file or any other stream and they’ll work just fine, despite their internal state changes to something completely different.

Const-me 6y ago

> Basically the DOM update loop that's popularly associated with languages like elm and frameworks like react Have very little idea, I don’t do web development. > That's similar to gaming right? There’re differences e.g. games render at 60Hz, games don’t run CPU-bound jobs which load all cores of all CPUs for minutes to hours. But overall, indeed it’s much more similar to games than to web. > Graphics I would estimate graphics is 25% of code complexity in games (however most modern games are using off the shelf engines who implement major parts of that), and 10% of complexity of CAD/CAM. > the majority of programming nowadays is Web sites I think the majority of programmers nowadays, and have been for decades, working on internal line of business applications. No reason to generalize their experience over the rest of the software development. > Even so JS and functional programming is powerful enough to drive 3D graphics on web browsers. JS is merely passing data to WebGL APIs. These APIs are implemented in web browsers, and underneath browsers in GPU drivers. Both modern browsers and GPU drivers have millions of lines of code written in C or C++, and JS is not performant enough to replace these, not even close. > What's the difference between a function that modifies state and a method that modifies it's own internal state? Visibility of that state. Usability of the API. Composability of the overall thing. > The method cannot be used outside of that context. Yes, and that’s usually a good thing. Here’s a method: https://docs.microsoft.com/en-us/uwp/api/windows.storage.streams.ioutputstream.writeasync?view=winrt-19041#Windows_Storage_Streams_IOutputStream_WriteAsync_Windows_Storage_Streams_IBuffer_ https://docs.microsoft.com/en-us/uwp/api/windows.storage.str... You can’t write bytes to a stream without the stream. From API design perspective that’s a feature, not a bug. > What's the difference between a function that modifies state and a method that modifies it's own internal state? For some cases, runtime polymorphism helps a lot. In that case, neither you nor compiler knows what’s in the state or how’s that implemented, it only determined in runtime. Take a look at this toy API in C#: https://gist.github.com/Const-me/0745e09695e8e8615c14b18fc3fbe028 https://gist.github.com/Const-me/0745e09695e8e8615c14b18fc3f... The internal state of the object returned from setupConnection method can be just the TCP socket, or it can be a socket + AES decryption + a decompressor. The decrypt, decompressGzip and decompressLz4 functions are usable for any streams not just TCP sockets, you can pass them a file or any other stream and they’ll work just fine, despite their internal state changes to something completely different.