из Вашингтона спрашивают

[juan_gandhi]

"В своё время Питер Нортон сказал, что в СССР была очень сильная математика, поэтому нас ждут очень хорошие успехи в области программирования.

Но если оглядеться, то российских программных продуктов на мировом рынке очень немного. А те, которые вынужденно становятся массовыми (как 1с), восторга не вызывают.

Так в чем здесь проблема? Уровень математики всё же оказался недостаточно высоким?" 

Т.к. я не знаю ответа, могу только языком почесать, то приглашаю желающих. Особенно Дениса, конечно.

Comments

[zyxman]

> человека надо было направить на написание параллелизуемого кода, - какие проблемы-то?

Сложно это - направить. Во первых, потому что это уже принуждение, которое кто-то должен сделать (а программиста принуждать должен человек сопоставимого с ним ума, что уже само по себе есть проблема), а во вторых, потому что не все поддаются принуждению - некоторые просто не принуждаются, другие слишком легко ломаются.

[snowps]

Хорошему программисту, как правило, интересно решать сложные задачи, а оптимизация - это как раз достаточно нетривиальная сфера для приложения инженерных умений (в том числе и математических). Конечно бывает очень часто, что высококлассный специалист не испытывает особого энтузиазма при работе с какими-то определёнными инструментами, но это совершенно нормальная ситуация - заставлять, скажем, столяра работать с металлом с точки зрения производственной рациональности бессмысленно, но это уже сфера ответственности менеджмента, который должен находить для сотрудников ту часть работы, которую они способны выполнять эффективно и с удовольствием. Просто сейчас, во времена больших IT-компаний, где bus factor играет значительно бОльшую роль, чем потребность создавать качественный код, ожидать эффективного руководства программистами не приходиться, именно поэтому современный код из энтерпрайза и больших компаний в большинстве случаев на порядок хуже, чем код тридцатилетней давности. Я ещё могу понять, когда хипстеры-падаваны, для которых даже джава уже выглядит какой-то палеозойской окаменелостью, молятся на свежие веянья, но для людей взрослых, которые прошли через много периодов смены моды на концепции, и знающих, что фундамент как писался на одной и той же платформе, так и пишется, подобные детсадовские восторги совершенно ненормальны.

[juan_gandhi]

> поэтому современный код из энтерпрайза и больших компаний в большинстве случаев на порядок хуже, чем код тридцатилетней давности

Золотые слова.

Только где вы этих хипстеров берете? Хотя бы и падаванов.

[snowps]

Да мОлодежь падка на всякое модное, а ФП ныне - мода, за которую ещё и платят иногда выше рынка, но, разумеется, для реализации можных закидонов нужно сначала найти какой-нибудь стартап, где инвесторам рассказывают, что-де мы в самом авангарде технологий, поскольку пишем на скале. К счастью, в нормальных компаниях, где пишут серьёзный софт, а не аналитику для биржевых спекулянтов, веб-парсинг и AI для рекламщиков, вся эта мода идёт десом, поэтому машины ездят, самолёты летают, а стиральные машины не требуют 8 гб RAM. :) У вас там в bay area просто рассадник подобных стартапов, поэтому хипстеров и больше, но и у нас тут достаточно попадается.

[juan_gandhi]

Который десяток лет я слышу и вижу вот такую вот чушь, боже мой.

[snowps]

Ну десять лет назад ФП стартапов было очевидно меньше чем сейчас, но, тем не менее, что с этим утверждением не так? Или есть какое-то другое место, где ФП стартапов больше, чем в ваших краях? Народ даже вопросы соответствующие задаёт. :)

[zyxman]

Направлять нужно не на оптимизацию, а на то чтобы сделать продукт.

Я так скажу по опыту, что ядро, которое именно интересная сложная часть работы, делается за менее чем за 10% времени, а 90% времени занимает деятельность уровня сисадмина и машинистки - тупо сидеть и повторять тысячи раз какую-то тупую рутину.

А этап доводки продукта, это вообще сплошная рутина.

