Win a copy of Secure Financial Transactions with Ansible, Terraform, and OpenSCAP this week in the Cloud/Virtualization forum!

Yehonathan Sharvit

+ Follow
since Feb 25, 2021
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Yehonathan Sharvit

Thank you Campbell and all of you at Coderanch for the open minded reaction to my "provocative" ideas.
Are you going to use your smart Dynamic class that you mentioned in the other thread about DOP?
2 weeks ago
Instead of endless holy wars ⚔️ static vs. dynamic or OO vs. FP, let's debate around code👩🏽‍💻.

Solve the coding challenges featured in this blog post in Java and argue about or against Data-Oriented programming.
2 weeks ago
We achieve high scalability due to data immutability.
In Chapter 5 of the book I explain how to leverage data immutability to implement an efficient data diff algorithm in order to detect conflicts between concurrent mutations.

Spoiler: This is similar to git 3-way merge conflict resolution.
The discussion about DOP in Java has started here.
I like what you created Mike! Curious to see how other Java folks receive it.

Could you elaborate further on what you wrote about type inference and give an example?
Data-Oriented programming is an interesting paradigm but it is quite challenging when we try to apply it in a statically-typed language like Java.

I am happy to answer questions about DOP in general and DOP in Java.
The main difference between DOP and FP is about how we treat data.

In most FP languages (e.g. OCaml, Haskell), data is statically typed. As a consequence, data access is not flexible. Whereas in DOP, data can be manipulated via generic functions.

For instance, in DOP one could write a function renameKeys that rename some fields in a record. This function would work with any record e.g. a Book or a User.

In traditional FP, one would have to write two separate functions renameKeysInBook and renameKeysInUser and to create two records Book2 and User2 with the new keys.

In traditional FP, field names compile away where in DOP fields are first-class citizens.

You can read more about the conceptual approach to information in this article.
Based on your reactions in this thread, I wrote a blog post to illustrate various ways of providing dynamic data access in Java.

Looking forward to get your feedback.
3 weeks ago
Making sure we never mutate data is an essential part of Data-Oriented programming.

Now, regarding static methods:

Traditionally in OOP, we encapsulate data in objects that contain both members and methods.

When data is represented as records we split code and data in two different entities:

1. A record for the data
2. A class with static methods for the code, where the methods receive the data they manipulate (the state) as an argument.

The main benefit of this approach is that it reduces the complexity of the class hierarchies.

I have made this provocative diagram to illustrate this complexity reduction.

Let me know if it makes things a bit clearer.

3 weeks ago
Ok. Let's say that  for now, having a flexible access to data is not beneficial enough to a Java developer so that he is willing to trade off type safety for it.

When about the other approach presented in the article where:

  • Data is represented with Java 14 records
  • Code is stored in static methods

  • Do you guys think that it could help reducing the complexity of  Java programs?
    3 weeks ago
    In fact your list of TicketAttribute is inline with the Data-Oriented spirit.

    The Data-Oriented approach would treat regular attributes and custom attributes in the same dynamic way.
    The benefits is that it gives you a unified approach to data.

    Let me give you a couple of benefits of this unified approach to data:

  • Get an attribute with myJiraTicket.get("myCustomAttribute") without the need to know if it's a custom attribute or a regular attribute.
  • Count the number of attributes without any custom codde
  • Serialize a JIRA ticket to JSON without any custom code
  • Duplicate a JIRA ticket to JSON without any custom code

  • I am not saying that you should this approach everywhere in Java. I am trying to illustrate what are the benefits of this approach in order to discover together what are the situations and use cases where it makes sense to trade off type safety for data access flexibility.

    3 weeks ago
    In Data-Oriented programming, we trade off type-safety for flexibility.

    I know it's not natural in Java. That's why I asked for advices from open-minded Java experts.

    For information systems that deal with information of dynamic nature, this tradeoff might make sense in some parts of the coded, even if it's not natural for Java developers.

    Suppose you need to represent the data of a JIRA ticket with fields like: title, author, priority etc.. in addition to custom fields that are defined by the user. How would you store those fields as members of a class whose layout is defined at compile time in Java?
    3 weeks ago
    You store each person in a separate maps.

    var joe = Map.of("Joe", 42);
    var kelly = Map.of("Kelly", 37);
    3 weeks ago