Single Responsibility Principle - what does it mean to you and your Elixir apps?

[OvermindDL1]

@Deithrian

I just prefer “the_word_apple” and “the_adjective_red” vs “String a = ‘apple’”, “String b = ‘red’”

“the_word_apple” + 3. hmmm
the_word_apple = the_word_hamburger. hmmmm
put(the_word_apple, basket)

a+3. why not?
a = c. sure! What was “c” again?
g(a,n). Oh no! “g” was milk the cows, buy a newspaper, say the moon is red, 4356334, and “n” was launch the rockets, ? Dang it…
I’m exaggerating, but not by much.

None of that has anything whatsoever to do with type driven programming. ^.^

Type driven programming would be something like, oh if we were to emulate Phoenix’s :safe html renderer:

type safe = SafeHTML of string

let make_input_safe input =
  SafeHTML (escape_html input)

let raw input = SafeHTML raw

let render_html (SafeHTML html) = render_to_whatever html

Notice that I do define a wrapper type, it is documentation but otherwise no types are listed anywhere, not in the input arguments, no where else, it is all properly inferred. With the above you cannot even accidentally pass a non-safe chunk of html text to the renderer, you have to either mark is as raw or or escape the input. Also notice that the type drove the interface, not vice-versa.

Your examples are much more, hmm, Java-like, and Java is NOT a good language to do type-driven programming.

I’m not even sure what your example is demonstrating, do you have actual code to show?

And your things about the_word_apple and so forth seems very hungarian notation, but significantly more verbose, and verbosity can make code much harder to read as well.

Like say you have a unit of measurement, let’s say a meter:

let width_of_house = 12

Well that is not descriptive at all, we could do:

let meters_width_of_house = 12

That just makes it longer, and does not cause an error when we doing something like:

centimeters_is_expected_in_this_function meters_width_of_house

Wow that becomes unreadable very fast, and sure you may catch it with your eyes, but it is still easily missable. Compare this to a type driven approach to measurements:

type meter = Meter of float

let cm i = Meter (i /. 100.0)
let dm i = Meter (i /. 10.0)
let m i = Meter i
let km i = Meter (i *. 1000.0)

Or you could do something like:

type length =
| Meters of float
| Centimeters of float
| Kilometers of float
| Feet of float
...

let centimeters_of_length = function
| Meters m -> m
| Centimeters cm -> cm /. 100.0
| Kilometers km -> km *. 1000.0
| Feet f -> f *. 30.48
...

Or via Witnesses or a variety of other ways, whatever type style fits the pattern best. And you can keep names short, descriptive, readable, and never worry about the system compiling when you try to pass something to somewhere where it does not belong. ^.^

[Deithrian]

Yes, it will not cause an error to call “calc_in_centimeters(house_width_gallons)”
But why would you ever type it?

And is this Hungarian notation?

defmodule Main do
def handle_user_input(user_input_post) do
with
{:ok, user_input_post} ← Sanitize_user_input.escape_html_chars(user_input_post),
{:ok, user_input_post} ← Sanitize_user_input.step_2(user_input_post),
{:ok, user_input_post} ← Sanitize_user_input.step_3(user_input_post)
do
continue(user_input_post)
else
{:error, user_input_post} → game_over_man_game_over()
end
end

defmodule Sanitize_user_input do
def escape_html_chars(user_input_post){
}
def step_2(user_input_post){
}
def step_3(user_input_post){
}
end

[OvermindDL1]

@Deithrian

But why would you ever type it?

Because things happen, could be an accident, a macro, any number of other things.

@Deithrian

step_2
…
step_3

Uh, what was that about descriptive names? What do those even mean?! o.O
And what if you accidentally commented out, say, step_2, will step_3 break? Does step_3 even make sense then? Etc…

[Deithrian]

Step 2 and Step 3 are to illustrate the point for SRP, not actual names
And I don’t accept the provided answer for why would you ever type that

[OvermindDL1]

@Deithrian

Step 2 and Step 3 are to illustrate the point for SRP, not actual names

So what happens if they get, say, swapped? With proper types that becomes impossible:

let handle_user_input user_input_post =
  try
    let Some user_input_post = Sanitize_user_input.escape_html user_input_post in
    let Some user_input_post = Sanitize_user_input.step_2 user_input_post in
    let Some user_input_post = Sanitize_user_input.step_3 user_input_post in
    continue user_input_post
  with _ -> game_over_man_game_over ()

...
module Sanitize_user_input = struct
  let escape_html user_input = ...

  let step_2 (EscapedHtml user_input) = ...

  let step_3 (Step2Completed user_input) = ...
end

As an example, this now makes it that you cannot mix up the order either, at compile time instead of at some random time at runtime later.

@Deithrian

And I don’t accept the provided answer for why would you ever type that

Really? Have you not been programming long? o.O
Innumerable times have I done something like:

set_dimensions(height, width); // wrong swapped arguments!

And the arguments ended up being backwards or something trivial like that, hence why I started typing out about everything since my early C++ days, at least in the code I control. Among a whole host of other instances and styles.

[Deithrian]

Idk, some of the proposed scenarios sound like “what if my cat walked on the keyboard”
The swamped arguments case is also strange, because why would you call the function without being sure of the order of the arguments?
If I want to use a function I must go and check to see what it expects?
If a function has arity 1, 2 or 3, I must go and see what’s on offer?
When you “type”, I guess you can say “first argument is of type width”, “second is of type height” and get an error when you try to pass swamped arguments. But this means that to get swamped arguments, you must call the function without being sure what the arguments are. In one case you get an error, in the other you don’t, but in both cases you must call the function without being sure what it expects, and that’s something I don’t know how it happens.

Yes, I’m new, but for example, after not having used a basic “web component” for a while and need to import it and extend it, I go and check what it does, what it already offers, because I can’t be sure if I remember everything about everything?

I think that’s the main point for SRP, not to have magic, not to be able to put anything into a single function and have a result + 30 other things happening? At least that’s how I understand it.
Push complexity down and break it apart until it’s impossible to get it wrong.

[kylethebaker]

While I 100% agree with the general approaches you’ve outlined (small, modular components with limited scopes; descriptive variable names; self-documenting functions, etc.), I don’t think the conclusions you’ve drawn from them are tenable for non-trivial applications that are worked on by teams over some period of time.

Comments, tests (!!), types, and specs are all very important tools for dealing with complexity. These aren’t things that are pursued simply to adhere to some strict formalities of ‘good software’, but rather because they are effective ways of identifying, describing, and reasoning about the complexity and correctness of systems. Over the lifecycle of any given project you may have new features, new bugs (same difference), plenty of human error, shifting requirements, employee turnover, etc. The software and the people writing it will grow throughout the project’s lifetime and I think it’s important to treat this growing complexity as a first class citizen. Comments, tests, types, specs, etc. are all ways of acknowledging this. You have to recognize from the start that a project will be too complex for a single person (or multiple) to hold in their mind all at once, and respond by putting in place the appropriate safeguards and ‘crutches’ to accommodate for this.

@Deithrian

So when I read my code I go to the main file and look at the module names to recall what’s going on. Then it’s just a matter of following the module names and function names down the line to add or change stuff.

This only works when there is a well defined ‘main’ file, but often you will have multiple ‘main’ entry points, each to different parts of the system that are reached under different circumstances. You might also be dealing with code that was written by another member of your team, in which case there is nothing for you to recall since you have no memories of it. Good module and function names are tremendously helpful here for explaining the ‘how’, but they can’t adequately explain the ‘why’, and understanding the ‘why’ is crucial before you start making changes that are going to have an effect on the whole system.

@Deithrian

Why write a unit test for the + sign? It will add two numbers (in every respectable language) right?
…
Higher level functions only describe the steps taken to solve a problem, no work is done there. If there’s a problem, you can instantly tell where it is, because all the work is done in low level functions, and if it’s a logic problem, then it’s a logic problem, and it’s easy to spot because all low level functions must work, which they always should if done right. 1+1 should always work right?

The main purpose of writing tests is to avoid regressions and ensure that changes to one part of the system don’t unknowingly effect another. As systems grow it becomes increasingly more difficult to instantly tell where a problem is. Sometimes it’s even difficult to tell where a problem is a week later, when an an unrelated part of the system is suddenly crashing or returning incorrect results. Some regressions don’t reveal themselves instantly, nor do they reveal themselves in expected ways. “Why is the FooService crashing? We’ve only been working on BarService this week?”. Integration tests help alleviate this by acting as a kind of formal contract for the interactions that happen between different subsystems.

Even if you have a bunch of low level functions that perform simple tasks, these functions still have to be composed together at different layers. And the more compositions you have the more dependencies you create between different parts of the system. It may be easy to reason about how changing a function will effect a single specific composition, but what about the other 30? and what about the 15 or so higher layer constructs that those 30 functions compose into? and the 7 above that? You don’t get the higher layer functions risk free just because their lower layers are 1 + 1.

@Deithrian

In other words, I feel like “comments”, “unit tests”, “types”, “specs”, and so on, are the crutches of the lazy programmer, who didn’t break the top problem into small modules,didn’t write functions that describe the steps taken to solve the problem, didn’t write low level functions that are so simple it’s impossible to have an error,

