4 ms·

> what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytim

> what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? The only mindset required to avoid long-term bugs and maintenance problems is a personal conscientiousness, a personal approach to defensive programming based on (ideally, extensive) personal experience, which will inevitably include a very-hard-earned skillset of decoupling. Everything else is trivial (borderline bike-shedding) in comparison. Static types, OO, functional programming, agile, TDD, etc, etc -- these will not save you from your own personal deficiencies. Only long, hard practice will. A skilled practitioner can build a large, complex system in Visual Basic or PHP using entirely OO idioms. Now he or she may do a somewhat quicker (and happier) job if he or she is able to employ some convenient tools of the trade (eg syntactic niceties, functional-orientation, immutable libs, testing libs, etc etc etc). But the quality and manageability of the system is entirely a function of experience-based skillsets that far transcend the particulars of the programming paradigms that we currently have available to us. I've seen many a strong static typer, who thinks they have found God, make an absolute mess of everything including its leverage of the type system over time. I've seen many a developer write OO code within a functional language and vice versa and the success or failure in these cases is irregardless of even the slight misapplication of the tool in hand. Can you articulate a real world problem into a sound domain model? Can you decouple the behaviors of your system into composable parts? Are you conscientious enough to informally "prove" the transformations (ie git commits) you make to your software system? If you can do these things, you avoid a mess of a system regardless of your PL and programming paradigms. If you cannot do these things then no matter what kind of process you bring to the table, you will not be saved.

demilicious 8y ago
This makes a whole lot of sense to me. However, one of the elements of truly productive learning is _focused_ practice; that is, practice with mindfulness and intentionality directed at a specific element. One won't necessarily get any better at decoupling unless it is specifically practiced. To that end, _how_ would one truly practice the skill of decoupling? Or maybe, what resources or heuristics or strategies would you suggest to help draw the lines between behaviours or modules? The first thing that comes to mind is Gary Bernhardt's talk on Boundaries, or "functional core, imperative shell", but I'm not sure that this is entirely what you're discussing here.
- wellpast 8y ago
  I think you're hitting the nail on the head. It is specific and focused practice. I've been thinking about working on a book or set of blog posts or something to try to flesh out what a regimen would look like. Most writing on software of course is technical (on PLs, algorithms, processes) but there seems to be very little to guide the software practitioner who really wants to seek mastery. > what resources or heuristics or strategies would you suggest to help draw the lines between behaviours or modules? The best I can come up with for teaching this would be to create some concrete "problems"/scenarios that would exercise the skill set, and then reveal various ways the problem could be decomposed and quantify the degree of decoupling and even reveal the practical consequence of the coupling by introducing new "requirements"/dimensions to the scenario.

demilicious 8y ago

This makes a whole lot of sense to me. However, one of the elements of truly productive learning is _focused_ practice; that is, practice with mindfulness and intentionality directed at a specific element. One won't necessarily get any better at decoupling unless it is specifically practiced. To that end, _how_ would one truly practice the skill of decoupling? Or maybe, what resources or heuristics or strategies would you suggest to help draw the lines between behaviours or modules? The first thing that comes to mind is Gary Bernhardt's talk on Boundaries, or "functional core, imperative shell", but I'm not sure that this is entirely what you're discussing here.

wellpast 8y ago
I think you're hitting the nail on the head. It is specific and focused practice. I've been thinking about working on a book or set of blog posts or something to try to flesh out what a regimen would look like. Most writing on software of course is technical (on PLs, algorithms, processes) but there seems to be very little to guide the software practitioner who really wants to seek mastery. > what resources or heuristics or strategies would you suggest to help draw the lines between behaviours or modules? The best I can come up with for teaching this would be to create some concrete "problems"/scenarios that would exercise the skill set, and then reveal various ways the problem could be decomposed and quantify the degree of decoupling and even reveal the practical consequence of the coupling by introducing new "requirements"/dimensions to the scenario.