LINUX.ORG.RU

*GPL vs пермиссивные в отечественном программировании в 2025

 ,


0

0

Я понял, в чём проблема с A2 и ЯОС. Надо было раньше понять. Основные усилия находятся в закрытых форках. Да, меня предупреждали, но такой вот я тугодум. Проблема даже не в том, что концепция ЯОС как ОС на русском языке и не на языках из семейства Си мало кому интересна. Проблема в том, что точка старта низкая. Если бы проект был открыт, его качество в стартовой точке было бы выше. А так, по сути дела я начинал с помоечного открытого варианта, который уже на тот момент был хуже закрытых форков. Поскольку работа над закрытыми форками A2 продолжается и люди работают над этим за зарплату, отставание ЯОС от закрытой версии только увеличивается. Понятно, что уже поздно и специфика ЯОС как ватного проекта будет мешать и впредь, но в принципе, как сейчас поживают проекты ОС и тулчейнов под LGPL? Я видел обратный процесс, когда Racket переехал на пермиссивную лицензию. Golang изначально под пермиссивной лицензией. Clang стал за это время лучше конкурировать с gcc. Есть ли вообще истории успеха в этой области за последнее время, или движение GPL выродилось?

★★★★★

Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от den73

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

anonymous
()
Ответ на: комментарий от monk

Ровно как и пояснение логики решения не имеет ничего кроме доступной формой пояснения это самой логики. Вы еще образное мышление запретите и о боже, есть дальтоники: срочно, СПРАВИТЬ ДАЛЬТОНИКОВ, у них цветокорректция в голове не такая как у Вас.

anonymous
()
Ответ на: комментарий от monk

ЯП и Тьюринг полный ЯП позволяют решать задачки, - согласен. Не согласен, Я вообще не навиже слово АЛГОРИТМ (можете туда еще записать ПАРАДИГМА), что частное решение задачи есть (чпоньк, включай заднюю мысль) про симметричный тьюринг полный ЯП. Вот академическая задача про hello world в тыщу строк на С, потому что можем поверю. Про подмножество ЯП, вносите в студию: покрывало покрывало покрывало.

anonymous
()
Ответ на: комментарий от den73

Нет, это не фанатизм, а приведение исходника в соответствии с российским законодательством.

Спорить не буду.
Я бы поступил так:

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

  • конечно написал бы мануалы по тархитектуре проекта, назначении подсистем и API;

  • .. .

Почему так?

Чтобы другим программистам было легче понять как устроен проект.

«Руссификация» в данном случае заключалась бы не в замене всё и вся на кириллицу, а хорошее документирование модулей и мануалы для разработчиков.

Посмотрите например исходники PostgreSQL.
Чтобы понять архитектуру проекта нужно много месяцев потратить на изучение исходников, чтобы её понять,

anonymous
()

Уважение за небезразличие к таким сложным вопросам. Надеюсь что эта статья (пока ставил чайник, вспомнил, когда размышлял) https://lwn.net/Articles/641244/ поможет Вам в оптимальный сроки продуктивно реализовать интерпритацию так, что молучится ЯП-API c перспективой для ОС. Мир. ЗЫ: тем не менее, я умоляю, если сделает 1С-ОС, - без фанатизма. Лучей добра.

anonymous
()
Ответ на: комментарий от anonymous

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

Так топикстартер его перевёл. Причём именно с английского на русский. Также, как Лозинский перевёл «Гамлета» и новый текст стал подмножеством русского языка, хотя Шекспир писал на английском.

Если же не считать оберон подмножеством английского, то ЯОС остался тем же обероном, в который добавлены метапроцедуры и улучшен отладчик. То есть тогда вообще нет повода осуждать его работу.

А моя Адина всего лишь расширение бесскобочного синтаксиса для Racket: https://rosettacode.org/wiki/100_doors#Adina

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от anonymous

ЗЫ: тем не менее, я умоляю, если сделает 1С-ОС, - без фанатизма.

1С ОС нет смысла разрабатывать.

Ныне реализовано динамическое использование модулей в библиотеках в run-time.

Но есть ещё данные, которые так же за частую нужно связывать в run-time с работающей программой.

Вот этого ныне практически почти никто не занимается.
Всё и вся возлагают на этап компиляции.

Понятно, что при этом у программистов просто нет возможности производить динамическое связывание данных с программой в run-time.
Компиляторы понимают лишь статически, определённые данные.

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

Ныне веду разработку технологии использования метаданных в run-time.

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

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

Ныне использую линкеры, которые не понимают, что такое динамические данные и что с ними нужно делать.

Конечно через какое-то время произведу доработку линкера для Linux так, чтобы он мог помогать программам использовать динамические данные.

Здесь удивляет то, что проблема не нова, но «воз и ныне там».

В 1С как раз в конфигураторе программисты и определяют динамические данные, но у них нет подсистемы управления динамическими данными.

Вместо этого у них 50000 классов, которые умеют использовать метаданные, заданные в конфигураторе.

У меня нет 50000 классов, а разрабатывается API, которое позволяет использовать динамические метаданные, определённые в run-time.

Поэтому в частности нет необходимости в разработке 50000 классов.

Революции конечно с моей стороны никакой нет.
А так всё как обычно.
Все всё знают и понимают, а «воз и ныне там».

anonymous
()
Ответ на: комментарий от anonymous

Поэтому в частности нет необходимости в разработке 50000 классов

std, STL, template, class из C++ не использую.

Почему?

Разрабатываю API, которое позволяет использовать не статически, опредлелённые данные при компиляции, а динамически определённые в run-time метаданные.

Например, map пригоден для использования данных, для которых в run-time определены, метаданные.

И.т.д. и.т.п.

Скажу по великому секрету - «И хрусти и очень вкусно».

В частности на основе своего core разработал crt аналогичное, разработанному фирмой 1С.

Почему?

Потому что, з/п получаю за разработку конфигураций для 1С 8.3 и даже 1С 7.7.

Например теперь в 1С 7.7 имеется функционал аналогичный 1С 8.x.

Здесь главное то, что crt «гвоздями не прибито» к 1С и его можно использовать в любом ЯП.

Цели разработать а-ля 1С никогда не было, но такова моя селяви.

Ещё в оправдание скажу, что в crt фирмы 1С много полезных объектов и API для их использования не сложное.

anonymous
()
Ответ на: комментарий от anonymous

А теперь немного иронии.

Много раз говорил о том, что технологии разработки программ застыли в 60-х.

https://www.opennet.ru/opennews/art.shtml?num=64308 В состав GCC одобрено включение фронтэнда для языка Алгол 68 23.11.2025 08:25

Так Алгол не сильно и устарел …

anonymous
()
Ответ на: комментарий от den73

Если что, я за обсуждением уже особо не слежу, так что мог что-то пропустить.

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

anonymous
()
Ответ на: комментарий от firkax

Называй хоть osv_s, хоть qxt_z, хоть ргя_й, это всё равно останется «какой-то отчёт»

Фил Картон (Phil Karlton), программист из Netspace, сказал, что в компьютерной науке есть только две главные проблемы: присваивание имен элементам и аннулирование кеша.

Мне кажется, ты слишком недооцениваешь важность именования.

monk ★★★★★
()