Shareware на Python? - Shareware и бизнес

Здравствуйте, andyag, Вы писали:

A>С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.

A>1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап.
A>2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.

Что мешает юзать 2.7?

A>3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.

А в с++ он есть? Или плюсы тоже не самостоятельный инструмент?

A>Python можно рассматривать как тул для реализации логики отдельных частей приложения: весь хардкор написать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%, а потом скрутить этот хардкор в кучу через Python. Например есть реализация Python на Java — Jython. Но с таким же успехом там есть и JavaScript, и JRuby и ещё штук 10 менее попсовых языков.

можно

A>Python можно рассматривать как тул для всяких экспериментов — типа запрограммировать алгоритм, посмотреть как он работает, а потом переписать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%. У него есть какие-то там интересные математические библиотеки, поэтому для таких задач оно может иметь смысл.

тут он чудесен.

A>Python можно рассматривать как тул для скриптов, замену всяким *.bat и *.sh, т.к. стандартная библиотека у него вполне интересна — многое можно сделать в 2 строчки без запуска внешних процессов и разбора их вывода через grep и прочие ужасы. Но примерно с таким же успехом можно использовать и тот же Ruby, и Groovy, и даже NodeJS при должной мотивации.

ну да, как вариант можно и так.

A>ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.

А в чем изобретение велосипеда — мало ли гуев на питоне? Кьют с ним сочетается практически как с плюсами, портабельность выше дотнетовской. При этом, я, например, пишу в одиночку — у меня скорость разработки получается в разы выше, чем на плюсах. И при отладке приходится иметь дело не с access violation, а с полным стеком.

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

Да, а еще на нем под веб писать можно.

Здравствуйте, andyag, Вы писали:

A>Zen of Python неявно существует в абсолютно любом ЯП. Главное чтобы автор кода верил, что придерживается этого дзена — тогда у него есть гармония. Но читатели кода часто несогласны, что написанный код имеет какое-то отношение к дзену и вульгарно называют код — говнокодом.

Философия языков сильно разница. Наиболее важно то, какой политики (философии) придерживаются те, кто работает над развитием самого языка.

A>Это снова что-то сильно субъективное. Если оно не мешает вашим кейзам, это не значит, что оно не мешает вообще. Это как-то нездорово — чувствовать себя спокойно, когда знаешь, что завтра может понадобиться какая-то библиотека для XXX, которой может не быть для Python 3, в то время как остальная часть проекта уже написана именно на 3. Это просто ненормально.

Проблемы с совместимостью имеют только наиболее сложные библиотеки с большими специфическими для платформ фрагментами. Если на этапе старта проекта подумать о его архитектуре, то подобные ограничения будут видны еще до тех пор, пока появилась первая функция нового проекта. И, возможно, проект начнется не с выбора Python 3, а 2.7.

A>Просто чтобы я мог оценить ваше высказывание в полной мере — когда вы говорите "не самый лучший", какой "самый лучший" вы имеете в виду?

Например мне куда больше Maven нравится. Лично я его считаю образцовым решением.

A>Не понял с чем вы спорите — я сказал почти то же самое. Более того, тут вы подтверждаете мое самое первое утверждение — "С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент".

Где? Что-то мне кажется, кое-кто пытается выдать собственную мысль, с которой я не согласен, за мою

A>И нафига мне алгоритм на Python, если остальной код написан, например, на C#? Проясню ситуацию: я делаю какой-то проект на C#, возникает необходимость запилить какой-то не очень тривиальный алгоритм. Я хочу сначала пощупать этот алгоритм, проверить на разных данных, порисовать какие-то графики — в этом случае я возьму Python. Но как только нащупаюсь, перепишу всё на C#.

А нафига тебе код на этом одноплатформенном недоразумении?

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

1) Простой;
2) Кроссплатформенный;
3) Со встроенной разумной защитой от write-only кода.

A>Тут снова достаточно возразить, что у Ruby как минимум нет проблем 2 vs. 3, огроменный централизованный репозиторий с кучей библиотек и тот самый, упомянутый вами, RoR. Даже если согласиться, что Ruby и Python примерно одинаковы, окей, почему Python, а не Ruby?

