Should we adopt Dave's way of building applications as a series of components? (Dave's talk has now been added!)

Chat / Discussions
, , ,
21

Loved it!!! :purple_heart:

Personally I prefer the word ‘application’ instead of ‘assembly’ but I can certainly live with Assembly as it adequately expresses the idea of what it is; the assembled Components (and Libraries).

I know I’ve said it before, but I think building apps as a series of components feels incredibly right, and when I look at the reaction of others (in Dave’s course thread as well as the various other threads discussing Dave’s ideas) I think could well be one of Elixir’s ‘killer’ features. It really does excite me that much and I genuinely believe many others, who like me, having been searching for a better way of developing applications, will feel the same.

I reckon that when word gets out that Elixir promotes and makes what is, in my mind, the Replaceable Component Architecture astonishingly easy, we’ll see the next wave of Elixir users in droves :003:

4 Likes
22

I wish this was talk 1 of a multi-part series (with many more parts available now). I want to see what Dave considers “right” demonstrated, over and over, with before and after examples. A few example apps showing the “new way”. And a mix task that I can use to play with this new idea.

I’m interested but a bit frustrated that a lot of well-intentioned bile was followed up with a couple slides that showed some code that might work in a GitHub repo somewhere. I didn’t see the links in the presentation. I don’t see them as part of the YouTube description or comments. I don’t know where to go from here. Feels like he ran out of time just as he was getting to the interesting bits.

3 Likes
23

His course is an excellent place to start imo :slight_smile:

I can’t wait for his next course :003:

4 Likes
24

I love this course. I need to revisit it. But if you’re going to try and change the world, these ideas can’t be behind a paywall. Or at least, can’t only or predominantly live behind a paywall.

It might be nice to for Dave to spin up a site for these ideas, using these ideas. Dog food the whole concept by coding, assembling, and deploying the site using this methodology. Then GitHub the whole thing. There will still be plenty of money to be made on additional hand holding (training/books).

7 Likes
25

Actually, the course doesn’t go into the stuff in the empex talk-that stuff is just experimental now.

I will be making videos and blog posts about these ideas once things settle down.

Dave

15 Likes
26

When is your next course going public?

3 Likes
27

I just went through your course and am now reading your book.

Your idea of writing small methods (like “cat” in UNIX) and having a clear separation of concerns between components (the way you organize the hangman game) really resonates with and excites me. Thanks for the awesome materials you put out. Can’t wait for more, especially on the topic of design best practice and code organization!

1 Like
28
  • +1 here :raising_hand_woman:
  • +1 :raising_hand_woman:

This sounds awesome already!

2 Likes
29

One of Joe Armstrongs reactions:

https://twitter.com/joeerl/status/1003237611400548352

Also … the big ideas in Erlang and elixir are processes messages and links -
not gen_servers, file structure, and dependency management- the distinguishing feature
of Erlang/elixir is the light-weight concurrency and error handling- all the rest is hype.

I much agree with that.

10 Likes
30

Joe’s reaction to me says how we organise our apps (using Erlang or Elixir) is more than amenable to changing with the times or personal tastes - because that was not the problem Erlang was trying to solve - the core underlying system (of highly concurrent, fault tolerant and distributed systems, i.e with messages/processes etc) was :slight_smile:

3 Likes
31

I think what @pragdave is doing is not an hype at all… He is just trying to bring order to the chaos that we see now in software development and unfortunately is not an issue of only Elixir, it spreads across all languages.

I really get is frustration with the current state of organising code because I felt exactly the same a while ago in my day to day, but I was also able to disrupt the way everybody follows and come with a nicer approach that my team as adopted and is already paying dividends in code maintenance, re-usability, on-boarding of juniors and less bugs.

So really looking forward for @pragdave approach to become mainstream :wink:

4 Likes
32

I don’t understand the need to differentiate applications with a process tree from those without. It should be completely opaque to the user of the application. It’s not an important or interesting distinction and only adds cognitive overhead to understanding what an application does.

8 Likes
33

I think we are on the right track with this thinking. Tool and die making made possible replaceable parts which made possible the assembly line. Why wouldn’t we follow the same pattern with software? Scaffolding can be thought of as tool and die making for components and components can be thought of as replaceable parts for software assemblies. Makes sense to me.