Доходит до того, мне сейчас рассказывают, что в какой-то крупной корпорации наняли дата сайентиста, чтобы он им сделал систему с глубоким обучением - он за год ее делает, потом его пересаживают на рутину и он увольняется (ну скучно ему заниматься рутиной), и через 5 и более лет они вдруг обнаруживают что уже надо новое обучение делать, а никто не может разобраться в том что тот сайентист сделал, и они с нуля повторяют этот цикл.

[punk_floyd]

>наняли дата сайентиста, чтобы он им сделал систему с глубоким обучением - он за год ее делает, потом его пересаживают на рутину и он увольняется (ну скучно ему заниматься рутиной), и через 5 и более лет они вдруг обнаруживают что уже надо новое обучение делать, а никто не может разобраться в том что тот сайентист сделал, и они с нуля повторяют этот цикл.

в общем случае в Интернете описания использования функционального программирования выглядят так

"наняли программиста, чтобы он им сделал ... - он за год ее делает на ФП, потом его пересаживают на рутину и он увольняется (ну скучно ему заниматься рутиной, багфиксингом), и через 5 и более лет они вдруг обнаруживают что уже надо ... делать, а никто не может разобраться в том что тот функциональный рограммист сделал, и они с нуля повторяют этот цикл, либо переписывают на не ФП"

[zyxman]

Ну да, так и есть :)

И вообще есть такое ФП, в котором вообще багфиксинг бессмысленен, потому что доказанная верность программы.

[snowps]

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

[juan_gandhi]

Шо вы несете насчет производительности.
Сколько раз я видел, как функциональное решение дает логарифм сложности, а тупое в лоб - линейную.

[snowps]

А не надо исполоьзовать тупые решения и всё встанет на свои места. Или мне про рекурсивный реверс листа напомнить?

[juan_gandhi]

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

[snowps]

Всё, что нужно знать из того обсуждения, - это гигантская разница в производительности методов ФЯ с даже ни капли не оптимизированным традиционным кодом. Соответсвие или не соответствие каким-либо математическим правилам, немутабельности и т.п. - это всё вторичные и ничего не значащие для результирующего кода вещи. То, что функциональщики придают им значение избыточной важности в этом контексте вообще нерелевантно: для задач, где производительность важна, ФП применять нерационально, где не важна - можно, если класс задач удобно описывается его языком (рил-лайф задачи в этот список не входят - в основном это аналитика, AI, machine learning и т.п.) Я не понимаю, зачем каждый раз возвращаться к этой теме и игнорировать очевидные результаты всех бенчмарков. Все (все!) задачи, которые не работают с тяжёлой математикой, на ФЯ работают медленно, это специфика работы massive parallel evaluation на современном железе, её невозможно обойти никакими алгоритмами, а создание dedicated железа под ФП никогда не окупит вложения, это уже тут (и в ЖЖ) сто раз обсуждалось с примерами, ценами и бенчмарками. Что за тяга заставить воевать тупоконечников с остроконечниками? Для каждой парадигмы несть подходящие и неподходящие задачи, зачем всех заманивать блёстками и стразами в ФП, создавая ему ореол непогрешимости и кошерности? Это бессмыслица. К тому же Вы сами подтвердили, что 30 лет назад код был намного лучше - догадайтесь, почему.

[juan_gandhi]

Ой ради бога; все это чушь и демонстрация страха перед неизвестным.

[snowps]

Это демонстрация понимания того, что языки, в которых программист освобождён от необходимости следить за ресурсами, дают на выходе код, который не является универсальным из-за неприлично большого memory footprint и низкой производительности, которая делает невозможным использование этого кода в мобильных или встраиваемых приложениях, а когда он туда всё же попадает, это начинает непосредственно влиять на комфорт пользования устройствами, поскольку вместо работы в течение несколькиз дней, современный смартфон приходится заряжать иногда по несколько раз в сутки, причём железо-то как раз работает хорошо - например обычный не новый смартфон на Андроиде с аккумулятором в полтора ампер-часа при отключении гуглевских сервисов в состоянии проработать несколько дней, а если отключить интернет - то и вовсе до десяти. Это говорит лишь о том, что система даже при всех недостстках архитектуры Андроида написана терпимо и инженерами, а уровень приложений и бэкофисов - чистыми программистами, которые точно так же не желают расширять свои знания в железе, как и те программисты, которых Вы обвиняете в нежелании изучать теорию категорий. Вот только код недопрограммистов в основном не вызывает нареканий по работе, а код любителей абстракций - постоянно.

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

