Search
Write a publication
Pull to refresh
-1
0
Сергей Гусев @sgusev

User

Send message

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

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

Круды.

Ладно, конкретно с этим пунктом я погорячился - не в том смысле, что этого не надо делать, а в том, что я это упомянул, да ещё и в самом начале. Естественно, это не первостепенная проблема.

Расскажите, пожалуйста, почему в C++ категорически нельзя делать стандартный менеджер пакетов, расширенную стандартную библиотеку и вменяемо оформленные ключевые слова?

Зашел в репозиторий, и сразу же на втором скрине вижу в десятки раз более простой и безопасный код:

$cat hello.cpp2

// left-to-right, order-independent,
// context-free, "import std;" default

main: () -> int = {
    hello("world\n");
}

hello: (msg: _) =
    std::cout << "hello " << msg;

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

В отличной статье Разработчик с мозгом груга есть замечательный момент:

груг хочет фильтровать список на java

«Ты преобразовал его в поток?»

ладно, груг преобразовал в поток

«Хорошо, теперь можно фильтровать»

хорошо, но теперь нужно вернуть список! а есть поток!

«Ты собрал свой поток в список?»

что?

«Определи Collector<? super T, A, R>, чтобы собрать поток в список»

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

добавь обычную вещь типа filter() для списка и пусть возвращает список, слушай меня разработчик java api большой мозг!

никому не нужен «поток» и никто не слышал про «поток», не сетевой api, все груги java используют списки мистер большой мозг!

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

Просто дайте мне, блин, обычные плюсы, ровно с тем же самым синтаксисом, но с

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

  • сильно расширенной стандартной библиотекой, учитывающей современные и используемые стандарты

  • стандартным менеджером пакетов

  • удалёнными из языка совсем устаревшими конструкциями (да, я вижу, что они удалили union и адресную арифметику, что тоже дискуссионно)

  • вменяемо оформленными ключевыми словами, а не безумными [[nodiscard]]

  • и самое главное - с возможностью писать как можно меньше кода, получая при этом самое очевидно ожидаемое поведение, которое не надо потом часами дебажить в отладчике

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

Есть один неочевидный сценарий, при котором сборка приложения и его подпись должны явно разделяться на 2 этапа: брендированная версия вашего (коммерческого и закрытого) приложения для других компаний. Вы по договору не должны делиться кодом с этими компаниями, только предоставлять готовые бинари, а они не хотят давать вам свои сертификаты для подписи.

Проблема тут в том, что процесс создания конечного приложения выглядит так: компиляция кода в бинарники -> подпись -> упаковка в dmg/pkg (а на винде - ещё и повторная подпись результирующего exe файла инсталлера). Можно, конечно, просто собрать бинарники и отдать архив с ними с чистой совестью, пусть пакуют как хотят, нооо это только в идеальном мире. В реальной жизни заказчику нужно готовое приложение "под ключ", и его не волнуют все эти технарские термины вроде CI/CD.

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

Я собрал вашу игру, у меня картинка не расслаивается, как будто бы всё отрисовывается нормально. У меня правда макось и Qt 5.15, но не вижу, как бы это могло повлиять.

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

Я прекрасно понимаю, что вы — не sales manager, не юрист и не CEO. Вы разработчик, который работает непосредственно в Qt Company и в частном порядке пишет познавательные вещи о работе компании для русскоязычного сообщества, и это супер круто. Я также понимаю, что вы пишете в некоторых случаях ваши личные догадки, и ни в коем случае не пытаюсь добиться от вас истины в последней инстанции. Я просто очень сильно удивлён условием перехода между лицензиями, и пытаюсь обосновать своё удивление, потому как мало ли я что-то не так понял.

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

И, да, если будет возможность, запилите success story попадания в Qt Company, интересно же :)
если вы задались целью обмануть/нарушить лицензию
В качестве небольшого дисклаймера, особенно ввиду вашего апдейта к статье, хочу сказать, что я всеми руками и ногами против любых нарушений интеллектуального права, лицензионных соглашений и законодательства. В сфере моей деятельности я использую Qt по лицензии LGPL, линкуюсь только динамически, не модифицирую исходный код Qt (т.е. поставляю оригинальные библиотеки из вашего SDK), не копипащу код/ресурсы из поставки Qt.

Вопрос изначально задавал как раз с мыслью «а не будет ли больше профита от коммерческой лицензии?», потому как мысль давно была в голове, да вот внятного описания этих самых профитов я до этого нигде не видел. И вот теперь я вижу, что просто так (в условный один клик) пересесть с Open Source на коммерческую лицензию не получится, вот и удивляюсь, почему так. Собственно, я на 100% диванный продажник и маркетолог, но кажется мне, что такой подход больше отпугивает потенциальных клиентов, которые уже используют Qt, чем стимулирует сразу выбирать коммерческую лицензию. Будь я реально владельцем стартапа с уже рабочими приложениями в продакшене, мне было бы страшно писать в Qt Company о том, что вот-де ребята, я тут 5 лет бесплатную лицензию использовал, из-за чего вы недополучили прибыли на 100500 денег, что делать? Например потому что после этого существует риск привлечь к себе повышенное внимание Qt Company и активистов FSF, даже если таких прецедентов немного и я соблюдал все правила лицензии.

