*е
как хобби это очень интересно может быть
>новом ЯП
На каком?
почему ты хочешь совершенствоваться к рамках кода, который никто не видит, а не визуальной части?
Луа.
Рисование и моделинг это не мое. Просто нравится.
Изначально вкатывался ради денег, а потом проникся.
Только ситхи возводят все в абсолют
Вообще это зависит от того что ты считаешь "функциональным программированием". По моему опыту если ты можешь вынести кусок кода в функцию которая не зависит от внешних переменных (а именно это и есть функциональный кусок) то это в какой то степени упрощает понимание и работу с такой функцией. И тебе ничего совершенно не мешает тебе в методах класса вызывать такие функции.
Целиком все приложение писать на таких функциях? Как будто бы зачем, что бы что?
Делай так, что бы легко заменять куски функционала и легко понимать что написано, это ж две основные потребности. Как ты их закрываешь не важно.
Пруф ми вронг.
>Пруф ми вронг.
Нет инкапсуляции на уровне языка, да и классов в привычном понимании.
И что делать?
Инкапсуляция это просто термин который описывает механизм при котором ты объединяешь данные и методы которые работают с этими данными в один объект - класс. Благодаря инкапсуляции у тебя просто есть такая штука как класс.
То что у тебя поля в классе приватные это не инкапсуляция. Приватные поля это хорошо только потому что когда ты читаешь или меняешь поведение по требованию заказчика тебе не нужно беспокоится о том что они меняются где то еще, ты себе контекст понимания таким образом упрощаешь.
В каком то смысле функциональная функция которая не работает с внешними переменными это твоя идеальная "инкапсуляция" как ее понимаешь онкретно ты - у тебя все переменные изолированы внутри функции (даже не внутри класса), и твой контекст для понимания и изменений еще меньше чем в классе.
я перечитал еще раз и возможно не ответил на твой вопрос в первый раз.
Если я правильно его все таки понял во второй раз -то если у тебя нет такого понятия как класс и вопрос стоит как "делать глобальные переменные снаружи функций или не делать"? Ответ - не делать, хуй разберешься потом. Делай все на "функциональном программировании" да, это будет правильно
Ну или если я два раза мимо то поясняй че не так то?
Если я правильно его все таки понял во второй раз -то если у тебя нет такого понятия как класс и вопрос стоит как "делать глобальные переменные снаружи функций или не делать"? Ответ - не делать, хуй разберешься потом. Делай все на "функциональном программировании" да, это будет правильно
Ну или если я два раза мимо то поясняй че не так то?
Да.
Я просто не настолько грамотный, опираюсь больше на интуицию.
Изначально вообще пытался эмулировать все на хэш-таблицах, у которых были в качестве значений функции.
Но у меня в итоге вся память потекла.
Алтьтернативная реализация и принятая практика выглядела как-то разорванно, не целостно.
А функции как тип данных и поддержка замыканий наталкивали ознакомиться с фп как к спасению.
Всё кринж, кроме ассемблера. Ну или батрачка на бизнес за бабло - но там твоя хуйня точно не нужна.
Дебилы не видят разницы между процедурным и функциональным программированием, но пытаются строить из себя дохуя крутых специалистов в ITT.
Штангу поднимешь?
Ну а че делать, пиши как принятно +-. Не знаю что за яп но создать примитивные типы данных как на первой картинке как будто база. Создавать их что бы юзать как бизнес логику как в ооп - явно не стоит.
Юзать замыкание для коллбэков тоже база.
А баловаться передачей функций уже ведет запутыванию как по мне, заебешься читать это потом.
Ну высри свое мнение, здесь все свои, вдруг что дельное скажешь, интересно же
чувак а ты точно понимаешь что такое функциональное программирование? это если че - вот это -
```
import qualified Data.Map.Strict as M
twoSum :: Int -> [Int] -> Maybe (Int, Int)
twoSum target xs = go M.empty 0 xs
where
go _ _ [] = Nothing
go seen i (x:rest) =
case M.lookup (target - x) seen of
Just j -> Just (j, i)
Nothing -> go (M.insert x i seen) (i + 1) rest
```
а вообще какая хрен разница? Главное, чтобы код выполнялся с определённой выгодой в плане ресурсов.
Да, если нужен максимально проверяемый в статике код. Императивные говнокодеры часто как правило херачат лапшу из сайд-эффектов, никто не может заранее знать как она будет работать, и не отъебнет ли в рандомный момент.
Главное что бы он денюжку приносил и тебе за него заплатили ващет. А для этого изволь вносить правки и пилить новые фичи. А для этого или ллмка или сиди сам разбирайся пиши. А для этого заранее пиши что бы тебе потом понятно было че написано и не было боль дырка в заднице внести правку не сломав к хуям что уже работает. Вот что главное ящитаю
>Функционально программирование норм тема или кринж?
Норм братюнь, вкатывайся https://2ch.su/ai/res/1653365.html
но функциональный код требует больше когнитивных ресурсов на обслуживание, потому что путь кода ты должен держать в голове.
> Рисование и моделинг это не мое
А причём тут roblox?
представили ебало даунов, которые пишут код нейросетями?
Представляешь ебло где я четыре игры выпустил благодаря нейросетям
Типа ты злишься что мы можем тратить на месячную подписку 200 баксов и лутать с этого от 500к?
>А причём тут roblox?
О, для тебя у меня тоже есть
Разве не лучше выпустить одну на миллиард, чем четыре на миллион?
меня ваши копейки в найме не волнуют, я кабанчик. Если вы уж имеете страсть писать код, так пишите руками. Код - это искусство.
Нет, у меня рука хуево оправилась после перелома.
> я кабанчик.
Лукавишь) Ой щегол лукавишь... Настоящие начинающие кабанчики только в бизаче сидят, но не в бэ
Обычно на фп делают ядро, которое должно быть железобетонными, а всю обвязку отдают императивным мартышкам.
Сколько денег всего на них заработал?
потому что я любитель лавандового рафа, а не скуф кабан.
давайте не будем его шеймить. То, что он сделал, уже круто.
пук
* Luau
Компактней джавы?
У функционального программирования есть склонность впадать в мозгоёбство, любую хуйню преподносят как какое-то откровение, на любой чих - пейпер, засидишься в чатике функциональщиков, и тебя затянет в пучину элитарности, ты же не какой-то деревенщина, чтобы писать прикладные программы, мы здесь обсуждаем верификаторы и теорем-пруверы.
Это ты своих погромистов фиксиками называешь?
нет.
Да, чатики функциональщиков - это такое дело.
Там у каждого кто сидит в чатике, в голове есть внутренний цензор, который задаётся вопросом "достаточно ли элитарно то, что я собираюсь запостить? достаточно ли функционально?"
И в итоге никто ничего не постит, и в чатике тишина.
Ну или обсуждают какую-то элитарную заумную хуйню.
Лучше сидеть в чатиках, посвящённых более конкретным темам, например геймдев, или базы данных там не знаю, а фп - это парадигма, и если собираться вокруг парадигмы, то получается такое мозгоёбство почему-то.
>Насколько программка будет структурированной, если написана в рамках этой парадигмы?
Парадигма не так важна как сам язык. Так всегда у анальников почему-то: имплементации никогда прям не делают как в теории.
Так в лбом чатике такая хуйня, просто упарываются в разное.
Может и так, но у функциональщиков есть особая склонность к элитизму и мозгоёбству.
Хочу попробовать изучить haskell или scheme первым ЯП.
Ну, не считая бейсика в далеком детстве школьном.
Я музыкант и нищий пенсионер, мне нахуй не нужно программирование, в практическом смысле, не нужно вкатываться в ит, не хочу.
Просто мозги себе поебать хочу, заняться чем-то новым, чем-то, что сложнее игрушки типо дарк-соулся, настоящий хардкор.
Номральная идея? Или кринж?
Ну, не считая бейсика в далеком детстве школьном.
Я музыкант и нищий пенсионер, мне нахуй не нужно программирование, в практическом смысле, не нужно вкатываться в ит, не хочу.
Просто мозги себе поебать хочу, заняться чем-то новым, чем-то, что сложнее игрушки типо дарк-соулся, настоящий хардкор.
Номральная идея? Или кринж?
>функциональщиков есть особая склонность к элитизму и мозгоёбству
Например?
>Функционально программирование норм тема или кринж?
Кринж.
зигохистоморфный препроморфизм
Я уж думал тут будет что-то хотябы уровня теоремы Чёрча-Россера, ну ладно.
МОНАДА
О
Н
А
Д
А
О
Н
А
Д
А
Чистое лямда калькулюс... Вот это труъ!
Не то что хаскеллы всякие...
Кринж.
>Луа
Кал.
>Чистое
Мне кажется, это называется безтиповое или как-то так.
Есть и такое и такое, не?
Но я мог перепутать, я лох
По Хаскелю есть много материалов, можешь попробовать "Haskell from first principles" by Christopher Allen and Julie Moronuki, книга для начинающих, насколько я помню, там прикол в том, что со-автор тня, которая не знала Хаскель и ФП, и когда что-то ей было не понятно в тексте, то они его переписывали, пока не становилось понятно.
>Haskell from first principles" by Christopher Allen and Julie Moronuki,
Спасибо! А я уже потихоньку начал через всеми расхайпленный "Learn You a Haskell for Great Good!"
Еще и линукс себе поставил специально под это дело, тоже время ушло на освоение основ и настройку
Имею опыт в разработке на окамле, не вижу там какой-то илитарности яп как яп для своих задач.
>мы здесь обсуждаем верификаторы и теорем-пруверы.
Це ж не имеет отношения к фп in the first place.
>Це ж не имеет отношения к фп in the first place.
Не имеет?
Знаю один чатик, который захватили любители верификаторов и теорем-пруверов.
Получается их надо прогнать?
>Имею опыт в разработке на окамле, не вижу там какой-то илитарности яп как яп для своих задач.
>Знаю один чатик, который захватили любители верификаторов и теорем-пруверов.
>Получается их надо прогнать?
> я четыре игры выпустил благодаря нейросетям
Кому твое высранное говно нужно? Никому. Потому что ты сам хуесос бесполезный нейрослопный
>Представляешь ебло где я четыре игры выпустил благодаря нейросетям
А сколько читалок с дежавю?
Я угадаю: ты переходишь на Rust, Go, Elixir или даже современный TypeScript, пытаешься запихнуть туда паттерны из Java/C# (фабрики, абстрактные классы, инъекции зависимостей через конструкторы) и чувствуешь, что язык тебе сопротивляется. Это классическая ошибка.
Если ты пишешь на новом ЯП в ООП-стиле, ты борешься с языком.
В Rust нет наследования — это сделано, чтобы ты использовал трейты и композицию.
В Go нет классов — это заставляет тебя писать маленькие интерфейсы и функции.
Как перестать страдать и сделать структуру крутой:
Забудь про «объекты с состоянием». Сделай структуры/записи только для хранения данных (DTO). Вся логика — это функции, которые принимают эти структуры и возвращают новые.
Введи «границу». В ФП есть железное правило: I/O on the edges, pure logic in the middle. Ввод-вывод (чтение БД, запросы в API, печать в консоль) делай только на входе и выходе из программы. Внутри работай с неизменяемыми данными и чистыми функциями. Тогда структура становится идеальной — бизнес-логика не знает, откуда пришли данные.
Используй Result / Option вместо null и try-catch. Это принудительно структурирует твой код, заставляя обрабатывать ошибки на каждом шаге конвейера, а не ловить их где попало.
А нахуя тебе инкапсуляция на уровне языка и классы? Структуры во всех языках есть. Пиши структуры + функциии, принимающие указатель на структуру в качестве первого аргумента. Вот тебе и класс. Для инкапсуляции пользуйся пимплом. Захочешь полиморфизма - ну вот тут поебаться придется, придется виртуальную табличку запилить. Это на самом деле не так сложно. Наследование придется заменить иньекцией (и добавить массу бойлерплейт кода, которая поднимает функции родителя на уровень потомка). Ну а хули ты хотел, пишешь на тупом языке получаешь тупые проблемы.
Итого ты можешь писать в ооп-стиле хоть на ассемблере.
Дружище кринж это в 2к26 руками там структурировать код и вообще его читать, когда нейронка за день генерит объёмы кода команды 3ёх человек за пол года.
Кринж, когда используется не по делу (99% случаев). Хотя некоторые принципы и в процедурном охуенно работают, типа юзать чистые функции и т.п.
>за день генерит объёмы кода команды 3ёх человек за пол года
Представляю, какой там у тебя лютый кал. Она с одной задачкой на одну человеконеделю-то справляется не всегда с первого раза, а ты предлагаешь тонны высирать, которые никакого терпения не хватит проверить.
>Она с одной задачкой на одну человеконеделю-то справляется не всегда с первого раза, а ты предлагаешь тонны высирать, которые никакого терпения не хватит проверить.
Дружище, я работаю в мировой фирме, проект хай лоад. Все таски руками не пишутся уже больше чем пол года как. Задачи уровня создать пачку крудов, под него фронтенд по дизайну, расписать юнит и е2е тесты по шаблону. Паттерн через луп и сварм агентов со скептическим ревьюингом. Через пол дня всё готово в идеальном виде. Ты, как и все что подобное высерает, сидите на каком-нибудь бесплатном курсор говне используя в лучшем случае нейронку как чатик с автокомплитом. Для кого ты там строчки полируешь непонятно, когда вместо тебя придёт нейронка и весь твой легаси калл шизойдный, который ты вымучивал годами, перепишет за 2-3 часа.
>мой барен всем баренам барен
Проиграл с бахвальства крепостного своим бареном
Такой нелепый куопинг. Ещё бы орфографию у меня проверил.
Почему мизантропы любят низкоуровневую сишную/плюсовую хуйню?
> Функционально программирование норм тема или кринж?
Три слова: одноразовая, неотлаживаемая хуета. Все эти мэтчи, монады и прочий блёв заебись для кода который ты написал один раз и забыл про него, но если тебе надо пофиксить баг, то удачи ебстись с этими мудацкими конструкциями.
> Луа.
Так в луа нет нихуя функционального. Я думал ты там на скалу какую нибудь сел
Да тут аноны думают, что функциональное программирование это когда ты пишешь отдельные функции и переиспользуешь их)))
Ето процедурное, и в него не умеет разве что какая то редкая хуета из 60х на готолапше
вы все смешные хуесосиксы, которые пишут код для дяди, а не делают свои проекты.
Хуище, я тоже работаю в такой фирме, перед кем ты выебнуться решил? Нихуя нейронка в идеальном виде не осиливает, или у вас хуевые стандарты идеала, или вы ебашите целые новые направления в продукте, ни с чем предыдущим особо не связанные и поэтому вам похуй как там будет (насирать с нуля - не то же самое, что впилить в старое не наломав дров), или и то, и другое.
>работаю в мировой фирме, проект хай лоад.
Щас бы кичиться тем, что формошлёпишь в большой конторе, будто размер оной положительно сказывается на квалификации обитающих там кодомакак.
Пошёл нахуй!
>перед кем ты выебнуться решил?
>Щас бы кичиться
Я факт сказал, чтобы понятно было, что это стандарт индустрии теперь, а не моё пожелание или шиза старртапа. Ваша же тряска очень показательная. Такое у нищих обычно, они когда видят, что кто-то покупает что-то не по их карману, то они всегда поясняют, что человек дурак, мажор, выёбывается, кичится и т.д.
Да, это стандарт индустрии, кто спорил-то? Только идеально всё равно он не хуярит, нужно доводить до ума. Если тебе не нужно - у меня плохие новости для вашей охуительной конторы, и тем более для тебя - оператора LLM.
80 постов, правильного ответа так и не прозвучало. Внимание, правильный ответ: ты выбираешь парадигму и язык под задачу программы. Скажи, что ты хочешь написать, а только тогда можно будет обсудить, как и на чём это писать.
Двачую.
Ещё раз. Речь шла про то, что какие-то споры о стилях проганья это даже не прошлый век, а средневековье. Это как спорить о гужевых повозках. Нейронки за пару недель делают проект разработки в год и стоимостью в 100к + и абсолютно поебать, что там код не соответствует выбранному тобой стилю или что линтер там не слишком модный сегодня. В 9 случаях из 10 код нейронки будет в разы лучше рандомных мидлов, тупо хотя бы по той причине, что нейрока в нём разобраться может без визгов, что Х пишет не так как Y. Теперь ты решил съехать на то, что оказывается нейронка может сделать БАГ и наверное нужно будет лишние 5 минут провести с клодом, чтобы он его переписал.
Тебе самому не смешно со своего бреда?
Ты сказал
>кринж - руками там структурировать код и вообще его читать
а не, что сейчас пиздишь про стили проганья.
Как без чтения ты собрался выявить БАГ? Или же как ты хочешь читать свои
>объёмы кода команды 3ёх человек за пол года
? Никак? Тогда БАГ придет и выебет тебя, мамкиного вайбкодера, и возможно неоднократно.
>Как без чтения ты собрался выявить БАГ?
Я думал ты не юзаешь нормальные модели, но ты видимо и не прогал никогда ничего. Ничего тупее я в жизни не слышал. Оказывается БАГ выявляется через прочтения кода много раз. Т.е. приходит вот тестеровщик видимо и начинает за прогером код читать и говорит.
>ВАНЬ, ВОН У ТЕБЯ ОШИБКА ЁКСЕЛЬ МОКСЕЛЬ НУ ВОТ В 315 СТРОКЕ
Да, именно так оно и работает.
Может быть сам багфикс и займет всего 5 минут клода, а вот масштаб трагедии, которую баг мог вызвать - может исчисляться сотнями тысяч, если не миллионами долларов.
>Ещё раз. Речь шла про то, что какие-то споры о стилях проганья это даже не прошлый век, а средневековье.
Да, теперь мы спорим о том, отчуждать владение кодом в пользу очень продуктивного проприетарного чёрного ящика, или нет. Появление типочков, предлагающих перестать заглядывать в код — это вообще замечательно. Побольше бы таких ребят нашим конкурентам в штат.
Согласен, ведь всем известно программист то не ошибается в отличии от нейронки. Сразу пишет 100% рабочий код. Тестеровщики и тесты это тупо ради прикола придумали, рофл такой. Бля, вы реально идиоты или как?
Маня, ты продолжаешь закапываться всё дальше. Если у вас такие стандарты кодирования, то и тестировщики я представляю какие из себя. Happy path он тебе протестирует ок, а потом будут бега с горелой сракой в НЕОЖИДАННОЙ СИТУАЦИИ.
>Да, теперь мы спорим о том, отчуждать владение кодом в пользу очень продуктивного проприетарного чёрного ящика, или нет
Толи дело Ванька погромист наёмный работяга. Это конечно не чёрный ящик ни капли. Всегда живой, в любой момент всё расскажет покажет, легаси перепишет. Ага ага. Особенно индус с аутсорса.
Я уже понял выше, что баги только у нейронки. До нейронки багов не существовало. Можешь не продолжать.
Один программист ошибается, 3 ревьюера могут это предотвратить, если они не такие же распездолы как ты. 0 ревьюеров нихуя предотвратить не могут. Тестировщик тоже может проебаться и даже более вероятно, что не учтет все нюансы, потому что в душе не ебет что там под капотом.
Набирая исходный код руками ты приближаешься к богу.
Код сгенеренный нейросетью есть путь к сатане.
Код сгенеренный нейросетью есть путь к сатане.
ООП фактически всегда это убогое говно из жопы. Даунгрейд эффективности в приоритет якобы поддержке кода.
Любой код из ООП-высера это тупо бесконечные прыжки по памяти и раздробленный кэш процессора и обосраная память. В век нейросетей писать в ООП вообще нет никакого практического смысла.
Любой код из ООП-высера это тупо бесконечные прыжки по памяти и раздробленный кэш процессора и обосраная память. В век нейросетей писать в ООП вообще нет никакого практического смысла.
Человек насрал в промпте ошибок.
Нейросеть насрала в выдаче.
Стало ошибок в 2 раза больше.
Очевидно, нельзя исключить человеческий фактор ошибок.
Можно исключить нейросетевой фактор ошибок.
Нейросеть насрала в выдаче.
Стало ошибок в 2 раза больше.
Очевидно, нельзя исключить человеческий фактор ошибок.
Можно исключить нейросетевой фактор ошибок.
Фп это обычная тема, ради интереса можешь попробовать, но работы нет
мимо пишу на скале говнокод
Мой код ревьют 3 агента на ПР. Дополнительно 1 смотрит е2е. Ещё по 2 на каждой итерации из дева в тест и из теста в прод. С расписыванием фичей в артефактах и генерации комментариев в таски для тестировщика. В нескольких репах по 200-300 строк в пре. Теперь расскажи кто такие объёмы у тебя ревьюит? Ах да, у тебя видимо нету таких объёмов, ты по старинке руками делаешь 2-3 коммита в день на 5 строк идеальный пьюр функций функционально правильного кода и потом, видимо, тимлид пол дня их разбирает.
>Хмммм а может стоит тут переназвать функцию?
>Ой а вот тут у вам не тот кейс
Удачи, далеко пойдёте. В каком году сможете туду лист закончить наверное для пет проекта? Позови моих внуков на релизе глянуть, если живи будут ещё.
А если по клавиатуре мимо попадать, то вообще софт не заработает, прикинь? Лучше тогда в дворники идти, чтобы ошибок не было.
Нейрохуета ошибается сильно реже чем человеческая макака. Да и те места где ошибается это не галлюцинации нейрозалупы а просто в моменте проёбанный контекст.
Собственно объём уязвимостей и багов найденных нейронкой в топовых опенсорс проектах которые юзают миллионы - говорит сам за себя.
>А если по клавиатуре мимо попадать, то вообще софт не заработает, прикинь?
Смелое заявление.
Подозреваю, что есть такие ЯП, к которым возможно набирать исходный код, просто стуча по клавиатуре бананом.
Лол, да хоть 100 агентов поревьюит, бывают такие неочевидные хуйни, которые не полезут в контекст никакому агенту на данном этапе, а человек легко это заметит.
>В каком году сможете туду лист закончить наверное для пет проекта? Позови моих внуков на релизе глянуть, если живи будут ещё.
Так ещё год назад так кодировали и ничего, никто не умер, нет задачи быстро обосраться поносом, качество превыше всего.
>а просто в моменте проёбанный контекст
= просто нейронка проебалась. Ну ничего, пару сотен туда, пару сотен сюда - считай бизнес-расходы.
>Нейрохуета ошибается сильно реже чем человеческая макака.
Так-то это верные данные, с этим не поспоришь.
Но всë же проблема в том, что даже если 100% кода написано нейронкой верно, и нет ошибок в коде нейронки, это не отменяет наличия ошибок, созданных человеком.
>Толи дело Ванька погромист наёмный работяга.
Манера речи выдаёт в тебе человека, не способного без кривляний отстаивать свою позицию.
После опытного разработчика, у тебя остаётся код, в котором другой опытный разработчик способен ориентироваться, не испытывая при этом избыточной когнитивной нагрузки. После ллм — твоя кодовая база выглядит так, будто её писала сотня джунов, толкаясь локтями.
>которые не полезут в контекст никакому агенту на данном этапе, а человек легко это заметит
Верю. Примера конечно не будет.
>Так ещё год назад так кодировали и ничего
Помню времена, когда уже обосновались вполне фреймворки, всякие гитхабы, докеры, фронты, джанги, битриксы, расты. Стали стандартом. При этом на ХХ переодически видел резюмехи типа
>Делаю сайты в джумле
>владею АШТЭМЕЛЬ, ЦЭ ЭС ЭС
>Навыки: php + джей кьюри
Я вот тогда думал. Ну что это за люди? Они не видят куда поезд едет? Они не понимают, что остануться неудел в какой-то легаси помойке нищей? Годы идут, ничего не меняется.
Удаленного рабочего стола тред
>просто нейронка проебалась. Ну ничего, пару сотен туда, пару сотен сюда - считай бизнес-расходы.
Это же не в слепую делается, всё равно результат контролирует мясная макака и всё обмазывается тестами.
Да и сейчас ИИ работает в очень ограниченном окне контекста и разрабы вынуждены юзать всякие вело-костыли в виде RAG/вики/компрессии/агентов из-за чего нейронка постоянно работает в режиме недостатка информации и предположений. В будущем нейронки смогут вмещать в себя миллиарды токенов контекста и такой проблемы уже не будет в принципе.
>Манера речи выдаёт в тебе человека, не способного без кривляний отстаивать свою позицию
На нелепые аргументы без кривляний реагировать невозможно. Не надо писать хуйню в духе
>НИРОНКА ОШИБАЕТСЯ А ПОГРАМИСТ НЕ ОШИБАИЦА!
тогда и кривляний не будет
>После опытного разработчика, у тебя остаётся код, в котором другой опытный разработчик способен ориентироваться
Легаси выдумка, так и запишем. В очередной раз безошибочгный идеальный программист пишет безошибочный код. Никогда такого не было, что приняли код после сотрудника, а он лапшичное ифэлс говно. Индусов тоже нету, аутстаф страшилка цру, хардод придумали в застенках кремля. Всё понятно.
Я ухожу из треда, пошел ты на хуй ‼️
>Верю. Примера конечно не будет.
Да банальный пример - нейронка пиздит, что ряя у вас будут orphaned records в БД, если вы здесь не поставите вот эту автоудалительную залупу, но в её тупенькую голову не помещается, что у нас есть кастомный эффективный клинап, который всё это хендлит, если не ткнуть её туда носом только.
>Они не видят куда поезд едет? Они не понимают, что остануться неудел в какой-то легаси помойке нищей? Годы идут, ничего не меняется.
Да мне как-то уж поебать в какой я там помойке, куда там поезд, лишь бы деньги платили. Мы используем нейронки с умом, без крайностей. Если смотреть куда идет твой поезд, то ты сам уже нахуй не нужен за телевизором, можешь увольняться, рой агентов тебя порешал. А мы будем в легаси загнивать дальше по одному PR в день, кастомеры-то никуда не денутся, им тоже переучиваться на новую кривую-косую хуету вайбкодерскую не хочется.
>Дружище кринж это в 2к26 руками там структурировать код и вообще его читать
Если ты не читаешь код, как ты находишь баги? Чтение кода — это не самоцель, а необходимость для рефакторинга и поиска причин сбоев. Генерация объема не заменяет понимание логики.
Нейронка генерирует среднестатистический код, который прошел обучение на открытых репозиториях. Он хорош для CRUD-шаблонов, но ужасен для нестандартной высоконагруженной архитектуры, где нужно учитывать специфику железа и кэшей.
>а человек легко это заметит
>у нас есть кастомный эффективный клинап, который всё это хендлит
Очень хотелось бы увидеть человека, который придёт к вам работать и по наитию сразу лего это заметит, как ты писал.
>если не ткнуть её туда носом
Удивительно как человек что-то срёт про нейронки, но не может пользоваться банальным её функционалом. Например единственный раз прогнать весь проект и создать для нейронки базу знаний по модулям, важные вещи записать в мемориз. При этом удивляется, что нейронка не смогла сразу вычислить какой-то костыль ебучий самописный.
>Мы используем нейронки с умом
Ору.
> как ты находишь баги?
Баги находят тесты, тестировщик и юзеры. Как можно, блять, баги найти через прочтения кода? Ты ебобо?
>Нейронка генерирует среднестатистический код
Советую перестать жить в 2022-23 годах, попробовать что-то новое.
>Если ты не читаешь код, как ты находишь баги?
По визгам саппорта в слаке, по беготне в коридоре, по экстренным созвонам.
>На нелепые аргументы без кривляний реагировать невозможно.
Я же реагирую.
>Легаси выдумка, так и запишем.
Легаси — это не синоним write-only кода.
>В очередной раз безошибочгный идеальный программист пишет безошибочный код.
Это не мой тейк.
>Никогда такого не было, что приняли код после сотрудника, а он лапшичное ифэлс говно.
Там, где такое происходит — можно смело отчуждать код в пользу ллм. Хуже не станет.
>Индусов тоже нету, аутстаф страшилка цру, хардод придумали в застенках кремля.
Ты сейчас бравируешь тем, что ллмы пишут код лучше полных дегенератов? И это повод целиком доверить им написание кода?
>Всё понятно.
Мне, в общем-то, тоже.
>Ты сейчас бравируешь
Я бравирую тем, что ты ллм противопостовляешь выдуманного у себя в голове швятого неполживого безошибочного программиста, который работает за идею, каждый день переписывает код на ап ту дейт. Всё кто не являются такими - у тебя дегенераты.
> программировать в ручную в 2027
На этом, собственно, можно разговор заканчивать. Успехов тебе в осваивании профессии.
>Очень хотелось бы увидеть человека, который придёт к вам работать и по наитию сразу лего это заметит, как ты писал.
А нам не нужен такой человек, когда есть достаточно людей, которые в курсе как там всё устроено. Код не обязан быть нейронно-среднестатистическим пока bus factor > 2 хотя бы и пока он эффективен, есть кривая обучения специфике проекта, которая в текущем виде не лезет в башню нейронки целиком.
>Удивительно как человек что-то срёт про нейронки, но не может пользоваться банальным её функционалом. Например единственный раз прогнать весь проект и создать для нейронки базу знаний по модулям, важные вещи записать в мемориз.
Вся хуйня не лезет в мемориз, они тупо рандомно отваливаются и нихуя с этим не сделать.
>При этом удивляется, что нейронка не смогла сразу вычислить какой-то костыль ебучий самописный.
Самописные костыли разной степени ебучести есть почти в любом проекте, если это не тот самый туду лист миллион раз задроченный. И даже он при достаточных масштабах будет иметь самописные костыли.
>Как можно, блять, баги найти через прочтения кода?
И ты всерьёз считаешь себя программистом? В прошлом году тебя к компуктеру только допустили?
>Это же не в слепую делается, всё равно результат контролирует мясная макака и всё обмазывается тестами.
Да, у нормальных людей делается так. У долбоёба, которому код читать не надо вообще - нет.
>В будущем нейронки смогут вмещать в себя миллиарды токенов контекста и такой проблемы уже не будет в принципе.
Но речь про сейчас.
Ты получаешь лог ошибки (или жалобу). Дальше ты открываешь код и читаешь его, чтобы понять, почему при определенной последовательности действий состояние разъехалось. Чтение кода — это не метод обнаружения, это метод Root Cause Analysis. Тест скажет «упало здесь», но не скажет «почему сломался инвариант в соседнем модуле 3 часа назад». Без чтения кода ты не напишешь фикс, ты просто заменишь одну нейросетевую генерацию на другую, надеясь, что повезет.
Про «тесты покрывают всё»:
В реальных распределенных системах (high-load) есть Race Conditions и Deadlocks, которые в 99% случаев не ловятся юнит-тестами на локальной машине. Они проявляются только при конкретном тайминге в проде. Чтобы понять, где сломался лок или почему кэш инвалидировался, нужно перечитывать код синхронизации. Тестировщик тут бессилен, он видит только «упал таймаут».
>По визгам саппорта в слаке, по беготне в коридоре, по экстренным созвонам.
Визги — это триггер. Чтение — это инструмент. Если ты не умеешь читать код, ты не сможешь воспользоваться даже нейросеткой, потому что не проверишь, не сгенерила ли она фикс, который отключит тебе индексы в БД или сломает соседний кейс.
Фп охуенная тема в c++. Как я применяю.
Беру тело цикла, пакую в лямбду. Затем цикл делаю шаблонной функцией по лямбде. Так у меня контексты отделаются от нагрузки. Очень хорошо делить по файлам!
>Чтобы понять, где сломался лок или почему кэш инвалидировался
Так вот же, можно синхронизацию/барьеры упихивать в другой файл и форвардить. Задача то - обмазать гвардосами код, хорошо решается на стеке над кодом
>чтобы понять, почему при определенной последовательности действий состояние разъехалось
Надо!!!! Указывать!!!! Инварианты!!!!! От которых зависишь!!!!! ЯВНО!!!!!! НАЗЫВАЕТСЯ assert.
Тогда в дебаг билде будет нормальная остановка в отладчике
Ассерт — это детектор симптома, а не диагност причины. Он покажет, что баланс отрицательный, но не объяснит, как туда пришли данные. Причину ищешь чтением кода вокруг мутаций.
В проде ассерты отключены. Баг приходит через логи и метрики, без отладчика. Единственный инструмент — прочитать код и сопоставить с логами.
Не все инварианты выражаются ассертами (асинхронность, внешние системы, распределённые транзакции).
Чтобы написать хороший ассерт, нужно сначала прочитать и понять код — значит, чтение всё равно первично.
Да, это грамотный архитектурный ход — вынести синхронизацию в декораторы или гарды. Но это не уменьшает потребность в чтении кода, а переносит её в другой файл. Чтобы понять, почему лок сломался, ты всё равно читаешь этот гард и его взаимодействие с бизнес-логикой. Отделение усложняет трассировку (цепочка вызовов размазана по слоям), так что без вдумчивого чтения не обойтись.
>Ассерт — это детектор симптома, а не диагност причины
Нет! Это именно диагност причины. Моя программа, сломалась, потому что ИНВАРИАНТ НАРУШЕН. Это и есть причина. Почему именно нарушен вариант - ты прав, потому что код неправильный. И для его исправления, у тебя есть отладчик! Который остановится в нужном месте и времени
Ты смешиваешь непосредственную причину падения (нарушенный инвариант) и корневую причину (ошибку в логике, которая привела к нарушению).
Да, assert поймает момент, когда инвариант перестал быть истинным. И отладчик покажет стек в этот момент.
Но проблема в том, что состояние могло испортиться за 1000 итераций до этого вызова. Например, другой поток изменил разделяемую переменную, а assert сработал только когда она понадобилась. Отладчик покажет тебе момент обнаружения, а не момент порчи.
Ты скажешь: «поставлю assert сразу после каждой мутации». Но тогда код превращается в решето проверок, и ты всё равно не узнаешь, какая именно мутация была неправильной, пока не пройдёшь по стеку всех вызовов в обратную сторону — а это и есть чтение кода.
В продакшене отладчик не доступен. У тебя только лог «assert failed». И ты идёшь читать код, чтобы восстановить цепочку событий. Так что assert — это улика, а не следствие. Причина — в коде, написанном до assert'а.
Ассерт надо писать вместе с кодом. Инвариант поломки и диагностика к нему, это как ручка у ложки! Важная часть.
>Но проблема в том, что состояние могло испортиться за 1000 итераций до этого вызова. Например, другой поток изменил разделяемую переменную, а assert сработал только когда она понадобилась. Отладчик покажет тебе момент обнаружения, а не момент порчи.
>Ты скажешь: «поставлю assert сразу после каждой мутации». Но тогда код превращается в решето проверок, и ты всё равно не узнаешь, какая именно мутация была неправильной, пока не пройдёшь по стеку всех вызовов в обратную сторону — а это и есть чтение кода.
Я читаю это, и мне кажется, что это какая-то ваша личная особенность вашего стиля. Потому что я сразу пишу так, чтобы состояние объектов было связанным. И сразу закладываю в интерфейс, свойство того, чтобы состояние было тестируемым.
другими словами,
>Но проблема в том, что состояние могло испортиться за 1000 итераций до этого вызова. Например, другой поток изменил разделяемую переменную
контрится тем, чтобы меньше полагаться на вот такие последствия действий. Изначальная проблема описанного дизайна как раз в каких-то неявных последствиях, которые не протестировать адекватно
>Причина — в коде, написанном до assert'а
попробую перефразировать иначе.
если причина, в коде, написанном до asserta -- это означает, что в программе, кто-то сделал инвариант, который нельзя было. А это значит, что ровно до наступления этого инварианта, можно было поймать, что случилось то, что нельзя. А раз можно было поймать, но не поймали, то в программе не хватает ещё одного assert
Assert указывает точку, где инвариант нарушен.
Корневая причина (кто и когда испортил состояние) лежит выше по стеку или раньше во времени.
Отладчик останавливается в нужном месте, но чтобы понять, почему туда пришли плохие данные, ты всё равно читаешь код всех мутаций, произошедших до этого момента. Assert — это маяк, а не карта. Без чтения ты не узнаешь, как до него добрались.
Ассерты — это точки контроля. Если их много, отладчик остановится в первом нарушенном инварианте. Но чтобы понять, почему этот инвариант нарушен, ты всё равно идёшь по стеку вызовов и читаешь код, который изменял состояние до этого. Ассерты лишь указывают, где искать.
Полностью избежать неявных последствий нельзя в распределённых или асинхронных системах, где состояние зависит от внешних сервисов (сетевые задержки, сбои). Там ты не можешь покрыть всё ассертами до того, как проблема проявится.
Assert'ы — это тоже код. Их надо осмысленно расставить. Чтобы понять, какие инварианты нужно защитить и где, ты должен сначала прочитать код и понять его логику. То есть чтение предшествует написанию ассертов.
можно писать без багов! но для этого надо продумывать определённую связность. Я не говорю, что это просто. Я говорю, что это работает)
жертвовать ничем мне не пришлось пока что. Просто пользуюсь механикой компилятора, что можно юзать эквивалентные семантики
жертвовать ничем мне не пришлось пока что. Просто пользуюсь механикой компилятора, что можно юзать эквивалентные семантики
>Assert'ы — это тоже код. Их надо осмысленно расставить. Чтобы понять, какие инварианты нужно защитить и где, ты должен сначала прочитать код и понять его логику. То есть чтение предшествует написанию ассертов.
во время написания надо ставить!
ну как вам ещё сказать. Помимо POSTcondition есть PREconditions. Так я вам и пишу: очень часто чей-то сломанный postcondition мог быть чьим-то precondition!
Я написал много сетевого и асинхронного кода. Там мне это и пригодилось! Когда я покрывал каждый инвариант состояния, а потом тестировал всё это, мой код больше никогда не ломался.
>сначала прочитать код и понять его логику. То есть чтение предшествует написанию ассертов
я не говорю, что читать не обязательно, но я всё-таки утверждаю, что предложенная методика уменьшает площадь для чтения
>Ассерты — это точки контроля. Если их много, отладчик остановится в первом нарушенном инварианте. Но чтобы понять, почему этот инвариант нарушен, ты всё равно идёшь по стеку вызовов и читаешь код
просто, люди мне такое говорят, а потом у них ровно 0! ассертов и по факту мне надо их напрягать, потому что их нерабочее говно сломалось (опять)
>функциональное программирование
небыло б это кринжем все бы так делали
>Функционально программирование норм тема или кринж?
Много в каких темах не хуже ООП, если умеешь правильно готовить. Офк со своими плюсами и минусами.
>По моему опыту если ты можешь вынести кусок кода в функцию которая не зависит от внешних переменных (а именно это и есть функциональный кусок) то это в какой то степени упрощает понимание и работу с такой функцией. И тебе ничего совершенно не мешает тебе в методах класса вызывать такие функции.
>
>Целиком все приложение писать на таких функциях? Как будто бы зачем, что бы что?
>
Это не фп.
>да и классов в привычном понимании.
Разве не во всех фп языках есть что-то типо трейтов?
>А баловаться передачей функций уже ведет запутыванию как по мне, заебешься читать это потом
Ты не можешь какой-нибудь map f прочитать?
Хороший тейк, но нужно обратить внимание на его изнанку. Если задача требует лапши из сайд эффектов а такое, внезапно, иногда случается фп неподходящий выбор.
Хз, как будто бы наоборот больше готовых комбинаторов в коде и меньше хуйни, которую надо в голове держать. В хаскеле еще и охуевший интепретатор за тебя половину работы делает.
Если нравится математика, то идея хорошая. Если нет, то нет. Про схему не могу ничего сказать.
>ряяяя как они смеют обсуждать другие области разработки, а не один вебчик
Расскажи какой баг ты там не мог пофиксить из-за фп.
>Нихуя нейронка в идеальном виде не осиливает,
Он же написал, что у них типовые круды с фронтом - это литералли задача для нейронки.
Первое годное сообщение за весь тред.
>Если задача требует лапши из сайд эффектов а такое, внезапно, иногда случается фп неподходящий выбор.
Тут скорее подход. Подход к задаче всегда можно очистить, но нахуя, если другое пришло в голову первым?
Это не кринж или база, это просто инструмент. Ты не в восьмидесятых живёшь, сейчас самый популярный язык - Пайтон, он мультипарадигмный, и там есть вся фукциональщина, хуй знает что ты там новое учить собрался.
Кроме совсем странных предметных областей, вроде формальной верификации обязательно использовать хаскель нигде не надо, но где-то просто удобнее использовать функциональщину, потому что так код будет более читаемый.
А серверная часть whatapp'а вроде на Erlang написана...
>Функционально
Это тупо высер. Посмотри в реале ЛВМ, на дерево обосцанное. Обычно нам надо конкретный результат, а не чтобы дерево улетало в небо если по модулю прокрутилось чет.
И с хвоста писать типо ретурн 0, и дальше гавно накидывать это поебота.
ФП - заебись тема. Но лишь когда это это ML-подобный язык сугубо функциональный. На худой конец что-нибудь типа F#.
Вне личных проектов ты вряд ли будешь это юзать, поэтому расценивай как увлекательный квест на 1-2 года для вправления мозгов и привития чувства прекрасного.
Наработки полученные в ФП прекрасно расцветают даже в самых обоссанных языках, код становится элегантнее и менее дырявый. Но надеяться что хачкель принесёт тебе доход сам по себе - мягко говоря наивненько. Однако если на собесе или в рабочих обсуждениях тебе попадётся фп-боярин то знание фп тебе сразу дохуя бонусов в карму даст.
Ну вообще в тиньке на Scala есть места. Но,работая над продуктом, придётся писать продуктовый код. А наш мозг мыслит состояниями, тяжело на чистое фп ложиться это всё. ФП в академической среде цветут, но в РФ там денег нету.
>Пайтон, он мультипарадигмный, и там есть вся фукциональщина
Нахуй ты это пишешь, если это неправда? Там даже оптимизации хвостового вызова нет, я уже не говорю про вещи типо нормальных лямбд, некостыльного паттерн матчинга. А всяких hkd в питоне наверное вообще никогда не будет. Питон нихуя не задумывался как функционалтный язык и сам его создатель прямо говорил об этом.
Насколько программка будет структурированной, если написана в рамках этой парадигмы?
Раньше только ООП использовал, но сейчас прикинул, что на новом ЯП писать так боль.