Ещё бы сделали наконец поддержку клонирования отдельных файлов (reflinks) и было совсем хорошо. Это единственное, что мешает нам использовать ZFS в production. Тикету 9 лет исполнилось уже, в третий класс пошёл.
Расскажите, пожалуйста, как вы на ней набираете по-русски?
Какая-то специальная раскладка?
Нет, использую стандартную раскладку. Требуется некоторое время, чтобы привыкнуть к новому положению символов, в том числе и русских, но это верно для любой клавиатуры нестандартной формы. В связи с работой из дома сейчас в основном использую KINESIS Advantage 2, там аналогичная ситуация.
Ага. От беглого осмотра синтаксиса сразу впечатывается в мозг вся Typeclassopedia и семантика GHC Runtime, начинаешь ориентироваться в сотнях расширений GHC и не задумываясь писать Хаскель-код который не тормозит и не течёт мемликами.
Idris — это совсем другой подход к программированию вообще просто.
Другой подход именно к процессу набора кода. Процесс дизайна программ не сильно меняется.
В типах, как таковых, никакого смысла нет, а зависимые типы первого класса — это прямо глоток свежего воздуха в душном мире CS.
У зависимых типов, конечно, много приятных применений (самый близкий мне пример, пожалуй, — схемы бд).
По мне так type inference + pure functions + ADTs + pattern matching + type classes дают 80% профита от ФП в принципе, и дальнейшее усложнение типов — diminishing returns, хоть и не лишено смысла.
И пока вы инкрементально пишете код, компилятор вам выводит по типам, что тут может появиться, что — нет, и во многих случаях, получается так, что пишет код за вас.
Пока проект чуть-чуть не подрастёт, и тогда ответы компилятора начинают занимать несколько секунд, а не миллисекунд...
Тот факт, что я начал по настоящему разбраться с докером только в этом году — делает меня плохим разработчиком.
Очень странная логика. Мне лично докер никогда не нужен был, я вряд ли будет нужен в ближайшее время. Почему знание докера вдруг становится критерием хорошего разработчика? Мне нравится работать с людьми, которые быстро разбираются в чём угодно и создают красивые понятные дизайны, а не знают все детали всех технологий.
Я сказал именно то, что сказал. Валидация АСТ дерева должна происходить на лету.
Почему именно должна? Я считаю, что у разных людей разные подходы к написанию кода, и это нормально.
Меня вот, например, люто раздражает задержка (latency). Я зачастую согласен отказаться от автокомплита, если это поможет сделать редактор более отзывчивым.
Мне вот, например, не нравится интерактивная подсветка ошибок. Я люблю написать несколько страниц интерфейсов и кода, написать АПИ-комментарии и инварианты, набросать реализацию, и только когда в голове всё сложилось, я запускаю компилятор и перехожу в другой режим работы: от креатива в механическое исправление мелких ошибок.
Если вам больше подходит какой-то способ работы, это не значит, что он всем лучше подходит.
Понимание уже написанного кода — это тоже другой режим работа мозга. Для этого важна быстрая навигация, и ctags/LANGUAGE-tags/codesearch вполне неплохо с этим справляются.
На некоторых языках очень сложно писать без IDE, в основном из-за того, что там доминируют порочные практики. К примеру, в Java принято разбивать проект на малюсенькие файлы, один класс — один файл. Это делает понимание структуры и навигацию настолько непосильным делом, что без специальных инструментов становится не обойтись. Ответ на вопрос "где происходит X" может занять пару часов, даже с IntelliJ IDEA.
Поэтому мне гораздо легче понимать проекты на C, чем на Java. Зачастую ответить на вопрос "где происходит X" в коде PostgreSQL или Redis или Emacs, который ты видишь первый раз, гораздо проще без всяких IDE, чем в Java-махине, над которой ты работаешь уже как 2 года.
Знаете ли Вы, что говорил Кельвин на старости лет?
Кельвин до конца жизни считал, что Солнце – это большой кусок угля, который скоро сгорит, и очень гордился своими расчётами возраста земли.
Он не хотел серьёзно рассматривать данные, противоречащие его мировоззрению. Никого не напоминает?
Simon Peyton Jones, мой личный герой, пишет код в обычном Emacs. Аналогично поступают Andrei Alexandrescu, Richard Stallman, Donald Knuth, etc.
Я лично знаю очень талантливых и продуктивных разработчиков, которые пишут код в обычном Vim без LSP (для многих языков никакого LS и нету вовсе).
Я не против IDE. Я против предубеждений и громких, необоснованных высказываний.
Вы считаете IDE абсолютно незаменимым инструментом для вашей продуктивности? Отлично, пользуйтесь на здоровье. Никто не будет сомневаться в вашей профпригодности на основании этого факта.
Использование простых инструментов само по себе также не сделает никого хорошим программистом (во всяком случае, никаких данных, подтверждающих это, у меня нет). Я не думаю, что тут в принципе есть какая-то корреляция.
заросли догматизмом
Мне кажется, в своём глазу бревно сложнее увидеть.
но я не нашёл книги, которая подробно рассказывает о различных представлениях кода, удобных для оптимизации (CPS, SSA), учит переводить в них свой код и содержит в себе каталог основных оптимизационных приёмов
Я занят заполнением налоговой декларации! Осталось всего 3 дня до сдачи.
Коротко (об окрестностях Цюриха):
Транспорт отличный. Поезда удобные, приходят вовремя. С освоением транспортной сети и тарифной сетки было поначалу трудно, но на самом деле всё очень логично. Сеть настолько удобна, что многие живут в 15-30 минутах езды за пределами Цюриха: там жильё дешевле и жизнь спокойнее (я живу в небольшом городке рядом с озером с видом на горы, время в пути до офиса — 45 минут, можно работать 30 минут из поезда). Если детей нет, то от машины толку мало. Парковку, как правило, найти очень сложно, и стоит она недёшево.
Отдых: когда тепло — хайкинг и купание, зимой — лыжи/сноуборд. Осенью можно посетить фермы и сыроварни, посмотреть как скот с гор сгоняют (Alpabfahrt). Во всех кинотеатрах крутят фильмы на английском с субтитрами. Зимой катки открытые работают. До красивых европейских городов обычно можно добраться довольно быстро (Париж — скоростной поезд доезжает за 4 часа, Вена — поездом часов 6, самолётом часа 2, Инсбрук — около 4 часов поезда, Мюнхен или Neuschwanstein — 4 часа на машине).
Про школы я пока мало знаю. Посещение обязательное, всё очень строго (нельзя просто так взять и забрать ребёнка в отпуск на пару недель). Сама программа в среднем довольно слабая по нашим меркам (также зависит от региона). Есть русские школы (там один день в неделю вроде посещение, по субботам вроде).
По поводу языка: в Швейцарии "обычный" немецкий (Hochdeutsch) используется в основном в документах, но местные могут на нём говорить (хоть и не особо рады, особенно с немцами). В каждом регионе используется свой диалект (Цюрихский, Бернский, Базельский, и т.д.). Без знания хотя бы Hochdeutsch сложно, хотя некоторые умудряются выживать только с английским. Если знаешь Hochdeutsch, диалект выучить не сложно (это другой язык со своей грамматикой, но многие слова очень похожи). Впрочем, я до сих пор понимаю от силы половину слов в предложениях моего соседа-швейцарца.
Про зарплаты лучше на каком-нибудь Glassdoor смотреть. В Цюрихском Google поначалу вполне можно получать 150K CHF в год (без учёта бонусов и акций), на что вполне можно комфортно жить семье из 3 человек. В целом по индустрии ЗП вроде бы ощутимо ниже (я думаю около 80-120K в год).
Ребёнок не оставляет свободного времени на всякую ерунду, поэтому к работе начинаешь относиться совсем по-другому. Я после рождения ребёнка уволился с хорошей, но не очень интересной работы чтобы заниматься тем, что действительно по душе. Просадки в "перформансе" не заметил: чем меньше у тебя ресурсов (времени), тем более рационально ты их используешь. Я стал меньше страдать фигнёй и лучше, глубже работать.
К слову, у SPJ не менее шести детей. Мы все тут перформим гораздо хуже него.
Также горячо рекомендую книгу Deep Work, она действительно изменила мою жизнь к лучшему.
Полгода назад купил Planck EZ и не нарадуюсь. Отличное решение для убогой клавиатуры на Macbook Pro:
Вес примерно 250г, ношу всегда с собой в сумке. После пары недель привыкания возвращаться на staggered layout совершенно не хочется.
синтаксис в третьей скале куда более читаемый имхо:
Да, это выглядит лучше. В Scala 2.10 все операции реализовывались через переопределение методов трейта, что выглядело очень громоздко и требовало повторения сигнатур по 3 раза. И всё же Haskell заметно проще, компактнее и приятнее глазу:
class Functor f where
map :: f a -> (a -> b) -> f b
data Option a = None | Some a
instance Functor Option where
map None _ = None
map (Some x) f = Some (f x)
main = putStrLn "Hello" >> print (Some 2 `map` (*2))
В какой-то момент я осознал, что при написанию кода на Scala я на самом деле транслирую свои Haskell идеи в синтаксис Scala. Почему бы не писать сразу на Haskell?
Мне раньше нравилась Scala. Бросил и возвращаться не хочу:
Bloat. Современный софт ужасен в этом плане, и Scala — явный тому пример. Я как-то чинил багу в парсере разметки в Lift Framework. Парсер жил в одном файле строк на 600. Компиляция этого файла занимала пару минут и порождала более 600 класс-файлов, т.е. более одного класса на строчку.
Очень тормозной компилятор, даже с fsc.
Побочные эффекты в неожиданных местах. Многие библиотеки выглядят чисто функциональными, но не являются потоко-безопасными, к примеру. Referential Transparency? Забудте.
Громоздкий синтаксис. Чтобы написать банальный Maybe нужно непростительно много букв и неочевидных фич языка.
Хороший язык должен снижать сложность, Scala эту сложность только преумножает.
Думаю, это состояние знакомо многим и не зависит от языка.
Пару недель назад я собеседовал мэйнтейнера GHC, который устал от Haskell и хочет поработать с чем-нибудь другим.
Мне тоже стало не особо интересно следить за нововведениями в языках. Как правило, в таких новостях нет нечего кардинально нового: всё это было изобретено десятилетия назад. Я вообще люблю изучать старые добрые языки вроде Common Lisp, Prolog или APL, вот уж где были инновации.
От Haskell я тоже порядком устал. "Знать" Haskell становится всё сложнее и сложнее, в GHC льётся нескончаемый поток плохо документированных, несогласующихся расширений.
С каждым годом я всё больше и больше ценю старый добрый застывший StandardML.
С прошлого июля я пишу на Rust full-time, скучаю по C++. Мало что интересует меня меньше, чем релиз-ноты новых версий rustc. Перечитываю "The D Programming Language", думаю написать что-нибудь для души на D.
Мне интересно проектировать и реализовывать интересные, полезные информационные системы. Представлять потоки данных и как они трансформируются, и переносить мысленные образы в исполняемые файлы. А язык с каждом годом играет всё меньшую и меньшую роль.
Соответственно вариант без промежуточного списка с одним только состоянием
Я почти уверен, что корректного решения с такими свойствами (обработка потока с O(1) дополнительной памяти) не существует (Контр-пример может выглядеть как длинная лестница вроде [n, n-1..0] ++ [x]. Как-то нужно впихнуть в O(1) все возможные исходы для всех возможных лестниц как функцию от x).
Он не работает для стакана у которого последняя левая стенка выше правой
Какой смысл приводить решение, которое не работает в общем случае?
Ещё бы сделали наконец поддержку клонирования отдельных файлов (reflinks) и было совсем хорошо. Это единственное, что мешает нам использовать ZFS в production. Тикету 9 лет исполнилось уже, в третий класс пошёл.
Я не совсем понимаю термин "переезжают". Они точно также "переезжают" как символы "[" (отвечающий за "х" в русской раскладке), "]" ("ъ") "'" ("э").
Т.е. чтобы набрать "эхъ", я переключаюсь в русскую раскладку и нажимаю те же кнопки, что выдают "'[]" в QWERTY, т.е. "' Raise + { Raise + }"
Нет, использую стандартную раскладку. Требуется некоторое время, чтобы привыкнуть к новому положению символов, в том числе и русских, но это верно для любой клавиатуры нестандартной формы. В связи с работой из дома сейчас в основном использую KINESIS Advantage 2, там аналогичная ситуация.
Ну нет, синтаксис в Idris гораздо проще же. Сам Брэди об этом говорит (например, тут https://corecursive.com/006-type-driven-development-and-idris-with-edwin-brady/).
Haskell большой, сложный и постоянно расширяется. Зависимые типы делают язык более простым и однородным.
Ага. От беглого осмотра синтаксиса сразу впечатывается в мозг вся Typeclassopedia и семантика GHC Runtime, начинаешь ориентироваться в сотнях расширений GHC и не задумываясь писать Хаскель-код который не тормозит и не течёт мемликами.
Другой подход именно к процессу набора кода. Процесс дизайна программ не сильно меняется.
У зависимых типов, конечно, много приятных применений (самый близкий мне пример, пожалуй, — схемы бд).
По мне так type inference + pure functions + ADTs + pattern matching + type classes дают 80% профита от ФП в принципе, и дальнейшее усложнение типов — diminishing returns, хоть и не лишено смысла.
Пока проект чуть-чуть не подрастёт, и тогда ответы компилятора начинают занимать несколько секунд, а не миллисекунд...
+100500
Использовать языки вроде Coq без какого-нибудь Proof General — за пределами человеческих возможностей, как мне кажется.
Очень странная логика. Мне лично докер никогда не нужен был, я вряд ли будет нужен в ближайшее время. Почему знание докера вдруг становится критерием хорошего разработчика? Мне нравится работать с людьми, которые быстро разбираются в чём угодно и создают красивые понятные дизайны, а не знают все детали всех технологий.
Почему именно должна? Я считаю, что у разных людей разные подходы к написанию кода, и это нормально.
Меня вот, например, люто раздражает задержка (latency). Я зачастую согласен отказаться от автокомплита, если это поможет сделать редактор более отзывчивым.
Мне вот, например, не нравится интерактивная подсветка ошибок. Я люблю написать несколько страниц интерфейсов и кода, написать АПИ-комментарии и инварианты, набросать реализацию, и только когда в голове всё сложилось, я запускаю компилятор и перехожу в другой режим работы: от креатива в механическое исправление мелких ошибок.
Если вам больше подходит какой-то способ работы, это не значит, что он всем лучше подходит.
Понимание уже написанного кода — это тоже другой режим работа мозга. Для этого важна быстрая навигация, и ctags/LANGUAGE-tags/codesearch вполне неплохо с этим справляются.
На некоторых языках очень сложно писать без IDE, в основном из-за того, что там доминируют порочные практики. К примеру, в Java принято разбивать проект на малюсенькие файлы, один класс — один файл. Это делает понимание структуры и навигацию настолько непосильным делом, что без специальных инструментов становится не обойтись. Ответ на вопрос "где происходит X" может занять пару часов, даже с IntelliJ IDEA.
Поэтому мне гораздо легче понимать проекты на C, чем на Java. Зачастую ответить на вопрос "где происходит X" в коде PostgreSQL или Redis или Emacs, который ты видишь первый раз, гораздо проще без всяких IDE, чем в Java-махине, над которой ты работаешь уже как 2 года.
Кельвин до конца жизни считал, что Солнце – это большой кусок угля, который скоро сгорит, и очень гордился своими расчётами возраста земли.
Он не хотел серьёзно рассматривать данные, противоречащие его мировоззрению. Никого не напоминает?
Это очень сильное и безосновательное утверждение. Множество специалистов высшего уровня пользуются очень простыми инструментами разработки. Примеры:
Я лично знаю очень талантливых и продуктивных разработчиков, которые пишут код в обычном Vim без LSP (для многих языков никакого LS и нету вовсе).
Я не против IDE. Я против предубеждений и громких, необоснованных высказываний.
Вы считаете IDE абсолютно незаменимым инструментом для вашей продуктивности? Отлично, пользуйтесь на здоровье. Никто не будет сомневаться в вашей профпригодности на основании этого факта.
Использование простых инструментов само по себе также не сделает никого хорошим программистом (во всяком случае, никаких данных, подтверждающих это, у меня нет). Я не думаю, что тут в принципе есть какая-то корреляция.
Мне кажется, в своём глазу бревно сложнее увидеть.
M-x projectile-compile-project
Я занят заполнением налоговой декларации! Осталось всего 3 дня до сдачи.
Коротко (об окрестностях Цюриха):
Транспорт отличный. Поезда удобные, приходят вовремя. С освоением транспортной сети и тарифной сетки было поначалу трудно, но на самом деле всё очень логично. Сеть настолько удобна, что многие живут в 15-30 минутах езды за пределами Цюриха: там жильё дешевле и жизнь спокойнее (я живу в небольшом городке рядом с озером с видом на горы, время в пути до офиса — 45 минут, можно работать 30 минут из поезда). Если детей нет, то от машины толку мало. Парковку, как правило, найти очень сложно, и стоит она недёшево.
Отдых: когда тепло — хайкинг и купание, зимой — лыжи/сноуборд. Осенью можно посетить фермы и сыроварни, посмотреть как скот с гор сгоняют (Alpabfahrt). Во всех кинотеатрах крутят фильмы на английском с субтитрами. Зимой катки открытые работают. До красивых европейских городов обычно можно добраться довольно быстро (Париж — скоростной поезд доезжает за 4 часа, Вена — поездом часов 6, самолётом часа 2, Инсбрук — около 4 часов поезда, Мюнхен или Neuschwanstein — 4 часа на машине).
Про школы я пока мало знаю. Посещение обязательное, всё очень строго (нельзя просто так взять и забрать ребёнка в отпуск на пару недель). Сама программа в среднем довольно слабая по нашим меркам (также зависит от региона). Есть русские школы (там один день в неделю вроде посещение, по субботам вроде).
По поводу языка: в Швейцарии "обычный" немецкий (Hochdeutsch) используется в основном в документах, но местные могут на нём говорить (хоть и не особо рады, особенно с немцами). В каждом регионе используется свой диалект (Цюрихский, Бернский, Базельский, и т.д.). Без знания хотя бы Hochdeutsch сложно, хотя некоторые умудряются выживать только с английским. Если знаешь Hochdeutsch, диалект выучить не сложно (это другой язык со своей грамматикой, но многие слова очень похожи). Впрочем, я до сих пор понимаю от силы половину слов в предложениях моего соседа-швейцарца.
Про зарплаты лучше на каком-нибудь Glassdoor смотреть. В Цюрихском Google поначалу вполне можно получать 150K CHF в год (без учёта бонусов и акций), на что вполне можно комфортно жить семье из 3 человек. В целом по индустрии ЗП вроде бы ощутимо ниже (я думаю около 80-120K в год).
Ребёнок не оставляет свободного времени на всякую ерунду, поэтому к работе начинаешь относиться совсем по-другому. Я после рождения ребёнка уволился с хорошей, но не очень интересной работы чтобы заниматься тем, что действительно по душе. Просадки в "перформансе" не заметил: чем меньше у тебя ресурсов (времени), тем более рационально ты их используешь. Я стал меньше страдать фигнёй и лучше, глубже работать.
К слову, у SPJ не менее шести детей. Мы все тут перформим гораздо хуже него.
Также горячо рекомендую книгу Deep Work, она действительно изменила мою жизнь к лучшему.
Кстати, принципам описанным в статье есть весьма полезные применения: https://www.thev.net/PaulLiu/invert-inversion.html
Полгода назад купил Planck EZ и не нарадуюсь. Отличное решение для убогой клавиатуры на Macbook Pro:
Вес примерно 250г, ношу всегда с собой в сумке. После пары недель привыкания возвращаться на staggered layout совершенно не хочется.
DFINITY, в команду разработчиков Motoko. Но товарищ вроде ушёл в Facebook.
https://osa1.net/posts/2020-01-22-no-small-syntax-extensions.html
Я в принципе стараюсь использовать минимум расширений, особенно синтаксических.
Последний раз я писал код на Scala в 2013 году.
Да, это выглядит лучше. В Scala 2.10 все операции реализовывались через переопределение методов трейта, что выглядело очень громоздко и требовало повторения сигнатур по 3 раза. И всё же Haskell заметно проще, компактнее и приятнее глазу:
В какой-то момент я осознал, что при написанию кода на Scala я на самом деле транслирую свои Haskell идеи в синтаксис Scala. Почему бы не писать сразу на Haskell?
Мне раньше нравилась Scala. Бросил и возвращаться не хочу:
Bloat. Современный софт ужасен в этом плане, и Scala — явный тому пример. Я как-то чинил багу в парсере разметки в Lift Framework. Парсер жил в одном файле строк на 600. Компиляция этого файла занимала пару минут и порождала более 600 класс-файлов, т.е. более одного класса на строчку.
Очень тормозной компилятор, даже с fsc.
Побочные эффекты в неожиданных местах. Многие библиотеки выглядят чисто функциональными, но не являются потоко-безопасными, к примеру. Referential Transparency? Забудте.
Громоздкий синтаксис. Чтобы написать банальный Maybe нужно непростительно много букв и неочевидных фич языка.
Хороший язык должен снижать сложность, Scala эту сложность только преумножает.
Думаю, это состояние знакомо многим и не зависит от языка.
Пару недель назад я собеседовал мэйнтейнера GHC, который устал от Haskell и хочет поработать с чем-нибудь другим.
Мне тоже стало не особо интересно следить за нововведениями в языках. Как правило, в таких новостях нет нечего кардинально нового: всё это было изобретено десятилетия назад. Я вообще люблю изучать старые добрые языки вроде Common Lisp, Prolog или APL, вот уж где были инновации.
От Haskell я тоже порядком устал. "Знать" Haskell становится всё сложнее и сложнее, в GHC льётся нескончаемый поток плохо документированных, несогласующихся расширений.
С каждым годом я всё больше и больше ценю старый добрый застывший StandardML.
С прошлого июля я пишу на Rust full-time, скучаю по C++. Мало что интересует меня меньше, чем релиз-ноты новых версий
rustc
. Перечитываю "The D Programming Language", думаю написать что-нибудь для души на D.Мне интересно проектировать и реализовывать интересные, полезные информационные системы. Представлять потоки данных и как они трансформируются, и переносить мысленные образы в исполняемые файлы. А язык с каждом годом играет всё меньшую и меньшую роль.
Я почти уверен, что корректного решения с такими свойствами (обработка потока с O(1) дополнительной памяти) не существует (Контр-пример может выглядеть как длинная лестница вроде [n, n-1..0] ++ [x]. Как-то нужно впихнуть в O(1) все возможные исходы для всех возможных лестниц как функцию от x).
Какой смысл приводить решение, которое не работает в общем случае?
Откуда взялся
log_2
? Если я правильно понял идею, то оно работает заO(MAX_VALUE * n)
. Если брать на вход целые произвольной точности, то вполне себе https://en.wikipedia.org/wiki/Pseudo-polynomial_time.С этим никто не спорит, я лишь утверждаю, что этот алгоритм не требует random-access.
Вообще говоря, случайный доступ тут не нужен, достаточно положить вход в
Data.Sequence
и обращаться только к голове и хвосту.