On 28/07/16 13:47, roger peppe wrote: > I agree with that. But we're talking about sugar here, I think. Added > sugar doesn't *necessarily* imply a cleaner, less messy or better > articulated component IMHO. That's one of the reasons I like Go - more > layers of abstraction can make things harder to reason about, although > equally they can sometimes really help.
We're not talking about sugar. Look at your example - it got *shorter* when hand crafted. That's *less* fluff. We all value different things individually, and I respect the things that you in particular value. However, we can also make concrete observations about the behavior of humans at scale. And we know that developers respond really well to clear documentation, clear and interesting demos, and elegant APIs in the language of that choice. You're saying we could save a small amount of time by writing code, I say that we pay that small price at the time and then your audience - the developers - benefits every time they look at your work. As a team, we can both value your values, and set a goal to shoot for what we know works with the developers who are our audience. I don't ask the Juju core team to maintain charms or visit customers to work on charms. Your audience is developers who will integrate, and I do expect us as a team to be mindful of that and set a very high bar. Auto-generated code has been the same clever idea since the 1980s and it has always produced the same result - a brief high matched with ultimate frustration and distaste. > In this world of limited development time, all else being equal, I > tend to prefer "no code at all" over a "bounded amount of code", > because all code implies potential bugs and ongoing maintenance > cost. Is that being too much of a lazy programmer? Quite possibly. > Where to draw the line between pragmatism and perfection is > something that's always on my mind, something that we're > all exploring all the time. That's good. As a team, however, on this codebase, we have a commitment to a particular approach. That way, it doesn't feel like a hodge-podge of explorations. Katherine, thanks for opening the subject. We are agreed that schema-based internal validation of messages and calls, on both the client and the server, offer long-term value and we should do them, with an initial approach that is cheap and also relatively effective. Our bindings, however, will be handcrafted, and we will critique them for taste. I suggest we designate people to act as leads for the different languages we target (Go, Python, JS) with the goal of having those folks lead consistency (but each committer is responsible for updating the all bindings of the APIs they touch). Mark -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
