I agree.

I commuted into Washington DC for a year and it was hell. The noise, and just walking on the sidewalk was stressful, with the traffic and congestion and all the drivers in a horrible mood because of it. And when using the metro (subway), I would have to deal with sleet and snow and rain and walking long distances from the metro stop to my destination, avoiding cars and buses and horrible weather, usually with the stress of being on the verge of being late because commuting took such a large chunk of my day.

Today I have a really nice house on a lake in a suburb. I could not have a home like this in a city - it would cost tens of millions of dollars. I can walk to the store if I choose (or kayak there), as well as kayak on the lake for exercise (which I do several times a week), and bicycle on a nearby path with no cars and lots of quiet and beautiful scenery. And nowadays I have a very pleasant 20 minute commute to my job in a suburban office - on the ground floor with windows and my car parked right outside instead of me tucked away up in some high rise prison.

Why anyone would want to live or work in a city mystifies me.

The rationale for a graphical approach is that one can visualize concurrent behavior more easily.

Structure is also easier to perceive if it is visually apparent - unless it is cluttered up with detail level features, as you have pointed out. So to be able to perceive large scale structure, one must "factor" low level features into larger, more conceptual structure.

I agree that software tools on the market for "visual programming" are not what we want here: you are completely right about those tools being suitable only for simple programs. I am talking about the class of models/designs that represent concurrent behavior, including event oriented designs.

For example, consider a system that is designed completely around events. If one can visualize the inter-connection of components, and one annotates each component with the types of events that it generates (perhaps using expressions), one can easily grasp the overall behavior much more easily than one could if that same design were expressed textually. Thoughts?

PS - I was on the team that designed the VHDL language at Intermetrics circa 1984, and I built the first synthesis compiler for VHDL, so I definitely appreciate your points. I am just not convinced that we are not on a path that is a result of the dominant computing paradigm (imperative programming), rather than the optimal path... I have been out of the HDL field for a long time though, but I often build simulation models of complex systems, and a visual paradigm seems to really help with analysis. That is what makes me wonder about visual approaches to design. I have also wondered about the fact that software programs - created using an imperative paradigm - are so buggy, whereas electronic systems tend to be far more error free. What are your thoughts on why that is?

Interesting. Thanks for the clarification.

I can see that low level schematics would be hopelessly complex to wade through, and would be missing "intent". But what about design level?

E.g., suppose that the design was based on an event paradigm? In that case, the signals are high level flows of information, and the events triggering the signals are not electrical level, but rather are at a conceptual level such as "task A completed".

I wonder if an even based programming paradigm would lend itself to a more graphical approach.

Is it really true that IC are designed with HDLs? I worked in that field during the '80s, so things might have changed; but back then, graphical tools were used, and then the final design was documented using an HDL. I.e., the HDL (e.g., VHDL) was a final generated output, but was not used during the actual design process.

Good point about symbols documenting intent. Symbols enable a comment to refer to something else, e.g., "module ABC".

It is because there are millions of programmers who are experienced using an imperative programming paradigm, and that keeps it going, because imperative constructs lend themselves to textual form.

It is true that if one were to create graphical equivalents for current programming languages, those graphical languages would be cumbersome. One has to think beyond that:

E.g., an event-based programming paradigm is much more powerful than an imperative paradigm, but event based programming is hard to understand when expressed textually; but it is easy to understand if expressed graphically. And that is why concurrent systems - electronic systems - are designed graphically.

And they tend to be relatively error free, compared to imperatively written programs. Complex chips can be designed with few errors, whereas imperative software code tends to have lots of errors.

A graphical language obviates the need to define symbols. Symbols are only needed to cross-reference things; but in a graphical language, you just connect them. The fact that all communication pathways are explicit means that there is no need to control "aliases", and that makes the design process inherently more reliable, and it lends itself to simulation.

It's about more than gates. It is about registers, ALUs, gates, and how they are all connected. There are many different possible architectures, so it depends on the design: some designs are faster but take more real estate. There are algorithm-to-silicon compilers (I know: I wrote one for a product company during the '80s and it is apparently still in use today) but each compiler will assume a certain architecture. I would recommend one but I have been out of that field for decades.

In any such trial, it is important that aspects such as maintainability, reliability and securability be considered. The ability to hack out a-lot of functionality is not the only criteria that is important, unless you are building a home hobby project.

"...reminder that Java has become an Internet security menace."

Actually, the largest menace is Javascript. That's why so many people use NoScript.

Any kind of in-browser active code execution will inevitably have security challenges.

Yes you might be right - perhaps there are some lines that one should not cross no matter what.

Yes: one challenges the Federal government with great peril.

You are right, it does. But one could also say that merely voicing one's opinion against a war "gives comfort to our enemies". Thus, the issue is not "black and white" and there must be a matter of degree as well as consideration of concomitant circumstances.

In my opinion, it all comes down to the level of risk: If we were in an actual war, with a true existential threat and bombs falling on our cities every day, that would be one thing, and it would be acceptable for the government to use any tool at its disposal - including martial law and concentration camps for foreign nationals. But we are not in that situation: averaged over the last 20 years, the chance of dying from terrorism in the US is less than the chance of dying from lightning . Given that low level of risk, we should not be so willing to sacrifice our Constitution in the name of the alleged and over-hyped "war on terror", and allow a secretive organization to engage in widespread surveillance of citizens without effective independent oversight. As a patriotic American, I value our Constitution too much to dismiss that as unimportant, and I applaud Snowden for his courage in uncovering the scope of the surveillance that is occurring. He is not a traitor: he is a hero.

"An enlightened people, and an energetic public opinion... will control and enchain the aristocratic spirit of the government." --Thomas Jefferson

"I think there's an English word that describes selling American secrets to another government, and I do think it's treason," Hayden said.

Well, not if the revelations are about illegal - and especially unconstitutional - behavior.

I agree in principle but it is not all-or-nothing. There is an appropriate balance. Keeping the right balance is hard: it is an endless tug of war among special interests of all kinds.

Very true!

"Get back home alive" is not really a story. I think it is more like an acceptance criteria.