Apart from my family and some minor health issues, I currently am focused on 2 things: learning Luxembourgish/Luxembourgian and develop a deep understanding of functional programming.
About the former one: that should help me find a job in some Luxembourgish administration (I really wish I'll be able to find one soon).Luxembourg might be a small country, but I think it's managed well, CTIE (Luxembourgish administration that manages most of the IT infrastructure and software used by the state) has quite smart and competent people (also some dumb ones, but where's that not the case?), and I think I like the culture, which is almost my own, as I grew up close to Luxembourg and even went to a german-speaking school, while speaking family-native French (I'm as fluent speaking German as French, no accent).
Regarding the latter one, I started applying functional programming principles early this year, almost as obstinately as I can (and as much as possible using Java 8 then now 17) (I've got more than 16 years of professional experience using Java, both as a developer and software architect).
This was just the beginning of a more insightful journey into new coding practices, which result from one principle I discovered this year: source code should never lie.
This became an evidence once I implemented and started to use my self-made "Maybe" type (a better Optional - Optional is quite weak if you want to avoid procedural programming). While using Maybe, it struck me that what I did was just explicitly forcing my code to say the truth. So I started to dig into types and have types represent various states (this may be seen as a better use of object orientation - this is not relevant, what's relevant is the improvement in the quality of my code). Using the multiple types (usually sub-classes) and combining with "fold" methods make a lot of if-else unnecessary and force the developer to handle each case: one can't just forget one case. What one may do is not handle a case, but it remains explicitly visible in the source code, with as much importance as the other cases. Then, the removal of the if-else usually means that the logic is much simpler to read and reason about. Using adequate types also means that only functions of the actual type are available, so we also reap the benefits of OO design. Also, while it is stated that Optional was not made to be serialized, I made my Maybe type so that it may be used in serialized objects and thus accurately reflect the state of affairs.
I'm still discovering FP patterns (for example, I still have to read about how to properly manage IO/side-effects/state. Once I've learned FP patterns, I'll focus on the synthesis of my knowledge of Java, DDD and FP in order to find out how to best apply FP and DDD principles to professional Java projectes, given the constraints of the language, it's modularity (Java 9 modules, Maven modules) and the JVM. I already have the intuition that the Spring framework (which is the de facto standard in Luxembourg businesses) might not be a good fit to serious FP programming - at least not without appropriate abstractions on top of it. This probably already starts with the dependency injection/inversion of control, which, I think (to be confirmed, though), does not make sense if a purely functional approach.
Regarding a Maybe type (I'm picky about naming - remember, code shouldn't lie): I firmly believe that Optional and Option are bad names for this type. As the user of an API/function that may return something or nothing, I don't get a choice about what I receive. Maybe I receive something, maybe I receive nothing. It's not like I receive some option from which to choose. As the one who implements the API, I have indeed the choice to provide something or nothing, so yes, I have some option, but what I'll return may be something or may be null. Thus I strongly recommend to stick with the name Maybe. Option/Optional is just lying to the user of the API/function.
It might just be an anecdote, my own, but I think that using lambdas and a few other FP principles with Java >= 8 for more than 9 months really opened doors in my mind about functional programming and types (way more than following Martin Oderski's FP courses on Coursera), to the point that I now really feel comfortable reading and understanding more advanced literature about FP, even stuff in Haskell. I'm not saying it's easy/simple. But if I focus, I think I'm now able to understand, which might not have been the case just last year. So Java provides, I think, a good enough environment to learn more than the rudiments of FP.
The most important lesson learned this year about programming is: source code must not lie. Replace nullable stuff with Maybe, when a Boolean may be null, don't just use a Boolean, but (for example) reimplement a NullableBool interface that has three types: TrueBool, FalseBool and UndefinedBool/NullBool. To represent two-valued booleans, I have Bool with subclasses TrueBool and FalseBool. Don't hesitate to use multi-valued booleans in cases where you have to represent probabilities (I, for example, have used a TetraValuedBool, which has the types False-Improbable-Probable-True). All these Bool types come with various static functions ('of()' to get/construct an instance) and non-static functions ('fold()'). To allow functions to return results that may represent anomalies, don't hesitate to use a Result type, which has two sub-types, one wrapping anomalies and one wrapping the actual legit result, and, again work with a "fold" function to handle both cases explicitly. Use strong types whenever possible, even if it's just some wrap around a String. Nothing is just a String.
This takes some time to implement, but once you have, it just makes your code easy to read and understand, nothing is hidden anymore: no implicit consequences. Once your code does not lie anymore, it becomes self-documenting, especially given FP is rather declarative (one does rather state what one wants than how to do it). This is rather cool, as you won't have to maintain separate documentation (at least not for developers).
Now, I'm not sure I recommend you do the same: my client will stop my contract by the end of this year because they don't understand the benefits of this higher code quality. They'd have preferred 'simple' procedural code, with which they believe I would have been able to deliver more features faster. Even my developer colleagues don't recognize the beauty of it. This, of course, is utter BS, because their problem is scope creep and they need to designate some responsible for being late. They just decided it's me. I'll be sacrificed on the altar of bad project management. I'm still making up my mind about defending myself and telling my point of view to their superiors: Luxembourg is small, it's not a place where one wants open conflicts, but at the same time, do I have to allow being made responsible for bad PM choices?
The intellectual challenge of combining FP, DDD and Java is absolutely great and quite huge. I couldn't do it just after-work (my wife and I are raising two little boys), because the deeper understanding of these needs regular, almost daily practice and reading about these topics. Doing this at work clearly made me vulnerable in a way I didn't see coming when I began this path, so I definitely can't recommend it to everyone. But I can't wait reaping the results of my deeper understanding of these topics, and I'm really happy to still be a programmer instead of doing some management (that is also an option - I have both experience and university degrees in engineering and in management), it's been a long time since I've had so many interesting intellectual opportunities.
Some references I used this year to improve my programming skills or just enjoyed reading (I consider these to be a good intro into FP and DDD):
- [1] ...and it's related source code (cf. the "core" module), which I used as a reference (no direct dependency), in order to be able to make some changes: https://github.com/siy/pragmatica
Apart from my family and some minor health issues, I currently am focused on 2 things: learning Luxembourgish/Luxembourgian and develop a deep understanding of functional programming.
About the former one: that should help me find a job in some Luxembourgish administration (I really wish I'll be able to find one soon).Luxembourg might be a small country, but I think it's managed well, CTIE (Luxembourgish administration that manages most of the IT infrastructure and software used by the state) has quite smart and competent people (also some dumb ones, but where's that not the case?), and I think I like the culture, which is almost my own, as I grew up close to Luxembourg and even went to a german-speaking school, while speaking family-native French (I'm as fluent speaking German as French, no accent).
Regarding the latter one, I started applying functional programming principles early this year, almost as obstinately as I can (and as much as possible using Java 8 then now 17) (I've got more than 16 years of professional experience using Java, both as a developer and software architect).
This was just the beginning of a more insightful journey into new coding practices, which result from one principle I discovered this year: source code should never lie. This became an evidence once I implemented and started to use my self-made "Maybe" type (a better Optional - Optional is quite weak if you want to avoid procedural programming). While using Maybe, it struck me that what I did was just explicitly forcing my code to say the truth. So I started to dig into types and have types represent various states (this may be seen as a better use of object orientation - this is not relevant, what's relevant is the improvement in the quality of my code). Using the multiple types (usually sub-classes) and combining with "fold" methods make a lot of if-else unnecessary and force the developer to handle each case: one can't just forget one case. What one may do is not handle a case, but it remains explicitly visible in the source code, with as much importance as the other cases. Then, the removal of the if-else usually means that the logic is much simpler to read and reason about. Using adequate types also means that only functions of the actual type are available, so we also reap the benefits of OO design. Also, while it is stated that Optional was not made to be serialized, I made my Maybe type so that it may be used in serialized objects and thus accurately reflect the state of affairs.
I'm still discovering FP patterns (for example, I still have to read about how to properly manage IO/side-effects/state. Once I've learned FP patterns, I'll focus on the synthesis of my knowledge of Java, DDD and FP in order to find out how to best apply FP and DDD principles to professional Java projectes, given the constraints of the language, it's modularity (Java 9 modules, Maven modules) and the JVM. I already have the intuition that the Spring framework (which is the de facto standard in Luxembourg businesses) might not be a good fit to serious FP programming - at least not without appropriate abstractions on top of it. This probably already starts with the dependency injection/inversion of control, which, I think (to be confirmed, though), does not make sense if a purely functional approach.
Regarding a Maybe type (I'm picky about naming - remember, code shouldn't lie): I firmly believe that Optional and Option are bad names for this type. As the user of an API/function that may return something or nothing, I don't get a choice about what I receive. Maybe I receive something, maybe I receive nothing. It's not like I receive some option from which to choose. As the one who implements the API, I have indeed the choice to provide something or nothing, so yes, I have some option, but what I'll return may be something or may be null. Thus I strongly recommend to stick with the name Maybe. Option/Optional is just lying to the user of the API/function.
It might just be an anecdote, my own, but I think that using lambdas and a few other FP principles with Java >= 8 for more than 9 months really opened doors in my mind about functional programming and types (way more than following Martin Oderski's FP courses on Coursera), to the point that I now really feel comfortable reading and understanding more advanced literature about FP, even stuff in Haskell. I'm not saying it's easy/simple. But if I focus, I think I'm now able to understand, which might not have been the case just last year. So Java provides, I think, a good enough environment to learn more than the rudiments of FP.
The most important lesson learned this year about programming is: source code must not lie. Replace nullable stuff with Maybe, when a Boolean may be null, don't just use a Boolean, but (for example) reimplement a NullableBool interface that has three types: TrueBool, FalseBool and UndefinedBool/NullBool. To represent two-valued booleans, I have Bool with subclasses TrueBool and FalseBool. Don't hesitate to use multi-valued booleans in cases where you have to represent probabilities (I, for example, have used a TetraValuedBool, which has the types False-Improbable-Probable-True). All these Bool types come with various static functions ('of()' to get/construct an instance) and non-static functions ('fold()'). To allow functions to return results that may represent anomalies, don't hesitate to use a Result type, which has two sub-types, one wrapping anomalies and one wrapping the actual legit result, and, again work with a "fold" function to handle both cases explicitly. Use strong types whenever possible, even if it's just some wrap around a String. Nothing is just a String.
This takes some time to implement, but once you have, it just makes your code easy to read and understand, nothing is hidden anymore: no implicit consequences. Once your code does not lie anymore, it becomes self-documenting, especially given FP is rather declarative (one does rather state what one wants than how to do it). This is rather cool, as you won't have to maintain separate documentation (at least not for developers).
Now, I'm not sure I recommend you do the same: my client will stop my contract by the end of this year because they don't understand the benefits of this higher code quality. They'd have preferred 'simple' procedural code, with which they believe I would have been able to deliver more features faster. Even my developer colleagues don't recognize the beauty of it. This, of course, is utter BS, because their problem is scope creep and they need to designate some responsible for being late. They just decided it's me. I'll be sacrificed on the altar of bad project management. I'm still making up my mind about defending myself and telling my point of view to their superiors: Luxembourg is small, it's not a place where one wants open conflicts, but at the same time, do I have to allow being made responsible for bad PM choices?
The intellectual challenge of combining FP, DDD and Java is absolutely great and quite huge. I couldn't do it just after-work (my wife and I are raising two little boys), because the deeper understanding of these needs regular, almost daily practice and reading about these topics. Doing this at work clearly made me vulnerable in a way I didn't see coming when I began this path, so I definitely can't recommend it to everyone. But I can't wait reaping the results of my deeper understanding of these topics, and I'm really happy to still be a programmer instead of doing some management (that is also an option - I have both experience and university degrees in engineering and in management), it's been a long time since I've had so many interesting intellectual opportunities.
Some references I used this year to improve my programming skills or just enjoyed reading (I consider these to be a good intro into FP and DDD):
- [0] Pragmatic Functional Java: https://dzone.com/articles/introduction-to-pragmatic-functio... ...
- [1] ...and it's related source code (cf. the "core" module), which I used as a reference (no direct dependency), in order to be able to make some changes: https://github.com/siy/pragmatica
- [2] Functional programming made easier: https://leanpub.com/fp-made-easier (that one is quite easy to ready)
- [3] https://dusted.codes/the-type-system-is-a-programmers-best-f... (posted a few days ago on HN)
- [4] https://fsharpforfunandprofit.com/ (I'd really like to do some project in F#)
- [5] https://www.cambridge.org/core/books/purely-functional-data-...
- [6] https://www.amazon.fr/Implementing-Domain-Driven-Design-Vaug...
- [7] https://www.amazon.com/Functional-Programming-Java-Harnessin...