3 ms·
I think the key here, as a responsible developer, is ensuring isomorphism between the GUI representation and the generated code. To the extent that the developm
by ethbr0 5y ago
I think the key here, as a responsible developer, is ensuring isomorphism between the GUI representation and the generated code. To the extent that the development method could be swapped without repercussion.
Most GUI tools, presumably in speed to market, skip this. But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem.
So I'd approach this from a "If my tool is successful, and users use all the editors we give them, what will their support story for a 10 year old codebase look like?" (If you care about the greater good)
- nyellin 5y agoI like this. SaaS platforms typically don't want to do this precisely because it limits vendor lock-in, but I think it's the right approach.
- bmitc 5y ago> But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem. Why is that? You don't view the bytes your text editor generates do you?
- nopenopenopeno 5y agoYAML parsers don’t read the bytes or the GUI. They read the text.
- ethbr0 5y agoASCII and Unicode are standards. Presumably OP isn't building a tool with enough market share it's going to have an international standard encoding. What you end up with, if you don't have a standard, and you don't maintain isomorphism... is user "code" that requires a vendor tool to view & modify. Which sets up some really screwy incentives & business models. A thing you built. That you paid for the tools to build. That you have to continue paying for, otherwise you'll be unable to guarantee maintainability. Charge for execution if you want! But IMHO user developed code, in whatever format, deserves to be owned by users. Even if they decide to no longer be customers.
- bmitc 5y ago> ASCII and Unicode are standards. Right, and those didn't just materialize out of thin air. They took time and effort to develop. My point is that we shouldn't keep shooting down visual based tools and languages on the notion that there aren't standards, because there isn't anything (besides preconceived biases) that prevent them. There are many things that text is just not good at describing, such as dataflow, and by claiming everything must be text and isomorphic to text, we're holding things back.
- ethbr0 5y agoI'd be more sympathetic to this idea if I hadn't seen the tactic executed repeatedly over the last 10 years to ensure vendor lock-in, which ultimately burns the end user. And/or requires them to insecurely freeze a portion of their IT infrastructure in time. And honestly, if your GUI/designer is standardized, then it's trivial to define a stable serialization to and from text anyway.
- z3ncyberpunk 5y agoYou only need to sympathetic because you have let yourself become jaded by your anecdotal experience.
- ethbr0 5y agoIt didn't feel anecdotal when I was the one trying to modernize systems like these in the face of vendor apathy (or active hostility) and business resistance to change, because they had 10+ years of legacy "code" built in these things.
- z3ncyberpunk 5y agoSo every other software project for every business ever? Got it, still anecdotal data
- dv_dt 5y agoAh yes? and diff, track, and version the bytes with tools like git. Or perhaps I’m misunderstanding the question here?