Как стать автором
Обновить
Го в рейд? Нет, мы ничего не перепутали. Кланы вокруг фреймворков, баттлы по сложным техническим вопросам, ганк на чужой территории, рейды в комментарии — чем не типовая атмосфера RPG? Ну и классика жанра — путь героя. На первом этапе ты выбираешь класс (например, разработчик) и первоначальные абилки (например, Python или C++). Затем прокачиваешься, развивая основные способности (джун-миддл), добавляя к первоначальному набору новые умения, меняя ветки талантов (DevOps, продакт). Чем выше уровень, тем больше направлений и больше возможностей кастомизировать билд. Открываются квесты (курсы, проекты, хакатоны), другие локации (новые технологии), случаются вайпы (а у кого не было провалов). Ну и всевозможные поты, фласки и эликсиры, которые заряжают энергией и восстанавливают силы, когда горит проект или перегорел ты сам.

Академия больших данных MADE от Mail.ru Group открывает портал в мир Big Data, ML и AI. Два рейда (C++ и Python) идут на зачистку подземелья. Решая задачи с кодом, игроки набирают экспу, чтобы на финальном этапе апнуть lvl и открыть новую специализацию. Присоединяйтесь к своим собратьям, решайте задачи. Таймер на зачистку (точнее на прохождение теста) - 5 мин. А через неделю мы посмотрим, какая команда окажется сильнее, и поздравим победителей в апдейте к этому посту и соцсетях Хабра.
Начать рейд
Всего голосов 61: ↑48 и ↓13 +35
Просмотры 23K
Комментарии 36

Комментарии 36

А зачем проверять знание языка на таких упоротых задачах? Я уже довольно давно пишу на питоне и плюсах, но некоторые вещи мне кажутся ну вообще не очевидными, потому что никто в здравом уме не станет их использовать.


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

Прошел за С++, порадовали строчки «а на питоне это реализуется в один взмах ресниц». Подобные комментарии на питоне в сторону с++ присутствуют?
Можешь пройти за Python и проверить ;)
Вроде здесь не ограничено количество попыток
>>> our_dict = {"a" : 1, "b" : 2, "c" : 3}
>>> 
>>> ourdict = ourdict.update({"a" : -1, "b" : "c"})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'ourdict' is not defined
>>> print(our_dict)

Ответ объявленный "правильным" — None :)

Shit happens! Спасибо, поправили.
Скрытый текст
image
int a, *b;

    a = 10;

    *b = a;

То есть вы предлагаете узнать что же будет по итогам UB? Разыменование неинициализированного указателя.

тоже искал ответ про назальных демонов
Кажется вы что то пропустили вот
(или статью поправили)
Второе))
ЕГЭ для девелоперов
Очень крутой формат, продолжайте!
C++ имеет смысл только если вам нужно выжимать ms из железа или очень древняя спека под какие-нибудь хардварные компоненты у автомобилей. Хотя, тут уже больше С и С++2003. А еще ООП вредно и портит культуру разработки. Везде классы и перегружено все.
inb4 C++ в 2-3 раза быстрее Python/Go/Rust.
А нуда. А еще все уже решили проблемы с I/O, DB и прочим. Чтоб язык прям давал такие скорости.
Это утверждения или подборка стереотипов?
Ого-го. Вот это заявления. Какую именно культуру портит ООП?

Конечно, если стоит задача «по быстрому накидать код, чтобы получить результат здесь и сейчас, но нам не надо, чтобы это работало годами» — да, ООП в целом избытычен.

Но когда речь идет про энтерпрайз, где написанное должно отрабатывать ну хотя бы лет пять, и чтобы можно было легко подменять модули без необходимости вычитывать всё — ООП прекрасная концепция. Как говориться — к каждой задаче нужен свой инструмент. И если вы работаете в сфере, где ООП действительно избыточен — это не значит, что за соседней стенкой не может быть задачи, которую без ООП решить проблематично.
У ООП есть много недостатков, а именно:
  1. ООП в полной реализации просто нигде не используется, т.к. очень требователен к вычислительным мощностям и продуманности архитектуры. Квази-ООП, которое используется сейчас — это лишь элементы
  2. Любую реализацию в виде Квази-ООП можно заменить на ФП, причём последняя будет работать быстрее и проще расширяться. Но порог вхождения будет выше.
  3. Большая часть квази-ООП будет обмазано множественным наследованием, которое в целом плохой паттерн
  4. Квази-ООП приучает к monkey patching и перегрузкам, которые приводят к не очевидному поведению
Большая часть квази-ООП будет обмазано множественным наследованием, которое в целом плохой паттерн

Квази-ООП приучает к monkey patching и перегрузкам, которые приводят к не очевидному поведению

Все так. И ООП сейчас это не про обмен сообщениями (что было бы более правильно), а про "давайте-ка дернем тот перегруженный в производном классе сеттер". Черт

