Hacker News Reader

Comment by Joker_vD | Hacker News Reader

You know, sometimes I wish the programming languages had a better distinction between "immutable data pieces" and "stateful agents". Sometimes it's really nice to have a simple struct for which you (or anyone else) can write many function to act upon. Sometimes it's really nice to have an opaque "object" with methods to yank described in some public interface, but which encapsulates loads of state and other objects inside it so you don't have to think about all of that.

View on HN

C# will be getting records in .NET 5, which would be analogous to what you refer as 'immutable data pieces', in addition to the normal objects the language has always had. https://devblogs.microsoft.com/dotnet/announcing-net-5-0-rc-...

This is exactly the reason C++ was created. It has structs and classes. In theory, structs and classes are exactly the same, but conventionally, a struct represents some kind of data object while a class represents something with encapsulation and state.

This is probably an imperfect solution, but isn't this kind of what Actors provide? Syntax and concurrency aside, passing a message is equivalent to calling a method.

The biggest annoyance I can foresee is discoverability. Object-orinented classes make it pretty clear what a given object's interface is (just look at its public methods). This is not true of actors in the languages I've used (not many), but in theory it should be a fairly trivial question of syntax.

The "stateful agents" is what OOP is all about. The objects are interpreters. I referenced a discussion elsewhere in this thread between Alan Kay and Rich Hickey where Kay talks about the value of interpreters. Rich Hickey talks about data/values coming from a seismometer or an IoT device but what he misses there I think is that it's not all just "data". There are also stateful agents. The seismometer (or the earthquake) is a stateful agent and the data is messages that are sent by it. If we had to model a seismometer or iot device (e.g. a smoke alarm) it would be best to do so using an object that encapsulates it's state and manages itself. It only communicates to the outside world with messages/data (in this case a sound when the temperature exceeds some internal state). I can replace my smoke alarm with another and I don't need to understand anything about its internal data or how it interprets it.

But for dealing with the historical data from an IoT device it may make sense to use a data oriented/functional approach. That time series data is not stateful, it's an immutable history of something stateful. Functions/transformations work best there usually.

Right. And the problem is, quite often those "data/values" turn out to be objects too, and for no good reason. Take the whole Active Records approach, for example, re-implemented in Java in the most straightforward way possible: you have a class with data fields (well, with getters/setters) but it also has "Save()/Load()" methods on it. Ugh.

So like an Erlang map and a GenServer?

Reply on news.ycombinator.com