Здравствуйте, Cyberax, Вы писали:
C>Там зеленые за лягушек волнуются. Их может потревожить взлетающая ракета.
Что с них взять — зеленые, те и другие.
C>Там будет три разгонника и центральный модуль. Причём движки везде одинаковы.
Одинаковые и много, но не те, что у Falcon-9. Удельный импульс на 14 секунд больше, давление в камере в полтора раза больше, тяга тоже в полтора.
C>За счёт общей топливной системы сначала три разгонника + центральный модуль будут первой ступенью, потом разгонники отделяются, но за счёт общей топливной системы в центральном модуле горючее не будет израсходовано почти совсем. Так что центральный модуль дальше работает второй ступенью. Ну и там дальше отделение и уже обычная третяя ступень. Просто как всё гениальное.
Просто, просто. Но полезную нагрузку увеличивает только на несколько процентов. Как и добавление третьей ступени. Не случайно почти все современные ракеты двухступенчатые. Это, конечно, если с чистого листа пректировать при всех остальных равных условиях. Семерка и Протон отдельные истории, им добавление третьих ступеней много дало.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[17]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, pagid, Вы писали:
C>>Там зеленые за лягушек волнуются. Их может потревожить взлетающая ракета. P>Что с них взять — зеленые, те и другие.
Ага.
C>>Там будет три разгонника и центральный модуль. Причём движки везде одинаковы. P>Одинаковые и много, но не те, что у Falcon-9. Удельный импульс на 14 секунд больше, давление в камере в полтора раза больше, тяга тоже в полтора.
?
На Falcon 9 стоят Merlin 1C на существующих или 1D на будущих ракетах, на Heavy будет только 1D.
Вся вариация будет только в том, что для последних ступеней будут вакуумные версии, а так все варианты ракет будут использовать только один двигатель.
C>>За счёт общей топливной системы сначала три разгонника + центральный модуль будут первой ступенью, потом разгонники отделяются, но за счёт общей топливной системы в центральном модуле горючее не будет израсходовано почти совсем. Так что центральный модуль дальше работает второй ступенью. Ну и там дальше отделение и уже обычная третяя ступень. Просто как всё гениальное. P>Просто, просто. Но полезную нагрузку увеличивает только на несколько процентов.
Около 10% — весьма немало.
P>Как и добавление третьей ступени. Не случайно почти все современные ракеты двухступенчатые. Это, конечно, если с чистого листа пректировать при всех остальных равных условиях. Семерка и Протон отдельные истории, им добавление третьих ступеней много дало.
Третяя ступень, если она отдельная, то не очень окупается по стоимости. А тут они сделали 2.5-ступенчатую ракету.
Sapienti sat!
Re[18]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Cyberax, Вы писали:
C>Около 10% — весьма немало.
Если обсуждать переходы ежду вариантами на 32 и 52 тонны, 10% это ничто.
C>Третяя ступень, если она отдельная, то не очень окупается по стоимости. А тут они сделали 2.5-ступенчатую ракету.
Ох уж эти условные циферки "2.5-ступенчатую ракета", "компьютер пятого поколения"...
К слову, 2.5 ступени было у какой-то эмериканской буйной фантазии (но успешно летавшей) на рубеже 50-60-х — два из четырех двигателей отделялись, когда становились избыточными.
А уж как важен был перелив в проекте "луной ракеты" Челомея — УР-700, там без него никуда.
Привожу пример реальной дракон-схемы.
Схема занимает 5 листов формата А1.
Мысленно расположите листы по горизонтали (в цепочку)
слева направо.
Пронумеруйте листы 1, 2, 3, 4, 5.
Для увеличения листов используйте "лупу" со знаком +
Вообще, дракон очень похож на языки IEC_61131-3, которые достаточно активно применяются инженерами при программировании встроенной электроники. И скорее всего его ноги как раз из этого стандарта и растут. Для программистов, конечно, такие языки кажутся слишком упрощенными и не катят, но для инженеров они подходят — не слишком их перегружая новыми знаниями и требованиями.
IEC 61131-3 is the third part (of 8) of the open international standard IEC 61131 for programmable logic controllers, and was first published in December 1993 by the IEC. The current (second) edition was published in 2003.
Part 3 of IEC 61131 deals with programming languages and defines two graphical and two textual PLC programming language standards:
Ladder diagram (LD), graphical
Function block diagram (FBD), graphical
Structured text (ST), textual
Instruction list (IL), textual
Sequential function chart (SFC), has elements to organize programs for sequential and parallel control processing.
Ladder logic is a programming language that represents a program by a graphical diagram based on the circuit diagrams of relay logic hardware. It is primarily used to develop software for programmable logic controllers (PLCs) used in industrial control applications. The name is based on the observation that programs in this language resemble ladders, with two vertical rails and a series of horizontal rungs between them.
Здравствуйте, DarkGray, Вы писали:
DG>Вообще, дракон очень похож на языки IEC_61131-3, которые достаточно активно применяются инженерами при программировании встроенной электроники. И скорее всего его ноги как раз из этого стандарта и растут. Для программистов, конечно, такие языки кажутся слишком упрощенными и не катят, но для инженеров они подходят — не слишком их перегружая новыми знаниями и требованиями.
Не-не. Графические языки для электроники — это хорошая, полезная вещь. ДРАКОН — это язык записи алгоритмов. Внешняя похожесть — только в квадратиках со стрелочками.
Чтоб понять уровень их идиотизма — у них на форуме флейм в 5 страниц о том, как делать диаграммы с пересечениями стрелок.
Sapienti sat!
Re[19]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, pagid, Вы писали:
C>>Около 10% — весьма немало. P>Если обсуждать переходы ежду вариантами на 32 и 52 тонны, 10% это ничто.
Большая ценовая эффективность — это не шутки. У сравнимой "Ангары А7" при полезной нагрузке в 40т на LEO масса в 1154т., против 53т. при массе 1400т.
C>>Третяя ступень, если она отдельная, то не очень окупается по стоимости. А тут они сделали 2.5-ступенчатую ракету. P>Ох уж эти условные циферки "2.5-ступенчатую ракета", "компьютер пятого поколения"... P>К слову, 2.5 ступени было у какой-то эмериканской буйной фантазии (но успешно летавшей) на рубеже 50-60-х — два из четырех двигателей отделялись, когда становились избыточными.
Вполне логично, идея лежит на поверхности.
P>А уж как важен был перелив в проекте "луной ракеты" Челомея — УР-700, там без него никуда.
Ну, лунные ракеты никуда нормально не полетели, к сожалению.
Здравствуйте, DarkGray, Вы писали:
C>> ДРАКОН — это язык записи алгоритмов. DG>вот это утверждение мне непонятно. А какой язык не является языком записи алгоритмов? Если, конечно, не брать группу markup languages.
Грубо говоря, языки для электрических схем устанавливают взаимное соединение элементов. В том числе и в тех случаях, когда результирующая схема не выполняет никаких цифровых вычислений.
А ДРАКОН — это язык для записи обычных императивных алгоритмов, т.е. if-then-else, циклы и т.п.
C>А ДРАКОН — это язык для записи обычных императивных алгоритмов, т.е. if-then-else, циклы и т.п.
Оба графических языка(Ladder diagram (LD), Function block diagram (FBD)) из IEC_61131-3 предназначены для того же (один меньше, другой больше).
FBD, вообще, похож на примитивные блок-схемы:
A function block diagram (FBD) is a block diagram that describes a function between input variables and output variables. A function is described as a set of elementary blocks. Input and output variables are connected to blocks by connection lines. An output of a block may also be connected to an input of another block:
Functional block diagram of the attitude control and maneuvering electronics system of the Gemini spacecraft. June 1962.
Inputs and outputs of the blocks are wired together with connection lines, or links. Single lines may be used to connect two logical points of the diagram:
An input variable and an input of a block
An output of a block and an input of another block
An output of a block and an output variable
Siemens, beckhoff, schneider и т.д. — сейчас все предлагают визуальные среды для программирования на FBD, который по сути графическое представление ассемблера. Дракон по сравнению с FBD — это шаг вперед, это графическое представление языков уровня алгола или паскаля.
Соответственно, дракон в нише для программирования электроники домофона, гаражных ворот, бойлерной, мини-конвеера для сахарного заводика и т.д. — смотрится перспективно, по сравнению с тем, что сейчас там есть.
В образовании и "нормальных"(не plc) нишах программирования Дракон, конечно, нафиг не нужен. Там уже все занято более современными, и более мощными и выразительными языками.
зы
Но занять нишу PLC-языков у Дракона скорее всего не получится — не хватит денег и грамотного менеджмента. Также Дракону не хватает текстового представления наравне с графическим представлением. Вообще, конечно, жалко — труд российских(советских) инженеров уйдет в мусорку, хотя при грамотном менеджменте мог бы поднять программирование plc-ишек на новую ступень.
В ДРАКОНе такого нет, там есть обычный линейный поток управления. Приспособить его, конечно, можно. Но получится тот же FBD в другой нотации.
DG>и, имхо, в тех же SCADA-системах — Дракон не плохо будет смотреть (при грамотном трансляторе для PLC) по сравнению с FBD.
В СКАДА? Да ну.
Здравствуйте, DarkGray, Вы писали:
DG>Siemens, beckhoff, schneider и т.д. — сейчас все предлагают визуальные среды для программирования на FBD, который по сути графическое представление ассемблера. Дракон по сравнению с FBD — это шаг вперед, это графическое представление языков уровня алгола или паскаля. DG>Соответственно, дракон в нише для программирования электроники домофона, гаражных ворот, бойлерной, мини-конвеера для сахарного заводика и т.д. — смотрится перспективно, по сравнению с тем, что сейчас там есть.
Почему? Это всё обычные примеры КА. ДРАКОН асболютно отстойно подходит для них, так как переходы между состояниями получаются скрытыми в мелочах из действий.
Тем более, что в ДРАКОНе абсолютно отсутствуют понятия инвариантов и программирования по контракту, что как раз весьма важно для вещей типа бойлерной или контроллера светофора. Не хотелось бы, чтобы у светофора горело одновременно два зелёных света. Т.е. нельзя формально взять схему и показать, используя эту схему, что никогда не возможно наличие конфликтующих зелёных. Точнее можно, но потребуется обычное формальное текстовое доказательство.
Для сравнения, в JPF от НАСА есть интересный режим, когда задаётся конечный автомат состояний (в виде графической схемы!) и верификатор проверяет, что код соответствует этой схеме. Причём таких схем может быть несколько.
Это поднимает вопрос, а какая программа является не обычным примером КА?
C> В ДРАКОНе такого нет, там есть обычный линейный поток управления.
Каждая вертикальная линия в драконе — это отдельный поток управления. Линии могут разветвляться или сливаться. Разве не так?
C>Для сравнения, в JPF от НАСА есть интересный режим, когда задаётся конечный автомат состояний (в виде графической схемы!) и верификатор проверяет, что код соответствует этой схеме. Причём таких схем может быть несколько.
в моем понимании — это отдельный блок. и его можно прикрутить к произвольному языку.
и разве JPF графический?
C>Тем более, что в ДРАКОНе абсолютно отсутствуют понятия инвариантов и программирования по контракту
Вот такой разговор, в формате — а что стоит добавить, чтобы стало лучше — мне больше нравится, чем разговор вида: язык — говно, автор — идиот.
В первом случае, мы все становимся чуточку образованнее, во втором — лишь глупее и обиженнее.
Что на твой взгляд еще бы стоило добавить (или сделать по другому)? При условии, что язык обязан иметь полное графическое представление (допустим на мгновение, что данное требование — догма и не подлежит обсуждению).
DG>Каждая вертикальная линия в драконе — это отдельный поток управления. Линии могут разветвляться или сливаться. Разве не так?
оказывается — это не так. Тогда — да, согласен, очень многого не хватает. Разве что правила графической визуализации очень хорошо проработаны — мне нравится.
Здравствуйте, DarkGray, Вы писали:
DG>Вообще, дракон очень похож на языки IEC_61131-3, которые достаточно активно применяются инженерами при программировании встроенной электроники. И скорее всего его ноги как раз из этого стандарта и растут. Для программистов, конечно, такие языки кажутся слишком упрощенными и не катят, но для инженеров они подходят — не слишком их перегружая новыми знаниями и требованиями.
Ну, по редким внятным описаниям от того же Паронджанова, так и есть. Инженеры-непрограммисты описывают достаточно высокоуровневый алгоритм, который потом воплощается в железе или софте (или и том и другом).
Сейчас же (если взять этот ответ), Дракон можно использовать как простой аналог Rational Rose для кодогенерации на основе UML (где в роли UML выступает сам Дракон).
К>>И как это соотносится с тем, что проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.? Или в драконе есть аналоги структурных диаграмм UML, например? К>>Ещё пару вопросов (если вдруг есть возможность/желание ответить) - К>>Как насчёт взаимодействия сущностей (проектируем в рамках ООП, например) наподобие диаграмм последовательности? К>>Можно ли на драконе нарисовать алгоритм, использующий ФВП? LVV>1. Я думаю, эти вопросы лучше задать автору Дракона Владимиру Даниэловичу.
Задали, и не один раз. Он так и не соизволил ответить. Ну или генерит какую=то бредятину (например, см. его ответ на мой вопрос тут
Ну и еще один перл приведу:
DM>А можно пару подтверждающих примеров?
За этим вам лучше сходить на oberoncore.ru
Там большое сообщество, там огромное количество примеров, там обсуждают и делают редакторы Дракона.
За три страницы обсуждения успели обсудить все — мою личность, мои стихи, мою компетенцию, нимб и самовлюбленность TAU, но примеры так и не появились. К чему бы это?
