Pull to refresh
65
0
Дмитрий Стропалов @helions8

Инженер

Send message
Я не постулировал достаточность одного навыка преобразования выражений для освоения программирования.

Я не говорил только лишь про навык преобразований, а про математику в целом — «у Васи математический склад ума, математика дается ему легко». А с другой стороны вы очень категоричны, не находите? —
Сможет ли он вообще написать понятный другим людям код, если у него не сформирован идеал этой самой лаконичности? На мой взгляд — нет.
В первую очередь школьная алгебра и конкретный прием преобразования выражений, который отрабатывается в рамках этой дисциплины. Каким образом преобразование выражений принуждает вкручивать рекурсию на чистых функциях в программе по выводу в stdout?

Переменная в школьной математике и в программировании циклов на императивном языке совсем не одно и то же.
Не отрицая необходимость получения (и применения) фундаментальных знаний, идея статьи мне кажется неким переупрощением. Для большинства программирование является инженерной практикой, а значит огромное значение имеют стандарты, практики и многие-многие другие вещи. Когда зашла речь о сравнении упрощения выражений с рефакторингом, то первая моя мысль была «а тесты есть?». Я предпочту первую версию кода второй, лишь бы у первой были тесты и покрытие. Условный «гуманитарий» вполне способен (да и примеров таких я видел не один) кое-как писать REST-сервисы, выполняя требования заказчика. Про неспособность написать цикл — это уже что-то с обычной логикой не так у человека (да, математика это может поправить), обычно с циклами справлялись все мои одноклассники (~25 лет тому назад, правда). Ну и с другой стороны, если математика и алгебра, то какие циклы? — должна быть рекурсия на чистых функциях без мутабельности.

Ну и последнее. У меня в школе было программирование, именно программирование — циклы, сортировки, матрицы и прочее. Мне кажется, что этот предмет ввели как раз потому, что он учит детей связному алгоритмическому мышлению, показывая взаимосвязь всех действий, которые необходимо совершить для достижения результата. Далеко не все в моем классе, у кого было все хорошо с математикой, могли «перенести навык» на этот предмет. Не так все просто.
Вопрос, мне кажется, не в задачках – они бывают разные, не только на алгоритмы. Вопрос в том, что собеседование зачастую не отбирает кандидатов, реально необходимых требуемой позиции. Нанимающая сторона зачастую не знает, как отобрать нужных им людей – мне кажется, что именно поэтому возникают негативные ощущения от собеседований. Мне очень понравилось мое же недавнее собеседование в большой банк, которое я не прошел, но было сразу понятно 1) кто им конкретно нужен 2) чем они занимаются 3) почему ни я им, ни они мне не подходят. А вот когда мелкий «стартап» начинает устраивать Google-style interview, говоря, что раз вы с задачками справитесь, то и с остальным точно справитесь, то вот тут уже возникают вопросы. За прошлый год я провел 50+ собеседований, как интервьюер, и для меня самой важной задачей было выяснить 1) проверка минимально необходимого нам уровня (ну должен он знать про хеш-таблицы) 2) границы опыта 3) хотел бы я с таким человеком работать 4) если кандидат нормальный, то дать задачку, чтобы порассуждать. Процесс постоянно надо менять и подстраивать, нужны итерации… Хороший найм и проведение собеседований — это сложно и утомительно.
Всё, что я вынес за годы практики и разного вида «у нас тут свой аджайл» сводится буквально к одному – хорошей команде при адекватном менеджменте аджайл (плюс другие фреймворки, позволяющие сделать процесс разработки и доставки управляемым) поможет стать еще лучше, остальным не поможет ничего.
Я нигде не говорил ни про лучше, ни про хуже. Я вам пытаюсь объяснить то, как оно работает в Erlang, и какие сущности могут быть сопоставлены с понятием «объект» в других языках, в данном случае Smalltalk, и как работает механизм взаимодействия «объектов». А вы пытаетесь просто один к одному переложить понятия из одной экосистемы на другую – это не работает. Процесс это не объект, код это не объект и не класс. Стейт мейлбокса процесса не связан со стейтом кода, выполняемого процессом.

