LINUX.ORG.RU

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

 ,


0

0

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

★★★★★

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

Что непонятного в английских названиях переменных?

pCurBlockArray это курсор? проклятый? вылеченный? или пульсирующего тока?

cntItemBlocks - это считать-блоки-элемента? или количество-блоков-элемента? или содержимое-блоков-элемента?

Понятно, что «все привыкли», но это явно не норма.

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

pCurBlockArray это курсор?

Cur - сокращение слова «current» (типичное сокращение).

cntItemBlocks - это считать-блоки-элемента?

cnt - сокращение (count).
Item - элемент.
Blocks - блоках (s в конце).

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

Видите как полохо, когда комментариев нет.
А многие утверждают, что комментарии нужны.

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

Но кто о них знает кроме меня?

Поэтому в исходниках имеются краткие комментарии о назначении полей, … (иногда и подробные)

Как-то так.

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

cnt - сокращение (count).

Так это «считать» или «количество»? Или вообще «счётчик»?

Видите как плохо, когда комментариев нет.

Плохо, когда имена не очевидны для читающего.

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

Для человека, обычно, нормой является описание алгоритмов на родном языке.

#monk у меня комментарии вседа имеются (редко, когда нет).

  ArrayBlock_ *pCurBlockArray = nullptr;                   // Адрес текущего блока в динамическом массиве
  ULONG       cntItemBlocks   = NULL;                      // Общее количество элементов в просмотренных блоках
  ArrayBlock_ *pNewBlock      = nullptr;                   // Адрес нового блока
anonymous
()
Ответ на: комментарий от monk

Так это «считать» или «количество»? Или вообще «счётчик»?

cnt - стандартное сокращение (счётчик, количество).

Вот что теперь скажут те, кто считает, что комментарии излишни?

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

ULONG cntItemBlocks = NULL; // Общее количество элементов в просмотренных блоках

А вот это хороший пример, где имя противоречит описанию.

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

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

Это где такая норма соблюдается?

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

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

Вот что теперь скажут те, кто считает, что комментарии излишни?

А мы ещё не рассмотрели вопрос наличия хоть небольшого комментария о назначении: алгоритма, блока строк, …

Можно не помещать комментари в исходнии?
Можно.
Но это ИМХО элемент «культуры» оформления исходного кода (вопросов здесь не мало).
Понятно, что могут быть использованы разные методики, но не БАРДАК.

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

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

Если код на иностранном, приходится комментировать строки кода.

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

Привести код на 1С без комментариев (на кириллице)?

А он в конфигурациях почти весь такой. Комментарии только перед функциями и то не всегда.

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

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

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

Эх ребята.
Вы не знаете что такое война или быть пол года без света.
Не возможности купить булку хлеба.
А у меня такое было.
Да много невзгод по жизни было.

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

А где ты видел описания алгоритмов на английском в программировании? С, Java, Python - это английский язык по-твоему?

Конечно. Все действия и переменные в них принято именовать по-английски. При том, что Java и Python синтаксически позволяют использовать кириллицу, но «у нас так не принято».

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

Без комментариев её нужно ретранслировать.

Она описана в сопровождающих документах, а не в комментариях. В комментариях в шапке метода должна быть ссылка на пункт архитектуры.

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

При том, что Java и Python синтаксически позволяют использовать кириллицу, но «у нас так не принято».

ИМХО всё зависит от предметной части проекта.
Иногда кириллица полезна, иногда излише её использовать.
А вот хорошие комментарии всегда экономят время.

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

Она описана в сопровождающих документах, а не в комментариях. В комментариях в шапке метода должна быть ссылка на пункт архитектуры.

Что касаемо бухгалтерскиз задач, то зачастую в них не логика, приемлемая программисту, а вышестоящему руководству.
Здесь вариаций не мало.
Бывает добавляешь документы, …, а через время лишь выясняется их назначение.
Например скрыть от вышестоящих организаций что-то или «запудрить мозги» вышестоящим организациям, …
В это мире неправды, правды весьма мало.

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

Хорошие комментарии встречаются ещё реже, чем хорошая документация.

Так не будешь же в исходниках писать трилогию «Война и мир»?
Поэтому некоторые комментарии с стороны кажутся «не очень».
Но они понятны разработчику.

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

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

У кого как.
Люди весьма разные.
Я вот например: не матерюсь, не кину бумажку на тротуаре, …
И разработка проекта имеет некую «культурность».
Здесь более зависит от того каков характер человека, …

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

Серьезно, все эти тыщи ЯП являются подмножеством английского? А филологи в курсе?

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

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

Здесь больше зависит от сроков. Если надо срочно сдать кучу задач, то будешь делать чтобы работало, а комментирование где-то в конце. А если потом свободного времени не появится или тебя перебросят на другой проект, то так и останется в коде новая версия, а в комментариях старая. И это хуже, чем когда комментариев нет вообще.

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

https://softwareengineering.stackexchange.com/a/298

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

Вот Библия и Заповеди Господа как раз о том, как человеку стать человеком (если кто понимает о чём речь).

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

Диагноз понятен, вопросов больше не имею.

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

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

Не так, можно понять общую суть по знакомым именам, если они достаточно подробные, но досконально понять логику работы нетривиальной программы человеку далекому от IT нереально. И наоборот, человек хорошо знакомый с данным ЯП, разберется в программе, даже если не знает всех терминов.

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

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

Хочешь сказать, англоязычный непрограммист не поймёт код вроде такого?

function showNotification(timeout) {
    revealNotification();
    var defaultTimeoutInMilliseconds = 5000;
    timeout = timeout || defaultTimeoutInMilliseconds;
    var userRequestsSkip = timeout === -1;
    if (!userRequestsSkip) {
        setNotificationExpiration(timeout);
    }
}

function revealNotification() {
    var idAttributeSelector = '#';
    var notificationBarId = 'notification';
    var notifyNode = $(idAttributeSelector + notificationBarId);
    var transitionTimeInMilliseconds = 200;
    notifyNode.slideDown(
        transitionTimeInMilliseconds,
        function noop() { }
    );
}

Бухгалтеры куски кода на 1С вполне нормально понимали, не будучи программистами. Когда надо было показать, по каким условиям НДФЛ считается в 1С, например.

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

И наоборот, человек хорошо знакомый с данным ЯП, разберется в программе, даже если не знает всех терминов.

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

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

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

Неплохой проимер кода, который лишний раз подтверждает то, что комментарии нужны.

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

Хочешь сказать, англоязычный непрограммист не поймёт код вроде такого?

По-твоему это нетривиальный код? Пара функций, сплошные присваивания, впрочем, даже на операторах $, ||, ===, ! и на вызовах функций, уверен, многие споткнутся.

Бухгалтеры куски кода на 1С вполне нормально понимали

Бывалые бухгалтеры - наверняка, поди не первый раз код 1С видели.

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

Давай на Go)

anonymous
()