Как вы считаете, что будет с программированием в недалеком-далеком будущем?
Леонид, Вы правы, но и я тоже. Просто мы забыли провести еще одно разграничение:
- Я рассматриваю работу, выполняемую по инициативе самого разработчика
- Вы рассматриваете работу, которую разработчик выполняет по стороннему заказу
… Но отдать с трудом добытую работу какому-то подрядчику - такого я не видывал…
Работу - отдают, деньги - оставляют себе. Что тут непонятного?
Генподрядчик тоже не всегда работает за деньги:
“Из лагеря Каган попал на шарашку благодаря своему выдающемуся
остроумию. В трудную минуту, когда его изгнали с поста “заместителя старшего по бараку” и стали гонять на лесоповал, он написал письмо на имя председателя совета министров товарища Сталина о том, что если ему, Исааку Кагану, правительство предоставит возможность, он берется осуществить управление по радио торпедными катерами.
Расчeт был верен. Ни у кого в правительстве не дрогнуло бы сердце, если
бы Каган по-человечески написал, что ему очень-очень плохо и он просит его спасти. Но выдающееся военное изобретение стоило того, чтобы автора немедленно привезти в Москву. Кагана привезли в Марфино, и разные чины с голубыми и синими петлицами приезжали к нему и торопили его воплотить дерзкую техническую идею в готовую конструкцию. Уже получая здесь белый хлеб и масло, Каган, однако, не торопился. С большим хладнокровием он отвечал, что он сам не торпедист и, естественно, нуждается в таковом. За два месяца достали торпедиста (зэка). Но тут Каган резонно возразил, что сам он - не судовой механик и, естественно, нуждается в таковом. Еще за два месяца привезли и судового механика (зэка). Каган вздохнул и сказал, что не радио является его специальностью. Радио-инженеров в Марфине было много, и одного тотчас прикомандировали к Кагану. Каган собрал их всех вместе и невозмутимо, так что никто не мог бы заподозрить его в насмешке, заявил им: “Ну вот, друзья, когда теперь вас собрали вместе, вы вполне могли бы общими усилиями изобрести управляемые по радио торпедные катера. И не мне лезть советовать вам, специалистам, как это лучше сделать.” И, действительно, их троих услали на военно-морскую шарашку, Каган же за выигранное время пристроился в аккумуляторной, и все к нему привыкли.”(С)
Полностью - тут: www.lib.ru/PROZA/SOLZHENICYN/vkp2.txt
Давно фирмварь интеловских процов вошла во все OS и платформы без разбору. Бедный бедный Linux на ARM. Как ему боротся с фимварью интеловских процов ну вот скажите как - ума не приложу.
Вам Forth систему в исходных кодах для микроконтроллера подарить?
Вы ГАРАНТИРУЕТЕ, что там нет ошибок, в этом форте? Зуб даете, жизнь положите? Да и отсутствие известных косяков на армовом ядре не заслуга арма и линукса, а нераспространенность этой комбинации в сравнении с х86. И не надо мне ничего говорить про андроид.
Вы ГАРАНТИРУЕТЕ
А вам для возможности ПРОВЕРКИ отсутсвия закладок и соотвествия поведения системы ее документации еще и от меня какие то ГАРАНТИИ нужны? Исходных текстов и собственной головы Вам недостаточно? Что такое 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, хотя сам на нем пишу иногда.