Акторная модель — это математическая модель прежде всего, для которой Erlang стал очень удобной платформой, позволяя ее реализовать посредством встроенных в платформу и язык фич, одна из которых — процессы с мейлбоксами. Но если вы создали процесс, и в качестве кода ему передали функцию, которая делает ничего — это не актор. Актор это то, что 1) принимает сообщения 2) посылает сообщения 3) создает другие акторы. Это концепция, в конце-то концов.

Ориентация на concurrency и хорошая поддержка параллелизма — это фичи, а не принципиальная разница.


Это очень, очень спорное заявление. Весь пример Erlang'а показывает, как введение определенных примитивов параллелизма в язык очень сильно меняет подход разработки.

Еще раз, не пытайтесь «смапить» сущности из одной парадигмы на другую 1 к 1, это очень часто не работает.
Если заменить слова «процесс» и «PID процесса» на «объект»
Нельзя заменить, у них разная семантика. Процесс — единица обработки/выполнения, объект — совокупность состояния и поведения. В Erlang объектом будет совокупность процесс + код, притом, при соблюдении некоторых дополнительных условий. Еще раз подчеркну — сообщения отправляются процессу, а не «объекту». Общего состояния у процессов нет.

ориентироваться не на асинхронную, а синхронную обработку сообщений (делающую почтовый ящик ненужным ...)
Опять нельзя. В рамках Erlang'овой модели у вас нет никаких гарантий, что что именно в этот момент, когда вы отправили сообщение, код, исполняемый процессом, будет этих самых сообщений ожидать. Собственно, нет гарантий, что процессом вообще будет исполнятся такой код, а это значит, что при синхронной модели (если б она была в Erlang) любая мелкая ошибка приведет к остановке всего — например, отправили сообщение процессу, код которого сообщения не читает -> ждем ответа бесконечно. Синхронная модель накладывает обязательства на получателя – это то, почему в Smalltalk есть протоколы. Еще раз повторюсь — в асинхронной модели Erlang на получателя не накладывается вообще никаких обязательств, именно потому, что модель асинхронная.

Асинхронная модель эмулируется, это правда. Producer и consumer, связанные очередью – довольно известный шаблон. Синхронная «объектная» модель эмулируется в Erlang, но тоже посылкой сообщений, со всеми вытекающими последствиями. Замечу, что вызов обычных функции в Erlang — синхронный, если что, но это не про акторы и процессы. Любая эмуляция остается эмуляцией, из под которой протечет настоящая модель.

В целом, то, что вы написали, сводится к «если все переделать, то станет похоже».
Может быть она в том, что в Smalltalk-е для связывания сообщения с кодом используется имя сообщения (селектор), а в Erlang/Elixir паттерн-матчинг (если я правильно понимаю)?


Нет, это не так. Не уверен, что я смогу нормально объяснить, но всё же. В Erlang всё есть процессы (т.н. «грин-треды»), которые идентифицируются PID'ами. Каждый процесс исполняет какой-то произвольный код, с котором его запустили (я имею в виду, что никакого «типа» у процесса нет). Мейлбокс это свойство процесса, а не кода. Сообщения отправляются процессу (без деталей), зная его PID. Если код, выполняемый процессом не читает мейлбокс — значит, он его не читает. Всё. Можно долго отправлять такому процессу сообщения в одну сторону, пока мейлбокс не переполнится или процесс не закончится (выполнили весь код и вышли). Сообщения это просто данные. Можно читать, можно не читать. Можно читать и что-то делать, а можно читать и ничего не делать. Можно читать те, которые «нравятся», оставляя в очереди не подходящие. Отправка сообщений всегда односторонняя, у нее нет возвращаемого значения.

Я не очень много знаю о Smalltalk, но из того, что я прочитал — это вообще не похоже на Erlang.
Я бы точно так де ответил. В чём тогда был вопрос на самом деле?
В отличие от большей части технологического сектора, где близкие к монополиям игроки взяли контроль в свои руки – к примеру, Google в области поиска, и Facebook в соцсетях – обмен сообщениями ещё предстоит подмять под себя.

