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

in “Making a Lego Domino Machine [video]” · View on HN

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

in “Show HN: Tetris Implemented in ClojureScript” · View on HN

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.

in “How I Learned to Stop Worrying and Love the State Machine” · View on HN

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

in “A Database Model for Simple Board Games” · View on HN

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

in “Making the move from Scala to Go” · View on HN

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

in “Modern Software Over-Engineering Mistakes” · View on HN