Design tradeoffs and guiding principles #648
DaveSkender
announced in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
One of the toughest challenges in designing a system is to properly balance needs for:
I occasionally get questions, good suggestions, or thoughtful opinions from the community about design choices for this library. All feedback is appreciated and helpful. This is an open discussion for generalized design decisions and rationale.
Guiding principles
Here are a few concepts that I've tried to stick to throughout the implementation of this library.
Make it easy to use: if you've ever tried to use old technical analysis libraries you've probably shared in my frustration regarding how much added work is required to interface with it. We aim to do better.
Be unopinionated: this means implementing indicators from reputable authors with no alterations to the original recipe. If you've been on the various online charting platforms, you've probably seen some variations and wondered what they did to make it different. We source our recipes carefully, avoid the use of alternate interpretations, and never use someone else’s code as a source of truth.
Single-responsibility: this library consumes historical quote history and configuration parameters, then produces indicator results. Nothing more. We will never extend it to add trade signal generators, strategy and backtest engines, data provider interfaces, etc.
Accommodate all instruments: we intend to support all the unique financial market price data for equities, commodities, forex, cryptocurrencies, and others in standard OHLCV format. For crypto, in particular, this means supporting fractional volume and unusually large/small price data (e.g. the Satoshi unit). Decimalized precision is important in financial data.
Avoid gold-plating and extraneous features. Simplicity is the best design decision. Just because you can add a capability or low-quality indicators, or if other platforms do something, does not mean it should be done.
Performance is important and we always seek opportunities to make the library faster, but not at a high cost to the other guiding principles. The library is already quite fast.
Encapsulate it so the library does not access external systems and does not depend on any other third-party packages or data providers, ever. Only the caller puts and gets data in and out of this library. This makes it more secure, portable, and reliable.
Make it open-source to ensure longevity and to encourage community contributions to 1) keep it up-to-date with modern compatibility, and 2) add new reputable indicators as they rise in popularity. Unmaintained libraries becoming unusable.
Do all the things needed to deliver professional quality packages that can be trusted by everyone:
Related discussions
Beta Was this translation helpful? Give feedback.
All reactions