u/eccentric_jin r/Clojure • Recommends
What are the cons of Bottom Up\Data Driven Design?
0:00 / 0:00
Bottom Up vs Top Down Design in Clojure - Mark Bastian
ClojureTV
111K subscribers • 158 videos on Hallway
- Recommended by 8 people: 5 on Hacker News, 1 on Lobsters, 1 in engineering communities and 1 curated list.
- A classic. People kept recommending it from 2016 to 2021.
- Presented by Mark Bastian
- An opinion. It argues one side of a question engineers disagree on.
Intermediate. Assumes working knowledge.
29K views10 years ago8 recommendations
Software designProgramming languagesFunctional programmingDesign patternsSoftware architecture
Mark Bastian contrasts top-down object-oriented design with bottom-up, data-oriented design in Clojure by modeling a board game.
The standard approach to developing a program or API in Object Oriented Programming is to take a "Top Down" approach in which the modeler starts with the domain at large and decomposes this domain into smaller pieces, generally in the form of classes. This often results in complex, interconnected type hierarchies. In Clojure, the standard approach is to design "Bottom Up," in which the developer first models an actual domain instance using Clojure data structures and then writes simple functions for manipulating the domain data. These functions can then be recombined and composed into more powerful functions. Ultimately, a program emerges. This approach has several advantages including: 1) bottom up functions have more reuse, 2) bottom up design allows for immediate domain modeling using actual data, 3) it is easier to reason about what is going on in bottom up design. This talk will first describe the two approaches, then it will walk through the development of a program using bottom up design in Clojure, culminating in a live demonstration of the program. Attendees will gain an appreciation for this technique and see it in action. In particular, they will see how Clojure is especially well suited to this approach. About the speaker: Mark Bastian has been developing applications in the Java ecosystem for over 10 years. He started doing Scala and Functional Programming over 5 years ago and has been programming in Clojure personally and professionally for over a year. He is a programming languages and paradigms enthusiast and loves finding and evangelizing the best practices from all the languages and paradigms he encounters. In his spare time he blogs about Clojure and Functional Programming at fn-code.blogspot.com.Why it's here
8 people recommend thisWhat people say. Highly recommended for its clear contrast between traditional OOP class hierarchies and functional, data-oriented modeling.
Moments people linked to
lewisl9029on Hacker News • Recommends
On “A Database Model for Simple Board Games”
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: link to 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 g…
lewisl9029on Hacker News • Recommends
On “How I Learned to Stop Worrying and Love the State Machine”
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: link to 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 o…
bederson Hacker News • Recommends
On “Show HN: Tetris Implemented in ClojureScript”
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. link to this video
robtoon Hacker News • Recommends
On “Making a Lego Domino Machine [video]”
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 link to this video
programming-talkscurated list on GitHubRecommends
Under “Clojure”
Bottom Up vs Top Down Design in Clojure 00:36:41 by **Mark Bastian** (2015)
lewisl9029on Hacker News • Recommends
On “Ask HN: Why don't more web projects start with a JVM stack?”
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: link to 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: link to 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.
cygnedon Hacker News • Recommends
On “Modern Software Over-Engineering Mistakes”
I think, a "Data Driven Development" approach would make a lot of implementations easier. Something as described in this talk: link to this video
abc_lisperon Hacker News • Recommends
On “Making the move from Scala to Go”
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 link to this video
u/MalloZupin r/Clojure • Mentions
What have you watched this month/week in clojure?
Just a thread about useful videos:
I personally enjoyed this talk: [video
u/kontravariantin r/Clojure • Mentions
On “I'm looking for a YouTube video of a talk about making a board game with Clojure”
1. Bottom Up vs Top Down Design in Clojure - Mark Bastian [video Shows how to represent a card game entirely as data structures in clojure and how easy it is to map these to a GUI implementation
2. Solving problems the clojure way - Rafal Dittwald - [video Simple card game modelled with datastructures. Initial implementation in traditional javascript way and then porting to data oriented programming principles the way it would be implemented in clojure.
u/jaen-ni-rinin r/Clojure • Mentions
On “New Clojurians: Ask Anything”
…h one (or more) parameters fixed to certain values,
* you can use the `->` macro family as a readable alternative to `comp` of `partial`s, because that's what it basically does (just by syntactical rearrangement instead of function calls).
This very recent video from Clojure conj illustrates this dichotomy quite nicely on a board game example - link to this video…
u/jschmin r/Clojure • Mentions
On “Are "world-state" parameters a code smell in Clojure?”
I don't think there is anything wrong with this. These functions are what Marc Bastian refers to as "top-level functions" in his recent talk on Bottom up vs. top down design in Clojure. It's a great talk and I highly recommend watching it all the way through.
As for testing, it might make sense to use a generative testing tool such as test.check to help you cover a larger portion of the state space.
u/klujerin r/Clojure • Mentions
On “How do you deal with state? Is it best to just keep passing to and receiving from all functions?”
This gives a practical example in a similar style
Bottom Up vs Top Down Design in Clojure - Mark Bastian
u/brad_radberryin r/Clojure • Mentions
On “How to convert code from imperative to functional?”
This is an older one, but it's the one that really helped it click for me:
Bottom Up vs Top Down Design in Clojure - Mark Bastian
It's spiritually similar to Rafal's work, but less well developed. But also, just a 30 minute video.