Как вы считаете, что будет с программированием в недалеком-далеком будущем?
Лично я люблю ассемблер, а программирование на MFC (или что там .NET?) внушает мне панический ужос. Но речь о тенденции; если все перейдут на “кубики” - деваться некуда, кому надо придется писать на них. И мне кажется что так и будет.
Аркадий, Вы сравниваете несопоставимые вещи:
-
сказать “люблю ассемблер” - ничего не сказать т.к. ассемблеры является всего лишь символическим отражением системы команд и архитектур разных процессоров/контроллеров. Сколько архитектур - столько и ассемблеров.
-
Си как, собственно, язык программирования не имеет никакого отношения к Microsoft Foundation Classes (MFC) и, тем более, к .NET, последний из которых, вообще, исполняется в режиме интерпретации.
-
MFC и .NET в значительной степени и являются этими самыми “кубиками” (только не графическими), которые давно используются повсеместно.
Однако, если надо напрямую работать с физ. ресурсами аппаратуры, то чаще всего это удобнее делать на ассемблере.
Сейчас Вы не сможете в Винде даже символ в порт послать напрямую, просто не даст, начиная с Win2000 прямой доступ к железу закрыт.
Даже на микроконтроллерах и то ассемблер не требуется, все прекрасно делается на С (допускаю что иногда бывают исключения).
Более того, в условиях часто изменяющейся среды - ассемблер это зло, т.к. переносимость его крайне низка. Уже через полгода может вылезти куча граблей (и 100% вылезет) если надо перенести код на более новую платформу.
Лично я люблю ассемблер, а программирование на MFC (или что там .NET?) внушает мне панический ужос.
Написание программы под Windows на асме - будет ужас в разы больший, гигантская простыня совершенно нечитаемого и непереносимого кода 😃
Да и MFC уже устарел лет на 5-10, хотя сам на нем пишу иногда.
Сейчас Вы не сможете в Винде даже символ в порт послать напрямую, просто не даст, начиная с Win2000 прямой доступ к железу закрыт.
Даже на микроконтроллерах и то ассемблер не требуется, все прекрасно делается на С (допускаю что иногда бывают исключения).
а) я не имел в виду приложения для Windows
б) если вы пишете драйвер, то прямой доступ к железу как раз есть
в) если вы пишите код для микроконтроллера с очень ограниченными ресурсами (быстродействие и память), то кроме ассемблера выбора обычно не остается.
г) вопрос переносимости/совместимости тоже может не стоять если вы пишете, например, какой-нибудь АОН для традиционного бытового телефона с копеечным 4-х битным микроконтроллером и крошечной встроенной памятью. Кстати, компилятора с Си для него может просто не быть.
Конструкторы программ, всякие там <чтоугодно>мэйкеры и некоторые движки - не уменьшают объем работ по человеко-часам при реализации конкретной задачи.
Но само по себе создание разных конструкторов и своих сред разработки со своим рыбьим языком внутри - неплохой бизнес! Если завернуть в красивую обертку, можно подсадить на себя определенное количество людей и долго получать с них деньги. При этом - чем дольше эта система на рынке, тем больше у нее пользователей и эти пользователи никуда не могут свалить. Потому, что он изучал не Си++, который применяется везде с небольшими вариациями и похож еще на десяток других скриптов и языков, а изучал самобытную фигню, которая существует только в пределах одной конкретной среды разработки. 😃
за свою жизнь я создал несколько специализированных языков и написал компиляторы/интерпретаторы к ним. Причем, задачей было не “подсаживание” на них пользователей, а именно ускорение разработки своим же собственным коллективом программистов, которым я тогда руководил.
Причиной создания этих специализированных языков являлась оптимизация (уменьшение) количества языковых примитивов вместе с увеличением их мощности. Т.е. принцип “максимума возможностей при минимуме выразительных средств”. Вообще, это довольно сложная задача, которая по зубам далеко не всем. В частности, то “воронье гнездо”, которое получилось, например, у разработчиков платформ 1С служит прямо противоположным примером. Т.е. примером того, как НЕ НАДО делать.
Кстати, если не заморачиваться созданием специализированных языков, то во многих случаях в этом же могут помочь макропроцессоры (развитые препроцессоры исходного кода).
Аркадий, Вы сравниваете несопоставимые вещи:
Андрей, я может плохо выразился. Я имею ввиду что по мне чем язык “меньше” и “прозрачнее” тем лучше (в идеале я бы хотел программировать машину тьюринга))). И я согласен, что MFC те же кубики, и я думаю что дальше будет еще хуже)), т.е идея кубиков будет повсеместно культивироваться в том числе по маркетинговым причинам о которых говорил ADF. (Кстати, вы не заметили тенденцию писать рекламные проспекты на хардверные и софтверные инструменты разработки как будто это конструкторы адресованные детям: “Дорогой друг, в этой коробке ты найдешь все что тебе надо чтобы построить…”)
Написание программы под Windows на асме - будет ужас в разы больший,
Не про нас будет сказано - не дай Бог! я это не имел ввиду…))) (когда-то давно немного баловался простыми VxD драйверами…)
Кстати, вы не заметили тенденцию писать рекламные проспекты на хардверные и софтверные инструменты разработки как будто это конструкторы адресованные детям: “Дорогой друг, в этой коробке ты найдешь все что тебе надо чтобы построить…”)
Ну так это именно для того и делается, чтобы народ заманить! 😃 И еще любят показывать красивые “видео-уроки” - где с помощью этой замечательной, волшебной среды разработки с ловкостью решают некую якобы произвольную задачу. А на самом деле - решают строго ту задачу, с оглядкой на которую эта среда создавалась и не факт, что задачи с даже небольшими вариациями относительно показанной - в этой среде решаются также легко.
в идеале я бы хотел программировать машину тьюринга))).
не дай Бог! )))))
Конечно, чем более просты и компактны примитивы языка, тем проще он для понимания, но из этого совершенно не следует, что каждый простой язык удобен для программирования. В идеальном случае специализированный язык для какого-либо класса задач должен оперировать терминами самого этого класса задач и операциями над данными, характерными именно для этого класса. Но я уже писал выше, что создание таких языков с компактными, но мощными примитивами, является нетривиальной задачей и, вообще, сродни искусству. Язык машины Тьюринга безусловно к таким языкам не относится ))
Представьте, сколько операций такой машины, умеющей только двигать ленту взад и вперед проставляя на ней символы, Вам потребуется чтобы выполнить хотя бы элементарную программу сложения двух чисел!
Так что, машина Тьюринга - всего лишь абстракция автомата, не имеющего к практической жизни никакого отношения.
Кстати, вы не заметили тенденцию писать рекламные проспекты на хардверные и софтверные инструменты разработки как будто это конструкторы адресованные детям: “Дорогой друг, в этой коробке ты найдешь все что тебе надо чтобы построить…”
нет, не заметил.
Красота!!😈
не дай Бог! )))))
+1 . Из того что для построения любой логической схемы достаточно единственного элемента “Штрих шеффера” (2И-НЕ ) или “стрелка Пирса” (2ИЛИ-НЕ) совершенно не следует что используя его и только его удобно строить цифровые логические схемы. Скорее даже наоборот - триггеров, сумматоров и т.д. они не отменили. С програмированием аналогчно.
Красота!!
По существу практически так и есть уже сечас при програмировании FPGA. Кубики готовые библиотечные модули реализации того или иного протокола или модуля. Мало кто будет в сотый раз сам выдумывать реализацию сумматора или буфера. для этого нужны очень и очень веские основания. В програмировании аналогично.
…Мало кто будет в сотый раз сам выдумывать реализацию сумматора или буфера. для этого нужны очень и очень веские основания. В програмировании аналогично.
Вот именно в программировании бывает обратная тенденция. Сестра оверинженеринга и перфекционизма: когда программист делает что-то только потому, что он может это сделать, даже если для этого он подглядывает в код готовой, но написанной не им библиотеки 😈
за свою жизнь я создал несколько специализированных языков и написал компиляторы/интерпретаторы к ним.
Из каких областей ? (если не секрет)
А как бы мог выглядеть язык для описания пилотажного комплекса?
Т.е. на какие элементы-кубики порезать например кубинскую восьмерку или разворот на горке?
(Реализация - видимо так: форт-байткод с наземки заливается в автопилот на avr(ardupilot) или arm(cortex-m3,4).
Ограничена память, интерпретатор и скрипт не должны обмолачивать память)
Из каких областей ? (если не секрет)
в основном для работ с большими БД (примитивы работы с БД были имплементированы прямо в язык), для потоковой обработки текстовых данных, включая компилятор компиляторов, макропроцессоры и кое-какие препроцессорные расширения + библиотеки функций для игр (MSX). Это было очень давно (в эпоху ЕС ЭВМ) и сейчас практически потеряло актуальность.
Кроме мастерства, конечно, которое не пропьёшь ))
А как бы мог выглядеть язык для описания пилотажного комплекса?
Первое, что приходит в голову - в качестве примитивов языка использовать каталог Арести, но на мой взгляд он “грубоват” т.е. недостаточно детален с точки зрения исполнения элементов отдельных фигур. Нужны какие-то более мелкие примитивы + возможность рил-тайм управления ими для опционального подключения “автопилотных” и стабилизирующих средств. Причем, языки управления БПЛА тут не пригодятся, т.к. они рассчитаны не на пилотаж, а на выполнение прикладной задачи в целом.
Мне кажется, что детализация должна быть на уровне 1/8 или даже 1/16 бочки, петли и каких-то еще самых примитивных ЧАСТЕЙ (!!!) фигур. Кстати, провести исследование всех фигур ВП и 3Д и выявить минимальный набор таких примитивов - ОЧЕНЬ достойная задача! Мне кажется, что таких примитивов окажется не так уж и много. Не более 1-2 десятков, включая переходные связки. А потом уже, как следующий “над-уровень” из них можно строить сам Арести и иже с ним фигуры для 3Д.
добавлено: хорошая тема для диссера, кстати )))
Ограничена память, интерпретатор и скрипт не должны обмолачивать память
мне кажется, что это излишние ограничения. Даже для 30-50 размеров (размах 1.20-1.50) лишние 100 г мощного проца с хорошей памятью и контроллерами погоды не сделают. А что уже говорить о размахах от 2.20…
Не надо забывать также и о том, что интерпретатор вряд ли сможет обеспечить приемлемый рил-тайм для стабилизации и автопилота. Нужна какая-нибудь вполне стандартная начинка с элементной базой экономичного, но вполне производительного нетбука.
еще добавлено: также будет забавно рассмотреть процесс настройки/привязки такого типового пилотажного софта к конкретным моделям. Что-то вроде процесса “обучения” софта в руках опытного пилота на целевой модели. Еще одна тема для диссера ))
и напоследок: на земле закладываем в ноут музончик с таймкодом и синхрометками, синхрометки передаем в эфир, бортовым приемником ловим их и синхронизируем выполнение пилотажной программы с музыкой )))
Первое, что приходит в голову - в качестве примитивов языка использовать каталог Арести,
Спасибо. Читаю.
добавлено: хорошая тема для диссера, кстати )))
Присоединяйтесь, тема была тут rcopen.com/forum/f90/topic273212, дисер Ваш (или Вашего сына). 😃
мне кажется, что это излишние ограничения.
Ограничение связано с продающимся железом, хотелось бы начать с простого, доступного немедленно.
также будет забавно рассмотреть процесс настройки/привязки такого типового пилотажного софта к конкретным моделям.
Это для наземного компа - проверка и перевод рисунка в байткод, допустимый для модели. Кажется, что решаемо, если есть сим и описание модели.
Байткод двигает уставки пид-регуляторов по 4-м каналам (в зависимости от времени,ориентации,скорости и т.д.) - это “как-бы ассемблер”.
на земле закладываем в ноут музончик с таймкодом и синхрометками,
А если соотнести характер мелодии и фигуры, то можно не рисовать, микрофон на борту - получится авто-танцор 😃
Присоединяйтесь, тема была тут FCL (Flight Contol Language) - пользовательский язык для управления автопилотом, дисер Ваш (или Вашего сына).
Спасибо, но присоединяться не буду т.к.:
- тема заглохла более года назад
- речь там идёт о языке для управления БПЛА, а не о пилотаже
- начинать такую разработку надо с семантики языка, а не с синтаксиса. Иначе получится монстр, что мы и видим, кстати.
- мне не нравится концепция бортового вычислителя на микроконтроллере
Это для наземного компа - проверка и перевод рисунка в байткод, допустимый для модели. Кажется, что решаемо, если есть сим и описание модели.
Байткод двигает уставки пид-регуляторов по 4-м каналам (в зависимости от времени,ориентации,скорости и т.д.) - это “как-бы ассемблер”.
я, вообще-то, имел в виду совершенно иное. А именно рил-тайм “обучение” программы фигурам, выполняемым живым пилотом на целевой модели.
Что же касается отладок, проверок и тестирования, то, конечно, без симулятора тут не обойтись. Причем, сим сгодится любой из хороших - AFPD, AF5, RF. Надо только соорудить простой, но не менее, чем 5-ти канальный генератор РРМ, управляемый, например, через USB. Сигнал с этого генератора надо заводить на вход сима как с обычного аналогового пульта. Вот тут какому-нибудь микроконтроллеру, кстати, самое место ))
А если соотнести характер мелодии и фигуры, то можно не рисовать, микрофон на борту - получится авто-танцор
получится “цветомузыка” - полная фигня не имеющая к искусству никакого отношения ))
А зачем для управления БПЛА или траекторией аппарата - язык? Достаточно просто жестко заданного вектора. Каждая точка - помимо пространственных координат, также содержит целевые показатели линейной скорости и угловых скоростей, а автоматика как может отрабатывает, чтобы аппарат максимально точно попадал в текущую точку.
Язык (программирования) - предполагает наличие условий и переходов, для описания траектории полета условия и переходы не нужны, да и не очень ясна цель? Анально-огородить (от кого?! разработчик не сделает плохого своему аппарату, а никто другой в коде колупаться не должен) код управления аппаратом - от остального кода автопилота и вообще бортового мозга? Так на практике будут постоянно вылезать исключение, которые будут требовать расширения функционала этого языка-скрипта. Проще сделать нечто типа фреймворка (по сути просто грамотное структурирование всего ПО, паттерны проектирования в помощь) - и тогда блок управления аппаратом на уровне плана полета или пилотажного комплекса - и так и сяк будет обособленным, но в тоже время будет использовать всю мощь того давно существующего языка, на котором сделан весь проект.
ИМХО, разные новые языки и скрипты актуальны лишь тогда, когда надо допускать к работе с железом фиг пойми кого с фиг пойми каким уровнем знаний и фиг пойми какими умыслами, и чтобы они ни в коем случае не могли ничего сломать - ни случайно, ни специально. Если же с системой работают только профессионалы - в топку скрипты.
для описания траектории полета условия и переходы не нужны, да и не очень ясна цель?
я говорил не столько о траектории полёта, сколько об описании выполнения фигур, в частности, 3Д. В этом случае “расколбас” может происходить практически в одной точке без перемещения по траектории.
Кроме того, при составлении, например, музыкальных шоу может понадобиться реально разное программирование и траекторий, и положений летательного аппарата применительно к точкам траектории. Особенно на предельно малых скоростях при “силовом” пилотаже.
Конечно, для описания траектории с названиями/обозначениями фигур в отдельных точках никакие условия и циклы не нужны, но для выполнения самих фигур при разных внешних условиях (погоде, например) и учете значений датчиков положения - они еще как понадобятся!
да, и еще: наверное, условия и циклы могут также понадобиться при воздушном бое для выполнения маневров атаки и уклонения ))
…не столько о траектории полёта, сколько об описании выполнения фигур, в частности, 3Д. В этом случае “расколбас” может происходить практически в одной точке без перемещения по траектории.
Так и в чем проблема? 😃 Пространственные координаты - не меняются, а меняются только целевые значения углов ориентации аппарата в пространстве.
Для пущего удобства в каждой точке добавить еще значение временного интервала, чтобы управлять плотностью точек при описании траектории. на прямых участках без маневрирования - две точки, в начале и в конце. В сложных фигурах - точки можно через каждые 10 мс поставить.
Кроме того, при составлении, например, музыкальных шоу может понадобиться реально разное программирование и траекторий, и положений летательного аппарата применительно к точкам траектории. Особенно на преде…
Это вопрос обработки и подготовки данных, а не формата записи.
…условия и циклы не нужны, но для выполнения самих фигур при разных внешних условиях (погоде, например) и учете значений датчиков положения - они еще как пона…
Учитывать погодные условия и прочие мешающие факторы - автопилот должен автоматически! Траектория для него - как точки маршрута для водителя. Ехать между точками и попадать в них - задача водителя, а не того, кто маршрут на бумажечке рисовал 😒
да, и еще: наверное, условия и циклы могут также понадобиться при воздушном бое для выполнения маневров атаки и у…
Чего уж там, надо сразу включить в скрипт библиотечку “искусственный интеллект” и функцию “нагнуть всех” 😃 Вызвал эту функцию в середине полета - бой выигран!
Пространственные координаты - не меняются, а меняются только целевые значения углов ориентации аппарата в пространстве.
ну, напишем мы “значения углов ориентации”, а как описать “что делать” для установки модели в эти значения? Причём, с учётом её предыдущего/текущего положения и скорости!
Короче, о разных вещах мы говорим.
Да и вообще, автопилоты никогда не занимались и не занимаются пилотажными фигурами. Их цель - траекторию и время обеспечить, а углы ориентации аппарата а пространстве и скорость - это средства достижения этой цели, а не сама цель.
ну, напишем мы “значения углов ориентации”, а как описать “что делать” для установки модели в эти значения? Причём, с учётом её предыдущего/текущего положения и скорости!
Короче, о разных вещах мы говорим.
Таки нет, как раз об одних вещах говорим 😉 Как именно выйти на нужные координаты (координаты - в самом широком смысле слова, а не только пространственные x,y,z) - т.е. соединить две точки некой плавной кривой - задача лет 50 назад еще решена. Всяческих интерполяционных полиномов - с десяток на выбор, выбирай любой!
Задача же “запихивания” нашего объекта управления в пределы этих параметров - задача из теории автоматического управления. Чуточку более сложная, чем ПИД-регулирование, но также не нова. Естественно будут определенные допуски точности попадания в требуемые параметры, ограничения на возможность или невозможность попасть в те или иные параметры (связанные с инертностью системы и другими мешающими факторами) - но в целом - это во-первых не нанотехнология, во вторых - не имеет отношения к способу задания самой траектории.
Да и вообще, автопилоты никогда не занимались и не занимаются пилотажными фигурами. Их цель - траекторию и время обеспечить, а …
Вот тут вообще в корне не согласен!
Как раз решаемые в настоящий момент задачи автопилотов - именно того-же самого типа, что задача полета по траектории пилотажного комплекса. С той лишь разницей, что в обычном маршрутном полете - точки расставлены с большими интервалами, отсутствуют требования по ориентации аппарата в контрольных точках (и то не всегда - точка типа “ворота” пролетается в определенном направлении, да и при заходе на полосу - углы очень даже конкретные), более широкие допуски по точности попадания в траекторию.
Задача автоматического полета по пилотажной траектории - таже самая, только точки стоят плотнее и требования к проворности и точности автопилота - более высокие. Но принципиальной (подчеркиваю!) разницы - нет.