Интересно, что скажут разработчики библиотек? К примеру популярный Qt.
Как говорили выше, инструмент должен соответствовать задаче. Это относится как к паттернам, так и к выбору ЯП.
Конечно и граблями можно мастерски причёску сделать, а микроскопом газеты читать при слабом зрении, вот только зачем?
Если уж мы начали до такой степени утрированно рассуждать, то тогда уж FP — это «когда нам нужно, чтобы футбольный мяч переместился, то мы не идем легким путем, просто изменяя его координаты, нет, мы создаем его заново, а заодно и всю вселенную вокруг него, а старую выбрасываем» :)
что вы понимаете под «обменом сообщениями»? В C#, например, можно «кидать» события. Один объект подписывается на другой и получает как раз сообщения от него. То есть объект класса А просто сообщает «Произошло событие Х!», а уже все кто подписался на это — получают «сообщение» об этом и при необходимости обрабатывают.

давайте-ка дернем тот перегруженный в производном классе сеттер

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

сойдемся на том, что Вы мою фразу не поняли. Перегружаются функции именно в производных классах — с этим я не спорю. И действительно вызывается именно перегруженный вариант "автоматом" — собственно, в чем суть полиморфизма. Я имел в виду именно то, что происходит "под капотом". Другая проблема, что зачастую интерфейсы криво реализованы и реализация под капотом протекает. А в случае использования чужих библиотек — сорян, Вы используете кривую модель, которую в корне уже пофиксить нельзя. А в случае своих — это попросту может быть дорого (т.к. надо бежать по всей иерархии от потомка к предку и в конечном счете базовому классу).


В C#, например, можно «кидать» события. Один объект подписывается на другой и получает как раз сообщения от него. То есть объект класса А просто сообщает «Произошло событие Х!», а уже все кто подписался на это — получают «сообщение» об этом и при необходимости обрабатывают.

В Qt, кстати, доработали ту модель ООП, которая есть в С++ в базе. И добавили довольно удобные элементы (слоты/сигналы). С чем соглашусь (о чем dvserg) — что графические интерфейсы, где есть иерархия сущностей — скорее удобнее делать на ООП, чем каким-либо другим способом (если кто видел гуевые штуки в процедурном стиле — это ужОс и кошмар). Насчет ФП способа описания… Может 0xd34df00d в курсе разработок.
Думаю, что тоже можно было, но это точно не стало мейнстримом — все-таки уже есть 100500 относительно хороших библиотек и большинство задач ими решаются за разумное время/стоимость при приемлемом качестве.


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

Непонятное противопоставление ООП и ФП.
А чем ФП с функциями, которые объекты высшего порядка и которые можно вызывать друг на друге через методы вызова, не ООП, где объекты со скрытым состоянием и открытыми методами воздействия взаимодействуют друг с другом посредством событий как объектов или прямой передачей аргументов в вызовы методов?

Потому что есть ООП как идеализированная концепция и есть его имплементация в основных ЯП на уровне базового синтаксиса, причем не всегда оптимальная? Ну, и есть ЯП, где ООП надо делать вручную, как закат солнца (например, Си).


Ну, и если уж на то пошло — ооп-модель в каком-то смысле проникает и в другие сферы айти. Например, в инфраструктуру. Докер-контейнеры — чем не ООП, только на уровне компонентов приложений? Все есть — и наследование (от базового образа), и полиморфизм, и инкапсуляция. И разработчик контейнера описывает правила его использования (реализация) и тюнинга параметров (интерфейс — через ENV, конфиг-файлы). Или любая IaC штуковина — ansible (переменные+роли), salt (formula), puppet (модули).


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

Проблема в том, что никто не понимает ООП правильно )))
А я то думал, что мой учитель аппелировал к SmallTalk-76

Библия для девов

Все стереотипы в одном комментарии.

Неужели одинаково любишь два?) Не верю)
Есть такая злая шутка, про то, кого любишь большие — маму или папу. Я тоже использую оба языка и каждый люблю за что-то своё.
Как говорил один хороший человек:
«Профессиональный программист должен одинаково ненавидеть все языки программирования»
Странный тест на C++.
В одном из примеров присходит присваивание по неинициализированному указателю `*b = a`. После этого бессмысленно спрашивать, что выведет программа — да хоть розовых пони!

Пример с reinpreted_cast — тоже UB. Посмотрите www.youtube.com/watch?v=_qzMpk-22cc
Не знаю, что людям не понравились эти тривиальные задачки. Некоторые из них мне показались заковыристыми — ответил лишь на 6. Что из этого следует? А то, что иногда неплохо пройтись по азам)
Вариантов может быть больше для решения задачи.

#4
a = range(10)

b = list(a[::-2])

print(b)

>[9, 7, 5, 3, 1]
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вообще это замануха ребят не ведитесь лучше развивайте свои проектики! Нето просто разведут на денежку да и васе!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.