Search in topic

Как вы считаете, что будет с программированием в недалеком-далеком будущем?

каталог Арести

Почитал, вполне подходящая система. Если поделить фигуры из каталога на более мелкие кубики - получаются такие элементы:

1. прямая с параметрами азимут,возвышение,длинна
2. дуга окружности с параметрами центр,радиус,плоскость и длинна дуги
   Они сопрягаются по касательной.
   Для возможности “внешней синхронизации” надо к каждому элементу еще добавить параметр: скорость или время прохождения.
   На каждый элемент может быть наложено элеронное вращение с параметрами угол и угловая скорость. (напр. петля с бочкой наверху = дуга+(дуга с бочкой)+дуга)
   Еще бы надо для блока(набора) элементов добавить общий масштаб (по размеру и скорости) и поворот по азимуту.
   Что-то из каталога Арести не сложится из таких элементов?

я, вообще-то, имел в виду совершенно иное. А именно рил-тайм “обучение” программы фигурам, выполняемым живым пилотом на целевой модели.

А решаема ли эта задача?
Примерно представляю как по логам многих полетов посчитать параметры модели - это очень большой объем данных и маш.времени.
Совершенно не представляю, что можно поменять, чтобы влезло в реалтайм. (соотв. не понимаю смысла мощного компа на борту)

при воздушном бое для выполнения маневров атаки и уклонения ))

модельные “глаза” - сложная штука.

Причем, сим сгодится любой из хороших - AFPD, AF5, RF.

Сим должен отдавать на сторону координаты,ориентацию и скорости(обычную и угловую). Желательно по сети.

А зачем для управления БПЛА или траекторией аппарата - язык? Достаточно просто жестко заданного вектора. Каждая точка -

А как лететь между точками? Три точки под прямым углом - это что, два отрезка или дуга окружности? Интерполировать надо не абы-как, а так как указано в правилах.
Аналогия - растровые и векторные рисунки. Векторные описываются языками (postscript в pdf-ах, svg, …)

Совершенно не представляю, что можно поменять, чтобы влезло в реалтайм. (соотв. не понимаю смысла мощного компа на борту)

я предполагал менять весовые коэффициенты отклонения рулей/газа и скорости их изменения. Т.е. обучение должно свестись просто к изменению чисел в таблицах пересчёта.

модельные “глаза” - сложная штука.

это точно. Но реально об этом пока речь не идёт. Скорее, это смешной аргумент, которым можно заинтересовать военных ))

Сим должен отдавать на сторону координаты,ориентацию и скорости(обычную и угловую). Желательно по сети.

Вы правы. Об этом я как-то забыл.

Что-то из каталога Арести не сложится из таких элементов?

по-моему, Арести совершенно не учитывает 3Д. Хотя, последние редакции я не смотрел (уже лет 5 как)

На каждый элемент может быть наложено элеронное вращение с параметрами угол и угловая скорость

почему только элеронное? Водпад крутят РВ, сваливание от РН используется как минимум при штопоре…

а я думал, что Вы давно уже поняли, что язык, о котором я говорю, включает в себя функции автопи…

А, кажется понял.
Но не согласен 😃 Лучше - сделать декомпозицию задачи: вот - автопилот, вот - вектора полета (маршруты, если по старому) и редактор для этих самых маршрутов.

PS: в современном мире - за то, что программисты вечно норовят максимально обобщить задачу и от частностей перейти к решению общностей с наприсаниями фрэймворков, движков и собственных скриптов - их нещадно бьют и гонят с работы 😈 Потому, что это прямой способ срыва всех сроков, а повторно и-или в других проектах этот код будет использоваться с вероятностью менее 1%. Сейчас все чаще откровенно говорят: нужен го8нокод, причесанный и структурированный ровно до того уровня, чтобы самому в нем не утонуть до сдачи проекта, но не более.

Добавлено: Вы полагаетесь на абстрактный чужой автопилот, который…

Таки не на чужой, а на отдельный. В моем варианте решения - он отделен от способов и средств описания траектории.

А как лететь между точками? Три точки под прямым углом - это что, два отрезка или дуга окружности? Интерполировать надо не абы-как, а так как у…

Не вижу никакой проблемы. Абсолютно. Во-первых - в точках можно задавать тип интерполяции. Во вторых - можно не задавать, пусть везде будет автоматически кривая второго порядка (хоть Безье, хоть билинейный сплайн или как его там) или линейная интерполяция. В обоих последних случаях для уточнения траектории - ставим просто больше точек. В случае кривой второго порядка - три точки образуют кусок, похожий на кусок окружности.
Если надо прямой угол - в районе самого угла ставим точки очень плотно. Математически-прямой угол конечно не нарисовать, но это не проблема: модель все равно не способна математически точно под прямым углом резко повернуть, какой-то минимальный радиус там будет в любом случае.

почему только элеронное? Водпад крутят РВ, сваливание от РН используется как минимум при штопоре…