Будем надеяться, что этого никогда не случится.
С этим нельзя не согласиться, но вроде как и не противоречит тому, что я написал.
Не туда воюете, IMHO, и смешиваете понятия. Например, странно видеть такую «ФП-приватизацию» иммутабельности. Есть Erlang, который со всех сторон иммутабельный, но который же и один из самых ООП из всех ООП языков, просто не в понятиях «разложим код по классам и методам». ADT есть во вполне себе императивных Rust и TypeScript, функции высшего порядка вообще были много где десятилетиями в явном (JS тот же) или не явном виде (реализация интерфейса с единственным методом apply).

Может, стоит вообще начать с того, чтобы как-то выйти за пределы Blub-области в целом? Что ООП это не Borsch borsch = new Borsch(), а ФП это не только Клейсли ваш любимый, а просто стримы из Java, которые 1) содержат в разы меньше кода 2) ленивые 3) вы уже их используете, бояться поздно. А с ADT было бы удобно обрабатывать ошибки, не выхватывая NPE в щи.

Абстрактные аргументы про «скорость разработки» и «меньше ошибок» без хорошей статистики ничего не стоят, а «легкая композиция» вообще из области вкусовщины.
Вернулись к программированию на листике. Псевдокод да схемы. Из тех, кто пришел по этой системе, пока все выглядят хорошо, но их еще не много, дальше будет видно. Ну, и мы стали чуть прозаичнее и три месяца испытательного (100% зарплата, без унижений и ущемлений в правах) не простая формальность.
Там не надо ничего доказывать, там крупный аутсорс и 1500 людей в офисе. Там хадуп, и тут хадуп, там бигдата, и тут бигдата. Тест может быть составлен как угодно, но большинство даже не пройдет по ссылке в письме, отправив сразу в корзину. Мы платим чуть больше медианы рыночной, но не настолько сильно, чтобы это привлекало толпы. Большинство людей пойдет по пути наименьшего сопротивления.
Не всегда возможно применить, мы с этим столкнулись вот недавно. У нас нет DevRel, dev-бренда для разработчиков, мы такие же, как еще десятки фирм за углом. И кандидат делает несложный выбор — идет туда, где всё тож самое по описанию, но не заставляют тратить 2-3 часа на тестовое, т.е. не к нам. Мотивация простая — кто вы такие, я вас не знаю, а вы меня уже тестовое заставляете писать.
А почему exceptional talents должны хотеть работать в такой фирме, когда людьми затыкают дырки в проектах?
Да просто. Фирма хочет денег, нанимают тех, кто Java выговаривает, продают, а в фирме есть несколько нормальных специалистов, которые «пасут» всех остальных.
Это лучшая история пока что :)
В современном IT «продолжать сидеть» можно только по собственному желанию – при приложении минимальных усилий смена стека делается достаточно легко. ИМХО.
Я сейчас собеседую людей почти на потоке, и сталкиваюсь с немного обратной ситуацией. Мы напираем не на «сколько параметров у метода», а наоборот – на базовые вещи. Одна из задачек заключается в том, что нужно придумать («придумать»), как распределять данные по ключу в воображаемой key-value базе данных между шардами. Примерно половина не может узнать за этим хеш-таблицу. Ну хорошо, ты поставил себе 4 из 5 по Java, давай поговорим про GC и какие они есть, на что следует вопрос «вы тут часто GC тюните что ли?». Ну, тюним, приходится, в описании вакансии же написано, что у нас и нагрузка какая-никакая есть, и данных много (продуктовая кампания в сфере онлайн рекламы). Люди приходят писать Controller и считают, что этого достаточно. А еще зачастую не понимают, что тайтл зависит от кампании, и если тебя в атусорсе продают как сеньера, то это может значить, что просто продажники хорошо работают. С большим количеством кандидатов просто не о чем разговаривать, кроме как о количестве параметров у метода. Никого не хочу обидеть, но работа собеседующего часто заставляет разочаровываться в людях.

Information

Rating
Does not participate
Location
Донецк, Донецкая обл., Украина
Date of birth
Registered
Activity