Zen is all related to the nature of this world which would be used as to the essence of something. Python and every other programming language have been beneficial by people quotes over what they prepare for users. Coding needs to be understood by algorithmic thinking, moreover, each of the languages has its details every developer must know well to get used to it and also create the best out of it. Tim Peters wrote this scenario as the Zen of Python. The list below shows his ideas about using python as well as what it is:
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
- Flat is better than nested.
- Sparse is better than dense.
- Readability counts.
- Special cases are not special enough to break the rules.
- Although practicality beats purity.
- Errors should never pass silently.
- Unless explicitly silenced.
- In the face of ambiguity, refuse the temptation to guess.
- There should be one– and preferably only one –obvious way to do it.
- Although that way may not be obvious at first unless you are Dutch.
- Now is better than never.
- Although never is often better than *right* now.
- If the implementation is hard to explain, it is a bad idea.
- If the implementation is easy to explain, it may be a good idea.
- Namespaces are one honking great idea – let’s do more of those!
Zen of Grasshopper
I am going to set some rules as the nature of Grasshopper from almost 11 years working according to what Tim Peters has said. I am trying to include these experiences I had within the coding ambiance and also to have you more precise about what you are heading to if you are getting serious to learn to code. These series of explanatory items might be simple for anyone who knows Grasshopper well but, these are key frames for me as a concept while I work with Grasshopper.
- Write down your algorithm on a piece of paper conceptually
- Get to know data structure and List by training them non-stop
- Upgrade your knowledge about any add-ons before using them
- Ask Grasshopper anything you need by searching in the middle of the canvas
- Use bubbles as grouping each set of components and note on every part on the canvas
- Use gates from “Set” for decision-making procedures to have your algorithm smart enough to reduce errors
- Try to write everything down well-composed as a machine which does what you want
- Try to learn simplifying definitions by training and correcting your algorithms even if they work well
- Grasshopper is not just a generative modeler, at least not anymore. use it interdisciplinary. Where parameters from different factors meet!
- Optimization with algorithmic thinking should be an aim to have parameters connections well-fitted
Any ideas to fulfill the list above? I totally am sure you would have, you can comment below and share as a List to have using Gh better by a cumulative experience altogether.