Smalltalk - изучаем вместе

Вышедший за три года до него паскаль уже имел строки явной длины, решавшие огромное число проблем, …

И добавлявшие кучу проблем, если вдруг строка не помещалась в 255 байтов. В современном паскале (fpc) строки неограниченные.

Как у тебя сочетаются преимущество ограниченных строк и «ограничение в 128 КБ на длину аргументов программы ничем не оправдано» я вообще не понимаю.

«правильная» объектно-ориентированность, месседж пассинг, все объект это мы +- знаем.

Это и в лиспе легко делается: https://github.com/Kalimehtar/message-oo

Потому помощи от простых людей не жди

Проще говоря - «На форуме пофлудим, /а на большее ты не рассчитывай/».

У Кернигана есть статья «почему Паскаль не мой любимый язык»

Это очень весёлое чтиво. Я слышал про эту статью, но то ли не читал ее, то ли почти не читал. Да, чувствуется здесь, что Керниган - опытный системный кодер, а Вирт в этом плане слабоват. Ряд претензий Кернигана перестали быть актуальными в 1983 с выходом турбо паскаля, в котором были и строки, и приведения типов (а значит, свободные оперции с указателями и данными переменной длины через getmem/freemem), и произвольное количество var/type/const. Еще позже завезли полноценные модули с interface/implementation и стадией линковки.

Про строки странная история: в книге 1975 года их нет, в книге 1991 года - тоже, однако, строки есть в руководстве турбо паскаля 1983 года, и сам Керниган упоминает, что в компиляторах, вообще-то, всё-таки есть строки:

Many commercial Pascal compilers provide a 'string' data type that explicitly avoids the problem; 'string's are all taken to be the same type regardless of size. This solves the problem for this single data type, but no other. It also fails to solve secondary problems like computing the length of a constant string; another built-in function is the usual solution.

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

Статические переменные являются недостатком Си, а не его достоинством - отсюда возникла пагубная традиция среди сишников совать всё подряд в статические переменные. Это один из двух пунктов, по которому я не согласен с Керниганом (вторым является реализация строк). Зато я согласен с тем, что в паскале отвратителен стандартный ввод-вывод: за много лет письма я никогда не пользовался стандартными функциями, это совершенно бесполезные обрубки, «смирительная рубашка», как выразился Керниган - они в нынешних компиляторах паскаля остались скорее ради совместимости с кодом старых пердунов.

Я думаю, что отсутствие готовых удобных механизмов ввода-вывода стало той преградой, благодаря который в 80-х Си обогнал паскаль даже несмотря на более грамотную реализацию граматики паскаля. Я должен заметить, что именно язык Вирта должен был стать алголом 68, при разработке которого изначально должны был просто исправить недостатки ввода-вывода алгола 60 (и которые так и не исправил Вирт в паскале), но в какой-то момент поехавший (математик) Вайнгаарден предложил граматику, суть которой я до сих пор не понимаю, а просто догадываюсь, что это граматика, описывающая граматику (метаграматика). В итоге никто из коммитета просто не мог понять, что за язык проектируется, а потому не мог возразить по существу. Типа «сделай свой язык сам» и «у вас не получается пользоваться нашим языком? Вы просто не умеете его готовить». Таким образом коммитет снял с себя ответственность и выдал совершенно бесполезный язык. Примерно то же коммитеты сделали с PL/I и C++, только туда просто насовали кучу бесполезных фич - и я искренне не понимаю, почему столь плохой стандарт крестов продолжили использовать, пусть и с модификациями, при том, что PL/I и Algol 68 пошли верной дорогой - то есть, исчезли.

Проще говоря - «На форуме пофлудим, /а на большее ты не рассчитывай/»

Давай по делу: что вы мне можете предложить? У меня есть довольно много свободного времени, и пока что я его потихоньку вкладываю в том числе в свой хобби-проект, в котором я вижу смысл по крайней мере лично для меня. Что должно меня сподвигнуть писать софт по имени X?

Или вот, например: ограничение в 128 КБ на длину аргументов программы ничем не оправдано.

