Здравствуйте, Polymorphic, Вы писали:
P>Кто-нибудь использует? Интересуют в основном грабли и что для GUI.
Ну так а как же Dropbox?
Originally, both the Dropbox server (running on the cloud) and desktop client software were primarily written in Python.[52] From mid-2013 Dropbox began migrating its backend infrastructure to Go.[3] The desktop client uses Python GUI toolkits such as wxWidgets and Cocoa. Other notable Python libraries include Twisted, ctypes, and pywin32. Dropbox ships and depends on the librsync binary-delta library (which is written in C). Dropbox’s full browser-side codebase is written in CoffeeScript instead of JavaScript.[53]
9+ летней давности. Там как-то без особых восторгов было.
Граблей будет много, особенно по первости. Со всякими так PyPy и прочими радостями "простого и незаметного компилирования кода на Python в код на Си". Плюс еще динамический язык со всемы вытекающими особенностями.
Я правильно поинмаю, что планируется что-то глобально кроссплатформенное?
Здравствуйте, Polymorphic, Вы писали:
KP>>Я правильно поинмаю, что планируется что-то глобально кроссплатформенное? P>Да, если конечно будет интерес у целевой аудитории.
Если это затевается только ради кроссплатформенности, но чем не устраивает С++?
Здравствуйте, Polymorphic, Вы писали:
P>Кто-нибудь использует? Интересуют в основном грабли и что для GUI.
Ну я использую, python + pyside(это опенсорсная qt под питон), компилируется с помощью pyinstaller. Плюс у меня там numpy/scipy для алгоритмов.
Писать намного удобнее и быстрее чем на плюсах. Грабли — приходится в отдельных местах заморачиваться с производительностью там, где на плюсах с приемлемой скоростью работал бы самый тупой алгоритм. Ну и надо понимать, что любой желающий сможет декомпилировать прогу в исходники.
хотел уже на боковую
папаху снял и сапоги
но в комментариях проснулись
враги
Здравствуйте, drVanо, Вы писали:
V>Если это затевается только ради кроссплатформенности, но чем не устраивает С++?
До кроссплатформенности дойдет, если действительно начнет взлетать (но я надеюсь).
Можно и на С++, но хочется же чего-то нового посмотреть. В интернетах пишут, что вроде у питона есть богатые библиотеки.
P>можно компилировать питон в си и дальше компилировать си в нативный код. реверсить такой код сложно будет.
Я не знаю таких решений, которые бы взяли полноценный питоновский проект со сторонними библиотеками и скомпилировали его в си или в натив.
Отдельные участки кода действительно можно вынести в библиотеки, специально подготовить и скомпилировать, но их можно и сразу на плюсах написать и грузить как dll.
хотел уже на боковую
папаху снял и сапоги
но в комментариях проснулись
враги
Здравствуйте, Polymorphic, Вы писали:
P>Писать планирую десктопное приложение, использующее API нескольких SaaS.
Если один эз этих SAAS твой, то писать становится абсолютно все равно на чем.
Здравствуйте, alexdpp, Вы писали:
A>Sublime text написан на питоне, поддерживает Win/Mac/Linux, 32/64 bits
Википедия подсказывает, что не на Питоне, а на C++ и Питоне: http://en.wikipedia.org/wiki/Sublime_Text
Совершенно попсовая практика — весь хардкор написать на чём-то одном, а потом сверху прикрутить какой-нибудь JS.
Более того, Sublime скорее загнулся, чем не загнулся — последний билд версии 3 был 29 августа 2014. Можно предположить, что Питон проклят.
9+ летней давности. Там как-то без особых восторгов было.
P>Писать планирую десктопное приложение, использующее API нескольких SaaS.
С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.
1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап.
2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.
3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.
Python можно рассматривать как тул для реализации логики отдельных частей приложения: весь хардкор написать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%, а потом скрутить этот хардкор в кучу через Python. Например есть реализация Python на Java — Jython. Но с таким же успехом там есть и JavaScript, и JRuby и ещё штук 10 менее попсовых языков.
Python можно рассматривать как тул для всяких экспериментов — типа запрограммировать алгоритм, посмотреть как он работает, а потом переписать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%. У него есть какие-то там интересные математические библиотеки, поэтому для таких задач оно может иметь смысл.
Python можно рассматривать как тул для скриптов, замену всяким *.bat и *.sh, т.к. стандартная библиотека у него вполне интересна — многое можно сделать в 2 строчки без запуска внешних процессов и разбора их вывода через grep и прочие ужасы. Но примерно с таким же успехом можно использовать и тот же Ruby, и Groovy, и даже NodeJS при должной мотивации.
ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.
Здравствуйте, andyag, Вы писали:
A>Более того, Sublime скорее загнулся, чем не загнулся — последний билд версии 3 был 29 августа 2014. Можно предположить, что Питон проклят.
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, andyag, Вы писали:
A>>Более того, Sublime скорее загнулся, чем не загнулся — последний билд версии 3 был 29 августа 2014. Можно предположить, что Питон проклят.
Н>4 февраля
Здравствуйте, andyag, Вы писали:
A>С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.
Ты не прав. Инструмент очень удачный. Он простой в изучении, он относительно прост в поддержке и он базируется, наверное, на самых правильных принципах в разработке ПО, какие только можно придумать (PEP 20). А еще у них есть замечательные IPython с Notebook.
A>1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап. A>2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.
Проблема есть, она, иногда, создает неудобства. Но я бы не сказал что это что-то критическое, сколь-нибудь сильно мешающее разработке на нем.
A>3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.
Менеджер как менеджер. Не самый лучший, но однозначно выполняющий свою задачу. Пакетов в нем много, у меня не так что бы очень уж обширный Python опыт, но почти все находилось. Плюс еще можно поставить Конду и вообще жизнь станет прекрасной.
A>Python можно рассматривать как тул для реализации логики отдельных частей приложения: весь хардкор написать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%, а потом скрутить этот хардкор в кучу через Python. Например есть реализация Python на Java — Jython. Но с таким же успехом там есть и JavaScript, и JRuby и ещё штук 10 менее попсовых языков.
Нет-нет и еще раз нет. Python можно и нужно рассматривать как основной кандидат для написания не критичной ко скорости логики. Именно по тем причинам, что я привел в самом начале.
A>Python можно рассматривать как тул для всяких экспериментов — типа запрограммировать алгоритм, посмотреть как он работает, а потом переписать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%. У него есть какие-то там интересные математические библиотеки, поэтому для таких задач оно может иметь смысл.
Зачем переписывать? Есть серьезное подозрение что проблема в не умении его готовить, а не самом языке.
A>Python можно рассматривать как тул для скриптов, замену всяким *.bat и *.sh, т.к. стандартная библиотека у него вполне интересна — многое можно сделать в 2 строчки без запуска внешних процессов и разбора их вывода через grep и прочие ужасы. Но примерно с таким же успехом можно использовать и тот же Ruby, и Groovy, и даже NodeJS при должной мотивации.
А почему для более сложных задач нельзя? На нем можно великолепно писать всяческие считалки (привет NumPy с Pandas) так и сервера (тут очень интересен Twisted). Единственное о чем бы я 10 раз подумал, перед тем как писать на Python – GUI приложения. У меня есть подозрения (не пробовал, только гадать могу), что в этой области выйдет не очень.
A>ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.
Python обладает более обширной библиотекой (за пределами разработки Web-сайтов) чем Ruby и он слегка шустрее. Я бы не сказал что у Ruby есть какие-то серьезные преимущества, как минимум до тех пор, пока ты Рельсы не хочешь использовать.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, andyag, Вы писали:
A>>С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.
KP>Ты не прав. Инструмент очень удачный. Он простой в изучении, он относительно прост в поддержке и он базируется, наверное, на самых правильных принципах в разработке ПО, какие только можно придумать (PEP 20). А еще у них есть замечательные IPython с Notebook.
Zen of Python неявно существует в абсолютно любом ЯП. Главное чтобы автор кода верил, что придерживается этого дзена — тогда у него есть гармония. Но читатели кода часто несогласны, что написанный код имеет какое-то отношение к дзену и вульгарно называют код — говнокодом.
A>>1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап. A>>2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.
KP>Проблема есть, она, иногда, создает неудобства. Но я бы не сказал что это что-то критическое, сколь-нибудь сильно мешающее разработке на нем.
Это снова что-то сильно субъективное. Если оно не мешает вашим кейзам, это не значит, что оно не мешает вообще. Это как-то нездорово — чувствовать себя спокойно, когда знаешь, что завтра может понадобиться какая-то библиотека для XXX, которой может не быть для Python 3, в то время как остальная часть проекта уже написана именно на 3. Это просто ненормально.
A>>3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.
KP>Менеджер как менеджер. Не самый лучший, но однозначно выполняющий свою задачу. Пакетов в нем много, у меня не так что бы очень уж обширный Python опыт, но почти все находилось. Плюс еще можно поставить Конду и вообще жизнь станет прекрасной.
Просто чтобы я мог оценить ваше высказывание в полной мере — когда вы говорите "не самый лучший", какой "самый лучший" вы имеете в виду?
A>>Python можно рассматривать как тул для реализации логики отдельных частей приложения: весь хардкор написать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%, а потом скрутить этот хардкор в кучу через Python. Например есть реализация Python на Java — Jython. Но с таким же успехом там есть и JavaScript, и JRuby и ещё штук 10 менее попсовых языков.
KP>Нет-нет и еще раз нет. Python можно и нужно рассматривать как основной кандидат для написания не критичной ко скорости логики. Именно по тем причинам, что я привел в самом начале.
Не понял с чем вы спорите — я сказал почти то же самое. Более того, тут вы подтверждаете мое самое первое утверждение — "С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент".
A>>Python можно рассматривать как тул для всяких экспериментов — типа запрограммировать алгоритм, посмотреть как он работает, а потом переписать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%. У него есть какие-то там интересные математические библиотеки, поэтому для таких задач оно может иметь смысл.
KP>Зачем переписывать? Есть серьезное подозрение что проблема в не умении его готовить, а не самом языке.
И нафига мне алгоритм на Python, если остальной код написан, например, на C#? Проясню ситуацию: я делаю какой-то проект на C#, возникает необходимость запилить какой-то не очень тривиальный алгоритм. Я хочу сначала пощупать этот алгоритм, проверить на разных данных, порисовать какие-то графики — в этом случае я возьму Python. Но как только нащупаюсь, перепишу всё на C#.
A>>Python можно рассматривать как тул для скриптов, замену всяким *.bat и *.sh, т.к. стандартная библиотека у него вполне интересна — многое можно сделать в 2 строчки без запуска внешних процессов и разбора их вывода через grep и прочие ужасы. Но примерно с таким же успехом можно использовать и тот же Ruby, и Groovy, и даже NodeJS при должной мотивации.
KP>А почему для более сложных задач нельзя? На нем можно великолепно писать всяческие считалки (привет NumPy с Pandas) так и сервера (тут очень интересен Twisted). Единственное о чем бы я 10 раз подумал, перед тем как писать на Python – GUI приложения. У меня есть подозрения (не пробовал, только гадать могу), что в этой области выйдет не очень.
Ни разу не спорю, что можно. Вопрос в том, какая должна быть мотивация, чтобы выбрать Python, а не что-то другое. Если про NumPy мне возразить нечего (и не хочу — см. предыдущий пункт про "алгоритм"), то тот же Twisted — это совершенно точно не киллер-фича Python. Сейчас практически на любой платформе есть своё супер-производительное асинхронное решение для построения сетевого фасада. Но у многих из этих платформ ещё и нет недостатков, описанных выше, поэтому зачем Python?
A>>ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.
KP>Python обладает более обширной библиотекой (за пределами разработки Web-сайтов) чем Ruby и он слегка шустрее. Я бы не сказал что у Ruby есть какие-то серьезные преимущества, как минимум до тех пор, пока ты Рельсы не хочешь использовать.
Тут снова достаточно возразить, что у Ruby как минимум нет проблем 2 vs. 3, огроменный централизованный репозиторий с кучей библиотек и тот самый, упомянутый вами, RoR. Даже если согласиться, что Ruby и Python примерно одинаковы, окей, почему Python, а не Ruby?
A>Совершенно попсовая практика — весь хардкор написать на чём-то одном, а потом сверху прикрутить какой-нибудь JS.
Ты не понял. Критичный "хардкор" пишется на языке низкого уровня. Остальная часть на (предметно ориентированном) языке более высокого уровня.
Здравствуйте, eskimo82, Вы писали:
A>>Совершенно попсовая практика — весь хардкор написать на чём-то одном, а потом сверху прикрутить какой-нибудь JS. E>Ты не понял. Критичный "хардкор" пишется на языке низкого уровня. Остальная часть на (предметно ориентированном) языке более высокого уровня.
E>Это правильный подход.
Моя мысль была не столько о конкретной роли Python, сколько в самом факте того, что далеко не на все роли он подходит.
Здравствуйте, eskimo82, Вы писали:
A>>Но как только нащупаюсь, перепишу всё на C#. E>Зачем ? Шило на мыло ?
Затем, что проект _уже_ на C#.
E>Что из бонусов ты хочеш получить после переписывания на шарп ?
Сопровождаемость, неразрастание требований к квалификации программиста, которому позже придётся в этот код вносить изменения. Программистов знающих язык A всегда больше, чем программистов знающих одновременно A и B.
Неразрастание требований к рабочему месту — отсутствие необходимости ставить и конфигурировать десяток инструментов. Неразрастание инфраструктуры для сборки и деплоймента.
E>поизводительность не изменится в силу очевидных причин. E>а переносимость станет хуже (исчезнет воввсе).
Если проект _уже_ существует как "проект на C#", очевидно, что переносимость не рассматривается как ценность.
A>Сопровождаемость, неразрастание требований к квалификации программиста, которому позже придётся в этот код вносить изменения. Программистов знающих язык A всегда больше, чем программистов знающих одновременно A и B. A>Неразрастание требований к рабочему месту — отсутствие необходимости ставить и конфигурировать десяток инструментов. Неразрастание инфраструктуры для сборки и деплоймента.
Если нет возможности нанять квалифицированных програмистов, то имеет смысл посмотреть на интерпретируемые языки-песочницы. И неуходиь из них. Это очевидно.
A>Если проект _уже_ существует как "проект на C#", очевидно, что переносимость не рассматривается как ценность. A>Ещё вопросы?
Зачем вам Python ?
Здравствуйте, eskimo82, Вы писали:
A>>Сопровождаемость, неразрастание требований к квалификации программиста, которому позже придётся в этот код вносить изменения. Программистов знающих язык A всегда больше, чем программистов знающих одновременно A и B. A>>Неразрастание требований к рабочему месту — отсутствие необходимости ставить и конфигурировать десяток инструментов. Неразрастание инфраструктуры для сборки и деплоймента. E>Если нет возможности нанять квалифицированных програмистов, то имеет смысл посмотреть на интерпретируемые языки-песочницы. И неуходиь из них. Это очевидно.
A>>Если проект _уже_ существует как "проект на C#", очевидно, что переносимость не рассматривается как ценность. A>>Ещё вопросы? E>Зачем вам Python ? В том плане, что он даст для отладки алгоритмов, по сравнению с шарпом ?
Здравствуйте, 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>Из перечисленных языков десктопных только два, из них кроссплатформенный — один. И это, внезапно, питон
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>Что такое "десктопный язык"?
Язык, подходящий для разработки десктопного софта.
хотел уже на боковую
папаху снял и сапоги
но в комментариях проснулись
враги
