Zen #129
Replies: 14 comments
-
Pass onPass on the data that you take, not only result, so the user of your component can reuse that value without hustle with connections. Exception for this rule is |
Beta Was this translation helpful? Give feedback.
-
Strive for strong invariantLet's design a structure that represent two possible states: message is full and user should read it and message is empty and user should not do so: Bad
It's bad because it's possible to have Also bad
It's possible to have Good
There's just 2 possible states: Sometimes it's impossible to create structures with unbreakable invariant but it's also possible to find structure with the minimum invalid states. The lesser possible states you have the stronger invariant you get. The goal is to make compiler do as much work as possible so the user of your API can think about more important things |
Beta Was this translation helpful? Give feedback.
-
To batch or not to batchwhen to use structures instead or separate (out?)ports TODO |
Beta Was this translation helpful? Give feedback.
-
Relax the requirements, enrich the outputDon't be specific at what you accept, but be specific at what you give. The special case for that is a TODO think about "return" types examples (and about whether it's a really good rule of thumb) as an inspiration see Go's "take interfaces, return structs" |
Beta Was this translation helpful? Give feedback.
-
Avoid if-elseThat stuff looks scary in FBP TODO |
Beta Was this translation helpful? Give feedback.
-
Prefer multiple nodes to not portsDesign the component's API in a way that it should be used on a single "pulse" of data instead of adding an array port in order to allow componentn operate on multiple "pulses" (Not sure about this one. Array ports actually could be more general-universal. And what about sub-streams?) |
Beta Was this translation helpful? Give feedback.
-
Avoid duplicating context in naming
TODO create separate |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Simple API First
Designing the API make sure you cover the most popular use-cases by the simplest API. E.g. having Simple API here probably also means "less parameters". It's always important of course to remember that API could easily be too simple and bad because of that. Because it doesn't cover important cases |
Beta Was this translation helpful? Give feedback.
-
Left a backdoorhttps://youtu.be/xcZ5yq_gG-4?t=777 This is a story about Haskell and Clojure. Haskell's HTTP library that wraps C's curl wasn't complete by wrapping everything. So instead of leaving a backdoor to bypass types and just pass strings author of a library just expose a limited API. That lead to a developers just cmd For a language like Nevaland that wraps Go this could also be an important thing. Even though Go's stdlib is more or less well typed. And the thing with Nevaland could be more about "How do I wrap this?" instead of "How do I wrap everything I could and somehow expose everything else"? It's not clear how to actually expose stuff in a backdoor way cuz paradigms are way too different. Anyway if that's possible for Haskell or Clojure that must be somehow possible for Nevaland. This could be a part of a more general "be practical first" approach. Like the science and architecture and clean code and patterns and style and stuff are all cool but those are just instruments to make things work (and maintainable, yes). But those are just instruments. The goal they serve is to make language practical. |
Beta Was this translation helpful? Give feedback.
-
Principle of Least Astonishment
(This one is not created by me and is just common sense from the internet. Not sure if, thus, must be included) |
Beta Was this translation helpful? Give feedback.
-
Rule of 7https://publish.obsidian.md/programmingsimplicity/2023-04-03-Rule-of-7 No node in a layer has more than 7±2 items in it. |
Beta Was this translation helpful? Give feedback.
-
Prefer custom errors to multiple outportsHave one |
Beta Was this translation helpful? Give feedback.
-
Multiple instances is better than spaghettiGood code is the code that is easy to understand by looking at it. If your code looks complicated as a visual schema then it can be improved. One of the possible ways to improve it is to make use of several instances of the same component. Even thought you can actually use one. General rule is that the more connections coming from different places you have that are point to single inport, the more spaghetti-like your component looks. Example is "a+b" program - it could use only one (Also could be better for mock configuration?) TODO "won't exit because printlns won't exit" this is a problem |
Beta Was this translation helpful? Give feedback.
-
This discussion is a heap for everything "conceptual" or "philosophical" about the Nevalang. Everything that feels like a "go proverbs" or "zen of python" must go here. Perhaps later we will structure these thoughts better. This is the place for both the language itself philosophy and heuristics that language users should use.
Beta Was this translation helpful? Give feedback.
All reactions