Дядюшка Боб на днях написал:
"You should definitely learn GO, F#, Scala, Elixr, Rust, Elm, Kotlin, Swift, etc.
But first, learn Clojure."
Солидарен! Круче Лиспа в ФП ничего не было придумано, и уже не будет.
наблюдение: если из Лиспа удалить скобочки, то мы получим ML :)
"You should definitely learn GO, F#, Scala, Elixr, Rust, Elm, Kotlin, Swift, etc.
But first, learn Clojure."
Солидарен! Круче Лиспа в ФП ничего не было придумано, и уже не будет.
наблюдение: если из Лиспа удалить скобочки, то мы получим ML :)
Почему крупные компании используют Java, хотя на самом деле C# в плане системы типов например явно получше, чем Java?
Потому что Microsoft (как обычно) потребовалось много времени, чтобы понять, что языки должны быть кросс-платформными. Если бы они создали что-то вроде .net core на 10 лет раньше, Java, вероятно, уже вымерла бы.
Потому что Microsoft (как обычно) потребовалось много времени, чтобы понять, что языки должны быть кросс-платформными. Если бы они создали что-то вроде .net core на 10 лет раньше, Java, вероятно, уже вымерла бы.
"I just recently finished my job search and a lot of the startups I interviewed at were using typenoscript. So if you want to do frontend work at unicorn startups I suggest you get experience with that."
https://news.ycombinator.com/item?id=29140062
Сам по себе TS сегодня прежде всего для строчки в резюме must have (изучить хороший учебник + запилить пару проектов на гитхаб),
стратегически его Microsoft конечно достаточно сильно продавит,
только надо чётко помнить, что хоть в TS и статическая типизация, однако система типов в нём unsound, поэтому неприятных подводных камней остаётся множество, не особо меньше чем в JS.
https://news.ycombinator.com/item?id=29140062
Сам по себе TS сегодня прежде всего для строчки в резюме must have (изучить хороший учебник + запилить пару проектов на гитхаб),
стратегически его Microsoft конечно достаточно сильно продавит,
только надо чётко помнить, что хоть в TS и статическая типизация, однако система типов в нём unsound, поэтому неприятных подводных камней остаётся множество, не особо меньше чем в JS.
Микроволновка не включится, если у неё открыта дверца.
На автомобилях в бортовую систему сегодня закладываются режимы, которые не включат газ, если сперва не нажать на тормоз -- потому что огромное количество случаев, когда люди врезались в стены гаража, думая, что нажимают на тормоз, а не на газ.
Оказалось значительно эффективнее и проще встроить в систему "защиту от дурака" (poka-yoke по-японски и по-западному), нежели научить людей элементарно пользоваться (в реально опасных ситуациях!) двумя педалями так, как было задумано.
Передача кода другому разработчику на code review перед тем, как отправить его в продакшен -- это всё та же защита от дурака, которая всегда работает очень хорошо.
Вы можете (вы должны! :) добавлять "защиту от дурака" практически в любую систему, где потенциально ожидаются ошибки из-за сложности, или когда вы просто нервничаете, рассчитывая на надёжный результат. Почитайте про защитное программирование например (которое само по себе лишь слабенькая инженерная приляпка, не злоупотребляйте подобным, потому что такой навык тоже кривой и неверный, но для начала хотя бы так лучше, чем никак...).
Типовые рекомендации по подобным защитам:
https://habr.com/ru/company/badoo/blog/333592/
На автомобилях в бортовую систему сегодня закладываются режимы, которые не включат газ, если сперва не нажать на тормоз -- потому что огромное количество случаев, когда люди врезались в стены гаража, думая, что нажимают на тормоз, а не на газ.
Оказалось значительно эффективнее и проще встроить в систему "защиту от дурака" (poka-yoke по-японски и по-западному), нежели научить людей элементарно пользоваться (в реально опасных ситуациях!) двумя педалями так, как было задумано.
Передача кода другому разработчику на code review перед тем, как отправить его в продакшен -- это всё та же защита от дурака, которая всегда работает очень хорошо.
Вы можете (вы должны! :) добавлять "защиту от дурака" практически в любую систему, где потенциально ожидаются ошибки из-за сложности, или когда вы просто нервничаете, рассчитывая на надёжный результат. Почитайте про защитное программирование например (которое само по себе лишь слабенькая инженерная приляпка, не злоупотребляйте подобным, потому что такой навык тоже кривой и неверный, но для начала хотя бы так лучше, чем никак...).
Типовые рекомендации по подобным защитам:
https://habr.com/ru/company/badoo/blog/333592/
Ситуация в ИТ сегодня такая скоростная, что если к вам персонально (а не эйчаровским спамом) за последние полгода по поводу перехода на другую работу программистом никто не обращался, если именно вас, лично, давно никуда не зовут, значит ваша карьера стремительно летит под откос.
В 1984-м 37% программистов в мире были женщины, а сегодня их в ИТ около 10%. Я работал в 1980-е в ГВЦ Миноборонпрома СССР, ну там прикладными программистами работало вообще 80% женщин. Не знаю почему так сегодня всё изменилось, реально не понимаю: из занимающихся у меня представительницы прекрасного пола в целом существенно лучше учатся и понимают программирование, нежели ребята.
Регулярно рекомендую язык+экосистему Erlang
https://www.erlang.org
для практики в парадигме акторов (математическая модель параллельных вычислений, единственная практическая на сегодня, которая преодолевает ограничения недетерминированной машины Тьюринга).
Эпические кибервойны ближайшего будущего, в частности, подразумевают масштаб, доступный лишь модели акторов, однако засада в том, что на сегодня нету ни одного прикладного инструмента, способного качественно реализовать эту модель.
Ну может быть какие-то тайные работы ведутся, хотя очень сомневаюсь,
а сам эрланг ну совершенно несекьюрный язык )))
https://www.erlang.org
для практики в парадигме акторов (математическая модель параллельных вычислений, единственная практическая на сегодня, которая преодолевает ограничения недетерминированной машины Тьюринга).
Эпические кибервойны ближайшего будущего, в частности, подразумевают масштаб, доступный лишь модели акторов, однако засада в том, что на сегодня нету ни одного прикладного инструмента, способного качественно реализовать эту модель.
Ну может быть какие-то тайные работы ведутся, хотя очень сомневаюсь,
а сам эрланг ну совершенно несекьюрный язык )))
Erlang.org
Index
The official home of the Erlang Programming Language
Полезно ли указывать в резюме знание C++?
Почему бы и нет, если вы действительно в нём компетентны?
Но вы действительно компетентны в плюсах? Потому что это сегодня уже не просто язык, а огромная и довольно странная экосистема со своей культурой, довольно сильно отличающаяся от мэйнстрима.
Возможно, вы программируете на Java или C#, не особо завязываясь на какие-то специфические фичи стандартных библиотек, и способны быстро перенести 80% своего кода с этих языков на С++ просто на уровне синтаксиса и описания классов, с минимальными правками -- для этого достаточно просто почитать несколько часов какие-то быстрые старты в синтаксис плюсов на уровне википедии.
Так вот, этот уровень совершенно не соответствует знанию C++.
Если вы напишете в резюме, что знаете C++, а на интервью попадётся человек, действительно знающий плюсы, он вас за пять минут размажет по столу чуть более чем полностью :) Вы быстро сольётесь уже на первых вопросах по темплейтам или std.
Конечно, вы можете просто написать в резюме, что "немного знакомы с C++", или что имеете небольшое рабочее понимание, но зачем?
Потому что никому нету до этого дела.
Компании обычно требуют от джуниоров базовое понимание структур данных, общие алгоритмы, паттерны проектирования, объектно-ориентированное проектирование, рекурсию, понимание когда какие структуры данных использовать надо и когда не надо...
Неважно, пишете вы на Java или C++ или Python, или на чём угодно другом, это не имеет особого значения. И если вам задают вопрос о многопоточности, вероятно, не стоит вдаваться в детали её реализации в JavaScript.
Наоборот, вообще по всем техническим вопросам старайтесь подниматься на один пункт абстракции повыше (но только на один, не переборщите :).
Почему бы и нет, если вы действительно в нём компетентны?
Но вы действительно компетентны в плюсах? Потому что это сегодня уже не просто язык, а огромная и довольно странная экосистема со своей культурой, довольно сильно отличающаяся от мэйнстрима.
Возможно, вы программируете на Java или C#, не особо завязываясь на какие-то специфические фичи стандартных библиотек, и способны быстро перенести 80% своего кода с этих языков на С++ просто на уровне синтаксиса и описания классов, с минимальными правками -- для этого достаточно просто почитать несколько часов какие-то быстрые старты в синтаксис плюсов на уровне википедии.
Так вот, этот уровень совершенно не соответствует знанию C++.
Если вы напишете в резюме, что знаете C++, а на интервью попадётся человек, действительно знающий плюсы, он вас за пять минут размажет по столу чуть более чем полностью :) Вы быстро сольётесь уже на первых вопросах по темплейтам или std.
Конечно, вы можете просто написать в резюме, что "немного знакомы с C++", или что имеете небольшое рабочее понимание, но зачем?
Потому что никому нету до этого дела.
Компании обычно требуют от джуниоров базовое понимание структур данных, общие алгоритмы, паттерны проектирования, объектно-ориентированное проектирование, рекурсию, понимание когда какие структуры данных использовать надо и когда не надо...
Неважно, пишете вы на Java или C++ или Python, или на чём угодно другом, это не имеет особого значения. И если вам задают вопрос о многопоточности, вероятно, не стоит вдаваться в детали её реализации в JavaScript.
Наоборот, вообще по всем техническим вопросам старайтесь подниматься на один пункт абстракции повыше (но только на один, не переборщите :).
Знакомый недавно жаловался, несколько лет писал функциональный код в какой-то академической конторе, а потом пошёл таки сдаваться на галеры, за зарплатой. Для тренировки к собеседованиям стал активно решать типовые задачки с leetcode и подобных сервисов, но там везде человека буквально принуждают писать супер-императивный код. Говорит, насколько это было уродливо и противно, передать невозможно )))
При том, что кодить ведь и на массовых языках (Java, C#, Python...) уже сегодня можно неплохо в функциональной парадигме; уверен, что постепенно и до типовых задачек на собеседованиях правильные подходы доберутся.
При том, что кодить ведь и на массовых языках (Java, C#, Python...) уже сегодня можно неплохо в функциональной парадигме; уверен, что постепенно и до типовых задачек на собеседованиях правильные подходы доберутся.
+1 Настоятельно рекомендую, когда вы делаете какие-то свои долгосрочные проекты, периодически создавайте бэкапы не только кода, но и всей системы в целом. Например, если делаю что-то в линуксе, то почти всегда в виртуалке, и её слепки периодически сбрасываю на облачный диск. Потому что, спустя годы, вы скорее всего не сможете восстановить всю dev-среду 1:1, т.к. компиляторы библиотеки фреймворки быстро обновляются, и возникновение в будущем конфликтов из-за обратной несовместимости очень вероятно.
Почти через год после запуска на Replit было создано 2 147 483 648 (2^31) пользовательских баз данных (Replit DB, простое хранилище key-value). Сервис закономерно упал, и им пришлось обновить поле 'database_id' до BigInt. Так как на бэке реплита юзается обычная реляционка, ага, никаких nosql-ей.
+2 Порекомендую кстати PostgreSQL как лучшую опенсорсную РСУБД для 99% типовых проектов, с учётом и её мощности, и темпов развития, и экосистемы.
+2 Порекомендую кстати PostgreSQL как лучшую опенсорсную РСУБД для 99% типовых проектов, с учётом и её мощности, и темпов развития, и экосистемы.
Хороший вопрос, что если даже erlang в плане security не тянет, на чём же тогда создавать критически важные киберсистемы будущего 2030? :)
Ну к эрлангу претензии прежде всего концептуальные: когда типизация динамическая, когда сама система типов weak/unsound, ни о какой формальной строгости в принципе говорить нельзя.
Но что например в отношении akka.io и подобных? Да, однозначно этот фреймворк рекомендую, благо и Java и C# поддерживаются, и обязательно учебник "Akka в действии" поизучать, реально хороший, слегка поверхностный, но многие важные вещи рассматриваются. Для уровня просмотрщика миллиардов котиков или унылых госуслуг на 100500 миллионов человек, вполне норм.
Но для серьёзных проектов проблемы-то остаются: ну ок, вы запилили тоненький уровень логики с классными абстракциями, лёгонький, миллионы акторов фигачат миллиарды сообщений в хорошем реальном времени, вообще без лагов; возможно даже доказали формальную корректность вашей системы.
Но под ней лежит довольно внушительная архитектура; в akka понапихано много самых разношёрстных модулей (от поддержки кластеров до конечных автоматов и языка описания графов), качество реализации которых типично для опенсорса. Например, говоря akka, подразумеваем часто и k8s :)
И такую техническую архитектуру, зоопарк разных тяжёлых технологий, пожалуй без особых проблем любой noscript kiddie хакнет.
=
+4 Правильно так: создавать актор-системы конечно только в сильной статической типизации (как минимум, а дальше надо смотреть на саму систему типов в конкретном языке), и вообще под bare metal (тот же эрланг такое кстати неплохо умеет).
Короче говоря, рекомендация: Gleam (ML-семейство! algebraic data types! full type inference! и моё обожаемое "no null" :) ), абсолютный топчик на сегодня из всех BEAM-языков пожалуй: gleam.run
P.S. Запиню этот пост как стратегическую темку; самому интересно, когда (если) он устареет :)
Ну к эрлангу претензии прежде всего концептуальные: когда типизация динамическая, когда сама система типов weak/unsound, ни о какой формальной строгости в принципе говорить нельзя.
Но что например в отношении akka.io и подобных? Да, однозначно этот фреймворк рекомендую, благо и Java и C# поддерживаются, и обязательно учебник "Akka в действии" поизучать, реально хороший, слегка поверхностный, но многие важные вещи рассматриваются. Для уровня просмотрщика миллиардов котиков или унылых госуслуг на 100500 миллионов человек, вполне норм.
Но для серьёзных проектов проблемы-то остаются: ну ок, вы запилили тоненький уровень логики с классными абстракциями, лёгонький, миллионы акторов фигачат миллиарды сообщений в хорошем реальном времени, вообще без лагов; возможно даже доказали формальную корректность вашей системы.
Но под ней лежит довольно внушительная архитектура; в akka понапихано много самых разношёрстных модулей (от поддержки кластеров до конечных автоматов и языка описания графов), качество реализации которых типично для опенсорса. Например, говоря akka, подразумеваем часто и k8s :)
И такую техническую архитектуру, зоопарк разных тяжёлых технологий, пожалуй без особых проблем любой noscript kiddie хакнет.
=
+4 Правильно так: создавать актор-системы конечно только в сильной статической типизации (как минимум, а дальше надо смотреть на саму систему типов в конкретном языке), и вообще под bare metal (тот же эрланг такое кстати неплохо умеет).
Короче говоря, рекомендация: Gleam (ML-семейство! algebraic data types! full type inference! и моё обожаемое "no null" :) ), абсолютный топчик на сегодня из всех BEAM-языков пожалуй: gleam.run
P.S. Запиню этот пост как стратегическую темку; самому интересно, когда (если) он устареет :)
Лаборатория Математики и Программирования Сергея Бобровского pinned «Хороший вопрос, что если даже erlang в плане security не тянет, на чём же тогда создавать критически важные киберсистемы будущего 2030? :) Ну к эрлангу претензии прежде всего концептуальные: когда типизация динамическая, когда сама система типов weak/unsound…»
+6 Когда вам трудно подобрать подходящее имя для поля или метода класса, это верный признак, что сам класс спроектирован плохо.
100% рабочий способ попасть в ВОТВАСЯ (ВК Озон Тинькофф Валберис Авито Сбер Яндекс), да и в MMANGA
- Создайте стартап
- Успешно конкурируйте с любой компанией ВОТВАСЯ/MMANGA
- Станьте купленным ей
- Профит!
- Создайте стартап
- Успешно конкурируйте с любой компанией ВОТВАСЯ/MMANGA
- Станьте купленным ей
- Профит!
В одной из платных подписок встретил отчёт (лето 2021), ребята долго анализировали данные с https://www.levels.fyi
так вот, пять компаний которые сегодня самый топчик в плане зарплат программистов-сеньоров (MMANGA отдыхает). Зарплаты за год, конечно.
Базовая зарплата + бонусы + RSU (акции)
5. AirBnB: $418,000 (210+42+166)
4. Stripe: $420,000 (215+32+175)
3. Pinterest: $450,000 (200+0+250)
2. Netflix: $455,000 (455+0+0 чистый кэш! :) )
1. LinkedIn: 461,000 (204+31+226)
Явно выгоднее сегодня идти не в ИТ-компании, не в интернет-торговлю, и даже не в финтех, а в онлайн-компании, активно работающие на массовом рынке (развлечения, работа...).
так вот, пять компаний которые сегодня самый топчик в плане зарплат программистов-сеньоров (MMANGA отдыхает). Зарплаты за год, конечно.
Базовая зарплата + бонусы + RSU (акции)
5. AirBnB: $418,000 (210+42+166)
4. Stripe: $420,000 (215+32+175)
3. Pinterest: $450,000 (200+0+250)
2. Netflix: $455,000 (455+0+0 чистый кэш! :) )
1. LinkedIn: 461,000 (204+31+226)
Явно выгоднее сегодня идти не в ИТ-компании, не в интернет-торговлю, и даже не в финтех, а в онлайн-компании, активно работающие на массовом рынке (развлечения, работа...).
+7 При прохождении интервью в ВОТВАСЯ/MMANGA с очень большой вероятностью вы будете получать весьма двусмысленные задачки и вопросы, которые не подразумевают очевидный однозначный ответ или решение. И чаще всего такие задания не имеют ничего общего с обычной работой, с типовыми тасками. Они готовятся специально, топовые компании целенаправленно расставляют разные ловушки, чтобы проверить, кто вы такой на самом деле. Вы должны быть готовы к этому.
Ну например, возможен такой странный вопрос на интервью: "напишите код, который выявляет циклы в связном списке" -- и люди сразу начинают рассуждать в духе "помечаем каждый узел флажком "посещён", после чего начинаем сканировать список с головы, проверяя и фиксируя этот флажок..."
Но тут начинать надо с того, что уточнить -- используем ли стандартный (в экосистеме вашего языка) тип linked list? Если да, если гарантируется, что всегда есть связанные head и tail, то в нём циклов не может быть в принципе :)
Да и в нестандартном, если реализован аккуратно, тоже циклы не должны присутствовать. А искать циклы в заведомо кривой реализации, хм...
Ну например, возможен такой странный вопрос на интервью: "напишите код, который выявляет циклы в связном списке" -- и люди сразу начинают рассуждать в духе "помечаем каждый узел флажком "посещён", после чего начинаем сканировать список с головы, проверяя и фиксируя этот флажок..."
Но тут начинать надо с того, что уточнить -- используем ли стандартный (в экосистеме вашего языка) тип linked list? Если да, если гарантируется, что всегда есть связанные head и tail, то в нём циклов не может быть в принципе :)
Да и в нестандартном, если реализован аккуратно, тоже циклы не должны присутствовать. А искать циклы в заведомо кривой реализации, хм...
"Дайте кому-нибудь программу, и он будет мучиться целый день; научите кого-нибудь программировать, и он будет мучиться всю жизнь"
-- David Leinweber, глава Lawrence Berkeley National Laboratory Computational Research Division's Center for Innovative Financial Technology
-- David Leinweber, глава Lawrence Berkeley National Laboratory Computational Research Division's Center for Innovative Financial Technology
то странное чувство, когда пишешь интерпретатор хаскеля на питоне, а на вопрос "почему на питоне-то, а не на самом хаскеле (ибо деды дали заповедь "лисп на лиспе")?" отвечаешь "он проще"...
Сегодня практически везде учат принципу DRY именно как "не повторяйся", или что ещё примитивнее, "не копипасти код". Сами по себе эти рекомендации безусловно хорошие, но оригинальная идея DRY в The Pragmatic Programmer была про "единственное истинное представление" ("single point of truth") каждой части кода в рамках системы, что ближе даже скорее к SRP.
DRY просто неудачным названием оказалось.
DRY просто неудачным названием оказалось.
То, что скоростное движение в ИТ через изучение одного фреймворка и прикладные проэкты под требования вакансий -- это зашквар, проигрывающий в качестве и силе обучения университетскому подходу в разы, а то и на порядки, давно доказано научно.
Например, две группы студентов решают на leetcode задачки уровня hard. Одну и ту же сильно сложную задачку можно решить множеством способов; первая группа решает одну и ту же hard-задачу три раза, вторая -- три разные hard-задачи. И на четвёртый раз вторая группа решает hard-задачу первой группы существенно лучше, чем сама эта группа, вроде бы уже её как следует изучившая!
Это контринтуитивно, но факт: даже глубокое погружение в один учебный трек никогда не даст вам способности действительно глубоко его понять, нежели когда вы одновременно изучаете и этот трек более "поверхностно", и близкие ему треки.
Тут безусловно имеется важная грань: не скатиться в поверхностное скакание по верхам, ну вот для этого и работает моя Школа. Не думаю, что кто-то ещё из онлайн-курсов в России придерживается в ИТ подобных научных схем обучения, потому что правильные модели никакого профита не приносят, это скорее благотворительность; а продаётся на миллионы рублей вот такое:
"Функциональность а-ля инстаграм на минималках: показывать карточки, лайки, личный кабинет, соответственно регистрация и авторизация.
Моя оценка — это все задачи для человека как минимум с двумя годами реального опыта. Пройти путь с нуля когда не понимаешь что такое переменная и что функцию надо вызвать чтобы заработала, и до такого объема работы за 9 месяцев, очень и очень сложно."
Например, две группы студентов решают на leetcode задачки уровня hard. Одну и ту же сильно сложную задачку можно решить множеством способов; первая группа решает одну и ту же hard-задачу три раза, вторая -- три разные hard-задачи. И на четвёртый раз вторая группа решает hard-задачу первой группы существенно лучше, чем сама эта группа, вроде бы уже её как следует изучившая!
Это контринтуитивно, но факт: даже глубокое погружение в один учебный трек никогда не даст вам способности действительно глубоко его понять, нежели когда вы одновременно изучаете и этот трек более "поверхностно", и близкие ему треки.
Тут безусловно имеется важная грань: не скатиться в поверхностное скакание по верхам, ну вот для этого и работает моя Школа. Не думаю, что кто-то ещё из онлайн-курсов в России придерживается в ИТ подобных научных схем обучения, потому что правильные модели никакого профита не приносят, это скорее благотворительность; а продаётся на миллионы рублей вот такое:
"Функциональность а-ля инстаграм на минималках: показывать карточки, лайки, личный кабинет, соответственно регистрация и авторизация.
Моя оценка — это все задачи для человека как минимум с двумя годами реального опыта. Пройти путь с нуля когда не понимаешь что такое переменная и что функцию надо вызвать чтобы заработала, и до такого объема работы за 9 месяцев, очень и очень сложно."