Здравствуйте, Ватакуси, Вы писали:
M>>Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить В>Никогда не встречал. Может не компилироваться из-за ц++ хелла на твоей машине, это да. Раза 3 или 4 приходилось долго танцевать.
M>>>Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить В>>Никогда не встречал. Может не компилироваться из-за ц++ хелла на твоей машине, это да. Раза 3 или 4 приходилось долго танцевать.
N>Я пару раз попадал на это
На ц++ хелл? Или откатывание пипа?
Здравствуйте, kaa.python, Вы писали:
KP>В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами. KP>Можно-можно. Python по-умолчанию доступен много где. KP>И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.
Всё, я перетрудился добавляя сторонние библиотеки в свой проект, пойду отдохну. Другое дело, что не нужно заниматься популизмом. Или нужно?
Проблема здесь вовсе не в добавлении сторонних библиотек, а в том, что:
1) Открытый интерфейс этих библиотек не соответствует собственному восприятию понятий, причём в любом языке программирования и практически любой библиотеке алгоритмов. Потому когда кто-то говорит, я сел и написал за 5 минут на Python, и сторонние библиотеки подключил легко, а вот в C++ замучался, очень тяжело. Хочется спросить, а сколько времени ушло на изучение того же Python. То есть я зная как подключить библиотеки в C++ и чисто для примера не зная как это делается в Python, всё равно как бы должен считать, что в Python это всё проще.
2) Это как раз тема топика. Внезапно языки программирования и библиотеки алгоритмов со временем меняются. Чтобы предотвратить отрицательные эффекты в лучшем случае, что можно сделать при использовании сторонних библиотек, это вынести вызов чужих библиотек в собственноручно созданную обёртку и работать с ними только через неё. В противном случае чужой код будет размазан по собственному. Любое изменение чужого кода автоматически может сломать свой собственный. А нужно ли покрывать чужой код тестами, то есть гарантируется ли, что даже не сломавшись он будет отрабатывать так же.
Несколько раз перечитал твои комментарии, но так и не понял смысла. Я не утверждаю, что его там нет, это я просто не понял. Предположим у нас есть учебный пример алгоритма.
Остальные языки нас вроде бы как не интересуют, но чисто для примера.
Assembler компиляция
gcc -m32 hello_world.s -o hello_world_asm
Assembler запуск
./hello_world_asm
Bash запуск
sh hello_world.sh
Go запуск
go run hello_world.go
или
Go компиляция
go build hello_world.go
Go запуск
./hello_world
Java компиляция
javac HelloWorld.java
Java запуск
java HelloWorld
Lua запуск
lua hello_world.lua
Pascal компиляция
fpc hello_world.pas
Pascal запуск
./hello_world
Php запуск
php hello_world.php
Prolog запуск
swipl -q -l hello_world.pl
Ruby запуск
ruby hello_world.rb
Есть различия в точке доступа в приложение, но вот прямо принципиальной разницы, почему Python (а мне из скриптовых вообще-то нравится лишь Lua) не вижу. Тот же Bash через аргументы командной строки использует другие программы как библиотеки алгоритмов. Но разве это его уникальное свойство.
К тому же, выражение на Python всё есть, но откуда оно там взялось. Ах, да, большая часть это вызовы на библиотеки алгоритмов C/C++. Это логично, потому что скрипты в том числе для этого и созданы. Другое дело, что это не делает скрипты принципиально лучше, ни для разработки, ни для прототипирования. Дописать функционал, которого нет в основной программе, это да, а вот когда пишешь эту самую программу не получаешь никаких преимуществ.
Ладно, это всё были хелло ворлды. Если не жалко времени приведи конкретный "внушительный" пример, чтобы я мог посмотреть на код и сказать, — "О, Python это круто, а вот тот же самый проект или прототип на C++ полное говно".
N>На откатывание пипа. Вручную подбирал версию пипа и библиотек.
Я на Python не писал ничего серьезного, но давно понял, что любой проект сложнее скрипта из одного файла нужно начинать с установки и настройки virtual environment. Неужели кто-то делает по-другому...
Здравствуйте, Masterspline, Вы писали:
M>Я на Python не писал ничего серьезного, но давно понял, что любой проект сложнее скрипта из одного файла нужно начинать с установки и настройки virtual environment. Неужели кто-то делает по-другому...
Я также делаю, но оно же не обязательно будет работать. Ты ставишь requirements для одного проекта, пишешь код, например, сервера. Потом хочешь сделать, чтобы он распознавал котиков на фотках. Находишь предобученную модель, подключаешь tensorflow, а он не работает. Ему нужен другой python, более древний. И какой-нибудь другой protobuf. Или numpy. Потом выясняется, что это старая версия или версия, которая требует строго определённые версии пакетов, ни больше, ни меньше. Не случайно сейчас самые популярные репозитории начинают раздел Install со слов: "Скачайте такой-то Докер..." Как раз потому что в версиях Питона и библиотек разброд и шатание и не так просто подбирать рабочие комбинации для разных библиотек.
Здравствуйте, velkin, Вы писали:
KP>>В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами. KP>>Можно-можно. Python по-умолчанию доступен много где. KP>>И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.
V>Да, знаем.
Не похоже
V>Например, вот так: V>
V>LIBS += -lcryptopp
V>
А так же LIB_PATH, INCLUDE_PATH, а, библиотеку же еще скачать и собрать надо, и хранить, и ключи компиляции/линковки должны совпадать, под Linux еще RPATH или LD_LIBRARY_PATH + возможные зависимости. Еще и инсталятор нужно, под Windows хоть из той же папки грузится, тут хоть архив на первое время можно сделать.
V>Всё, я перетрудился добавляя сторонние библиотеки в свой проект, пойду отдохну. Другое дело, что не нужно заниматься популизмом. Или нужно?
Не нужно
V>Проблема здесь вовсе не в добавлении сторонних библиотек, а в том, что:
V>1) Открытый интерфейс этих библиотек не соответствует собственному восприятию понятий, причём в любом языке программирования и практически любой библиотеке алгоритмов. Потому когда кто-то говорит, я сел и написал за 5 минут на Python, и сторонние библиотеки подключил легко, а вот в C++ замучался, очень тяжело. Хочется спросить, а сколько времени ушло на изучение того же Python. То есть я зная как подключить библиотеки в C++ и чисто для примера не зная как это делается в Python, всё равно как бы должен считать, что в Python это всё проще.
Мелочи.
V>Название проекта: project_name V>IDE: qt creator
Прелесть Qt в том что тебе в 90% случаях не придется подключать ничего другого, на нём прототипы С++ писать можно относительно легко, или под Linux, apt-get install lib-dev + find_package, или студийный nuget основной сценарий использования стороних либ покрывает.
V>Создаём папку project и копипастим два файла:
Да, для Qt можно
V>Но вот вопрос, зачем было называть файл C++ project_name. А затем, чтобы положить в эту же папку исходники других языков. Если бы это был hello_world:
Да ни для кого hello world почти не нужен, а проблема С++ в скудной stl, чуть в сторону и тебе нужно network, db, xml, ini, json, csv, log, получить директорию пользователя куда можно файлы сохранить, открыть файл системным приложением, etc, и ничего этого нет, вперед читать искать библиотеки который тебе нужны, качать, компилировать, подключать, настраивать, собирать инсталятор, или брать монстров Qt, boost где просто не нужно будет скорей всего ничего другого искать.
V>Ладно, это всё были хелло ворлды. Если не жалко времени приведи конкретный "внушительный" пример, чтобы я мог посмотреть на код и сказать, — "О, Python это круто, а вот тот же самый проект или прототип на C++ полное говно".
Именно что хелло ворлды, хорошо, прототип, отслеживать выложеную в интеренете БД в формате ACCESS, после скачать и обновить данные в твоей локальной postgresql базе, на python-e будет в разы проще сделать. А для C++ можешь попробовать для разных системы прикинуть какие библиотеки тебе понадобятся для реализации этого несложного приложения.
Здравствуйте, Igore, Вы писали:
V>>Например, вот так: V>>
V>>LIBS += -lcryptopp
V>>
I>А так же LIB_PATH, INCLUDE_PATH, а, библиотеку же еще скачать и собрать надо, и хранить, и ключи компиляции/линковки должны совпадать, под Linux еще RPATH или LD_LIBRARY_PATH + возможные зависимости. Еще и инсталятор нужно, под Windows хоть из той же папки грузится, тут хоть архив на первое время можно сделать.
PyCryptopp is a set of Python wrappers for a few of the best crypto algorithms
from the Crypto++ library (including SHA-256, AES, RSA signatures and Elliptic
Curve DSA signatures).
Это, конечно, всё здорово и замечательно, но особого смысла не вижу восхищаться обёртками, когда тоже самое можно использовать напрямую.
I>Именно что хелло ворлды, хорошо, прототип, отслеживать выложеную в интеренете БД в формате ACCESS, после скачать и обновить данные в твоей локальной postgresql базе, на python-e будет в разы проще сделать. А для C++ можешь попробовать для разных системы прикинуть какие библиотеки тебе понадобятся для реализации этого несложного приложения.
Тоже самое можно сделать и для C++. Python это обёртки, обёртки и ещё раз обёртки. Возможно меня здесь уже записали в противники Python, но я просто не вижу разницы запускать напрямую или обёрткой. Причём от проблемы версий библиотек алгоритмов мы никуда не ушли.
Здравствуйте, Nuzhny, Вы писали:
N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы,
Ты и сейчас её не понимаешь.
ОНИ СЧИТАЮТ, ЧТО ЕСЛИ ОНИ НЕ ПОДНИМУТ ВСЁ ЭТО ГОВНО, КОМУ-ТО БУДЕТ ХУЖЕ!
вот в чём проблема.
Здравствуйте, Nuzhny, Вы писали:
N>Я также делаю, но оно же не обязательно будет работать. Ты ставишь requirements для одного проекта, пишешь код, например, сервера. Потом хочешь сделать, чтобы он распознавал котиков на фотках. Находишь предобученную модель, подключаешь tensorflow, а он не работает. Ему нужен другой python, более древний. И какой-нибудь другой protobuf. Или numpy. Потом выясняется, что это старая версия или версия, которая требует строго определённые версии пакетов, ни больше, ни меньше. Не случайно сейчас самые популярные репозитории начинают раздел Install со слов: "Скачайте такой-то Докер..." Как раз потому что в версиях Питона и библиотек разброд и шатание и не так просто подбирать рабочие комбинации для разных библиотек.
Это просто больно читать... virtualenv, venv море других. Просто не надо валить всё в системные библиотеки Питона и всё будет хорошо.
Уверен что знаешь? С чего вдруг на машине должен быть QMake (у меня вообще никогда не было)? Показал бы уж как всё легко и просто, ну и конечно кроссплатформенно, на Makefile.
V>Например, вот так: V>
V>LIBS += -lcryptopp
V>
Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же
_># Mercurial will never work on Python 3 before 3.5 due to a lack
_># of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
_># due to a bug in % formatting in bytestrings.
_># We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
_># codecs.escape_encode() where it raises SystemError on empty bytestring
Здравствуйте, kaa.python, Вы писали:
KP>Это просто больно читать... virtualenv, venv море других. Просто не надо валить всё в системные библиотеки Питона и всё будет хорошо.
Я же как раз и отвечал, что virtualenv использую. Это работает, когда имеешь дело с одним репозиторием на Гитхабе. Но когда надёргиваешь код из разных источников, то всё ломается и начинаются пляски с бубном. Кажется, что большую программу на Питоне просто так вообще не написать, поэтому и стали популярными Докеры и микросервисы — не только из-за масштабируемости, но и из-за того, что всё работает само по себе с кучей разных библиотек разных версий. Описанная мной проблема как раз и была в отдельном env.
Здравствуйте, Nuzhny, Вы писали:
N>Я же как раз и отвечал, что virtualenv использую. Это работает, когда имеешь дело с одним репозиторием на Гитхабе. Но когда надёргиваешь код из разных источников, то всё ломается и начинаются пляски с бубном. Кажется, что большую программу на Питоне просто так вообще не написать, поэтому и стали популярными Докеры и микросервисы — не только из-за масштабируемости, но и из-за того, что всё работает само по себе с кучей разных библиотек разных версий. Описанная мной проблема как раз и была в отдельном env.
Ну, разве что это особенность ML. Я довольно много делал проектов на Python и с описанным сталкивался только по молодости и глупости, когда про venv не знал
Здравствуйте, Nuzhny, Вы писали:
N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых.
Дело не в динамике, а в том, что кое-кто, не подумав, вносит ломающие изменения в язык.
Мораль: серьезные проекты можно писать только на языках, для которых верно хотя бы одно из двух: 1) у языка есть несколько независимых, влиятельных реализаций 2) за языком стоят люди, которым можно доверять
Здравствуйте, Nuzhny, Вы писали:
N>Ну, на современном CMake + vcpkg не сложнее, а то и проще. Оно пока ещё не такое гибкое как pip, но уже ближе к нему, чем голый CMake или qmake
Сложнее всё-же. Во-первых, телодвижений больше чем с Python, хотя и не так много как было раньше. Во-вторых, к проекту нужны тесты, тут еще больше сложностей. В-третьих, если (когда) проект вырастет, CMake превратится в ад. В-четвертых, когда проект вырастет, с большой вероятностью о предсобранных в vcpkg пакетах придется забыть.
C++ зык прекрасный, но вот сборочно-тестовая-деплойная инфраструктура, мягко говоря, оставляет желать лучшего.
Здравствуйте, kaa.python, Вы писали:
KP>Уверен что знаешь? С чего вдруг на машине должен быть QMake (у меня вообще никогда не было)? Показал бы уж как всё легко и просто, ну и конечно кроссплатформенно, на Makefile.
Я же написал так сказать ручной запуск из командной строки для gcc (g++). CMake применять не вижу смысла, так как пользуюсь Qt Creator, но замечу, что CMake, что QMake везде ручной набор. И касательно систем сборок это дело десятое, их довольно много. Однако никто не мешает добавить тем же способом то, что нужно, тот же Makefile, и даже не обязательно под этим именем. Иными словами идея не только в том, чтобы создавать разные файлы для систем сборок одного языка программирования, так же параллельно можно добавить проекты для других языков, а то и вовсе объединить, пусть даже без прямой поддержки IDE.
project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp
OTHER_FILES += project_name.py project_name.lua # ... и так далее
KP>Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же
Не так долго как кажется. В конце концов я сижу на рсдн и по большей части читаю всякую муть, даже не про программирование. Вообще я читал твой блог, то есть это как бы вопрос к себе.
Времени катастрофически ни на что не хватает, а на ближайший год очень серьезные планы. Одним из главных бессмысленных пожирателей свободного времени, до вчерашнего дня был РСДН, всё остальное давно “похерил”.
Поразмыслив на тему планирования времени, временно ушел оттуда, самозабанившись на 1 год. Жалко, конечно, но реально нужно достать еще свободного времени.
Да, я и на этот блог нашёл время сколько-то лет назад и не только. У кого-то мало времени, у кого-то много, но в любом случае люди движутся к смерти. Каждый сам определяет себе приоритеты.
Мысли:
А если бы все программисты бросили писать комментарии на рсдн и вместо этого писали аналогичный объём кода. Или вот, не только программисты, все люди перестали писать в свои бложики, социальные сети, чаты, а вместо этого стали генерировать хардкорный код. И старушки тоже бы перестали смотреть телевизор и принялись кодить.