3 ms·
Maybe it's just me but I find the part about structures a bit silly. So let's get rid of the big fat structs, and replace them with tuples. Nested tuples. How i
by zaro 10y ago
Maybe it's just me but I find the part about structures a bit silly.
So let's get rid of the big fat structs, and replace them with tuples. Nested tuples. How is that any different than a struct, apart from immutability? And it is worsened by the fact that the fields now are just indexes in a tuple/list instead of being named.
- bunderbunder 10y agoI think I'd go for records over tuples, so that the values can be named.
- douche 10y agoIf you're using a record, you're effectively just using a struct again...
- haasn 10y agoMathematically, structs and tuples are virtually equivalent. They are both examples of the same fundamental data construct: Product types (i.e. grouping multiple values together) The other two most important abstractions are sum types, i.e. unions or alternatives, and exponent types, i.e. function types, and IMO they're the two that are far more important for the success of functional programming.
- bunderbunder 10y agoI think that one depends on the language. In F#, for example, records are pass-by-reference and structs are pass-by-value. In a language-unspecified setting I like to follow the convention that structs are implied to be mutable data types and records are implied to be immutable data types. I don't know how widely-used that convention is, though.
- pmarreck 10y agoI think the design of this part depends on how well your functional language of choice implements immutable data structures, from a performance and memory consumption (and by inference, garbage collection) perspective.
- jstimpfle 10y agoProbably immutability is the point. Whether you want to name record members depends on the situation, but not having to name them consistently throughout your project (and instead being able to give names on pattern match) is often advantegeous. Look at the mess that is Sql Queries because you have to juggle all those names when joining.
- lmm 10y agoI agree that it's good to name the fields (i.e. use records or similar). The important idea is going from a big flat struct to a hierarchical one where related data is grouped together, so that you can have functions that operate on small subsets of the data. This gives you visibility over which functions touch which parts of the state, and makes those functions a lot more testable.