• Есть ли аналоги перлового Coro в Python 3?

    mututunus
    @mututunus
    Backend developer (Python, Golang)
    Ответ написан
    Комментировать
  • Как разбить массив?

    С помощью срезов, например:
    m = [3, 5, 'o', 4, 5, 'c', 9]
    m[2:6] = [m[3:5]]

    Индексы срезов можно найти с помощью метода index у списка.
    Ответ написан
    Комментировать
  • В чем преимущество динамически типизированных языков?

    Tiendil
    @Tiendil
    Разработчик ПО.
    Преимущество у динамически типизированных языков, конечно, не в синтаксисе, а в семантике.

    Благодаря определению типов во время исполнения программы сильно облегчается метапрограммирование. Очень сильно облегчается. Оно, в свою очередь, упрощает всю остальную работу.

    Благодаря гибкости кода в рантайме (см. тот же duck typing) и интроспекции (анализ свойств объектов и кода) получается на порядок проще и быстрее писать универсальные алгоритмы и конструкции вроде декораторов, всяческих ORM и подобных вещей. Это сильно упрощает интерфейсы библиотек, что в совокупности ведёт к более простому коду и к плавной кривой обучения новичков.

    Из моей практики (5 лет писал на C++, потом столько же на Python, эти сроки немного пересекались) могу сказать, что с точки зрения ошибок типизации (а собственно их и ставят в недостаток динамически типизированным языкам) разница минимальна — они очень редки и все отлавливаются автоматическими тестами. Конечно, если у вас руки откуда надо растут, а если не откуда надо, то эти ошибки будут далеко не самой большой проблемой. Поэтому в области разработки софта, не требовательного к производительности, такие языки рулят.

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

    В итоге мы получаем классическую дилемму: повышение уровня абстракции против повышения уровня специализации. У каждого пути есть свои плюсы и минусы.

    По производительности питона ссылок уже накидали, но в любом случае тут надо исходить из требований конкретной задачи — проще взять и протестировать самому.
    Ответ написан
    Комментировать
  • Как добавить в Python xmlproc?

    xSkyFoXx
    @xSkyFoXx
    Эм... 10 лет как deprecated и удалено из стандартной библиотеки.
    Опишите подробнее свою задачу, помогу вам найти альтернативу.
    Ответ написан
    6 комментариев
  • Почему не все серверы пишутся на Node js?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
    Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

    2. Ответ на абстрактный вопрос:
    а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
    б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
    в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

    UPD
    hbrmdc
    У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
    Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

    1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
    JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

    На самом деле основные отличия другие:
    Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

    2) Личные предпочтения обоснованные привычками это основной аргумент.
    Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
    Мне нужна новая команда на новый проект.
    Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
    PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
    Собственно на этом выбор и закончен.

    На малопопулярных языках пишут в случаях:
    a) это мелкий сервис с неявными перспективами который можно переписать за неделю
    б) это проект "для души" разработчика.

    Получается замкнутый круг на самом деле.
    Менеджер смотрит резюме, резюме на node.js нет =>
    Менеджер не начнет проект на node.js =>
    Не возникнет вакансия на node.js =>
    Разработчик анализируя вакансии не увидит вакансий на node.js =>
    Разработчик будет учить что то другое =>
    Менеджер смотрит резюме, резюме на node.js нет...

    Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)
    Ответ написан
    13 комментариев
  • Почему не все серверы пишутся на Node js?

    mannaro
    @mannaro
    Умею профессионально гуглить
    Есть Ассемблер.
    Но если он есть, на нем все возможно, и в добавок он соображает быстрее того же C++, то почему еще существуют другие решения в мире софтовой разработки?

    Традиции, привычки и необходимость поддерживать существующие проекты не в счет. Мне интересно, почему новые проекты пишутся не всегда на ассемблере?
    Ответ написан
    14 комментариев
  • Как правильно читать книги по программированию?

    saboteur_kiev
    @saboteur_kiev Куратор тега Книги
    software engineer
    сперва были вопросы "как стать программистом"
    затем вопросы "что читать"
    теперь уже "как читать"
    может скоро будет "как учить алфавит, а то за меня родители пишут на тостере".

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

    Добавлю еще момент:
    Почитайте статью megamozg.ru/post/10126
    Там очень понятно указано, что профессиональный навык и боль программиста - гиперконцентрация, которая необходима, чтобы освоить понятия и вещи для профессиональной работы. 40 минут это как-то несерьезно.
    Ответ написан
    3 комментария
  • Flask - когда новый релиз?

    @denkl
    Комментарий Армина на реддите
    There is going to be a new release soon. There just was no real need to make a release.
    Ответ написан
    Комментировать
  • Как прокачаться и научиться языку программирования\аналитики R?

    Добавлю, там же на курсере есть пачка курсов по анализу данных:
    https://www.coursera.org/jhu
    Сам так начал программировать на R, еще можно взглянуть на udacity -- они очень не плохи, там же есть курс на pandas -- этакая смесь python и R.

    В качестве практики можно начать писать статьи на хабр по этой теме. Все данные стараюсь собрать в одном и том же месте для всеобщего пользования: https://github.com/SergeyParamonov/HabraData

    Народ на хабре такое воспринимает более менее положительно, там же можно получить фидбек (в виде комментов от знающих товарищей)
    habrahabr.ru/company/dmlabs/blog/219679
    habrahabr.ru/post/236759
    habrahabr.ru/company/dmlabs/blog/218607
    Ответ написан
    Комментировать