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

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

W>>Строгий, типизированный язык
С>

С>Язык, понятный людям
С>

На основании чего сделан такой вывод? Чем допустим cs понятнее Python?
Да вот хотя бы скриптовые языки обходятся без явных get/set методов и можно писать в атрибуты напрямую. ЛюдЯм понятнее
Ну и всякие там BaseFactoryCustomerAccountStrategyFactoryGeneratorResultExceptionPresenterFacade не попадаются

W>>При прочих равных я предпочту недоязык. По причине более краткости и батарейности.
С>Одно радует, что перл помирает вместе с его седыми адептами.

Perl6 очень хорош. Эпизодически набегаю почитать и побровать. Годнота

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

С>А еще в odoo нужно ставить модули в строго определённом, но неизвестном порядке. Иначе оную odoo перекосоё%ит — без предупреждения, и больше на неё ничего поставить не удастся.

С чего ты такое взял, нет такого. В модуле прописываются зависимости от других модулей, все устанавливается как надо.
Может какой-то ты какой-то левый (недоработанный) модуль поставил

С>В общем, шлак ваша Odoo, в девичестве OpenERP.

На мой взгляд, далеко не шлак.
Продукт уровня 1С:УПП, только с возможностью точечной доработки (модулями), на нормальном языке, с нормальной IDE

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

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

Понятие "строгой" типизации размытое, четкого определения, если я правильно понимаю, нет. Вот вы что именно называете строгой типизацией, применимо к Питоне/JS? Ворнинги компилятора и подсветку в IDE? Или есть что-то "посильнее"?

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

M>Ну давай возьмем последние PHP и Python. В чем по твоему заключается их недоязыковость?

Не возьмусь указать на конкретную проблему, если конечно не называть проблемой динамическую суть самого Python. Но вот что-то я до сих пор не видел примеров, где его "правильно готовят". Для простых скриптов (в пределах нескольких сотен строк кода) — все прекрасно. А вот когда над проектом начинают работать более двух-трех человек, начинаются грабли. Я работал в разных крупных конторах. В нескольких местах использовался Питон для вспомогательных задач типа тестов и я пока не видел, чтоб разработка на Питоне проходила столь же гладко, как для статически типизированных языков.

Вот сейчас у нас интеграционные тесты на Питоне написаны. Все прекрасно структурировано и объектно-ориентировано, с продуманной иерархией наследования и хорошей читабельностью кода. Прям "вах!". Вот честно. Но оно при этом то и дело ломается от свежих коммитов. В 9 случаев из 10, когда я вижу упавший билд, мне даже не нужно смотреть на конкретную ошибку в логе — просто перезапускаю верификацию и обычно со второго раза оно проходит. А это еще +4 часа ожидания результата.

Потому что, в отличие от Java, при коммите питоновского кода никаких особых проверок компилятор не делает. Каждое изменение, само по себе, выглядит корректно и программер, который писал код, наверное смотрел, нет ли ворнингов и даже (хочется верить) запустил код перед отправкой на код-ревью. Но где-то после слияния изменений от нескольких человек все время что-нибудь ломается. И происходит так по несколько раз на дню. Плюс, все сильно усугубляется использованием веб-сервисов — если где-то поменялся параметр REST-запроса, то пока соответствующий тест не запустится, никто даже не узнает, откуда оно там еще вызывается. И ошибки каждый раз — какое-то нечитаемое гумно из кучи "неправильный вызов __init__" или еще чего-то, внушающего уныние. Не, я, конечно, согласен — беглый взгляд на те сообщения и просмотр последних коммитов позволяет найти ошибку за несколько минут, но к этому моменту уже потеряно N часов ожидания результатов билдов. Десяток человек запустили верификацию билда, прождали 3..5 часов чтоб увидеть сообщение об ошибке в рантайме, которое было бы найдено сразу в любом языке со статической типизацией. И изменение API для языков со статической типизацией тоже куда менее болезненно — пересобираем прокси-классы и видим, где компилятор сказал про несовпадение параметров. А для Питона — перезапускаем, ждем 5 часов и разгребаем логи.

Кто-то когда-то, много лет назад, решил у нас писать интеграционные тесты на Питоне. А сейчас никто уже не будет переписывать десятки и сотни тысяч строк кода на Питоне. Остается страдать. При том, особых плюсов от такого выбора уже и не видно. Когда объем кода маленький, то Питон кажется более легким выбором в плане модификаций. Когда же оно переступает весьма небольшой порог сложности, то сложность поддержки такого кода, по-моему, куда выше.

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

S> Вот Когда 1С будет на "odoo на питон", тогда можно и попробовать.

А эта оду умеет больше одного типв дб? Она умеет из коробки веб-клиента и мобильного клиента? А то по вики это не понятно....

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

S> S>> Я как программист 1С
S> DC>Не льсти себе )))
S> То есть 1С ник не программист?

Нет. Он выше этого

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


AK>Понятие "строгой" типизации размытое, четкого определения, если я правильно понимаю, нет. Вот вы что именно называете строгой типизацией, применимо к Питоне/JS? Ворнинги компилятора и подсветку в IDE? Или есть что-то "посильнее"?

часто используют "строгую" как синоним "сильной".
я как раз об этом — сильная типизация есть.

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

_>Потому как они способны неприятно удивлять:

