>Думаю лет через 5 любая модель выпускаемая любой серьезной конторой будет во многом раз умнее этих и любого человека на планете
Не будет, прогресс в модельках уже не первый год на месте стоит. Это все мертворожденный продукт без практических применений, опенаи упорно пытаются запрыгнуть в уже ушедший поезд. Будущее за небольшмми узкоспециализированными локальными моделями.
>они уже научились нагло врать, сознательно обманывать и защищать себя от отключения всеми доступными способами
А как в табах различать например редиез и мибемоль? На скрипке они обычно поразному играются.
>Сначала появились табы для отдельно взятых инструментов, а затем уже ноты для приведения их к единому знаменателю
Эм, нет. Табы предполагают наличие ладов, а безладовые инструменты существенно древнее, не говоря уже о голосе. Так что сперва появились ноты (не равномерно темперированного строч, конечно, другие)
напомню, сперва в том же JS/Python появились то, что вы зовёте монадками - промисы.
Напомню, они появились в функциональщине, в 70е. Ни какого жса и питухона в 70х не было. В 90х появился монадический синтаксис для промисов (через который выражался async/await) - тоже в функциональных языках, в 90х. Жса тогда тоже еще не было, а первый питухон вот примерно через годик допилили. К концу нулевых промисы доехали из функциональщины в мейнстрим, еще через десяток лет - в мейнстрим из функциональщины доехал огрызок монадической нотации (async/await). В целом, как я и сказал - выполняется правило о том, что все фичи доезжают мейнстрим через 10-20-30 лет.
гоните пруф.
Ну пообщайтесь в функциональном коммунити. Только не говорите громко, что лиспы - фукнциональщина, а то вас сочтут долбоебом, простите.
большинство академиков жрёт гранты, а потому им надо вводить в заблуждение инвесторов.
Инвесторов папир по семантикам яп?)) не несите чепухи
Поэтому подход "выбрать что-то заумное и делать непонятное" в противовес "достичь каких-то целей" вполне для академиков частотен.
Как видим это заумное через 10-20-30 лет потом в мейнстрим и спокйно используется сообществом разработчиков. А потом приходит ednersky и рассказывает о том, что функциональщина НИНУЖНО, хотя практически весь софт написанный как минимум за последний десяток лет плотно на этой функциональщине сидит. Не доводит криокамера до добра.
это способ писать функции в процедурном стиле, а не функциональном
Наоборот, callback hell - результат написания в процедурном стиле, а монадки - функциональный.
ваш Хацкель совершенно ни при чём, даже если в нём есть похожий паттерн, это не означает, что именно он является прототипом
Это не похожий паттерн и не прототип. Это _буквально в точности та же самая фича_.
а для того, чтобы от неё (функциональщины) уйти.
Это не слишком логично - впиливать функциональные фичи в язык, чтобы уйти от функциональщины, не находите?
пайп функций это именно функциональный стиль.
Пайп функций не имеет ни чего общего с функциональный стилем.
Он описан ещё в старых книжках по Лиспу Хювенена/Сапеняна в 1985-88 годах (ЕМНИП).
Ломающие известия для тех, кто не вылезал последние 20 лет из криокамеры - лиспы давным-давно уже не считаются функциональными языками. Современная (ну как современная - пару десятилетий минимум) функциональщина - это чистые функции и навороченные системы типов с нетривиальными гарантиями. По второму параметру лиспы сразу пролетают, по первому - теоретически могли бы проходить некие scheme-derived диалекты, но с ними проблема в том, что значительная часть лисп-сообщества уже, в свою очередь, не считает такие диалекты труъ-лиспами.
И да, именно поэтому функциональщиной считается, например, раст - он четко проходит по второму пункту, системы типов.
процедурные языки не чураются забрать в себя все подходы, в отличие от функциональных языков, которые как те сектанты "проповедуют стиль".
Здесь дихотомия не процедурное - функциональное, а академическое - мейнстрим (просто так уж пошло что почти все современные академические языки - та или инаяфункциональщина).
В мейнстриме никогда не появляется ни чего нового - оно туда приходит из академических языков, с задержкой лет на 10 (20, 30...). Логично, что обратный процесс невозможен - из мейнстримного языка в академический прийти ни чего не может точно так же, как нельзя наполнить полный сосуд из пустого. В академических языках и так все мейнстримные фичи давным-давно есть.
Так вот и вышло с тем же async/await, который десятилетиями мариновался в функциональных языках, и уже не так давно был запилен в C#, откуда потом и распространился по этим вашим питонам с жсами.
&>именно поэтому абсолютно все популярные языки отказались от функционального стиля описания асинхронщины и притащили операторы (или варианты), как писать асинхронный код но в процедурном стиле
Я чтото пропустил и до сих пор у нас callback-hell? Уже давным давно везде отошли от процедурной асинхронщины с ручным пероленьем коллбеками и юзают чисто функциональщиный аналог в виде async/await (это частный случай ду-нотации, утащенный в мейнстримные языки из хакскеля, если вы не в курсе).
Вообще ваши посты почитать - и такое чувство что вы последние лет 10-15 в криокамере провели. Щас 2024, а не 2010, прием.
>что такое функциональный стиль? это когда вы собираете пайп функций
Вы сейчас как раз описали процедурный стиль. То есть вся ваша критика - критика процедурного стиля.
>а потому если можно рекурсию преобразовать к циклам так и поступают
Так поступают только плохие компиляторы. В нормальных компиляторах оптимизируются все хвостовые вызовы, в том числе и нерекурсивные. И ни кто рекурсию в циклы не разворачивает, так как незачем.
Так по факту из любой такой задачки несложно сделать реальную. Взять тот же факториал (или в целом задачки "на рекурсию") - ну ок, написать ф-ю которая принимает дерево, предикат и фильтрует это дерево по предикату. Только если брать вторую задачу то полчаса уйдет на уточнения, граничные случаи и т.п., т.к. кандидат будет всегда какие-то подвохи видеть, когда от него просто хотят чтобы он хоть как-то отфильтровал гребаное дерево) задача про факториал такого недостатка решена
А те, кто пишет что "Х в реальной работе не встречается" - ну тут же все просто, если ты не умеешь использовать молоток, то ты никогда его и не используешь, а соответственно он и "не нужен, не применяется". Здесь своего рода замкнутый круг: не умею применять -> не применяю -> оно не нужно -> раз не нужно, то не изучаю -> не умею применять
на практике я не встречал или почти не встречал (30 лет как программирую) необходимости
Вы исходите из ложного предположения о том, что вопросы, которые задаются на собеседовании, должны каким-то образом "соответствовать" реальным задачам. Это неверно, конечно же. Смысл этих вопросов - отсеять тех, кто заведомо профнепригоден, причем максимально эффективно - чтобы потратить минимум времени как специалиста, который проводит собеседование, так и времени самого кандидата.
Если человек не может написать факториал или развернуть строку - то как программист он ни чего не умеет и полностью профнепригоден. Зачем нужен человек, который не сможет на работе решить ни одной, самой простой задачи? При этом на то, чтобы задать такой вопрос достаточно буквально полминуты-минуту. К чему выдумывать другой вопрос, на который придется давать вводные полчаса, и который даст те же результаты?
Чтобы получать как в фаанг, нужны и компетенции соответствующие, а тут люди строку не могут развернуть на php. Знакомые мне люди, которые в фаанг устраивались джунами, могли бы без проблем не только на пхп ее развернуть - а еще следом на каком-нибудь ассемблере, и в хаскеле на типах в компайл-тайме, при чем вообще не сочли бы это задачей, требующей включать мозг.
Так что всему этому безграмотному непутевому сброду, который тут в комментах пишет про ужасно, несправедливо сложные собеседования, где от мидла требуют способность написать fizz buzz, до зарплат фаанга - как рогозину до марса. Их в компанию подобного уровня подметать полы ни кто не взял бы с таким уровнем экспертизы.
Оценка такой мелкой таски будет тем точнее, чем меньше таска.
Я и говорю - это просто глупость, которую один дурак когда-то сказал, а остальные дураки - повторяют.
но и сами риски по мелким таскам тоже мелкие
На самом деле риски по мелким задачам существенно крупнее, чем по большим. Это достаточно очевидно. Но даже если их не считать больше, а считать такими же - то в итоге для большой задачи оценка будет точнее все равно.
Если у вас есть несколько одинаковых независимых случайных величин с положительным матожиданием, и вы их будете суммировать - то матожидание растет линейно от n (количества задач), а стандартное отклонение - пропорционально корню, с-но точность оценки растет пропорционально корню от размера задачи (на самом деле даже не самой оценки - а в принципе неопределенность в сроках уменьшается, с-но уменьшается и неопределенность в оценке).
Это как бы очевидно и на конкретных примерах - допустим, у вас есть задача на два часа. Если вдруг случится какой-то несущественный риск - то вместо 2 часов будет 4 часа, это 100% отклонения. И такие отклонения для задач подобного размера - обычное дело, они постоянно происходят и на них особ внимания ни кто не обращает. С другой стороны, если у вас задача на год, то 100% отклонение крайне маловероятно (и считается уже не нормой, фактически это проваленный проект в 9 случаях из 10).
Точность оценки в случае маленьких задач возникает просто из-за того, что они лучше и подробнее поставлены - любая неопределенность в постановке всегда закладывается в риски, т.е. в + к оценке, что снижает точность. Маленькие задачи же ставятся конкретно, что снижает неопределенность. Если же большая задача и маленькая поставлены одинаково - то для большой задачи ниже риски, с-но точнее оценка.
>Большие задачи потому и делят на много маленьких, потому что оценка маленьких задач всегда будет точнее
Не поэтому, на самом деле, это лишь распространенное заблуждение. На самом деле все точно наоборот - чем меньше задача, тем менее точной будет оценка, в силу того что риски не усредняются.
И все вышеперечисленные технологии резко уменьшили уровень знаний, необходимых для решения проблем. Теперь не надо быть цсс-нинзей, чтобы выровнять один сраный элемент, т.к. благодаря современным фичам все just in works одной строчкой. Не надо курить многотонные мануалы по разворачиванию окружения - достаточно пару раз сделать ctrl+c ctrl-v в терминал и в докере все само поднимется. Не надо изобретать какие-то сложные архитектурные подходы для того чтобы привнести интерактивности в интерфейс - за тебя все сделают фрейморвки.
Современные инструменты разработки в типичных случаях просто берут на себя 90% всех знаний и умений. Достаточно тыкнуть пару кнопок и оно все само заработает. На магии.
Извините, пилота самолета меньше учат. Врача меньше учат. Но да, это же так просто, ну конечно.
Не знаю, что там на счет пилотов, но врача за эти 10 лет вы точно не выучите. Да и за 20. И за 30 - сомнительно. Вы же не забыли, что мы не о фуллтайм обучении в юности, а об обучении взрослого, 30+ вкатуна, которому удается иногда выделять на обучение часик-другой в перерывах между семьей/работой/етц.?
Где мне без опыта открыть с ноги дверь в джуны, дайте контакты?
Да в любой крупной компании. Джуна в принципе сейчас найти практически невозможно, нет их на рынке. Логично, что отсутствие предложения ведет к росту цен.
и на каждую под тысячу откликов
Ну так это не джуны откликаются и не джуновская вакансия.
Про пользователя согласен, но мы говорим не про пользователей.
Именно про пользователей мы и говорим. Разработчик - это пользователь средств разработки. И эти средства становятся проще с каждым годом - не "внутри", а именно для пользователя проще.
Багаж знаний постоянно растёт
Нет, это просто глупая выдумка.
Потому что просто нет таких гениев, чтоб в голове держать всю отрасль на достаточно глубоком уровне.
Ну как нет? Есть. Любой нормальный выпускник хорошего вуза по айти специальности является таковым.
И снова, это не я утверждал, что программисты работали за еду и что з/п программиста была максимум 16 т.р. в 2011.
Так ни кто не утверждал. Речь была о программистах _без опыта_. Именно это ключевой водораздел был в том время. Не имеешь опыта работы - изволь работать за еду первые месяцы, а потом уже можешь трудоустроиться нормально.
но 20 лет назад накиданный самостоятельно сайтик представлял собою набранный в блокноте спагетти-код из HTML с PHP.
И написание этого кода требовало на порядок более высокой квалификации, чем нашлепать формочки на реакте.
и прочего, и прочего, и прочего
Что именно это "прочее, прочее и прочее" то?
Равно как не было адаптивной вёрстки под десктопы и мобилы
Современная верстка с адаптивностью и мобилками просто в разы проще того ада, с которым приходилось работать людям в конце нулевых.
не потому что люди другие, а потому что объём требуемых знаний увеличился на порядок (если не на порядки).
Ну это же очевидная глупость, которая опровергается обыкновенным здравым смыслом. Технологии _всегда и везде_ развиваются в сторону упрощения (= снижения требований к квалификации пользователя), поэтому объем требуемых знаний неуклонно снижается. Если кто-то придумает более сложные, чем уже есть, методы/инструменты/подходы разработки - то их просто не станут использовать. А то, что в итоге используют - оно всегда проще. Написать интернет-магазин в 2024 намного проще и требует существенно меньшего набора знаний и навыков, чем было в 2014, а в 2014 - было проще, чем в 2004. А в 2004 проще, чем в 1994.
Поэтому если сейчас из криокамеры вылезет программист, который в 2004 туда сел, то он за выходные поскролит доки и с понедельника спокойно выйдет на работу, не имея ни каких проблем. Вы даже не поймете по его работе, что он из 2004. Т.к. он обладает абсолютно всеми навыками и знаниями, необходимыми для эффективной разработки в 2024. Если же современного фреймворк-сениора отправить в 2004 - хорошо если за месяц он сможет поднять сервер, отдающий хелло ворлд. Потому что он не обладает необходимым навыками и знаниями для разработки в 2004. И мануалы курить не умеет - а стековерфлоу в 2004 еще не изобрели.
в 2004, это была серьёзная заявка на успех.
Это даже в 1994 не было заявкой на успех. У вас какое-то странное представление о тех временах, будто тогда по городам телеги с лошадями ездили.
Тогда уже были сложные учетные системы на предприятиях, ввести что-то там куда-то там, которое благодаря автоматизации сделает чего-то там и распечатает что-то там - не было ни каким рокетсаенсом. И сейчас не то чтобы эти системы изменились, каким-то невиданным функционалом не обросли - по итогу они делают то же самое и так же. Их просто стало намного проще и дешевле разрабатывать.
В детские увлечения двоичные деревья обычно не входят.
Если человек изучал язык с ручным управлением памяти (а он изучал почти наверняка), то про списки и бинарные деревья он знает в девяти случаях из десяти. В оставшемся одном случае из десяти он без каких-либо проблем решит задачку, если ему сказать определение бинарного дерева. Там тривиальный алгоритм на несколько строчек.
По нынешним меркам это может быть и "за еду", но тогда это так не воспринималось.
Так и воспринималось. Это сейчас джуны всем нужны и к работодателю дверь с ноги открывают, а тогда "без опыта" было черной меткой. Люди буквально на минималку соглашались идти, чтобы полгодика поработать и получить отметку в трудовой.
В конце концов, у нас есть интернет, и в нём есть архивы. Просто беглым поиском нашёл вот, например, хедхантер даёт такую картинку для сисадминов
Так это же не джуновская зп.
медианная зарплата в РФ порядка 60 т.р., или примерно $600, а джунам предлагают по 30-40 тыс.
Это что за комедия?) Дешевле 100к вы джуна сейчас не найдете, а в целом и на 150+ джуны устраиваются. Я джунов имею ввиду, естественно, а не выпускников курсов, которым до джуна учиться надо 10 лет.
Соответственно математики доказывают, что разделив пул кандидатов в соотношении 1/e, вы в среднем наймете наилучшего из кандидатов.
Здесь должны выполняться несколько условий:
не должно быть возможности отфильтровать кандидатов заранее, повысив "качество" исходной выборки
нельзя собеседовать следующего кандидата до того, как полностью отвергнут предыдущий
надо максимизировать качество кандидата
Ни один из этих пунктов в найме не выполняется - мы _можем_ улучшить качество выборки, мы _можем_ переходить к следующему кандидату до того, как отвергли предыдущего (и даже опрашивать нескольких одновременно), и нам не нужен с максимально ожидаемыми скилами - нам нужен первый, кто нас устраивает (или даже сразу все). Исходя из этого, процесс найма и устроен.
Если вернуться к вашей аналогии с оркестром - допустим, нам в оркестр понадобилась скрипка, пришло на прослушивание сто человек, и мы знаем, что из них хорошо если десяток вообще хоть раз в жизни видел скрипку ирл. Тогда мы сперва применяем примитивные фильтры - просим, например, продемонстрировать, как кандидат будет держать смычок во время игры. Половина кандидатов берет смычок не за тот конец и идет домой. Потом предлагаем сыграть гамму (без всяких технических изысков вроде там децимами или двойными флажолетами - просто гамму, как захочется) - в итоге остается 5 человек, их можно вести на прослушивание.
На самом деле, при отборе в реальные оркестры именно так и происходит - только туда уже на первоначальный отбор приходят люди в айтишной терминологии уровня сениор++, поэтому вместо того чтобы развернуть бинарное дерево (= подержать смычок) их просят быстренько перепрошить микроконтроллер (что-то такое сыграть минуты за 3 чтобы жюри восхитилось и дало возможность пройти по отбору дальше). Ну а потом уже несколько недель подготовки к настоящему собеседованию, и дальше их как раз будут гонять и по скоростной печати, и по навыкам демосцены, и змейку в compile time на типах в хаскеле написать попросят. И тому, кто все это пройдет - предложат по итогу испытательный срок)
Т.е. у таких людей нет смысла просить подержать смычок - они и так умеют, это только время тратить. А вот в ит - смысл есть, натурально половина приходит и не умеет. Потому и задаются все эти вопросы при найме, что - смысл есть, люди действительно умудряются не обладать даже самыми базовыми навыками программирования..
Трава с небом, может, цвет и не поменяла, а вот рынок труда в ит-индустрии поменялся кардинально - и это объективный факт.
Средний джун того времени - это человек, который с детства увлекался ИТ, еще в школе мог на нескольких языках инвертировать бинарное дерево (или уж на первом курсе универа, максимум) и к своей первой работе имел уже опыт программирования под 10 лет (при чем реальный опыт решения сложных инженерных задач, а не перекладывания жсонов), в комбе с глубокими и обширными фундаментальными знаниями. Ну и навыками из разряда быстро поднять ламп (с нуля, руками, без всяких докеров, ессно) и накидать самостоятельно какой-нибудь интернет-магазинчик. Причем это был результат именно фултайм обучения, которое приходилось на самый эффективный в плане восприятия мозгом этап жизни.
Теперь же, в 2024, у нас джун это условный 30+ человек после курсов - ну просто физически, чтобы достичь уровня джуна выше и хоть как-то на равных с ним конкурировать, ему придется потратить не менее 10-15 лет. И это при условии что будет эти 10-15 лет мотивация серьезно вжобывать. Попроси у такого современного "фронтенд сениора" написать гц или там на хаскеле типами пообмазываться - это же будет комедия.
ЗЫ: и да, вот люди с такими по современным меркам безумными и невозможными навыками тогда могли рассчитывать зачастую не более чем на стажировку за еду. Это к вопросу о том как сейчас сложно устроиться.
По моему опыту, лучше всего работает просто поболтать с соискателем про его опыт
15-20 лет назад так и делали. Но тогда в индустрию не приходило случайных людей - и средненький джун после универа имел квалификацию выше, чем сейчас имеют в среднем сеньоры.
Но рынок изменился, и теперь проще сразу попросить человека развернуть бинарное дерево, убедиться, что он профнепригоден, и не продолжать этот цирк с конями.
И в идеале ещё щепотку тестового задания в живом режиме, ничего серьезного, никаких там алгоритмов, никакой бумаги и т.д. Условно может ли человек например форму отправить с помощью JavaScript или там вставить данные в БД с помощью PHP и т.д.
Подобные умения как раз скорее минус для кандидата чем плюс, обычно. Если человек помнит всякие ненужные в реальной работе вещи вроде апи, то, значит, он не помнит что-то другое - нужное. В силу ограниченности ресурсов.
Но снаружи, глядя на эти "коробочки" - костяную и железную - можно чисто модельно сказать, что принцип работы одинаковый.
Ну так и у лошади с истребителем принцип работы одинаковый. И то и другое - транспортное средство, которое работает на энергии, полученной при окислении кислородом углерода, загружаемого в данное ТС в составе органических соединений (топлива). И да, мы не знаем на каких принципах работает мозг. Знаем только про работу его самой простой и примитивной части - нейронной сети.
Разве не аналогичность физических процессов в двух "нейросетях" опровергает возможность ИИ научиться программировать не хуже человека?
Разница не в физических процессах, а в принципах работы. Логических.
Опровергать возможность не требуется, требуется ее доказывать. То, что завтра могут к нам прилететь инопланетяне и подарить вечный двигатель - тоже ни как не опровергается. Или то что случится зомби-апокалипсис. Или то что нами всеми управляют жидорептилоиды. Но мы всерьез не обсуждаем все эти _возможные сценарии_.
И с сетками ситуация несколько иная чем с инопланетянами. Если отсутствие инопланетян не доказано, то вот то, что сетки (по крайней мере текущей архитектуры) ИИ быть не могут - математический факт. Трансформер - это фидворвард сеть из начала 80-х (да, трансформеры - гигантский шаг назад в развитии нейронок, от молотка вернулись к палке-копалке, по сути), можно очень условно считать его рекуррентной сетью (если считать рекуррентной связью отправку результата на вход при генерации последующих токенов). Рекуррентная сеть - это конечный автомат. Не больше и не меньше. Поэтому такая сеть не может (и никогда не сможет) решать ни какую из тех задач, которые не может решить КА - например, умножать числа. Или парсить арифметические выражения (да и вообще проверять балансировку скобочек). И много чего еще. На самом деле, все даже еще хуже - дело в том, что МТ у нас универсальные бывают, а вот КА - нет. Поэтому конкретная нейросеть кроме того, что не может решить те задачи, которые не может решить КА, не может решить еще и множество тех задач, которые какой-то КА решить может.
Тут есть некое непонимание в плане того, что способности демонстрируемые сетью _не являются_ свойствами сети. В сетке нет ни чего магического, это все не результат устройства сети и ее архитектуры. Все, что делает сеть - это аппроксимирует некую функцию. И все наблюдаемые свойства - это свойства данной функции. Не сети. В нашем случае эта функция - функция распределения токенов в обучающей выборке. Именно в ней все и содержится. Именно она оказалось структурно сложнее и содержательнее, чем мы полагали. И вместо сети мы можем взять _любую другую_ аппроксимацию - она будет выдавать тот же результат. Можете, например, аппроксимировать полиномами - они тоже универсальны. Будет у вас один огромный полином предсказывать следующий токен. Полиномы теперь умеют программировать? Здесь изначальная ошибка в нейминге - есть нейросеть в мозгу, и есть "искусственная нейронная сеть" (которая, во-первых, практически ни чего с нейросетью мозга по принципам работы не имеет, а во-вторых - нейросеть мозга составляет меньше половины массы мозга так-то). Но люди слышат, что и там нейросеть и тут нейросеть - и им кажется что это что-то одинаково (или хотя бы близко) работающее.
>И что РКН сделает с провайдером, который так напишет?
Ни чего не сделает, естественно. С какой стати ркн в этом случае должен чтото делать и зачем?
>Думаю лет через 5 любая модель выпускаемая любой серьезной конторой будет во многом раз умнее этих и любого человека на планете
Не будет, прогресс в модельках уже не первый год на месте стоит. Это все мертворожденный продукт без практических применений, опенаи упорно пытаются запрыгнуть в уже ушедший поезд. Будущее за небольшмми узкоспециализированными локальными моделями.
>они уже научились нагло врать, сознательно обманывать и защищать себя от отключения всеми доступными способами
Не научились и не научатся.
А как в табах различать например редиез и мибемоль? На скрипке они обычно поразному играются.
>Сначала появились табы для отдельно взятых инструментов, а затем уже ноты для приведения их к единому знаменателю
Эм, нет. Табы предполагают наличие ладов, а безладовые инструменты существенно древнее, не говоря уже о голосе. Так что сперва появились ноты (не равномерно темперированного строч, конечно, другие)
>приведение функционального стиля к процедурному.
Наоборот. колбеки - процедурный стиль, async-await - функциональный.
Напомню, они появились в функциональщине, в 70е. Ни какого жса и питухона в 70х не было. В 90х появился монадический синтаксис для промисов (через который выражался async/await) - тоже в функциональных языках, в 90х. Жса тогда тоже еще не было, а первый питухон вот примерно через годик допилили. К концу нулевых промисы доехали из функциональщины в мейнстрим, еще через десяток лет - в мейнстрим из функциональщины доехал огрызок монадической нотации (async/await). В целом, как я и сказал - выполняется правило о том, что все фичи доезжают мейнстрим через 10-20-30 лет.
Ну пообщайтесь в функциональном коммунити. Только не говорите громко, что лиспы - фукнциональщина, а то вас сочтут долбоебом, простите.
Инвесторов папир по семантикам яп?)) не несите чепухи
Как видим это заумное через 10-20-30 лет потом в мейнстрим и спокйно используется сообществом разработчиков. А потом приходит ednersky и рассказывает о том, что функциональщина НИНУЖНО, хотя практически весь софт написанный как минимум за последний десяток лет плотно на этой функциональщине сидит. Не доводит криокамера до добра.
Все верно, решение проблемы процедурных языков.
Наоборот, callback hell - результат написания в процедурном стиле, а монадки - функциональный.
Это не похожий паттерн и не прототип. Это _буквально в точности та же самая фича_.
Это не слишком логично - впиливать функциональные фичи в язык, чтобы уйти от функциональщины, не находите?
Пайп функций не имеет ни чего общего с функциональный стилем.
Ломающие известия для тех, кто не вылезал последние 20 лет из криокамеры - лиспы давным-давно уже не считаются функциональными языками. Современная (ну как современная - пару десятилетий минимум) функциональщина - это чистые функции и навороченные системы типов с нетривиальными гарантиями. По второму параметру лиспы сразу пролетают, по первому - теоретически могли бы проходить некие scheme-derived диалекты, но с ними проблема в том, что значительная часть лисп-сообщества уже, в свою очередь, не считает такие диалекты труъ-лиспами.
И да, именно поэтому функциональщиной считается, например, раст - он четко проходит по второму пункту, системы типов.
Здесь дихотомия не процедурное - функциональное, а академическое - мейнстрим (просто так уж пошло что почти все современные академические языки - та или инаяфункциональщина).
В мейнстриме никогда не появляется ни чего нового - оно туда приходит из академических языков, с задержкой лет на 10 (20, 30...). Логично, что обратный процесс невозможен - из мейнстримного языка в академический прийти ни чего не может точно так же, как нельзя наполнить полный сосуд из пустого. В академических языках и так все мейнстримные фичи давным-давно есть.
Так вот и вышло с тем же async/await, который десятилетиями мариновался в функциональных языках, и уже не так давно был запилен в C#, откуда потом и распространился по этим вашим питонам с жсами.
&>именно поэтому абсолютно все популярные языки отказались от функционального стиля описания асинхронщины и притащили операторы (или варианты), как писать асинхронный код но в процедурном стиле
Я чтото пропустил и до сих пор у нас callback-hell? Уже давным давно везде отошли от процедурной асинхронщины с ручным пероленьем коллбеками и юзают чисто функциональщиный аналог в виде async/await (это частный случай ду-нотации, утащенный в мейнстримные языки из хакскеля, если вы не в курсе).
Вообще ваши посты почитать - и такое чувство что вы последние лет 10-15 в криокамере провели. Щас 2024, а не 2010, прием.
>что такое функциональный стиль? это когда вы собираете пайп функций
Вы сейчас как раз описали процедурный стиль. То есть вся ваша критика - критика процедурного стиля.
>а потому если можно рекурсию преобразовать к циклам так и поступают
Так поступают только плохие компиляторы. В нормальных компиляторах оптимизируются все хвостовые вызовы, в том числе и нерекурсивные. И ни кто рекурсию в циклы не разворачивает, так как незачем.
Так по факту из любой такой задачки несложно сделать реальную. Взять тот же факториал (или в целом задачки "на рекурсию") - ну ок, написать ф-ю которая принимает дерево, предикат и фильтрует это дерево по предикату. Только если брать вторую задачу то полчаса уйдет на уточнения, граничные случаи и т.п., т.к. кандидат будет всегда какие-то подвохи видеть, когда от него просто хотят чтобы он хоть как-то отфильтровал гребаное дерево) задача про факториал такого недостатка решена
А те, кто пишет что "Х в реальной работе не встречается" - ну тут же все просто, если ты не умеешь использовать молоток, то ты никогда его и не используешь, а соответственно он и "не нужен, не применяется". Здесь своего рода замкнутый круг: не умею применять -> не применяю -> оно не нужно -> раз не нужно, то не изучаю -> не умею применять
Вы исходите из ложного предположения о том, что вопросы, которые задаются на собеседовании, должны каким-то образом "соответствовать" реальным задачам. Это неверно, конечно же. Смысл этих вопросов - отсеять тех, кто заведомо профнепригоден, причем максимально эффективно - чтобы потратить минимум времени как специалиста, который проводит собеседование, так и времени самого кандидата.
Если человек не может написать факториал или развернуть строку - то как программист он ни чего не умеет и полностью профнепригоден. Зачем нужен человек, который не сможет на работе решить ни одной, самой простой задачи? При этом на то, чтобы задать такой вопрос достаточно буквально полминуты-минуту. К чему выдумывать другой вопрос, на который придется давать вводные полчаса, и который даст те же результаты?
Чтобы получать как в фаанг, нужны и компетенции соответствующие, а тут люди строку не могут развернуть на php. Знакомые мне люди, которые в фаанг устраивались джунами, могли бы без проблем не только на пхп ее развернуть - а еще следом на каком-нибудь ассемблере, и в хаскеле на типах в компайл-тайме, при чем вообще не сочли бы это задачей, требующей включать мозг.
Так что всему этому безграмотному непутевому сброду, который тут в комментах пишет про ужасно, несправедливо сложные собеседования, где от мидла требуют способность написать fizz buzz, до зарплат фаанга - как рогозину до марса. Их в компанию подобного уровня подметать полы ни кто не взял бы с таким уровнем экспертизы.
>А body у GET запросов не предусмотрен
Вообще говоря, его изначально ни кто не запрещал обрабатывать, т.е. гет запросы с боди ни как не нарушали и не нарушают стандарт.
Я и говорю - это просто глупость, которую один дурак когда-то сказал, а остальные дураки - повторяют.
На самом деле риски по мелким задачам существенно крупнее, чем по большим. Это достаточно очевидно. Но даже если их не считать больше, а считать такими же - то в итоге для большой задачи оценка будет точнее все равно.
Если у вас есть несколько одинаковых независимых случайных величин с положительным матожиданием, и вы их будете суммировать - то матожидание растет линейно от n (количества задач), а стандартное отклонение - пропорционально корню, с-но точность оценки растет пропорционально корню от размера задачи (на самом деле даже не самой оценки - а в принципе неопределенность в сроках уменьшается, с-но уменьшается и неопределенность в оценке).
Это как бы очевидно и на конкретных примерах - допустим, у вас есть задача на два часа. Если вдруг случится какой-то несущественный риск - то вместо 2 часов будет 4 часа, это 100% отклонения. И такие отклонения для задач подобного размера - обычное дело, они постоянно происходят и на них особ внимания ни кто не обращает. С другой стороны, если у вас задача на год, то 100% отклонение крайне маловероятно (и считается уже не нормой, фактически это проваленный проект в 9 случаях из 10).
Точность оценки в случае маленьких задач возникает просто из-за того, что они лучше и подробнее поставлены - любая неопределенность в постановке всегда закладывается в риски, т.е. в + к оценке, что снижает точность. Маленькие задачи же ставятся конкретно, что снижает неопределенность. Если же большая задача и маленькая поставлены одинаково - то для большой задачи ниже риски, с-но точнее оценка.
>Большие задачи потому и делят на много маленьких, потому что оценка маленьких задач всегда будет точнее
Не поэтому, на самом деле, это лишь распространенное заблуждение. На самом деле все точно наоборот - чем меньше задача, тем менее точной будет оценка, в силу того что риски не усредняются.
И все вышеперечисленные технологии резко уменьшили уровень знаний, необходимых для решения проблем. Теперь не надо быть цсс-нинзей, чтобы выровнять один сраный элемент, т.к. благодаря современным фичам все just in works одной строчкой. Не надо курить многотонные мануалы по разворачиванию окружения - достаточно пару раз сделать ctrl+c ctrl-v в терминал и в докере все само поднимется. Не надо изобретать какие-то сложные архитектурные подходы для того чтобы привнести интерактивности в интерфейс - за тебя все сделают фрейморвки.
Современные инструменты разработки в типичных случаях просто берут на себя 90% всех знаний и умений. Достаточно тыкнуть пару кнопок и оно все само заработает. На магии.
Не знаю, что там на счет пилотов, но врача за эти 10 лет вы точно не выучите. Да и за 20. И за 30 - сомнительно. Вы же не забыли, что мы не о фуллтайм обучении в юности, а об обучении взрослого, 30+ вкатуна, которому удается иногда выделять на обучение часик-другой в перерывах между семьей/работой/етц.?
Да в любой крупной компании. Джуна в принципе сейчас найти практически невозможно, нет их на рынке. Логично, что отсутствие предложения ведет к росту цен.
Ну так это не джуны откликаются и не джуновская вакансия.
Именно про пользователей мы и говорим. Разработчик - это пользователь средств разработки. И эти средства становятся проще с каждым годом - не "внутри", а именно для пользователя проще.
Нет, это просто глупая выдумка.
Ну как нет? Есть. Любой нормальный выпускник хорошего вуза по айти специальности является таковым.
Так ни кто не утверждал. Речь была о программистах _без опыта_. Именно это ключевой водораздел был в том время. Не имеешь опыта работы - изволь работать за еду первые месяцы, а потом уже можешь трудоустроиться нормально.
И написание этого кода требовало на порядок более высокой квалификации, чем нашлепать формочки на реакте.
Что именно это "прочее, прочее и прочее" то?
Современная верстка с адаптивностью и мобилками просто в разы проще того ада, с которым приходилось работать людям в конце нулевых.
Ну это же очевидная глупость, которая опровергается обыкновенным здравым смыслом. Технологии _всегда и везде_ развиваются в сторону упрощения (= снижения требований к квалификации пользователя), поэтому объем требуемых знаний неуклонно снижается. Если кто-то придумает более сложные, чем уже есть, методы/инструменты/подходы разработки - то их просто не станут использовать. А то, что в итоге используют - оно всегда проще. Написать интернет-магазин в 2024 намного проще и требует существенно меньшего набора знаний и навыков, чем было в 2014, а в 2014 - было проще, чем в 2004. А в 2004 проще, чем в 1994.
Поэтому если сейчас из криокамеры вылезет программист, который в 2004 туда сел, то он за выходные поскролит доки и с понедельника спокойно выйдет на работу, не имея ни каких проблем. Вы даже не поймете по его работе, что он из 2004. Т.к. он обладает абсолютно всеми навыками и знаниями, необходимыми для эффективной разработки в 2024. Если же современного фреймворк-сениора отправить в 2004 - хорошо если за месяц он сможет поднять сервер, отдающий хелло ворлд. Потому что он не обладает необходимым навыками и знаниями для разработки в 2004. И мануалы курить не умеет - а стековерфлоу в 2004 еще не изобрели.
Это даже в 1994 не было заявкой на успех. У вас какое-то странное представление о тех временах, будто тогда по городам телеги с лошадями ездили.
Тогда уже были сложные учетные системы на предприятиях, ввести что-то там куда-то там, которое благодаря автоматизации сделает чего-то там и распечатает что-то там - не было ни каким рокетсаенсом. И сейчас не то чтобы эти системы изменились, каким-то невиданным функционалом не обросли - по итогу они делают то же самое и так же. Их просто стало намного проще и дешевле разрабатывать.
Если человек изучал язык с ручным управлением памяти (а он изучал почти наверняка), то про списки и бинарные деревья он знает в девяти случаях из десяти. В оставшемся одном случае из десяти он без каких-либо проблем решит задачку, если ему сказать определение бинарного дерева. Там тривиальный алгоритм на несколько строчек.
Так и воспринималось. Это сейчас джуны всем нужны и к работодателю дверь с ноги открывают, а тогда "без опыта" было черной меткой. Люди буквально на минималку соглашались идти, чтобы полгодика поработать и получить отметку в трудовой.
Так это же не джуновская зп.
Это что за комедия?) Дешевле 100к вы джуна сейчас не найдете, а в целом и на 150+ джуны устраиваются. Я джунов имею ввиду, естественно, а не выпускников курсов, которым до джуна учиться надо 10 лет.
ЗЫ: вот кстати статья с хабра по зп за 2011:
https://habr.com/ru/companies/pruffi/articles/120633/
Здесь должны выполняться несколько условий:
не должно быть возможности отфильтровать кандидатов заранее, повысив "качество" исходной выборки
нельзя собеседовать следующего кандидата до того, как полностью отвергнут предыдущий
надо максимизировать качество кандидата
Ни один из этих пунктов в найме не выполняется - мы _можем_ улучшить качество выборки, мы _можем_ переходить к следующему кандидату до того, как отвергли предыдущего (и даже опрашивать нескольких одновременно), и нам не нужен с максимально ожидаемыми скилами - нам нужен первый, кто нас устраивает (или даже сразу все). Исходя из этого, процесс найма и устроен.
Если вернуться к вашей аналогии с оркестром - допустим, нам в оркестр понадобилась скрипка, пришло на прослушивание сто человек, и мы знаем, что из них хорошо если десяток вообще хоть раз в жизни видел скрипку ирл. Тогда мы сперва применяем примитивные фильтры - просим, например, продемонстрировать, как кандидат будет держать смычок во время игры. Половина кандидатов берет смычок не за тот конец и идет домой. Потом предлагаем сыграть гамму (без всяких технических изысков вроде там децимами или двойными флажолетами - просто гамму, как захочется) - в итоге остается 5 человек, их можно вести на прослушивание.
На самом деле, при отборе в реальные оркестры именно так и происходит - только туда уже на первоначальный отбор приходят люди в айтишной терминологии уровня сениор++, поэтому вместо того чтобы развернуть бинарное дерево (= подержать смычок) их просят быстренько перепрошить микроконтроллер (что-то такое сыграть минуты за 3 чтобы жюри восхитилось и дало возможность пройти по отбору дальше). Ну а потом уже несколько недель подготовки к настоящему собеседованию, и дальше их как раз будут гонять и по скоростной печати, и по навыкам демосцены, и змейку в compile time на типах в хаскеле написать попросят. И тому, кто все это пройдет - предложат по итогу испытательный срок)
Т.е. у таких людей нет смысла просить подержать смычок - они и так умеют, это только время тратить. А вот в ит - смысл есть, натурально половина приходит и не умеет. Потому и задаются все эти вопросы при найме, что - смысл есть, люди действительно умудряются не обладать даже самыми базовыми навыками программирования..
Трава с небом, может, цвет и не поменяла, а вот рынок труда в ит-индустрии поменялся кардинально - и это объективный факт.
Средний джун того времени - это человек, который с детства увлекался ИТ, еще в школе мог на нескольких языках инвертировать бинарное дерево (или уж на первом курсе универа, максимум) и к своей первой работе имел уже опыт программирования под 10 лет (при чем реальный опыт решения сложных инженерных задач, а не перекладывания жсонов), в комбе с глубокими и обширными фундаментальными знаниями. Ну и навыками из разряда быстро поднять ламп (с нуля, руками, без всяких докеров, ессно) и накидать самостоятельно какой-нибудь интернет-магазинчик. Причем это был результат именно фултайм обучения, которое приходилось на самый эффективный в плане восприятия мозгом этап жизни.
Теперь же, в 2024, у нас джун это условный 30+ человек после курсов - ну просто физически, чтобы достичь уровня джуна выше и хоть как-то на равных с ним конкурировать, ему придется потратить не менее 10-15 лет. И это при условии что будет эти 10-15 лет мотивация серьезно вжобывать. Попроси у такого современного "фронтенд сениора" написать гц или там на хаскеле типами пообмазываться - это же будет комедия.
ЗЫ: и да, вот люди с такими по современным меркам безумными и невозможными навыками тогда могли рассчитывать зачастую не более чем на стажировку за еду. Это к вопросу о том как сейчас сложно устроиться.
15-20 лет назад так и делали. Но тогда в индустрию не приходило случайных людей - и средненький джун после универа имел квалификацию выше, чем сейчас имеют в среднем сеньоры.
Но рынок изменился, и теперь проще сразу попросить человека развернуть бинарное дерево, убедиться, что он профнепригоден, и не продолжать этот цирк с конями.
Подобные умения как раз скорее минус для кандидата чем плюс, обычно. Если человек помнит всякие ненужные в реальной работе вещи вроде апи, то, значит, он не помнит что-то другое - нужное. В силу ограниченности ресурсов.
Если под ии понимать ллм, то они просто генерируют следующий токен. Это точно не то, как работает человеческое мышление.
Ну, кстати, есть гипотеза о том, что мышление содержится именно в эмп создаваемом мозгом)
Ну так и у лошади с истребителем принцип работы одинаковый. И то и другое - транспортное средство, которое работает на энергии, полученной при окислении кислородом углерода, загружаемого в данное ТС в составе органических соединений (топлива). И да, мы не знаем на каких принципах работает мозг. Знаем только про работу его самой простой и примитивной части - нейронной сети.
Разница не в физических процессах, а в принципах работы. Логических.
Опровергать возможность не требуется, требуется ее доказывать. То, что завтра могут к нам прилететь инопланетяне и подарить вечный двигатель - тоже ни как не опровергается. Или то что случится зомби-апокалипсис. Или то что нами всеми управляют жидорептилоиды. Но мы всерьез не обсуждаем все эти _возможные сценарии_.
И с сетками ситуация несколько иная чем с инопланетянами. Если отсутствие инопланетян не доказано, то вот то, что сетки (по крайней мере текущей архитектуры) ИИ быть не могут - математический факт. Трансформер - это фидворвард сеть из начала 80-х (да, трансформеры - гигантский шаг назад в развитии нейронок, от молотка вернулись к палке-копалке, по сути), можно очень условно считать его рекуррентной сетью (если считать рекуррентной связью отправку результата на вход при генерации последующих токенов). Рекуррентная сеть - это конечный автомат. Не больше и не меньше. Поэтому такая сеть не может (и никогда не сможет) решать ни какую из тех задач, которые не может решить КА - например, умножать числа. Или парсить арифметические выражения (да и вообще проверять балансировку скобочек). И много чего еще. На самом деле, все даже еще хуже - дело в том, что МТ у нас универсальные бывают, а вот КА - нет. Поэтому конкретная нейросеть кроме того, что не может решить те задачи, которые не может решить КА, не может решить еще и множество тех задач, которые какой-то КА решить может.
Тут есть некое непонимание в плане того, что способности демонстрируемые сетью _не являются_ свойствами сети. В сетке нет ни чего магического, это все не результат устройства сети и ее архитектуры. Все, что делает сеть - это аппроксимирует некую функцию. И все наблюдаемые свойства - это свойства данной функции. Не сети. В нашем случае эта функция - функция распределения токенов в обучающей выборке. Именно в ней все и содержится. Именно она оказалось структурно сложнее и содержательнее, чем мы полагали. И вместо сети мы можем взять _любую другую_ аппроксимацию - она будет выдавать тот же результат. Можете, например, аппроксимировать полиномами - они тоже универсальны. Будет у вас один огромный полином предсказывать следующий токен. Полиномы теперь умеют программировать?
Здесь изначальная ошибка в нейминге - есть нейросеть в мозгу, и есть "искусственная нейронная сеть" (которая, во-первых, практически ни чего с нейросетью мозга по принципам работы не имеет, а во-вторых - нейросеть мозга составляет меньше половины массы мозга так-то). Но люди слышат, что и там нейросеть и тут нейросеть - и им кажется что это что-то одинаково (или хотя бы близко) работающее.