Здравствуйте, Calc, Вы писали:
НС>>Нет, это фанатизм вызванный нежеланием менять точку зрения. На РНР почти не делают новых проектов, это факт. А дальше нужно либо его принять, либо выстраивать вокруг себя виртуальную реальность, где РНР офигенен. C>вот это новость. Весь мобильный бэкэнд на PHP, пройдитесь по агенствам.
ЛОЛ.
Например, внутри Amazon (компания стоимостью в триллион) язык PHP прямо запрещён для проектов. В смысле, совсем запрещён.
Здравствуйте, Буравчик, Вы писали:
C>>Отладчик в PyCharm не может нормально работать с gevents или в удалённом режиме. Б>Работает, вроде, с gevent. И удаленный режим поддерживает.
Ключевое слово здесь "нормально".
C>>Find Usages работает за счёт эвристик и очень часто ничерта не находит, особенно если надо смотреть библиотечный код. Б>Не сталкивался с такими проблемами (пока?), в т.ч. с библиотеками
Проблема с Find Usages в том, что он работает за счёт эвристик. Если в своём коде ещё можно расставить аннотации типов, то в библиотеках их чаще всего просто нет.
Здравствуйте, neFormal, Вы писали:
F>>>в статике ровно то же самое будет C>>До такой степени — не будет. Просто за счёт типов. F>в типах ты просто не всё можешь сделать.
Что не смогу?
F>поэтому у тебя меньше точек внимания, голова напрягается меньше, и кажется, что ты всё контролируешь F>на самом деле это как отрезать себе ноги с обоснованием "всё равно я не бегаю"
Нет. Типы — это как перила на лестнице. И они мешают прыгать с пролёта на пролёт.
F>>>вообще, все давно проекты держат в локальных окружениях для конкретного проекта C>>venv — это просто Докер для бедных. Он не решает проблем версирования и повторяемых сборок. F>дык он для разработки, лел F>с докером его можно сравнить только от большой фантазии
Идеология та же — создание виртуального окружения. В venv — за счёт магических переменных окружения.
C>>Те кто пишет что-то серьёзное — испытывают. F>у тебя "серьёзное" начинается от сотни строчек кода. а это даже не смешно.
Нет. Просто тривиальный проект имеет опасность вырасти до нетривиального. Потому имеет смысл использовать нормальные технологии сразу же.
Сто строчек — это нижний предел для риска.
F>конечно, неосиляторы испытывают сложности, это факт. но это с любыми технологиями
Осилить можно что угодно. Но зачем?
Здравствуйте, Cyberax, Вы писали:
N>>Как в Яве с такой мегафичей "обычной разработки и отладки" как repl? C>Есть. В самой удобной форме — можно остановиться на breakpoint'е и в отладчике выполнить произвольный код.
Ну создай в отладчике на ходу функцию на десять, ой я забыл у нас Джава, на 100 строчек.
C>Есть чистый REPL в виде JShell, но мало кому интересен.
Правильно, потому что неудобно. Язык должен быть разработан под REPL изначально.
N>>Правильно, используй IoC и еще кучу файлов на всех возможных форматах разметок и убогим синтаксисом для каждой библиотеки. Отладка? "методом тыка"! Навигация? Попросите JBrains, они может быть сделают для вас плагинчик. Неправильные джависты" еще используют Groovy и прочую гадость. Получился продуктивный зоопарк. C>IoC можно делать без всяких фреймворков, я так и делаю в Golang, например.
Можно делать свои велосипеды, только это не всегда продуктивно. Не воспринимай как критику — я в курсе, что в Go нет нормальных библиотек и ide и у тебя просто не было выхода.
C>Навигация по Spring работает безупречно, так что на практике это не проблема.
Со Spring-ом может сейчам и не проблема, только это давно легаси. В среднем джава-проекте есть обычно пяток DSL-ей на корявых языках разметки. Метапрогаммирование позволяет этого избежать.
N>>Find Usage с аннотацией в Py3 работает нормально. C>А с нормальными типами — ещё лучше.
С нормальными да, но нормальные в Яву и Go не завезли. А в те языки куда завезли, есть другие проблемы.
N>>find/grep никто не отменял. За время пока ту создашь нужное для поиска проблемы в Яве окружение, пэтч на питоне уже уйдет в продакшн. C>Нет, пока я в IDE нажму Alt-F7 и напишу патч с тестами — в Питоне всё ещё будет разворачиваться venv, тщетно пытаясь скомпилировать код на Cython.
При чем здесь Cython?
N>>Для меня нет. Говнокод не нужен, но любителям Go не понять. C>Это просто у тебя опыта работы нет.
Дешевый приемчик. Я таким манером могу тебе брейнфак рекламировать.
C>Иначе знал бы, что твоя собственная нетленка — это тот же говнокод.
Под говнокодом понимается в данном случае boilerplate для решение простейших задач, а не кодерские способности.
Здравствуйте, novitk, Вы писали:
C>>Есть. В самой удобной форме — можно остановиться на breakpoint'е и в отладчике выполнить произвольный код. N>Ну создай в отладчике на ходу функцию на десять, ой я забыл у нас Джава, на 100 строчек.
Это не проблема совершенно. В Java можно на лету заменять код, кстати. Как с этим в Питоне?
Ой, никак.
C>>Есть чистый REPL в виде JShell, но мало кому интересен. N>Правильно, потому что неудобно. Язык должен быть разработан под REPL изначально.
Зачем? REPL в принципе не очень-то удобен для реальной разработки.
Даже там, где REPL удобен (научные эксперименты), сейчас предпочитают использовать блокноты Jupyter.
C>>IoC можно делать без всяких фреймворков, я так и делаю в Golang, например. N>Можно делать свои велосипеды, только это не всегда продуктивно. Не воспринимай как критику — я в курсе, что в Go нет нормальных библиотек и ide и у тебя просто не было выхода.
Никаких велосипедов не нужно. IoC не требует контейнеров, от слова "вообще".
C>>Навигация по Spring работает безупречно, так что на практике это не проблема. N>Со Spring-ом может сейчам и не проблема, только это давно легаси. В среднем джава-проекте есть обычно пяток DSL-ей на корявых языках разметки. Метапрогаммирование позволяет этого избежать.
Метапрограммирование не позволяет ничего избежать. Оно просто добавляет удовольствия ещё и отлаживать язык программирования, вдобавок к прикладной программе.
У всяких хипстеров Spring может быть и legacy, но мне на хипстеров плевать.
N>С нормальными да, но нормальные в Яву и Go не завезли. А в те языки куда завезли, есть другие проблемы.
Что не так с типами в Java?
C>>Нет, пока я в IDE нажму Alt-F7 и напишу патч с тестами — в Питоне всё ещё будет разворачиваться venv, тщетно пытаясь скомпилировать код на Cython. N>При чем здесь Cython?
Ну как же, это же решение проблем с тормозами!
N>>>Для меня нет. Говнокод не нужен, но любителям Go не понять. C>>Это просто у тебя опыта работы нет. N>Дешевый приемчик. Я таким манером могу тебе брейнфак рекламировать.
Ты это и делаешь прямо сейчас.
C>>Иначе знал бы, что твоя собственная нетленка — это тот же говнокод. N>Под говнокодом понимается в данном случае boilerplate для решение простейших задач, а не кодерские способности.
В Питоне его будет не меньше.
Здравствуйте, neFormal, Вы писали:
F>банальный пример с гетерогенными списками F>очень актуально для конфигов, где в одном списке могут лежать разные структуры данных
Любой конфиг имеет схему данных.
Данных без схемы в принципе не бывает. Просто иногда этой схемы нет в явном виде.
Всё что нужно для статически типизированного языка это задать эту схему явно.
И динамически типизированные языки тоже требуют схему данных.
Просто эти требования размазаны ровным слоем по всему коду.
F>в некоторых статических языках это можно ещё быстро описать, но мейнстримовые требуют довольно много действий, и большинство программистов этого старательно избегают
Надеюсь, ты понимаешь, что проблемы некоторых языков не могут быть доказательством преимуществ динамической типизации?
Ибо если тебя так сильно напрягает жаба, то кусок программы можно написать на скале где с типами всё в порядке. И спокойно интегрировать эти два куска программы.
Интеграция с питоном будет куда сложнее.
F>а если события происходят в какой-то готовой системе, то там вообще нереально таким воспользоваться F>в динамике с этим в разы проще, т.к. на лету можно понять, с чем ты работаешь
С чего это? И там и там будет одна и та же гора условий.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Dair, Вы писали:
D>Здравствуйте, AleksandrN, Вы писали:
AN>>Потом буква P означала Perl/PHP. PHP вытеснил Perl из веб-разработки и я думал, что PHP остаётся основным языком для разработки на стороне сервера. А в этой теме пишут, что это уже не так.
D>Ну как бы современный веб — это статический js-фронтенд (чаще всего на каком-нибудь React или Angular), который на бекэнд ходит за данными в формате json. PHP для этого ну вообще не нужен.
C>>>Продуктивность определяется не тем, какие в языке есть средства метапрограммирования и мега-супер-фичи, а удобством обычной разработки и отладки. Т.е. как быстро подключить библиотеки, как делать навигацию по исходникам (простейший Find Usage спасает часы разработки) и как отлаживать. Б>>Имхо, с этим, в питоне все очень хорошо. В PyCharm и отладчик норм, и навигация есть, и Find Usage, и библиотеки легко подключаются. C>Отладчик в PyCharm не может нормально работать с gevents или в удалённом режиме.
C>Find Usages работает за счёт эвристик и очень часто ничерта не находит, особенно если надо смотреть библиотечный код.
C>>>1) Динамичности. Любая реальная большая кодовая база становится крайне лохматой, даже если писать в стиле Питон-с-классами и избегать магии в виде декораторов и прочих страшностей. Тестов обычно бывает недостаточно. В>>Самый мой крупный проект содержал более 3-х миллиардов строк на питоне. Работало там 7 тысяч программистов. В>>Кол-во бардака было такое же как и в проекте на яве. Сравнивомогу по размеру. C>Я участвовал в миграции проекта с Питона на Go. Количество бардака после миграции сильно упало, а качество увеличилось. Количество строк там было меньше, в районе десятка миллионов. Миграция заняла несколько лет.
Какие-то чудеса рассказываешь. Пять самых крупных в мире банков с огромным удовольствием уходят из Явы (почти ушли, на самом деле) в питон. Я про 80% их кода.
Они такие тупые, а ты умный?
C>Понятно, что при желании и должной дисциплине можно и на ассемблере всё писать. Но зачем?
Затем, что когда хочешь написать на яве, с# или подобных языках то, что делается на питоне за час-два у тебя вдруг это занимает день. А то и два.
C>>>2) Однопоточности. Это реально проблема — сервер придётся запускать в виде нескольких процессов, что делает невозможным вещи типа разделяемого кэша. В>>Никогда не нужно. CPython, корутины, сервлеты и вообще торнадо. или твистед. числодробилки не берём во внимание. Их менее 1% C>Брехня это всё. Оно всё равно будет однопоточным, асинхронность просто размажет тормоза по всем клиентам.
Это не брехня, как ты изволился утончённо выразиться, а суровая правда жизни. Если у тебя распределённая система (и база), кучка сервисов и клиентов, то I/O будут занимать минимум 50%, а то и все 90% времени выполнения. Если ты, конечно, фибоначчи считаешь или там рисуешь чего, тут питон конечно не нужен. Только когда ты последний раз подобные задачи решал?
C>Корутины в текущих реализациях Питона относятся к категории "do not use" из-за "coloured function problem".
Сам придумал?
C>>>3) Интерпретируемости. Если нужно делать высокоскоростные сервисы, то можно забыть про высокоуровневые библиотеки типа SQLAlchemy. Теоретически на подходе есть PyPy, но он всё ещё не дорос. В>>Алё. CPython и компиляция в ц++. C>Эээ... Ты ТОЧНО писал на Питоне? CPython — это интерпретатор Питона. Есть Cython, но он крайне ограничен и требует писать на (фактически) С с питоновским синтаксисом.
Да, писал. Cython нужен для всях вычислений. И на нём не пишут обычно. А пишут сперва на нормальном питоне, а потом когда уже всё готово — оптимизируют.
Я же имел ввиду, что если у тебя сервис занимается сбегать в базу и отдать json, то разницы 0. Если там какая-то математика, то это решается опусканием на C++ уровень (через библиотеки типа pandas, numpy и т.п.). В тех совсем редких случаях, когда тебе нужно параллелить работу есть multiprocessing.
C>К нему прилагается сложность распространения — если хочется распространять бинарные артефакты, то с Cython начинаются прыжки и ужимки из-за его мега-умности.
Ты пробовал? Там всё прямолинейно как дерево, какие прыжки?
C>>>4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/ В>>Это о чём? В>>Докер, хренокер — одной пяткой. Уставновка на виртуалку или в процессе разворачивания — элементарно. C>Даже с Докером хорошей практикой является создание наиболее лёгкого образа, без компиляторов и сред разработки внутри.
эээ каких сред разработки? Докер несколько для другого. Обычно в образё все, что тебе нужно для ИСПОЛНЕНИЯ.
Пакетный же менеджер под названием pip отлично справляется со своими задачами уже много лет.
C>>>При этом начинать проект легко, да. Сначала код пишется как будет сам. Но вот потом всё становится очень уныло. Я и сам попадал в эту ловушку, и в других проектах тоже встречал. В>>С индусами что-ли работал? C>В том числе и с ними (разных национальностей), как на любом большом проекте.
Ну, с ними проблем конечно становится больше. Тут как раз без твоей дисциплины только на компилятор полагаться.
Правда, когда они пишут SQL функцию (компилируемую) на 10 тыщ строк с 39-ю запросами внутри (и обращению к десяткам разных таблиц), это понять можно только после присоединения к кришне.
C>>>Да, всё то же относится к Ruby и немного меньшей степени к NodeJS (он хотя бы быстрый). В>>Угу, особенно яваскрипт тут поможет. C>JS нынче чаще всего заменяют TypeScript, который более-менее адекватен по сравнению с Питоном.
Не заметил огромной адекватнойсти. И мода на TS что-то утихла.
Здравствуйте, WolfHound, Вы писали:
F>>банальный пример с гетерогенными списками F>>очень актуально для конфигов, где в одном списке могут лежать разные структуры данных WH>Любой конфиг имеет схему данных.
вообще, нет.
например, если в качестве конфига выступает скрипт(а такое тоже бывает), то схемы там нет
это задача читалки конфига привести конфиг к какой-то структуре, если надо
WH>Данных без схемы в принципе не бывает.
я понимаю, что это КСВ, но совсем в глупый фанатизм сваливаться не надо.
WH>Всё что нужно для статически типизированного языка это задать эту схему явно.
а ещё как [де-]сериализовывать.
и это намного сложнее, чем в нескольких местах расставить условия для кастомного поведения.
F>>в некоторых статических языках это можно ещё быстро описать, но мейнстримовые требуют довольно много действий, и большинство программистов этого старательно избегают WH>Надеюсь, ты понимаешь, что проблемы некоторых языков не могут быть доказательством преимуществ динамической типизации? WH>Ибо если тебя так сильно напрягает жаба, то кусок программы можно написать на скале где с типами всё в порядке. И спокойно интегрировать эти два куска программы. WH>Интеграция с питоном будет куда сложнее.
к сожалению, скалка не относится к таким языкам.
там много разных фич по статической типизации, но это лишь для самоудовлетворения адептов данного подхода. прикладные задачи оно не решает.
F>>а если события происходят в какой-то готовой системе, то там вообще нереально таким воспользоваться F>>в динамике с этим в разы проще, т.к. на лету можно понять, с чем ты работаешь WH>С чего это? И там и там будет одна и та же гора условий.
в динамике не будет специфичной сериализации, и не надо будет описывать структуры данных.
Здравствуйте, Ватакуси, Вы писали:
В>Какие-то чудеса рассказываешь. Пять самых крупных в мире банков с огромным удовольствием уходят из Явы (почти ушли, на самом деле) в питон. Я про 80% их кода.
Можно полюбопытствовать, откуда вы знаете про 80% кода в пяти самых крупных в мире банков? Даже не одного, а сразу пяти.
Здравствуйте, Cyberax, Вы писали:
C>Типы — это как перила на лестнице. И они мешают прыгать с пролёта на пролёт.
типы — это такие костыли, чтобы программа не падала рандомно после запуска.
F>>с докером его можно сравнить только от большой фантазии C>Идеология та же — создание виртуального окружения. В venv — за счёт магических переменных окружения.
фактически виртуальная машина и переменные окружения — немножко не одно и то же.
Здравствуйте, Cyberax, Вы писали:
F>>банальный пример с гетерогенными списками F>>очень актуально для конфигов, где в одном списке могут лежать разные структуры данных C>1) Не надо так делать.
ты скозал?
C>2) Какие проблемы-то?
сериализации дофига
F>>в некоторых статических языках это можно ещё быстро описать, но мейнстримовые требуют довольно много действий, и большинство программистов этого старательно избегают C>List<Object> — Java, []interface{} — Go, std::list<void*> — C++, ...
Здравствуйте, Ночной Смотрящий, Вы писали:
F>>например, банальные форумы и прочие штуки лучше сделаны на пхп, поэтому для бизнеса оно быстрее и дешевле НС>Это не делает пхп хорошим языком.
я не считаю его хорошим.
но бизнес считает. я только об этом.
Здравствуйте, Ватакуси, Вы писали:
В>Какие-то чудеса рассказываешь. Пять самых крупных в мире банков с огромным удовольствием уходят из Явы (почти ушли, на самом деле) в питон. Я про 80% их кода.
Здравствуйте, neFormal, Вы писали:
F>вообще, нет. F>например, если в качестве конфига выступает скрипт(а такое тоже бывает), то схемы там нет
Так скрипт заполняет определённые структуры данных.
Дёргает определённое API.
F>это задача читалки конфига привести конфиг к какой-то структуре, если надо
Ты ничего из конфига прочитать не сможешь, если там уже нет структуры, которую понимает твоя читалка.
WH>>Данных без схемы в принципе не бывает. F>я понимаю, что это КСВ, но совсем в глупый фанатизм сваливаться не надо.
Так не сваливайся.
WH>>Всё что нужно для статически типизированного языка это задать эту схему явно. F>а ещё как [де-]сериализовывать. F>и это намного сложнее, чем в нескольких местах расставить условия для кастомного поведения.
Когда есть типы, то по ним можно просто сгенерировать читалку/писалку. Ну, или через рефлексию работать, если язык не имеет мета программирования.
А после того как всё прочитано то места динамической типизации уже не будет.
F>к сожалению, скалка не относится к таким языкам. F>там много разных фич по статической типизации, но это лишь для самоудовлетворения адептов данного подхода. прикладные задачи оно не решает.
А какие тебе нужны фичи?
Попробуй привести пример того что не решается через алгебраические типы данных.
WH>>С чего это? И там и там будет одна и та же гора условий. F>в динамике не будет специфичной сериализации, и не надо будет описывать структуры данных.
А работать ты как будешь с тем, о чём твой код не знает?
Твой код ждёт поля foo и bar, а получил baz и biz.
Что дальше?
Вот это ожидание foo и bar и есть неявно заданная схема данных.
И если в случае со статически типизированным языком ты при чтении конфига получишь сообщение об ошибке с указанием строки и позиции. То в случае с динамикой у тебя через полчаса свалится программа с сообщением: у объекта нет нужного поля.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Calc, Вы писали:
C>>вот это новость. Весь мобильный бэкэнд на PHP, пройдитесь по агенствам.
С>Это про РФ, видимо?
ну как бы домен сайта намекает
Да, про РФ. Любой проект со спринтом в 2 недели на бэк уходит в PHP.