[juan_gandhi]

Боже мой, сколько чепухи в защиту собственного невежества.

[zyxman]

Есть такая штука - функциональная или процедурная абстракция - применяем функцию не вникая в детали ее реализации.

А за верностью интегральной схемы следят другие люди, и они же занимаются поддержкой той интегральной схемы - это называется разделение труда и на этом стоит современная цивилизация.

Про мифичность этого самого якобы катастрофичного падения производительности, вам уже сказал уважаемый juan_gandhi.

[snowps]

Угу, а когда внутри функции трэш - этого в итоге никто не видит и это никого не интересует, что приводит к увеличению трэша со временем. Ту же самую болезнь имеет ООП, и именно поэтому системную часть никсов никто не писал и не будет писать на плюсах, поскольку стабильности и предсказуемости производительности системы сразу же придёт конец. Плюсы, равно как и ФП, удобны для написания больших и некритичных по производительности систем, когда коллектив программистов большой, каждый пишет свою часть и не интересуется работой других, но не более того.

Влад может рассказывать что угодно, но против практики не попрёшь. Поддерживать свои иллюзии по поводу производительности в кругу поддакивающих апологетов ФП можно долго, но к реальности это всё не имеет ни малейшего отношения.

[juan_gandhi]

Это чо было по линку? Костя посчитал, что Котлин быстрее С++, или наоборот, С++ быстрее Котлина?

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

[snowps]

Да тут сообщество функциональщиков будет смеяться над любыми аргументами, где любимая Cкала проигрывает, - проходили сто раз. :) Я эту ссылку привёл потому, что там масса языков и есть исходники для всех тестов, можно посмотреть глазами и убедиться. Костя это лили не Костя - опять-таки нерелевантно, какая разница?

[juan_gandhi]

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

Не, я верю, что человек может потратить месяцок-другой и уделать jit, может быть (а может быть, и нет) в одной конкретной программе. И что? Железный плуг землю портит?

По мне так смешно это все. Соревнование с компьютерами.

[snowps]

Ваша основная ошибка в том, что "бацать" кого-нибудь ФЯ можно только если он не понимает, что плюсов без минусов не бывает, и в том, что Вы варитесь в ограниченном пространстве приложений определённой природы, как раз по причине невыхода за рамки парадигмы ФП по соображениям комфорта. Нельзя написать на ФП хорошую фирмварь для жёсткого диска, ну просто никак, - там просто некого "бацать", а когда продукт, выпускаемый десятками миллионов штук потребует для работы в сто раз больше памяти и в тридцать раз более мощного процессора, производитель жёстких дисков тут же обанкротится, поскольку выпустить такое устройство стоимостью в 50 долларов и иметь прибыль невозможно. И от людей, которые пишут такой софт, требуется гораздо больше, чем от программистов вашей категории, поскольку там одна единственная ошибка может легко привести к банкротству производителя целиком. Если б качество кода, даваемое ФЯ, было высоким, то их бы уже давно применяли в критичных эмбеддед решениях типа самолётов или космоса, но такого нет и в обозримой перспективе не предвидится, и лишь изредка функциональщики с придыханием обсасывают новость, что где-то в недрах NASA начали использовать что-то модное, забыв упомянуть, что оно там на ролях, аналогичных перлу в HPC. :) Don't dream, it's over.

[juan_gandhi]

Почему "Нельзя написать на ФП хорошую фирмварь для жёсткого диска"? Можно, конечно.
Цитирую: "Forth is basically an FP, and it has been used in embedded environments for a long time."

Ну это так, к слову. Вы просто понятия не имеете, о чем говорите. Это как ругать китайский язык, потому что там буковки слишком сложные.

[euthanasepam]

Какие классные таблички! Хотелось бы их в эксель сразу. :-)