DEV Community

Discussion on: Should programming languages be made for IDEs rather than humans?

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch

Although I think we definitely should look for alternative ways to program, the concept of Envision is IMHO a dead-end. I've seen approaches like this before, one has even made it into a product I had to use at work. Everybody hated it. Here's the problem:

visually rich presentations of code

As long as code is text in your thoughts, there's no better visualisation for it than (syntax highlighted) text. Graphical representation of text is utter shit. It makes it hard to write, hard to version/diff, and hard to view anywhere else than in the IDE it has been developed in.

If you want to abstract code, don't try to display code. Slice code into packages/modules, display them as icons and orchestrate them! That's the way to go. I'm pretty sure about it. However you then have added the complexity of another abstraction layer.

Collapse
 
dimitarasenov profile image
Dimitar Asenov

Thanks for your comments, Thorsten. I am very curious what product you used that everybody hated, would you mind sharing?

I have myself used a few visual systems at work, such as Labview and Siemens Plant Simulator. It's true that these systems are not easy to use outside of their specific domain. Unlike these systems, Envision has been designed from the ground up to be generally applicable.

Regarding some of your other points:

code is text in your thoughts

Software developers do not "think in text". Developers think in abstractions (such as classes, functions, modules), control flow (branches, loops), data flow (steps of algorithms and data transformation), etc. Thinking in text would imply that the syntax of a language (as opposed to its semantics) may somehow influence the design of a system or a function, which is not the case.

Once we have decided on a design we have to create a corresponding program. This is mostly done as text, but doesn't have to be. As long as whatever editor we're using nicely maps to our mental model, things can work out smoothly.

(syntax highlighted) text

Syntax highlighted text is in fact a basic form of a visually rich presentation of code. One way to think of the visual aspect of Envision is syntax highlighting on steroids.

Graphical representation of text is utter shit

Graphical representation of "text" might be utter shit, but we're talking about graphical representation of programs. For example:

  • If you want to explain to a new team member how your system works, would you write a bunch of text or draw a diagram with the major components of your system?
  • If you are teaching someone a graph algorithm, would you just write a bunch of text or draw a graph diagram?

Graphical representations absolutely include text where it's the best way to communicate something. E.g., in most cases showing expressions as text is a great option.

hard to write

We have specifically designed Envision to support keyboard-based editing and shown that it is is as fast as typing in a text-editor.

hard to version/diff

Again, we have specifically designed a version control system that integrates with Git and provides a number of improvements over standard text-based diffs, both in terms of presentation and diff accuracy. You may want to watch the corresponding video and/or see the paper.

hard to view anywhere else than in the IDE

As long as the storage format is open and simple (both of which are the case for Envision), any number of editors can be made for it and show it in any number of ways. Take, for example, png image files. You can open/view/edit them in a number of different programs, each with its own strengths and weaknesses.

Slice code into packages/modules, display them as icons and orchestrate them!

I agree. This is part of what Envision does.

complexity of another abstraction layer

This is true, but I see it as a strength, not a weakness. This extra layer allows us to decouple the backend (program structure/code) from the frontend (editor/visualizations/text) and enables both to evolve in ways that are impossible if they are coupled.

Thread Thread
 
thorstenhirsch profile image
Thorsten Hirsch • Edited

Thank you for your detailed reply. The "tool from hell" is SwissRisk's X-Gen, a transformation tool being used at some banks. One might think that it's highly specialised on orders and trades, but it's rather generic and can handle any data as long as you're using XML. But here's the point: the design philosophy of the IDE seems to be based on the assumption, that typing (like on a keyboard) is bad. Unfortunately that's the only "innovative" idea, thus the graphical building blocks that you can drag'n'drop in the IDE are in fact just representations of elements of structured programming. What does that mean? Well in order to program something like this...

if (input.trade[0].type == "foo") { output.info = "hello world"; }

...which you can type in a matter of seconds, you will have to complete the following steps in X-Gen:

  1. create a new transformation.
  2. select the size of your workspace for the transformation. your options are "DIN A3" and "DIN A4". (yep, that's true.)
  3. drag'n'drop the [IF] square on the sheet
  4. open details of the [IF] square and enter 'input.trade[0].type == "foo"' (yes, here you're allowed to type something)
  5. drag'n'drop the [THEN] square onto the [IF] square
  6. open details of the [THEN] square and enter 'output.info = "hello world"'
  7. I also think that one needs to draw some arrows between the squares so that X-Gen knows the order of your squares (i.e. control flow) - well, we only have one square in this example that needs arrows, so 2 arrows are enough: start -> [IF[THEN]] -> end.

You see, this tool really represents text as graphics. It does not even try to step up onto the next abstraction layer, it just makes it really hard to write code by disabling typing for all the keywords.

Why did I write "code is text in your thoughts"? After a long day of coding it happens that I dream of code and then I really see text. Syntax highlighted code. But that's probably just because I stared on it for countless hours. It's not what I think when I am working on code. So yes, I was wrong. Developers think in abstractions, I totally agree with you on that.

I guess this all leads to the question: What's a good abstraction layer for graphical representation? I'm pretty sure the answer is "it depends". When documenting/presenting I like to use Visio diagrams (and ASCII diagrams) for giving an overview of the system, I'm working on. However these diagrams have very different grades of detail, depending on the importance of the components for the audience. So a shape can represent a bunch of hosts (not important) as well as a single function or REST call (important). An IDE on the other side should present a consistent level of abstractions with similar grade of detail for all (technically) equivalent components.