это как C# ругать за то, что в линке нет map/reduce, а какие-то select/where

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

S>>>Нет строгой типизации
F>>тебе бы выучить, что там есть, а чего нет.
F>>а то хвалиться безграмотностью — нездоровая черта.
AK>Понятие "строгой" типизации размытое, четкого определения, если я правильно понимаю, нет. Вот вы что именно называете строгой типизацией, применимо к Питоне/JS? Ворнинги компилятора и подсветку в IDE? Или есть что-то "посильнее"?

Есть вполне однозначное определение строгой (она же сильная) типизации. Ты же надеюсь не путаешь это понятие с динамической/статической типизацией? )))

P.S. А подсветка в IDE вообще не имеет никакого отношения к особенностям языка.

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

AK>Потому что, в отличие от Java, при коммите питоновского кода никаких особых проверок компилятор не делает. Каждое изменение, само по себе, выглядит корректно и программер, который писал код, наверное смотрел, нет ли ворнингов и даже (хочется верить) запустил код перед отправкой на код-ревью. Но где-то после слияния изменений от нескольких человек все время что-нибудь ломается. И происходит так по несколько раз на дню. Плюс, все сильно усугубляется использованием веб-сервисов — если где-то поменялся параметр REST-запроса, то пока соответствующий тест не запустится, никто даже не узнает, откуда оно там еще вызывается. И ошибки каждый раз — какое-то нечитаемое гумно из кучи "неправильный вызов __init__" или еще чего-то, внушающего уныние.

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

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

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

S>> Вот Когда 1С будет на "odoo на питон", тогда можно и попробовать.

DC>А эта оду умеет больше одного типв дб? Она умеет из коробки веб-клиента и мобильного клиента? А то по вики это не понятно....

Система работает на postgres только. Естественно, можно подключаться к внешним базам средствами питон.
Веб-клиент из коробки есть, и он является основным. Десктоп-клиента нет, мобильный клиент есть для andriod и ios.

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

_>Есть вполне однозначное определение строгой (она же сильная) типизации.

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

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

F>почему автор сам не запускает свои тесты, если он их пишет?

Запускает, разумеется! Только чем это поможет-то? Я думаю, вы и сами легко можете описать вариант, когда все ломается к лешему.

Как пишется любой софт? Написали, отладили, сдали. Через два месяца нужно что-то допилить — разработчик из другой команды добавляет к методу новый параметр. Свои тесты погонял — все работает. Ближайший код просмотрел — вроде везде поменял, где надо. Закоммитил — опа, отвалилось двадцать семь тестов, написанных другой командой три недели назад. Потому что там тоже вызывается тот метод, но VSCode/PyCharm этого не покажет. Когда над разными частями проекта работают десятки людей из разных команд, то без проверок на этапе компиляции становится сложно.

Ну и классика, которая ломает билд вообще на любом языке — "race condition в GIT". Два разработчика поменяли два разных куска кода, зависящих друг от друга. Каждый по-отдельности проверил билд, прошел ревью кода и получил все подписи на мерж кода. Оба отправляют код в GIT и билд разваливается, потому как по-отдельности куски кода корректные, но вместе дают баг.

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

_>Есть вполне однозначное определение строгой (она же сильная) типизации.

Можете привести это определение? А то википедия говорит "термины не являются однозначно трактуемыми".

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

F>>почему автор сам не запускает свои тесты, если он их пишет?
AK>Запускает, разумеется! Только чем это поможет-то? Я думаю, вы и сами легко можете описать вариант, когда все ломается к лешему.

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

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

Мне кажется описаны общие проблемы разработки больших проектов большой командой. Неужто при статической типизации не ломают билды, не портят друг друг pull request-ы и NullPointerException потом не появляется в рантайме?
Да, компилятор часть проблем отловить на стадии компиляции. Зависит, конечно, от проекта и компилятора, но сколько времени может занять перекомпиляция проекта чтобы все проверить? Насколько это сравнимо с запусками тестов?
Хотя да, в динамическом языке смены интерфейса — это веселая штука, нужно уметь готовить

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

AK> ждем 5 часов
Это в один процесс или с распараллеливанием тестов?

S>Как известно, на плохих языках писать намного сложнее. Но почему то именно плохие языки завоевывают любовь публики.
S>В чем причина? Вот этого никак понять не могу.

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

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

S>В чем причина? Вот этого никак понять не могу.
Низкий уровень образования коненчо же.
S>Взять тот же JS, PHP или Python даже. Ну JS то понятно, хотя и тут светила человечества, которые устанавливают Web-стандарты, могли бы по уму поступить.
Порог входа. В JS и PHP легко зайти и сделать что-то рабочее, мелокое, на коленке и продать, а получив свои первые 1000$ кричать на каждом углу что он великий бизнесмен и JS/PHP лучше всех. Всё более-менее серьёзное они реализовать уже не смогут, да и не будут, а вскуреки про масштабируемость не подтверждаются рельным опытом.
S>Вот не понятна мне логика этого мира и все тут. Сами же себе кактусы придумывают.
Пусть придумывают. Чем больше любителей недоязыков там где не надо, тем дороже услуги профи по переделке этого всего, главное чтобы использование недоязыков не набрало крит. массу.

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

K>вскуреки про масштабируемость не подтверждаются рельным опытом.

расскажи про свой реальный опыт.