Да, действительно на дуги плохо раскладывается. (проблемма в параметрах, контролируемых на борту)
Получается надо задавать траекторию оси вращения, которая не обязательно проходит через ЦТ.

Во-первых - в точках можно задавать тип интерполяции.

Вот и получился обсуждаемый язык.

в современном мире - за то, что программисты вечно норовят максимально обобщить задачу и от частностей перейти к решению общностей с наприсаниями фрэймворков, движков и собственных скриптов - их нещадно бьют и гонят с работы

“В современном мире”…
Я говорил выше, что долго сам долго руководил коллективом и системных, и прикладных программистов целого института.
В числе прочих дел я ускорял сроки реализации задач, успешно разрабатывая и создавая для них целевые языки и др. средства разработки. Поверьте, я это умею делать хорошо.

Вы решили меня поучить как надо работать?
Так имейте в виду, что мне плевать на “говнокод”, который от вас кто-то требует и на того, кто его от вас требует. Я сам лично говнокод никогда не писал и другим не давал. И впредь писать не буду.
Не зарывайтесь, Саша - не учите более опытных, чем Вы, людей.

Вы решили меня поучить как надо работать?

Нет, ни в коем случае!

Однако, коллективов, контор и областей программирования - сейчас невообразимо много. Сейчас многие задачи требуют значительно более быстрого решения, чем, к примеру, даже 10 лет назад. При этом не надо забывать, что конечный пользователь никогда не увидит код программы изнутри, лишь бы не глючило и не тормозило.

Безусловно, это не повод писать - через задницу, но надо ощущать четкую (зыбкую 😃) границу между быстротой разработки (которая важна) и “правильностью” кода (которую никто, кроме тебя, не оценит).

Так имейте в виду, что мне плевать на “говнокод”, …Я сам лично говнокод никогда не писал и другим не…

Сейчас достоверно известно, что с точки зрения совершенства кода (грамотности структурирования проекта, оптимальности реализации функций) - предела совершенства нету. Реально нету. И если столкнуть лбами двух случайных программистов, то у одного из них - код будет го8нокодом по сравнению с кодом другого, и у обоих - код будет жалким подобием кода, написанного неким третьим программистом и т.д. Но при этом все эти программисты - способны решать поставленную задачу и делать это в срок, и З\П могут получать одинаковую, никак не зависящую от красивости их кода.

PS:
Вот интересное видео по теме. Человек в конкретных практических примерах рассказывает, в том числе о важности качества кода. Просто в качестве пояснения моей позиции.

“В современном мире”…
Я говорил выше, что долго сам долго руководил коллективом и системных, и прикладных программистов целого института.
В числе прочих дел я ускорял сроки реализации задач, успешно разрабатывая и создавая для них целевые языки и др. средства разработки. Поверьте, я это умею делать хорошо.

Вы решили меня поучить как надо работать?
Так имейте в виду, что мне плевать на “говнокод”, который от вас кто-то требует и на того, кто его от вас требует. Я сам лично говнокод никогда не писал и другим не давал. И впредь писать не буду.
Не зарывайтесь, Саша - не учите более опытных, чем Вы, людей.

МыслЯ вслух - это как это руководитель и сисадминов и прикладников(назовём проще - CIO) может не дать его прикладникам писать говнокод? Будет за Ними сидеть и перепроверять? У CIO на это в сутках есть максимум 30%, а у них 100%. И их на порядок больше.
Итог - задача нерешаема.

МыслЯ вслух - это как это руководитель и сисадминов и прикладников(назовём проще - CIO) может не дать его прикладникам писать говнокод? Будет за Ними сидеть и перепроверять?

1. не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))

2. “перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.

Вдогонку. Ни в коем случае никого не хочу обидеть, но в среде программистов - не принято хвастаться в духе “как красиво я пишу код” 😒
Потому, что каким бы крутым и опытным вы себя не считали, всегда найдутся еще более опытные и крутые кодеры; а даже в самом причесанном коде, но в крупном проекте - легко находятся “черезжопные” конструкции, за которые можно покраснеть как рак, если это увидит кто-то другой…

Гораздо правильнее - принять как данность, что вы (не зависимо от опыта и заслуг) - не самый крутой программист (пока общественность не потребует вас предъявить свой крутой код 😈). И сконцентрировать внимание на работе, на достижениях конкретных поставленных целей 😃

если столкнуть лбами двух случайных программистов, то у одного из них - код будет го8нокодом по сравнению с кодом другого, и у обоих - код будет жалким подобием кода, написанного неким третьим программистом и т.д

Саша, не будем заниматься бесполезным теоретизированием на пустом месте. Я лично знаю как отличить хороший код от плохого. Принцип прост и давно известен - “кто ясно мыслит, тот ясно излагает”. Но я также знаю, как можно специально сделать обычный код практически нечитаемым, например, в целях защиты.
Так что, не надо огород городить в пустоте ))

… от плохого. Принцип прост и давно известен - “кто ясно мыслит, тот ясно излагает”.

