Новость про Mercurial.
Удивительное дело, что такой большой проблемой является переход на новую версию языка, которая появилась уже более 10 лет назад.
Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых.
Вот, просто ужаснулся и захотелось поделиться.
Здравствуйте, Nuzhny, Вы писали:
N>Удивительное дело, что такой большой проблемой является переход на новую версию языка, которая появилась уже более 10 лет назад. N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых. N>Вот, просто ужаснулся и захотелось поделиться.
Сначала хотел написать что полностью поддерживаю, но потом передумал. С одной стороны ты прав, писать на динамике что-то кроме прототипов и тестов зачастую себе дороже. С другой стороны, сейчас динамика как бы и не совсем динамика – со всех сторон проверка типов, аннотации, спеки... С другой стороны, писать приложение бодро оперирующее данными на динамике всё же удобнее и быстрее. Динамика многое упрощает, просто необходимо иметь что-то еще, как например функциональную парадигму.
Например мой текущий проект использует Elixir и на любом другом языке с которыми я работал (разве что кроме Clojure) его было бы куда более тяжело развивать. Но у нас классический бэкенд с кучей запросов к базе и отсутствием состояний.
Так что, задача важна, был бы Меркуриал на C++ (а какой был выбор был в 2005?), то были бы просто проблемы другого рода, не менее злобные. Если же говорить про миграцию C++ проектов, то у меня как-то ушло около 3-х месяцев перевести кодовую базу KAV на C++11. Правда надо признать, после этого никаких проблем связанных с миграцией на новый стандарт не было.
Здравствуйте, Nuzhny, Вы писали:
N>Новость про Mercurial. N>Вот, просто ужаснулся и захотелось поделиться.
# Mercurial will never work on Python 3 before 3.5 due to a lack
# of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
# due to a bug in % formatting in bytestrings.
# We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
# codecs.escape_encode() where it raises SystemError on empty bytestring
_># Mercurial will never work on Python 3 before 3.5 due to a lack
_># of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
_># due to a bug in % formatting in bytestrings.
_># We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
_># codecs.escape_encode() where it raises SystemError on empty bytestring
Здравствуйте, Nuzhny, Вы писали:
N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы!
По поводу прототипов. Некоторые обвиняют тот же C++ в излишней сложности для написания простеньких утилит. Тем не менее в нём существуют такие понятия как физическое и логическое постоянство. Можно написать весь проект в одном файле. Можно определять члены класса внутри класса. Это влияет на компиляцию, но не на результат.
Таким образом можно ли сказать, что написание простенького прототипа на динамическом языке действительно быстрее. К примеру, для того, чтобы запустить скрипт на динамическом языке нужен интерпретатор, это программа, которую так же приходится устанавливать (пусть даже она входит в состав другой программы), как и пакет утилит для компиляции.
Следующим пунктом идут алгоритмы. Они могут быть полностью своими или чужими. Чужие можно использовать через свою обёртку и соответственно напрямую без обёртки. Если алгоритмы свои, или используются через свою обёртку, то есть ли разница в языке программирования.
Ещё один момент, динамические языки хороши для связывания различных компонентов на этапе выполнения. С другой стороны, при написании прототипа всё это не имеет смысла, так как программная система и так полностью под управлением программиста пишущего код.
Главная моя мысль здесь не в том чтобы отказаться от динамических языков программирования для прототипирования, а в том, что в этом плане разницы между ними и языками с компиляцией практически нет. Это больше похоже на самообман, когда кто-то думает, что прототипировать нужно обязательно на динамическом языке программирования.
Здравствуйте, velkin, Вы писали:
V>По поводу прототипов. Некоторые обвиняют тот же C++ в излишней сложности для написания простеньких утилит. Тем не менее в нём существуют такие понятия как физическое и логическое постоянство. Можно написать весь проект в одном файле. Можно определять члены класса внутри класса. Это влияет на компиляцию, но не на результат.
В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами.
V>Таким образом можно ли сказать, что написание простенького прототипа на динамическом языке действительно быстрее. К примеру, для того, чтобы запустить скрипт на динамическом языке нужен интерпретатор, это программа, которую так же приходится устанавливать (пусть даже она входит в состав другой программы), как и пакет утилит для компиляции.
Можно-можно. Python по-умолчанию доступен много где.
V>Следующим пунктом идут алгоритмы. Они могут быть полностью своими или чужими. Чужие можно использовать через свою обёртку и соответственно напрямую без обёртки. Если алгоритмы свои, или используются через свою обёртку, то есть ли разница в языке программирования.
И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.
Здравствуйте, Sheridan, Вы писали:
S>Я как то писал про то что питон нужно в топку, не помню уже даже когда и контекст. Но некоторые личности до сих пор мне это вспоминают
Здравствуйте, Sheridan, Вы писали:
S>Я как то писал про то что питон нужно в топку, не помню уже даже когда и контекст. Но некоторые личности до сих пор мне это вспоминают
В печку же...
Некоторые личности также знают, что иногда ты его из печи вытаскиваешь. Правда, только с твоих слов.
Здравствуйте, kaa.python, Вы писали:
V>>По поводу прототипов. Некоторые обвиняют тот же C++ в излишней сложности для написания простеньких утилит. Тем не менее в нём существуют такие понятия как физическое и логическое постоянство. Можно написать весь проект в одном файле. Можно определять члены класса внутри класса. Это влияет на компиляцию, но не на результат.
KP>В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами.
Это отчасти справедливо только для очень маленьких утилит, в которых очень много сторонних библиотек. Что-то большее писать, чем хеловорд — это боль
V>>Следующим пунктом идут алгоритмы. Они могут быть полностью своими или чужими. Чужие можно использовать через свою обёртку и соответственно напрямую без обёртки. Если алгоритмы свои, или используются через свою обёртку, то есть ли разница в языке программирования.
KP>И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.
Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить
Некоторые части кода удобно писать на динамике. Не понимаю, почему так мало статических языков это позволяют. Кроме C# нигде не видел dynamic. В той же Java — пишешь взаимодействие через JSON какой-нибудь: либо описывай весь протокол классами, втискивая его в прокрустово ложе маппера и это не факт, что всегда получится; либо пиши кошмарный код с Map<?, ?> и List<?>. Куда проще было бы сказать dynamic в этом случае, пускай "под капотом" и были бы ровно те же Map-ы, но код был бы куда проще.
Здравствуйте, Nuzhny, Вы писали:
N>Вот, просто ужаснулся и захотелось поделиться.
Просто P2 и P3 шибко разные. Первый про списки, а второй про итераторы, например.
В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sheridan, Вы писали:
S>Да-да, ты в том числе
А я что? Я ничего. Ты выдаешь нетленки на века. В результате тебя индекс, наверное, один из самых высоких на RSDN.
Я, кстати, с "питон в печку" не так, чтбы согласен. Прототипы, или что-нибудь по-быстромы проверить, на нем очень удобно. А вот в production с динамикой надо быть поосторожнее.
Здравствуйте, vsb, Вы писали:
vsb>Куда проще было бы сказать dynamic в этом случае, пускай "под капотом" и были бы ровно те же Map-ы, но код был бы куда проще.
С dynamic есть одна проблема. Ими частенько злоупотребляют. Мне вот по наследству досталась некая утилита. Автор для удобства использовал dynamic и рефлексию. А я внезапно выяснил, что программа эта свою конфигурацию считывает вовсе не из конфига, а из весьма неожиданных мест. И как это теперь починить, я не очень представляю. Не, я, конечно, костыль поставил, и оно работает. Но как бы этот костыль в недалеком будущем в грабли не превратился.
N>Новость про Mercurial.
Неизвестно какое там вообще качество кода и качество людей.
N>Удивительное дело, что такой большой проблемой является переход на новую версию языка, которая появилась уже более 10 лет назад. N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых. N>Вот, просто ужаснулся и захотелось поделиться.
Так либо трудность разработки, либо динамика. И там и там плюсы и минусы.
PS: Большие проекты вполне пишутся, нужны только бабки и люди. Собственно, как везде.
M>Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить
Никогда не встречал. Может не компилироваться из-за ц++ хелла на твоей машине, это да. Раза 3 или 4 приходилось долго танцевать.
