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
Because things happen, could be an accident, a macro, any number of other things.
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…
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.
Really? Have you not been programming long? o.O
Innumerable times have I done something like:
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.
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.
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.
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.
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.
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?).
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.
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
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.
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.
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:
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.
), 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.