На самом деле - это соответствие уровня кода - решаемой задаче. Но ни в коем случае не надо путать это - с идеальностью кода как самобытной (мифической и недостижимой) сущностью 😃

…можно специально сделать обычный код практически нечитаемым, например, в целях защиты…

Это называется обфускация, если вы вдруг не знали 😃
Как и многие другие методы “защиты”, помогает лишь условно. От китайских ре-инженеров ничего не спасает 😃

На самом деле - это соответствие уровня кода - решаемой задаче.

ничего подобного. Вы опять не поняли.
Мы на разных языках что ли говорим?

Человек может очень грамотно рассуждать и хорошо понимать, что он делает. Но при этом может банально изобретать велосипед - что в программировании распространено сплошь и рядом. Причем велосипед - не современный спортивный, а очень качественный, но трехколесный и детский 😃 Образно говоря.

Это распространено повсеместно, а уж в обособленных коллективах, да если вдруг они не сами на рынок свои проекты выводят, а принимают задания от заказчика - это аж мхом порастает, но никто этого не замечает.

Это называется обфускация, если вы вдруг не знали

ну почему ж не знал? Сам делал обфускаторы, которыми даже другие пользовались ))
В частности, для незабвенной платформы 1С был у меня обфускатор под названием “Кирпичный заводик”. Ставший, кстати, потом очень популярным в народе ))
Код такими кирпичами укладывал - хрен прочитаешь.

1. не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))

2. “перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.

Описание можно написать любое и тестирование выявит только результат работы, а не сам код.

вспомнилось: в литературе почти не описывается один редко встречающийся (в силу своей сложности), но изощренный вид обфускации. Он применим только к процессорам, имеющим команды переменной (разной) длины. Суть его в том, что переход может осуществляться не на начало команды, а на её середину, что, в свою очередь приводит к выполнению совершенно другой команды, код которой является операндом “правильной” команды. В эпоху ЕС ЭВМ мы иногда баловались этим, тем более, что мой собственный дисассемблер раскладывал код на три параллельных цепочки именно с учетом такой возможности.

Технология выглядела так:

1. на ассемблере писался обычный кусок кода, который стандартным образом собирался в объектный код

2. по объектному коду проходились 3-х цепочечным дисассемблером и отыскивали в нем вторичные и третичные более или менее осмысленные куски

3. исходный код слегка модифицировался так, чтобы эти куски реально что-то делали и имели выход (передачу управления) в обычный “первичный” код

На неподготовленные умы результат всегда производил очень сильное впечатление ))

Описание можно написать любое и тестирование выявит только результат работы, а не сам код.

1. речь идет не об “описании”, а о самодокументировании кода. Это совсем другое. (Хотя, общее описание, конечно, тоже нужно)

2. “выявлять” обычно ничего не требуется. Всё видно при беглом просмотре. В свое время существовал даже хороший принцип: “код любой функции не должен занимать больше одной страницы”. Не всегда удаётся ему буквально следовать, но стремится к этому полезно.

3. для проверки работы кода существует альфа и бета-тестирование. Если его результаты удовлетворительны при условии, что исходники оформлены в соответствии с требованиями и не вызывают вопросов - код принимается. При этом, не так важно, предпочитает программист использовать конструкции “for” или “while” - это его личное дело. Но, например, большое количество “goto” сразу вызывает сомнения ))

использовать конструкции “for” или “while” - это его личное дело.

Не всегда. Если это цикл поиска (единственного элемента) по массиву - за for можно сразу пинка под зад отвешивать 😃

…большое количество “goto” сразу вызывает сомнения ))

Одно единственное “goto” - вызывает сомнения 😃

Не всегда. Если это цикл поиска (единственного элемента) по массиву - за for можно сразу пинка под зад отвешивать

не принципиально, т.к. оптимизировать всё равно будет компайлер ))

Одно единственное “goto” - вызывает сомнения

да, я тоже не люблю ))
Но допускаю. Классический пример - из глубоко вложенного цикла надо резко вывалиться наружу.

Загнать цикл - в функцию, вываливаться через return 😃

Теоретически - да, но практически:
вызов функции - лишние операции с передачей параметров и со стеком. Причем, во внешнем цикле (!) (может, даже и не в одном, а в нескольких вложенных)
И вот тут-то оптимизатор компилятора как раз и не распознает такую эээ … дурь )) Обычно вызовы функций они не имеют права оптимизировать в линейный код.
Не всё так просто ))

Загнать цикл - в функцию, вываливаться через return

тут у Вас опечаточка, которую я сначала не заметил: не “цикл”, а “все вложенные циклы”. Тогда действительно можно вывалиться через return. Но можно и огрести проблемы с параметрами, если их много. Однозначного решения нет и goto остаётся допустимым.
К тому же, вывалиться совсем наружу - это частный случай. Может понадобиться вывалиться в один из внешних вложенных. Об этом я и написал до того, как заметил опечатку.

Классический пример - из глубоко вложенного цикла надо резко вывалиться наружу.

Андрей, я вот из цикла про баранов вывалился.😃
Или вывалили…