Не воспринимайте эту статью слишком серьёзно. Это одна большая метафора, которая позволяет взглянуть на вещи под другим углом.
Не будем. Давайте вообще закроем глаза на любые несоответствия аналогии языков с видами, как будто этого не было даже в заголовке статьи, и пройдёмся по всем остальным фактам.
Сразу отмечу, что вывод, что большинство языков похожи на живые системы, вполне неплох, вполне соответствует материальной действительности. Остальные выводы также фактически верны, однако по-моему этого недостаточно - попробуем рассмотреть это подробнее.
Что такое "среда, формирующая язык программирования"? Можно абстрактно сказать, что это "изменения, в которых участвуют буквально все", а можно прямолинейно сказать, что средой, формирующей язык программирования, является процесс разработки на этом языке, работа на этом инструменте. Откуда возникли перечисленные требования к "выживанию" языков программирования?
* отсутствие привязки к конкретной платформе;
* простота для пользователей, отсутствие лишних деталей (их обработкой занимается машина)
* возможность заметить и обработать ошибки в коде
* нефатальность ошибок для всей системы и др.
А это ничто иное, как требования к разработке. Притом некоторые из них, по мнению "отцов-основателей" Computer Science, абсурдны, но они здесь перечислены: например, необходимым требованием к языку программирования названа "нефатальность ошибок для всей системы", которая противоречит принципам доказательного программирования, и вообще дейкстровскому "Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения". Почему так получилось? Да потому что проще, просто дешевле производителю пользоваться языком, в котором ошибки рядового кодера нефатальны, чем математически доказывать корректность кода, или хотя бы писать код настолько иерархически определяя его и используя определения настолько кратко, насколько это вообще возможно (в том же Форте существует "правила хорошего тона", которые "не рекомендуют" использовать более 7 слов при определении нового слова - в результате приходится писать иерархии слов), и тут же проверять этот минимальный фрагмент на корректность.
"Простота для пользователей, отсутствие лишних деталей" является справедливым требованием, абсолютная правда: однако "отсутствие лишних деталей" предполагает наличие неопределенности в системе (то есть сказав при решении какой-то задачи слово "медведь", ну как на иллюстрации в статье, мы не уточили, белый или бурый - значит, это либо не имеет значения, либо напрямую следует из контекста), а следовательно для неопределенности необходима поддержка трёхзначной логики. Таких возможностей нет у большинства рассмотренных языков, трехзначность там представлена в архитектуре языка неявно (хотя декларируется при этом, что в ЯП явное лучше скрытого). К слову, данное требование в совокупности с игнорированием семейств Лисп и Форт и их наследием, уже вовсе выглядит как издевательство: ведь именно в этих языках можно без проблем создать свои языковые конструкции специально под свою задачу (или даже написать свою особенную реализацию языка под свою задачу) и действительно не отвлекаться на "лишние детали" даже в виде стандартных операторов языков программирования; более того, возможности метапрограммирования позволяют вообще уйти от рутинного написания кода к его автогенерации.
Однако такая простота находится в меньшинстве: ярким примером "простоты" для пользователя принято называть шаблоны C++, которые сами по себе являются ни много ни мало тьюринг-полным языком программирования. Простота нужна не для удобства программирования, не для ясности решаемой задачи, не для предотвращения внесения новых ошибок, а для максимально быстрого запихивания кода в прод при максимально возможно низкой квалификации кодеров - это та же проблема разработки.
Что же касается первого требования (отсутствие привязки к конкретной платформе), то оно противоречит фактам; даже фактам, перечисленным в статье. "Быть ближе к железу" в отношении C, который перечислен как достоинство этого языка по отношению к Паскалю, это как раз близость языка C к конкретному железу, просто очень популярному и простому (если быть предельно точным, к компьютерам PDP-11). Паскаль же к тому моменту располагал P-кодом (portable), очень напоминающим виртуальную машину Java. Не сходится. В качестве другого примера отмечу, что ядро Linux в ранних его версиях критиковалось именно за четкую ориентацию на ранние архитектуры семейства x86. Так сложились обстоятельства, что в течение почти 10 лет бурного роста компьютерной техники (2000ые) x86 была по сути абсолютным монополистом.
Почему C "уничтожил" Паскаль? В системном программировании виртуальные машины не очень пригодятся, а написание кода на "близком к железу" языке позволяет использовать больше вычислительных возможностей даже очень дешевых машин. C++ усугубил эту ситуацию, поскольку позволил писать на языке, близком к ассемблеру, прототипируя приложение на продажу в концепции ООП. При этом с точки зрения чистого ООП C++ не пользуется наверное ни одним преимуществом этого языка. Однако, он позволяет быстро разделить труд проектировщиков и кодеров, создавать программы не под конкретные задачи (которые постепенно усложняются), а под неопределенно широкий круг задач, создавать коммерческий софт, "софт как товар".
Приведу пример: при автоматизации советского Госплана к каждому инженеру-расчётчику приходил программист, беседовал с ним о решаемых им задачах, создавал инструмент, который выполнял все рутинные операции, чтобы можно было перенаправить работника на иную, более сложную и творческую, работу в этом же направлении. 70% полученного кода - это решение задач уровня "эксель", 30% - это различные достаточно сложные операции, которые расчётчики в том числе могли производить с применением "инженерной прикидки" и так далее, которые не решаются экселем (в базовом владении данным инструментом). А другой путь - это как раз купить условный MS Office Excel, который в сущности и автоматизацией не является, просто позволяет нанять менее клафицированного сотрудника для решения тех же задач, на выполнение настолько же рутинных (если не более рутинных) действий, просто более простых. Собственно, если в "мёртвых" языках Lisp и Forth есть возможность метапрограммирования (генерации программ программами, чтобы как раз можно было уйти от "рутины программирования") изначально, то во всех потомках C++ (о которых и идёт речь далее) эта возможность прикручена как "костыль", т.к. она противоречит модели языка.
Так и получается: если в 80-90ых написанный софт будет работать на слабеньких PC, то его закупят. А если софт при этом окажется на рынке раньше всех и он будет не настолько плох, чтобы от него отказывались, то он завоюет рынок. Так что это не C++ и его потомки победили всех остальных потому что "крутой язык", это компании которые практиковали С++/потомки C++ выкупили всех остальных. А дальше эту ситуацию уже можно заменять фразой "так сложилось исторически", не рассматривая произошедшего.
Я это к чему: эволюция языков программирования безусловно есть. Проблема в том, что большей частью отбор происходит не по объективным свойствам того или иного языка, а по требованиям к процессу разработки, по существующей конъюнктуре рынка софта и рынка IT-труда. Язык (или компьютерная архитектура - такое произошло, например, с легендарной "Сетунью" и массой других проектов советской школы микроэлектроники, убитых стандартизацией советской микроэлектроники по IBM - лидеру американского рынка) может обладать впечатляющими возможностями, быть достаточно удобным для разработчиков и прочих пользователей, но тупо "не вписаться". А потом люди будут писать, что технология X просто "обогнала время" и должна была появиться позже. Нет, она появилась скорее всего когда надо, просто прогресс в этой технологической области был предельно заторможен, пока "происходила вроде как эволюция, велись скрещивания, ..."
Похоже, "форты" выбиваются из этой теории "эволюции", ведь сам факт рождения этого языка два раза - независимо Чарльзом Муром и Эдсгером Дейкстрой - уже ближе не к эволюции, а скорее к научному открытию, подобно изобретению радио Маркони и Поповым. (Пускай первый пришёл к Форту из практических соображений, а второй к форт-архитектуре пришёл скорее из теоретических сообщений)
Самое интересное, что потомком Форта являются не только "форты", но и эзотерический FALSE, который фортом не является.
Такое ощущение, что чтобы выдвинуть теорию эволюции языков программирования, нужно было продемонстрировать лишь "подходящие" языки программирования
Отдельное спасибо за восстановление недописанной статьи Криса Касперски "Два слова о трёхзначной логике"! Надеюсь, будут ещё восстановленно-неопубликованные материалы от мыщъх'а, причем посвященные не только взлому и ИБ, но и всему будущему IT (если таковые материалы, конечно, ещё есть).
Собственно, с этой статьи начал знакомиться с его творчеством - до этого просто никого не знал, потому что новичок :) (И конечно жаль, что, по всей видимости, многое уже устарело...)
"этого глупца" - Вы про Криса Касперски или Николая Брусенцова? есть ли аргумент для данного утверждения, или это и есть Ваш аргумент?
"новомодными" - Вы про статью, вышедшую в 2007ом, или про книгу, вышедшую в 1985? А может, просто если не придерживаться "столпов", то окажется, что "новомодное" метапрограммирование на самом деле могло быть актуально всегда, а сейчас его ввели в моду потому что спустя столько лет стало наконец просто понятно, что без него просто не справиться со всей "красотой" бесконечных (и нарастающих подобно фракталу) уровней абстракции, которые получены согласно "столпам"?
"скажи это программистам из Microsoft" - спасибо, но в той же мере, в которой Вы считаете количество кода и программ аргументом. В Microsoft пишут на том, на чём в Microsoft скажут. Так что в таком случае Вы можете сказать что-то в корпорации SAP (где до сих пор пишут не на "коболе 90ых", а на вполне несколько осовремененном, но всё же "том самом" коболе). К слову, именно этот язык может похвастаться как заоблачным количеством кода, написанным на нём, так и массовостью применения в своё время.
В целом да, но при специфическом кодстайле по-моему возможны исключения.
Если почти весь код выстроен вокруг проверок и действий по проверке (проверить аргумент и выйти из функции с кодом возврата ошибки или скажем изменить значение счётчика при условии), на мой взгляд вполне оправдано пользоваться условием как раз без переноса строки и фигурных скобок:
if (cond) return handler();
Аналогия с командами по предикату - в ассемблере x86 это условные переходы, только тут это будут возвраты в функции, в ассемблере ARM для предикатов существует, если не ошибаюсь, полноценная система исполнения на любой команде.
Причем важно, что лучше всего запись именно без переноса строки и фигурных скобок одновременно. Фигурные скобки тут просто мешают читаемости, а перенос строки и написание кода "а-ля Python" может очень сильно обмануть, если вдруг придётся тело условия расширить.
Ну а "стандартный" вариант в стиле классического С это 4 строки, в стиле Java - 3, что очень сильно разреживает код и (имхо) рассредотачивает внимание, т.к. очень серьезно отличается по плотности кода от последовательностей операторов в одном блоке кода (ср.: 1 выражение на 1 строку vs 1 выражение на 3-4 строки).
Отдельно замечу, что циклов этот приём не касается (там лучше помириться с телом на 3-4 строчки, чем проморгать что-то не то)
Имеет смысл по крайней мере правильно финализировать работу программы - освободить ту память и прочие ресурсы (файлы), которые уже были заняты. В противном случае при первой же попытке работать с такой программой в автоматическом режиме (например, при помощи скрипта на bash), например вызывать её до первого успешного исполнения (то есть до экзит-кода 0), мы легко можем получить проблемы уже в пользовательской системе.
Я очень удивлён что "моддеры" XP вообще никак с ReactOS не взаимодействуют, хотя у нас полно всего что они решают всевозможными хаками. Например, полноценный KMDF фреймворк портированный из Windows 10.
Моддеры, насколько мне известно, в известной степени "гарантируют" работоспособность получаемых систем. Естественно, всегда есть пилотные версии, надо же как-то развиваться. Но в целом, например, как уже отмечал выше, до сих пор не побеждены абсолютно все контроллеры USB3.0, так как моддеры исследуют совместимость acpi.sys и драйверов USB из Windows 8.1 (отличия есть даже между 8.0 и 8.1) - без доказательств, что такое вообще возможно, "главные модеры" и не собираются начинать пытаться. А в ReactOS, извините, но иногда "спешат" с выводами. Это нормально - система в альфе, запускается большей частью в виртуалках, ... . XP mod не могут себе позволить такой роскоши, как баги - практически все системы у всех работают на реальном железе (поскольку в виртуалках можно запускать оригинальную XP)
А зачем вообще "обычные" люди допиливают XP для работы на современном железе? Какой сценарий использования, почему бы не взять более новую Windows 7 например?
Нет потребностей в более высоких версиях ОС Windows, вот и всё, и при этом возможно есть потребность в обратной совместимости и/или легковесности. Вот я, будучи студентом, могу сказать, что из всех используемых программ у нас есть одна (проприетарная CAD система), которая не запустится на XP, и несколько (штуки три минимум), которые будет достаточно сложно завести на (например) 10ке, но которые могли бы без проблем работать на XP, а остальным в целом "всё равно на чём работать". Учитывая, что большая часть программ профессиональная, думаю, что на рабочем месте ситуация не будет принципиально сильно отличаться.
Кто-то идёт в XP за звуком (аудиочувствительные люди говорят, что высочайшее качество звука на XP), кто-то (как я) за возможностью работать с продвинутыми планировщиками задач вроде nnCron (по близкой причине: система достаточно легкая, сравнительно предсказуемая, а потому всё работает как бы в пределах мягкого рилтайма; плюс в след.версиях кастомные планировщики задач начали постепенно зажимать*, пока окончательно не выпнули в десятке), ...
* В принципе, наверное, правильно поступили: технически безграмотный человек (коих за компьютерами всё больше) может не уловить, что за службы у него там фоном крутятся, и через них в принципе действительно можно осуществлять злонамеренные действия по отношению к пользователю. В мире свободного софта это решается форками: вот arch, вот ubuntu, вот void, ... . Однако у Windows сейчас монополия на Win32-среду (среду исполнения огромного количества программ), а значит прямо сейчас чем-то вроде "форка" в принципе может быть именно даунгрейд на XP
А на любую критику отвечать «Ну оно же работает!». В моменте - да, работает. На длинной дистанции - нет.
Так оно на длинной дистанции и не работает, по крайней мере сейчас (например, технический прогресс затормозился в край). Кого это волнует (из менеджеров)? Правильно, никого. "Долгосрочной перспективой", если я правильно помню, по меркам компаний в условиях рыночного хаоса, считаются 10-20 лет.
а в чем выражается эффективность?
В прибыли. Сколько удалось её извлечь, удалось ли избежать убытков и так далее. Это может быть формализовано через KPI, но суть-то всё та же - максимизация прибыли производства для расширения возможностей расширения бизнеса, стабилизации положения предприятия в занятой на рынке нише, максимизации дивидендов владельцев, и так далее.
На мой взгляд есть только один объективный показатель эффективности любого биологического индивидуума - его активное продолжение рода. И в этом плане, эффективнее любого абстрактного чубайса наши юные соседи.
По такой логике курицы наравне с людьми (по численности получается так), а кролики одной только Австралии всего лишь в несколько раз хуже всего человеческого вида на планете. Тем не менее, почему-то люди завезли кроликов в Австралию (не наоборот), а большинство куриц живёт в неволе и люди ими просто питаются. Вопрос сравнения животных с людьми не корректен в принципе, так как человек из всех биологических видов уникален тем, что серьезно и "направленно" изменяет окружающую среду под себя. (Кстати говоря, человек для этого прикладывает усилия, и реализует их через предприятия, прибыльность которых и максизируется и заставляет менеджеров считаться "эффективными"*)
А из этого следует также, что эффективность распространенения человеческого вида (в количестве, сейчас это почти 8млрд человек) росла не по биологическим причинам, а по технологическим. В демографии это выражается не рождаемостью, а продолжительностью жизни.
*Можно спорить о том, действительно ли такой подход эффективен для всего человеческого вида в целом - может быть да, может быть и нет, но для собственников производства, на котором действует эффективный менеджер (или которым он может просто являться), это точно можно считать адекватным показателем эффективности.
Возможно. Раньше был WooS, но сейчас это скорее (взгляд человека со стороны) "война лицензий" и способа разработки. Та же Windows XP может быть на данный момент установлена на современный компьютер (существуют патчи acpi.sys, возможна интеграция драйверов sata ahci, а также usb3.0 в целом поддерживается*), но XP продолжает оставаться закрытым и несвободным ПО, за нелицензированное использование которой ("без наклеек") предприятию в принципе может прилететь по шапке и у которой есть серьезные изъяны в плане поддержки нового закрытого софта, который безусловно уже сейчас есть и которого со временем может стать только больше.
*По usb3.0: по состоянию на сегодняшний день поддерживается почти всё, кроме нескольких контроллеров, выпущенных для windows8.1+ и не поддерживающих windows8.0. Не доказано, что эти контроллеры в принципе могут работать со старым acpi.sys
И хотя решено очень многое, уже сейчас патчеры windows xp сталкиваются с определенными сложнорешаемыми затруднениями, например: установка на компьютеры с pure UEFI (не помню, удавалось ли его как-то обмануть, UEFI/CSM точно уже бэкпортнули из висты, а вот с pure UEFI совсем не уверен). Библиотеки или ещё одна подсистема wow (windows-on-windows) для запуска приложений скопилированных для vista/7/...
По второй проблеме: конечно, средний пользователь windows xp 2021 edition консервативен, но всё же есть некоторые приложения, которыми надо пользоваться, но не выйдет или будет сложно (прежде всего, это касается клиентов интернета: вот если Zoom для XP есть вполне официальный, то вот Microsoft Teams вряд ли; последние версии скайпа, которые идут на xp, по-моему поддерживаются, но это вопрос времени, когда перестанут, и так далее). Проблем с открытым софтом конечно сильно меньше, его всё равно в крайнем случае всегда можно попробовать пересобрать из исходников, но далеко не весь обязательный к использованию (в смысле, в реальной жизни - на работе, в учёбе) софт поддерживается XP, это к сожалению факт. Естественно, эта же ситуация отчасти касается и драйверов.
ReactOS вроде как должен решить эти в каком-то смысле родовые проблемы, и даже существует подпроект OneCoreAPI, который, если мне не изменяет память, подменяет части ядра Windows XP частями ядра ReactOS... (Ну, надеюсь не нужно уточнять, что эта вещь заметно более сырая, чем даже сам ReactOS.)
Лично мне самому не вполне понятны некоторые моменты с ReactOS:
От версии к версии Windows не только экстенсивно наращивала кодовую базу, но и наверняка частично рушила обратную совместимость в "мелочах" вроде поведения API, библиотек и конечно же политики безопасности (Безотносительно вопросов, делалось это осознанно или просто не учли - просто есть такой момент). Вопрос очевиден: если ReactOS в проекте намерена поддерживать всё оборудование и софт, то каким образом это можно реализовать?
Касаемо запуска с compactFlash-карты - как челленндж конечно круто, но если мне не изменяет память, в ReactOS до сих пор нет простого способа установить ReactOS с флешки. Конечно, это очень хороший "цензор" для "ниасиливших" (вроде меня - void linux и devuan устанавливаются стократ проще, чем reactos на флешку с ramdisk), но уточню, что в итоге это скорее всего серьезно урезает количество потенциальных тестеров. [как мне кажется, возможно я ошибаюсь, но по-моему сейчас DVD есть либо в ПК, на которые ReactOS точно не встанет, либо на старые ПК, которые и под XP или даже 98se отлично себя чувствуют]. Уточню, что здесь наверное могу быть не прав.
Ну, вот Крис Касперски считал, что проблема Форта в том, что его парадигма плохо уживается с корпоративным миром софта. Он её просто не обогнал.
Что касается ООП, то на мой взгляд в 80-90ых вокруг ООП был в опредёленной мере хайп, а в определённой мере C с классами (назовём C++ своим изначальным именем) был нужен, чтобы, обеспечив переносимость и быстродействие как у C, обеспечить и скорость разработки. Тут уместно вспомнить ООП-системных аналитиков, и думаю что вот как раз их работа от "плюсов" и пошла.
Допустим, некоторая корпорация (например, "Крупнософт" или "Турланд") делает СУБД/офисный пакет/IDE с кучей фич, ... но который должен запускаться на компьютере, на котором памяти столько, что "всем должно быть достаточно", как (не?) говорил один известный бизнесмен, а процессор вообще такой, что с памятью можно даже сказать всё нормально... И вот в таком случае как раз на помощь спешит "C с классами": классы в нём чтобы писалось быстрее, а C чтобы можно было быстро допилить критические места на ассемблере, и в итоге софт работал даже на "печатной машинке". То есть часть "плюсовый" ООП был на месте современного фронтенда, где главное быстро запрототипировать а что мы вообще делаем, а "начинка" в виде наследия языка C (от которого постепенно отдалялись) - на месте бекенда
Вспоминается, что когда-то основатель Smalltalk заявил что-то в духе "Когда я говорил про ООП, я не имел ввиду C++". Наверное, сама концепция интересна, но наверное эта тема перегрета - индустрии в ООП было интересно несколько другое. Кстати, технических преимуществ, вроде того же масштабирования объектов на несколько процессоров, тогда в ООП и не взяли (в C++ существует один вариант вызова сообщений: по сути, это просто вызов функции C), а обратно трепыхаться (и смоллтолку, и C++) уже наверное поздно (но каждому по своим собственным причинам)
Да, слышал про Дейкстру. Насколько я помню, его вычислитель отличался ещё словом E, который Мур, когда ему показали эту систему, посчитал очень непрактичным. Возможно, были ещё какие-то недостатки. А может Дейкстра с самого начала увидел несовместимость форта с развивавшейся на тот момент индустрией, и именно поэтому и назвал его "непрактичным". А возможно, что просто Дейкстра просто очень хотел увидеть в этом вычислителе теоретическую ценность, в то время как Мур создавал Форт именно программируя на нём. Кстати, на мой взгляд, наверное какая-то теоретическая ценность есть, потому что это похоже на открытие. Хотя можно сказатть, что Попов и Маркони радио именно изобрели (... но попутно открыли целую область техники)
Да, нагуглили не то: гуглить в данном случае нужно было Оберон.
Что касается фундаментальности, то тут может быть интересно то, что называется собирательным термином оберон-технологии: грамотное проектирование обыкновенного, классически построенного софта и железа, как их грамотно соотнести (язык, операционную систему и "железо"). Всё это было сделано (то есть и язык, и операционная система, и железо) "с нуля", особой оригинальностью каждое в отдельности конечно не отличалось, но, по мнению разработчиков, может быть охвачено и осознано одним отдельным человеком целиком, без дополнительных инструментов.
(Таким образом, разработчики считают, что ушли от проблем "необъятного" софта и железа. И если бы к разработчиков к "излишней" абстрактности программ, а затем к бесконечным прослойкам на прослойках, толкало бы только "основание" всей этой системы, имели бы место только претензии Брусенцова (см.первый комментарий этой ветки, точнее продолжение в той же ветке про вторую теорию), то вопрос был бы снят. Но в чем я очень сомневаюсь, что в Обероне удалось развить метапрограммирование (претензия к классическим архитектурам и конкретно языкам уже от Криса Касперски) - а значит, проблема "необъятности" скорее всего снова появится при разработке уже второго поколения программ.)
Впрочем, в любом случае, минимальность обычно интересует, если вы используете язык для анализа метатеоретических свойств некоторой системы. Что анализировали с паскалем?
Если мне не изменяет память, именно паскали и можно использовать для доказательного программирования, и по-моему поэтому классический Паскаль используют в той же ракетной технике. (Причем валидация не модели программы, а собственно самой программы, что она точно не содержит ошибок). Но это, конечно, если память не изменяет.
Но повторюсь, минимальность важна не только тем, что посредством неё можно доказывать всякое математически - общая идея была как раз покончить с некачественным проектированием, показать "как надо"
Фундаментальная наука, в отличие от молока и прикладной науки, не скисает со временем. Так что статус исторического тут не очень мешает.
Что касается интересного, то паскалоиды отличаются минимальностью (в том числе грамматической) в рамках классических языков программирования. Чего-то принципиально отличного в них (в отличие от Форта или Лиспа, которые в какой-то степени "зеркальны" - кстати, Крис Касперски писал не только о Форте, но и о Лиспе, я лишь сократил пересказ), на мой взгляд, нет, но всё же 1) определённые исторические заслуги у Вирта и его разработок есть, 2) плюс оно чуть выгоднее выделяется на фоне того же самого современного софта, о котором идёт речь (повторюсь, пока не узнаёшь про что-то принципиально другое).
... Собственно, как мне лично кажется, сам Вирт пытался сделать что-то похожее на Форт или Лисп (например, языком с минимальной грамматикой является Форт, а Лисп, как Вы же и отметили, уже имел сборку мусора), но по каким-то своим причинам для него необходимо было остаться в рамках классических алголоподобных языков.
Сейчас закончил (вторую часть отправил как ответ первому комментатору), спасибо за интерес
В целом согласен, но у таких всегда есть "аргумент" - "за фреймворки Javascript [например] зато платят, и платят много". Хотя как аргумент научно-технического спора это выглядит максимально неубедительно, но ведь в конце концов это же самое суждение можно замаскировать в менее очевидные формы, например "а почему тогда на Паскале/Модуле/Обероне программируют 2.5 человека на зарплатах в НИИ, а остальные разботчики от этого ушли?".
И поскольку мнение "ориентированных на индустрию" достаточно влиятельно (в конце концов, на то она и индустрия), а широкой аудитории не всегда известно, как открытия и разработки Вирта повлияли лично на них (а тут как минимум привет языку Java: байт-код и GC, первое родственно П-коду, второе по крайней мере родственно обероновскому GC), то на всякий случай уточнил
(как всё-таки жаль, что на Хабре нельзя изменять свой комментарий, даже если проходишь премодерацию, и отменять отправку в течение первых N секунд)
А вторая теория выстроена на критике классических архитектур (и софта, и железа), а иногда и критике самого проектирования, которое такими архитектурами порождено.
Брусенцов (автор такого небезывестного компьютера как "Сетунь") ещё в 80ых в обзоре популярных компьютерных архитектур ("Микрокомпьютеры, 1985) выдвигал мысли примерно следующего содержания: "когда-нибудь в погоне за производительностью [и, как известно нам, живущим уже не в СССР в 80ых, также со скоростью выпуска продукта на рынок] мы получим архитектуры, в которых никто не будет разбираться - как пользователи сейчас отделяются дружелюбной оболочкой, так и программисты также будут отделены такой же. Если сейчас [речь про 85ый год] радиолюбители могут строить свои схемы, внедрять их в свою собственную жизнь как им заблагорассудится, то в случае с компьютерами в пользователей превратятся все. [А дальше шли мечты о том, что сейчас называется "умным окружением" и является трендом последних нескольких лет, а что можно было бы достичь намного раньше]"
Примерно похожую мысль выдвигал Крис Касперски в статье "Языки, которые мы потеряли". Если кратко, то мысль в той статье сводится к "Языки программирования пошли "не туда": процедурный подход языка Си был достаточно универсален (что до сих пор подтвердается тем, что почти все ОС пишутся на C) , однако его вершиной должно было быть метапрограммирование Вместо всего этого мы получили ООП в редакции C++, который мол не позволяет пользоваться ни одним преимуществом ООП, зато помогает быстро спроектировать программу". Крис был радикальнее, он вообще утверждал, что устойчивый "скелет", который даётся проектированием софта, вовсе не нужен - проектирование происходит "само" в процессе автоматизации определенной задачи (правда, для этого в перспективе как раз потребуется метапрограммирование). Данный устойчивый "скелет" не позволяет сокращать программу в процессе разработки - в итоге можно только "накидывать функции".
Тут с несколько иной точки зрения было точно такое же объяснение: производители софта работали на заказ, с неопределенным кругом задач. Не пользователь автоматизировал свою работу за компьютером (или программист под контролем пользователя), а компании изготовляли софт для определенного широкого круга задач. И отсюда и возникали абстракции "из воздуха". Дальше над одной абстракцией возникали новые, постепенно формировались системы API, а в какой-то момент без API и жесткого запроектированного "скелета" программу уже никто и представить не мог.
Самое интересное, что оба чисто техническую альтернативу господствующим архитектурам находили в... конкатенативном языке программирования Forth: возможность гибкого расширения (как у языков высокого уровня) и, одновременно с этим низкоуровневость как у ассемблера, официально допускаемые языком приёмы самомодификации кода (необходимые для метапрограммирования), ... . При этом естественно отмечали, что это именно альтернатива в технике, а индустрия софта сама по себе вряд ли изменится.
Тут у меня пылился на полке ноут старенький (года... всего-то 2018ого). 4ГБ оперативки, но проц Pentium N4200 это как бы не фонтан. Ну и принялся я его оживлять. Работать приходится прежде всего под программами Windows, причем не очень-то навороченными. Поэтому решил поставить... XP. Хвала патчерам, два основных BSOD (неподдержка ACPI и SATA AHCI) удалось обойти. В отличие от десятки, отзывчивость высший класс. Единственные две вещи, которые меня огорчили в Windows XP, были 1) не работали многие встроенные устройства (Wifi-модуль, Bluetooth), и, что самое нехорошее, не работали USB-порты. (В целом даже USB3.0 в XP энтузиасты завезли, а вот победить отдельные контроллеры USB не вышло), 2) нет "99% уверенности" в безопасности, выходить на таком в интернет и светить своими паролями от учёток всё-таки очень стрёмно. Поэтому сейчас приходится на линуксе (убунта тоже показалась не совсем отзывчивой, да и первоначально я вообще хотел "просто гипервизор", поэтому стоит void linux) - а когда надо что-то Win32-ое включить, то qemu в деле. Вот такая история из жизни.
Это что касается "практики", а что касается теории... На моей памяти, существует две теории, объясняющие почему в софте всё всрато и становится ещё всратее:
1) автором первой теории является Никлаус Вирт, автор языка Паскаль. (Не надо хихикать, добрая половина достоинств того же языка Java была либо в Паскале (П-код), либо в его потомках, таких как Оберон (сборщики мусора у Оберона и Java, по крайней мере, родственны)) Тут основная идея простая: "Программы жирнеют, потому что их плохо проектируют". Данная мысль полноценно раскрыта в таких работах как "Долой жирные программы" (Вирт Н.)
Что бы хотелось отметить, из практически подмеченного автором и пропущенного почтенной публикой. Комментаторы справедливо заметили, что в связи с появлением "курсов", неадекватного хайпа вокруг IT, в отрасль тянутся не только интересующиеся люди, но и неинтересующиеся (ничем, возможно кроме денег, но не всегда), однако "ищущий всё равно найдёт, а выходцев курсов будут пинать, потому что это и не джуны вовсе".
С данной мыслью сложно спорить, но к тому же она, безусловно, приятна аудитории - ведь в интересующихся людях они видят себя в молодости, вне зависимости от того как давно или недавно таковая имела место. И потому за данным суждением не видно других моментов, отмеченных автором: например, неадекватно разросшийся Веб. Я не фронтендер/бекендер, вообще к вебу имею мало отношения, однако твердо убежден, что даже на стороне пользователя (!) веб (в лице в данном случае фронтенда, конечно) стал "пожирателем старых компьютеров": есть девайсы, у которых характеристики вполне покрывают абсолютно все потребности пользователя и его софта, кроме обыкновенного веб-серфинга. Раньше такой нишей "убийц <<старья>>" были новые игры, однако от игр можно и отказаться - в конце концов сейчас выпущена масса увлекательнейших игр с минимальными требованиями к железу - а вот отказаться от пользования современным вебом не может практически никто. (Что отчасти и показали первые месяцы пандемии, когда произошёл взрывной рост продаж ноутбуков)
... Давайте буквально на пару минут отвлечёмся от частного случая с вебом и посмотрим на проблему во всей её полноте: а чем, собственно, занят коммерческий IT с периода своего образования? Если не брать в расчёт опенсорс, то производством конкретных программных продуктов. При этом чем быстрее продукт будет готов, тем как правило лучше. А если продукт не совсем уж сырой, то качество выше можно и не поднимать - потребность пользователей в поддержке скорее всего даже желательна, ведь она "подсаживает" на продукт. Если же мы возьмем в расчёт опенсорс, то окажется, что он как раз занят... производством инструментов для создания конкретных программных продуктов! (сюда относятся и компиляторы, и линукс - считай семейство универсальных серверных /и не только, но прежде всего серверных/ ОС, и даже фреймворки JS, да и любые другие фреймворки)
Однако так ли много в IT осталось производства? Раньше его безусловно было много - многое приходилось писать с нуля, потому что существующих ныне фреймворков для создания "чего угодно под ключ" просто не существовало физически, да и продуктов, на которых можно было бы основать свой собственный продукт, было меньше. Сейчас же даже написание кода нередко (ни в коем случае не утверждаю что постоянно!) идёт на заказ, чего уж говорить о последующих стадиях вроде поддержки (возможно кстати, что поддержки по подписке). Сейчас программисты (и близкие к ним должности) не "просто пишут код": 1) программисты пишут код, 2) программисты его латают, 3) программисты его "хоронят" - то есть обслуживают от рождения до перегнивания. IT во многом перешла из сферы производства в сферу обслуживания.
Иногда вовсе бывают случаи, что какая-то технология "внедряется" как временная, пока не восстановлена работа основной системы - благо, развертывание занимает максимум несколько часов (... чтобы потом этот трудодень канул в лету, как только всё починят).
... Вспоминается старенькая шутка из программистского интернет-фольклора: "если бы программисты строили дома, то первый залетевший дятел уничтожил бы цивилизацию". С высоты дней сегодняшних можно сказать, что в случае неудачного попадания дятла программистам предписано в процессе обрушения отстраивать дома обратно быстрее, чем они обрушают остальные дома. Где не успевают, нужно предупреждать пользователей жителей, чтобы там не ходили, потому что там обрушение.
... Именно поэтому я бы не возлагал таких надежд на "настоящих джунов", на "последующее поколение тех, кто просто разбирается и умеет", и скорее соглашусь с автором: тут скорее всего не ожидается никакой справедливости, ведь "старшие" именно писали код, четко понимали, когда написано качественно, а когда "спешили к проду", а "младшим" в лучшем случае удастся выбрать для себя подходящие инструменты, чтобы с этим хоть как-то взаимодействовать.
Не могу согласиться. С такими доводами как у Страуструпа, во времена Кобола говорили бы то же самое про Кобол, и где он сейчас? Речь идёт как раз о том, и в статье Криса это подчеркивается, что в программировании решают отнюдь не люди, не технологии, а индустрия. И индустрии было выгодно, чтобы ходить в соседний ларёк можно только на космическом корабле с облётом вокруг Плутона - потребовалось делать продукты на заказ, имелись компьютеры, которые работали быстро только если программы были на Си - ну вот, как говорится, "получите, распишитесь".
Если и сравнивать "по Страуструпу", тогда уж уместнее это делать так: языки делятся на те, на которых людей всё равно заставят работать, и те, на которых они могли бы; в такой интерпретации данное суждение действительно неоспоримо.
Вспоминается статья Криса Касперски "Языки, которые мы потеряли". Тут статья немного о другом, но в целом получилось "На этот раз мы теряем и Си".
Если упрощенно (кому лень читать, но как по мне... в общем, прямо-таки рекомендую прочесть её), ту статью можно пересказать таким набором тезисов:
Сишник будет решать конкретную задачу, для чего напишет простую утилиту, а плюсист сначала придумает абстрактный API и по итогу сделает гигантский продукт, который будет от версии к версии всё жирнее и жирнее.
Си мог бы наверное развиваться в сторону полноценного метапрограммирования (с самомодифицирующимся кодом, с построением программ программами), но вместо этого мы имеем непрозрачные шаблоны C++, которые вроде как облегчают копипаст кода и... тут же создают тучу неоднозначностей, в которой вроде как "нет" ответственных, вроде того а что будет, если я попробую сравнить теплое с мягким (или хотя бы даже треугольник с прямоугольником) используя полиморфизм оператора сравнения.
Настоящие языки метапрограммирования, поддерживающие СМК (самомодификацию кода) на официальном уровне - а именно Лисп и Форт - по сути забыты (отдельное уточнение: здесь не соглашусь с Крисом - и тот, и другой язык жив, но назвать их существование достойным на фоне однотипных потомков языка C во главе "плюсами", а с учетом последних стандартов и описанных в статье фокусов с компиляторами уже и обыкновенного C, всё же язык не повернётся)
Ну и само собой пояснение: вопрос "жирности" не праздный - да, мы можем себе позволить на своих рабочих станциях такое количество вычислительных мощностей, которые Крису могли бы разве что присниться (причем, скорее всего, в страшном сне), но можем ли мы понять, как работает "жирная" программа, даже если нам полностью доступны отлично документированные исходные тексты?
Нет, не оксюморон. Кристаллом может называться только строго периодическая структура, в которой атомы существенно не меняют своего периодического положения на протяжении крайне большого расстояния между ними. Иными словами, можно взять прямую, соединить два соответствующих атома из разных структурных единиц, и далее будут миллионы атомов, лежащие (с поправкой на термические колебания) на этой же прямой.
Поэтому если, скажем, у вас в структуре можно сосчитать, скажем, десяток тысяч атомов, находящихся подряд на одной линии, то это не кристалл. В то же время, это и не жидкость (это понятно как по макрохарактеристикам, так и по тому, что у жидкостей обычно такая "периодичность" решетки составляет десятки-сотни атомов). Это аморфное состояние вещества, которое при этом да, точно является структурой (т.к. атомы всё равно связаны между собой, притом на уровне решетки даже относительно упорядоченные). Названо оно аморфным только в сравнении с кристаллом, тут не нужно искать "скрытого смысла" в этих физических терминах.
(P.S. Возможно, что с некоторыми цифрами что-то напутал, но то, что жидкость отличается от аморфного состояния, а аморфное от кристалла каждый на несколько десятичных порядков по указанному критерию (сколько атомов можно поставить на одну прямую из-за периодичности структуры), это точно)
Не будем. Давайте вообще закроем глаза на любые несоответствия аналогии языков с видами, как будто этого не было даже в заголовке статьи, и пройдёмся по всем остальным фактам.
Сразу отмечу, что вывод, что большинство языков похожи на живые системы, вполне неплох, вполне соответствует материальной действительности. Остальные выводы также фактически верны, однако по-моему этого недостаточно - попробуем рассмотреть это подробнее.
Что такое "среда, формирующая язык программирования"? Можно абстрактно сказать, что это "изменения, в которых участвуют буквально все", а можно прямолинейно сказать, что средой, формирующей язык программирования, является процесс разработки на этом языке, работа на этом инструменте. Откуда возникли перечисленные требования к "выживанию" языков программирования?
А это ничто иное, как требования к разработке. Притом некоторые из них, по мнению "отцов-основателей" Computer Science, абсурдны, но они здесь перечислены: например, необходимым требованием к языку программирования названа "нефатальность ошибок для всей системы", которая противоречит принципам доказательного программирования, и вообще дейкстровскому "Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения". Почему так получилось? Да потому что проще, просто дешевле производителю пользоваться языком, в котором ошибки рядового кодера нефатальны, чем математически доказывать корректность кода, или хотя бы писать код настолько иерархически определяя его и используя определения настолько кратко, насколько это вообще возможно (в том же Форте существует "правила хорошего тона", которые "не рекомендуют" использовать более 7 слов при определении нового слова - в результате приходится писать иерархии слов), и тут же проверять этот минимальный фрагмент на корректность.
"Простота для пользователей, отсутствие лишних деталей" является справедливым требованием, абсолютная правда: однако "отсутствие лишних деталей" предполагает наличие неопределенности в системе (то есть сказав при решении какой-то задачи слово "медведь", ну как на иллюстрации в статье, мы не уточили, белый или бурый - значит, это либо не имеет значения, либо напрямую следует из контекста), а следовательно для неопределенности необходима поддержка трёхзначной логики. Таких возможностей нет у большинства рассмотренных языков, трехзначность там представлена в архитектуре языка неявно (хотя декларируется при этом, что в ЯП явное лучше скрытого). К слову, данное требование в совокупности с игнорированием семейств Лисп и Форт и их наследием, уже вовсе выглядит как издевательство: ведь именно в этих языках можно без проблем создать свои языковые конструкции специально под свою задачу (или даже написать свою особенную реализацию языка под свою задачу) и действительно не отвлекаться на "лишние детали" даже в виде стандартных операторов языков программирования; более того, возможности метапрограммирования позволяют вообще уйти от рутинного написания кода к его автогенерации.
Однако такая простота находится в меньшинстве: ярким примером "простоты" для пользователя принято называть шаблоны C++, которые сами по себе являются ни много ни мало тьюринг-полным языком программирования. Простота нужна не для удобства программирования, не для ясности решаемой задачи, не для предотвращения внесения новых ошибок, а для максимально быстрого запихивания кода в прод при максимально возможно низкой квалификации кодеров - это та же проблема разработки.
Что же касается первого требования (отсутствие привязки к конкретной платформе), то оно противоречит фактам; даже фактам, перечисленным в статье. "Быть ближе к железу" в отношении C, который перечислен как достоинство этого языка по отношению к Паскалю, это как раз близость языка C к конкретному железу, просто очень популярному и простому (если быть предельно точным, к компьютерам PDP-11). Паскаль же к тому моменту располагал P-кодом (portable), очень напоминающим виртуальную машину Java. Не сходится. В качестве другого примера отмечу, что ядро Linux в ранних его версиях критиковалось именно за четкую ориентацию на ранние архитектуры семейства x86. Так сложились обстоятельства, что в течение почти 10 лет бурного роста компьютерной техники (2000ые) x86 была по сути абсолютным монополистом.
Почему C "уничтожил" Паскаль? В системном программировании виртуальные машины не очень пригодятся, а написание кода на "близком к железу" языке позволяет использовать больше вычислительных возможностей даже очень дешевых машин. C++ усугубил эту ситуацию, поскольку позволил писать на языке, близком к ассемблеру, прототипируя приложение на продажу в концепции ООП. При этом с точки зрения чистого ООП C++ не пользуется наверное ни одним преимуществом этого языка. Однако, он позволяет быстро разделить труд проектировщиков и кодеров, создавать программы не под конкретные задачи (которые постепенно усложняются), а под неопределенно широкий круг задач, создавать коммерческий софт, "софт как товар".
Приведу пример: при автоматизации советского Госплана к каждому инженеру-расчётчику приходил программист, беседовал с ним о решаемых им задачах, создавал инструмент, который выполнял все рутинные операции, чтобы можно было перенаправить работника на иную, более сложную и творческую, работу в этом же направлении. 70% полученного кода - это решение задач уровня "эксель", 30% - это различные достаточно сложные операции, которые расчётчики в том числе могли производить с применением "инженерной прикидки" и так далее, которые не решаются экселем (в базовом владении данным инструментом). А другой путь - это как раз купить условный MS Office Excel, который в сущности и автоматизацией не является, просто позволяет нанять менее клафицированного сотрудника для решения тех же задач, на выполнение настолько же рутинных (если не более рутинных) действий, просто более простых. Собственно, если в "мёртвых" языках Lisp и Forth есть возможность метапрограммирования (генерации программ программами, чтобы как раз можно было уйти от "рутины программирования") изначально, то во всех потомках C++ (о которых и идёт речь далее) эта возможность прикручена как "костыль", т.к. она противоречит модели языка.
Так и получается: если в 80-90ых написанный софт будет работать на слабеньких PC, то его закупят. А если софт при этом окажется на рынке раньше всех и он будет не настолько плох, чтобы от него отказывались, то он завоюет рынок. Так что это не C++ и его потомки победили всех остальных потому что "крутой язык", это компании которые практиковали С++/потомки C++ выкупили всех остальных. А дальше эту ситуацию уже можно заменять фразой "так сложилось исторически", не рассматривая произошедшего.
Я это к чему: эволюция языков программирования безусловно есть. Проблема в том, что большей частью отбор происходит не по объективным свойствам того или иного языка, а по требованиям к процессу разработки, по существующей конъюнктуре рынка софта и рынка IT-труда. Язык (или компьютерная архитектура - такое произошло, например, с легендарной "Сетунью" и массой других проектов советской школы микроэлектроники, убитых стандартизацией советской микроэлектроники по IBM - лидеру американского рынка) может обладать впечатляющими возможностями, быть достаточно удобным для разработчиков и прочих пользователей, но тупо "не вписаться". А потом люди будут писать, что технология X просто "обогнала время" и должна была появиться позже. Нет, она появилась скорее всего когда надо, просто прогресс в этой технологической области был предельно заторможен, пока "происходила вроде как эволюция, велись скрещивания, ..."
Похоже, "форты" выбиваются из этой теории "эволюции", ведь сам факт рождения этого языка два раза - независимо Чарльзом Муром и Эдсгером Дейкстрой - уже ближе не к эволюции, а скорее к научному открытию, подобно изобретению радио Маркони и Поповым. (Пускай первый пришёл к Форту из практических соображений, а второй к форт-архитектуре пришёл скорее из теоретических сообщений)
Самое интересное, что потомком Форта являются не только "форты", но и эзотерический FALSE, который фортом не является.
Такое ощущение, что чтобы выдвинуть теорию эволюции языков программирования, нужно было продемонстрировать лишь "подходящие" языки программирования
Всех, кстати, с праздником - международным днём без интернета!
Отдельное спасибо за восстановление недописанной статьи Криса Касперски "Два слова о трёхзначной логике"! Надеюсь, будут ещё восстановленно-неопубликованные материалы от мыщъх'а, причем посвященные не только взлому и ИБ, но и всему будущему IT (если таковые материалы, конечно, ещё есть).
Собственно, с этой статьи начал знакомиться с его творчеством - до этого просто никого не знал, потому что новичок :) (И конечно жаль, что, по всей видимости, многое уже устарело...)
Хотелось бы уточнить несколько моментов:
"этого глупца" - Вы про Криса Касперски или Николая Брусенцова? есть ли аргумент для данного утверждения, или это и есть Ваш аргумент?
"новомодными" - Вы про статью, вышедшую в 2007ом, или про книгу, вышедшую в 1985? А может, просто если не придерживаться "столпов", то окажется, что "новомодное" метапрограммирование на самом деле могло быть актуально всегда, а сейчас его ввели в моду потому что спустя столько лет стало наконец просто понятно, что без него просто не справиться со всей "красотой" бесконечных (и нарастающих подобно фракталу) уровней абстракции, которые получены согласно "столпам"?
"скажи это программистам из Microsoft" - спасибо, но в той же мере, в которой Вы считаете количество кода и программ аргументом. В Microsoft пишут на том, на чём в Microsoft скажут. Так что в таком случае Вы можете сказать что-то в корпорации SAP (где до сих пор пишут не на "коболе 90ых", а на вполне несколько осовремененном, но всё же "том самом" коболе). К слову, именно этот язык может похвастаться как заоблачным количеством кода, написанным на нём, так и массовостью применения в своё время.
В целом да, но при специфическом кодстайле по-моему возможны исключения.
Если почти весь код выстроен вокруг проверок и действий по проверке (проверить аргумент и выйти из функции с кодом возврата ошибки или скажем изменить значение счётчика при условии), на мой взгляд вполне оправдано пользоваться условием как раз без переноса строки и фигурных скобок:
Аналогия с командами по предикату - в ассемблере x86 это условные переходы, только тут это будут возвраты в функции, в ассемблере ARM для предикатов существует, если не ошибаюсь, полноценная система исполнения на любой команде.
Причем важно, что лучше всего запись именно без переноса строки и фигурных скобок одновременно. Фигурные скобки тут просто мешают читаемости, а перенос строки и написание кода "а-ля Python" может очень сильно обмануть, если вдруг придётся тело условия расширить.
Ну а "стандартный" вариант в стиле классического С это 4 строки, в стиле Java - 3, что очень сильно разреживает код и (имхо) рассредотачивает внимание, т.к. очень серьезно отличается по плотности кода от последовательностей операторов в одном блоке кода (ср.: 1 выражение на 1 строку vs 1 выражение на 3-4 строки).
Отдельно замечу, что циклов этот приём не касается (там лучше помириться с телом на 3-4 строчки, чем проморгать что-то не то)
Имеет смысл по крайней мере правильно финализировать работу программы - освободить ту память и прочие ресурсы (файлы), которые уже были заняты. В противном случае при первой же попытке работать с такой программой в автоматическом режиме (например, при помощи скрипта на bash), например вызывать её до первого успешного исполнения (то есть до экзит-кода 0), мы легко можем получить проблемы уже в пользовательской системе.
Моддеры, насколько мне известно, в известной степени "гарантируют" работоспособность получаемых систем. Естественно, всегда есть пилотные версии, надо же как-то развиваться. Но в целом, например, как уже отмечал выше, до сих пор не побеждены абсолютно все контроллеры USB3.0, так как моддеры исследуют совместимость acpi.sys и драйверов USB из Windows 8.1 (отличия есть даже между 8.0 и 8.1) - без доказательств, что такое вообще возможно, "главные модеры" и не собираются начинать пытаться. А в ReactOS, извините, но иногда "спешат" с выводами. Это нормально - система в альфе, запускается большей частью в виртуалках, ... . XP mod не могут себе позволить такой роскоши, как баги - практически все системы у всех работают на реальном железе (поскольку в виртуалках можно запускать оригинальную XP)
Нет потребностей в более высоких версиях ОС Windows, вот и всё, и при этом возможно есть потребность в обратной совместимости и/или легковесности.
Вот я, будучи студентом, могу сказать, что из всех используемых программ у нас есть одна (проприетарная CAD система), которая не запустится на XP, и несколько (штуки три минимум), которые будет достаточно сложно завести на (например) 10ке, но которые могли бы без проблем работать на XP, а остальным в целом "всё равно на чём работать". Учитывая, что большая часть программ профессиональная, думаю, что на рабочем месте ситуация не будет принципиально сильно отличаться.
Кто-то идёт в XP за звуком (аудиочувствительные люди говорят, что высочайшее качество звука на XP), кто-то (как я) за возможностью работать с продвинутыми планировщиками задач вроде nnCron (по близкой причине: система достаточно легкая, сравнительно предсказуемая, а потому всё работает как бы в пределах мягкого рилтайма; плюс в след.версиях кастомные планировщики задач начали постепенно зажимать*, пока окончательно не выпнули в десятке), ...
* В принципе, наверное, правильно поступили: технически безграмотный человек (коих за компьютерами всё больше) может не уловить, что за службы у него там фоном крутятся, и через них в принципе действительно можно осуществлять злонамеренные действия по отношению к пользователю. В мире свободного софта это решается форками: вот arch, вот ubuntu, вот void, ... . Однако у Windows сейчас монополия на Win32-среду (среду исполнения огромного количества программ), а значит прямо сейчас чем-то вроде "форка" в принципе может быть именно даунгрейд на XP
Так оно на длинной дистанции и не работает, по крайней мере сейчас (например, технический прогресс затормозился в край). Кого это волнует (из менеджеров)? Правильно, никого. "Долгосрочной перспективой", если я правильно помню, по меркам компаний в условиях рыночного хаоса, считаются 10-20 лет.
В прибыли. Сколько удалось её извлечь, удалось ли избежать убытков и так далее. Это может быть формализовано через KPI, но суть-то всё та же - максимизация прибыли производства для расширения возможностей расширения бизнеса, стабилизации положения предприятия в занятой на рынке нише, максимизации дивидендов владельцев, и так далее.
По такой логике курицы наравне с людьми (по численности получается так), а кролики одной только Австралии всего лишь в несколько раз хуже всего человеческого вида на планете. Тем не менее, почему-то люди завезли кроликов в Австралию (не наоборот), а большинство куриц живёт в неволе и люди ими просто питаются. Вопрос сравнения животных с людьми не корректен в принципе, так как человек из всех биологических видов уникален тем, что серьезно и "направленно" изменяет окружающую среду под себя. (Кстати говоря, человек для этого прикладывает усилия, и реализует их через предприятия, прибыльность которых и максизируется и заставляет менеджеров считаться "эффективными"*)
А из этого следует также, что эффективность распространенения человеческого вида (в количестве, сейчас это почти 8млрд человек) росла не по биологическим причинам, а по технологическим. В демографии это выражается не рождаемостью, а продолжительностью жизни.
*Можно спорить о том, действительно ли такой подход эффективен для всего человеческого вида в целом - может быть да, может быть и нет, но для собственников производства, на котором действует эффективный менеджер (или которым он может просто являться), это точно можно считать адекватным показателем эффективности.
Возможно. Раньше был WooS, но сейчас это скорее (взгляд человека со стороны) "война лицензий" и способа разработки. Та же Windows XP может быть на данный момент установлена на современный компьютер (существуют патчи acpi.sys, возможна интеграция драйверов sata ahci, а также usb3.0 в целом поддерживается*), но XP продолжает оставаться закрытым и несвободным ПО, за нелицензированное использование которой ("без наклеек") предприятию в принципе может прилететь по шапке и у которой есть серьезные изъяны в плане поддержки нового закрытого софта, который безусловно уже сейчас есть и которого со временем может стать только больше.
*По usb3.0: по состоянию на сегодняшний день поддерживается почти всё, кроме нескольких контроллеров, выпущенных для windows8.1+ и не поддерживающих windows8.0. Не доказано, что эти контроллеры в принципе могут работать со старым acpi.sys
И хотя решено очень многое, уже сейчас патчеры windows xp сталкиваются с определенными сложнорешаемыми затруднениями, например: установка на компьютеры с pure UEFI (не помню, удавалось ли его как-то обмануть, UEFI/CSM точно уже бэкпортнули из висты, а вот с pure UEFI совсем не уверен). Библиотеки или ещё одна подсистема wow (windows-on-windows) для запуска приложений скопилированных для vista/7/...
По второй проблеме: конечно, средний пользователь windows xp 2021 edition консервативен, но всё же есть некоторые приложения, которыми надо пользоваться, но не выйдет или будет сложно (прежде всего, это касается клиентов интернета: вот если Zoom для XP есть вполне официальный, то вот Microsoft Teams вряд ли; последние версии скайпа, которые идут на xp, по-моему поддерживаются, но это вопрос времени, когда перестанут, и так далее). Проблем с открытым софтом конечно сильно меньше, его всё равно в крайнем случае всегда можно попробовать пересобрать из исходников, но далеко не весь обязательный к использованию (в смысле, в реальной жизни - на работе, в учёбе) софт поддерживается XP, это к сожалению факт. Естественно, эта же ситуация отчасти касается и драйверов.
ReactOS вроде как должен решить эти в каком-то смысле родовые проблемы, и даже существует подпроект OneCoreAPI, который, если мне не изменяет память, подменяет части ядра Windows XP частями ядра ReactOS... (Ну, надеюсь не нужно уточнять, что эта вещь заметно более сырая, чем даже сам ReactOS.)
Лично мне самому не вполне понятны некоторые моменты с ReactOS:
От версии к версии Windows не только экстенсивно наращивала кодовую базу, но и наверняка частично рушила обратную совместимость в "мелочах" вроде поведения API, библиотек и конечно же политики безопасности (Безотносительно вопросов, делалось это осознанно или просто не учли - просто есть такой момент). Вопрос очевиден: если ReactOS в проекте намерена поддерживать всё оборудование и софт, то каким образом это можно реализовать?
Касаемо запуска с compactFlash-карты - как челленндж конечно круто, но если мне не изменяет память, в ReactOS до сих пор нет простого способа установить ReactOS с флешки. Конечно, это очень хороший "цензор" для "ниасиливших" (вроде меня - void linux и devuan устанавливаются стократ проще, чем reactos на флешку с ramdisk), но уточню, что в итоге это скорее всего серьезно урезает количество потенциальных тестеров. [как мне кажется, возможно я ошибаюсь, но по-моему сейчас DVD есть либо в ПК, на которые ReactOS точно не встанет, либо на старые ПК, которые и под XP или даже 98se отлично себя чувствуют]. Уточню, что здесь наверное могу быть не прав.
Но в любом случае желаю проекту успеха
Спасибо за сайт.
Ну, вот Крис Касперски считал, что проблема Форта в том, что его парадигма плохо уживается с корпоративным миром софта. Он её просто не обогнал.
Что касается ООП, то на мой взгляд в 80-90ых вокруг ООП был в опредёленной мере хайп, а в определённой мере C с классами (назовём C++ своим изначальным именем) был нужен, чтобы, обеспечив переносимость и быстродействие как у C, обеспечить и скорость разработки. Тут уместно вспомнить ООП-системных аналитиков, и думаю что вот как раз их работа от "плюсов" и пошла.
Допустим, некоторая корпорация (например, "Крупнософт" или "Турланд") делает СУБД/офисный пакет/IDE с кучей фич, ... но который должен запускаться на компьютере, на котором памяти столько, что "всем должно быть достаточно", как (не?) говорил один известный бизнесмен, а процессор вообще такой, что с памятью можно даже сказать всё нормально... И вот в таком случае как раз на помощь спешит "C с классами": классы в нём чтобы писалось быстрее, а C чтобы можно было быстро допилить критические места на ассемблере, и в итоге софт работал даже на "печатной машинке". То есть часть "плюсовый" ООП был на месте современного фронтенда, где главное быстро запрототипировать а что мы вообще делаем, а "начинка" в виде наследия языка C (от которого постепенно отдалялись) - на месте бекенда
Вспоминается, что когда-то основатель Smalltalk заявил что-то в духе "Когда я говорил про ООП, я не имел ввиду C++". Наверное, сама концепция интересна, но наверное эта тема перегрета - индустрии в ООП было интересно несколько другое. Кстати, технических преимуществ, вроде того же масштабирования объектов на несколько процессоров, тогда в ООП и не взяли (в C++ существует один вариант вызова сообщений: по сути, это просто вызов функции C), а обратно трепыхаться (и смоллтолку, и C++) уже наверное поздно (но каждому по своим собственным причинам)
Да, слышал про Дейкстру. Насколько я помню, его вычислитель отличался ещё словом E, который Мур, когда ему показали эту систему, посчитал очень непрактичным. Возможно, были ещё какие-то недостатки. А может Дейкстра с самого начала увидел несовместимость форта с развивавшейся на тот момент индустрией, и именно поэтому и назвал его "непрактичным". А возможно, что просто Дейкстра просто очень хотел увидеть в этом вычислителе теоретическую ценность, в то время как Мур создавал Форт именно программируя на нём. Кстати, на мой взгляд, наверное какая-то теоретическая ценность есть, потому что это похоже на открытие. Хотя можно сказатть, что Попов и Маркони радио именно изобрели (... но попутно открыли целую область техники)
Да, нагуглили не то: гуглить в данном случае нужно было Оберон.
Что касается фундаментальности, то тут может быть интересно то, что называется собирательным термином оберон-технологии: грамотное проектирование обыкновенного, классически построенного софта и железа, как их грамотно соотнести (язык, операционную систему и "железо"). Всё это было сделано (то есть и язык, и операционная система, и железо) "с нуля", особой оригинальностью каждое в отдельности конечно не отличалось, но, по мнению разработчиков, может быть охвачено и осознано одним отдельным человеком целиком, без дополнительных инструментов.
(Таким образом, разработчики считают, что ушли от проблем "необъятного" софта и железа. И если бы к разработчиков к "излишней" абстрактности программ, а затем к бесконечным прослойкам на прослойках, толкало бы только "основание" всей этой системы, имели бы место только претензии Брусенцова (см.первый комментарий этой ветки, точнее продолжение в той же ветке про вторую теорию), то вопрос был бы снят. Но в чем я очень сомневаюсь, что в Обероне удалось развить метапрограммирование (претензия к классическим архитектурам и конкретно языкам уже от Криса Касперски) - а значит, проблема "необъятности" скорее всего снова появится при разработке уже второго поколения программ.)
Если мне не изменяет память, именно паскали и можно использовать для доказательного программирования, и по-моему поэтому классический Паскаль используют в той же ракетной технике. (Причем валидация не модели программы, а собственно самой программы, что она точно не содержит ошибок). Но это, конечно, если память не изменяет.
Но повторюсь, минимальность важна не только тем, что посредством неё можно доказывать всякое математически - общая идея была как раз покончить с некачественным проектированием, показать "как надо"
Фундаментальная наука, в отличие от молока и прикладной науки, не скисает со временем. Так что статус исторического тут не очень мешает.
Что касается интересного, то паскалоиды отличаются минимальностью (в том числе грамматической) в рамках классических языков программирования. Чего-то принципиально отличного в них (в отличие от Форта или Лиспа, которые в какой-то степени "зеркальны" - кстати, Крис Касперски писал не только о Форте, но и о Лиспе, я лишь сократил пересказ), на мой взгляд, нет, но всё же 1) определённые исторические заслуги у Вирта и его разработок есть, 2) плюс оно чуть выгоднее выделяется на фоне того же самого современного софта, о котором идёт речь (повторюсь, пока не узнаёшь про что-то принципиально другое).
... Собственно, как мне лично кажется, сам Вирт пытался сделать что-то похожее на Форт или Лисп (например, языком с минимальной грамматикой является Форт, а Лисп, как Вы же и отметили, уже имел сборку мусора), но по каким-то своим причинам для него необходимо было остаться в рамках классических алголоподобных языков.
Сейчас закончил (вторую часть отправил как ответ первому комментатору), спасибо за интерес
В целом согласен, но у таких всегда есть "аргумент" - "за фреймворки Javascript [например] зато платят, и платят много". Хотя как аргумент научно-технического спора это выглядит максимально неубедительно, но ведь в конце концов это же самое суждение можно замаскировать в менее очевидные формы, например "а почему тогда на Паскале/Модуле/Обероне программируют 2.5 человека на зарплатах в НИИ, а остальные разботчики от этого ушли?".
И поскольку мнение "ориентированных на индустрию" достаточно влиятельно (в конце концов, на то она и индустрия), а широкой аудитории не всегда известно, как открытия и разработки Вирта повлияли лично на них (а тут как минимум привет языку Java: байт-код и GC, первое родственно П-коду, второе по крайней мере родственно обероновскому GC), то на всякий случай уточнил
(как всё-таки жаль, что на Хабре нельзя изменять свой комментарий, даже если проходишь премодерацию, и отменять отправку в течение первых N секунд)
А вторая теория выстроена на критике классических архитектур (и софта, и железа), а иногда и критике самого проектирования, которое такими архитектурами порождено.
Брусенцов (автор такого небезывестного компьютера как "Сетунь") ещё в 80ых в обзоре популярных компьютерных архитектур ("Микрокомпьютеры, 1985) выдвигал мысли примерно следующего содержания: "когда-нибудь в погоне за производительностью [и, как известно нам, живущим уже не в СССР в 80ых, также со скоростью выпуска продукта на рынок] мы получим архитектуры, в которых никто не будет разбираться - как пользователи сейчас отделяются дружелюбной оболочкой, так и программисты также будут отделены такой же. Если сейчас [речь про 85ый год] радиолюбители могут строить свои схемы, внедрять их в свою собственную жизнь как им заблагорассудится, то в случае с компьютерами в пользователей превратятся все. [А дальше шли мечты о том, что сейчас называется "умным окружением" и является трендом последних нескольких лет, а что можно было бы достичь намного раньше]"
Примерно похожую мысль выдвигал Крис Касперски в статье "Языки, которые мы потеряли". Если кратко, то мысль в той статье сводится к "Языки программирования пошли "не туда": процедурный подход языка Си был достаточно универсален (что до сих пор подтвердается тем, что почти все ОС пишутся на C) , однако его вершиной должно было быть метапрограммирование Вместо всего этого мы получили ООП в редакции C++, который мол не позволяет пользоваться ни одним преимуществом ООП, зато помогает быстро спроектировать программу". Крис был радикальнее, он вообще утверждал, что устойчивый "скелет", который даётся проектированием софта, вовсе не нужен - проектирование происходит "само" в процессе автоматизации определенной задачи (правда, для этого в перспективе как раз потребуется метапрограммирование). Данный устойчивый "скелет" не позволяет сокращать программу в процессе разработки - в итоге можно только "накидывать функции".
Тут с несколько иной точки зрения было точно такое же объяснение: производители софта работали на заказ, с неопределенным кругом задач. Не пользователь автоматизировал свою работу за компьютером (или программист под контролем пользователя), а компании изготовляли софт для определенного широкого круга задач. И отсюда и возникали абстракции "из воздуха". Дальше над одной абстракцией возникали новые, постепенно формировались системы API, а в какой-то момент без API и жесткого запроектированного "скелета" программу уже никто и представить не мог.
Самое интересное, что оба чисто техническую альтернативу господствующим архитектурам находили в... конкатенативном языке программирования Forth: возможность гибкого расширения (как у языков высокого уровня) и, одновременно с этим низкоуровневость как у ассемблера, официально допускаемые языком приёмы самомодификации кода (необходимые для метапрограммирования), ... . При этом естественно отмечали, что это именно альтернатива в технике, а индустрия софта сама по себе вряд ли изменится.
Тут у меня пылился на полке ноут старенький (года... всего-то 2018ого). 4ГБ оперативки, но проц Pentium N4200 это как бы не фонтан. Ну и принялся я его оживлять. Работать приходится прежде всего под программами Windows, причем не очень-то навороченными. Поэтому решил поставить... XP. Хвала патчерам, два основных BSOD (неподдержка ACPI и SATA AHCI) удалось обойти. В отличие от десятки, отзывчивость высший класс. Единственные две вещи, которые меня огорчили в Windows XP, были 1) не работали многие встроенные устройства (Wifi-модуль, Bluetooth), и, что самое нехорошее, не работали USB-порты. (В целом даже USB3.0 в XP энтузиасты завезли, а вот победить отдельные контроллеры USB не вышло), 2) нет "99% уверенности" в безопасности, выходить на таком в интернет и светить своими паролями от учёток всё-таки очень стрёмно. Поэтому сейчас приходится на линуксе (убунта тоже показалась не совсем отзывчивой, да и первоначально я вообще хотел "просто гипервизор", поэтому стоит void linux) - а когда надо что-то Win32-ое включить, то qemu в деле. Вот такая история из жизни.
Это что касается "практики", а что касается теории... На моей памяти, существует две теории, объясняющие почему в софте всё всрато и становится ещё всратее:
1) автором первой теории является Никлаус Вирт, автор языка Паскаль. (Не надо хихикать, добрая половина достоинств того же языка Java была либо в Паскале (П-код), либо в его потомках, таких как Оберон (сборщики мусора у Оберона и Java, по крайней мере, родственны)) Тут основная идея простая: "Программы жирнеют, потому что их плохо проектируют". Данная мысль полноценно раскрыта в таких работах как "Долой жирные программы" (Вирт Н.)
2) автором второ
Что бы хотелось отметить, из практически подмеченного автором и пропущенного почтенной публикой.
Комментаторы справедливо заметили, что в связи с появлением "курсов", неадекватного хайпа вокруг IT, в отрасль тянутся не только интересующиеся люди, но и неинтересующиеся (ничем, возможно кроме денег, но не всегда), однако "ищущий всё равно найдёт, а выходцев курсов будут пинать, потому что это и не джуны вовсе".
С данной мыслью сложно спорить, но к тому же она, безусловно, приятна аудитории - ведь в интересующихся людях они видят себя в молодости, вне зависимости от того как давно или недавно таковая имела место. И потому за данным суждением не видно других моментов, отмеченных автором: например, неадекватно разросшийся Веб. Я не фронтендер/бекендер, вообще к вебу имею мало отношения, однако твердо убежден, что даже на стороне пользователя (!) веб (в лице в данном случае фронтенда, конечно) стал "пожирателем старых компьютеров": есть девайсы, у которых характеристики вполне покрывают абсолютно все потребности пользователя и его софта, кроме обыкновенного веб-серфинга. Раньше такой нишей "убийц <<старья>>" были новые игры, однако от игр можно и отказаться - в конце концов сейчас выпущена масса увлекательнейших игр с минимальными требованиями к железу - а вот отказаться от пользования современным вебом не может практически никто. (Что отчасти и показали первые месяцы пандемии, когда произошёл взрывной рост продаж ноутбуков)
... Давайте буквально на пару минут отвлечёмся от частного случая с вебом и посмотрим на проблему во всей её полноте: а чем, собственно, занят коммерческий IT с периода своего образования? Если не брать в расчёт опенсорс, то производством конкретных программных продуктов. При этом чем быстрее продукт будет готов, тем как правило лучше. А если продукт не совсем уж сырой, то качество выше можно и не поднимать - потребность пользователей в поддержке скорее всего даже желательна, ведь она "подсаживает" на продукт. Если же мы возьмем в расчёт опенсорс, то окажется, что он как раз занят... производством инструментов для создания конкретных программных продуктов! (сюда относятся и компиляторы, и линукс - считай семейство универсальных серверных /и не только, но прежде всего серверных/ ОС, и даже фреймворки JS, да и любые другие фреймворки)
Однако так ли много в IT осталось производства? Раньше его безусловно было много - многое приходилось писать с нуля, потому что существующих ныне фреймворков для создания "чего угодно под ключ" просто не существовало физически, да и продуктов, на которых можно было бы основать свой собственный продукт, было меньше. Сейчас же даже написание кода нередко (ни в коем случае не утверждаю что постоянно!) идёт на заказ, чего уж говорить о последующих стадиях вроде поддержки (возможно кстати, что поддержки по подписке) . Сейчас программисты (и близкие к ним должности) не "просто пишут код": 1) программисты пишут код, 2) программисты его латают, 3) программисты его "хоронят" - то есть обслуживают от рождения до перегнивания. IT во многом перешла из сферы производства в сферу обслуживания.
Иногда вовсе бывают случаи, что какая-то технология "внедряется" как временная, пока не восстановлена работа основной системы - благо, развертывание занимает максимум несколько часов (... чтобы потом этот трудодень канул в лету, как только всё починят).
... Вспоминается старенькая шутка из программистского интернет-фольклора: "если бы программисты строили дома, то первый залетевший дятел уничтожил бы цивилизацию". С высоты дней сегодняшних можно сказать, что в случае неудачного попадания дятла программистам предписано в процессе обрушения отстраивать дома обратно быстрее, чем они обрушают остальные дома. Где не успевают, нужно предупреждать
пользователейжителей, чтобы там не ходили, потому что там обрушение.... Именно поэтому я бы не возлагал таких надежд на "настоящих джунов", на "последующее поколение тех, кто просто разбирается и умеет", и скорее соглашусь с автором: тут скорее всего не ожидается никакой справедливости, ведь "старшие" именно писали код, четко понимали, когда написано качественно, а когда "спешили к проду", а "младшим" в лучшем случае удастся выбрать для себя подходящие инструменты, чтобы с этим хоть как-то взаимодействовать.
Не могу согласиться. С такими доводами как у Страуструпа, во времена Кобола говорили бы то же самое про Кобол, и где он сейчас? Речь идёт как раз о том, и в статье Криса это подчеркивается, что в программировании решают отнюдь не люди, не технологии, а индустрия. И индустрии было выгодно, чтобы ходить в соседний ларёк можно только на космическом корабле с облётом вокруг Плутона - потребовалось делать продукты на заказ, имелись компьютеры, которые работали быстро только если программы были на Си - ну вот, как говорится, "получите, распишитесь".
Если и сравнивать "по Страуструпу", тогда уж уместнее это делать так: языки делятся на те, на которых людей всё равно заставят работать, и те, на которых они могли бы; в такой интерпретации данное суждение действительно неоспоримо.
Вспоминается статья Криса Касперски "Языки, которые мы потеряли". Тут статья немного о другом, но в целом получилось "На этот раз мы теряем и Си".
Если упрощенно (кому лень читать, но как по мне... в общем, прямо-таки рекомендую прочесть её), ту статью можно пересказать таким набором тезисов:
Сишник будет решать конкретную задачу, для чего напишет простую утилиту, а плюсист сначала придумает абстрактный API и по итогу сделает гигантский продукт, который будет от версии к версии всё жирнее и жирнее.
Си мог бы наверное развиваться в сторону полноценного метапрограммирования (с самомодифицирующимся кодом, с построением программ программами), но вместо этого мы имеем непрозрачные шаблоны C++, которые вроде как облегчают копипаст кода и... тут же создают тучу неоднозначностей, в которой вроде как "нет" ответственных, вроде того а что будет, если я попробую сравнить теплое с мягким (или хотя бы даже треугольник с прямоугольником) используя полиморфизм оператора сравнения.
Настоящие языки метапрограммирования, поддерживающие СМК (самомодификацию кода) на официальном уровне - а именно Лисп и Форт - по сути забыты (отдельное уточнение: здесь не соглашусь с Крисом - и тот, и другой язык жив, но назвать их существование достойным на фоне однотипных потомков языка C во главе "плюсами", а с учетом последних стандартов и описанных в статье фокусов с компиляторами уже и обыкновенного C, всё же язык не повернётся)
Ну и само собой пояснение: вопрос "жирности" не праздный - да, мы можем себе позволить на своих рабочих станциях такое количество вычислительных мощностей, которые Крису могли бы разве что присниться (причем, скорее всего, в страшном сне), но можем ли мы понять, как работает "жирная" программа, даже если нам полностью доступны отлично документированные исходные тексты?
Нет, не оксюморон.
Кристаллом может называться только строго периодическая структура, в которой атомы существенно не меняют своего периодического положения на протяжении крайне большого расстояния между ними.
Иными словами, можно взять прямую, соединить два соответствующих атома из разных структурных единиц, и далее будут миллионы атомов, лежащие (с поправкой на термические колебания) на этой же прямой.
Поэтому если, скажем, у вас в структуре можно сосчитать, скажем, десяток тысяч атомов, находящихся подряд на одной линии, то это не кристалл. В то же время, это и не жидкость (это понятно как по макрохарактеристикам, так и по тому, что у жидкостей обычно такая "периодичность" решетки составляет десятки-сотни атомов). Это аморфное состояние вещества, которое при этом да, точно является структурой (т.к. атомы всё равно связаны между собой, притом на уровне решетки даже относительно упорядоченные). Названо оно аморфным только в сравнении с кристаллом, тут не нужно искать "скрытого смысла" в этих физических терминах.
(P.S. Возможно, что с некоторыми цифрами что-то напутал, но то, что жидкость отличается от аморфного состояния, а аморфное от кристалла каждый на несколько десятичных порядков по указанному критерию (сколько атомов можно поставить на одну прямую из-за периодичности структуры), это точно)