Как стать автором
Поиск
Написать публикацию
Обновить

Командный бой на Хабре: Python vs C++

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

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

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

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


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

Всего голосов 36: ↑34 и ↓2+32
Прошел за С++, порадовали строчки «а на питоне это реализуется в один взмах ресниц». Подобные комментарии на питоне в сторону с++ присутствуют?
Всего голосов 6: ↑6 и ↓0+6
Можешь пройти за Python и проверить ;)
Вроде здесь не ограничено количество попыток
Всего голосов 2: ↑2 и ↓0+2
>>> 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 :)

Всего голосов 2: ↑2 и ↓0+2
Shit happens! Спасибо, поправили.
Скрытый текст
image
Всего голосов 1: ↑1 и ↓0+1
int a, *b;

    a = 10;

    *b = a;

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

Всего голосов 18: ↑18 и ↓0+18
тоже искал ответ про назальных демонов
Всего голосов 5: ↑5 и ↓0+5
Кажется вы что то пропустили вот
(или статью поправили)
Всего голосов 1: ↑1 и ↓0+1
Второе))
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
Очень крутой формат, продолжайте!
Всего голосов 7: ↑4 и ↓3+1
C++ имеет смысл только если вам нужно выжимать ms из железа или очень древняя спека под какие-нибудь хардварные компоненты у автомобилей. Хотя, тут уже больше С и С++2003. А еще ООП вредно и портит культуру разработки. Везде классы и перегружено все.
inb4 C++ в 2-3 раза быстрее Python/Go/Rust.
А нуда. А еще все уже решили проблемы с I/O, DB и прочим. Чтоб язык прям давал такие скорости.
Всего голосов 12: ↑2 и ↓10-8
Это утверждения или подборка стереотипов?
Всего голосов 5: ↑5 и ↓0+5
Ого-го. Вот это заявления. Какую именно культуру портит ООП?

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

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

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

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

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

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

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

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


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

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


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

Всего голосов 1: ↑1 и ↓0+1

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

Всего голосов 1: ↑1 и ↓0+1

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


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


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

Всего голосов 1: ↑1 и ↓0+1

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

Всего голосов 1: ↑1 и ↓0+1
Библия для девов
Всего голосов 1: ↑1 и ↓0+1

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

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

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

#4
a = range(10)

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

print(b)

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

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr