Bra podcast
Sveriges mest populära poddar
Each week, we discuss a different topic about Clojure and functional programming.
If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to [email protected], or join the #clojuredesign-podcast channel on the Clojurians Slack.
This week, the topic is: "playing games with data." We go back to start and play through a composition strategy to see where we land.
Our discussion includes:
- The return of Tic Tac Toe. It's back!
- The biggest difference between object-oriented and functional composition.
- Can a game board play its own pieces? Isn't that the stuff of horror films?
- What does it mean to be "complected"?
- What's more important: data or behavior?
- Why separate data from behavior?
- The simple domain of batch processing.
- The dark magic of hidden side effects.
- What lasts longer: data or your application?
- Representation vs operations in an information domain.
- Common kinds of functions.
- How do schemas fit in?
- Where does I/O fit in?
- Rationale for organizing your namespaces.
- The horror of code organization in Java.
- The stability of pure information models.
- What is language imposed complexity?
Selected quotes:
- "It's been a few years for us, but it could have been a few days if you're really on a binge on this podcast!"
- "The biggest and most important difference between object-oriented programming and functional programming is the relationship between data and behavior. Functional programming keeps those separate, whereas object-oriented programming likes to mix them together into classes."
- "When I want to play a piece, does the board know how to play pieces onto itself? Or, does a piece know how to place itself on the board?"
- "You can't just have the functionality sit on its own. It has to be attached."
- "I arrived at a point where I thought, 'What am I doing?!'"
- "All kinds of different scripts that operate on the same data file don't need to know about each other at all."
- "I'm just going to get the name attribute from the Person object, right? You don't know. Am I getting a field, or am I getting some magical overloaded getter thingy that does a bunch of side effects?"
- "Data is simple, and data will almost certainly outlast your application. Often, the data that your application deals with came from somewhere else in the first place."
- "This reminds me of the fun abomination known as object-relational mapping where you take the data that was there before your program and you pour it somehow into your objects, then you do something with it, and then you pour it back out into the database. Why is this such a hard problem? Because it's a hard thing to do! It's something that doesn't make sense."
- "In OO, there are way more dimensions of potential organization, so therefore, more things for a software development team to fight over."
- "The only place you can put functionality in object-oriented language is attaching it to classes."
- "In Clojure, you don't have a lot to fight over in your bike shedding sessions."
- "When you're talking about which object to put it in, you're not actually talking about your problem. It's a problem that is introduced by the tool choice, not by the domain of the problem."
- "Because they're separated, you get reuse. You get data composition and behavioral composition as separate kinds of composition--because they don't often happen the same way."
"I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
If you have referentially transparent code, if you have pure functions all the data comes in its input arguments and everything goes out and leave no state behind it’s incredibly reusable."
~ Joe Armstrong in "Coders at Work"
Links:
Kategorier
Förekommer på
00:00
-00:00