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

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

Отправить сообщение

Ещё бы сделали наконец поддержку клонирования отдельных файлов (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 и не задумываясь писать Хаскель-код который не тормозит и не течёт мемликами.


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

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


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

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


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


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

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

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

+100500


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

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

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


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

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


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


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


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


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


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


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


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

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

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

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


  • Линус Торвальдс пишет код в 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

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

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

Я занят заполнением налоговой декларации! Осталось всего 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, она действительно изменила мою жизнь к лучшему.

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

Полгода назад купил 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.


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

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

Я почти уверен, что корректного решения с такими свойствами (обработка потока с 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 и обращаться только к голове и хвосту.

1
23 ...

Информация

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