34

The problem resides exactly in using the term application as you are using it, because the pieces of code that @pragdave describes as library are intend to solve one exact single thing, thus treating them as applications is misleading and will lead inevitably to code that is not easy to change, because everything is tied up together in a big thing.

This is not about the Users of the application but about us Developers working on it or with it… so I don’t want it to be Opaque but rather very Explicit.

Software Architecture Matters

The current style of mixing a lot of concerns in 1 single file is a no go for a Clean Software Architecture that clearly violates the Single Responsibility Principle, that leads to code that is hard to change, thus hard to maintain and improve, not to mention that is prone to produce more bugs.

As it stands now having Client and Server logic mixed together makes hard to reason about the code. Having 1 single file with the unique responsibility of defining he API for the Component we want to use is a big plus for me. The same goes to define the Server and the business logic. I even say more, the business logic must be separated by their actions on the Resource they handle. So the logic to create should be in a separated file from the logic to update the resource.

So for me to be able to distinguish only by the folder architecture what is what without the need to jungle inside the code is a big win. If I need to fix a bug or implement a new feature will make my life much easier to know where I need to go to achieve it.

I see developers saying they love big files of code because:

  • they don’t like to have many files open in the editor.
  • is easier to debug them in production with VIM.
  • everything is in one place, even if that means thousands of lines in 1 file.

This is only some of the ones that I remember now from the top of my head.

Conlusion

Software that is developed with re-usability, easy of change and composition in mind are always a big win in the long term, but they require a huge effort and discipline to pay up-front, that normally no one wants to pay, because they are too much excited to see the thing working and to release it.

Is normal for companies to say is unacceptable to spent more time to come with a good software architecture, but they then are happy to accept that their developers spent countless hours to debug or implement new features that could otherwise take a fraction of the time in a Clean Software Architecture.

1 Like
35

Another example of poor naming.

What he actually meant:

Gather together those things that change for the same reason, and separate those things that change for different reasons.

… which ultimately is about cohesion.

The Single Responsibility Principle

SOLID Deconstruction

I don’t know - but am starting to suspect that the term application was chosen because it identified the unit of configuration within a deployed system (release).

6 Likes
36

There is a good discussion about the SRP here: Single Responsibility Principle - what does it mean to you and your Elixir apps? :slight_smile:

1 Like
37

I would argue that software should be developed with replaceability. If you think of Log4j, it was designed to be easily reused, but once it’s everywhere in your code replacing it becomes a nightmare. SLF4J, in contrast, was designed to facilitate replaceability.

4 Likes
38

Re: distinguishing between applications with and without process trees, someone at Empex brought up an example of a user agent parsing library they pulled in to their project, which actually started a bunch of processes that they did not expect it to.

39

That is why the use of Adapters are for… If you don’t want to couple your code to a third part code then you should create an Adapter that will sit between your code and the third part code, thus acting like a bridge between both.

This will allow you to decouple from the third part code and when you want to use other third part implementation only 1 place need to change, the Adapter.

2 Likes
40

So do you mind to give me a concrete example?

My Single Responsibility Principle Example

Lets’ say that I am working on an Ecommerce platform and writing the code for the Product resource.

To write this code I use what I call the Resource Action approach, where I will create a file of code for each action I want to perform.

Example of actions on the Product:

  • new
  • modify
  • discontinue

So for each of the above actions I will have at least:

  • Controller
  • Handler
  • Repository
  • Model
  • BusinessLogic
  • View

So the folder structure is like:

src
   Resource
       Product
           New
               NewProductController
               NewProductHandler
               NewProductRepository
               NewProductModel
               NewProductLogic
               NewProductView
           Modify
           Discontinue

This is a much more clean approach than the traditional one of sticking all that actions on the same file of code.

The end result is files of code that rarely go above 200 lines of code and that only have 1 public entry point.

With this approach the code is much easier to test, to change, reason about and less prone to bugs.

Another benefit is that if one new feature/action needs to be added to the Product resource is obvious for the developer that a new set of files need to be create only for that purpose… They will fill bad editing the existing files to add the new action :wink:

2 Likes