This philosophy is not specific to Julia, but favors Julia due to its high-level nature, ease of generic, etc… I want to compare them to popular development philosophies. Thanks.
Code is either an end-user application or (part of) a library.
This separates code into two neat categories.
Each functionality should be owned by one person (can be advised and ownership/maintainer can change, and the functionality can be forked into several variants, but each should be maintained by ONLY ONE PERSON.
This also means the project manager needs to assemble the final application together.
While this sounds like a strange philosophy, it is based on a simple observation. Imagine you ask someone to print hello world. “Please print hello world for me.” Well, you could’ve more simply done it yourself
Of course, this was a “simple” function, but inside, it actually had to call lots of IO and so on. This illustrates the principle well, with the right abstraction/tool, you could more easily do whatever you want to yourself. The help others provide is simply providing a layer of abstraction. If you specify what you want to build specific enough, you could have written your code. Therefore, you can communicate through programming abstraction lots of programmers spent decades perfecting?
- Library API should be documented.
So they’re usable. The response to “please print hello world for me” could be like “print(x) takes x that can be converted to string and prints it out to studio”
- A library should be as generic as plausible
So they can be re-used more, and more reasoning below.
- Respond to uncertain requirement and defer knowing requirement with generic code.
Maybe your customer changes the specifications all the time. Unlike other philosophies that might do some quick prototyping and so on, this philosophy says that ideally, the code should be generic enough that even crazy-sounding specification change is only a few line of code change in the final application code.
- Shorten/simplify end-user application code.
Move functionalities to generic library when possible. This helps code re-use. End application can’t be re-used.
So, in summary, this practice divides the code into documented, generic libraries and short end-user applications that takes only 1 person to produce. Complex projects can be made into short code that divides task into functionalities that themselves can be subdivided.
What do you think about this approach? Compare this to scrum methodology or whatever.