I'm sorry I don't know but I recently came across this device which is I guess a complex mechnical trajectory tracker and I believe was the only device used to determine any corrections needed to steer the spacecraft: http://en.wikipedia.org/wiki/Voskhod_Spacecraft_%22Globus%22... .. It's definitely an interesting read.... and sorry again for not answering your question.
EDIT: So from what I understand this is how it worked: they would record their initial trajectory observations from the ground as the rocket was fired into space. They would then enter that data into the mechanical Globus or IMP which would track the rocket while it was circling around Earth. Russians could only visually track it while it was over their own space as they did not have bases all over the world. The Globus would make sure they weren't flying totally blind. It wasn't perfect, however, and as the spacecraft came back into their observable space they would have to make minor corrections on the Globus and then instructed the astronauts in the spacecraft which firing sequence to perform in order to stay on course.
Perhaps the idea that code can only be read and manipulated by an educated intellectual minority seemed a revoltingly bourgeoisie concept to those in charge at the time.
Most advanced visual programming systems I'm familiar with can't be properly read or manupulated by anyone except even tinier minority of people who specialize on working with the particular system.
Well, having worked with various 4GLs that were meant to improve productivity and produce re-usable code, ones that are being used merely add more accidental complexity rather than reduce it.
And a diagram (in such a 4GL) does not help when it has hundreds of decision nodes and the end-user (read: a human being) visual system can only deal with at most 10 nodes.
It is also very amusing when the executives finally realize how unnecessarily complex their order processing chain is.
Since the dawn of computing, we've seen great increases in programming productivity as we've ramped up our level of abstraction. I'd assume that visual programming is attractive as it appears to be the next rung on this ladder. It may turn out to be a dead end, but people still try.
I'd argue that our next big jump in productivity is likely to come when we are able to have a conversation with an AI about the desired function of a program and have the AI write it for us. Whether visual programming will be a part of this conversation remains to be seen.
No we haven't. What do we really have now that we didn't 30 years ago? A web browser is just an IBM 3270 at the end of the day. The boost in productivity is an illusion hidden behind ever more elaborate bells and whistles.
The boost in productivity will come when we stop reinventing the wheel every few years.
Each new batch of programmers is so ignorant of the past that they spend all their time reinventing it (usually, badly) instead of making any real progress.
It won't happen.
The essence of programming is having a vague description of a problem and figuring it out a way to solve it very, very precisely. This is just not a thing that can be done using AI. Any progress that has been made in AI is just the opposite: Put in a very precise question or description of the problem and you may get a vague answer.
Heck, if, even two decades from now we have some form of AI that just barely understands _existing_ code so that it can have at least a simple discussion with the programmer, I would be very surprised.
Speech in conjunction with diagramming is more powerful than either alone. There's a reason most software companies' supply cupboards are stocked with dry-erase markers and notepads.
I'd be disappointed if our hypothetical AI was unable to grok simple diagrams or generate its own. If a conversation with this entity can still be called programming, I can definitely see it having a visual element.
I think the point is that programming languages fail even in that regard: Even if the syntax is simplistic and understanding is easy, writing code requires a deeper understanding both in terms of how to model things in code and how to conform to syntax ("Oh, I got 2 pages of unrelated errors because I forgot a semicolon"). Both problems don't exist when reading, but do exist when writing.
"Although the main purpose of DRAKON Editor is capturing and editing algorithmic knowledge, it can also be used to build programs." (http://drakon-editor.sourceforge.net/)
> I guess also, if it aids readability, why not just generate the charts from code, rather than the other way around?
Because it works like syntax highlighting. You don't ask "Why don't you write code black on white, and add colors later for reading aid?".
I know because I've done some work in Max/MSP (specifically, in Max4live). Visual programming makes it easy to experiment and try new things. On top of that, the visual programming systems I've used (mostly Max and Synthmaker, but I've tinkered with one or two others too) have had far superior interactive environments than most textual programming languages. Personally, I find the Max environment much better than both the Python and Clojure REPLs (these are currently my two most used textual languages that support some form of interactive programming). Max also has a really convenient debugger which visually shows you how data flows through your program.
My ideal programming system would let you program in both textual and visual code interchangeably (and ideally let you convert one to the other at will).
As an aside, one observation I made when interactively programing in Max is that one of the things that I find most useful for experimentally developing is the ability not to name things. I find textual languages are pretty bad at this: you have to name functions, you have to name variables, you have to name structs/classes - in a visual language, you can usually leave things unnamed. While this would be bad practice in a finished program, it is incredibly convenient while you are trying out ideas before you've committed to a solution and the fact that you can visually see where the data flows, I find its nowhere near as confusing as, eg, anonymous functions or badly named variables in textual languages.
Having said all that, visual languages are far from perfect and are unlikely to ever replace textual languages, but I do believe that a visual language could be created that solves most of the problems with existing visual languages that would, for a large class of programs, be better suited than textual languages alone (certainly if, as I said above, you could mix and match visual and textual at will).
For one, a text-based programming language must be learned using separate documentation or instruction, as the possible commands are not obvious. In a visual programming environment, the available commands are discoverable within the development environment.
A visual environment for a text-based language can get you a long way. Intellisense makes learning a lot of things about a new language without any external documentation very practical.
It's described as "2-dimensional" - I guess that means you set your calculation up as a spreadsheet, then it generates native code to run it at full speed.
Most soviet equipment I have seen (1980-1991) was programmed using plain Assembly or C. The Soviet Union manufactured its own version of the 8086 processor that worked with all popular compilers of that time. However I don't know about the 1970s era.
While this may be off topic, i am actually a lot more interested how they executed the project management part of the whole program.
The project management techniques in use today seem like they have been largely developed in the US aeronautics industry.
The soviet space program was inteed a complex task requiring coordination with large teams in different areas of development. Is anybody aware how they organize that? is the methodology documented somewhere?
>> "This language is also intended for using by non-programmers."
Hardly surprising the Russians created their own programming language (doubt this is available via open source). However positive to see they aimed it towards non programmers.
EDIT: So from what I understand this is how it worked: they would record their initial trajectory observations from the ground as the rocket was fired into space. They would then enter that data into the mechanical Globus or IMP which would track the rocket while it was circling around Earth. Russians could only visually track it while it was over their own space as they did not have bases all over the world. The Globus would make sure they weren't flying totally blind. It wasn't perfect, however, and as the spacecraft came back into their observable space they would have to make minor corrections on the Globus and then instructed the astronauts in the spacecraft which firing sequence to perform in order to stay on course.