Hey, what’s wrong with being lazy. I usually get called lazy for not writing these things. I guess it’s ‘damned if you do, damned if you don’t’ . I don’t agree with the implication that these these are used by less abled programmers in lieu of following good development principles (in fact, I think these things are a critical part of those principles), but on the other hand I say “what’s wrong with a crutch?”. Things get hard and complicated sometimes and being able to lean on these fundamentals enables you to deal more confidently with complexity. Though I would say these things are more like snow shoes than crutches, and building a complex system is like climbing a mountain. And code is like snow… (or something?).

@Deithrian

Anyway, I bet I’ll get some heat for this, but it’s ok I write my code, I love my code, I love, love, love, my code.

I’m throwing a little heat (), but in general I agree with the underlying principles you’ve outlined: small pieces are much easier to reason about; things should be grouped together logically by their purpose in the system; design things as layers of composable interfaces; descriptive naming is an absolute necessity. But in my experience no matter how good your names are, or how small your functions are, or how impeccably contextualized your boundaries are, complexity will rear its ugly head at some point and you have to be prepared to take it on. And I don’t think relying merely on your ability to write a bunch of aptly-named small things that are “impossible to have any errors” is sufficient when that complexity grows large. Sometimes neither are specs, comments, and tests, but they certainly make it more manageable than the alternative.

[Deithrian]

I strongly believe that complexity is created and is not there inherently.

SRP, for me, is like having bricks. With bricks, I feel I can build an infinite wall.
Other approaches feel like trying to build a wall with bricks, balloons, giraffes, wind, and good wishes.
In that case there’s definitely the need for support beams to hold the thing together.

It sounds idealistic, but in my limited experience with my personal project, it’s actually how things have been working.
The only time I got into trouble is when I decided to take the “easy/lazy” route and used innerHTML with a div instead of creating a brand new web component for the job.
In a system with bricks, one must stick with bricks, or one balloon and the whole thing goes down or support beams are needed, and with support beams people go crazy and star building with sound waves ; )
Btw, I must mention how much I love web components, it’s like processes and message passing in the browser <3
Anyway, I hope I don’t have to meet the mentioned monsters from the OO world and captain SRP with FP will win the day

[AstonJ]

@AstonJ

I’m not sure if this counts as part of the SRP, but apps being split into components could be closely related as well.

A little later in the course Dave confirms this:

A thread that runs through this course is the idea of designing for decoupling using the Single Responsibility Principle. As we’ve seen, this applies equally to individual functions, to complete modules, and to entire applications.

[gregvaughn]

@Deithrian

I strongly believe that complexity is created and is not there inherently.

Yet Fred Brooks pointed out in The Mythical Man-Month (in the 1970’s) how there’s both inherent and accidental complexity. We should avoid accidental complexity, sure, but there are problem domains with inherent complexity too. I suspect you haven’t encountered them yet.

[kylethebaker]

@Deithrian

I strongly believe that complexity is created and is not there inherently.

I think it’s certainly possible to create complexity where there is none, and distilling a complex set of requirements into non-complex code is the “name of the game” for us as developers, but the complexity present in networks of interconnected systems is more of a natural phenomena than it is a side-effect. It’s not about whether or not it’s avoidable or exists, but how it can be minimized and managed effectively.

I will use WebComponents as a example, but from a different angle. Take a look at the specs browsers are required to implement for web components:

Template Element
Custom Element
Shadow Trees
Shadow DOM
HTML Imports
CSS Scoping

Now imagine something like firefox, which is almost 18 million lines of code that have been worked on by over 5000 contributors. These are features that touch on several of the fundamental subsystems of the browser: the dom, rendering engine, and javascript engine. These are features that have over a decade of active code that is being relied on by millions of users. Even in the most ideal of systems where SRP is strictly adhered to and state is managed following the principles of FP, you will have unavoidable complexity.

I personally agree that the principles behind SRP and FP are great ways to minimize this, but I don’t think they replace good test coverage, formal specifications, and descriptive comments.

Web components are sweet though. I wish I could write erlang/elixir in the browser. Being able to represent a web component as GenServer would be amazing.

[AstonJ]

@peerreynders

I think it may have more to do with where you are (in reference to understanding the intent of SRP - as it seems to be a new concept for you). If you go by the Dreyfus model of skill acquisition a “novice” will tend towards “rigid adherence to taught rules or plans” - but in design/architecture things are rarely black and white - everything is about making tradeoffs. So the real “mental overhead” comes from the fact that there are numerous design guidelines that have to be balanced to meet the requirements for a particular situation - some will be met while others will be deliberately violated to gain some highly valued benefit.

I think you are spot on… and another great talk! You must have a good memory! Think I am going to call you the TalkMaster from now on