Search in topic

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

Программные конструкторы

я не знаю, что это такое. Дайте линк на определение, плз.

Дайте линк на определение, плз.

qiqer.ru/konstruktory-programm.html, fiks-ru.net/forum/13-112-1
Алгоритм, HiAsm,Mess Box DVI v.4.5

Приводить его в качестве примера командного “минимализма” совершенно неоправданно.

Я его дал не как пример минимального процесора, а как одну из изученных вдоль и поперек древностей с миикроскопическим числом ресурсов. Древность в которой закладкам и “открытиями” особых режимов работы места уже давно нет. И даже этой древности за глаза достаточно для построения рабочей forth платформы. RISC-и естественно проще по набору команд, но боюсь для “целевой аудитории” сомневающейся в достаточной документированности и предсказуемости железа Sparc или MIPS аргумент еще меньший чем z80. И честно говоря что не назови хоть Z80 хоть 8080 хоть AVR хоть … думаю бесполезно - для сомневающгося “не аргумент”

Это все к паре

• есть OS 100% доступные в исходных кодах.
• нет таких платформ.

…Алгоритм, HiAsm,Mess Box DVI v.4.5

Дас ист колоссаль 😃 “Kак стать программистом-конструктором за 10 минут”. ЕГЭ на сайте и сертификат в конце первого дня обучения 😃 …

Андрей как вы думаете получит развитие Программные конструкторы

Этой идеии и различным ее реализациям лет уже двадцать как (первая с которой работал SQLWindows от GuptaTechnologies). Все развиваются. Но никак не разовьются. 😃

На определенном этапе и для опреденной аудитории такие конструктроры вполне неплохая игрушка. Но именно игрушка для для начинающих в рамках маленьких и простеньких задачь. Начиная с некотрого уровня сложности (очень очень невысокого) и графическое представление действий становится похожим на паутину и выясняется что написать тоже самое но кодом быстрее и удобнее. Кроме развлекательно обучающего направления сейчас подобные констукторы рисовалки в основном встречаются и используются для описания процессов на ESB (Enterprise Service Bus - интеграционная шина предприятия) и во всевозможных BPEL (WS-BPEL) (Buisness Process Execution Language) рисовалках процессов. Что назвается - для менеджеров. Иногда для прототипирования или быстрой автоматизации несложных процессов бывает удобно. Но именно иногда и для несложных.

Основной недостаток
Шаг в лево шаг в право расстрел на месте, прыжок на месте првокация. Набор доступных компонент и степень их гибкости решает все. Отсюда классическая проблема 33. Компоненты/адаптеры массово никто не пишет посколку решания массово почти никто не использует, никто неиспользует решения покольку набор компонент слишком беден и недостаточно гибок.

Классический мой вопрос к производителям подобных решений (в рамках задачь ESB и WS-BPEL) - а как вы предлагаете в рамках вашего решения взаимодествовать с системой управлемой исключительно по telnet протоколу. В 90 процентах случаев - тут такое начинается (telnet компоненты нет практически ни у кого, а полноценную эмуляцию протокола проще и быстрее сделать на обычном языке)

Самой успешным, сбалансированным и полезным (на мой взгляд) из подобных конструктров “для всех и каждого” был Visual Basic. Принцип по существу тотже - сборка программы из готовых компонент с минимальным допиливанием в виде программного кода или параметризации готовых компонент (при адкватном подборе под решаемую задачу набора компонент). А отсутсвие в нем бантиков ака квадратики по сути означющих a= b*c это скорее достоинстово чем недостаток.

WBR CrazyElk

Если же продукт изготавливается в единичном экземпляре, то лицензировать деятельность (работу) разработчиков невозможно.

Эмм, я лично не вижу противоречия… Вполне можно сертифицировать производство, которое произведёт продукт в единственном экземпляре. Другой вопрос только в том, что это заметно дольше и дороже. Но всё равно я вижу реальную возможность развития событий:
-разработали продукт (о боже, какой-классный-крутой-навороченный)
-сертифицировали производство (под конкретного клиента, обещал купить 100500 лицензий).
-продали 1 экземпляр конкретному клиенту.
-финита ля комедия, продукт устарел, клиент отпал, банкротимся господа.

qiqer.ru/konstruktory-programm.html, fiks-ru.net/forum/13-112-1
Алгоритм, HiAsm,Mess Box DVI v.4.5

ах, это…
Все эти конструкторы предназначены для ОЧЕНЬ узких классов задач.
Пока что они не представляют серьёзной альтернативы традиционному программированию на языках с символическим алфавитно-цифровым синтаксисом и семантикой.

Андрей спасибо за ответ. Да ,Вы правы, но намой взгляд развитие таких программ получит в ближайшие 5-7 лет. Программировать на низких уровнях становится все сложнее с каждым годом (рост возможности железа, появление новых протоколов связи и т.п.) Создание мало-мальски приемлемых современных программ становятся уделом коллективного творчества. Хотя нельзя откидывать фактор гениальности.

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

Однако, при этом никуда не исчезает вопрос создания самих этих “кубиков” и низкоуровневого программирования как такового. В этих случаях необходимость в традиционном программировании на символических языках встаёт в полный рост. Заменить другими “кубиками” эти виды программ не удастся.
Всё это всегда называлось “системным программированием” и невозможно себе представить, что эта профессия исчезнет ))

Моя жена когда-то, если ее разбудить ночью, мгновенно переводила шестнадцетеричное число в двоичное, и читала перфокарты как по нотам!
А сейчас очень мало кто опускается ниже Си. Возможно что скоро и “системное программирование” будет на кубиках…

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

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

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

Лично я люблю ассемблер, а программирование на MFC (или что там .NET?) внушает мне панический ужос. Но речь о тенденции; если все перейдут на “кубики” - деваться некуда, кому надо придется писать на них. И мне кажется что так и будет.

Аркадий, Вы сравниваете несопоставимые вещи:

1. сказать “люблю ассемблер” - ничего не сказать т.к. ассемблеры является всего лишь символическим отражением системы команд и архитектур разных процессоров/контроллеров. Сколько архитектур - столько и ассемблеров.

2. Си как, собственно, язык программирования не имеет никакого отношения к Microsoft Foundation Classes (MFC) и, тем более, к .NET, последний из которых, вообще, исполняется в режиме интерпретации.

3. 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…
Не надо забывать также и о том, что интерпретатор вряд ли сможет обеспечить приемлемый рил-тайм для стабилизации и автопилота. Нужна какая-нибудь вполне стандартная начинка с элементной базой экономичного, но вполне производительного нетбука.

еще добавлено: также будет забавно рассмотреть процесс настройки/привязки такого типового пилотажного софта к конкретным моделям. Что-то вроде процесса “обучения” софта в руках опытного пилота на целевой модели. Еще одна тема для диссера ))

и напоследок: на земле закладываем в ноут музончик с таймкодом и синхрометками, синхрометки передаем в эфир, бортовым приемником ловим их и синхронизируем выполнение пилотажной программы с музыкой )))