Pomisos released!

While the previous "official" Java desktop GUI framework, Swing, was based on the Publisher-Observer pattern, JavaFX is instead oriented around Properties.

Although superficially similar (they also allow listeners to be added), the crucial difference is the concept of "binding" properties to one another, essentially synchronizing them automatically. This allows for essentially writing GUI logic like a set of logic rules, e.g. (pseudocode) :

where visible and selected are both of type BooleanProperty. What’s more, you can bind multiple properties into complex statements, which essentially allows you to create dataflows that are updated automatically.

Essentially, the logic starts to look like a declarative stream specification, much more maintainable and convenient than the "Listener Hell" of Swing. It’s a shame JavaFX arrived only when classic desktop apps have already started to go out of fashion.

If you do want to start developing JavaFX applications, however, there’s several libraries that allow to comfortably code using Scala.

The first one, of course, is scalafx, which simply "Scalifies" the API, and adds a convenient DSL for property bindings. The previous example would now look like:

Even more rule-like^[1]!

Another thing is FXML development. FXML works pretty much like e.g. Android’s UI XML files - it allows you to separate general UI specification (the XML) from your business-logic code (a Controller class).

To take advantage of that convenience in Scala, there’s scalafxml. What’s especially nice is that integrates Scala DI approaches (like Macwire), to automatically instantiate the Controller classes^[2].

Over the last year or so, I’ve been evaluating Gremlin/TinkerPop, specifically the Scala implementation, in a variety of projects. Out of curiosity, I went with it as the DB layer for pomisos, using an embedded OrientDB instance as the storage implementation.

Unfortunately^[3], while the API Gremlin API is almost amazingly intuitive (and the Scala implementation doubly so, big kudos to Michael Pollmeier for his work here), I found the "constant" cost of introducing this kind of abstraction seems to be an overkill for projects with only several, unconected, entity types.

Specifically, the biggest problem was creating generalized DAOs, and attempting to use edges as an Ersatz for trivial relations.

To be clear though: in this case, the aforementioned cost of introduction is comparable to an RDBMs. It’s just that, for projects of scale comparable to pomisos, simple object stores are more than sufficient.

From my observations, it appears there’s a persistent myth that experienced developers somehow create perfect code instantly - like some sort of rainbow-excreting unicorns. I find that exceedingly harmful, since it effectively reduces the amount of code that gets out to the public, due to lowered self-esteem of aspiring devs.

By the way, one of the best things in Clean Code is the part where Uncle Bob shows the continuous process of implementing a simple example, starting from a very messy prototype.

This is exactly why I haven’t squashed the ongoing commits. I think it’s a good idea for there to be more transparency in development of similar-scale projects, exactly because of the learning potential in demonstrating the actual coding process.