• Перспективное место
    0

    Глядя на картинку, долго не мог понять, что медведь в халате делает около андроида.

  • Трагедия Common Lisp: почему популярные языки раздуваются в сложности
    +2

    Трагедия Common Lisp в том, что мало у кого есть желание как следует разобраться в этом чрезвычайно интересном и мощном языке, спроектированном лучшими умами того времени. Все в основном слышали звон про размер стандарта и скобки. Автор оригинальной статьи тоже не удосужился, что совершенно явственно из его комментариев к оригинальной статье.


    Рекомендую, кстати, также почитать оригинальное обсуждение по ссылке. Там автор статьи решительно выступает против введения let-statements.

  • Как мы спасали код-ревью
    0

    Яндекс ≠ Яндекс.Деньги.


    Сомневаюсь, что в Яндексе ещё кто-то пользуется Jira, там есть отличный внутренний багтрекер, рядом с которым Jira несколько лет назад выглядела мамонтом (по скорости работы, интерфейсу, удобству и отказоустойчивости).


    Ну и наверняка Император уже навёл порядок и унифицировал код-ревью почти везде.

  • Как я нашел пасхалку в защите Android и не получил работу в Google
    +1

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


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

  • Как я нашел пасхалку в защите Android и не получил работу в Google
    +4

    Для большинства инженеров собеседования — это обыденная обязанность. Они отвлекают от работы, вынуждают тебя быть пунктуальным, после них нужно потратить кучу на написание фидбека, даже если кандидат очень слабый. Мало кто в здравом уме не будет тратить столько времени и ресурсов, чтобы потешить самолюбие.


    далеко не высокими зарплатами

    Зависит от региона, но в целом зарплаты в гугле очень хорошие.


    ни топикстартеру, ни мне никакого «детального фидбека» не предоставлялось

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

  • Как я пишу конспекты по математике на LaTeX в Vim
    +2
    Я на лекциях по вышке не всегда успевал от руки конспектировать.

    Средний человек пишет от руки со скоростью 13 слов в минуту.
    Средняя скорость при слепой печати — 40-60 слов в минуту. (источник)


    Я печатаю не очень быстро — 60-90 слов в минуту (зависит от того, что печатаю). Я пробовал конспектировать лекции по топологии в университете в Emacs + рисовал картинки от руки отдельно (их потом нужно было сканировать и подставлять в документ руками, не очень удобно).


    Если при записи от руки я всё время отставал от лектора, то при наборе на клавиатуре мне приходилось постоянно ждать лектора, даже без всяких продвинутых макросов. К тому же не приходится постоянно переключать зрение между документом и доской.
    За это приходилось платить пост-обработкой документа для расстановки картинок.

  • Как я нашел пасхалку в защите Android и не получил работу в Google
    0

    Не, мне и в Цюрихе хорошо. Проект у меня вполне себе интересный, грех жаловаться.
    Чтобы стать богатым, достаточно запромоутиться до L7.

  • Как я нашел пасхалку в защите Android и не получил работу в Google
    +2
    единый тулинг для мониторинга, пуша в прод и прочее.

    Нет, тулинга в всегда как минимум два — один deprecated, а другой красивый, но пока толком не работает, причём вам нужно срочно на него переехать.
    Ну и для пуша в прод вариантов гораздо больше, чем 2.

  • Как я нашел пасхалку в защите Android и не получил работу в Google
    +1
    Они выкупили стартапчик

    Есть такая полу-шутка, что единственный способ заниматься чем-то действительно интересным в Гугле — пилить интересный стартап, который потом купит Гугл.

  • Как я нашел пасхалку в защите Android и не получил работу в Google
    +6

    Оптимизации — вещь полезная, но их надо уметь преподносить.


    Ключевая сложность с промо — нужно скрупулёзно собирать метрики и доказывать свою полезность, чтобы твоему менеджеру было что показать комитету, который ни про тебя, ни про твои проекты вообще ничего не знает. Чтобы сделать что-то для промо, нужно в 3 раза больше времени, чем просто это сделать.


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

  • Как моя жизнь превратилась в книгу Кафки
    0
    Удобный git svn

    Я нигде не называл его удобным. Я один раз его пробовал использовать на одной и предыдущих работ, и так не мог дождаться завершения загрузки репозитория всего с несколькими десятками тысяч коммитов (через много часов я просто прервал процесс). Просто если ну очень нужно читать и править локальную историю — выход есть.


    Использовать голый git с центральным репозиторием и trunk-based подходом, когда в команде активно работает ~100 инженеров — очень сомнительное удовольствие. Для небольших команд это ещё более-менее работает, для больших уже нужны какие-то мёрж-боты.


    К слову, одна из киллер-фич Git, которых очень не хватает в SVN — index. Тем забавнее, что большинство плагинов пытаются её спрятать, по пути создавая кучу проблем.

  • Как моя жизнь превратилась в книгу Кафки
    0
    ничего и не остается.

    Во-первых, он гораздо проще в освоении.
    Во-вторых, в нём есть удобные и понятные порядковые номера ревизий.


    Я лично всегда и везде для личных проектов использую git, мне просто не нравится дихотомия SVN — устаревшее и плохое, git — новое и хорошее. Это разные точки в пространстве возможных решений.


    Если вам ну очень хочется работать в оффлайне, git svn в помощь.

  • Как моя жизнь превратилась в книгу Кафки
    +5
    случайно угодила в команию, где всё ещё пользовались SVN

    А что плохого в использовании SVN? Яндекс, скорее всего, до сих пор много использует SVN, т.к. SVN хорошо умеет partial checkouts (актуально для огромных кодовых баз). Я работаю в компании, где система контроля версий ходит и крякает как Perforce начала двухтысячных, и не испытываю с этим никаких проблем (благо, добрые люди написали плагин для Emacs, который работает почти как magit).


    Вот если бы компания использовала SCCS/RCS/CVS или, упаси боже, MS Visual SourceSafe, вот тут, наверное, можно было бы посочувствовать.

  • Монорепозитории: пожалуйста не надо
    +1
    Интересное начинается когда добираешься до 3p кода

    Ну вообще говоря, c 3p не так уж всё и плохо. Как всегда с монорепами, это — проблема тулинга. Написаны инструменты для импорта сторонних зависимостей из разных источников и синхронизации с открытыми репозиториями. Очень многие популярные вещи уже в third_party.


    Зато получаем


    • codesearch по всем зависимостям
    • очередной leftpad вам ничего не сломает
    • вместо двух тысяч копий leftpad у вас будет ровно одна
    • версии всех зависимостей всегда консистентные (особенно актуально в каком-нибудь Haskell)
  • Монорепозитории: пожалуйста не надо
    +3

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


    В полирепе так же просто сделать неявную зависимость между модулями: предположения о формате данных, структуре хранилища и т.п. Я точно также могу утверждать, что полирепы поощрают вас, к примеру, хранить фронт-енд и бэк-енд в разных репозиториях, и протокол между ними не генерить из общего IDL по соседству, а писать руками дважды (счастливой отладки при апдейте схемы).
    И вот такое я как раз видел сплошь и рядом.

  • Монорепозитории: пожалуйста не надо
    +1
    А потом без пол-литры не разберешь, а где же у этих систем границы. Где собственно зоны отвественности и все такое…

    Это самый бредовый аргумент из всей статьи. У нас у каждой большой системы есть свой каталог с OWNERS файлами, в которых написано, кто владеет кодом. В нормальном воркфлоу без аппрува этой команды ничего изменить в их коде не получится. Всегда понятно, где границы, и кто за что отвечает. Сервисы взаимодействуют друг с другом через посылку сообщений поверх gRPC. Сложно представить себе более ясные границы.


    Полирепы вас от плохого кода точно не спасут.

  • Монорепозитории: пожалуйста не надо
    +2
    40+ тысяч строк с git/npm/gulp/webpack на эту чудесную монорепу

    На какую чудесную монорепу? В чём заключался перевод? Просто переписали билд на bazel/pants/buck?


    Перевод проекта с системы сборки X на систему сборки Y, ∀ X, Y — это всегда много скучной, изматывающей, неблагодарной работы.


    Я переводил ~500.000 строк кода и двумя десятками приложений на Java с кастомной ANT-сборки на Gradle, утомился. При чём тут монорепы?

  • Монорепозитории: пожалуйста не надо
    +2

    Говорю следующее как разработчик, ежедневно использующий монорепу с миллиардами строк кода. Начать работать с этой монорепой было очень просто, реализовывать кросс-модульные фичи — это просто сказка, навигация по всему коду напрямую из codesearch — это божественно. Видимо, в вашей монорепе нет правильных инструментов.

  • Монорепозитории: пожалуйста не надо
    +1

    Когда в команде несколько десятков разработчиков, начинается гонка за коммит в head. В линуксе это работает благодаря организационной структуре: там изменения льются в апстрим по дереву доверия, и в каждом узле небольшое код-во разработчиков.

  • Монорепозитории: пожалуйста не надо
    +2

    Я работал с большими кодовыми базами с использованием обоих подходов.


    Монорепы — это на порядок более удобный и продуктивный подход (полирепы вспоминаю как страшный сон), если у компании есть ресурсы для настройки (а возможно, и написания с нуля) инструментов для работы с ними. Facebook и Google выкладывают много полезного для этого кода в открытый доступ (Kythe, Bazel, Hg-experimental), но инвестировать в инфраструктуру придётся много.


    Не выйдет просто взять и начать сваливать весь код в одну кучу.

  • Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать
    0
    Не, поймите, я сам иногда мечтаю об анонимных неявных тайпклассах в хаскеле.

    Наверное, вы хотите просто записи с Row Polymorphism.

  • Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать
    –2

    Программисты нужны не для того, чтобы хорошо знать «TypeScript», а чтобы уметь эффективно решать проблемы. Этот навык приходит исключительно с опытом и изучением фундаментальных наук (математика, логика, алгоритмы).


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


    Я изучил C# и .NET с разными областями применения (asp.net, wpf, xamarin), js/ts (react/redux, node) и убедил себя, что теперь-то могу действительно всё.

    Это что ли много?


    Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).
    http://norvig.com/21-days.html

    Я бы добавил к этому списку языки, которые обладают выразительной модульной системой (OCaml, Standard ML) и языки, которые помогают осознать соответствие Карри—Ховарда: Coq, Agda, Idris или F*.


    Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте» так не делают.

    А кого волнует, что там кто делает или не делает в «TypeScript»? Надо уметь обосновать выбор дизайна. Идиоматичность дизайна является одним из факторов (к примеру, в математике никто не будет обозначать целое число буквой большой буквой S), но если преимущества (простота в поддержке, эффективное использование ресурсов, лёгкость в отладке) «неидеоматичного» решения перевешивает недостатки, аргумент «так никто не делает» выглядит довольно нелепо.

  • Проблемы современной записи математических текстов
    0
    Вы забыли про правила вывода.

    Под "законами логики" я имел ввиду исчисление предикатов и логика высших порядков, о каких именно "правилах вывода" вы говорите? Мат. индукция? Это частный случай исчисления предикатов.

  • Проблемы современной записи математических текстов
    0
    А доказательства этих теорем — конечные последовательности правил

    Нет, правила — это логика + набор аксиом. Доказательства — это последовательные применения законов логики к аксиомам для получения требуемого результата.


    Только вот в современной математике док-ва стали настолько сложными, что проверить их абы кто не может, нужны другие супер-математики. И даже если всё проверили, не исключена вероятность, что где-нибудь ошибка сидит. Воеводский не от хорошей жизни гомотопической теорией типов занялся.


    Когда-нибудь всё везде будет строго доказываться на аналоге Coq, вот тогда ваш тезис будет совсем верным.

  • Проблемы современной записи математических текстов
    0
    В математике чтение учебника — это и есть выполнение упражнений

    Нет.


    Я прочитал много книжек по математике и программированию, и совершенно уверен, что просто чтение не работает, в голове не остаётся совершенно ничего.


    Кмк, лучше всего начинать сразу с задач, и читать учебник, чтобы понять в чём заключается проблема и как её решить.
    Недавно пробовал такой подход с топологией. Берёшь задачи-теоремы, которые нужно доказать, и читаешь ровно столько учебника, сколько нужно, чтобы всё доказать/решить.


    Вот тогда реально хорошо понимаешь материал.

  • Проблемы современной записи математических текстов
    0
    В математике ученые формулируют утверждения вида: "из последовательности символов А при помощи последовательного применения правил преобразования Х можно получить последовательность символов В".

    Это только в конструктивной математике. Вообще говоря, много утверждений вида "существует объект, обладающий свойством P" или, выражаясь вашими словами "как не крути правила X, последовательность B из A ты получить не сможешь" (обычно эти теоремы самые важные и сложные).


    Примеры:


    • У любого полинома n-степени с комплексными коэффициентами (n≥1) существует хотя бы один комплексный корень (ни слова про то, как его найти).
    • Для любого n ≥ 5 не существует формулы, которая бы выражала корни любого полинома степени n в радикалах.
    • Всякое n-мерное многообразие гомотопически эквивалентно n-мерной сфере тогда и только тогда, когда оно гомеоморфно ей (когда я наконец понял разницу между гомотопиями и гомеоморфизмами, мне это крышу снесло).
  • Проблемы современной записи математических текстов
    +4
    вообще, фихтенгольц — это простейшая книга по матану, где всё разжёвывается до мелочей и читателя просто закидывают разнообразными примерами, настолько приближенными к практике, насколько это возможно

    Подтверждаю. Я на втором курсе перечитывал этот учебник (начались диффуры, хотелось ещё раз подтянуть матчасть). Он читается как художественная литература. У меня до сих пор дома тома стоят, так и тянет ещё раз почитать.


    Но часть критики в статье я всё же считаю верной. Например, зачастую в учебниках не хватает бэкграунда, процесса становления. Математику в учебниках описывают от общего к частному, а ведь развивается она в обратном направлении: есть конкретные задачи, люди придумывают методы их решения, а потом потихоньку обобщают. Если показываешь сразу готовое комплекстное решение, понять его гораздо сложнее, потому что непонятно, как ко всему этому пришли.


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

  • Презумпция тупизны
    +1

    Что, Гриша, тоскуешь по Яндексу? О чём статья-то? Я ничего не понял.


    P.S. А, это ответ на другую статью, которая тоже ни о чём. Извини тогда. Как тебе Erlang после C++?

  • Идеала нет: как я искал язык программирования для себя
    0

    Добавлю также про сильно искажённые факты


    К слову, и Reason / Ocaml не поддерживают multi-core, для этого есть Lwt.

    Lwt не для multi-core, а для concurrent programming! Вот что написано в оригинальной статье:


    Native Reason/OCaml doesn’t have multi-core support yet, but for doing concurrent processes you can use Lwt, which is a promise-like library.

    От себя добавлю, что есть похожая библиотека Async, которой посвящена глава в Real World OCaml. Хотя Lwt гораздо более популярена, основные принципы одинаковы.

  • Как начать писать код на Lisp?
    +1
    Скобки здесь при том, что это синтаксический рудимент Лиспа

    Скобки — это не рудимент, это преимущество лиспа. Поначалу они действительно кажутся неудобными, но стоит лишь перестроиться и начать думать "сбалансированными выражениями" вместо символов и строк, работать с кодом становится гораздо удобнее, и современные плагины для работы с Lisp (paredit, lispy) сильно помогают. Они превращают редактор текста в редактор синтаксического дерева программы. Вот небольшое демо с демонстрацией базовых возможностей paredit.


    После работы с Lisp начинаешь думать по-другому и в других языках: я в основном пишу на C++ в Emacs, и работа со "сбалансированными выражениями" прочно засела в моём workflow.

  • Как начать писать код на Lisp?
    0
    зачем писать на LISP, и что писать на LISP?

    Common Lisp – очень неплохо спроектированный язык. Да, в стандарте есть несколько моментов, которые сейчас не особо актуальны, но в целом язык очень интересный. Честно говоря, я с трудом переношу языки с динамической типизацией (Python и JavaScript снятся мне в кошмарах), но на CL я бы с удовольствием попробовал написать проект.
    Для CL есть качественные компиляторы, в языке есть возможность указать типы, если хочется (да, аналог gradual typing был давным давно). Код, который генерит, к примеру, SBCL, на удивление быстр (я сабмитил решения для computer language benchmark game, мой код для SBCL иногда работает ощутимо шустрее, чем мой код для Haskell, оба решения были в топе).


    Slime + Emacs – это приятная и мощная среда разработки, в которую вложено много человеко-лет труда. Её действительно иногда нетривиально настроить (нужно разобраться в терминологии, ASDF, системы, вот это всё). К примеру, компиляция совершенно не мешает разработке, ведь можно инкрементально компилировать код по одной функции за раз. При этом можно попросить компилятор показать ассемблерный код любой функции и посмотреть, как добавление аннотаций типов влияет на код, производимый компилятором.


    Ну и если в проекте нужна генерация кода, CL тут просто вне конкуренции.


    Единственное, что я бы не стал писать на CL – мелкие утилиты командной строки. Модель исполнения с тяжёлым долго-живущим образом не особо к этому располагает.


    К слову, у языка довольно много активных пользователей.  Например, бэкэнд ITA (ныне Google Flights) в значительной степени написан на CL.

  • Чего из Rust мне не хватает в C
    +1
    а что с mangling'ом?

    Посмотрел исходники. Никакой магии там нет, честно руками конвертируют плюсовые типы в питоньи и обратно, а для методов скриптом генерятся питоньи обёртки, которые кастят питоньи типы обратно в плюсовые и вызывают плюсовые функции. Поскольку питоний модуль компилируется плюсовым компилятором, проблема манглинга решена.

  • Чего из Rust мне не хватает в C
    +3
    Там почти нет темплейтов в API, поэтому манглинга нет.

    В С++ манглится всё, что не extern "C", независимо от наличия шаблонов.

  • Верифицированный QuickSort на Agda
    0

    Кстати, вставку символов по именам в TeX можно получить в любом моде Emacs через
    M-x set-input-method TeX

  • Чего из Rust мне не хватает в C
    0
    К Ruby — тривиальная задача, если использовать Helix.

    Это не означает, что Rust какой-то особенный. Для C++ тоже давно существуют аналоги: CLIF и SWIG.

  • Чего из Rust мне не хватает в C
    0

    Ну так а чем тогда растовый FFI сильно проще плюсового?

  • Чего из Rust мне не хватает в C
    0
    Вот тут пример небольшой есть

    Там владение объекта не передаётся в сторонний код. Сторонний код видит только указатель на объект, создаваемый и уничтожаемый в rust. Если стороннему коду нужно создавать и уничтожать экземпляры RustObject, нужно написать функции-обёртки для конструктора и деструктора. Один-в-один как в C++.

  • Чего из Rust мне не хватает в C
    +3

    Попрошу минусующих показать, как вызвать из C rust-функцию, возвращающую Result<Resource, Error> без написания специальных сишных обёрток. C++ исключения — это проблема, но как вы убеждаетесь, что panic! не прилетит из глубин сторонней библиотеки, которой вы пользуетесь? Может, так? Чем это отличается от catch(...)?


    Я ничего не имею против Rust, мне просто непонятно, как принципиальные семантические проблемы могут решиться сами собой при смене языка на аналогичный.

  • Чего из Rust мне не хватает в C
    +1
    Код возврата это просто Union, проблем с ним нет.

    Что значит "проблем с ним нет"? Обёртки для си всё равно писать надо. Что если в этом юнионе объекты с деструкторами лежат? Если нужно писать обёртки, то и в плюсах можно написать catch(...) и конвертировать исключения в коды возврата.

  • Чего из Rust мне не хватает в C
    0
    А что с классами из с++ делать?

    А что делать с RAII-структурами в Rust?


    И что делать с исключениями с++ вобще не понятно

    Ловить вcё в сишных обёртках и конвертировать в коды возврата. С растовыми статусами этого не придётся делать?