Потому, что архитектура elf, dll, exe … это зеркало технологий и
прекрасно характеризуется словами - «Каким ты был, таким ты и остался».
То же самое можно сказать и о разработке компиляторов.

За 50 лет ни одной идеи https://www.youtube.com/watch?v=lUV9W9ndorw

 Это какой-то позор

Давай по делу: что вы мне можете предложить?

А вы то причем здесь?

И добавлявшие кучу проблем, если вдруг строка не помещалась в 255 байтов. В современном паскале (fpc) строки неограниченные

Просто целое число, обозначающее длину строки, стало занимать 4/8 байт вместо 1 байта - вот и вся разница. В 80-е годы память была очень дорогая, и даже килобайтные строки были сомнительной роскошью. Для больших же структур были свои функции. По этой причине много софта 80-х имело ограничение в 255 на длину разных идентификаторов, заголовков, и прочего. В том числе MS Excel. Стала жирнее оперативка - расширили строки. В том числе в MS Excel.

Как у тебя сочетаются преимущество ограниченных строк и «ограничение в 128 КБ на длину аргументов программы ничем не оправдано» я вообще не понимаю.

«Строки явной длины» имеют неограниченный размер. Так-то и в юниксе было когда-то ограничение на размер командой строки в 512 символов. Но современное ограничение в 128 КБ ничем не оправдано.

Давай по делу: что вы мне можете предложить?

А вы то причем здесь?

А, ну хорошо, можно тогда дальше продолжать разговор про абстрактных людей, которые нам не ответят.

А, ну хорошо, можно тогда дальше продолжать разговор про абстрактных людей, которые нам не ответят.

Хороших идей у многих много, а работы - мало.

PS: Пусть хоть идеями поделятся …

Для фанатов Linux … /взято с сайта/

Что касается стабильности ОС, я скомпилировал и запустил этот двоичный файл объемом 860 МБ на 550 МГц ОЗУ K-6-2 и 128 МБ с GNU / Linux Debian 8, занял несколько часов, но выполнил задачу на 100%.

Уже на Windows Server на компьютере 4 ГБ, он был прерван до завершения.

Я не говорю, что X лучше, чем Y, просто сообщаю о факте.

PS: Пусть хоть идеями поделятся …

«А в ответ тишина, видно все занялись работой».

Просто целое число, обозначающее длину строки, стало занимать 4/8 байт вместо 1 байта - вот и вся разница.

https://www.freepascal.org/docs-html/ref/refsu9.html :

Ansistrings are strings that have no length limit, and have a code page associated with them. They are reference counted and are guaranteed to be null terminated.

Но современное ограничение в 128 КБ ничем не оправдано.

$ xargs --show-limits
Ваши переменные окружения занимают 407 байт
Верхняя граница аргумента длины по POSIX (эта система): 2094697
Самое маленькое разрешённое значение верхней границы аргумента длины по POSIX (все системы): 4096
Максимальная длина команды, которую мы можем использовать: 2094290

ограничение в 128 КБ на длину аргументов программы

Есть патч: https://www.mail-archive.com/bug-make@gnu.org/msg05522.html

Ну дык я и говорю, проблемы, о которых говорит Керниган, были, в основном, решены. Но потом, а не тогда, когда создавался C.

Взялся изучать Smalltalk. Процесс изучения выкладываю на видео

Видео должны снимать те, кто что-то шарит. Смысл твоих бухтелок, если ты сам ничерта не понимаешь в том, что говоришь?

Ядреееена... А ты дикция специально где-то ставил? Я как будто во времена учебы вернулся...

Я понимаю, что текст читает робот.

Серьезно? Это не автор? Тогда вдвойне - нахрена?

Серьезно? Это не автор? Тогда вдвойне - нахрена?

Наверное единомышленников ищет.

PS: «Но нас на мякине - не проведешь».
Вообще то Smalltalk интересен …

А, ну хорошо, можно тогда дальше продолжать разговор про абстрактных людей, которые нам не ответят.

Обиделись?

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

во время разработки важна сама архитектура

Но не все это понимают и «что-то там разрабатывают» и «что-то там у них и получается».

