Подробнее
для любого эпсилон больше нуля ВПИЗДУ!
программирование,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,it-юмор
Еще на тему
программирование geek it-юмор
Подробнее
для любого эпсилон больше нуля ВПИЗДУ!
программирование,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,it-юмор
Подробнее
для любого эпсилон больше нуля ВПИЗДУ!
программирование,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,it-юмор
А фрагмент из мема на 0:55
никогда об этом ролике не слышал, но там пиздец полный
Нет, сам матан врядли пригодится.
Но с такими навыками обучения, в программировании их потолок - обезьяна на галере, пишущая очередную систему заказов.
> Если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр (над этой монадой) — топос.
Ну или хотя бы
> Шаблон мост — структурный шаблон проектирования, используемый чтобы «разделять абстракцию и реализацию так, чтобы они могли изменяться независимо», используея инкапсуляцию, агрегирование и наследование для того, чтобы разделить ответственность между классами.
// Use the cached data
[self useData:cachedData];
...
// Use the retrieved data
[self useData:data];
1. Шаблоны не для начинающих программистов.
2. У банды четырех суммарно за тысячу ICQ и писали они для таких же додиков. Если в английской вики еще попытались как-то разжевать, то в русской ебашат по методичке.
3. Отрывок - не определение, а какое-то рандомное описание, которое втемячили в первый абзац и терминами сверху присыпали чтобы ваще все охуели. Тяпки используются в сельскохозяйственных работах и состоят из палки, крепления, и хуёвины.
Про функциональщину ничо не скажу.
А так да, теоркат оверрейтед
как раз для них. Где-то на уровне "назовите трёх китов" и "что такое солид/кисс/ягни".
> 2. У банды четырех суммарно за тысячу ICQ и писали они для таких же додиков. Если в английской вики еще попытались как-то разжевать, то в русской ебашат по методичке.
Обычные инженегры, даже не ресерчеры ни в каком виде. айсикью у них такое же как у всех. Ну да, немного структурировали шаблоны, знаю человека который по-другому их же сгруппировал - это же опять же инженерная задача. Просто они популяризовали, это они молодцы.
> Тяпки используются в сельскохозяйственных работах и состоят из палки, крепления, и хуёвины.
Это просто определение, как в оригинальной картинке. Дальше уже можно было бы подробнее расписать что имелось в виду, но книжку уже выкинули и пошли заниматься чем-то ещё.
А ответ простой: любая работа головой требует думать этой самой головой. Само оно ничего не приходит.
Ведь практически всем проект нужно сдать "вчера" а тесты потом сами как-нибудь напишутся. Из воздуха блядь возникнут, не иначе. А секрет в том что нет - не напишутся. Тебя просто перекинут на другой проект и скажут "и так сойдет".
Надо бтв к нему в калифорнию (или он щас в техас переехал? Не помню) сгонять лично познакомиться. Но да, он меня смотивировал на всю эту фигню, статья про разворот списка была шикарна
А если не секрет, в какой области работаешь? Насколько могу судить по вакансиям, в основном около-ФП наблюдается либо в финтехе (редко), либо в каких-то крипто-блокчейн-стартапах.
Короч, как я выше написал рекомендую идрис - увлекательная зарядка для мозгов. Ну и в некотором кастрированном виде применить можно и в крестьянских языках.
или можно написать проверки в сеттере, не скатываясь в маргинальщину
1. С помощью конструкторов/сеттеров пытаешься поддерживать инвариант класса, ок. Но еще требуется поддерживать инвариант функций
2. Проверки придется написать своими руками, покрыть тестами своими руками. Зачем писать то, что может сделать компилятор?
3. Проверки в рантайме могут упасть в рантайме, это надо как-то обрабатывать
4. Самый смак: все такие проверки имеют свойство
а) либо расползаться по коду и дублироваться
б) либо приходится доверять кускам кода, полагаться на то, что то, что тебе пришло - уже правильное. И вот это самое мерзкое, я пишу на обычных ЯП (Си, питон), и у меня прям горит от этого.
Пример. Ко мне пришли какие-то данные, я проверил их, и пустил дальше. Какой-то модуль вынужден допустить, что там не NULL, что массив не пустой итп итд. Да, можно какую-то информацию вынести на уровень типов, но далеко не всю.
Например, в питоне с помощью аннотаций типов я должен явно указать, что аргумент функции/поле класса nullable, в противном случае, линтер поругается. Поэтому я могу проверить, что у меня есть какие-то нужные данные, и записать их в non-nullable поле структуры. Но каких-то ограничений на непустой массив, и тем более, более сложных, я наложить не могу.
Блин, выводить инварианты на уровень типов - это реально круто! Это в той или иной мере возможно во многих ЯП, это не обязательно сложно и требует знаний матана какого-то, но это дает новый уровень уверенности в коде.
Вдохновляющая статья:
https://habr.com/ru/post/498042/
С одной стороны, мы имеем ЯП, который заявляет, что более безопасен, чем сишечка, и может снизить вероятность сделать широкий класс ошибок. Казалось бы, это то, что нужно в разных safety-critical задачах.
Но у нас есть компилятор раста и библиотека раста, которые выкатывают новые версии каждый месяц, и которые, хочу заметить, не гарантируют, что ошибок нет в них самих! И они есть, время от времени баги компилятора раста находят.
И если у нас safety critical (такое, что там регуляторы регулируют и сертифицируют), то проще писать это с использованием определенного кодстайла (вроде MISRA C) и компилировать расово верным сертифицированным компилятормо (вроде IAR), чем писать на расте.
с другой стороны, я сижу и пилю на сях, и никогда он не станет безопасным в принципе.
административный подход к безопасности не работает. доказано всякими микрософтами, гуглами и тд, у которых частота косяков в проектах на сях/плюсах с годами не снижается
во-первых, хочется автору плюнуть в харю за попытку придать всем хорошо известному термину "парсинг" какой-то свой новый ёбнутый смысл.
про арбузинг системы типов тоже тупость.
рассмотрим его привет с функцией head. заебись, мы сделали тип, который нам "упрощает" вызов head. а потом мне понадобился tail - мне этот же тип расширять или другой мутить и туда-сюда перекладывать данные? а потом я захотел вызвать head(tail(arg)) - и всё, на колу мочало, начинай сначала - делаем тип, в котором будем хранить 2+ элементов?
нормальные люди делают вменяемое апи. в данном случае можно было бы сделать 3 функции: maybeHead, headOrDefault, headOrThrow - и всё.
не обязательно систему типов перегружать фичами, чтоб иметь ниибически широкий функционал. design by introspection от D как пример. сама система типов далеко не самая навороченная, эт вам даже не Цейлон с его reified generics и прочими intersection types, не говоря уже про что-то более навороченное. но ее охуенно дополняет compile-time function execution.
да и прост надо головой-то думать - как другие люди будут работать с таким фреймворком ad hoc типов?
Безусловно, реализация непустого списка в статье, не особо применима на практике, потому что нельзя просто так взять и сделать кальку с Haskell в плюс-минус мейнстримном языке, как минимум, потому что списки в том же Haskell - это связанные списки, что дает легкость операций head, tail, а бонусом идут всякие хитрые оптимизации компилятора. Получится неудобное и медленное говно.
2. > а потом я захотел вызвать head(tail(arg)) - и всё, на колу мочало, начинай сначала - делаем тип, в котором будем хранить 2+ элементов?
Зависимые типы не завезли ни в раст, ни даже в хаскель. Автор рассуждает о самом задротском способе подъема на уровень типов на примере ЯП, в котором этого нет и близко. Если в ЯП есть зависимые типы, то можно было бы списку указать ограничения и получить "список длинной не меньше 2" без копипасты.
3. > нормальные люди делают вменяемое апи. в данном случае можно было бы сделать 3 функции: maybeHead, headOrDefault, headOrThrow - и всё.
Может, у меня уже какое-то когнитивное искажение в сторону ФП и типодроча, но я не понимаю, как этот подход нам поможет в общем случае.
3.1. Напомню, что изначально задача стояла не получить head, а получить абстракцию "непустой список". Вы обосрали реализацию через head-tail, в чем я с вами согласен, потому что она неудобна в мейнстримных ЯП, и тут же предложили ее только в другом виде. Применяю ваш же контр-аргумент: что если мне нужен список с двумя и более элементами (head(tail(arg))? maybeFirst, maybeSecond и так далее? Возвращать tail? Если у нас есть NonEmptyList, то tail(NonEmptyList) != NonEmptyList, tail может быть пустым.
ну, похоже, автору очень не нравится каждый раз делать проверку на null, ловить эксепшен, или что там еще может быть. в старых языках вообще не запаривались. в новых компилятор ругнётся.
так вот, что обычно люди делают с неожиданно пришедшим null'ом?
либо это адов косяк, при котором дальше работать не получится; либо можно заюзать дефолтное значение и идти дальше; либо это значение надо надо тупо передать дальше, и пофигу, что там было.
вот на эти 3 самых частых кейса я и предлагаю замутить свои функции. а если их не хватает - ну придется уже написать свою обработку.
по-моему с таким продуманным апи можно очень даже ненапряжно жить
это кстати пратичски как в котлине или Шарпе
list[0]!! // throw
list[0] ?: default
"maybeFirst, maybeSecond и так далее?"
list.tail().maybeFirst()
list.tail().tail().maybeFirst()
Если maybeFirst возвращает null, то делая
list.maybeFirst()/list.tail().maybeFirst()/... мы можем получить null, и здесь у нас варианты:
1. Проверить на null, а мы как раз хотим уйти от проверки на null
2. Забить, и тогда можем получить условный NullReferenceException
Если maybeFirst возвращает Maybe {Nothing | T} (либо пусто, либо T, но нельзя неявно привести к T, в отличие от null), то
1. Нам придется проверить, что это не Nothing, а мы как раз хотим уйти от подобной проверки
2. Сделать небезопасный unwrap() и получить эксепшн/panic, если там таки был Nothing. Разница в том, что в отличие от null, unwrap явно прописан
Итого, мы либо пишем лишний код, либо получаем эксепшн, что, в принципе, мало чем отличается от банального выхода за границу массива в языках, в которых эта проверка осуществляется (java, c#, rust etc).
> так вот, что обычно люди делают с неожиданно пришедшим null'ом?
Возможно, я кэп, но идея в том, что мы хотим, чтобы у нас были гарантии времени компиляции, что неожиданный null или иное говно не придет. Т.е. чтобы не было internal error, this exception couldn't be raised и прочего говна.
Идея лифтинга на уровень типов вообще и завтипов в частности в том, что сделав проверку на принадлежность данных какому-то множеству значений один раз, мы дальше гарантируем, что данные точно принадлежат домену.
Условный пример на условном языке. Не привожу пример с NULL, потому что not-nullable уже завозят потихоньку в языки
Все, в функции do_other_shit нас вообще не парят никакие проверки, никакие null, вообще нихуя. У нас тупо не может быть неожиданно пришедшего null/пустого списка. Компилятор гарантирует, что кто-то заранее озаботился проверкой, а если не озаботился, то не скомпилируется.
ИХМО, это принципиально отличается от устоявшегося подхода с getMaybe/getDefault, которые предполагают, что хуйня может произойти на любом уровне.
так что можно сколько угодно раз его дернуть перед maybeHead, в отличие от варианта автора той статьи.
то, что во многих языках вообще что угодно когда угодно может оказаться нулом, я оставил за скобками.
неспроста эту хрень в жабе обозвали ошибкой на миллиард долларв.
пихать в систему типов что-то помимо того, что есть в теории категорий, имхо, не лучшая затея. этак мы начнём программировать на системах типов.
даже с размером списка, я более чем уверен, в компиляторе будет отдельная ветка обработки. а потом разгребай corner case'ы на стыке нескольких таких кастомных параметризованных типов.
алсо тормоза при компиляции. скала вон тормозит, хотя там система типов не сильно-то навороченная.
самая охуенная система типов в Цейлоне. она прагматичная, без всяких там извращений высших порядков, некоторые вещи захардкожены, зато быстрая.
жалко, что пидоры из ibm денег не дают его дальше пилить :(
попроще в котлине, но тоже заебись. скорее всего под капотом там происходит примерно то же самое, просто в самом языке не все типы описать можно.
В котлине прикольная null-safety, но мне не особо зашло, как сделано (правда, смотрел давно, мб было лучше). Т.к. там компилятор делает все эти преобразования неявно под капотом, бывает, не очевидно. Я как-то сталкивался, когда переменная ну не может быть нулл, ну я все просмотрел, а компилятор не вывозит (мб он не умеет анализировать несколько файлов сразу, хз), приходится вставлять подпорки.
всё вроде норм уже давно
эт мож на стыке с явой происходило? оно понимает какие-то аннотации (типа @NotNull, каждый фреймворк себе такие наплодил), но если их нет - се ля ви
Можете подсказать, как это поможет решить задачу? Не сарказм, я об этом первый раз услышал.
5. да и прост надо головой-то думать - как другие люди будут работать с таким фреймворком ad hoc типов?
Ну, это проблема. Если говорить о FP-inspired типоматане, то он весьма навороченный. Алсо, в моем изначальном комментарии я не призывал к типоматану, я призывал к поднятию определенных проблем на уровень типов, частично это можно сделать и на уровне мейнстримных ЯП, просто типоматан дает больше возможностей, имхо. А типоматан требует какой-то перестройки мышления. Ну а вообще, индустрии не нужны навороченные ЯП, индустрии нужен Go, который не сильно далеко от Си ушел в плане той же обработки ошибок, но на котором можно посадить писать человека почти с улицы.
допустим, нам действительно очень нужен список с минимум 1 элементом, на D-шных темплейтах можно намутить новый тип-обёртку над простым списком, привязать к нему стратегию, что делать, если список пустой. а если мы точно знаем, что он непустой (статический массив, например), то обёртка будет практически бесплатной.
у них есть либа, оборачивающая Int таким образом, что при переполнении триггерится некая стратегия обработки. а если вдруг она тебе не нужна, то эта вся машинерия схлопывается в обычный инт.
и вот мы потом пилим алгоритм, в который хотим работать с обёрнутыми списками, или статическими массивами, или еще чем-то.
мы можем чекнуть, а что вообще на этом типе определено. есть у него размер - давай размер, есть head - давай head юзать, есть popFront - тоже покатит.
проверки мы сделали еще на этапе компиляции, и оверхэда на всякие обёрточки, прокладочки, декораторы, врапперы и прочие прокси не будет.
как и лишных проверок в рантайме, а не пустой ли нам тут список прилетел.
в других языках пришлось бы мутить свою реализацию под каждый кейс, а в D это пара статичских if'ов
надеюсь, хоть немного понятно выразил мысль.
Им говорили, современный язык без дженериков - это хуита, сначала не слушали, потом всё-таки запилили, но только для коллекций. Говорят, сделайте нормальные эксепшены - упираются. Посмотрим, надолго ли их хватит.
Если б не бабки гугла и его авторитет, эта херня не тянула бы и на курсач
Так их и делать не удобно, если нет чего-то типо newtype из хаскеля. Единственный вариант, который я знаю в мейнстрим языках - это оборачивать в структуру. Но потом придется вынимать обычный int из "НенулевойИнт", чтобы его использовать. А тут уже поле для ошибок и компилятор не моможет. Либо писать миллион перегрузок, что еще больше жесть.
checkM = +('' + data.eval).substring(5, 7);
А если серьезно, это вопрос бабок.
Можно отправить команду "сеньер + 3 джуна + ручник" делать проект. Быстро-дешево с багами.
Можно набрать команду сеньеров, наебенить отдел автотестов отдельный, классно спекать задачи, обмазываться хорошими практиками и вот это всё. Будет в 10 раз дороже и втрое дольше, багов почти не будет.
Стоит оно того? Зависит от бизнеса. Если на луну лететь или робота-хирурга делать, то, наверное стоит. Если клепать лэндосы, то, наверное, нет.
Почему-то относительно "не для каждого" профессия стала вбирать в себя огромные массы совершенно не подходящих для этого людей. И теперь "программирование это легко, просто пройдите недельный курс".
Пиздец.
А два - программистом может быть кто угодно. Это не какая то ультра непостижимая профессия. Секретов в ней нет. Только бабки и желание их зарабатывать. Се Ля Ви.
Можно из огорчения что в мире мало проектов без багов завести акк на гитхабе с парой проектов. HelloWorld, FizzBuzz, еще что-нибудь такое надежное.
А то и вторая вышка по проф. специальности
Только не такой, где можно пригласить из универа профессора на три дня, а где реально нужен ботающий разработчик
---
К слову у нас есть человек, который этим занимается. Сидит, пишет код, срется в чатиках про языки, читает параллельно пейперы про то, что там нового про задачи оптимизации придумали, ищет что из этих пейперов можно украсть к нам, чтобы улучшить какие-нибудь характеристики.
Короч, был вопрос "приведи пример" - я привел.
а реализацию напишет уже другой человек
Я посмотрю на питон макаку, которая напишет алгоритм, работающих на реальных данных (ну хотя бы 1000 заказов, 100 машин, 50 ограничений) за адекватное время и выдающий +- нормальный результат (не хуже, чем результат распределения Яндекс.Маршрутизации),
фу блять. я к вам и на собеседование не пошёл бы.
тот настоящий пидераст
1. понять, что в алгоритме плохо
2. понять, что ты видел другой схожий алгоритм, где это делается
3. подружить ежа и ужа. Получить итоговый алгоритм лучше, чем оба исходных
4. посмотреть что за последние пару месяцев вышло по теме, найти ещё пару прикольных моментов, вкорячить себе
5. радоваться, что все работает
6. приходит заказчик и говорит что хочет добавить ограничений, которые при наивной реализации роняют перф в 10 раз. Сидишь неделю и думаешь, что как
7. goto 1
Переменные в программировании: thingA, thingB, thingAPlusThingB
Просто говоря по своему опыту, понять что делает алгоритм на почти любом языке будет проще, чем понять тот же алгоритм математическим уравнением (да, может быть для записи это будет проще, но мы говорим про обучении)
А что не так? :) Это 5-10 средних зарплат по стране как минимум. Грех жаловаться, обезьянке то.
Просто это ограничивает технический рост - к серьёзным вещам и бóльшим зп.
Впрочем, если у кого-то есть организаторские возможности и желание, можно идти в тимлиды на ту же галеру. Они тоже нужны.
И при равном навыке продажи, продать себя при наличии хорошего навыка обучения и как следствие - огромного багажа знаний и умений, можно гораздо выгоднее.
В галерах есть верхняя граница зп, выше которой не прыгнуть, хоть сеньору, хоть тимлиду.
А в продуктовых зрелых компаниях, с теплыми местами, типичные галерные гребцы не нужны.
1. Веб бэкенд разный бывает.
1.1. Можно пилить адский хайлоад, где тебе придется нетривиально издрочиться, чтобы все это реализовать, иногда в процессе этого дела, крупные компании запиливают и потом выкатывают свои нетривиальные продукты, типо in memory баз и прочего.
1.2. Есть проекты, где всякая бизнес-логика замудренная
1.3. Но по моему опыту бэка, у тебя, в лучшем случае, 20% бизнес логика, и 80% - репозитории, фабрики фабрик, сервисы, DTO, мапперы и прочая перегонка данных из одних классов в другие
1.4 А есть и CRUDошлепство, и уверен, его больше. Я лично занимался таким на ASP.NET. Странички, реквесты, в базу пару запросиков сделал, данные слепил, на фронт отдал. Ну и отчетики всякие лепишь.
2. Плюсы тоже разные бывают.
2.1. По моему опыту, большинство вакансий по плюсам - это тот же бэк, только не на питоне/шарпе/жс/го, а на плюсах. Даже если это не непосредственно прямо-таки веб-бэкенд, все равно это что-то крайне близкое к нему с точки зрения задач.
2.2. Я ищу просто весьма специфичные вакансии, связанные с железным дрочем, это не свойство вакансий плюсов, а просто мои вкусы
3. Интересность задач в первую очередь зависит от проекта, а не от стека
Пиздец бля рокет саенс, земля тебе пухом.
Какими? Я легко за 2.5 часа после проебанного месяца (у нас каждый месяц сдачи контрольных, без сессий) осваивал практику.
А теория это пиздец, 30 страниц а4 попересокращенных доказательств просто из нечитаемых наборов символов.
Кому оно нахуй нужно? Все серьезные задачи давно расписаны в сотрудничестве с теми, у кого памяти хватает на всю эту хуйню, да там уже и нейроночки подоспевают которым похуй на некоторые стандартные проблемы и они находят шорткаты.
Я вот не вижу чтобы за рубежом бомбили на матан так сильно - правильно, ведь у них это не лотерейные билеты, а сдача сугубо с практикой - все зарубежные мемы про учебу это набор реальных задач которые ты решаешь на тесте.
Не важен сам матан, важно то, сможет ли человек его осилить.
Это коррелирует с возможностью осилить сложные вещи в программировании.
Потому, не можешь осилить матан, не сможешь и в ИТ продвинуться дальше, чем обезьяна на галере.
Тема бугурта поста никак не связана с "непониманием" матана, она связана с тем что студент тянет лотерейный билет в датабазу с полугодом часовых лекций 3+ раза в неделю, без надежды выехать на понимании, если не воспроизведешь рандомное доказательство-прересдача.
"куб где монотонным голосом тетка рассказывает что-то из матана"
Нужно обязательно познать весь, даже чтобы писать графические библиотеки, где алгем?
Я не сказал, что нужно учить матан. Я вообще и близко не подходил к системе образования и её нюансам.
Я сказал, что если ты не можешь сам осилить матан, неважно, где и как (это можно сделать и просто прочитав учебники, даже не учась нигде, внезапно), то в сложные аспекты программирования ты тоже не сможешь, потому что у них схожий уровень сложности.
У тебя всё гораздо хуже, ты не можешь осознать одну, весьма несложную, мысль, и говоришь с голосами в своей голове.
Уровень сложности абсолютно разный, одно дело ты создаешь реальные методы, обьекты, работаешь с вполне определенными типами и стандартами и совсем другое когда читаешь шизоидные высеры очередного учебника под редакцией очередного мухгу, ИТАКДАЛЕЕ, ОЧЕВИДНО.
В ИТ есть куча вещей вполне сравнимых с матаном по сложности. Но лично ты, как уже ясно, до них никогда не дойдешь, тебе ебашить фабрики классов в сервисах на галере - самое то.
Это не так и плохо, на самом деле. Не надо так бомбить.