Когда я смотрел на Ruby и думал не взять ли его вместо Python, то мне не понравилось: 1) довольно специфический синтаксис, кмк должен провоцировать write-only стиль разработки, 2) отсутствие сопоставимых по качеству и широте использования с Python математических библиотек, 3) отсутствие сопоставимых по качеству и широте использования с Python AI-ориентированных библиотек, 4) сильная заточенность под Web (то, что мне вообще не нужно).
Был бы Web-ориентирован, то однозначно предпочел бы Ruby.

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, andyag, Вы писали:

A>>Zen of Python неявно существует в абсолютно любом ЯП. Главное чтобы автор кода верил, что придерживается этого дзена — тогда у него есть гармония. Но читатели кода часто несогласны, что написанный код имеет какое-то отношение к дзену и вульгарно называют код — говнокодом.

KP>Философия языков сильно разница. Наиболее важно то, какой политики (философии) придерживаются те, кто работает над развитием самого языка.

Пример философии тех, кто работает над развитием самого языка: "а нахрен щас поломаем совместимость, зато будет круче". С другой стороны, про "дзен" я регулярно слышу только в контексте Python — в любом другом ЯП об этом просто не говорят, хотя ценности вполне разделяют.

A>>Это снова что-то сильно субъективное. Если оно не мешает вашим кейзам, это не значит, что оно не мешает вообще. Это как-то нездорово — чувствовать себя спокойно, когда знаешь, что завтра может понадобиться какая-то библиотека для XXX, которой может не быть для Python 3, в то время как остальная часть проекта уже написана именно на 3. Это просто ненормально.

KP>Проблемы с совместимостью имеют только наиболее сложные библиотеки с большими специфическими для платформ фрагментами. Если на этапе старта проекта подумать о его архитектуре, то подобные ограничения будут видны еще до тех пор, пока появилась первая функция нового проекта. И, возможно, проект начнется не с выбора Python 3, а 2.7.

Давайте без "если". Практически любой говнокод на Java, который работал на 1.5 будет работать и на 1.8 — разница между ними 10 лет. Почему Python может позволять себе ломать совместимость и не получать за это минус?

A>>Просто чтобы я мог оценить ваше высказывание в полной мере — когда вы говорите "не самый лучший", какой "самый лучший" вы имеете в виду?

KP>Например мне куда больше Maven нравится. Лично я его считаю образцовым решением.

Maven мне тоже нравится. Хорошо — ваша оценка для pip понятна.

A>>Не понял с чем вы спорите — я сказал почти то же самое. Более того, тут вы подтверждаете мое самое первое утверждение — "С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент".

KP>Где? Что-то мне кажется, кое-кто пытается выдать собственную мысль, с которой я не согласен, за мою

Цитирую ваше высказывание:

Нет-нет и еще раз нет. Python можно и нужно рассматривать как основной кандидат для написания не критичной ко скорости логики. Именно по тем причинам, что я привел в самом начале.

А вот моё:

С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.

В обоих случаях посыл один и тот же — "не стоит на Python делать всё". Или я ваше отверждение неправильно читаю?

A>>И нафига мне алгоритм на Python, если остальной код написан, например, на C#? Проясню ситуацию: я делаю какой-то проект на C#, возникает необходимость запилить какой-то не очень тривиальный алгоритм. Я хочу сначала пощупать этот алгоритм, проверить на разных данных, порисовать какие-то графики — в этом случае я возьму Python. Но как только нащупаюсь, перепишу всё на C#.

KP>А нафига тебе код на этом одноплатформенном недоразумении?

А у меня какой-то продукт для облегчения управления инфраструктурой Microsoft. Или чистилка реестра Windows. Или умная качалка апдейтов для Windows. Вариантов много, ни в одном случае переносимость не будет плюсом.

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

KP>1) Простой;

Бейсик тоже простой. Для меня, например, Java и C# — очень простые языки после C++

С другой стороны один приятель недавно пытался изучить программирование и начал с Python — где-то в районе первой 1000 строк кода полезла путаница с типами, все прелести динамической типизации. Нельзя сказать, что ему было _просто_ осознать и побороть этот феномен.

KP>2) Кроссплатформенный;

Бейсик тоже кроссплатформенный. А ещё JavaScript, Java, Scala, Groovy, Ruby.

KP>3) Со встроенной разумной защитой от write-only кода.

Расскажите пожалуйста подробнее. Я искренне не верю, что в языке с динамической типизацией этот консёрн может хоть как-то покрываться. Более того, видел много примеров write-only даже в случае статически типизрованных языков.

A>>Тут снова достаточно возразить, что у Ruby как минимум нет проблем 2 vs. 3, огроменный централизованный репозиторий с кучей библиотек и тот самый, упомянутый вами, RoR. Даже если согласиться, что Ruby и Python примерно одинаковы, окей, почему Python, а не Ruby?

KP>Когда я смотрел на Ruby и думал не взять ли его вместо Python, то мне не понравилось: 1) довольно специфический синтаксис, кмк должен провоцировать write-only стиль разработки,

У Python синаксис не менее специфический, если учесть что мейнстримные языки все со скобочками. Такой синтаксис может нравиться или не нравиться — это да, но в любом случае он специфический.

KP>2) отсутствие сопоставимых по качеству и широте использования с Python математических библиотек, 3) отсутствие сопоставимых по качеству и широте использования с Python AI-ориентированных библиотек,

Про эксклюзивные библиотеки я написал в своём самом первом сообщении — это безусловно перевес.

KP>4) сильная заточенность под Web (то, что мне вообще не нужно).

В чём именно проявляется заточенность под web? Если немного походить по rubygems.org, можно найти много сильно не-вебных библиотек вроде 3D геометрии, работы с MIDI — вроде кто-то ими даже пользуется.

Здравствуйте, eskimo82, Вы писали:

E>Здравствуйте, eskimo82, Вы писали:

A>>>Сопровождаемость, неразрастание требований к квалификации программиста, которому позже придётся в этот код вносить изменения. Программистов знающих язык A всегда больше, чем программистов знающих одновременно A и B.
A>>>Неразрастание требований к рабочему месту — отсутствие необходимости ставить и конфигурировать десяток инструментов. Неразрастание инфраструктуры для сборки и деплоймента.
E>>Если нет возможности нанять квалифицированных програмистов, то имеет смысл посмотреть на интерпретируемые языки-песочницы. И неуходиь из них. Это очевидно.

Что такое "интерпретируемые языки-песочницы"?
Ещё раз — есть проект на C#, есть команда из 10 программистов, которые неплохо этот самый C# умеют. Вопрос — зачем в проект тащить Python, который, может быть, из этих 10 человек умеют двое?

A>>>Если проект _уже_ существует как "проект на C#", очевидно, что переносимость не рассматривается как ценность.
A>>>Ещё вопросы?
E>>Зачем вам Python ? В том плане, что он даст для отладки алгоритмов, по сравнению с шарпом ?

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

1. У Python из коробки есть поддержка чисел с неограниченной разрядностью. Для .NET наверняка есть библиотека, но её нужно гуглить и ставить.
2. У Python из коробки есть возможность сравнивать файлы и папки. Для .NET наверняка есть библиотека, но её нужно гуглить и ставить.
3. У Python из коробки есть возможность использовать SQLite. У .NET есть SQLServer CE, но его нужно ставить отдельно.
4. У Python из коробки есть поддержка CSV, JSON, XML. У .NET из коробки только XML, для CSV и JSON — как обычно есть какие-то библиотеки.

Возьмём например задачу — из нескольких разных мест в интернете выкачать датасеты в разных форматах, как-то их проанализировать и выплюнуть результат в формате XML. Вот фича — это "проанализировать", а выкачать и сохранить результат — это рутина. В Python я могу в 5 строчек написать выкачивание, ещё в 5 — сохранение в базу, ещё в 3 — сохранение в XML. Это пишется за 5 минут без гугла и без геморроя с подключением левых библиотек. Далее я сажусь и пишу собственно "анализ данных". Более того, если мне захочется влезть в середину этой программы и попробовать добавлять/отключать какие-то датасеты или корректировать анализ, я могу это сделать в командной строке интерпретатора. На самом деле я могу вообще всё это проделать в командной строке.

В случае с .NET мне нужно будет подключить несколько библиотек, некоторые из которых могут оказаться "очень гибкими" и потребуют от меня кучи строчек кода, чтобы описать мою конкретную ситуацию. Далее, на каждое изменение в коде мне нужно будет перезапускать всю программу.

Здравствуйте, Brice Tribbiani, Вы писали:

BT>Здравствуйте, andyag, Вы писали:

A>>С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.

A>>1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап.
A>>2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.

BT>Что мешает юзать 2.7?

Официальные рекоммендации новые проекты начинать на 3, а не на 2? Наличие 99% нужных библиотек под 3? Нежелание геморроя, который как раз попытались убрать в 3?

A>>3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.

BT>А в с++ он есть? Или плюсы тоже не самостоятельный инструмент?

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

A>>ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.

BT>А в чем изобретение велосипеда — мало ли гуев на питоне? Кьют с ним сочетается практически как с плюсами, портабельность выше дотнетовской. При этом, я, например, пишу в одиночку — у меня скорость разработки получается в разы выше, чем на плюсах. И при отладке приходится иметь дело не с access violation, а с полным стеком.

Последний раз когда я пытался использовать Qt из Python (наверное, уже лет 5 назад), заработало оно далеко не с первого раза, причём потребовало каких-то конфигурационных активностей на уровне системы. Я помню, что PySide и PyQt тогда уже были, и по какой-то причине один из них мне не подошёл совсем. Для меня это всё выглядело как проблемы на ровном месте. Собственно, я попробовал тогда сделать _несколько_ таких "лабораторных работ" — UI, веб-клиент, веб-сервер, работа с БД, и практически каждый раз была борьба с системой. Один раз напрячься и сделать чтобы работало безусловно можно, но напарываться на эти проблемы регулярно и быть готовым решать их — это нездоровый подход.

BT>Хотя, если бы писал коллектив — думаю, отсутствие компилируемости и типизации могло бы усложнять процесс в сравнении с теми же плюсами.

Типизация — это на вкус и цвет. Я субъективно не люблю динамическую типизацию, но не озвучиваю это как минус Python, для меня это просто "Python — такой".

BT>Да, а еще на нем под веб писать можно.

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

Здравствуйте, andyag, Вы писали:

A>Официальные рекоммендации новые проекты начинать на 3, а не на 2? Наличие 99% нужных библиотек под 3? Нежелание геморроя, который как раз попытались убрать в 3?

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

A>В C++ менеджера зависимостей тоже нет и это очень большой недостаток, т.к. делает язык малопригодным для прикладного программирования.

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

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

A>Последний раз когда я пытался использовать Qt из Python (наверное, уже лет 5 назад), заработало оно далеко не с первого раза, причём потребовало каких-то конфигурационных активностей на уровне системы. Я помню, что PySide и PyQt тогда уже были, и по какой-то причине один из них мне не подошёл совсем. Для меня это всё выглядело как проблемы на ровном месте. Собственно, я попробовал тогда сделать _несколько_ таких "лабораторных работ" — UI, веб-клиент, веб-сервер, работа с БД, и практически каждый раз была борьба с системой. Один раз напрячься и сделать чтобы работало безусловно можно, но напарываться на эти проблемы регулярно и быть готовым решать их — это нездоровый подход.

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

A>Типизация — это на вкус и цвет. Я субъективно не люблю динамическую типизацию, но не озвучиваю это как минус Python, для меня это просто "Python — такой".

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

A>Сейчас в мейнстриме нет языков, на которых нельзя писать под веб.

Важно наличие фреймворков. Для питона есть джанго и есть питоновская среда для appengine.

Собственно, по этому питон лично для меня и разом покрывает много потребностей — гуи/инфраструктура, image processing(особенно на исследовательской стадии) и веб. И я не знаю одного языка, который для всех этих задач был бы для меня лучше.

Здравствуйте, Brice Tribbiani, Вы писали:

BT>Здравствуйте, andyag, Вы писали:

A>>Официальные рекоммендации новые проекты начинать на 3, а не на 2? Наличие 99% нужных библиотек под 3? Нежелание геморроя, который как раз попытались убрать в 3?

BT>Ну рекомендации — это не требования. А в чем там особый геморрой?

Вот здесь очень хорошо расписано почему 3, а не 2, что там изменилось и как со всем этим жить:
https://wiki.python.org/moin/Python2orPython3

A>>В C++ менеджера зависимостей тоже нет и это очень большой недостаток, т.к. делает язык малопригодным для прикладного программирования.

BT>А, ну если плюсы называть малопригодным для прикладного программирования языком, ну тогда да

Я так понимаю — сарказм? Давайте уточним:

1. Де-факто кроссплатформенного UI-фреймворка нет (есть Qt, но это нельзя однозначно назвать C++).
2. Де-факто сериализации-десериализации для XML/JSON нет.
3. Де-факто HTTP-сервера/клиента нет.
4. Де-факто application-level фреймворка нет.
5. Де-факто инструмента для юнит-тестирования нет.

Во всех случаях есть отмазка — "зато переносимость" и "нафига вам веб-сервер на микроконтроллере с 8кб ОЗУ". А ещё есть статистика по общению с C++-девелоперами — у них буквально любое предложение по интеграции вызывает истерику. "А давайте через HTTP заинтегрируемся" — "чооо!!!????", ну хорошо выберите из Thrift/Avro/ещёпаравариантов — "чооо????!!!!!". "Окей, ваш вариант?" — "ну мы сейчас просто заэкспортируем всё что понаписали, а вы у себя там в Java через JNI/JNA как-то байндинги сделаете". Вот и весь разговор. ИМХО, это не серьёзно. И я их прекрасно понимаю, потому что из коробки решений нет, а любая библиотека — риск геморроя. Такой мир C++.

Короче, отмазку про "веб-сервер на микроконтроллере" я уже давно принял и воспринимаю C++ и C++-девелоперов соответствующим образом.

BT>А в каких мейнстримовых языках он сильно лучше, чем в питоне, кстати?

Из всего, что я видел и щупал (Python, Ruby, .NET, Java, NodeJS), круче всех — Java с её Maven (или Gradle). На самом деле это немного нечестно, т.к. и Maven, и Gradle это скорее "файл проекта" — в одном единственном месте описываются и нужные зависимости, и запуск тестов, и процесс сборки, и построение дистрибутива. Если говорить только об управлении зависимостями, вот короткий пример веб-сервиса, который на запросы отдаёт "hello world":
http://projects.spring.io/spring-boot/

Показано "насколько длинно" описываются зависимости (особенно в случае Gradle). Это, кстати, не веб-сервис, а готовая программа, которая сама запускает настоящий веб-сервер, а уже в нём запускает свой веб-сервис. При запуске (типа "gradle run"), если зависимостей нет в локальном кэше, они скачаются, после этого сборка и запуск. Чтобы собрать полноценный запускабельный пакет, в Gradle нужно будет написать ещё 2 строчки, а потом сделать "gradlew distZip". В итоге получится большой zip-архив, в котором лежит всё что нужно для запуска — и веб-сервер, и сам Spring, и непосредственно веб-сервис. Единственная глобальная зависимость — это JRE.

A>>Последний раз когда я пытался использовать Qt из Python (наверное, уже лет 5 назад), заработало оно далеко не с первого раза, причём потребовало каких-то конфигурационных активностей на уровне системы. Я помню, что PySide и PyQt тогда уже были, и по какой-то причине один из них мне не подошёл совсем. Для меня это всё выглядело как проблемы на ровном месте. Собственно, я попробовал тогда сделать _несколько_ таких "лабораторных работ" — UI, веб-клиент, веб-сервер, работа с БД, и практически каждый раз была борьба с системой. Один раз напрячься и сделать чтобы работало безусловно можно, но напарываться на эти проблемы регулярно и быть готовым решать их — это нездоровый подход.

BT>Ну я не знаю, что там было 5 лет назад. Сейчас PySide вполне юзабелен и я даже и не помню в начале разработки проблем. Хотя в процессе несколько неприятных багов вылезло, но это баги именно фреймворка, в PyQt их нет.
BT>PyQt денег стоит, которых у меня нет на эти цели, но насколько я понимаю — он еще лучше.

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

A>>Типизация — это на вкус и цвет. Я субъективно не люблю динамическую типизацию, но не озвучиваю это как минус Python, для меня это просто "Python — такой".

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

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

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

A>>Сейчас в мейнстриме нет языков, на которых нельзя писать под веб.

BT>Важно наличие фреймворков. Для питона есть джанго

Сейчас в мейнстриме нет ЯП, для которых нет веб-фреймворков

Python: Django, Flask, CherryPy
Ruby: RoR и Sinatra
Java: Spring MVC, Wicket, GWT/Vaadin, Tapestry (и ещё наверное штук 5 достаточно популярных)
.NET: ASP.NET MVC
(уже мейнстрим или ещё нет?) NodeJS: Express, Koa (хотя они очень сильно низкоуровневые)

BT>и есть питоновская среда для appengine.

Я бы не стал это относить к значимым плюсам, т.к. на каком-нибудь Heroku можно легко крутить весь список кроме .NET

К тому же, насколько я помню, Django на GAE урезанный.

BT>Собственно, по этому питон лично для меня и разом покрывает много потребностей — гуи/инфраструктура, image processing(особенно на исследовательской стадии) и веб. И я не знаю одного языка, который для всех этих задач был бы для меня лучше.

У вас интересное сочетание направлений — я согласен, что скорее всего не получится найти какой-то другой ЯП, чтобы кроссплатформенно, безгеморройно и всё одновременно. С другой стороны, с поинтом про "безгеморройно" я до конца не могу согласиться, но это очень субъективно.

Здравствуйте, andyag, Вы писали:

BT>>Ну рекомендации — это не требования. А в чем там особый геморрой?

A>Вот здесь очень хорошо расписано почему 3, а не 2, что там изменилось и как со всем этим жить:
A>https://wiki.python.org/moin/Python2orPython3

Ну, если я не пишу на 3-м питоне, это не значит, что я вообще про него не знаю

Я не вижу там ответа на свой вопрос. Чего не хватает в 2.7 реально? Синтаксического сахара? Ну да, в 3 его больше, но и в 2.7 — полно, особенно если с плюсами сравнить. Юникодных по умолчанию строк? Ну да, хотелось бы. Но это не того уровня геморрой, чтобы говорить о неюзабельности языка.

A>Я так понимаю — сарказм? Давайте уточним:

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

A>1. Де-факто кроссплатформенного UI-фреймворка нет (есть Qt, но это нельзя однозначно назвать C++).

Ну здрасьте, а что это, если не плюсы? Не говоря уж о том, что кроме qt нормальных кросс-платформенных гуи фреймворков, по моему, вообще нет в природе. .Net недостаточно кроссплатформен, все джавовское — тормозное и страшное УГ, а больше ничего и нет.

A>2. Де-факто сериализации-десериализации для XML/JSON нет.
A>3. Де-факто HTTP-сервера/клиента нет.
A>4. Де-факто application-level фреймворка нет.
A>5. Де-факто инструмента для юнит-тестирования нет.

Это да.

A>Во всех случаях есть отмазка — "зато переносимость" и "нафига вам веб-сервер на микроконтроллере с 8кб ОЗУ". А ещё есть статистика по общению с C++-девелоперами — у них буквально любое предложение по интеграции вызывает истерику. "А давайте через HTTP заинтегрируемся" — "чооо!!!????", ну хорошо выберите из Thrift/Avro/ещёпаравариантов — "чооо????!!!!!". "Окей, ваш вариант?" — "ну мы сейчас просто заэкспортируем всё что понаписали, а вы у себя там в Java через JNI/JNA как-то байндинги сделаете". Вот и весь разговор. ИМХО, это не серьёзно. И я их прекрасно понимаю, потому что из коробки решений нет, а любая библиотека — риск геморроя. Такой мир C++.

A>Короче, отмазку про "веб-сервер на микроконтроллере" я уже давно принял и воспринимаю C++ и C++-девелоперов соответствующим образом.

Не, ну с джавой плюсы по нише мало пересекаются.

BT>>А в каких мейнстримовых языках он сильно лучше, чем в питоне, кстати?

A>Из всего, что я видел и щупал (Python, Ruby, .NET, Java, NodeJS), круче всех — Java с её Maven (или Gradle). На самом деле это немного нечестно, т.к. и Maven, и Gradle это скорее "файл проекта" — в одном единственном месте описываются и нужные зависимости, и запуск тестов, и процесс сборки, и построение дистрибутива. Если говорить только об управлении зависимостями, вот короткий пример веб-сервиса, который на запросы отдаёт "hello world":
A>http://projects.spring.io/spring-boot/

Спасибо.
Ну то есть, питон не нужен, потому что он не джава, да?

A>Показано "насколько длинно" описываются зависимости (особенно в случае Gradle). Это, кстати, не веб-сервис, а готовая программа, которая сама запускает настоящий веб-сервер, а уже в нём запускает свой веб-сервис. При запуске (типа "gradle run"), если зависимостей нет в локальном кэше, они скачаются, после этого сборка и запуск. Чтобы собрать полноценный запускабельный пакет, в Gradle нужно будет написать ещё 2 строчки, а потом сделать "gradlew distZip". В итоге получится большой zip-архив, в котором лежит всё что нужно для запуска — и веб-сервер, и сам Spring, и непосредственно веб-сервис. Единственная глобальная зависимость — это JRE.

Ясно. Ну, я наверно просто сильно далек от того класса задач, где это требуется. Это все-таки про enterprise-soft, насколько я понимаю.

A>Звучит хорошо. А вот если я напишу какой-то софт с применением PySide, что именно я должен буду поставлять на целевую машину? PySide — это только код с байндингами, или он по-честному тянет за собой Qt?

Ну, Qt рантайм, естественно, нужен. Физически его можно взять из дистрибутива PySide, если лицензионно LGPL-версия Qt устраивает.

A>Меня тут полгода назад заминусовали, громко рассказав, что правильно — это в каждом долбаном методе руками проверять типы аргументов

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

Ну, если они реально так делают — я им сочувствую

A>Сейчас в мейнстриме нет ЯП, для которых нет веб-фреймворков

A>Python: Django, Flask, CherryPy
A>Ruby: RoR и Sinatra
A>Java: Spring MVC, Wicket, GWT/Vaadin, Tapestry (и ещё наверное штук 5 достаточно популярных)
A>.NET: ASP.NET MVC
A>(уже мейнстрим или ещё нет?) NodeJS: Express, Koa (хотя они очень сильно низкоуровневые)

Из перечисленных языков десктопных только два, из них кроссплатформенный — один. И это, внезапно, питон

A>Я бы не стал это относить к значимым плюсам, т.к. на каком-нибудь Heroku можно легко крутить весь список кроме .NET

A>К тому же, насколько я помню, Django на GAE урезанный.

Ну ОК, значимость этого субъективна, да.
Джанго на эппенжине, действительно, с ограничениями, если не докупать cloudsql.

A>У вас интересное сочетание направлений — я согласен, что скорее всего не получится найти какой-то другой ЯП, чтобы кроссплатформенно, безгеморройно и всё одновременно. С другой стороны, с поинтом про "безгеморройно" я до конца не могу согласиться, но это очень субъективно.

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

Здравствуйте, Brice Tribbiani, Вы писали:

BT>Здравствуйте, andyag, Вы писали:

A>>Я так понимаю — сарказм? Давайте уточним:

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

A>>1. Де-факто кроссплатформенного UI-фреймворка нет (есть Qt, но это нельзя однозначно назвать C++).

BT>Ну здрасьте, а что это, если не плюсы? Не говоря уж о том, что кроме qt нормальных кросс-платформенных гуи фреймворков, по моему, вообще нет в природе. .Net недостаточно кроссплатформен, все джавовское — тормозное и страшное УГ, а больше ничего и нет.

Когда я последний раз им пользовался, там в тулчейне был какой-то волшебный препроцессор. Уже убрали или препроцессоры входят в C++?

A>>Короче, отмазку про "веб-сервер на микроконтроллере" я уже давно принял и воспринимаю C++ и C++-девелоперов соответствующим образом.

BT>Не, ну с джавой плюсы по нише мало пересекаются.

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

BT>>>А в каких мейнстримовых языках он сильно лучше, чем в питоне, кстати?

A>>Из всего, что я видел и щупал (Python, Ruby, .NET, Java, NodeJS), круче всех — Java с её Maven (или Gradle). На самом деле это немного нечестно, т.к. и Maven, и Gradle это скорее "файл проекта" — в одном единственном месте описываются и нужные зависимости, и запуск тестов, и процесс сборки, и построение дистрибутива. Если говорить только об управлении зависимостями, вот короткий пример веб-сервиса, который на запросы отдаёт "hello world":
A>>http://projects.spring.io/spring-boot/

BT>Спасибо.
BT>Ну то есть, питон не нужен, потому что он не джава, да?

Я не говорил этого. Вы задали вопрос — "где сильно лучше?", на него я и ответил. Могу другой вариант предложить: из Python, Ruby, .NET, Java, NodeJS самый хреновый менеджер зависимостей у Python, у оставшихся 4 платформ дела обстоят лучше. У C/C++ дела обстоят хуже.

A>>Показано "насколько длинно" описываются зависимости (особенно в случае Gradle). Это, кстати, не веб-сервис, а готовая программа, которая сама запускает настоящий веб-сервер, а уже в нём запускает свой веб-сервис. При запуске (типа "gradle run"), если зависимостей нет в локальном кэше, они скачаются, после этого сборка и запуск. Чтобы собрать полноценный запускабельный пакет, в Gradle нужно будет написать ещё 2 строчки, а потом сделать "gradlew distZip". В итоге получится большой zip-архив, в котором лежит всё что нужно для запуска — и веб-сервер, и сам Spring, и непосредственно веб-сервис. Единственная глобальная зависимость — это JRE.

BT>Ясно. Ну, я наверно просто сильно далек от того класса задач, где это требуется. Это все-таки про enterprise-soft, насколько я понимаю.

Почему энтерпрайз? Слово "веб-сервис" смутило? Можно просто странички отдавать, всё то же самое, что и в Django, только без мучений с Apache и mod_wsgi.

A>>Сейчас в мейнстриме нет ЯП, для которых нет веб-фреймворков

A>>Python: Django, Flask, CherryPy
A>>Ruby: RoR и Sinatra
A>>Java: Spring MVC, Wicket, GWT/Vaadin, Tapestry (и ещё наверное штук 5 достаточно популярных)
A>>.NET: ASP.NET MVC
A>>(уже мейнстрим или ещё нет?) NodeJS: Express, Koa (хотя они очень сильно низкоуровневые)

BT>Из перечисленных языков десктопных только два, из них кроссплатформенный — один. И это, внезапно, питон

Что такое "десктопный язык"?

Здравствуйте, andyag, Вы писали:

A>Когда я последний раз им пользовался, там в тулчейне был какой-то волшебный препроцессор. Уже убрали или препроцессоры входят в C++?

В плюсах есть препроцессор, хотя и другой

Когда ты пишешь код на qt, это практически чисто плюсовый код, наличие препроцессора не делает его другим языком.

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

Ну не все же решения клиент-серверные.

A>Я не говорил этого. Вы задали вопрос — "где сильно лучше?", на него я и ответил. Могу другой вариант предложить: из Python, Ruby, .NET, Java, NodeJS самый хреновый менеджер зависимостей у Python, у оставшихся 4 платформ дела обстоят лучше. У C/C++ дела обстоят хуже.

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

A>Почему энтерпрайз? Слово "веб-сервис" смутило? Можно просто странички отдавать, всё то же самое, что и в Django, только без мучений с Apache и mod_wsgi.

Ну ок, enterprise и saas/web. При этом в последнем деплоймент не является таким уж важным местом, поскольку делается фактически один раз — из-за этого настройка апача не является проблемой, влияющей на выбор языка. Что еще?
В любом случае, не совсем тот класс задач, который обычно понимают под shareware.

A>Что такое "десктопный язык"?

Язык, подходящий для разработки десктопного софта.

	От:	andyag
	Дата:	07.02.15 17:29
	Оценка:

	От:	andyag
	Дата:	07.02.15 17:38
	Оценка:

	От:	eskimo82
	Дата:	07.02.15 17:52
	Оценка:

	От:	eskimo82
	Дата:	07.02.15 17:54
	Оценка:

От:	Brice Tribbiani	http://vzaguskin.github.io
Дата:	07.02.15 18:20
Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	08.02.15 02:54
Оценка:	+1