Довод простой. Под новое оборудование не будет драйверов для старых ОС.
А еще довод - новые API в операционной системе. И то, что разработчикам нахер не вперлось поддерживать что-то там старое, для которого надо городить сраные костыли.
Я лично когда речь идет о клиентском софте, в 2023м году сразу готов говорить - минимальная поддерживаемая версия винды - Windows 10. Ретрограды, контрамоты и говноеды пусть идут к херам, ковыряются в грязи, и жрут говно. Хера им с три а не софт. Пусть ставят себе хоть Windows 3.11 и играют там в пасьянс «косынка».
Это я еще не говорю про Security Updates итд, которые под ОС с вышедшим сроком поддержки и вообще годности(типа семерки), не делают.
Я лично когда речь идет о клиентском софте, в 2023м году сразу готов говорить - минимальная поддерживаемая версия винды - Windows 10.
Так и запишем — не осилил.
Ретрограды, контрамоты и говноеды
…в переводе с твоего на русский — это люди, которые не хотят выбрать старую работающую технику, видимо.
ковыряются в грязи, и жрут говно
– то, чем всем придётся заниматься на убитой отходами планете. К сожалению, всем, а не только тем, кто не умеет в совместимость с умеренно старыми ОС, это действительно проблема.
Так как в Лисп можно в run-time использовать исходные тексты
модулей, то наверное можно для вашего клиента разработать
run-time генератор Лисп модулей согласно некоего исходного алгоритма или запроса.
То бишь некий свой ЯП.
Шутка
Совместимый с синтаксисом ЯП фирмы 1С.
да нет, не шутка. лет 11 назад мне надоела 7.7 и 8.2 – я почувствовал как тупею. и я начал изобретать свой её аналог (вдохновившись 2Cgpl, только там простой интерпретатор, а я писал компилятор/транспилятор). оказалось не сильно сложно.
написал парсер 7.7 на ANTLR и транслятор его распарсенного AST в другое всякое.
в ANTLR 3.4 есть метод ((Tree)parser.tree).toStringTree(), который прямо так берёт и выводит AST сгенерированного parser в виде S-выражений.
как-то копипастил её на лоре в несколько постов, там несложно.
парсер сам простой, основная сложность – в ANTLR грамматике.
опять же, если делать правильные семантические предикаты – то тоже нетривиально, если забить и делать динамически – но гораздо проще.
я пытался взять за образец грамматику из оберона, допилить до русскоязычного и отладить – сразу делать тесты грамматики правильные на gUnit. основное время заняли сами тесты.
примерно за пару месяцев, не сильно тратя время по паре часов вечерами – допилил прототип. основное время заняло чтение книжек по ANTLR и настройка плагина ANTLR в Eclipse.
потом немного повозился с правильным pretty printing-ом, но забил – готовая функция в Emacs и так неплохо справляется с форматированием лисп-кода.
в общем, получился такой простой и примитивный транслятор грамматики 7.7 и любой программы на ней в S-выражения.
потом с небольшим количеством макросов на лиспе, которые непосредственно исполняли либо переводили на другой язык (например, лисп) – получился готовый интерпретатор/компилятор 7.7 в лисп.
ещё возился с перенацеливанием с целевого лиспа в целевой оберон, затем аду.
Технология разработки ЯП с использованием грамматик не пригодна для создания ЯП с хорошим синтаксисом.
что такое «хороший синтаксис» и почему он хорош?
это какая именно технология и почему? что на ANTLR, что на CoCo/R пишется несложно, и синтаксис любой можно довольно просто сделать.
есть более правильная идеологически – K framework. там примерно как в ANTLR v3 gUnit, нужно начинать сразу с тестов и определять семантические предикаты, продвигаться сразу в семантику.
там тоже не очень сложно выглядит.
Линковщики застыли в 60-х и не понимают, что такое динамические переменные и много много более.
вот да, по Вашей ссылке, Владимир – на UCSD p-code system нашёл рассадник цитатник высказываний и книг Эдсгера Дейкстры и Никлауса Вирта.
сейчас вот перечитывал «Долой жирные программы». где он как раз рассказывал про design decisions повлиявшие на то как он Oberon-2 делал.
сделали расширение типов – правильное, с учётом наследования, перехода через границы модулей.
в какой-то другой книжке про оберон (то ли алгоритмы+данные=программы, то ли про конструирование компиляторов) – про метод пошагового уточнения /stepwise refinement и разницу между независимой и раздельной компиляцией модулей. (или это в книжке про модулу?)
независимая компиляция – взяли все модули, собрали в объектники. произошло стирание типов и много лишней работы из-за того что метаинформация о типах модуля на этом этапе отсутствует.
раздельная компиляция – обошли инструкцию об импорте, метаинформацию о типах модуля и символьный файл, как в модуле. и зависимости только по нужным символьным файлам – используя расширение типов – через границы модулей.
при этом модули не приходится перекомпилировать заново. на них вообще могут исходники отстутствовать.
в общем, сравнивая между собой операционную систему, которая запускает процессы которые падают в корку (с дампом образа процесса) – и операционную среду, которая гарантирует, что модуль в отличие от процесса запустится максимум один раз, и что в отличие от объектника или .dll метаинформация о экспортированных типах модуля корректно работает через границы модулей, и что нужно какое-то дальнейшее упрощение этих принципов и концепций – но сохраняя существенное, с возможностями прозрачного расширения –
видно все эти ценности и проектные решения которые были сознательно выбраны в проекте оберон.
в общем, долой жирные программы!! довольно познавательным чтивом оказалось, с эдаким design rationale
даже Plan 9 и Inferno выглядят какой-то вторичной и опоздавшей попыткой исправиться. сравнивая оберон и limbo, второй как-то более на виртуальную машину завязан (она хоть и регистровая Dis, но всё таки, с модульностью и корректной статической типизацией там другой подход).
в общем, что оберон, что активный оберон, что инферно выглядит какой-то более продуманной расширяемой операционной средой.
да даже тот же p-code в паскалях, m-сode в модулах, o-code в BCPL.
Например в Си if ( VpInt01 = VpInt02 ) является синтаксически правильным, а наверняка должно быть if ( VpInt01 == VpInt02 ).
Оператор запятая тоже может способствовать ошибкам в исходном коде.
Например:
VpInt01 = VpInt03 > 1,
15,
16;
Полная чушь, а компилятор видит в этом что-то полезное.
Всякие красивые синтаксические «фантики», ...
в общем, что оберон, что активный оберон,
Здесь важна не реализация Оберон, а новый технологический подход к разработке проектов.
Полная чушь, а компилятор видит в этом что-то полезное.
компилятор просто буквально переводит что написано и не додумывает отсебятины.
синтаксис в этом смысле должен устранять неоднозначности – например, if {LogicExp} then {op} else {op} endif одназначно подразумевает, что выражение логическое вычисляющееся в true/false, что op – оператор а не выражение, то есть, для которого важны побочные эффекты а не возвращаемое значение и т.п.
в этом смысле попытка налепить всё в одно-единственное выражение – пример того, как делать можно, но не нужно: нарушается соответствие синтаксиса и семантики, плотно упаковывая в одно выражение.
с другой стороны, если бы например это был функциональный язык. то op может быть например лямбдой, которую можно погрузить в другую лямбду либо конструкцию наподобие let over lamda – то есть, замыкание. то есть, упрощая композицию за счёт корректных типов выражений.
Оператор запятая тоже может способствовать ошибкам в исходном коде.
Это ещё что, вот у А. В. Столярова которого некоторые огульно хаят не читая – есть лисп InteLib, полученный трансляцией в С++ выражения.
в описании есть некая «операция пробел», конструирующая лисп-выражения в некоторой алгебре.
типа как в языке Io пробелом можно показывать вызов метода прототипного ООП и цепочечный вызов методов, только здесь раскрутка S-выражений в С++-выражения некоторых классов получается частично во время компиляции шаблонами, частично – во время выполнения.
лисп был раскручен в более-менее полноценный диалект схемы.
был у него студент, который написал аналогичную раскрутку на D, а не на С++.
D в этом смысле более перспективный язык – из-за CTFE и информации о типах времени выполнения, typeinfo в модулях.
было это (InteLib) примерно в 2006, диалект на D (Scheme4d.tar.gz) – примерно 2007..2008.
в это время D был диалекта D1, со многими ограничениями. например, 3D стрелялку Deadlock на D писал h3r2tic сайт наподобие quake – там на CTFE были шейдеры и множество фич завязаны. D1 в то время был не зрелым – в линкере digital mars OPTLINK были проблемы, некоторые фичи были в стандартной библиотеке phobos не доделаны. в той стрелялке они сделали свой форк D1, рантайма phobos и попутно написали средство сборки xfbuild.
ещё он делал Nuklear-подобный GUI: Hybrid, стрелялку Deadlock, xfbuild и CTFE raytracer на D ctrace.
большинство наворотов в Hybrid, Deadlock, ctrace сделаны во время компиляции (CTFE).
сейчас он похоже, растом увлёкся.
сейчас этот код Scheme4d бы стоило на D2 переписать.
например, когда в разработку D подключился Александреску – там появился std.algorithm как более полноценный аналог boost-а и Loki (про локи кажется тот же Александреску книжку написал, которой можно детей пугать – пример шаблонов головного мозга показывающий скорее то, как делать не надо. впрочем, в книге Александреску про D2 с описанием std.algorithm стало наконец понятно, к чему это всё было – из-за более полноценной поддержки typeinfo и CTFE в D, библиотеки наподобие STL std.algorithm поддерживает «лямбды времени компиляции» которые транслируются как string mixin, template mixin в D.
например, на D2 есть библиотека с некрасивым названием pegged позволяющая написать рекурсивный нисходящий парсер на CTFE выражениях времени компиляции.
из примеров в этой библиотеке есть, например, Oberon-2 или extended_pascal.
PEG выражения во время компиляции (CTFE) параметризуются нужной грамматикой и раскрываются в итоговые выражения через string mixin/template mixin – в полноценный код на языке D.
то есть, если бы например в подобном стиле переписать на D2 вот тот код Scheme4d.tar.gz студента Столярова – то возможно, получилось бы вообще обойтись только выражениями времени компиляции, с ещё меньшими накладными расходами на рантайм-поддержку объектных выражений полученных в алгебре программ с «операцией пробел» трансляцией из S-выражений исходного лиспа в целевой D2 (а не С++)
в общем, сделать такой лисп с минимальным рантаймом – потому что в основном вся раскрутка происходит во время компиляции, CTFE макросами.
в InteLib на С++ А.В. Столярова с «операцией пробел» в этом смысле не совсем правильный СTFE, ибо С++.
На D2 этот подход был бы реализован более прозрачно и правильно.
Здесь важна не реализация Оберон, а новый технологический подход к разработке проектов.
подход не такой уж и новый – всё новое это хорошо забытое старое.
«лишняя функция – это бОльшая ненадёжность и узязвимость»,
поэтому фичи и концепции нужно оценивать не столько поо количеству – сколько по качеству.
просто концепции – существенные, essential в основании должны быть правильные. допускающие адекватное расширение.
Э. Дейкстра давным-давно писал про «скромного программиста» humble programmer, дисциплину программирования, упрощение до минимализма, а не примитивизма используемых концепций.
минимализм – это про то, как выразить бОльший смысл малыми средствами.
примитивизм – это когда нет никаких бОльших смыслов кроме примитивно накаляканых.
в этом смысле, нужно как писал А. Белый в книге «Символизм как миропонимание» – не столько пассивное мировозрение, мировосприятие, любомудрие и прочее потакание собственной важности.
сколько активное преобразование реальности, этакий перфоманс – миропонимание. того как применить все эти символы и концепции, подходы, принципы и парадигмы.
Н. Вирт уточнил в stepwise refinement методе пошагового уточнения – как правильно нужно набрасывать абстракции.
в «долой жирные программы!» – выяснилось, что важно не просто количество фич, но их качество: структура, модульность, адекватное расширение типов.
в книге про устройство компонентной модели SOM для OS/2, например, тоже похожий подход: берём сначала принципы (ABI не должно ломаться при изменении класса в предка и потомка, двигая его по иерархии наследования) – то есть, реализация этих принципов должна сохранять некоторые инварианты. потом реализуем эти принципы и получается некоторый shim, trampoline для реализации SOM API, и компилятор VisualAge C++ который С++ классы в такие вот SOM классы на plain C ABI прозрачно транслирует.
для поддержки адекватного расширения типов – вводят метаинформацию, typeinfo о модулях и другой, более объектно-ориентированный линкер, лоадер.
в Plan 9 компилятор kencc тоже кстати переделывают 6c/6l, 8c/8l – более другой линкер/лоадер.
и внезапно, оказывается что можно делать разработку инкрементально, итеративно, модульно.
и не ждать пока по полчаса C++ шаблоны на BOOST или STL откомпилируются :))
в общем, и Никлаус Вирт в оберонах и Керниган, Пайк и Ритчи в Plan9 и Inferno, и Волтер Брайт, Александреску, h3r2tic,PhilippeSigaud показали – чего можно достичь адекватно структурированной модульностью.
даже на С можно писать аккуратно и модульно. только большинство так не делает :)
С++ в этом смысле наоборот, провоцирует писать монолитные жирные программы.
и пока продаются фичи по количеству, а не по качеству (никто же не покупает «правильную архитектуру» как более ценную фичу) – этот театр абсурда и будет продолжаться.
в оберонах, инферно, да даже том же p-code и паскалине – нужно немножко отстраниться назад и посмотреть не замыленным взглядом.
какие фичи наиболее важные, а какие концептуально не правильны.
как должно развиваться ядро системы, и как её модули.
по каким принципам должна строиться и развиваться система – чтобы не требовать бесконечной перекомпиляции.
в общем, интересные соображения появляются.
может даже, бОльшая часть такой системы должна быть сделана например на модульном, правильно структурированном лиспе.
или ещё каком языке – допускающим адекватное конструирование высокоуровневых конструкций из адекватно подобранных низкоуровневых.
//правда ощущение – как про моноид в категории эндофункторов // у мольера вон тоже герой внезапно обнаружил, что оказывается, // он прозой разговаривал – только не знал что это так по-учёному называется