What programming languages were used by the Soviet Union's space program?(programmers.stackexchange.com)
programmers.stackexchange.com
What programming languages were used by the Soviet Union's space program?
http://programmers.stackexchange.com/questions/145669/what-software-programming-languages-were-used-by-the-soviet-unions-space-progra
44 comments
Just a minor note: "astronauts" in Soviet Bloc are called "cosmonauts" (Космонавт).
Why do people care about "visual programming"?
The idea seems nice at first, but you always end up back at traditional programming (http://drakon-editor.sourceforge.net/python/python.html#clas...). To think that this is for non-programmers is silly.
I guess also, if it aids readability, why not just generate the charts from code, rather than the other way around?
The idea seems nice at first, but you always end up back at traditional programming (http://drakon-editor.sourceforge.net/python/python.html#clas...). To think that this is for non-programmers is silly.
I guess also, if it aids readability, why not just generate the charts from code, rather than the other way around?
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.
That certainly seems to be the case, but I'm not sure that it was the intention.
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.
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.
yours is the answer to "why do people care about non-programmers controlling machines" not "why do people care about visual programming".
how do you solve the issue you point out? isn't using symbols to represent something machine-readable what a programming language already is?
how do you solve the issue you point out? isn't using symbols to represent something machine-readable what a programming language already 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.
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.
The boost in productivity will come when we stop reinventing the wheel every few years.
This is why computing has stagnated for 30 years http://programmers.stackexchange.com/q/58186/6219
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.
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.
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.
That seems extraordinarily unlikely, speech is var better at conveying abstraction than pictures (though pictures have a higher bandwidth).
http://catb.org/~esr/writings/unix-koans/gui-programmer.html
http://catb.org/~esr/writings/unix-koans/gui-programmer.html
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'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.
> Why do people care about "visual programming"?
"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?".
"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?".
It's the same reason you use a mouse even though 99% of the things you do on a computer involve a keyboard.
People tend to be visual, especially when they are in unfamiliar territory - which everyone is in when they are learning.
"Visual Programming" helps with learning, thus comprehension.
People tend to be visual, especially when they are in unfamiliar territory - which everyone is in when they are learning.
"Visual Programming" helps with learning, thus comprehension.
"Visual Programming" helps with learning, thus comprehension.
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).
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.
[deleted]
the available commands are discoverable within the development environment
I suppose I should qualify that:
Visual Programming gets you to a point where you can "use" the language faster. I appreciate this isn't the same as pure comprehension.
My original sentence is a little off.
Visual Programming gets you to a point where you can "use" the language faster. I appreciate this isn't the same as pure comprehension.
My original sentence is a little off.
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.
Ladder programming is visual and is very widely used in PLCs.
Although some people dislike it a lot it is very nice for diagnostic reasons.
Although some people dislike it a lot it is very nice for diagnostic reasons.
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.
Why, Lisp of course: http://twitpic.com/60plzm/full
(I don't have anything but that Soviet era mosaic to back it up with.)
(I don't have anything but that Soviet era mosaic to back it up with.)
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?
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?
In late 80es and early 90es (and probably still) they used Modula 2 for programming satellites and such.
CCCP, I guess.
It's not soviet but if you're interested in this you should also see all of the programs used in the Apollo and Gemeni missions:
http://www.ibiblio.org/apollo/links.html
http://www.ibiblio.org/apollo/links.html
>> "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.
Are there any Drakon programmers on HN?
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.
Are there any Drakon programmers on HN?
As a kid, I had a book (Паронджанов В.Д., Занимательная информатика; Parondzhanov V.D., Zanimatel'naya Informatika; http://drakon.su/_media/biblioteka/parondzhanov_zanimatelnay...) that taught programming and logic concepts through Drakon.
Maybe not yet, but I'm sure there soon will be:
http://drakon-editor.sourceforge.net/
Really curious to see the Erlang code generation...
[deleted](1)
In Mother Russia language programs you.
I believe the primary language used was BORAT. Sorry, couldn't resist.
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.