В процессе эпичного крестосрача на LOR-е довелось заглянуть в парочку темных мест C++, о которых раньше даже и задумываться не приходилось. Чуток подробностей для тех, кому это интересно, находится под катом.
пятница, 17 июня 2016 г.
вторник, 14 июня 2016 г.
[software.business] Шум вокруг продажи LinkedIn...
...еще больше убеждает в том, что ИТ -- это уже про бизнес, а не технологии. Времена, когда ИТ-шиков интересовало насколько много 16-битового кода осталось в очередной версии Windows или что нового приносит Java 1.4 по сравнению с Java 1.3 закончились. Не суть важно, на каких технологиях построен LinkedIn, MSQRD или WhatsApp. Не важно, как и куда эти технологии будут развиваться и будет ли от этого какой-нибудь полезный выхлоп. Все это фигня по сравнению со стоимостью сделок.
А раз технологии ушли на задний план, то на передний план выходит маркетинг и все, что с этим связано. Что будет означать постепенное снижение роли разработчика ПО и усиление других ролей, начиная от продут-оунеров и проджект-менеджеров, заканчивая проектировщиками UI, дизайнерами и копирайтерами.
Так что если кто-то задумывается сейчас о том, как найти свое место в ИТ через 3-4-5 лет, то я бы рекомендовал смотреть в сторону специальностей, помогающих позиционировать и продавать программные продукты. Внешний вид, функциональные возможности, позиционирование, продвижение на рынке, поддержка -- все это будет гораздо важнее самой разработки (да, полагаю, уже и сейчас гораздо важнее).
"Как сделать?" -- это уже давно не вопрос. Тогда как вопросы "Что делать?", "Зачем это делать?", "Для кого делать?" и "Как им это продать?" не просто остались, но и стали еще актуальнее. Посему в ИТ будут востребованы те, кто могут внятно отвечать на эти вопросы.
Ну и плюс к тому: управление процессом производства, управление сроками и качеством так же будет востребовано. Потому, что толковых инженеров-разработчиков будет становиться все меньше. Если не в абсолютных цифрах, то в процентном соотношении точно.
понедельник, 13 июня 2016 г.
[prog.flame] Любопытная заметка "Disadvantages of purely functional programming"
Те, кто меня знает еще по RSDN-у, могут вспомнить, что я был довольно рьяным противником хайпа вокруг функционального программирования вообще и функциональных языков программирования в частности. В общем-то, практически таким же я остаюсь и сейчас, ибо любой хайп -- это не есть хорошо и за хайпом, как правило, стоят интересы тех, кто хочет вам что-нибудь впарить. А когда хайп сходит на нет или же возникает вокруг какой-то другой темы, то поддавшиеся моде могут обнаружить, что сильно разрекламированная цацка имеет свой собственный набор проблем, явные достоинства сильно нивелируются срываемыми до поры, до времени недостатками, а суммарный выигрыш если и есть, то не такой уж и большой.
Имхо, статейка Disadvantages of purely functional programming как раз в эту же тему. Суть -- чистое ФП классная штука, конечно. Но тормозит. И, в принципе, в определенных местах не может не тормозить.
Отдельно отметил бы ссылочку, которая есть в этой статье: Naive parallelism with HLVM. Особенно мне понравились пути повышения производительности HLVM-программы: Disabling bounds checking provides a substantial 20% performance improvement. Disabling the shadow stack (and, therefore, disabling GC) provides another 25% performance improvement. With these two changes, HLVM is only 24% slower than C++. Ну, т.е., берем язык более высокого уровня, чем C++, и гораздо более безопасный, чем C++, а потом отключаем нафиг те фичи, которые как раз и делают его более высокоуровневым и более безопасным. И все только для того, чтобы не тормозить так сильно.
Ну и вообще, как мне кажется, в последние год-полтора прослеживается интересная тенденция: если раньше во главу угла ставилась скорость разработки и на передний план выходили безопасные языки программирования (причем даже не Java, а всякие Python-ы, Ruby, Erlang-и, Scala, Clojure и прочие OCaml-ы с Haskell-ями), то теперь просто скорости разработки мало. Нужно еще, чтобы результат работал быстро и/или жрал мало. Отсюда и интерес к тому же Go, который позволяет писать что-то так же быстро, как и на Python-е, но работает затем это что-то намного эффективнее, чем на Python-е. И возродившийся интерес к старой ламповой сишечке (а так же вспыхивающие вновь споры C vs C++). И пристальное внимание к Rust-у и Nim-у...
Объяснение сей тенденции я вижу в том, что делать быстро на Python-е (Ruby, Erlang, Scala, Clojure,...) теперь могут практически все. И одним из важнейших факторов становится снижение издержек на эксплуатацию. Для чего нужны не только быстро выходящие на рынок решения, но еще и эффективно работающие. А вот это умеют делать пока не только лишь все :)
PS. Кстати говоря, то, что все стараются друг другу что-то продать (кто-то "продает" Haskell, кто-то "продает" Clojure, я, например, "продаю" SObjectizer) -- это нормально. Правильно сделанная "покупка" сильно облегчает жизнь. Однако, важно понимать, что в процессе "продажи" мало кто будет на 100% откровенен и будет честно и по собственной воле рассказывать не только о достоинствах, но и недостатках. Так что никому нельзя верить. Мне можно ;)
PPS. Прошу воспринимать написанный выше текст с изрядной долей юмора и иронии.
Подписаться на:
Сообщения (Atom)