То есть у вас есть готовый список по настоящему веских причин, чтобы пилить передовую ОС, не похожую ни на что имеющееся и несовместимую ни с чем существующим (в том числе и в плане прикладного ПО)?

Да, есть:

• это круто;
• это очень круто.

Такой подход в качестве мотивации конечно тоже имеет место быть, только каким местом эту «крутизну» потом будете прикручивать к реальному проекту? Ну то есть, какие-то начальные требования к системе всё равно ведь нужны. Вон, к примеру, ReactOS пилят уже четверть века на основе одного лишь требования, чтобы там все виндовые программы и драйвера запускались. И с такой концепцией они будут продолжать эту мышинную возню ещё столько же времени, пока не забьют на всё. Но даже это, пусть и не совсем вменяемое требование позволяет хотя бы бесчисленное множество альфа-версий выпускать. А что такое «круто»? Что оно позволит выпустить?

И с такой концепцией они будут продолжать эту мышинную возню ещё столько же времени, пока не забьют на всё.

Не совсем так.
Да до релиза /скорее всего/ им далеко, но они разработали много хорошего API.
Поэтому этот проект можно рассматривать ни как ОС, а - см. выше.

К сожалению их API местами бывает «гвоздями прибито» к самому проекту.
К примеру понадобилось мне разработать API для работы с xml /нужно было/.
Разработал API совместимое с MSXML 4.0.
Как-то посмотрел исходники аналогичного API в ReactOS, а оно у них «гвоздями прибито» к проекту /далее комментариев нет, так как и так «все ясно»/.

А питон - наоборот не мощная среда и не особо простая для осовения

Разработал API совместимое с MSXML 4.0.

Потому, что у них хорошее API и хорошая документация.
MSXML 6.0 не стал реализовывать, так как xml использую лишь как один из вариантов представления метаданных /но не данных/.

Вы тут не меня, ни других особенно то не слушайте.
Советов много /и правильных/, но все они «прибиты гвоздями» к некоему «контексту».

Вообще вы молодец!

А форумы они обычно бывают такими

Вы дурак, ваши родители, бабка и дед и весь род до пятого поколения и конечно ваша собака и кошка.

Это и в лиспе легко делается: https://github.com/Kalimehtar/message-oo

Симпотно! И достаточно коротко в плане реализации.

Исходные исследовательские работы по STM никакого отношения к функциональщине не имели

Но ведь изначально речь была о том, ЧТО делает clojure более фп-языком. Удобные средства для реализации различных подходов к параллельным вычислениям и делают. Которые еще и реализованы искаробочно пачкой.

даже в хаскеле ты не сможешь написать корректные STM операции, если будешь выдавать побочные эффекты внутри транзакции

Сооветственно, язык, в котором органично работать без побочных эффектов - имеет все же некоторые преимущества.

акторность / параллеллизм кругом -> подталкивает к написанию именно в фп-стиле Не вижу взаимосвязи.

фп с чистыми ф-циям зачем вообще нужно, кроме отсутствия сюрпризов с неизвестными состояниями и зависимости от внешнего контекста? Правильно, для удобного способа реализации параллельных вычислений. Вот тебе и взаимосвязь.

Ну и где твои божественные многопоточные приложения на хаскеле?

Речь ведь не о хаскеле, а кложе.

А нету их

Да есть они, просто язык используется в специфических областях (это я о хаскеле).

классический смешанный стиль - это лучший способ писать многопотоки. Математики придумали красивую идею, только они забыли, что без побочных эффектов их программа никому не нужна.

Так речь не о том, что побочных эффектов вообще нет. А о том, что их скоуп ограничен и поддается контролю.

Ну вот элементарный пример - строки с подсчетом ссылок. Какая к черту разница, то ли я выделяю каждый раз новую строку, то ли ссылаюсь на старую при условии неизменности и получаю новую ссылку при изменении?

Выделяешь для чего? Приведи пример алгоритма.

Разраб Clojure прекрасно знает, что львиная доля реализации сделана на жаве, и нет никакого толку пытаться притворяться отдельным языком - это исключительно придаток для JVM и ее стандартной библиотеки классов.

Какая разница, как устроен компилятор. Язык предоставляет возможности писать в фп-стиле. То, что там java-объекты и jvm под капотом это просто слой абстракции, который вообще не используется, пока не нужны оптимизации производительности. А когда нужны, то тоже фп-стиль не обязательно уходит лесом, просто берутся более низкоуровневые структуры над которым все так же осуществляется декомпозиция чистых ф-ций.

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

На С можно имитировать ф-циональный стиль, только это неудобно и так большинство программ на С не написано, потому что «нинужно». Программ, а не отдельных компонентов и ф-ций.

Пожалуйста, не надо мне объяснять, как устроеный строки в паскалях - я слишком хорошо знаком с разными реализациям. В современных делфи родная строка представляет собой структуру:

StrRec = packed record
{$IF defined(CPU64BITS)}
  _Padding: Integer; // Make 16 byte align for payload..
{$ENDIF}
  codePage: Word;
  elemSize: Word;
  refCnt: Integer;
  length: Integer;
end;

В FPC ситуация такая:

TAnsiRec = Record
  CodePage    : TSystemCodePage;
  ElementSize : Word;
{$ifdef CPU64}	
  Dummy       : DWord;
{$endif CPU64}
  Ref         : SizeInt;
  Len         : SizeInt;
end;

TWideRec = Packed Record
  Len   : DWord;
  First : WideChar;
end;

TUnicodeRec = Record
  CodePage    : TSystemCodePage;
  ElementSize : Word;
{$ifdef CPU64}	
  Dummy       : DWord;
{$endif CPU64}
  Ref         : SizeInt;
  Len         : SizeInt;
end;

Функции COM на оффтопе принимают только выделенные через специальные функции строки в формате TWideRec, так что они являются вполне серьезным игроком.

На седьмом делфи были только AnsiString с полями Ref и Len.

Есть патч: https://www.mail-archive.com/bug-make@gnu.org/msg05522.html

Увеличили лимит в 10 раз. Круто. Но все равно костыль ужасный.

Ну дык я и говорю, проблемы, о которых говорит Керниган, были, в основном, решены. Но потом, а не тогда, когда создавался C

Давай посмотрим правда в глаза: проблемы Си не решены до сих пор. Проблемы паскаля были решены в 80-х.

А, ну хорошо, можно тогда дальше продолжать разговор про абстрактных людей, которые нам не ответят.

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

Человек грит «давайте же больше по делу и меньше болтовни», я отвечаю «хорошо, давай по делу», и тут начинается в ответ «не, я чё, я ничё».

ReactOS пилят уже четверть века на основе одного лишь требования, чтобы там все виндовые программы и драйвера запускались. И с такой концепцией они будут продолжать эту мышинную возню ещё столько же времени, пока не забьют на всё

MS прекрасно понимает, насколько трудоемко реализовать полную совместимость с их реализацией из-за огромного пласта недокументированных функций, количество которых со временем только росло, как и кол-во написанного бездарными кодерами софта, использующего недокументированные особенности.

ReactOS пилят уже четверть века на основе одного лишь требования, чтобы там все виндовые программы и драйвера запускались

Круто? Круто!

А что такое «круто»? Что оно позволит выпустить?

Софт выпустить позволяет, конечно же.

Что должно меня сподвигнуть писать софт по имени X?

Ни кто вас ни о чем не просит.
Нужно вам разрабатывать софт или нет, вам решать.

Удобные средства для реализации различных подходов к параллельным вычислениям и делают. Которые еще и реализованы искаробочно пачкой

Казалось бы, при чем тут ФП:
https://github.com/arximboldi/immer - Postmodern immutable and persistent data structures for C++
Сам спросил - сам отвечаю: оно тут при том, что убогие чистые ФП языке не предоставляют простых способов изменять значения, потому приходится извращаться. Однако, в языках с полноценной поддержкой императивного программирования можно использовать любой подход, по обстоятельствам. Это относится к крестам, это относится к clojure - в последней есть как жавовые типы, так и изменяемая ячейка-атом.

фп с чистыми ф-циям зачем вообще нужно, кроме отсутствия сюрпризов с неизвестными состояниями и зависимости от внешнего контекста?

ФП нужно, чтобы оттягивать на себя поехавших математики, чтобы те не убивали прогрессивные разработки в IT, как они это сделали с алголом 68. Практика показала, что на ФП ничерта нельзя написать, а там уже нет разницы, во сколько потоков это ничерта будет выполняться.

Да есть они, просто язык используется в специфических областях (это я о хаскеле)

Да, в написании компиляторов. Они сделали компилятор для написания компиляторов.

Выделяешь для чего? Приведи пример алгоритма.

Взять строку, добавить в конец перевод строки. Сейчас многие языки для этого просто создают новую строку и возвращают ее. Но если нужно брать подстроку о тстроки-аргумента, то тут частенько применяет ссылку на старую строку - при этом ничего не создается и не меняется, создается лишь дополнительный указатель.

Какая разница, как устроен компилятор. Язык предоставляет возможности писать в фп-стиле

Да много что предоставляет возможность писать в ФП стиле, просто clojure делает больший акцент на неизменяемые структуры в родных методах. IBM, вон, тоже советует в контейнерах использовать неизменяемые структуры, то есть, вместо изменения значения создавть новый объект. Но неизменяемые структуры - это далеко не панцея, потому есть мало желающих резко переходить на них.

На С можно имитировать ф-циональный стиль, только это неудобно и так большинство программ на С не написано, потому что «нинужно». Программ, а не отдельных компонентов и ф-ций

Так пишут на Си, потому что Си пощряет использование глобальных переменных. В нём нет вложенных функций, которые есть в том же паскале - это огромный провал в Си, на мой взгляд. Вместо этого для локальных данных используются глобальные переменные. Керниган упрекает паскаль в том, что в паскале нет статичных переменных (глобальных с локальной видимостью) в функциях, но решительно не видит, что механизм вложенных функций паскаля предоставляет намного более мощный инструмент. Например, он позволяет на инклудах добавлять некий набор стандартных функций в другую функцию так, что стандартыне функции будут работать с локальным контекстом без необходимости этот контекст явно передавать. Я вот сейчас пишу свою либу на Си, и мне нужно полностью избегать глобального состояния - мне приходится в каждую, каждую функцию передавать контекст, а потом еще из каждой функции насквозь передавать статус возврата, а значение передавать по ссылке.

Истину вам говорю: алгол 60 и паскаль намного опередили свое время, до сих пор мало языков в IT до них доросло.

можно имитировать ф-циональный стиль, только это неудобно и так большинство программ на С не написано, потому что «нинужно»

Большинство программ написано в смешанном стиле, даже на Clojure и Haskell. Вопрос тут скорее в соотношениях.

Вы тут не меня, ни других особенно то не слушайте. Советов много /и правильных/, но все они «прибиты гвоздями» к некоему «контексту».

Вообще вы молодец!

Спасибо за поддержку.

мне приходится в каждую, каждую функцию передавать контекст,

Что вы вкладываете в термин «контекст» и как вы его передаете?

А что такое «круто»? Что оно позволит выпустить?

Софт выпустить позволяет, конечно же.

Ага, а потом юзер будет чертыхаться и поминать разработчиков «добрым словом» после такой «крутизны». Говорю это не понаслышке, и примеров, прочувствованных на собственной шкуре могу привести больше, чем сообщений в этой теме.

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

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

То есть, на уровне архитектуры нужно «вшить» запрет на чрезмерное увлечение разработчиками создавать ни с чем не совместимые велосипедоподобные конструкции. Такая постановка задачи приводит к необходимости вообще стереть грань между системой и прикладным софтом, чтобы унификация коснулась всех аспектов такой системно-прикладной конструкции. А как стереть грань, если отдельные приложения (как это происходит сейчас) склонны раздувать до бесконечности свою функциональность, конкурировать между собой в одних и тех же предметных областях (и это при ограниченных ресурсах опенсорсных сообществ), и сбивать с толку пользователей постоянными регрессами, надуманными изменениями итак переусложнённых интерфейсов, и т.д.?

