In the third example, is function isProlific missing a parameter?
Principles of Data Oriented Programming
81–90 of 139 posts
Re: Principles of Data Oriented Programming
#82It's a good idea to write a book about a data-oriented development style (I'm working on a methodology, a way of working in data-intensive projects called Data2Value). However, JavaScript or Clojure are not ideal for demonstrating this methodology in the sense that industrial applications will more likely be built in C++, Java or Python. For example C++ and Java support Apache UIMA, which is an industry standard for…
Data oriented programming is orthogonal to the type of biggish data tools you're talking about, although I agree that in the present day, the latter is actually a more interesting subject for methodological discussion.
Re: Principles of Data Oriented Programming
#83To principle #2: The author acknowledges this as being incompatible with static typing, but I'm not so sure. Is it that, or is it that it's incompatible with contemporary static languages? In FP, we already have a concept of type-safe hetergeneous lists and maps, and even some clever implementations in languages like Java[1]. The ergonomics are often less-than-stellar, but I'm pretty sure that's something a new langu…
I think a TypeScript style structural type system could work.
Be careful because there are perf issues if you are using parametric polymorphism. Monomorphic functions are preferable but the real problems occur once you get past the inline cache's maximum number of 'shapes'. This obviously applies to regular JS as well.
Re: Principles of Data Oriented Programming
#84I don't think these principles add up to something useful. It's not complete and I think some of the principles don't align that well to the problem space. The big one: "Data is immutable". The problem here is that data isn't actually immutable (generally) and mutability isn't actually the problem. The problem is unmanaged references or other dependencies on the mutable data. The "source of truth" becomes muddled whi…
> Immutability is a very useful tool since you have have any kind of dependency -- direct, indirect, implied, etc) -- and there's no worry. But you still need a mechanism to manage mutating data.
I agree. For me it feels like immutable data is a tool, not a universal principle. For example, in low-level C programming or direct control of a register in an embedded context, immutable data isn't a principle, it's just another approach.
What I mean by "universal" is something like SOLID. [1] (Most people only use SOLID for OOP, but Uncle Bob makes it clear in Clean Architecture that he thinks SOLID is universal, and not limited to OOP.)
That said: it does feel like immutable data should be the _default_ approach in many situations. But that's really hard to do in most languages.
[1] https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...
Re: Principles of Data Oriented Programming
#85I don't think these principles add up to something useful. It's not complete and I think some of the principles don't align that well to the problem space. The big one: "Data is immutable". The problem here is that data isn't actually immutable (generally) and mutability isn't actually the problem. The problem is unmanaged references or other dependencies on the mutable data. The "source of truth" becomes muddled whi…
Immutability is not the fact that something can not change in this case. It has more to do with the identity of a value. Every time you change anything inside the data structure you get a new reference, that is it!
Re: Principles of Data Oriented Programming
#86I don't think these principles add up to something useful. It's not complete and I think some of the principles don't align that well to the problem space. The big one: "Data is immutable". The problem here is that data isn't actually immutable (generally) and mutability isn't actually the problem. The problem is unmanaged references or other dependencies on the mutable data. The "source of truth" becomes muddled whi…
I think "data are immutable" should be qualified - usually it means "data are immutable through your codepaths" and if you are mutating data, you need explicit checkouts and checkins of the data.
This is the basic principle behind how sane database transactions work.
ORMs in some languages can be especially dangerous if they overload the getter/setters of the object in such a way that the checkins and checkouts are obscured; you could be passing your object to a function or method that expects to mutate a polymorphic class[0] that is usually a traditional "shared memory" form of objects, well hopefully you can imagine the chaos, redundant database transactions, consistency problems, failure modes, uncaught exceptions, etc. that are going to be a nightmare to debug.
[0] worse yet, imagine if it's someone else's code and they change the api from not mutating to mutating for performance reasons. Will you notice the documentation change or the changelog? It's bad enough in the case when it's not an ORM and just a mutable object.
Re: Principles of Data Oriented Programming
#87We certainly use some of these principles in OrgPad.com and some of those inspired even the User Experience in a fundamental way. E.g. a bullet point list in a linear medium such as a text or a slide in a presentation is like a star in a graph, where all children have the same weight. The thing is, when people see it like that graphically, they sometimes get ideas they wouldn't have, if they stared at a long text. Sometimes they figure out, that actually the points are not equal weighted or that there isn't such a clear boundary and connect some of these children together either by a link or by selecting the same colour to group them.
Btw. we program everything in Clojure + ClojureScript so immutability and the other points is like preaching to the choir.
Not related, I thought Manning will not publish the book. At least that is the last information I have seen a few days ago. I thought about buying that book.
Re: Principles of Data Oriented Programming
#88Earlier quoted context omitted.
I think a TypeScript style structural type system could work.
Be careful because there are perf issues if you are using parametric polymorphism. Monomorphic functions are preferable but the real problems occur once you get past the inline cache's maximum number of 'shapes'. This obviously applies to regular JS as well.
Perhaps I misunderstand, but wouldn't that only apply if you attach functions to objects? I suppose you wouldn't do that if you follow data oriented programming principles.
Re: Principles of Data Oriented Programming
#89I don't think these principles add up to something useful. It's not complete and I think some of the principles don't align that well to the problem space. The big one: "Data is immutable". The problem here is that data isn't actually immutable (generally) and mutability isn't actually the problem. The problem is unmanaged references or other dependencies on the mutable data. The "source of truth" becomes muddled whi…
You realize data is immutable when you first try to implement history.
Mutability is just a hack to save some memory.
Re: Principles of Data Oriented Programming
#90I don't think these principles add up to something useful. It's not complete and I think some of the principles don't align that well to the problem space. The big one: "Data is immutable". The problem here is that data isn't actually immutable (generally) and mutability isn't actually the problem. The problem is unmanaged references or other dependencies on the mutable data. The "source of truth" becomes muddled whi…
This seems to be describing a style of programming, and you'll have to take these principles in the spirit that they were intended, i.e. in the context of that programming style. I recognize this style as a common style in OOP/FP languages such as Scala, where it's common to pass around immutable Plain Old Scala Objects (made from lists and hashmaps).