Ah yes this is 100% fair and valid. I think to maintain the advantages of text I'm a big fan of visualizations that derive from the code, like in the case of JSX Lite and Build so you can keep using all your code tooling and workflows and visualization is purely optional.
But also agree that some things are not as inherently visual like game and frontend dev. That said I've seen some interesting stuff around for visualizing data flow in code, which brings me back to the idea of (optional) visualizations on top of (text based) code, which can have multiple formats too (eg visualize and edit the same code as a data graph, text based, maybe even block based, based on what type of editing or debugging you are doing)
Well I don't have a crystal ball, so I don't know exactly what the future is going to look like, but I think it's safe to assume that things will be really different in let's say 10 years from now - I can't imagine that we'll still be doing things the same way, writing tons of code for mundane stuff like user onboarding and so on.
Probably somehow the abstraction level and the 'automation level' will be much higher. I wouldn't be surprised if we'd be coding in a very high level pseudo-code language, and/or with abstract diagrams - and these two would then be just two representations of the same "model" (round-trip engineering).
Yes, I feel that that might very well be our future - we'll just design a "model" and voila we'll have our app or your system - all of the low level details will be managed by some sort of runtime. And maybe AI will be thrown in the mix.
So, to a large extent this actually sounds a lot like what your post was suggesting? :-)
Ah yes absolutely. Also worth noting there are ways to do this without additional artifacts generated that could go out of sync too. Eg in the case of JSX Lite and Build they parse the (javascript) source file to an AST, store and modify that in memory only when editing visually, and changes are applied back to the source code without anything else generated or saved
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ah yes this is 100% fair and valid. I think to maintain the advantages of text I'm a big fan of visualizations that derive from the code, like in the case of JSX Lite and Build so you can keep using all your code tooling and workflows and visualization is purely optional.
But also agree that some things are not as inherently visual like game and frontend dev. That said I've seen some interesting stuff around for visualizing data flow in code, which brings me back to the idea of (optional) visualizations on top of (text based) code, which can have multiple formats too (eg visualize and edit the same code as a data graph, text based, maybe even block based, based on what type of editing or debugging you are doing)
Right, I see what you mean - I'd call that round-trip engineering:
en.wikipedia.org/wiki/Round-trip_e...
Well I don't have a crystal ball, so I don't know exactly what the future is going to look like, but I think it's safe to assume that things will be really different in let's say 10 years from now - I can't imagine that we'll still be doing things the same way, writing tons of code for mundane stuff like user onboarding and so on.
Probably somehow the abstraction level and the 'automation level' will be much higher. I wouldn't be surprised if we'd be coding in a very high level pseudo-code language, and/or with abstract diagrams - and these two would then be just two representations of the same "model" (round-trip engineering).
Yes, I feel that that might very well be our future - we'll just design a "model" and voila we'll have our app or your system - all of the low level details will be managed by some sort of runtime. And maybe AI will be thrown in the mix.
So, to a large extent this actually sounds a lot like what your post was suggesting? :-)
Ah yes absolutely. Also worth noting there are ways to do this without additional artifacts generated that could go out of sync too. Eg in the case of JSX Lite and Build they parse the (javascript) source file to an AST, store and modify that in memory only when editing visually, and changes are applied back to the source code without anything else generated or saved