Стереть грань можно только одним способом - отказаться от привычных приложений вообще, и на архитектурном уровне закрепить первые два пункта философии Unix (программы должны делать что-то одно, а также - программы должны работать совместно). То есть, весь системно-прикладной комплекс должен состоять из массы взаимодействующих друг с другом программных компонентов, каждый из которых может выполнять только одну или небольшое число смежных функций. Также на архитектурном уровне нужно закрепить обязательное наличие документации, описывающей структуру и работу каждого компонента, а также наличие исходного кода для каждого компонента. Суть проста: если компонент не имеет документации и текста с исходниками - он неработоспособен, и система его «не видит». Тогда Опенсорс (а точнее единая системно-прикладная среда) станет по настоящему отличаться от проприетарного ПО (и выполнять основную свою задачу - ускорение разработки путём коллективных усилий на основе общих правил), а не фиктивно, как сейчас - с бесконечными холиварами, велосипедами разной степени корявости, и танцами с бубнами.

И всё вышесказанное проистекает только из первого требования к системе - быть максимально унифицированной. И именно из-за этого такая система не может быть совместимой ни с каким существующим ПО (за исключением различных показавших себя с лучшей стороны алгоритмов) - ведь проще всё продумать с нуля, чем оглядываться на «хвост» в виде массы зависимостей от постоянно обновляемых и устаревающих библиотек.

Но из-за этой самой несовместимости появляется второе требование к системе - она должна развиваться настолько быстро и эффективно, чтобы в короткие сроки обзавестись собственной экосистемой, способной полностью заменить (и превзойти) функциональность «утерянных» зависимостей. Как этого достичь? Архитектура всей системы должна быть упрощена настолько, чтобы во-первых, её можно было максимально легко и быстро модифицировать и дополнять; а во-вторых, чтобы любой, даже далёкий от программирования пользователь, мог бы на своём уровне понимания также легко и быстро освоить часть этой архитектуры, и тоже подключиться к разработке. То есть, модификация и дополнение системы должны вестись на разных уровнях абстракции (то есть на разных уровнях сложности), но при этом должна быть возможность вести разработку независимо (то, что делает один разработчик, не должно влиять на работу других разработчиков, главное, чтобы все соблюдали общие протоколы передачи данных между компонентами, и правила разработки).

Также, для ускорения разработки по максимуму нужно использовать графическую визуализацию этой самой разработки (с помощью блок-схем и других подходов), и всё это опять же, должно быть унифицировано. Ну и к тому же, пользовательский интерфейс (как текстовый, так и графический) тоже должен быть унифицирован и полностью изолирован от самой логики (образно говоря - типа гальванической развязки, но применительно к программам) в целях быстрого прототипирования интерфейсов при ещё нереализованных функциях, а также для быстрой смены пользовательских рабочих пространств.

Вот собственно и всё. Замечу, что я не использовал при описании гипотетической системы какие-либо технические подробности из существующих технологий. К тому же попытался объяснить всё на уровне понимания любого человека.

мне приходится в каждую, каждую функцию передавать контекст,

Что вы вкладываете в термин «контекст» и как вы его передаете?

Как ссылку на структуру, в которой хранятся необходимые идентификаторы, флаги, которые могут изредка изменяться. Обычно у функций есть уйма разных настроек, которые они должны читать извне, и Си не предоставляет никаких удобных механизмов для реализации этого механизма, кроме глобальных переменных. Для обхода проблемы придумали костыль под названием «локальная память потока» (TLS), но это решение не спасает от ситуаций, когда в одном потоке несколько контекстов - в таких ситуациях проги на Си обычно временно изменяют значение в TLS, что есть отвратительное решение, на мой взгляд. А всё из-за того, что Керниган не смог придумать удобных механизмов передачи контекстов с предыдущих уровней вызова.

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

Почему я должен париться о людях, которым на меня плевать? СПО не было свободным и не планирует им становиться - оно было и будет находиться под чутким надзором корпораций, которые и принимают основную массу решений в СПО. Линукс, как ядро, был свободен в 1991-1992 годах, но очень быстро его прибрали к рукам корпорации, и свободен он быть перестал. Ну, или я бы дал иное определение свободы: отсутсвие принадлежности к единственной корпорации.

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

