Bottom Up vs Top Down Design in Clojure - Mark Bastian

This strikes me as a perfect visual example of repl-driven development. I like how he starts very simple and slowly makes it more sophisticated, testing every step of the way. If you've never tried it before, I highly recommend giving it a shot - it's extremely satisfying. I use Clojure, but other lisps also have fantastic repl environments that facilitate this style of development. "Bottom Up vs Top Down Design in Clojure"[0] is the talk that really made it clear to me how to design programs this way. [0] ▶ this video

I picked on needless complexity due to top-down design not on static typing per se. Here's a good video highlighting the difference of approach. Well worth watching. Applies to how many Java architects would design a solution. I see the same kind of top-down approach happening in the Typescript area as well. ▶ this video

This is exactly my impression after taking a quick glance through these articles as well. If anyone is curious and would like to see a practical demonstration of this data-oriented approach of modelling problems, I highly recommend this talk from Mark Bastian in Clojure/conj 2015: ▶ this video In it, he contrasts the data-oriented modelling approach with a traditional OOP approach for implementing a board game, and was able to come up with a complete implementation of the game with the former approach that was shorter than even the structural boilerplate for the OOP version. Another related talk that I loved was Chris Granger's 2013 talk on Light Table: link Where he walks through his process of building a game in ClojureScript using an Entity-Component-System architecture, which is very well suited to this data oriented modeling approach.

I see what you are trying to say. You are saying Clojure is not the right tool to do top-down design. I agree with it. It is however a very good tool to do bottom up design. See ▶ this video

I think, a "Data Driven Development" approach would make a lot of implementations easier. Something as described in this talk: ▶ this video

I personally prefer a more data-oriented approach to modeling, as opposed to modeling in terms of objects and relations. One of my favorite videos from Clojure Conj last year talks about the approach in more detail and contrasts it with traditional OO modeling in the context of a board game: ▶ this video In summary, modeling the board game with data (state) and pure functions (state transitions) had significant benefits over the alternative OO style model in terms of the overall simplicity of the model. The OO modeling approach resulted in a model that consisted of 22 classes, 11 interfaces, 1 enum, and 271 lines of boilerplate code just to implement the classes and relationships alone, with no game logic whatsoever. On the other hand, the data-oriented approach produced an entire working implementation of the game logic in 144 lines using 31 functions (small and highly composable functions, longest of which was 7 lines). My takeaway was that modeling in the traditional OO style can be a helpful process in getting a good feel for your problem domain at a high level, but trying to immediately translate the resulting relationship model into code is not necessarily a good idea, because the classical OO relationship model is inherently highly complected, and will bring that complexity straight into your codebase if you try to translate it word-for-word. Taking the insights from your relational model and using it as a guide to help model your problem domain as data and functions usuall

Thanks for the link. That made my day. =) Here's a more realistic comparison between classic Java OOP design vs the more data-oriented approach to design encouraged in functional languages like Clojure for a simple board game: ▶ this video TL;DW: The classic OOP design of the board game ended up with 22 classes, 11 interfaces, 1 enum in total, with 271 lines of pure skeleton code with no implementation of any game logic whatsoever. The class diagram can be seen here for a better sense of the complexity involved: ▶ this video The data-oriented design had 31 functions, longest of which is 7 lines, with a grand total of 144 lines of code that implements the entirety of the game logic.