data in clojure and janet vs most other places

data-in-clojure-and-janet-vs-most-other-places.md

• Why getters and setters are terrible - Eric Normand - 2019-07

• Why you shouldn't hide your data - Eric Normand - 2019-04-15 / 2019-09-20

• The Expression Problem and its solutions - Eli Bendersky - 2016

  Imagine that we have a set of data types and a set of operations that act on these types. Sometimes we need to add more operations and make sure they work properly on all types; sometimes we need to add more types and make sure all operations work properly on them. Sometimes, however, we need to add both - and herein lies the problem. Most of the mainstream programming languages don't provide good tools to add both new types and new operations to an existing system without having to change existing code. This is called the "expression problem". Studying the problem and its possible solutions gives great insight into the fundamental differences between object-oriented and functional programming and well as concepts like interfaces and multiple dispatch.

• Data > Functions > Macros. But Why? - Eric Normand - 2014-12-24 / 2018-08-23

• Data, Visibility, and Abstraction - Stuart Sierra - JavaZone 2013 - video at youtube

• Thinking in Data - Stuart Sierra - Clojure/West 2012 - video at youtube

  • The Universal Design Pattern - Steve Yegge - 2008 - article mentioned by Stuart Sierra as "The Properties Pattern"
    • Dealing with Properties - Martin Fowler - 1997
    • Prototype-based programming - Wikipedia
    • Do-it-yourself Reflection - Peter Sommerlad, Marcel Rüedi
    • Prototype pattern - Wikipedia
    • Self programming language - Wikipedia
    • Refactoring to Adaptive Object Modeling: Property Pattern - Christopher G. Lasater

• The Value of Values - Rich Hickey - goto; conference 2012 - video at youtube

• Rich Hickey Q&A - Michael Fogus - 2011

  Fogus: Following that idea—some people are surprised by the fact that Clojure does not engage in data-hiding encapsulation on its types. Why did you decide to forgo data-hiding?

  Hickey: Let’s be clear that Clojure strongly emphasizes programming to abstractions. At some point though, someone is going to need to have access to the data. And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t. This is in addition to the other losing that occurs when simple information is put into classes. To the extent the data is immutable, there is little harm that can come of providing access, other than that someone could come to depend upon something that might change. Well, okay, people do that all the time in real life, and when things change, they adapt. And if they are rational, they know when they make a decision based upon something that can change that they might in the future need to adapt. So, it’s a risk management decision, one I think programmers should be free to make.

  If people don’t have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers.

  • HN Discussion

• Clojure's Solutions to the Expression Problem - Chris Houser - Strange Loop 2010 - video at youtube

• Information Hiding Wikipedia Page

  • On the Criteria To Be Used in Decomposing Systems into Modules - David Parnas - 1972
  • Does functional programming ignore the benefits gained from the "On the Criteria To Be Used in Decomposing Systems into Modules" (data hiding)?