Как вы считаете, что будет с программированием в недалеком-далеком будущем?
Вы ГАРАНТИРУЕТЕ
А вам для возможности ПРОВЕРКИ отсутсвия закладок и соотвествия поведения системы ее документации еще и от меня какие то ГАРАНТИИ нужны? Исходных текстов и собственной головы Вам недостаточно? Что такое forth система знаете? Как она описывается и устроена представляете?
Если ДА то ваши претензии и запросы несколько непонятны. И задорное “нет таких систем” по меньшей мере необьяснимо см. PS
Если НЕТ - теория заговоров это руллез ее ничем не прошибить. А был ли мальчик можно и не выяснять.
WBR CrazyElk
P.S.
Одна из замечательных особенностией forth системы кроме компактности кода это самоописываемость - система исполнения и интерпретатор языка forth описываются на языке forth за исключением очень ограниченного числа инструкций проверка коррекности работы которых уровень домашнего задания студента первокурсника.
Другая не менее замечательная особенность этой платформы это ПРОСТОТА (можно даже сказать примитивность) требований к минимально необходимому для реализации forth машины железу (реализации того самого десятка базовых инструкций). По гамбургскому счету даже Z80 больше чем необходимо. При желании процессорное ядро forth машины пишет не напрягаясь на VHDL или verilog студент третьего четвертого курса что дает свободный от закладок forth процесссор из любой более менее приличной FPGA. А при очень большом желании и немалой любви к извращениями базовый forth процессор реализуется на мелкой логике типа сумматоров, сдвиговых регистрах, триггерах и элементах и/или/не.
Исходное утверждение было - есть OS 100% доступные в исходных кодах. С этого и началось. Для Forth системы открытые и доступные для любой мыслимой проверки и анализа “исходные коды” - при желании можно довести до уровня мелкой логики. Ну нет на таком уровне контроля над средой исполнения и программирования места неучтенным закладкам. Дальше конечно можно сомневаться, а будет ли корректно работать элемент ИЛИ/НЕ и нет ли закладок в D-триггере - но это уже по ведомству психиатрии, а не программирования.
даже Z80 больше чем необходимо
Z80 обладал огромной несимметричной системой команд. Приводить его в качестве примера командного “минимализма” совершенно неоправданно.
Андрей как вы думаете получит развитие Программные конструкторы
Программные конструкторы
я не знаю, что это такое. Дайте линк на определение, плз.
Дайте линк на определение, плз.
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?) внушает мне панический ужос. Но речь о тенденции; если все перейдут на “кубики” - деваться некуда, кому надо придется писать на них. И мне кажется что так и будет.
Аркадий, Вы сравниваете несопоставимые вещи:
-
сказать “люблю ассемблер” - ничего не сказать т.к. ассемблеры является всего лишь символическим отражением системы команд и архитектур разных процессоров/контроллеров. Сколько архитектур - столько и ассемблеров.
-
Си как, собственно, язык программирования не имеет никакого отношения к Microsoft Foundation Classes (MFC) и, тем более, к .NET, последний из которых, вообще, исполняется в режиме интерпретации.
-
MFC и .NET в значительной степени и являются этими самыми “кубиками” (только не графическими), которые давно используются повсеместно.
Однако, если надо напрямую работать с физ. ресурсами аппаратуры, то чаще всего это удобнее делать на ассемблере.
Сейчас Вы не сможете в Винде даже символ в порт послать напрямую, просто не даст, начиная с Win2000 прямой доступ к железу закрыт.
Даже на микроконтроллерах и то ассемблер не требуется, все прекрасно делается на С (допускаю что иногда бывают исключения).
Более того, в условиях часто изменяющейся среды - ассемблер это зло, т.к. переносимость его крайне низка. Уже через полгода может вылезти куча граблей (и 100% вылезет) если надо перенести код на более новую платформу.
Лично я люблю ассемблер, а программирование на MFC (или что там .NET?) внушает мне панический ужос.
Написание программы под Windows на асме - будет ужас в разы больший, гигантская простыня совершенно нечитаемого и непереносимого кода 😃
Да и MFC уже устарел лет на 5-10, хотя сам на нем пишу иногда.
Сейчас Вы не сможете в Винде даже символ в порт послать напрямую, просто не даст, начиная с Win2000 прямой доступ к железу закрыт.
Даже на микроконтроллерах и то ассемблер не требуется, все прекрасно делается на С (допускаю что иногда бывают исключения).
а) я не имел в виду приложения для Windows
б) если вы пишете драйвер, то прямой доступ к железу как раз есть
в) если вы пишите код для микроконтроллера с очень ограниченными ресурсами (быстродействие и память), то кроме ассемблера выбора обычно не остается.
г) вопрос переносимости/совместимости тоже может не стоять если вы пишете, например, какой-нибудь АОН для традиционного бытового телефона с копеечным 4-х битным микроконтроллером и крошечной встроенной памятью. Кстати, компилятора с Си для него может просто не быть.
Конструкторы программ, всякие там <чтоугодно>мэйкеры и некоторые движки - не уменьшают объем работ по человеко-часам при реализации конкретной задачи.
Но само по себе создание разных конструкторов и своих сред разработки со своим рыбьим языком внутри - неплохой бизнес! Если завернуть в красивую обертку, можно подсадить на себя определенное количество людей и долго получать с них деньги. При этом - чем дольше эта система на рынке, тем больше у нее пользователей и эти пользователи никуда не могут свалить. Потому, что он изучал не Си++, который применяется везде с небольшими вариациями и похож еще на десяток других скриптов и языков, а изучал самобытную фигню, которая существует только в пределах одной конкретной среды разработки. 😃
за свою жизнь я создал несколько специализированных языков и написал компиляторы/интерпретаторы к ним. Причем, задачей было не “подсаживание” на них пользователей, а именно ускорение разработки своим же собственным коллективом программистов, которым я тогда руководил.
Причиной создания этих специализированных языков являлась оптимизация (уменьшение) количества языковых примитивов вместе с увеличением их мощности. Т.е. принцип “максимума возможностей при минимуме выразительных средств”. Вообще, это довольно сложная задача, которая по зубам далеко не всем. В частности, то “воронье гнездо”, которое получилось, например, у разработчиков платформ 1С служит прямо противоположным примером. Т.е. примером того, как НЕ НАДО делать.
Кстати, если не заморачиваться созданием специализированных языков, то во многих случаях в этом же могут помочь макропроцессоры (развитые препроцессоры исходного кода).
Аркадий, Вы сравниваете несопоставимые вещи:
Андрей, я может плохо выразился. Я имею ввиду что по мне чем язык “меньше” и “прозрачнее” тем лучше (в идеале я бы хотел программировать машину тьюринга))). И я согласен, что MFC те же кубики, и я думаю что дальше будет еще хуже)), т.е идея кубиков будет повсеместно культивироваться в том числе по маркетинговым причинам о которых говорил ADF. (Кстати, вы не заметили тенденцию писать рекламные проспекты на хардверные и софтверные инструменты разработки как будто это конструкторы адресованные детям: “Дорогой друг, в этой коробке ты найдешь все что тебе надо чтобы построить…”)
Написание программы под Windows на асме - будет ужас в разы больший,
Не про нас будет сказано - не дай Бог! я это не имел ввиду…))) (когда-то давно немного баловался простыми VxD драйверами…)