Получается, та другая компания — дураки, а вы — удалый мушкетёр? :)
Нет, потому как другая компания
приобрела коммерческую лицензию сразу на старте проекта и всё это время платила за обновление поддержки и получение апдейтов
Вы предоставляете возможность бесплатно пользоваться — компании пользуются, пока лицензия удовлетворяет их требованиям. Если какая-то компания выбрала коммерческую лицензию на старте разработки, то им это зачем-то надо (техподдержка, приоритет по фич-реквестам, денег куры не клюют), в противном случае они может и не дураки, но явно теряют деньги там, где можно сэкономить. Я руководствуюсь исключительно рыночными принципами: если я вложил условные 500$ в 2 месячных лицензии Qt, я не вложил их в зарплату дополнительного программиста, а это очень часто бывает критично, особенно в стартапах. Ещё раз повторюсь, я говорю про осмысленное взятие лицензии LGPL и полное соблюдение всех её условий, а не бесплатное использование Qt так, как вздумается.

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

У вас до перехода на коммерческую лицензию код был под лицензией Open Source.
Минуточку, я говорю про свой код, а не про код Qt. Мой код находится под коммерческой лицензией моей компании и эта лицензия не меняется из-за смены лицензии одной из библиотек, которую я использую. Соответственно все наработки, которые я делал ранее в моём коде, как были под лицензией компании, так и остаются, с ними ничего не происходит.

Вы попользовались Open Source и, когда это стало удобно, коммерцизировались.
Да, и начинаю платить вам деньги, хотя раньше не платил. А по вашим правилам я вам не могу платить, даже если очень хочу и начал зарабатывать достаточно для этого. Несу деньги, а Qt Company говорит, не, нельзя так, сначала купи у нас лицензию, и потом начинай разработку заново.

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

Таковы условия — нельзя смешивать Open Source и «коммерческий» код.
Что вы понимаете под термином «смешивать код»? Я же не вставляю куски из исходников Qt в свой проект.

Вот я написал калькулятор. У меня получилось 3-4 файла с исходным кодом на C++, в которых используются некоторые классы из QtCore и QtWidgets: кнопки, контейнеры, QString и так далее. Мой код сам по себе, и лицензия на него, никак не изменятся после того, как я приобрету коммерческую лицензию Qt и заполучу коммерческие версии SDK и либ. В чём тогда смешение кода? Я максимум перекомпилирую просто тот же самый свой код с новыми либами, а возможно и просто подменю libqtcore и libqtwidgets без изменения своих бинарников.

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

Но в реальности всё не так идеально, не все знают об этом условии.
Приведу другой пример: изначально я разрабатывал коммерческий проект, полностью удовлетворяющий условиям LGPL. Всё у меня было хорошо, потому что я не планировал нарушать какие-либо пункты лицензии — в случае моего приложения ничего такого и не требовалось — и благодаря этому не платил денег. Таким образом, я взял Open Source вариант Qt и долгое время не жалел о своём выборе. Потом проходит время, возможно годы, и мне становится позарез нужно, например, поставлять приложение единым бинарником (как это делает телеграм). Вот расшибиться в лепёшку, как мне нужна такая возможность, инвесторы вдруг начали требовать, и пользователи, и различные магазины приложений, и даже баба Клава с рынка, и соответственно с этого момента мне нужна коммерческая лицензия. То есть я знал всё что мне нужно до начала разработки и осмысленно сделал выбор в пользу LGPL, но со временем условия изменились, рынок изменился, и мне нужно подстраиваться. А включать дурачка и писать в Qt Company «ой, я и не знал» я тоже не хочу, потому как потом совесть замучает (нет, на самом деле я просто не хочу тратить N рабочих часов на какую-то малопонятную переписку).
Немного не понял следующий момент:
Также иногда встречаются ситуации, когда та или иная компания пару лет вела разработку своего проекта под Open Source лицензией, а перед релизом продукта “вдруг” узнала об её ограничениях и захотела приобрести коммерческую лицензию. Вообще, такое не допускается, лицензия должна выбираться на старте проекта, до начала разработки, и если вы взяли Open Source, то и распространение должно осуществляться в соответствии с требованиями GPL/LGPL. Но если такое всё-таки случилось не “вдруг”, а действительно по незнанию — свяжитесь с The Qt Company и опишите ситуацию.

Все имена вымышлены, а все совпадения случайны, но подозреваю, что таких ситуаций довольно много. Допустим я некоторое время назад основал стартапчик «Злобные буратины», в рамках которого разработал несколько приложений на Qt. Распространял я эти приложения с закрытым исходным кодом, линковался динамически, так как на момент создания стартапчика времени разбираться и денег на коммерческую лицензию не было. Кажется, что все условия LGPL соблюдены (хотя, как оказывается, вы и сами не до конца понимаете), время идёт, вопрос лицензирования периодически появляется в голове, но остаётся на втором плане.

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

Исходя из вашего комментария кажется, что я не могу просто перекомпилировать свои приложения с новыми либами, выставить версию на 1 выше и заново распространить среди пользователей. Однако, я не совсем понимаю, почему так? Вот я разрабатываю приложение, линкуясь с Qt по LGPL, вот я достаточно вырос и готов платить вам денежку, взамен получая юридическое спокойствие и разные плюшки. Или же, как буквально следует из вашего примера, я ещё даже не выпустил своё приложение — что мне мешает перекомпилировать исходники с новыми библиотеками и зарелизить программу?

А так спасибо, статья очень хорошая, проясняет разные интересные моменты по Qt.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity