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

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

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

UPD. Время итогов! За неделю в баттле приняли участие почти две тысячи человек, которые заработали 250 тысяч очков опыта для своих команд. Первый день прошел под знаменем C++, затем вперед вырвалась команда Python, которую мы и поздравляем с победой! Этот язык подтвердил свое звание одного из самых популярных инструментов для работы с данными, но для многих задач, особенно связанных с вычислениями на уровне железа, C++ был, есть и будет актуальным. Также в суровом мире Data Science есть место для Java, C#, JavaScript, но это уже будет другая история.

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

    +32

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

                                +1

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

                                  +1

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


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


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

                                +1

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

                                  +1
                                  Библия для девов
                                  +3

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

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

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

                                          #4
                                          a = range(10)
                                          
                                          b = list(a[::-2])
                                          
                                          print(b)
                                          
                                          >[9, 7, 5, 3, 1]
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              0
                                              Зачем этот холивар нужен? У каждого языка своё применение.
                                              Комментарий про «а в питоне можно было бы сделать за 3 строчки» в тесте про плюсы какой-то странный.
                                              Можно, ну и что? Какой-то толстый троллинг цепепешников.
                                                +1
                                                Вообще это замануха ребят не ведитесь лучше развивайте свои проектики! Нето просто разведут на денежку да и васе!

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.