Это пустые абстрактные фразы ни о чем. В каких коровах собрались мерять абсолютное значение согласованности и унификации?

Почему я должен париться о людях, которым на меня плевать?

Тут дело в психологии. Грубо говоря, можно воспользоваться формулировкой - «мы в ответе за тех, кого приручили». Каждый, выдавая что-то своё «в массы», уже ответственен перед теми, у кого это что-то нашло отклик в сознании. Вон даже здесь, в этой теме, некоторые умники обвиняют меня, что я краду их время, выкладывая видеоролики.

Что тогда говорить о разработчиках софта, пригодного для использования, нашедшего отклик в людях, которые вдруг обнаруживают, что автор программы просто тешит себя «крутостью», занимаясь самодурством и ведя проект в противоположном ожиданиям сообщества направлению (как пример - история развития видеоредактора Cinelerra)? Как бы ни пытались фанаты опенсорса оправдать такое поведение свободой, типа «автор вам дал халяву, и вправе делать что хочет, а вам не нравится, делайте своё» - это не срабатывает. С момента, когда программа начала завоёвывать популярность, её автор становится ответственным за ненужную нервотрёпку пользователей. Есть ещё такая поговорка - «Взялся за гуж, не говори, что не дюж». И не важно, бесплатно взялся или за деньги.

А чтобы и пользователям на автора было не плевать, им изначально надо дать максимально полную документацию по начальной версии программы, саму архитектуру сделать максимально понятной для понимания любым человеком, к тому же заранее продумать организационные вопросы по дальнейшей, уже коллективной разработке и ведению документации. Чтобы любой мог подключиться к разработке даже если автор забил на всё. А не так, как в своё время (2013 год) ведущий разработчик видеоредактора Kdenlive словил депресняк из-за предстоящего масштабного рефакторинга кода, и сообщество полгода рвало на себе волосы, думая как им быть дальше без «гуру». Благо тот через полгода одумался и объявился.

Это пустые абстрактные фразы ни о чем. В каких коровах собрались мерять абсолютное значение согласованности и унификации?

Ни о чём, это когда в качестве требований к проекту применяется формулировка «это же круто». Здесь же под унификацией может подразумеваться, например, единый стиль конфигурационных файлов, единый способ (пусть и с возможностью некоторой настройки под свои задачи) управления конфигурациями с помощью визуального интерфейса, единый стиль пользовательского графического интерфейса (допустим нечто, по типу применяющегося в Blender 3D), унифицированный стек протоколов передачи информации между отдельными программными компонентами. Да много чего ещё «единого» можно напридумывать, если говорить не здесь, навскидку, а при непосредственной разработке.

Смотря что ты считаешь проблемами C. На своём месте он всё ещё весьма хорош.

Однако, в языках с полноценной поддержкой императивного программирования можно использовать любой подход, по обстоятельствам.

Нельзя. Извини, но в ФП ты явно не шаришь.

Как ссылку на структуру, в которой хранятся необходимые идентификаторы, флаги, которые могут изредка изменяться.

Правильный подход.

PS: Предыдущие сообщения не подписывал.

Ни каких шестерых Владимиров нет.
Имеется один или два тролля, которые злобствуют в отношении меня.
Да и стиль их сообщений легко узнаваем.

Владимир

Хорошие суждения.
Спасибо!

Владимир

Sorry.

Мы рождены, чтоб Linux сделать былью,
Преодолеть пространство и простор,
Нам Linux дал стальные руки-крылья,
А вместо сердца — Метапрог.

Владимир

Для обхода проблемы придумали костыль под названием «локальная память потока» (TLS),

Экспромтом.

Еще об одном подходе - об аллокаторе.
Блоки памяти аллокатора могут содержать «контексты функций», …

PS: «И здесь Остапа понесло …».

Владимир

Нельзя. Извини, но в ФП ты явно не шаришь.

Ни когда не использовал ФП.
Конечно читал о ФП и «устройство трактора знаю».
Вот у меня к вам вопрос /это не сарказм/.

Куда же кобылу впрягать?

Владимир

Куда же кобылу впрягать?

Когда ФП полезен?

Владимир