Как вы считаете, что будет с программированием в недалеком-далеком будущем?
Андрей спасибо за ответ. Да ,Вы правы, но намой взгляд развитие таких программ получит в ближайшие 5-7 лет. Программировать на низких уровнях становится все сложнее с каждым годом (рост возможности железа, появление новых протоколов связи и т.п.) Создание мало-мальски приемлемых современных программ становятся уделом коллективного творчества. Хотя нельзя откидывать фактор гениальности.
Дмитрий, я тоже думаю, что прикладное программирование рано или поздно придёт к “складыванию программ из кубиков” - неважно какими они будут - плоскими или трёхмерными.
Это вполне закономерный процесс, который, с одной стороны подобен переходу от дискретных компонент к микросхемам (причем, всё более крупным), а с другой стороны в самом программировании мы наблюдаем мощные тенденции к использованию типовых решений и блоков. Современные программы, вообще, давно уже создаются “по типовым скелетонам” для выполнения системных требований. При этом, “молитв” (или “костей”) в них зачастую чуть ли не больше, чем “мяса” - авторского кода.
Однако, при этом никуда не исчезает вопрос создания самих этих “кубиков” и низкоуровневого программирования как такового. В этих случаях необходимость в традиционном программировании на символических языках встаёт в полный рост. Заменить другими “кубиками” эти виды программ не удастся.
Всё это всегда называлось “системным программированием” и невозможно себе представить, что эта профессия исчезнет ))
Моя жена когда-то, если ее разбудить ночью, мгновенно переводила шестнадцетеричное число в двоичное, и читала перфокарты как по нотам!
А сейчас очень мало кто опускается ниже Си. Возможно что скоро и “системное программирование” будет на кубиках…
Си - прекрасный язык, мой самый любимый ))
“Опускаться” до него не надо - на нём надо мыслить и “разговаривать” - изъясняться. При определенном складе ума это очень удобно и получается естественным образом - как дышать ))
Однако, если надо напрямую работать с физ. ресурсами аппаратуры, то чаще всего это удобнее делать на ассемблере. Но практически все современные компиляторы допускают возможность прямой вставки ассемблерных кодов в программу на Си при выполнении определенных правил передачи параметров. Поэтому это тоже обычно не вызывает затруднений.
С другой стороны, если мы пишем программу, предназначенную выполняться в определенной среде (ОС), то вынуждены пользоваться стандартными системными библиотеками и дефинициями. Вот тут нас может подстерегать множество самых различных каверз и ловушек…
Лично я люблю ассемблер, а программирование на 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. Сигнал с этого генератора надо заводить на вход сима как с обычного аналогового пульта. Вот тут какому-нибудь микроконтроллеру, кстати, самое место ))
А если соотнести характер мелодии и фигуры, то можно не рисовать, микрофон на борту - получится авто-танцор
получится “цветомузыка” - полная фигня не имеющая к искусству никакого отношения ))
А зачем для управления БПЛА или траекторией аппарата - язык? Достаточно просто жестко заданного вектора. Каждая точка - помимо пространственных координат, также содержит целевые показатели линейной скорости и угловых скоростей, а автоматика как может отрабатывает, чтобы аппарат максимально точно попадал в текущую точку.
Язык (программирования) - предполагает наличие условий и переходов, для описания траектории полета условия и переходы не нужны, да и не очень ясна цель? Анально-огородить (от кого?! разработчик не сделает плохого своему аппарату, а никто другой в коде колупаться не должен) код управления аппаратом - от остального кода автопилота и вообще бортового мозга? Так на практике будут постоянно вылезать исключение, которые будут требовать расширения функционала этого языка-скрипта. Проще сделать нечто типа фреймворка (по сути просто грамотное структурирование всего ПО, паттерны проектирования в помощь) - и тогда блок управления аппаратом на уровне плана полета или пилотажного комплекса - и так и сяк будет обособленным, но в тоже время будет использовать всю мощь того давно существующего языка, на котором сделан весь проект.
ИМХО, разные новые языки и скрипты актуальны лишь тогда, когда надо допускать к работе с железом фиг пойми кого с фиг пойми каким уровнем знаний и фиг пойми какими умыслами, и чтобы они ни в коем случае не могли ничего сломать - ни случайно, ни специально. Если же с системой работают только профессионалы - в топку скрипты.