SIMD b-tree traversal? Not maintaining two copies of that. I feel that it gives me 99% of the good of inheritance, polymorphism (Rust just makes the vtable explicit) and encapsulation.ĭRY is good in theory, but I think you need to either have something be tricky or appear a lot to move it into its own thing. Now, to prevent chaos there is a rule that you must own the struct and/or the trait (I think executables should be able to break that rule). I much prefer Rust’s traits, which allow implementing an interface for any struct. Behavior inheritance quickly turns into a web where you need to start special-casing things. These issues are compounded by DRY taken too far and cargo-culting until we get EarlyExitLoopRangeFactory instead of a for loop with a break statement. There are good parts, but a lot of people don’t realize that the original descriptions of OOP sound a lot more like microservices than what we now call OOP. Enterprise FizzBuzz may be a parody, but anyone who has ever worked in a large enough OOP codebase will go from “this is funny” to “wait I’ve seen this in production code” pretty quickly. I would argue that there is a LOT of cargo-culting around OOP. It's definitely not only a quality metric of a programming language how quickly you can create one readable, performant and correct program, but also how good you can change or compose existing programs to add new functionality. But is it better than regular OOP with some someObj instanceof someType statements? ) and a "content" pointer that you would have to cast into different other struct types. I guess you would have a struct or record "Expression" with a "type" variable that stores an enum (APPLICATION = 0, NUMBER_LITERAL = 1, ADDITION = 2. Can a point be made that both classical functional languages and OOP-languages are better than procedural languages in whatever metric? (You would probably disagree, but other people might say yes.) I wonder how a program would look that neither has OOP dynamic dispatch nor pattern matching. In some modern languages like Scala, that have both dynamic dispatch and pattern matching, you have to decide whether you want to make your class hierarchy "open" or "closed". If you go the oop-interface route, you need the visitor-pattern for that, which I find ugly and tedious. Object oriented programming makes it easier to add new subtypes to an interface and pattern-matching in functions for a closed type-hierarchy makes it easier to add new operations ( eval(expr), prettyprint(expr), compile(expr), step(expr)). There is the so called "expression-problem" on how to write an interpreter for parsed programming language expressions and their subtypes, like "number", "addition" and "function application".
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |