3 ms·
But, this is just leaky abstractions to the max. You replaced a python code base with adding a layer of YAML on top of it, but then still requiring you to write
by tnolet 1y ago
But, this is just leaky abstractions to the max. You replaced a python code base with adding a layer of YAML on top of it, but then still requiring you to write Python?
My IDE will have a stroke parsing this.
- maxgrinev 1y agoYou're right about the abstraction concern. The vast majority of the workflow stays in structured YAML - Python is only needed for two specific points: constructing HTTP request bodies and parsing JSON responses. These are inherently dynamic operations that need real programming logic. The alternatives - proprietary DSLs or visual builders - would be far more complex to learn and maintain than a few lines of Python/JavaScript for JSON manipulation. We actually started with JavaScript since it's more natural for JSON work, but the difference was marginal. Do you have suggestions for a better approach to these two specific dynamic parts? We're open to ideas that would be simpler than Python but still handle the complexity generically.
- zarathustreal 1y agoI think you’re misunderstanding. This product doesn’t make sense because the problem itself is not solvable under your given constraints.
- pan69 1y agoJust asking. Which problem? Which constraints?
- tnolet 1y ago> The alternatives - proprietary DSLs or visual builders - would be far more complex to learn and maintain that's where I disagree. Your YAML DSL is far harder to learn and maintain. My code can be tested, iterated, understood by my IDE etc. It's just code.