
Visual Logic Authoring vs. Code - gk1
http://blog.dominodatalab.com/visual-tools-vs-code/
======
gshrikant
The tone of the article sounds preemptively dismissive of the visual
programming paradigm itself using deficiencies of its implementations. This is
like saying OOP is deficient because a language implements it in a bad way. As
with text-based programming, visual tooling varies in quality.

Several existing visual tools address the issues the author raises (diff
support, searching, modularity etc.). Further, saying that visual tools are
not Googleable or have enough following on StackOverflow is a Catch-22
situation. It won't improve until people start using and improving the
tooling.

The same applies for other points the author makes. For example, I would argue
the lack of open-source visual programming tools is more due to the lack of
adoption stemming from FUD than it is from lack of interest in the paradigm
itself.

Generalizing what is essentially the state of infrastructure to an entire
paradigm (visual logic authoring) doesn't convey the full picture.

~~~
snowwindwaves
can you provide some links for visual diffing tools? 90% of the programs I
write are PLC programs in the IEC 61131 function block language. I would love
to be able to diff and merge.

PLC processors have come down so much in cost we have gone to a modular
architecture where we have multiple CPUs in a plant each running an
independent machine or part of the plant process partly so that one programmer
can work on the program for 1 CPU without having to merge another programmer's
changes.

I thought this could be useful if I could use the PLC programming software
(Schneider Unity) to export PDFs of the function block diagrams:
[http://www.evilmadscientist.com/2011/improving-open-
source-h...](http://www.evilmadscientist.com/2011/improving-open-source-
hardware-visual-diffs/)

I thought I might be able to get this open source PLC programming software
which includes a function block renderer to read the unity XML program exports
and then I could render the function block sections myself and diff them:
[http://www.beremiz.org/doc](http://www.beremiz.org/doc)

Here is the only real product I've ever seen which has a module for matlab
simulink diffing: [https://www.diffplug.com/](https://www.diffplug.com/)

Schneider does have the UnityDiff tool which has come a long way in the last
couple years and it does pretty decent diffs but there is no way to generate
them automatically that I know of. I have to open both versions of the program
I want to diff and then run the diffing tool. Then the visual diff output
can't be exported out of the unitydiff program. printing doesn't work. I
should make some feature requests.

~~~
Serow225
Simulink comes with a built-in diffing tool as of the last few releases.

For 61131, check out this work, sounds promising... You'd just need to figure
out how to download the LogixDiff tool that they developed (maybe contact the
authors?)
[https://dspace.cvut.cz/bitstream/handle/10467/24493/F3-BP-20...](https://dspace.cvut.cz/bitstream/handle/10467/24493/F3-BP-2014-Nedved-
Miroslav-prace.pdf)

------
egraether
> code comes first; visual representation follows

I think this really is the core insight behind visual tooling. I'm currently
working on Coati, a source explorer for C/C++, which does exactly that. By
building a visual representation on top of a textual syntax, you can leverage
the advantages of both.

[https://www.coati.io/](https://www.coati.io/)

~~~
Scea91
My problem with such tools as that it always looks nice on toy examples but
when faced with some real-life complexity the source seems always way more
clear and faster to navigate.

~~~
egraether
Naturally, you can't get rid of reading source code, that's where all the
information is. But the visual representation can speed up navigation and
understanding a lot. Having worked with the visual navigation of Coati for
while now, I can tell you that it changed the way I develop software. Seeing
at a glance which classes derive from an interface or where and how often a
function is called gives you a whole new perspective on your codebase.

------
jackmaney
> At some point in their careers, almost every data scientist has written code
> to perform a series of steps, and thought, “It would be great if I could
> build these transformations visually rather than by writing code.”

I have been in a data science career for nearly six years, now, and I have
_never_ thought this. Not once. Further, I don't know of a single colleague or
associate who _has_ thought such a thing.

~~~
slagfart
I've been in one for just slightly longer, and I absolutely adore visual tools
(SSIS). My coworker despises them. We are similarly experienced and similarly
productive.

After some discussion, the difference seems to stem from our own mental design
patterns. When I design and visualise a data process, I literally draw and
diagram on paper in the same way that a visual tool represents it. His own
prototyping is notes in the form of pseudocode.

Don't underestimate the human equation at work here. This debate might not
ever be 'solved'.

------
jweir
Why not have both? A language which supports strong visualization of its
underlying code would be a win for developers.

The point of visualization is to improve understanding where text fails.

Such a language would likely have more constraints, but constraints are not
necessarily a bad thing.

DRAKON-Erlang looks like such an environment.

[https://www.youtube.com/watch?v=yZLedcnFA94](https://www.youtube.com/watch?v=yZLedcnFA94)
[http://drakon-editor.sourceforge.net/](http://drakon-editor.sourceforge.net/)

I hope the future of software development will include powerful visualization
tools and A.I. to help developers deal with ever increasing complexity.

------
Pamar
I have worked most of the time in traditional (text based) languages, but I
have also a non-trivial experience with a tool which is mostly visual
(Software AG webMethods - here is an example of how it "looks":
[https://webmethodsexpert.files.wordpress.com/2015/07/try-
fin...](https://webmethodsexpert.files.wordpress.com/2015/07/try-
finallyblock.png?w=438&h=289)).

I suspect that unless you had most of your experience in a visual environment,
you will never be able to work at the same level of efficiency that you have
after a much shorter exposure to a text-based code.

This is also due, again in my own opinion, to the fact that while code has
been text-based for 60+ years now, and millions of people have worked with
that (and reinvested into the paradigm, and came up with new and better,
clearer, more concise ways to do things IN TEXT) every attempt to work with a
visual language never made much inroad outside of academia and/or games.

------
frik
I have good memories from an UML design tool that generated Java stub code and
kept in sync with code changes.

3D CAD is really great and works well.

WYSIWYG editors often work for 95% of the use cases.

For several domain specific niches there are already visual designing tools
that work great. Having a text representation in the background is often a
plus, so that some edge cases can be solved.

But I saw a lot of cumbersome tools too.

