Уровень неплохой, потому что как минимум есть ссылки и пруфы на конкретные утверждения.
Хочется отметить, что 5 комментов с описанием и выкладками того, в чем именно проблема статьи, оказались в сотни раз полезнее кучи комментариев "ой, бред, даже расписывать не хочу" и "мда, натянул сову на глобус. Скатился ресурс" без какой-либо конкретики.
Особенно порадовала пара саркастических сообщений в духе "ну да, в спейсэксе и старлинке же никто не делал экономические расчеты до этого". Интересно, такие люди понимают, что аргумент от авторитета выглядит очень плохо со стороны? Особенно в контексте статьи, где этот авторитет, как раз-таки, и ставят под сомнение
Как хаскелисту интересно — что делает скалу более юзер-френдли?
Больший пул кандидатов + возможность постепенного перехода от привычного си-подобного синтаксиса с ООП к хаскеле-подобному синтаксису. Как следствие, больше вакансий в коммерции
Здесь согласен, в таких сложных местах pyspark еще уступает. Но, к сожалению, суммарная тенденция все равно очевидна по непрямым показателям. Как один из примеров:
А вот подскажите ещё такой момент (по вашему мнению, разумеется): то, что популярность Scala хм "стагнирует" на сегодняшний день - у этого только маркетингово-рыночная основа (никто большой за неё не вписался) или всё-таки "по-честному" и технологически у неё нет особых крутых перспектив \ выгодных ниш и т.д. ?
Совокупность этого всего. Скажем так, лучшие и самые удобные штуки из нее переняли (ну если не напрямую, то косвенно) в Java, C# и Kotlin. И в итоге при сравнении плюсов/минусов скалы и вот этой троицы при старте проектов, выбор все чаще выпадал в пользу троицы. Два основных минуса скалы на мой взгляд: байт-код несовместимость между версиями (что должны были пофиксить в недавней 3й версии, но уже поздно для возвращения в мейнстрим. Лет 5 назад сделали бы, то еще был бы шанс) и излишняя сложность (приходится учить и ООП, и околохаскелевскую функциональщину). В итоге "рыночек порешал". (а) Сложно стартовать проект, т.к. нет разрабов и каких-то вещей в экосистеме => (b) разрабы не изучают и не пишут инструменты, т.к. становится меньше проектов на рынке => возвращаемся к (a). И так по кругу. Довольно классическая картина затухания.
По поводу того, что никто за нее не вписался - не совсем так. Вписывались, и многие. Твиттер так вообще чуть ли не все переписал на нее лет 10 назад, в волмарте писали на ней куски большие, в линкедине целую кафку сделали :) А уж количество компаний, которые писали на ней небольшие кусочки своего бэка, на порядки больше.
и технологически у неё нет особых крутых перспектив \ выгодных ниш и т.д. ?
На текущий 2021 год лично я вижу у нее 3 ниши. В порядке убывания:
1) Спарк и потоковая обработка. Хотя в batch обработке уже можно уверенно сказать, что по сути победил питон со своим pyspark'ом, но вот в потоковой еще пока нет. И, например, на Flink с использованием Скалы сейчас пишут некоторые вещи в Netflix, в Alibaba. В Tesla вроде есть какие-то сервисы по стриминговой обработке на Скале (но тут могу напутать). В Spotify биндинги для Apache Beam сделали. Как видите, это не классический бэкенд, а компании и их конкретные сервисы с терабайтами и петабайтами данных с требованием обработки в реальном времени, что довольно специфичный случай. Ну и да, не удивлюсь, если года через 4-5 и тут окончательно вытеснится джавой с питоном по вышеуказанным причинам.
2) Full FP style со всеми этими вашими эффектами, тайпклассами и монадами. В основном для более точного, корректного и тестируемого описание данных при моделировании доменной области. Самый крупный представитель, который приходит мне на ум - Disney+. У них крупные части сервисов billing system'ы написаны в таком стиле. Также видел пару статей, как некоторые компаниии обычные микросервисы пишут на этом стеке. По сути, это юзер-френдли хаскель.
3) Акторная модель на Akka.
То есть ниши есть, но в процентном соотношении относительно классического бэкенда - капли в море.
Если я правильно понимаю (из общих соображений) компилятор редко может доказать, что в коллекции "транзитивно иммутабельные" данные. И применить хорошие оптимизации.
А можете пример какой-нибудь привести таких оптимизаций? Там и так иммутабельные коллекции написаны здорово. Построены на всяких trie и HAMT структурах с применением structural sharing. Мне в голову так сейчас не приходит пример, где информация об иммутабельности содержащихся внутри данных может помочь компилятору в оптимизации еще больше. То, что это способно выстрелить потом, когда бесконтрольно из разных частей кода менять состояние - тут да, не спорю, об этом следующий пункт.
Ну и даже человек всегда должен помнить, что подлянка такого рода возможна (например предок иммутабельный, а в коллекции лежит его мутабельный потомок).
Это действительно возможно. Но перед этим нужно явно совершить действие с отходом от стандартных практик. Вот тот человек, который явно пропишет var вместо рекмендованного val или вложит внутрь изменяемую коллекцию, предварительно импортировав ее - именно он во время этих действий и должен осознавать данные вещи. А я не знаю, кстати, в хаскеле или расте компилятор умеет такую вложенность проверять?
Я вот её не понимаю, откуда взялся интерес к ней, на грани хайпа.
Интерес к ней взялся в то время, когда в джаве был ужасный застой. Она дала хороший буст всей jvm экосистеме, как минимум джаве (лямбды, функциональные интерфесы, стримы, Optional, type inference - это что в голову сразу пришло. Естественно в джаве это все появилось не просто так, а благодаря вынужденной конкуренции) и котлину (тут проще будет перечислить отличия, чем сходства).
1. Нетранзитивность признака "mutable". Ну какой смысл иметь иммутабельную коллекцию (или объект), содержащую в себе мутабельные данные?
Тут не понял. А зачем вы нарочно мутабельные данные засовываете в иммутабельные коллекции, если в вашей конкретной ситуации это еще и сильно вредит? Кейс классы по умолчанию иммутабельные. И вот какая-нибудь такая вещь у вас тоже полностью неизменяемая в итоге получается:
case class Item(id: UUID, name: String)
case class Quantity(value: Int) extends AnyVal
case class Customer(firstName: String, lastName: String)
case class Purchase(items: Map[Item, Quantity], total: BigDecimal)
val customer = Customer("Kyle", "Johnson")
val purchase = Purchase(
Map(Item(UUID.randomUUID(), "milk") -> Quantity(2)),
BigDecimal(5)
)
val completelyImmutableNestedStructure = List(
customer -> purchase // <- this is a tuple
)
Что вы имеете в виду под симмитричным? Что Left и Right равноценны? В скале это исправили годах в 2016-17 и теперь: Either is right-biased, which means that Right is assumed to be the default case to operate on. If it is Left, operations like map and flatMap return the Left value unchanged.
Вы не так поняли. Имел в виду, что едиственный способ узнать, какой алгоритм эффективнее на практике - проводить бенчмарки. Другого варианта не существует. Это, собственно, и есть ответ на "почему quicksort используется чаще heapsort, хотя последний лучше асимптотически". Потому что замеры на реальных данных в пользу первого.
Интересующие позиции: синьор+, строго бэкенд, строго не блокчейн и не node.js/php.
Это на кого рассматривался автор. Боюсь, с алготрейдингом и геймдевом мимо. kv-бд еще можно как-то подтянуть. Но даже в этом случае намного логичнее спрашивать про хэши и про отличия B-tree от B+ tree от LSM. Да даже просто heap (без сортировки) и priority queue было бы больше толку обсуждать, ибо они реально на практике применяются.
Сортировок много, и это весьма простые алгоритмы по своей сути.
Мне все еще непонятно, как из простоты следует необходимость это помнить и тем более обсуждать на собеседовании, которое огрниченно по времени. Побитовые операции тоже простые, но это не говорит о том, что про них стоит спрашивать на собесе C# или Ruby разработчика. Есть же просто куча тем, которые будут важнее и показательнее энциклопедической прогонки по неиспользуемому алгоритму.
почему на практике иногда лучше взять алгоритм с худшей ассимптотикой
Бенчмарки. Единственный правильный ответ, к которому в конце концов все и сводится.
"у какого алгоритма лучше константа" Бенчмарки.
Как вообще выбрать из алгоритмов с одной ассимптотикой самый подходящий под задачу
Бенчмарки.
Но самое смешное, что эти бенчмарки проводятся создателями СУБД, языков программирования, платформ и т.д. Это огромные труды, которые тянут на научные работы. Спрашивать с ходу такие вещи на собеседовании - как минимум нерезультативно в плане оценивания кандидата.
"Вопрос то глубокий на самом деле." Вопрос-то, может, и глубокий, но чисто энциклопедический. Больше всего он показывает, сталкивался ли кандидат с ним раньше. Я чувствую, что вы сталкивались :)
Итого: в вопросе зачем-то используется алгоритм heapsort, заранее зная, что он непопулярен. Что мешает узнать про константы на более знакомых алгоритмах? Да хотя бы тех же quicksort vs merge sort (две самых популярных сортировки).
P.S. как же здесь больно оформлять цитаты на комментарии
Уж не знаю почему, но всегда с интересом читаю подобные статьи. Спасибо, что поделились!
Немного вопросов:
1) Алгозадачки обычно ставят в какой форме? Устно проговаривают или текстом дают? Мне кажется, когда ее произносят - значительно сложнее, чем когда условие открыто перед тобой и ты всегда можешь глазами пробежаться по нему.
2) "heap sort vs normal sort"
Вот зачем им это нужно спрашивать? :) Серьезно, какая логика в голове при этом? "Кандидат не знает преимущества хип сорта, поэтому..." поэтому что? О чем им скажет этот факт? Этих сортировок десятки существует и если ты не лектор по предмету "Алгоритмы сортировок", то эта информация в голове надолго не задержится. Извините, словил флэшбэк - пишу, как давненько пострадавший от вопроса "хип сорт vs квик сорт. Преимущества и недостатки" :)
Послностью согласен. За последние лет 10 ситуация поменялась. Даже больше скажу, нынешние школьники растут на англоязычных медиа. То, что предыдущее поколение добывало честным трудом, читая книги, учебники и слушая песни, нынешнее поколение получает из стримов, мемов, видосов, подкастов и соцсетей. Как итог, их уровень языка при прочих равных на порядки выше, так еще и менее дискомфорта вызвает сам процесс обучения
Здесь, по-моему, вы надумали лишнего постфактум :) В США все спокойно говорят "Can I eat/drink/open/etc. ...?" и никто не подразумевает физическую возможность. То есть что с may, что с can поймут без проблем и без двусмысленных трактований. Молодежь до 40-50 лет так уж точно.
Но, вообще, такие вещи очень сильно могут зависеть от штата, района, образования собеседника, возраста, воспитания, семьи и прочего. Охотно верю, что в США все еще есть люди, которые действительно проводят различие между этими словами
Не касаяь согласия/несогласия со статьей, есть ощущение, что люди гуглят "отличие школьного английского от реального", переходят по первой выпавшей ссылке и идут писать уже свой пост со срывом покровов.
Ну серьезно, я даже не за весь рунет сейчас, а только за хабр говорю. Каждый год стабильно выходит пару статей о том, как же плохо учат в школе и что shall - архаизм, что pupil никто не говорит, что schedule по-разному читается, что truck и lorry, что burned и burnt, что...
День сурка какой-то :)
Неужели при написании не хотелось написать что-то свое, уникальное, с чем столкнулись на личном опыте и удивились? А не очередной раз бороться с соломенным чучелом в виде shall.
А значит может и ваша! Ведь я простой парень, живущий лишь два года в США, без местного образования, не имея особых знакомств. Для этого я и написал эти и предыдущие статьи. Надеюсь, в ближайшие годы, ребят с бывших советских стран станет больше в топовых компаниях!
Забыли добавить: "простой парень, владеющий грин-картой". А так да, любой из ex-USSR может :):)
В итоге, даже не имея письменный параллельный офер от Амазон, мои консультанты помогли мне выторговать на 50% лучшую компенсацию.
А вот здесь можете поподробнее рассказать? Как у них вообще происходит торг? Неужели люди прямо высылают оффер от второй компании на почту и пишут "Тут мне столько предложили. Ваш ход"?
Конкретно про стандартную библиотеку хаскеля не знаю, но, вообще, локальная мутабельность, которая гарантированно никак не может быть достигнута извне, не противоречит чистоте функции.
В скале, например, куча циклов while и обычных переменных внутри функций стандартной библиотеки и даже у функций/методов иммутабельных коллекций.
Короче говоря, пока пишешь нечто высокоуровневое, то все очень круто, но если надо написать нечто числодробильное, то все тлен.
Но ведь про какую-нибудь джаву можно сказать похожим образом :)
И как, пригодились хоть где-то? :)
Уровень неплохой, потому что как минимум есть ссылки и пруфы на конкретные утверждения.
Хочется отметить, что 5 комментов с описанием и выкладками того, в чем именно проблема статьи, оказались в сотни раз полезнее кучи комментариев "ой, бред, даже расписывать не хочу" и "мда, натянул сову на глобус. Скатился ресурс" без какой-либо конкретики.
Особенно порадовала пара саркастических сообщений в духе "ну да, в спейсэксе и старлинке же никто не делал экономические расчеты до этого". Интересно, такие люди понимают, что аргумент от авторитета выглядит очень плохо со стороны? Особенно в контексте статьи, где этот авторитет, как раз-таки, и ставят под сомнение
Прошли правило Крамера, перепрыгнув при этом через детерминанты? Мощно
Больший пул кандидатов + возможность постепенного перехода от привычного си-подобного синтаксиса с ООП к хаскеле-подобному синтаксису. Как следствие, больше вакансий в коммерции
Вот здесь и кроется опасность :)
Как альтернатива, один из двух вариантов:
А если совсем сложные структуры, то там Monocle как запасной вариант есть.
Но это вы, я так понимаю, специально упростили свой пример, в котором необходима изменяемость поля. В целом претензия ясна, да. Интересный случай
Здесь согласен, в таких сложных местах pyspark еще уступает. Но, к сожалению, суммарная тенденция все равно очевидна по непрямым показателям. Как один из примеров:
source
Совокупность этого всего. Скажем так, лучшие и самые удобные штуки из нее переняли (ну если не напрямую, то косвенно) в Java, C# и Kotlin. И в итоге при сравнении плюсов/минусов скалы и вот этой троицы при старте проектов, выбор все чаще выпадал в пользу троицы. Два основных минуса скалы на мой взгляд: байт-код несовместимость между версиями (что должны были пофиксить в недавней 3й версии, но уже поздно для возвращения в мейнстрим. Лет 5 назад сделали бы, то еще был бы шанс) и излишняя сложность (приходится учить и ООП, и околохаскелевскую функциональщину). В итоге "рыночек порешал". (а) Сложно стартовать проект, т.к. нет разрабов и каких-то вещей в экосистеме => (b) разрабы не изучают и не пишут инструменты, т.к. становится меньше проектов на рынке => возвращаемся к (a). И так по кругу. Довольно классическая картина затухания.
По поводу того, что никто за нее не вписался - не совсем так. Вписывались, и многие. Твиттер так вообще чуть ли не все переписал на нее лет 10 назад, в волмарте писали на ней куски большие, в линкедине целую кафку сделали :) А уж количество компаний, которые писали на ней небольшие кусочки своего бэка, на порядки больше.
На текущий 2021 год лично я вижу у нее 3 ниши. В порядке убывания:
1) Спарк и потоковая обработка. Хотя в batch обработке уже можно уверенно сказать, что по сути победил питон со своим pyspark'ом, но вот в потоковой еще пока нет. И, например, на Flink с использованием Скалы сейчас пишут некоторые вещи в Netflix, в Alibaba. В Tesla вроде есть какие-то сервисы по стриминговой обработке на Скале (но тут могу напутать). В Spotify биндинги для Apache Beam сделали. Как видите, это не классический бэкенд, а компании и их конкретные сервисы с терабайтами и петабайтами данных с требованием обработки в реальном времени, что довольно специфичный случай. Ну и да, не удивлюсь, если года через 4-5 и тут окончательно вытеснится джавой с питоном по вышеуказанным причинам.
2) Full FP style со всеми этими вашими эффектами, тайпклассами и монадами. В основном для более точного, корректного и тестируемого описание данных при моделировании доменной области. Самый крупный представитель, который приходит мне на ум - Disney+. У них крупные части сервисов billing system'ы написаны в таком стиле. Также видел пару статей, как некоторые компаниии обычные микросервисы пишут на этом стеке. По сути, это юзер-френдли хаскель.
3) Акторная модель на Akka.
То есть ниши есть, но в процентном соотношении относительно классического бэкенда - капли в море.
А можете пример какой-нибудь привести таких оптимизаций? Там и так иммутабельные коллекции написаны здорово. Построены на всяких trie и HAMT структурах с применением structural sharing. Мне в голову так сейчас не приходит пример, где информация об иммутабельности содержащихся внутри данных может помочь компилятору в оптимизации еще больше. То, что это способно выстрелить потом, когда бесконтрольно из разных частей кода менять состояние - тут да, не спорю, об этом следующий пункт.
Это действительно возможно. Но перед этим нужно явно совершить действие с отходом от стандартных практик. Вот тот человек, который явно пропишет var вместо рекмендованного val или вложит внутрь изменяемую коллекцию, предварительно импортировав ее - именно он во время этих действий и должен осознавать данные вещи. А я не знаю, кстати, в хаскеле или расте компилятор умеет такую вложенность проверять?
Интерес к ней взялся в то время, когда в джаве был ужасный застой. Она дала хороший буст всей jvm экосистеме, как минимум джаве (лямбды, функциональные интерфесы, стримы, Optional, type inference - это что в голову сразу пришло. Естественно в джаве это все появилось не просто так, а благодаря вынужденной конкуренции) и котлину (тут проще будет перечислить отличия, чем сходства).
Тут не понял. А зачем вы нарочно мутабельные данные засовываете в иммутабельные коллекции, если в вашей конкретной ситуации это еще и сильно вредит? Кейс классы по умолчанию иммутабельные. И вот какая-нибудь такая вещь у вас тоже полностью неизменяемая в итоге получается:
В американском, кстати, /ˈziːbɹə/
Что вы имеете в виду под симмитричным? Что Left и Right равноценны? В скале это исправили годах в 2016-17 и теперь:
Either is right-biased, which means that Right is assumed to be the default case to operate on. If it is Left, operations like map and flatMap return the Left value unchanged.Вы не так поняли. Имел в виду, что едиственный способ узнать, какой алгоритм эффективнее на практике - проводить бенчмарки. Другого варианта не существует. Это, собственно, и есть ответ на "почему quicksort используется чаще heapsort, хотя последний лучше асимптотически". Потому что замеры на реальных данных в пользу первого.
Это на кого рассматривался автор. Боюсь, с алготрейдингом и геймдевом мимо. kv-бд еще можно как-то подтянуть. Но даже в этом случае намного логичнее спрашивать про хэши и про отличия B-tree от B+ tree от LSM. Да даже просто heap (без сортировки) и priority queue было бы больше толку обсуждать, ибо они реально на практике применяются.
Мне все еще непонятно, как из простоты следует необходимость это помнить и тем более обсуждать на собеседовании, которое огрниченно по времени. Побитовые операции тоже простые, но это не говорит о том, что про них стоит спрашивать на собесе C# или Ruby разработчика. Есть же просто куча тем, которые будут важнее и показательнее энциклопедической прогонки по неиспользуемому алгоритму.
Бенчмарки. Единственный правильный ответ, к которому в конце концов все и сводится.
"у какого алгоритма лучше константа"
Бенчмарки.
Бенчмарки.
Но самое смешное, что эти бенчмарки проводятся создателями СУБД, языков программирования, платформ и т.д. Это огромные труды, которые тянут на научные работы. Спрашивать с ходу такие вещи на собеседовании - как минимум нерезультативно в плане оценивания кандидата.
"Вопрос то глубокий на самом деле."
Вопрос-то, может, и глубокий, но чисто энциклопедический. Больше всего он показывает, сталкивался ли кандидат с ним раньше. Я чувствую, что вы сталкивались :)
Итого: в вопросе зачем-то используется алгоритм heapsort, заранее зная, что он непопулярен. Что мешает узнать про константы на более знакомых алгоритмах? Да хотя бы тех же quicksort vs merge sort (две самых популярных сортировки).
P.S. как же здесь больно оформлять цитаты на комментарии
Уж не знаю почему, но всегда с интересом читаю подобные статьи. Спасибо, что поделились!
Немного вопросов:
1) Алгозадачки обычно ставят в какой форме? Устно проговаривают или текстом дают? Мне кажется, когда ее произносят - значительно сложнее, чем когда условие открыто перед тобой и ты всегда можешь глазами пробежаться по нему.
2) "heap sort vs normal sort"
Вот зачем им это нужно спрашивать? :) Серьезно, какая логика в голове при этом? "Кандидат не знает преимущества хип сорта, поэтому..." поэтому что? О чем им скажет этот факт? Этих сортировок десятки существует и если ты не лектор по предмету "Алгоритмы сортировок", то эта информация в голове надолго не задержится. Извините, словил флэшбэк - пишу, как давненько пострадавший от вопроса "хип сорт vs квик сорт. Преимущества и недостатки" :)
Послностью согласен. За последние лет 10 ситуация поменялась. Даже больше скажу, нынешние школьники растут на англоязычных медиа. То, что предыдущее поколение добывало честным трудом, читая книги, учебники и слушая песни, нынешнее поколение получает из стримов, мемов, видосов, подкастов и соцсетей. Как итог, их уровень языка при прочих равных на порядки выше, так еще и менее дискомфорта вызвает сам процесс обучения
Здесь, по-моему, вы надумали лишнего постфактум :) В США все спокойно говорят "Can I eat/drink/open/etc. ...?" и никто не подразумевает физическую возможность. То есть что с may, что с can поймут без проблем и без двусмысленных трактований. Молодежь до 40-50 лет так уж точно.
Но, вообще, такие вещи очень сильно могут зависеть от штата, района, образования собеседника, возраста, воспитания, семьи и прочего. Охотно верю, что в США все еще есть люди, которые действительно проводят различие между этими словами
Не касаяь согласия/несогласия со статьей, есть ощущение, что люди гуглят "отличие школьного английского от реального", переходят по первой выпавшей ссылке и идут писать уже свой пост со срывом покровов.
Ну серьезно, я даже не за весь рунет сейчас, а только за хабр говорю. Каждый год стабильно выходит пару статей о том, как же плохо учат в школе и что shall - архаизм, что pupil никто не говорит, что schedule по-разному читается, что truck и lorry, что burned и burnt, что...
День сурка какой-то :)
Неужели при написании не хотелось написать что-то свое, уникальное, с чем столкнулись на личном опыте и удивились? А не очередной раз бороться с соломенным чучелом в виде shall.
Учитывая, как много людей в комментариях повелось - это уже не толстый стеб, а тонкий троллинг
Забыли добавить: "простой парень, владеющий грин-картой". А так да, любой из ex-USSR может :):)
А вот здесь можете поподробнее рассказать? Как у них вообще происходит торг? Неужели люди прямо высылают оффер от второй компании на почту и пишут "Тут мне столько предложили. Ваш ход"?
Конкретно про стандартную библиотеку хаскеля не знаю, но, вообще, локальная мутабельность, которая гарантированно никак не может быть достигнута извне, не противоречит чистоте функции.
В скале, например, куча циклов while и обычных переменных внутри функций стандартной библиотеки и даже у функций/методов иммутабельных коллекций.
Но ведь про какую-нибудь джаву можно сказать похожим образом :)