>> Повторно прошу привести пример реальной проблемы человечества(ну если оставаться в рамках темы).
Я не знаю, что конкретно для вас является проблемой. Судя по репликам выше, на проблемы человечества вы смотрите свысока (мол гретатутберговские они), сами вы ни о каких проблемах не рассказываете, что вас побуждало писать про «с удовольствием в него впишусь» я тоже не понимаю. Возможно вам банально не хватает драйва или каких-то новых «открытий», а «проблемы человечества» лишь психологическое прикрытие.
Для меня основной проблемой является полное господство паразитов, которые постоянно мне указывают, что по их мнению я обязан делать. И если не сделаю — штраф, арест, тюрьма и т.д. Какая может быть польза от почти любой моей деятельности в таких условиях? Одна единственная — отдать им налоги во всех местах, где я что-то сделал. Всё остальное есть лишь поддержание меня в состоянии, достаточном для дальнейших выплат хозяевам. И строго по теме статьи — именно технологии используются для достижения показанной мною ситуации. Чем больше технологий, тем туже удавка на шее.
Но важно дли для вас это? Судя по репликам выше — скорее всего нет. Иначе вы давно бы сами давно написали что-то вменяемое место вопросов из серии «ну какие вообще могут быть проблемы?».
Всё зависит от того, что для вас важно и как вы расшифровываете свои собственные слова:
Лично я, если будет какое-то начинание, которое принесет реальную пользу человечеству, с удовольствием в него впишусь, по мере сил и способностей.
Если вам никто не мешает и вы не чувствуете никаких угроз своему будущему, то становится непонятно, зачем вы писали выше процитированные слова? Зачем ответили на реплику о том, что местные читатели так же ничем не обеспокоены и пребывают в вечном блаженстве?
Любой, кто знает о своих личных проблемах, способен сам себе ответить на поставленный вами вопрос. Почему не способны вы? Вы стесняетесь признаться, что ваши проблемы завязаны на проблемы общества? Вы боитесь получить виртуальный минус за реплику? Вы так сильно зависите от виртуального «отношения» к вам посторонних людей? Или почему вы задаёте такие вопросы? С такими очевидными ответами.
Похоже, что автор рассматривает собеседование именно с точки зрения подбора «своих людей» в «свою команду». Но бизнес — это не ваше, и это даже не моё, это чужое. Просто совсем левое.
Поэтому не стоит давать советы бизнесу. Хотя пытаться влиять на принятие решений, выгодных грамотным специалистам, безусловно стоит. И да, вот такими статьями тоже. То есть неявно идёт банальная война за деньги и минимум напряжения между бизнесом и специалистами. Специалисты, вот как в данной статье, описывают своё видение, свои предпочтения, ну а бизнес почитывает и делает выводы. Или не делает, что случается чаще. Хотя дефицит кадров бизнес очень волнует, но ведь всегда есть очень простой способ — купить проджект манагера (начальника отдела или ещё как-то похоже) и свесить все остальные заботы на него. Особенно в больших конторах. И этот манагер уже будет дрючить испытуемых исходя из личного опыта, который, возможно, включает прочтение подобных статей. Но часто не включает. Просто потому, что реальность требует много дешёвых кодеров, ну а манагер вынужден это чутко улавливать. Вот и методы отбора у него вырабатываются соответствующие. И это уже не выбить из такой головы.
Поэтому я бы рекомендовал специалистам «познать цзен». То есть, имея опыт, вы легко отличите манагера от хорошего специалиста, либо мальчика-джуна, посланного вас собеседовать по техническим вопросам менее грамотными товарищами (включая сеньоров). Просто вспомните, как вы сами участвовали в подобных действах. Там всё тривиально — конторе нужен продукт, продукту нужны кодеры, манагер пинает HR, те присылают толпу, далее нужно отсеивать, но понятно, заниматься этим лень, поэтому и посылают начинающего, но умело отвечавшего на собеседовании на технические вопросы. Ну и начинающий затем выдаёт своё ценное мнение наверх, этому мнению наверху не верят, ибо знают, что начинающий, пишут соседям, мол побеседуйте тоже и т.д. В общем — типичная конторская деятельность по перепихиванию работы с себя на окружающих. И где в такой суете место грамотным вопросам? Правильно — нет его.
Бывают конторы, где специалистам верят, поскольку от них всё зависит, но и там «идеальный отбор» отсутствует. Если всем рулит тим-лид, то вышестоящий начальник свешивает всю процедуру на него, ну а он уже подбирает народ под себя. Не по знаниям, не по «полезности для команды», а именно под себя (можно считать, что по сути он думает «команда — это я»). Да, не все люди идеальны. Хороших спецов я на собеседованиях встречал немного. Бывали интересные люди, но всегда были некие манагеры, либо те же мальчики-джуны, либо ещё какие-то специфические условия.
Какой из этого вывод? Да просто расслабьтесь. Не нервничайте по поводу глупых вопросов и всего того, из-за чего вы привыкли нервничать. Ну да, мальчик-джун очень хочет проявить себя и задаёт вам олимпиадные задачки, про которые он где-то читал. Ну так что в этом плохого? Он и обязан это делать, просто в полном соответствии со своим неокрепшим разумом и недостаточным опытом. На что тут жаловаться? На то, что вы не можете вспомнить, какой метод нужно дёрнуть для решения поставленной джуном задачи? Ну так и скажите — я хочу поглядеть документацию по такому-то классу, и через 5 минут отвечу. Если вы боитесь, что джун потом напишет негативный отзыв — не стоит нервничать! Вышестоящий начальник хорошо понимает, кого и куда он послал, поэтому решать всё равно будет субъективно, лишь частично опираясь на отзыв джуна. То есть просто действуйте спокойно, как вы привыкли, и пусть джун под вас подстраивается и потом покрывается, когда вы ему возражаете. Ну ведь просто же!
Так что — расслабьтесь и не нервничайте. Но к собеседованиям, безусловно, готовьтесь. То есть если бы ко мне пришёл якобы сеньор, но поленившийся освежить в голове хотя бы основное по списку указанных в вакансии технологий — ну очевидно же, что он привык к лёгкой жизни на старом месте, не учил новые технологии, не готов банально почитать о том, чем придётся заниматься на новой работе. Именно поэтому возникает вопрос о его проф.пригодности. Не из-за каких-то субъективных факторов, а именно из-за неготовности чуть-чуть напрячься. Потому что новое место работы — это всегда некоторое напряжение, связанное с необходимостью учиться тому, чего на прошлой работе не было.
Но даже моё возражение в куче контор никак бы не повлияло на субъективный выбор кем-то другим, так что опять же — расслабьтесь, не нервничайте, не попали в одну контору — попадёте в другую. А все эти собеседования — субъективная суета. Напрягают лишь если буквально жрать нечего, потому что денег нет. А во всех остальных случаях — не парьтесь. Но только при условии, что вы реально способны учиться и реально обладаете ценными опытом и знаниями.
>> К сожалению сейчас среди таких начинаний всё больше гретотунберговские заявления
Проблема в том, что заявления имеют под собой основания. Это называется манипуляция. То есть основание реальное и точно так же реальны связанные с ним проблемы, поэтому можно предложить порешать эти проблемы, ну а взамен получить лояльных граждан, занятых спасением белых медведей в антарктиде (и да, в антарктиде реально катастрофическая ситуация с белыми медведями — ни одного не осталось).
Для нас же эта проблема означает сложность привлечения внимания к реальным, то есть более значимым проблемам.
Что будет в будущем? Там обязательно исчезнут какие-то виды животных, и даже обязательно исчезнут какие-то нации (растворятся, ассимилируются, и да, некоторых отгенцидят), но что если само человечество перестанет существовать? То есть отвлекая людей сегодня на белых медведей реальные пастухи не дают им думать именно об общих, более важных проблемах. Но как отделить «правильные» проблемы от «манипулятивных»? В этом сложность.
Подходы к решению есть, но они комплексные, требуют вовлечения человека, но ведь у человека есть важное дело — надо срочно спасти котёнка! Он же есть хочет! А как мило он выглядит! И опять человек уходит в ложном направлении.
Вот такие проблемы надо бы порешать, если предположить, что мы вовлечены во что-то важное.
Судя по комментариям — у местных юзеров всё в шоколаде. Ну просто из ушей уже лезет. И ничего им более не надо. Будущее? Да ладно, лично у меня всё будет хокей! Какой гуманизм? О чём вы? Это когда я вынужден делиться с бомжами? А не пойти ли вам…
В общем — удивительные персонажи живут рядом с нами. Ни гуманизма, ни проблем. Один сплошной шоколад.
Если вы не согласны, что написание независимых модулей, состояние которых не влияет друг на друга, то можете подробнее рассказать, как это получается?
У меня к вам просьба — прочитайте процитированный выше ваш текст и найдите в нём смысл. Я не нашёл.
ФП так называется не для того, чтобы присвоить чьи-то заслуги (как я уже сказал), а чтобы был общий понятийный аппарат.
Общий понятийный аппарат формируется не случайным образом, а задаётся авторами аппарата. Так вот авторы исходили из применимости к программированию абстрактного понятия «математическая функция». Вы же выше написали, что якобы функциональное программирование, это про чистые функции, не меняющие состояние вне самих функций. Но нет, я ещё раз подчеркну — это не так, не про внешнее состояние речь, а про попытку применить математические абстракции в программировании.
Да, от математической абстракции можно прийти к чистым функциям ФП, но это лишь логическое следствие, не являющееся изначальной основой подхода. Поэтому я и написал, что вы вводите людей в заблуждение.
Ну так вы же можете менять внешнее состояние, только не напрямую. А эта индирекция позволяет вам иметь все плюсы чистоты, и оставаться при этом приложением которое может что-то полезное сделать.
Я писал про запрет, а вы мне про «на самом деле, если долго и нудно копать, то запрет можно обойти». Я в курсе, что затрата приличного количества пота иногда помогает сделать что-то полезное, но про изначальный запрет-то зачем забывать? Причина пота — запрет. Он есть. И если он есть, то уже не важно, в наличии ли какие-то решения «через задний проход» или они отсутствуют, ведь главное — запрет есть.
Я у программистов на низкоуровневых языках несколько раз спрашивал зачем им в офисах перила, двери в лифтах и т.п.
И вашему знакомому наверняка уже отвечали — перила есть не везде, а лифты — и подавно. Потому что экономически невыгодно везде ставить перила и лифты. И да, иногда невыгодно потому, что они реально мешают. Ну и точно такая же ситуация с уровнями языков. Правда здесь вы попутали уровни с дилеммой «ФП или не ФП», то есть опять придали ФП несуществующую в реальности роль якобы «высокого уровня», ну да я к такому уже привык, поскольку в разговорах со сторонниками ФП всегда встречаю что-то подобное, когда вместо ответа на конкретные факты мне начинают рассказывать какие-то сказки, как вот например про уровни и т.д.
Когда люди совершают ошибки с инструментом, хороший путь — починить инструмент. Плохой — ругать людей, и говорить, что они плохие и неправильные.
Вы как наши правители — ну вот надо им с нас денег содрать, вот они и доказывают, что «это хороший путь». И плевать им на все возражения. Просто потому, что реальная причина не «хороший путь», а банально денег хотят.
Инструмент (язык программирования в частности) нужно не чинить, а совершенствовать. И если у вас совершенствование ассоциируется с запретами, то вы неправы. Запрет — это примитивнейший способ устранения проблемы. Он почти всегда работает неэффективно. А правильный способ устранения проблемы — сделать совершенное решение. То есть такое, в котором не запретами добиваются нужного результата, а при при помощи учёт множества важных деталей. Поэтому не становитесь в позу нашего правительства, не запрещайте всё на свете, это по вам же потом ударит.
Можно примеры, какие альтернативы я забыл и какие другие ошибки могут произойти, с которыми ФП ничего сделать не может, а какой-то другой подход может
Ну возьмите хотя бы так любимые вами рекурсии. В императиве их обычно реализуют в виде циклов, где есть начало и конец (стандартная конструкция for), а в функциональных языках с их ленивостью предсказание результата рекурсивных вызовов, да ещё с бесконечными списками, внезапно, становится головной болью.
Вообще претензий к ФП, если серьёзно взяться, можно наковырять немало, так что здесь вы просто закрываете глаза на то, что в общем-то обязаны и так знать, являясь сторонником ФП. Собственно все отличия ФП от императива даются не бесплатно, а потому все они имеют минусы, но вы вот мне (отнюдь не стороннику ФП) задаёте вопрос — а какие минусы имеет мой любимый подход? Так он же ваш любимый, а не мой! Но я, тем не менее, вам отвечаю. Только вот у меня возникает вопрос об объективности вашего подхода. То есть вы не видите минусов и видите лишь одни плюсы. Прямо так выше и написали. Но объективно ли это?
Что-то мне подсказывает что вы несколько предвзяты
Ну я вам уже отвечал выше — постоянно сталкиваюсь со сторонниками ФП, которые упорно талдычат про сплошные плюсы их любимого подхода, но никогда ни один из них не соглашался, если я им говорил о минусах. Всегда мне либо рассказывали сказки про «ну есть же возможность обойти», либо вообще уводили в какие-то не относящиеся к вопросу дебри. Вот поэтому я и стал слегка предвзятым.
Функциональное программирование родилось как математическая абстракция, в которой (так привычно для математиков) всё было именно функцией. То есть функциональное — от слова функция. Не притянутое за уши к ФП понятие неизменности состояния (глобальных переменных), которое было введено задолго до ФП в теоретических работах именно по императивному программированию, а именно упор на функции, на подход «от математики». А вся эта идеологическая шелуха про «ФП позволяет писать надёжно» и тому подобное, есть следствие глубокого непонимания сторонниками ФП всего остального мира, связанного с созданием программ.
В целом — не надо вводить людей в заблуждение, указывая на некоторые случаи, когда неизменное состояние внешних переменных может быть полезно. И тем более — ни в коем случае нельзя приписывать это «достижение» исключительно ФП. Последнее может утверждать только человек, крайне поверхностно знакомый с альтернативами (либо вообще о них не знающий).
Программирование сложнее примитивного деления на «мне нравится ФП» и «мне не нравится ФП». Сторонники ФП по необразованности, к сожалению, часто ставят себя выше остальных, и всё лишь потому, что они обнаруживают в ФП лишь некоторые возможности, которые давно есть в других языках. Ну и в результате выставляют себя глупцами, да. А как ещё назвать людей с самомнением, да к тому же не желающих изучать альтернативы?
Ну и до кучи — возможность изменять внешнее состояние полезна. И если язык позволяет эту возможность использовать — это хороший язык. А если программист при использовании этой возможности не умеет избегать ошибок — это плохой программист. Сторонники ФП нашли выход из такой ситуации — запретили менять внешнее состояние. Просто потому, что считают всех плохими программистами. А как иначе объяснить запрет? Ведь если мы исходим из предположения о грамотном использовании инструмента, то и запрещать ничего не нужно, ведь грамотный пользователь и сам знает, где очередные грабли лежат.
Поэтому речь может идти лишь о наличии альтернативных подходов к разработке. Вот просто в мире есть альтернативы, и всё. Хочешь — пользуйся, не хочешь — не пользуйся. А утверждать, что якобы одна из альтернатив чего-то там делает за программиста — ну бред же. Ошибок можно наворотить бесконечное количество в любом языке. А указывать лишь на один класс ошибок (из миллионов) и при этом гордо задирать нос, мол вот мой любимый подход (ФП) какой прекрасный, это признак очень ограниченного интеллекта. То есть — не надо так себя вести. Даже неявно, когда, как например в данной статье, автор просто забыл про все альтернативы и опять увлекательно нам рассказал, что он недавно узнал, как некоторые языки позволяют отловить один единственный класс ошибок. А все остальные ошибки кто ловить будет?
>> Мне больше нравятся тесты наподобие «если я передаю А, то мне вернётся Б», нежели те, в которых проверяется, а был ли вызван такой-то сервис, с помощью того же Mockito.verify (необходимость таких тестов я не обсуждаю).
Тесты, как и вообще всё программирование, это инструмент. Может нравится молоток? С точки зрения эстетики, наверное, но оценивать его нужно с точки зрения способности забивать гвозди. И если гвозди забиваются нормально — молоток хороший. Здесь нет места эмоциям. Просто работа молотком. И всё. Хотя по началу (по молодости) из-за угла может показаться некий ореол романтичности, но это именно по началу.
Вообще, проверка «был ли вызван сервис» бывает разная. Например — нужно уведомлять внешнего клиента о произошедшем событии, тогда очевидно, что это важная часть функционала и вызов сервиса является критичным. Но бывает и по другому — внешний сервис просто даёт какую-то информацию, а потом, обработав эту информацию, процесс выдаёт какой-то свой результат. В таком случае проверка вызова сервиса бессмысленна, потому что нам важен результат, а не какие-то промежуточные действия. Если результат не сходится с ожиданиями — это критично, а был ли там в середине какой-то вызов — совершенно не важно, потому что архитектуру могут переделать буквально через месяц (и такое бывает) и все тесты «про вызов» пойдут псу под хвост. А вот если проверяли результат — переделывайте свою архитектуру сколько хотите, тест всё равно будет полезным.
Регулярные выражения это специфическая функция из предметной области «работа с шаблонами в произвольных последовательностях». То есть если стоит задача работать с последовательностями, то логично написать на универсальном языке некую библиотеку, которая и будет выполнять основные функции по работе с последовательностью. Далее эту функцию можно напрямую выставить в виде API в том же языке, на котором она разрабатывалась. Это просто, быстро, эффективно с точки зрения работы с дополнительной логикой, с которой универсальный язык легко справляется.
И второй вариант — сочиняем DSL. Ну вот сочинили, и прикрутили к нему всё ту же выше показанную библиотеку. Но в добавок сочиняем ещё и правила текстового взаимодействия с этой библиотекой. Ладно если почти весь требуемый функционал хорошо ложится именно на регулярки, но если где-то требуется слегка отличающаяся от шаблонов логика? Сразу получаем очень негибкое решение, нацеленное на очень узкую группу задач.
А теперь сравните затраты пользователей. Они учат какой-то новый язык (DSL), а внутри в любом случае учат эти самые регулярные выражения. То есть учатся два раза. И что мешает учиться сразу в сторону универсальности? То есть вместо DSL учим JavaScript. При чём не весь, а только простейшую логику — условные операторы, циклы, функции. А внутри пишем что-то вроде «var result=apply('[1-9,a-z]','Long string from our specific domain')». Можно написать это чуть короче на неком вымученном DSL, но зачем? Что это даст? Объяснить, что «сюда суёшь регулярку, а сюда последовательность» в случае того же JavaScript очень просто, так зачем тогда DSL? Что он даст пользователю?
Начинающий программист удивляется встрече с объективной реальностью:
Мне не нравится, что ни одна функция не написана в стиле ФП
Потом вот так:
не люблю тесты
Или вот так:
Испльзуя mock'и, я сумел протестировать код
И наконец вот такой перл:
С другой стороны, такой подход заставляет писать столько кода, что от него сразу хочется отказаться
В целом в статье видим предвзятый взгляд начинающего разработчика на слегка неидеальное решение другого, более опытного разработчика.
Собственно указание на ФП в самом начале уже прямым текстом говорит об отсутствии опыта работы с императивными подходами, иначе фразы типа «мне не нравится без ФП» просто не встречались бы. Но даже если забыть про ФП, то заявление «мне не нравится», не подкреплённое аргументами, выглядит как типичное недовольство не разбирающегося в проблеме, но считающего, что всё, что он видит на работе ему должно нравиться.
В тексте программы, конечно же, используется новомодный синтаксис, скрывающий от разработчика тип используемого объекта. Это всё привычно для разработчиков на JavaScript или на чём-то другом плохо типизированном, но в Java это выглядит страшно. Хотя, к сожалению, такую возможность всё же включили в какую-то из последних версий языка. Но тем не менее, привычка писать в таком стиле очередной раз показывает — перед нами самый что ни на есть начинающий разработчик на Java, скорее всего пришедший из мира редко используемых в промышленной разработке языков, что в свою очередь намекает на отсутствие опыта в промышленной разработке вообще.
Ну и собственно по смыслу проблемы. Автор видит простенькую неидеальность и пытается сделать код «совершенным». Это тоже типичная проблема новичка. И решает её новичок в таком виде, про который он сам говорит — «такой подход заставляет писать столько кода, что от него сразу хочется отказаться». Ну что-ж, полезная самокритика. Но вот результат всё же не впечатляет.
Почему результат не впечатляет? Очень просто — автор привык оптимизировать по сложно формализуемому критерию исключительно учебные кейсы для ФП, а потому автоматически применяет этот навык в более серьёзной разработке. В результате у него получается, как он сам отметил, нагромождение всего на свете.
Как исправить ситуацию? Всегда самый эффективный способ улучшения находится на уровень, а то и два, выше примитивов непосредственно кода. То есть алгоритм решения проблемы никак не зависит от любого языка программирования, но привычка новичков уделять внимание «красоте кода» (в их очень субъективном понимании) заставляет их строить то самое нагромождение, от которого сам же автор в конце концов плюётся.
Не надо переходить на уровень кода, когда ваш алгоритм глупый. Просто не надо.
Почему алгоритм глупый? Потому что автор даже не пытается понять, а что реально происходит в программе. Он видит только код и его субъективную «красоту». А что этот код делает?
Можно предположить, что объект типа Product заполняется данными. И точно так же можно предположить, что объект типа Product служит источником для заполнения каких-то дополнительных объектов. Это два архитектурно принципиально разных подхода. И решение усмотренной автором небольшой неидеальности должно в первую очередь зависеть именно от того, в каком направлении движутся данные. А на более высоком уровне всё зависит от того, зачем вообще эти данные куда-то движутся. В результате скорее всего весь рассматриваемый автором метод вообще не нужен, например потому, что итак уже содержащий данные объект типа Product (во втором варианте), можно направить в то место, где эти данные каким-то образом потребляются. Но повторюсь — автор не видит ситуацию «в большом», то есть вместо понимания ненужности условного дома, он старательно штукатурит его стены, что является самым главным признаком начинающего разработчика. Никакие зазубренные знания синтаксиса не помогут вам сделать глупость умной. Потому что глупость находится на несколько уровней выше в иерархии абстракций, по сравнению с синтаксисом языка. И вот это понимание затмевает зубрёжка синтаксиса, желание видеть очень условно понимаемую «красоту», основой для которой являются примеры из ФП, часто не имеющие к реальной жизни практически никакого отношения (да, всё те же сортировки, перестановки, операции над структурами). Погружаясь во все эти сортировки человек видит условную «красоту» низкоуровневых алгоритмов, а собственно зачем эти все алгоритмы применяются — ему совершенно по барабану. Ну и в результате имеем глупость.
Поэтому, дети (начинающие программисты) — зрите в корень! Не ведитесь на гламурный синтаксис и мнение функциональных программистов о «некрасивости» кода без функциональной шелухи. Думайте о главном. И даже больше — думайте, что такое главное. И может быть в итоге вы станете реально хорошими (полезными для проекта) разработчиками, а не поставщиками гламурной чешуи под рекламным называнием «красивый код».
>> Здесь ключевым моментом является компактность представления знания
Не компактность, а понятность. Это очень разные вещи. Компактность достигается выкидыванием из языка всех конструкций длиннее одной буквы, а понятность достигается структурой языка и форматированием. Вот последнее для некой предметной области будет либо очень нетривиальным, либо элементарным. Простые варианты банально вызывают некие библиотеки, которые и реализуют нужный функционал, но стоит захотеть расширить набор функций, как придётся всё реализовывать вручную на недо-языке. Если же мы встраиваем в язык возможности для программирования сложной логики, то сразу получаем относительно сложный для неподготовленного юзера универсальный язык программирования.
В целом дать пользователю какой-нибудь JavaScript и написать для него библиотеки будет много проще, чем возиться с DSL. Либо если по сути нужно заполнять какие-то шаблоны (выше пример с играми), то здесь вполне подходит обычное решение на GUI — просто собираем данные для шаблона и выполняем над ними необходимые действия. Сложной логики здесь никакой, а потому требования к пользователям низкие. Но если помимо шаблона нужна сложная логика игры — вот и приехали, придётся переходить на универсальный язык программирования.
>> На деле мы видим зависимость от уровня языка и производительностью разработки на нем
Уровень языка никак не относится к делению на DSL и универсальные языки. Это всё высокоуровневые языки программирования. Но в DSL обычно присутствует некий набор функций, характерный для предметной области. То есть отличие двух высокоуровневых языков, один из которых DSL, а другой — универсальный язык, состоит в том, что в DSL сразу присутствует специфический функционал, который в универсальном языке может быть добавлен в виде библиотеки, но отсутствует в дефолтной реализации.
>> По хорошему юзеру это понимать и исправлять.
Что бы юзер понял, ему нужно всё объяснить в знакомых терминах. Если ошибка будет выдаваться в виде «в строке Х около символа на позиции У присутствует синтаксическая ошибка», то юзер долго будет пытаться понять о чём вообще речь. Но даже при таком простом описании ошибок уже сложно как-то передать проблему в структуре данных, а не в синтаксисе. Например — в предметной области есть деревья, пользователь их описывает на DSL, с точки зрения синтаксиса всё корректно, но вот структура дерева кривая. Теперь вопрос — сколько видов кривизны структуры дерева может быть? Не отвечайте сразу, сначала добавьте в модель зависимости между узлами дерева, а потом попробуйте описать это всё коротко на DSL.
>> даже на DSL можно описать крайне громоздкую и сложную логику, но на языке общего назначения та же самая логика выглядела бы еще хуже.
Как раз наоборот. DSL не содержит никаких хитрых универсальных логических конструкций. Все хитрые универсальные логические конструкции давно включены в универсальные языки программирования. И если вам нужна именно сложная логика, то именно на универсальных языках она реализуется проще всего.
Либо вы путаете универсальную логику с заранее подготовленными решениями для конкретной предметной области. Тогда я выше уже говорил — на универсальном языке просто реализуем необходимые библиотеки и далее обеспечиваем к ним доступ пользователей. Доступ обеспечивается тремя способами — (1) обычный GUI, (2) DSL и (3) напрямую на универсальном языке. Способ №1 очень прост и давно отработан, но там сложно с добавлением логики, поэтому приходится делать решения со скриптовыми языками, имеющими доступ к введённым пользователем данным. Способ №2 отличается от №1 тем, что заставляет пользователя самостоятельно представлять в голове всё то, что в №1 ему даётся в GUI, а в остальном логика работает идентично, кроме чисто субъективных отличий DSL от скриптового языка. Ну и способ №3 отличается от №2 тем, что вообще нет необходимости делать ничего, кроме написания библиотеки. То есть способ №3 самый экономный. А раз уж мы знаем, что пользователь в любом случае будет учить язык программирования, то пусть уж учит универсальный и дёргает оттуда библиотеку.
Из-за отсутствия избыточных конструкций всего несколько строк на DSL могут реализовать довольно сложный функционал, что приводит к положительным следствиям: увеличивается скорость разработки, сокращается количество ошибок, упрощается тестирование системы.
Все эти плюсы довольно мифические. Скорость, ошибки и прочее улучшаются только одним способом — нахождением общего решения проблемы и последующим программированием решения. Всё остальное — паллиатив.
Выход видится в создании DSL для построения DSL
Нет там выхода. Когда вы просто разделяете строку на слова, используя пробелы в качестве разделителя — это одно. Но когда вы пытаетесь понять, а потом исправить, всю ту галиматью, которую нарисовал вам юзер, и при этом не в виде строки с простейшими разделителями, а в виде очень нетривиальной структуры данных (да, предметная область такая), то одно вылавливание потенциальных ошибок юзера выливается в мега-квест, я уж не говорю про проблемы всей остальное работы со сложными структурами данных.
Тут либо всё упрощать, что сразу убивает предметную область (или по другому — делает DSL бесполезным), либо долго и нудно сочинять нечто сложное и по сути решающее задачу за пользователя.
Где-то посередине иногда можно найти приемлемые варианты, но это редкость. Если всё просто, то язык не нужен, легче всё подать в стандартном графическом стиле, а если сложно, то..., как бы это не было удивительно, всё именно сложно.
Хотя можно пообсуждать примеры реально используемых DSL. Правда всегда это использование очень узкое, никому кроме рассказывающего неизвестное.
>> Нет причин, по которым эта информация должна соблюдать локальность или вообще что-то знать о пространстве.
Предположим, что существует некий процесс (для упрощения — человек), который действует с учётом той или иной информации. Что будет, если за миллиарды световых лет от процесса произойдёт интересное событие? По вашей гипотезе информация будет получена процессом мгновенно. Но тогда процесс начнёт менять физическое состояние как себя, так и окружающего мира, в соответствии с поступившей информацией. В итоге к моменту поступления физически наблюдаемых изменений о произошедшем далёком событии мы давно уже забудем о нём, а процесс уже будет обрабатывать очередное событие, о котором в физической реальности станет известно лишь через миллиарды лет.
То есть в ответ на сверхсветовую скорость передачи информации мы получаем сверхсветовую скорость реакции на физические изменения. Если процесс управляет силой притяжения, то сила притяжения отреагирует на удалённое событие мгновенно. Возможно ли такое без нарушения известных физических принципов?
>> В КМ изначально не предусмотрено таких вещей как состояние системы не в контексте измерения
Но само-то состояние допускается? То есть до измерения. Мы можем не знать состояния, но его наличие, по сути, оспаривается теориями вроде запутанности.
>> Нет, он не взаимодействовал ни с чем. Фотон «одноразовая» частица. Как только он отдает информацию о своем состоянии куда-то, он перестает существовать.
То есть фотоны пролетали заметное расстояние без столкновений с молекулами воздуха? А потом без столкновений с молекулами оптических приборов? Сразу на некий приёмник, где не взаимодействовали ни с какими частями приёмника, кроме собственно той части, которая порождает некий наблюдаемый со стороны эффект? Выглядит как некая магия.
>> В природе практически нет легких задач для КМ.
Не только для КМ. Гравитация с теорией струн ничуть не проще. Вроде Ли Смолин писал о теории струн примерно такое — они все ходили с огромными чехлами, в которых хранились листы формата А0, на которые с трудом умещались все необходимые формулы для обсуждения на текущем заседании.
Проблема сложности убивает науку. Когда о смысле происходящего догадываются лишь 5-10 человек на планете, вряд ли стоит говорить о научном подходе с его верифицируемостью. Группа в 5-10 человек студентов и одного «идейного лидера» скорее напоминает секту, из которой потом выйдут эти 5-10 «идейных» проводников учения, между которыми и будут продолжаться все обсуждения, но строго в направлении, каким-то образом отвечающем желаниям участников секты, а не науки.
И есть другая сторона проблемы — миллионы публикаций. Правда опять — всё на узкие темы, значит опять по каждой нужны те самые 5-10 экспертов, а все остальные просто никогда не читают подавляющую часть опубликованного.
Но тем не менее — ваш ответ для меня вполне познавателен, за что вам отдельное спасибо (в карму не могу, возможность отключили).
это изолированная от мира система, которая в принципе может превратиться в момент измерения во что угодно, при условии что это что-угодно не нарушает множества действующих законов сохранения.
Проблема в протяжённости.
То есть электроны разлетаются на большое расстояние, а потом, превращаясь по вашему «во что угодно», они в двух очень далёких точках вселенной оба одновременно обеспечивают выполнение законов сохранения. Но взаимодействие же произошло в одной точке вселенной, а информация об этом (для соблюдения законов сохранения) передана мгновенно на очень большое расстояние, после чего можно измерять вторую частицу, которая мгновенно ответит нам, что её состояние вполне конкретное, которое не было известно до взаимодействия второй частицы за миллиарды световых лет от первой.
Хотя в целом — да, не понимая (как я) квантовой механики совершенно непонятно, почему все эти спины и прочие попугаи не являются свойством изначально созданной системы из двух электронов, но должны с чего-то «внезапно проявиться» именно в момент взаимодействия. Почему их не может быть до взаимодействия? Что этому мешает? Как я понял, в каких-то случаях нарушается некое неравенство, выведенной неким Беллом, и из этого почему-то следует, что система из двух электронов принципиально не может иметь характеристику типа «спин» до момента взаимодействия. И даже больше — до момента взаимодействия с чем? В опыте на Тенерифе фотон вообще летел через воздух и бесконечное количество раз взаимодействовал с молекулами воздуха. И почему он всё это время не мог определиться со спином?
В общем — да, без понимания квантовой механики возникает миллион вопросов, и не появляется ни одного ответа. Какой-то сумрачный и непредсказуемый мир с отсутствием (понятных) причинно-следственных связей.
Да и подход к этому миру тоже сумрачный — в учебнике вводится некое уравнение (волновая функция) и предлагается поверить, что всё на свете описывается именно им, просто потому, что в экспериментах всё складывается так, что предложенное уравнение вроде бы сходится с результатами экспериментов. Но какого вида эксперименты? Какие параметры измерялись? Как измерялись? Что за адская математика во всём этом участвовала?
В целом, конечно, есть аналогия с выводом формулы для закона всемирного тяготения (её тоже взяли с потолка, просто потому, что она подходит), но там неизвестное одно — сила притяжения, а в квантовой механике какое-то огромное количество попугаев, каждый из которых получает смысл лишь в неком математическом контексте, то есть он «подходит» при подстановке в какие-то страшные формулы, а более смысла в попугае никакого не прослеживается (наглядный пример — очарованные частицы). В целом возникает вопрос — о чём вы вообще? Может есть другая математика, попроще? Почему её никто не ищет, но лишь увлечённо городят всё более страшные формулы?
Хотя ответов, понятно, не дождёшся. Но физику (и её математику) учить подробно времени нужно очень много.
В математике есть случаи, когда можно придумать проверку гипотезы, то есть произвольно взять некий результат, а потом посчитать с учётом зависимостей значения других переменных. Так вот эти другие переменные могут авторитетно заявить — всё сходится, вы выбрали правильное значение. Примерно так же действуют физики — предполагают нечто, а потом проверяют. И если проверка показывает, что всё сходится, то физики считают, что именно вот так вот и устроен мир. Только есть одна проблема.
В математике, когда по другим переменным проверяют предположение, всё тоже может сходиться, но если возникает возможность прямо (без проверок по косвенным данным) вычислить искомое значение, то оказывается, что оно не равно предполагавшемуся. И если копнуть глубже, то окажется, что все проведённые проверки действительно должны были сойтись, но только в определённых случаях, которые как раз и попадают в область доступных для вычисления параметров.
Немного по другому — бывает проще проверить что-то косвенным образом, потому что вычислять напрямую не хватит никаких вычислительных мощностей. Но если всё же проверить задачу на достижимых для прямого вычислительного эксперимента значениях, то окажется, что не смотря на подтверждение со стороны косвенных проверок, предполагаемый результат не сходится с вычисленным напрямую.
Не знаю, как там в деталях в квантовой физике, но точно знаю, что там полно той самой математики. И математика может вот так вот легко обмануть, если мы будем верить проверке гипотез экспериментом.
Зачем люди сами создают себе проблемы? Потому что гуглы им сказали «надо»?
Что такое учёт активности? Это в первую очередь самостоятельное планирование. Не ожидание счастья от гуглов или китайцев, это самостоятельная работа. Да, работа, которую многие делать просто не хотят. Но стоит заметить, что подумать у вас займёт ну максимум пол-часа, а потом просто выполняете придуманный план и тратите на это суммарно в день минут 10, ну ладно, пусть 15. И вот это вот вам делать лень? Нужен какой-то гугл, что бы вас за задницу постоянно брал и подталкивал? Тогда очевидно — не надо вам никакого фитнеса и прочего, потому что это самообман. То есть вы надеетесь, что кто-то за вас сделает вам красиво, без вашего минимального напряжения (10-15 минут в день). Ну да, без напряжения, да сразу в рай. И вы в это верите. Ну молодцы, что сказать.
Про шаги. Считать их почти всегда — бессмысленно. Есть карты, на них есть линейки, померить расстояние до работы — 5 минут затрат, но зато потом все годы вашего хождения на работу вы всегда будете знать, сколько километров вы прошли. И вот потратить 5 минут один раз в несколько лет — кого-то напрягает…
Про «я много бегаю по делам». Здесь примерно то же самое. Вы просто фиксируете время вне офиса. И всё. Ваш средний темп ходьбы практически никогда не меняется, поэтому время вам даёт очень точную оценку затрат калорий на ту же ходьбу. Вам неохота каждый раз разглядывать часы и запоминать время выхода из офиса? Так ничего страшного не случится, если вы будете это делать хотя бы раз на 10 выходов из офиса. Потому что важна активность в среднем, а не лишний километр в конкретный день. И вот среднюю цифру вы получите легко, даже забывая её замерять 9 раз из 10. Ну а далее — тривиально, вот она, вся ваша активность, выраженная средним количеством времени вне офиса. Точнее никакие гуглы и мега-супер-убер-девайсы вам не скажут. Обычно наоборот — точность девайсов просто никакая.
Про всякий фитнес. Вам лень считать количество отжиманий? Ну ужас же! Вам не хочется почитать, что такое программа тренировок? Вам лень скачать готовую примерную программу? Вам в лом самостоятельно учитывать минимальный набор простейших показателей? Ну зачем вам тогда фитнес? Что бы гугл сказал, «ты молодец»? Он вам обязательно это скажет, для этого фитнес совершенно не нужен. Это бизнес по продаже эмоций, так что они вам обязательно улыбнутся, лишь бы платили.
Про бег. Один раз померили расстояние по карте и далее всего лишь смотрите на показания пульсометра. Но даже пульсометр становится ненужным, когда привыкаете к определённому темпу. В итоге пульсометр лишь иногда таскаете для контроля, выявления улучшений/ухудшений. Вот и всё. Или вы мировой рекорд собрались ставить? С помощью гуглов что ли? Ну смешно же.
В общем — куда ни плюнь, везде всё очень просто, и никакие подсказки от столь любимых некоторыми гуглов не нужны. Либо вы сами определяете свою жизнь, либо вы бегаете как дурак по указанию каких-то дятлов из гугла, которые на самом деле самые обычные люди, которым лень делать много качественных продуктов, которые воюют со своими начальниками за безделье и много денег, ну а продукт (и тем более — вы) для них где-то на 48-м месте по важности. И вот этим людям вы доверяете своё здоровье. Ну поздравляю, вы на правильном пути!
Делите функционал на общий и правила. Далее общий функционал распространяете, а правила — выборочно. Универсальные правила можно легко пускать в общую копилку, а вот специфику всякую можно придерживать, пока не станет ясно, что «это уже прошлый век».
Я не знаю, что конкретно для вас является проблемой. Судя по репликам выше, на проблемы человечества вы смотрите свысока (мол гретатутберговские они), сами вы ни о каких проблемах не рассказываете, что вас побуждало писать про «с удовольствием в него впишусь» я тоже не понимаю. Возможно вам банально не хватает драйва или каких-то новых «открытий», а «проблемы человечества» лишь психологическое прикрытие.
Для меня основной проблемой является полное господство паразитов, которые постоянно мне указывают, что по их мнению я обязан делать. И если не сделаю — штраф, арест, тюрьма и т.д. Какая может быть польза от почти любой моей деятельности в таких условиях? Одна единственная — отдать им налоги во всех местах, где я что-то сделал. Всё остальное есть лишь поддержание меня в состоянии, достаточном для дальнейших выплат хозяевам. И строго по теме статьи — именно технологии используются для достижения показанной мною ситуации. Чем больше технологий, тем туже удавка на шее.
Но важно дли для вас это? Судя по репликам выше — скорее всего нет. Иначе вы давно бы сами давно написали что-то вменяемое место вопросов из серии «ну какие вообще могут быть проблемы?».
Всё зависит от того, что для вас важно и как вы расшифровываете свои собственные слова:
Если вам никто не мешает и вы не чувствуете никаких угроз своему будущему, то становится непонятно, зачем вы писали выше процитированные слова? Зачем ответили на реплику о том, что местные читатели так же ничем не обеспокоены и пребывают в вечном блаженстве?
Любой, кто знает о своих личных проблемах, способен сам себе ответить на поставленный вами вопрос. Почему не способны вы? Вы стесняетесь признаться, что ваши проблемы завязаны на проблемы общества? Вы боитесь получить виртуальный минус за реплику? Вы так сильно зависите от виртуального «отношения» к вам посторонних людей? Или почему вы задаёте такие вопросы? С такими очевидными ответами.
Поэтому не стоит давать советы бизнесу. Хотя пытаться влиять на принятие решений, выгодных грамотным специалистам, безусловно стоит. И да, вот такими статьями тоже. То есть неявно идёт банальная война за деньги и минимум напряжения между бизнесом и специалистами. Специалисты, вот как в данной статье, описывают своё видение, свои предпочтения, ну а бизнес почитывает и делает выводы. Или не делает, что случается чаще. Хотя дефицит кадров бизнес очень волнует, но ведь всегда есть очень простой способ — купить проджект манагера (начальника отдела или ещё как-то похоже) и свесить все остальные заботы на него. Особенно в больших конторах. И этот манагер уже будет дрючить испытуемых исходя из личного опыта, который, возможно, включает прочтение подобных статей. Но часто не включает. Просто потому, что реальность требует много дешёвых кодеров, ну а манагер вынужден это чутко улавливать. Вот и методы отбора у него вырабатываются соответствующие. И это уже не выбить из такой головы.
Поэтому я бы рекомендовал специалистам «познать цзен». То есть, имея опыт, вы легко отличите манагера от хорошего специалиста, либо мальчика-джуна, посланного вас собеседовать по техническим вопросам менее грамотными товарищами (включая сеньоров). Просто вспомните, как вы сами участвовали в подобных действах. Там всё тривиально — конторе нужен продукт, продукту нужны кодеры, манагер пинает HR, те присылают толпу, далее нужно отсеивать, но понятно, заниматься этим лень, поэтому и посылают начинающего, но умело отвечавшего на собеседовании на технические вопросы. Ну и начинающий затем выдаёт своё ценное мнение наверх, этому мнению наверху не верят, ибо знают, что начинающий, пишут соседям, мол побеседуйте тоже и т.д. В общем — типичная конторская деятельность по перепихиванию работы с себя на окружающих. И где в такой суете место грамотным вопросам? Правильно — нет его.
Бывают конторы, где специалистам верят, поскольку от них всё зависит, но и там «идеальный отбор» отсутствует. Если всем рулит тим-лид, то вышестоящий начальник свешивает всю процедуру на него, ну а он уже подбирает народ под себя. Не по знаниям, не по «полезности для команды», а именно под себя (можно считать, что по сути он думает «команда — это я»). Да, не все люди идеальны. Хороших спецов я на собеседованиях встречал немного. Бывали интересные люди, но всегда были некие манагеры, либо те же мальчики-джуны, либо ещё какие-то специфические условия.
Какой из этого вывод? Да просто расслабьтесь. Не нервничайте по поводу глупых вопросов и всего того, из-за чего вы привыкли нервничать. Ну да, мальчик-джун очень хочет проявить себя и задаёт вам олимпиадные задачки, про которые он где-то читал. Ну так что в этом плохого? Он и обязан это делать, просто в полном соответствии со своим неокрепшим разумом и недостаточным опытом. На что тут жаловаться? На то, что вы не можете вспомнить, какой метод нужно дёрнуть для решения поставленной джуном задачи? Ну так и скажите — я хочу поглядеть документацию по такому-то классу, и через 5 минут отвечу. Если вы боитесь, что джун потом напишет негативный отзыв — не стоит нервничать! Вышестоящий начальник хорошо понимает, кого и куда он послал, поэтому решать всё равно будет субъективно, лишь частично опираясь на отзыв джуна. То есть просто действуйте спокойно, как вы привыкли, и пусть джун под вас подстраивается и потом покрывается, когда вы ему возражаете. Ну ведь просто же!
Так что — расслабьтесь и не нервничайте. Но к собеседованиям, безусловно, готовьтесь. То есть если бы ко мне пришёл якобы сеньор, но поленившийся освежить в голове хотя бы основное по списку указанных в вакансии технологий — ну очевидно же, что он привык к лёгкой жизни на старом месте, не учил новые технологии, не готов банально почитать о том, чем придётся заниматься на новой работе. Именно поэтому возникает вопрос о его проф.пригодности. Не из-за каких-то субъективных факторов, а именно из-за неготовности чуть-чуть напрячься. Потому что новое место работы — это всегда некоторое напряжение, связанное с необходимостью учиться тому, чего на прошлой работе не было.
Но даже моё возражение в куче контор никак бы не повлияло на субъективный выбор кем-то другим, так что опять же — расслабьтесь, не нервничайте, не попали в одну контору — попадёте в другую. А все эти собеседования — субъективная суета. Напрягают лишь если буквально жрать нечего, потому что денег нет. А во всех остальных случаях — не парьтесь. Но только при условии, что вы реально способны учиться и реально обладаете ценными опытом и знаниями.
Это для вас проблема?
Проблема в том, что заявления имеют под собой основания. Это называется манипуляция. То есть основание реальное и точно так же реальны связанные с ним проблемы, поэтому можно предложить порешать эти проблемы, ну а взамен получить лояльных граждан, занятых спасением белых медведей в антарктиде (и да, в антарктиде реально катастрофическая ситуация с белыми медведями — ни одного не осталось).
Для нас же эта проблема означает сложность привлечения внимания к реальным, то есть более значимым проблемам.
Что будет в будущем? Там обязательно исчезнут какие-то виды животных, и даже обязательно исчезнут какие-то нации (растворятся, ассимилируются, и да, некоторых отгенцидят), но что если само человечество перестанет существовать? То есть отвлекая людей сегодня на белых медведей реальные пастухи не дают им думать именно об общих, более важных проблемах. Но как отделить «правильные» проблемы от «манипулятивных»? В этом сложность.
Подходы к решению есть, но они комплексные, требуют вовлечения человека, но ведь у человека есть важное дело — надо срочно спасти котёнка! Он же есть хочет! А как мило он выглядит! И опять человек уходит в ложном направлении.
Вот такие проблемы надо бы порешать, если предположить, что мы вовлечены во что-то важное.
В общем — удивительные персонажи живут рядом с нами. Ни гуманизма, ни проблем. Один сплошной шоколад.
У меня к вам просьба — прочитайте процитированный выше ваш текст и найдите в нём смысл. Я не нашёл.
Общий понятийный аппарат формируется не случайным образом, а задаётся авторами аппарата. Так вот авторы исходили из применимости к программированию абстрактного понятия «математическая функция». Вы же выше написали, что якобы функциональное программирование, это про чистые функции, не меняющие состояние вне самих функций. Но нет, я ещё раз подчеркну — это не так, не про внешнее состояние речь, а про попытку применить математические абстракции в программировании.
Да, от математической абстракции можно прийти к чистым функциям ФП, но это лишь логическое следствие, не являющееся изначальной основой подхода. Поэтому я и написал, что вы вводите людей в заблуждение.
Я писал про запрет, а вы мне про «на самом деле, если долго и нудно копать, то запрет можно обойти». Я в курсе, что затрата приличного количества пота иногда помогает сделать что-то полезное, но про изначальный запрет-то зачем забывать? Причина пота — запрет. Он есть. И если он есть, то уже не важно, в наличии ли какие-то решения «через задний проход» или они отсутствуют, ведь главное — запрет есть.
И вашему знакомому наверняка уже отвечали — перила есть не везде, а лифты — и подавно. Потому что экономически невыгодно везде ставить перила и лифты. И да, иногда невыгодно потому, что они реально мешают. Ну и точно такая же ситуация с уровнями языков. Правда здесь вы попутали уровни с дилеммой «ФП или не ФП», то есть опять придали ФП несуществующую в реальности роль якобы «высокого уровня», ну да я к такому уже привык, поскольку в разговорах со сторонниками ФП всегда встречаю что-то подобное, когда вместо ответа на конкретные факты мне начинают рассказывать какие-то сказки, как вот например про уровни и т.д.
Вы как наши правители — ну вот надо им с нас денег содрать, вот они и доказывают, что «это хороший путь». И плевать им на все возражения. Просто потому, что реальная причина не «хороший путь», а банально денег хотят.
Инструмент (язык программирования в частности) нужно не чинить, а совершенствовать. И если у вас совершенствование ассоциируется с запретами, то вы неправы. Запрет — это примитивнейший способ устранения проблемы. Он почти всегда работает неэффективно. А правильный способ устранения проблемы — сделать совершенное решение. То есть такое, в котором не запретами добиваются нужного результата, а при при помощи учёт множества важных деталей. Поэтому не становитесь в позу нашего правительства, не запрещайте всё на свете, это по вам же потом ударит.
Ну возьмите хотя бы так любимые вами рекурсии. В императиве их обычно реализуют в виде циклов, где есть начало и конец (стандартная конструкция for), а в функциональных языках с их ленивостью предсказание результата рекурсивных вызовов, да ещё с бесконечными списками, внезапно, становится головной болью.
Вообще претензий к ФП, если серьёзно взяться, можно наковырять немало, так что здесь вы просто закрываете глаза на то, что в общем-то обязаны и так знать, являясь сторонником ФП. Собственно все отличия ФП от императива даются не бесплатно, а потому все они имеют минусы, но вы вот мне (отнюдь не стороннику ФП) задаёте вопрос — а какие минусы имеет мой любимый подход? Так он же ваш любимый, а не мой! Но я, тем не менее, вам отвечаю. Только вот у меня возникает вопрос об объективности вашего подхода. То есть вы не видите минусов и видите лишь одни плюсы. Прямо так выше и написали. Но объективно ли это?
Ну я вам уже отвечал выше — постоянно сталкиваюсь со сторонниками ФП, которые упорно талдычат про сплошные плюсы их любимого подхода, но никогда ни один из них не соглашался, если я им говорил о минусах. Всегда мне либо рассказывали сказки про «ну есть же возможность обойти», либо вообще уводили в какие-то не относящиеся к вопросу дебри. Вот поэтому я и стал слегка предвзятым.
В целом — не надо вводить людей в заблуждение, указывая на некоторые случаи, когда неизменное состояние внешних переменных может быть полезно. И тем более — ни в коем случае нельзя приписывать это «достижение» исключительно ФП. Последнее может утверждать только человек, крайне поверхностно знакомый с альтернативами (либо вообще о них не знающий).
Программирование сложнее примитивного деления на «мне нравится ФП» и «мне не нравится ФП». Сторонники ФП по необразованности, к сожалению, часто ставят себя выше остальных, и всё лишь потому, что они обнаруживают в ФП лишь некоторые возможности, которые давно есть в других языках. Ну и в результате выставляют себя глупцами, да. А как ещё назвать людей с самомнением, да к тому же не желающих изучать альтернативы?
Ну и до кучи — возможность изменять внешнее состояние полезна. И если язык позволяет эту возможность использовать — это хороший язык. А если программист при использовании этой возможности не умеет избегать ошибок — это плохой программист. Сторонники ФП нашли выход из такой ситуации — запретили менять внешнее состояние. Просто потому, что считают всех плохими программистами. А как иначе объяснить запрет? Ведь если мы исходим из предположения о грамотном использовании инструмента, то и запрещать ничего не нужно, ведь грамотный пользователь и сам знает, где очередные грабли лежат.
Поэтому речь может идти лишь о наличии альтернативных подходов к разработке. Вот просто в мире есть альтернативы, и всё. Хочешь — пользуйся, не хочешь — не пользуйся. А утверждать, что якобы одна из альтернатив чего-то там делает за программиста — ну бред же. Ошибок можно наворотить бесконечное количество в любом языке. А указывать лишь на один класс ошибок (из миллионов) и при этом гордо задирать нос, мол вот мой любимый подход (ФП) какой прекрасный, это признак очень ограниченного интеллекта. То есть — не надо так себя вести. Даже неявно, когда, как например в данной статье, автор просто забыл про все альтернативы и опять увлекательно нам рассказал, что он недавно узнал, как некоторые языки позволяют отловить один единственный класс ошибок. А все остальные ошибки кто ловить будет?
Тесты, как и вообще всё программирование, это инструмент. Может нравится молоток? С точки зрения эстетики, наверное, но оценивать его нужно с точки зрения способности забивать гвозди. И если гвозди забиваются нормально — молоток хороший. Здесь нет места эмоциям. Просто работа молотком. И всё. Хотя по началу (по молодости) из-за угла может показаться некий ореол романтичности, но это именно по началу.
Вообще, проверка «был ли вызван сервис» бывает разная. Например — нужно уведомлять внешнего клиента о произошедшем событии, тогда очевидно, что это важная часть функционала и вызов сервиса является критичным. Но бывает и по другому — внешний сервис просто даёт какую-то информацию, а потом, обработав эту информацию, процесс выдаёт какой-то свой результат. В таком случае проверка вызова сервиса бессмысленна, потому что нам важен результат, а не какие-то промежуточные действия. Если результат не сходится с ожиданиями — это критично, а был ли там в середине какой-то вызов — совершенно не важно, потому что архитектуру могут переделать буквально через месяц (и такое бывает) и все тесты «про вызов» пойдут псу под хвост. А вот если проверяли результат — переделывайте свою архитектуру сколько хотите, тест всё равно будет полезным.
И второй вариант — сочиняем DSL. Ну вот сочинили, и прикрутили к нему всё ту же выше показанную библиотеку. Но в добавок сочиняем ещё и правила текстового взаимодействия с этой библиотекой. Ладно если почти весь требуемый функционал хорошо ложится именно на регулярки, но если где-то требуется слегка отличающаяся от шаблонов логика? Сразу получаем очень негибкое решение, нацеленное на очень узкую группу задач.
А теперь сравните затраты пользователей. Они учат какой-то новый язык (DSL), а внутри в любом случае учат эти самые регулярные выражения. То есть учатся два раза. И что мешает учиться сразу в сторону универсальности? То есть вместо DSL учим JavaScript. При чём не весь, а только простейшую логику — условные операторы, циклы, функции. А внутри пишем что-то вроде «var result=apply('[1-9,a-z]','Long string from our specific domain')». Можно написать это чуть короче на неком вымученном DSL, но зачем? Что это даст? Объяснить, что «сюда суёшь регулярку, а сюда последовательность» в случае того же JavaScript очень просто, так зачем тогда DSL? Что он даст пользователю?
Потом вот так:
Или вот так:
И наконец вот такой перл:
В целом в статье видим предвзятый взгляд начинающего разработчика на слегка неидеальное решение другого, более опытного разработчика.
Собственно указание на ФП в самом начале уже прямым текстом говорит об отсутствии опыта работы с императивными подходами, иначе фразы типа «мне не нравится без ФП» просто не встречались бы. Но даже если забыть про ФП, то заявление «мне не нравится», не подкреплённое аргументами, выглядит как типичное недовольство не разбирающегося в проблеме, но считающего, что всё, что он видит на работе ему должно нравиться.
В тексте программы, конечно же, используется новомодный синтаксис, скрывающий от разработчика тип используемого объекта. Это всё привычно для разработчиков на JavaScript или на чём-то другом плохо типизированном, но в Java это выглядит страшно. Хотя, к сожалению, такую возможность всё же включили в какую-то из последних версий языка. Но тем не менее, привычка писать в таком стиле очередной раз показывает — перед нами самый что ни на есть начинающий разработчик на Java, скорее всего пришедший из мира редко используемых в промышленной разработке языков, что в свою очередь намекает на отсутствие опыта в промышленной разработке вообще.
Ну и собственно по смыслу проблемы. Автор видит простенькую неидеальность и пытается сделать код «совершенным». Это тоже типичная проблема новичка. И решает её новичок в таком виде, про который он сам говорит — «такой подход заставляет писать столько кода, что от него сразу хочется отказаться». Ну что-ж, полезная самокритика. Но вот результат всё же не впечатляет.
Почему результат не впечатляет? Очень просто — автор привык оптимизировать по сложно формализуемому критерию исключительно учебные кейсы для ФП, а потому автоматически применяет этот навык в более серьёзной разработке. В результате у него получается, как он сам отметил, нагромождение всего на свете.
Как исправить ситуацию? Всегда самый эффективный способ улучшения находится на уровень, а то и два, выше примитивов непосредственно кода. То есть алгоритм решения проблемы никак не зависит от любого языка программирования, но привычка новичков уделять внимание «красоте кода» (в их очень субъективном понимании) заставляет их строить то самое нагромождение, от которого сам же автор в конце концов плюётся.
Не надо переходить на уровень кода, когда ваш алгоритм глупый. Просто не надо.
Почему алгоритм глупый? Потому что автор даже не пытается понять, а что реально происходит в программе. Он видит только код и его субъективную «красоту». А что этот код делает?
Можно предположить, что объект типа Product заполняется данными. И точно так же можно предположить, что объект типа Product служит источником для заполнения каких-то дополнительных объектов. Это два архитектурно принципиально разных подхода. И решение усмотренной автором небольшой неидеальности должно в первую очередь зависеть именно от того, в каком направлении движутся данные. А на более высоком уровне всё зависит от того, зачем вообще эти данные куда-то движутся. В результате скорее всего весь рассматриваемый автором метод вообще не нужен, например потому, что итак уже содержащий данные объект типа Product (во втором варианте), можно направить в то место, где эти данные каким-то образом потребляются. Но повторюсь — автор не видит ситуацию «в большом», то есть вместо понимания ненужности условного дома, он старательно штукатурит его стены, что является самым главным признаком начинающего разработчика. Никакие зазубренные знания синтаксиса не помогут вам сделать глупость умной. Потому что глупость находится на несколько уровней выше в иерархии абстракций, по сравнению с синтаксисом языка. И вот это понимание затмевает зубрёжка синтаксиса, желание видеть очень условно понимаемую «красоту», основой для которой являются примеры из ФП, часто не имеющие к реальной жизни практически никакого отношения (да, всё те же сортировки, перестановки, операции над структурами). Погружаясь во все эти сортировки человек видит условную «красоту» низкоуровневых алгоритмов, а собственно зачем эти все алгоритмы применяются — ему совершенно по барабану. Ну и в результате имеем глупость.
Поэтому, дети (начинающие программисты) — зрите в корень! Не ведитесь на гламурный синтаксис и мнение функциональных программистов о «некрасивости» кода без функциональной шелухи. Думайте о главном. И даже больше — думайте, что такое главное. И может быть в итоге вы станете реально хорошими (полезными для проекта) разработчиками, а не поставщиками гламурной чешуи под рекламным называнием «красивый код».
Не компактность, а понятность. Это очень разные вещи. Компактность достигается выкидыванием из языка всех конструкций длиннее одной буквы, а понятность достигается структурой языка и форматированием. Вот последнее для некой предметной области будет либо очень нетривиальным, либо элементарным. Простые варианты банально вызывают некие библиотеки, которые и реализуют нужный функционал, но стоит захотеть расширить набор функций, как придётся всё реализовывать вручную на недо-языке. Если же мы встраиваем в язык возможности для программирования сложной логики, то сразу получаем относительно сложный для неподготовленного юзера универсальный язык программирования.
В целом дать пользователю какой-нибудь JavaScript и написать для него библиотеки будет много проще, чем возиться с DSL. Либо если по сути нужно заполнять какие-то шаблоны (выше пример с играми), то здесь вполне подходит обычное решение на GUI — просто собираем данные для шаблона и выполняем над ними необходимые действия. Сложной логики здесь никакой, а потому требования к пользователям низкие. Но если помимо шаблона нужна сложная логика игры — вот и приехали, придётся переходить на универсальный язык программирования.
>> На деле мы видим зависимость от уровня языка и производительностью разработки на нем
Уровень языка никак не относится к делению на DSL и универсальные языки. Это всё высокоуровневые языки программирования. Но в DSL обычно присутствует некий набор функций, характерный для предметной области. То есть отличие двух высокоуровневых языков, один из которых DSL, а другой — универсальный язык, состоит в том, что в DSL сразу присутствует специфический функционал, который в универсальном языке может быть добавлен в виде библиотеки, но отсутствует в дефолтной реализации.
>> По хорошему юзеру это понимать и исправлять.
Что бы юзер понял, ему нужно всё объяснить в знакомых терминах. Если ошибка будет выдаваться в виде «в строке Х около символа на позиции У присутствует синтаксическая ошибка», то юзер долго будет пытаться понять о чём вообще речь. Но даже при таком простом описании ошибок уже сложно как-то передать проблему в структуре данных, а не в синтаксисе. Например — в предметной области есть деревья, пользователь их описывает на DSL, с точки зрения синтаксиса всё корректно, но вот структура дерева кривая. Теперь вопрос — сколько видов кривизны структуры дерева может быть? Не отвечайте сразу, сначала добавьте в модель зависимости между узлами дерева, а потом попробуйте описать это всё коротко на DSL.
>> даже на DSL можно описать крайне громоздкую и сложную логику, но на языке общего назначения та же самая логика выглядела бы еще хуже.
Как раз наоборот. DSL не содержит никаких хитрых универсальных логических конструкций. Все хитрые универсальные логические конструкции давно включены в универсальные языки программирования. И если вам нужна именно сложная логика, то именно на универсальных языках она реализуется проще всего.
Либо вы путаете универсальную логику с заранее подготовленными решениями для конкретной предметной области. Тогда я выше уже говорил — на универсальном языке просто реализуем необходимые библиотеки и далее обеспечиваем к ним доступ пользователей. Доступ обеспечивается тремя способами — (1) обычный GUI, (2) DSL и (3) напрямую на универсальном языке. Способ №1 очень прост и давно отработан, но там сложно с добавлением логики, поэтому приходится делать решения со скриптовыми языками, имеющими доступ к введённым пользователем данным. Способ №2 отличается от №1 тем, что заставляет пользователя самостоятельно представлять в голове всё то, что в №1 ему даётся в GUI, а в остальном логика работает идентично, кроме чисто субъективных отличий DSL от скриптового языка. Ну и способ №3 отличается от №2 тем, что вообще нет необходимости делать ничего, кроме написания библиотеки. То есть способ №3 самый экономный. А раз уж мы знаем, что пользователь в любом случае будет учить язык программирования, то пусть уж учит универсальный и дёргает оттуда библиотеку.
Все эти плюсы довольно мифические. Скорость, ошибки и прочее улучшаются только одним способом — нахождением общего решения проблемы и последующим программированием решения. Всё остальное — паллиатив.
Нет там выхода. Когда вы просто разделяете строку на слова, используя пробелы в качестве разделителя — это одно. Но когда вы пытаетесь понять, а потом исправить, всю ту галиматью, которую нарисовал вам юзер, и при этом не в виде строки с простейшими разделителями, а в виде очень нетривиальной структуры данных (да, предметная область такая), то одно вылавливание потенциальных ошибок юзера выливается в мега-квест, я уж не говорю про проблемы всей остальное работы со сложными структурами данных.
Тут либо всё упрощать, что сразу убивает предметную область (или по другому — делает DSL бесполезным), либо долго и нудно сочинять нечто сложное и по сути решающее задачу за пользователя.
Где-то посередине иногда можно найти приемлемые варианты, но это редкость. Если всё просто, то язык не нужен, легче всё подать в стандартном графическом стиле, а если сложно, то..., как бы это не было удивительно, всё именно сложно.
Хотя можно пообсуждать примеры реально используемых DSL. Правда всегда это использование очень узкое, никому кроме рассказывающего неизвестное.
Предположим, что существует некий процесс (для упрощения — человек), который действует с учётом той или иной информации. Что будет, если за миллиарды световых лет от процесса произойдёт интересное событие? По вашей гипотезе информация будет получена процессом мгновенно. Но тогда процесс начнёт менять физическое состояние как себя, так и окружающего мира, в соответствии с поступившей информацией. В итоге к моменту поступления физически наблюдаемых изменений о произошедшем далёком событии мы давно уже забудем о нём, а процесс уже будет обрабатывать очередное событие, о котором в физической реальности станет известно лишь через миллиарды лет.
То есть в ответ на сверхсветовую скорость передачи информации мы получаем сверхсветовую скорость реакции на физические изменения. Если процесс управляет силой притяжения, то сила притяжения отреагирует на удалённое событие мгновенно. Возможно ли такое без нарушения известных физических принципов?
>> В КМ изначально не предусмотрено таких вещей как состояние системы не в контексте измерения
Но само-то состояние допускается? То есть до измерения. Мы можем не знать состояния, но его наличие, по сути, оспаривается теориями вроде запутанности.
>> Нет, он не взаимодействовал ни с чем. Фотон «одноразовая» частица. Как только он отдает информацию о своем состоянии куда-то, он перестает существовать.
То есть фотоны пролетали заметное расстояние без столкновений с молекулами воздуха? А потом без столкновений с молекулами оптических приборов? Сразу на некий приёмник, где не взаимодействовали ни с какими частями приёмника, кроме собственно той части, которая порождает некий наблюдаемый со стороны эффект? Выглядит как некая магия.
>> В природе практически нет легких задач для КМ.
Не только для КМ. Гравитация с теорией струн ничуть не проще. Вроде Ли Смолин писал о теории струн примерно такое — они все ходили с огромными чехлами, в которых хранились листы формата А0, на которые с трудом умещались все необходимые формулы для обсуждения на текущем заседании.
Проблема сложности убивает науку. Когда о смысле происходящего догадываются лишь 5-10 человек на планете, вряд ли стоит говорить о научном подходе с его верифицируемостью. Группа в 5-10 человек студентов и одного «идейного лидера» скорее напоминает секту, из которой потом выйдут эти 5-10 «идейных» проводников учения, между которыми и будут продолжаться все обсуждения, но строго в направлении, каким-то образом отвечающем желаниям участников секты, а не науки.
И есть другая сторона проблемы — миллионы публикаций. Правда опять — всё на узкие темы, значит опять по каждой нужны те самые 5-10 экспертов, а все остальные просто никогда не читают подавляющую часть опубликованного.
Но тем не менее — ваш ответ для меня вполне познавателен, за что вам отдельное спасибо (в карму не могу, возможность отключили).
Проблема в протяжённости.
То есть электроны разлетаются на большое расстояние, а потом, превращаясь по вашему «во что угодно», они в двух очень далёких точках вселенной оба одновременно обеспечивают выполнение законов сохранения. Но взаимодействие же произошло в одной точке вселенной, а информация об этом (для соблюдения законов сохранения) передана мгновенно на очень большое расстояние, после чего можно измерять вторую частицу, которая мгновенно ответит нам, что её состояние вполне конкретное, которое не было известно до взаимодействия второй частицы за миллиарды световых лет от первой.
Хотя в целом — да, не понимая (как я) квантовой механики совершенно непонятно, почему все эти спины и прочие попугаи не являются свойством изначально созданной системы из двух электронов, но должны с чего-то «внезапно проявиться» именно в момент взаимодействия. Почему их не может быть до взаимодействия? Что этому мешает? Как я понял, в каких-то случаях нарушается некое неравенство, выведенной неким Беллом, и из этого почему-то следует, что система из двух электронов принципиально не может иметь характеристику типа «спин» до момента взаимодействия. И даже больше — до момента взаимодействия с чем? В опыте на Тенерифе фотон вообще летел через воздух и бесконечное количество раз взаимодействовал с молекулами воздуха. И почему он всё это время не мог определиться со спином?
В общем — да, без понимания квантовой механики возникает миллион вопросов, и не появляется ни одного ответа. Какой-то сумрачный и непредсказуемый мир с отсутствием (понятных) причинно-следственных связей.
Да и подход к этому миру тоже сумрачный — в учебнике вводится некое уравнение (волновая функция) и предлагается поверить, что всё на свете описывается именно им, просто потому, что в экспериментах всё складывается так, что предложенное уравнение вроде бы сходится с результатами экспериментов. Но какого вида эксперименты? Какие параметры измерялись? Как измерялись? Что за адская математика во всём этом участвовала?
В целом, конечно, есть аналогия с выводом формулы для закона всемирного тяготения (её тоже взяли с потолка, просто потому, что она подходит), но там неизвестное одно — сила притяжения, а в квантовой механике какое-то огромное количество попугаев, каждый из которых получает смысл лишь в неком математическом контексте, то есть он «подходит» при подстановке в какие-то страшные формулы, а более смысла в попугае никакого не прослеживается (наглядный пример — очарованные частицы). В целом возникает вопрос — о чём вы вообще? Может есть другая математика, попроще? Почему её никто не ищет, но лишь увлечённо городят всё более страшные формулы?
Хотя ответов, понятно, не дождёшся. Но физику (и её математику) учить подробно времени нужно очень много.
Здесь ключевое — Белл придумал.
В математике есть случаи, когда можно придумать проверку гипотезы, то есть произвольно взять некий результат, а потом посчитать с учётом зависимостей значения других переменных. Так вот эти другие переменные могут авторитетно заявить — всё сходится, вы выбрали правильное значение. Примерно так же действуют физики — предполагают нечто, а потом проверяют. И если проверка показывает, что всё сходится, то физики считают, что именно вот так вот и устроен мир. Только есть одна проблема.
В математике, когда по другим переменным проверяют предположение, всё тоже может сходиться, но если возникает возможность прямо (без проверок по косвенным данным) вычислить искомое значение, то оказывается, что оно не равно предполагавшемуся. И если копнуть глубже, то окажется, что все проведённые проверки действительно должны были сойтись, но только в определённых случаях, которые как раз и попадают в область доступных для вычисления параметров.
Немного по другому — бывает проще проверить что-то косвенным образом, потому что вычислять напрямую не хватит никаких вычислительных мощностей. Но если всё же проверить задачу на достижимых для прямого вычислительного эксперимента значениях, то окажется, что не смотря на подтверждение со стороны косвенных проверок, предполагаемый результат не сходится с вычисленным напрямую.
Не знаю, как там в деталях в квантовой физике, но точно знаю, что там полно той самой математики. И математика может вот так вот легко обмануть, если мы будем верить проверке гипотез экспериментом.
Что такое учёт активности? Это в первую очередь самостоятельное планирование. Не ожидание счастья от гуглов или китайцев, это самостоятельная работа. Да, работа, которую многие делать просто не хотят. Но стоит заметить, что подумать у вас займёт ну максимум пол-часа, а потом просто выполняете придуманный план и тратите на это суммарно в день минут 10, ну ладно, пусть 15. И вот это вот вам делать лень? Нужен какой-то гугл, что бы вас за задницу постоянно брал и подталкивал? Тогда очевидно — не надо вам никакого фитнеса и прочего, потому что это самообман. То есть вы надеетесь, что кто-то за вас сделает вам красиво, без вашего минимального напряжения (10-15 минут в день). Ну да, без напряжения, да сразу в рай. И вы в это верите. Ну молодцы, что сказать.
Про шаги. Считать их почти всегда — бессмысленно. Есть карты, на них есть линейки, померить расстояние до работы — 5 минут затрат, но зато потом все годы вашего хождения на работу вы всегда будете знать, сколько километров вы прошли. И вот потратить 5 минут один раз в несколько лет — кого-то напрягает…
Про «я много бегаю по делам». Здесь примерно то же самое. Вы просто фиксируете время вне офиса. И всё. Ваш средний темп ходьбы практически никогда не меняется, поэтому время вам даёт очень точную оценку затрат калорий на ту же ходьбу. Вам неохота каждый раз разглядывать часы и запоминать время выхода из офиса? Так ничего страшного не случится, если вы будете это делать хотя бы раз на 10 выходов из офиса. Потому что важна активность в среднем, а не лишний километр в конкретный день. И вот среднюю цифру вы получите легко, даже забывая её замерять 9 раз из 10. Ну а далее — тривиально, вот она, вся ваша активность, выраженная средним количеством времени вне офиса. Точнее никакие гуглы и мега-супер-убер-девайсы вам не скажут. Обычно наоборот — точность девайсов просто никакая.
Про всякий фитнес. Вам лень считать количество отжиманий? Ну ужас же! Вам не хочется почитать, что такое программа тренировок? Вам лень скачать готовую примерную программу? Вам в лом самостоятельно учитывать минимальный набор простейших показателей? Ну зачем вам тогда фитнес? Что бы гугл сказал, «ты молодец»? Он вам обязательно это скажет, для этого фитнес совершенно не нужен. Это бизнес по продаже эмоций, так что они вам обязательно улыбнутся, лишь бы платили.
Про бег. Один раз померили расстояние по карте и далее всего лишь смотрите на показания пульсометра. Но даже пульсометр становится ненужным, когда привыкаете к определённому темпу. В итоге пульсометр лишь иногда таскаете для контроля, выявления улучшений/ухудшений. Вот и всё. Или вы мировой рекорд собрались ставить? С помощью гуглов что ли? Ну смешно же.
В общем — куда ни плюнь, везде всё очень просто, и никакие подсказки от столь любимых некоторыми гуглов не нужны. Либо вы сами определяете свою жизнь, либо вы бегаете как дурак по указанию каких-то дятлов из гугла, которые на самом деле самые обычные люди, которым лень делать много качественных продуктов, которые воюют со своими начальниками за безделье и много денег, ну а продукт (и тем более — вы) для них где-то на 48-м месте по важности. И вот этим людям вы доверяете своё здоровье. Ну поздравляю, вы на правильном пути!
То есть проблема вполне решаемая.
Плюс ещё Греция — страна гористая. На равнине, наверное, лошадь всё же выиграет, а вот по горным тропам лазить — однозначно проиграет.
А седло и стремя — лишь техника, которую бы обязательно изобрели, если бы была потребность. Но лошадь, видимо, проигрывает и с седлом и со стременами.