Как стать автором
Обновить
38
Карма
0
Рейтинг
Роман Кашицын @roman_kashitsyn

Пользователь

Вышел релиз OpenZFS 2.0, реализация ZFS для Linux и (теперь) для FreeBSD

Ещё бы сделали наконец поддержку клонирования отдельных файлов (reflinks) и было совсем хорошо. Это единственное, что мешает нам использовать ZFS в production. Тикету 9 лет исполнилось уже, в третий класс пошёл.

Обзор механической клавиатуры Vortex Core RGB

Я не совсем понимаю термин "переезжают". Они точно также "переезжают" как символы "[" (отвечающий за "х" в русской раскладке), "]" ("ъ") "'" ("э").


Т.е. чтобы набрать "эхъ", я переключаюсь в русскую раскладку и нажимаю те же кнопки, что выдают "'[]" в QWERTY, т.е. "' Raise + { Raise + }"

Обзор механической клавиатуры Vortex Core RGB

Расскажите, пожалуйста, как вы на ней набираете по-русски?
Какая-то специальная раскладка?

Нет, использую стандартную раскладку. Требуется некоторое время, чтобы привыкнуть к новому положению символов, в том числе и русских, но это верно для любой клавиатуры нестандартной формы. В связи с работой из дома сейчас в основном использую KINESIS Advantage 2, там аналогичная ситуация.

«Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить

В отличие от того же хаскеля — там синтаксис бегло просмотрел — и ты уже на коне.

Ну нет, синтаксис в Idris гораздо проще же. Сам Брэди об этом говорит (например, тут https://corecursive.com/006-type-driven-development-and-idris-with-edwin-brady/).
Haskell большой, сложный и постоянно расширяется. Зависимые типы делают язык более простым и однородным.


синтаксис бегло просмотрел — и ты уже на коне

Ага. От беглого осмотра синтаксиса сразу впечатывается в мозг вся Typeclassopedia и семантика GHC Runtime, начинаешь ориентироваться в сотнях расширений GHC и не задумываясь писать Хаскель-код который не тормозит и не течёт мемликами.


Idris — это совсем другой подход к программированию вообще просто.

Другой подход именно к процессу набора кода. Процесс дизайна программ не сильно меняется.


В типах, как таковых, никакого смысла нет, а зависимые типы первого класса — это прямо глоток свежего воздуха в душном мире CS.

У зависимых типов, конечно, много приятных применений (самый близкий мне пример, пожалуй, — схемы бд).


По мне так type inference + pure functions + ADTs + pattern matching + type classes дают 80% профита от ФП в принципе, и дальнейшее усложнение типов — diminishing returns, хоть и не лишено смысла.


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

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

«Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить

А вот идрис (да и агда), например, в блокноте просто потеряют 95% своего очарования

+100500


Использовать языки вроде Coq без какого-нибудь Proof General — за пределами человеческих возможностей, как мне кажется.

«Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить

Тот факт, что я начал по настоящему разбраться с докером только в этом году — делает меня плохим разработчиком.

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


Я сказал именно то, что сказал. Валидация АСТ дерева должна происходить на лету.

Почему именно должна? Я считаю, что у разных людей разные подходы к написанию кода, и это нормально.


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


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


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


Понимание уже написанного кода — это тоже другой режим работа мозга. Для этого важна быстрая навигация, и ctags/LANGUAGE-tags/codesearch вполне неплохо с этим справляются.


На некоторых языках очень сложно писать без IDE, в основном из-за того, что там доминируют порочные практики. К примеру, в Java принято разбивать проект на малюсенькие файлы, один класс — один файл. Это делает понимание структуры и навигацию настолько непосильным делом, что без специальных инструментов становится не обойтись. Ответ на вопрос "где происходит X" может занять пару часов, даже с IntelliJ IDEA.


Поэтому мне гораздо легче понимать проекты на C, чем на Java. Зачастую ответить на вопрос "где происходит X" в коде PostgreSQL или Redis или Emacs, который ты видишь первый раз, гораздо проще без всяких IDE, чем в Java-махине, над которой ты работаешь уже как 2 года.


Знаете ли Вы, что говорил Кельвин на старости лет?

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

«Docker уже умер» или все, что вы хотели узнать про Devops, но боялись спросить

Проблема в том, что они не отличные спецы.

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


  • Линус Торвальдс пишет код в https://github.com/torvalds/uemacs, очень простой текстовый редактор.
  • Walter Bright, создатель языка D, пишет код в https://github.com/DigitalMars/med.
  • Simon Peyton Jones, мой личный герой, пишет код в обычном Emacs. Аналогично поступают Andrei Alexandrescu, Richard Stallman, Donald Knuth, etc.

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


Я не против IDE. Я против предубеждений и громких, необоснованных высказываний.


Вы считаете IDE абсолютно незаменимым инструментом для вашей продуктивности? Отлично, пользуйтесь на здоровье. Никто не будет сомневаться в вашей профпригодности на основании этого факта.


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


заросли догматизмом

Мне кажется, в своём глазу бревно сложнее увидеть.


M-x projectile-compile-project

Мой топ IT книг из прошлого века, актуальных до сих пор

но я не нашёл книги, которая подробно рассказывает о различных представлениях кода, удобных для оптимизации (CPS, SSA), учит переводить в них свой код и содержит в себе каталог основных оптимизационных приёмов

  • CPS должен хорошо покрываться Compiling with Continuations. Я её пока не читал, но слышал много хорошего.
  • SSA упоминается и немного разбирается в Engineering: A Compiler, но я от их объяснения не в восторге.

Переезд IT-специалиста в Швейцарию: процесс релокации, стоимость жизни, полезные ссылки

Я занят заполнением налоговой декларации! Осталось всего 3 дня до сдачи.


Коротко (об окрестностях Цюриха):


  1. Транспорт отличный. Поезда удобные, приходят вовремя. С освоением транспортной сети и тарифной сетки было поначалу трудно, но на самом деле всё очень логично. Сеть настолько удобна, что многие живут в 15-30 минутах езды за пределами Цюриха: там жильё дешевле и жизнь спокойнее (я живу в небольшом городке рядом с озером с видом на горы, время в пути до офиса — 45 минут, можно работать 30 минут из поезда). Если детей нет, то от машины толку мало. Парковку, как правило, найти очень сложно, и стоит она недёшево.


  2. Отдых: когда тепло — хайкинг и купание, зимой — лыжи/сноуборд. Осенью можно посетить фермы и сыроварни, посмотреть как скот с гор сгоняют (Alpabfahrt). Во всех кинотеатрах крутят фильмы на английском с субтитрами. Зимой катки открытые работают. До красивых европейских городов обычно можно добраться довольно быстро (Париж — скоростной поезд доезжает за 4 часа, Вена — поездом часов 6, самолётом часа 2, Инсбрук — около 4 часов поезда, Мюнхен или Neuschwanstein — 4 часа на машине).


  3. Про школы я пока мало знаю. Посещение обязательное, всё очень строго (нельзя просто так взять и забрать ребёнка в отпуск на пару недель). Сама программа в среднем довольно слабая по нашим меркам (также зависит от региона). Есть русские школы (там один день в неделю вроде посещение, по субботам вроде).



По поводу языка: в Швейцарии "обычный" немецкий (Hochdeutsch) используется в основном в документах, но местные могут на нём говорить (хоть и не особо рады, особенно с немцами). В каждом регионе используется свой диалект (Цюрихский, Бернский, Базельский, и т.д.). Без знания хотя бы Hochdeutsch сложно, хотя некоторые умудряются выживать только с английским. Если знаешь Hochdeutsch, диалект выучить не сложно (это другой язык со своей грамматикой, но многие слова очень похожи). Впрочем, я до сих пор понимаю от силы половину слов в предложениях моего соседа-швейцарца.


Про зарплаты лучше на каком-нибудь Glassdoor смотреть. В Цюрихском Google поначалу вполне можно получать 150K CHF в год (без учёта бонусов и акций), на что вполне можно комфортно жить семье из 3 человек. В целом по индустрии ЗП вроде бы ощутимо ниже (я думаю около 80-120K в год).

Я посредственный разраб, плохой муж и ужасный отец — нет никакого баланса и выбора

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


К слову, у SPJ не менее шести детей. Мы все тут перформим гораздо хуже него.


Также горячо рекомендую книгу Deep Work, она действительно изменила мою жизнь к лучшему.

Кооперативные потоки с нуля в 33 строках на Хаскеле

Кстати, принципам описанным в статье есть весьма полезные применения: https://www.thev.net/PaulLiu/invert-inversion.html

Обзор механической клавиатуры Vortex Core RGB

Полгода назад купил Planck EZ и не нарадуюсь. Отличное решение для убогой клавиатуры на Macbook Pro:image
Вес примерно 250г, ношу всегда с собой в сумке. После пары недель привыкания возвращаться на staggered layout совершенно не хочется.

Пора на свалку

Хмм, интересно. А куда собеседовали?

DFINITY, в команду разработчиков Motoko. Но товарищ вроде ушёл в Facebook.


На QuantifiedConstraints не жаловались?

https://osa1.net/posts/2020-01-22-no-small-syntax-extensions.html


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

Пора на свалку

вы со скалой очень давно общались

Последний раз я писал код на Scala в 2013 году.


синтаксис в третьей скале куда более читаемый имхо:

Да, это выглядит лучше. В 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. Бросил и возвращаться не хочу:


  1. Bloat. Современный софт ужасен в этом плане, и Scala — явный тому пример. Я как-то чинил багу в парсере разметки в Lift Framework. Парсер жил в одном файле строк на 600. Компиляция этого файла занимала пару минут и порождала более 600 класс-файлов, т.е. более одного класса на строчку.


  2. Очень тормозной компилятор, даже с fsc.


  3. Побочные эффекты в неожиданных местах. Многие библиотеки выглядят чисто функциональными, но не являются потоко-безопасными, к примеру. Referential Transparency? Забудте.


  4. Громоздкий синтаксис. Чтобы написать банальный Maybe нужно непростительно много букв и неочевидных фич языка.



Хороший язык должен снижать сложность, Scala эту сложность только преумножает.

Пора на свалку

Думаю, это состояние знакомо многим и не зависит от языка.


Пару недель назад я собеседовал мэйнтейнера GHC, который устал от Haskell и хочет поработать с чем-нибудь другим.


Мне тоже стало не особо интересно следить за нововведениями в языках. Как правило, в таких новостях нет нечего кардинально нового: всё это было изобретено десятилетия назад. Я вообще люблю изучать старые добрые языки вроде Common Lisp, Prolog или APL, вот уж где были инновации.


От Haskell я тоже порядком устал. "Знать" Haskell становится всё сложнее и сложнее, в GHC льётся нескончаемый поток плохо документированных, несогласующихся расширений.
С каждым годом я всё больше и больше ценю старый добрый застывший StandardML.


С прошлого июля я пишу на Rust full-time, скучаю по C++. Мало что интересует меня меньше, чем релиз-ноты новых версий rustc. Перечитываю "The D Programming Language", думаю написать что-нибудь для души на D.


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

Сколько воды утекло? Решаем задачу лунной походкой на Haskell

Соответственно вариант без промежуточного списка с одним только состоянием

Я почти уверен, что корректного решения с такими свойствами (обработка потока с O(1) дополнительной памяти) не существует (Контр-пример может выглядеть как длинная лестница вроде [n, n-1..0] ++ [x]. Как-то нужно впихнуть в O(1) все возможные исходы для всех возможных лестниц как функцию от x).


Он не работает для стакана у которого последняя левая стенка выше правой

Какой смысл приводить решение, которое не работает в общем случае?

Сколько воды утекло? Решаем задачу лунной походкой на Haskell

Откуда взялся log_2? Если я правильно понял идею, то оно работает за O(MAX_VALUE * n). Если брать на вход целые произвольной точности, то вполне себе https://en.wikipedia.org/wiki/Pseudo-polynomial_time.

Сколько воды утекло? Решаем задачу лунной походкой на Haskell

чтобы превратить список в пальчиковое дерево, тоже придется его обойти

С этим никто не спорит, я лишь утверждаю, что этот алгоритм не требует random-access.

Сколько воды утекло? Решаем задачу лунной походкой на Haskell

Вообще говоря, случайный доступ тут не нужен, достаточно положить вход в Data.Sequence и обращаться только к голове и хвосту.

Информация

В рейтинге
5,844-й
Откуда
Zürich, Zürich, Швейцария
Дата рождения
Зарегистрирован
Активность