На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (21) « Первая ... 17 18 [19] 20 21   ( Перейти к последнему сообщению )  
> ООП - в топку!
    Цитата Астарот @
    Поэтому в конечном итоге идиота, который перечислив несомненные достоинства Светланы сделает вывод, что женится нужно было именно на ней, можно только послать нахер, все остальное будет не конструктивно.
    Ты должен помнить, что, выступая против сентенций Линуса, я вменил ему совсем не это. Он привёл аргументы против Плюсов, которые ровно так же применимы и к Сям. Об чём предпочёл умолчать. Из чего можно сделать два вывода: либо он просто не понял, о чём высказывается (почему бы и не "не осилил" в конце концов), ибо лично я не могу себе представить, что бы профессиональному разработчику, успешно решающему подобные проблемы в C, могло б помешать использовать те же подходы в C++, либо он лукавит, имея в виду совсем не то, что сказал, умолчав об истинных причинах. Ни то, ни другое не говорит в его пользу.
    Сообщение отредактировано: Qraizer -
      Цитата Qraizer @
      Ты должен помнить, что, выступая против сентенций Линуса, я вменил ему совсем не это. Он привёл аргументы против Плюсов, которые ровно так же применимы и к Сям. Об чём предпочёл умолчать. Из чего можно сделать два вывода: либо он просто не понял, о чём высказывается (почему бы и не "не осилил" в конце концов), ибо лично я не могу себе представить, что бы профессиональному разработчику, успешно решающему подобные проблемы в C, могло б помешать использовать те же подходы в C++, либо он лукавит, имея в виду совсем не то, что сказал, умолчав об истинных причинах.

      Если честно, то лично мне сугубо фиолетово на чем разрабатывает Линус. Нет, серьезно, какое мое собачье дело? Он выбрал инструмент, он этим инструментом сделал то, что я не смогу сделать хоть на этом, хоть на любом другом - значит его выбор был верен. У него есть результат. Поэтому правильный ответ на вопрос "почему не плюсы?", как я уже сказал, должен звучать примерно, как "идите в жопу". Собственно именно это он и пытался сказать приводя зачем-то какие-то аргументы. Возможно потому, что не знает замечательного ответа ПАТАМУШТА. Ну, в смысле ПАТАМУШТАИДИТЕВЖОПУ, да.
        Цитата applegame @
        Но прямо вот ржать... думаю Qraizer несколько преувеличивает свою реакцию.
        Та ладно. Он даже цитаты "переврал", оторвав от контекста в лучших традициях жёлтых троллей. Ну серьёзно же.
        Цитата
        Плохие никогда не успевают учиться, они просто нажимают кнопки на клавиатуре как сумасшедшие. Нравится вам это или нет, но вы будете работать с такими людьми. И, к сожалению, ООП не имеет достаточных ограничений, которые бы помешали плохим программистам нанести слишком большой ущерб.
        Электродрель является плохим инструментом, не имеющим достаточных ограничений на причинение большого ущерба? Стоит ли её заменять на ручную?
        Цитата
        На самом деле, чем меньше у программистов выбора, тем более устойчивым становится их код.
        и тем менее продуктивной становится его работа. И устойчивость тут не причём, самый устойчивый код пишут создают инструменты автогеренации.
        Цитата
        ООП предоставляет разработчикам слишком много инструментов и вариантов, не налагая правильных ограничений.
        Абсолютная чушь. В любой ОСи её API без ограничений позволяет писать зловредные программы, API с ограничениями не позволяет писать любые приложения. Это справедливые тезисы, но внезапно из этого ничего не следует. Задачи "дать возможность писать любые приложения" и "не дать писать зловредные" противоречивы и не могут быть удовлетворены одновременно. Более того, одно и то же приложение сможет быть и полезным, и зловредным. Эти характеристики не зависят от приложений, они зависят от их пользователей.
        Цитата
        Erlang — это ООП в чистом виде. В отличие от других популярных языков, он сосредоточен на основной идее ООП — обмен сообщениями. В Erlang объекты взаимодействуют, передавая между собой неизменяемые сообщения
        Внезапно ООП именно так и выглядит везде. Если автор не осилил подход ООП, то тот же Линус его уволил бы и не поморщился, и неважно, что писал бы он при этом на чистых Сях. Впрочем, о чём это я... какие нахрен Си рядом с автором.
        Цитата
        Что делает кодовую базу сложной? Есть много вещей, на которые следует обратить внимание. На мой взгляд, главными причинами являются: общее изменяемое состояние, ошибочные абстракции и низкое отношение сигнал/шум (бойлерплейт). Все они распространены в ООП.
        Наконец-то спалился вчистую. Дальше можно уже не цитировать. Бойлеплейт необходим всегда, в любой абстракции, и его высокий процент о чём-то да и говорит. Конечно, и о хреновом проектировании тоже, но внезапно не всегда. Так же как "лучше день потерять, потом за пять минут долететь" плохой аргумент в разовом применении, однако в долгосрочной перспективе он оправдан. Ошибочные абстракции являются результатом неверного проектирования, и пофик, какую парадигму потом использовать для реализации. И наконец, в ООП нет разделяемых состояний, их нет даже в процедурном. Как после этого его можно серьёзно читать дальше, а?
        Что там дальше... Инкапсуляция, которая как раз лишает проект разделяемых состояний и которой он так и не научился пользоваться? Заставляющая плохих программистов программировать строго в рамках обмена сообщениями? Напрочь опровергая его собственные тезисы касательно ООП? Рассуждения о наследование, которое чётко показывает, что автор даже не курсе теории ОП как дисциплине, вследствие чего понятия ковариантности, контрвариантности и инвариантности вгоняют его в ступор? Полиморфизм, который он внезапно функционально практикует на всю катушку? Человек не смог научиться мыслить по Дейкстра, коли не осилил простейший патерн проектирования сверху вниз. Т.е. он слился уже на школьной программе, и при этом он – смотрим наверх – senior full-stack-разработчик. Естественно, иммутабельная функциональщина для него единственный выход, иначе он голый король. И безработный.
        Сообщение отредактировано: Qraizer -
          Цитата Qraizer @
          Внезапно ООП именно так и выглядит везде.

          Ээээ? :huh: Где в java обмен сообщениями?
            Цитата Астарот @
            Поэтому правильный ответ на вопрос "почему не плюсы?", как я уже сказал, должен звучать примерно, как "идите в жопу".
            Если б он так сказал, я б только кивнул в ответ. Но он сказал не это, и при этом абсолютную хрень. Так что если кто вдруг решил, что он ниасилил, то он вполне имеет право так о нём думать.

            Добавлено
            Цитата Астарот @
            Где в java обмен сообщениями?
            Вызовы методов.
              Цитата Qraizer @
              Если б он так сказал, я б только кивнул в ответ.

              Да он, наверное, и говорил. Много раз. Но достоянием общественности стал тот вариант, где он понял, что вопрошающие непосылаемы и попытался дать им то, чего они хотят.

              Цитата Qraizer @
              Вызовы методов.

              Но вызов метода это не посыл сообщения.
                Цитата Астарот @
                Если честно, то лично мне сугубо фиолетово на чем разрабатывает Линус.

                Тебе да. Но другим разработчикам линукса может быть отнюдь не фиолетово по понятной причине, и они, разумеется, заслуживают более развёрнутого ответа, чем посылание в задницу.

                Добавлено
                К тому же ты подменяешь вопросы. Разговор о том, что линус не осилил плюсы, а не о том, есть кому-то из тут присутствующих дело до того, на чём он разрабатывает.
                  Цитата OpenGL @
                  и они, разумеется, заслуживают более развёрнутого ответа, чем посылание в задницу.

                  Как я уже сказал, я не уверен, что более развернутый ответ в принципе возможен :-?

                  Добавлено
                  Цитата OpenGL @
                  К тому же ты подменяешь вопросы

                  Ничего я не подменяю. Просто выражаю свой взгляд на вещи, говорю, как лично мне кажется.
                    Цитата OpenGL @
                    Но другим разработчикам линукса может быть отнюдь не фиолетово по понятной причине, и они, разумеется, заслуживают более развёрнутого ответа, чем посылание в задницу.

                    Почему?
                      Цитата Qraizer @
                      Вызовы методов.

                      В голом С++ нормальной реализации этой идиомы нету.
                      Именно поэтому для реализации "сигнал-слот" Qt запилило свой moc.
                      И это, я считаю - костыльное решение! В идеале было бы неплохо
                      дать возможность структуре-классу генерить сообщение, самому
                      уметь подписываться, иметь вектор подписчиков, возможность
                      бродкаста ... Но, коль и многопоточность в С++ не реализуется
                      самим языком, а его внешней, пусть и стандартной, но либой ...
                      грузите методы бочками!

                      Хотя бы такой параллелизм запилили, как в Ada.
                        Цитата Астарот @
                        Как я уже сказал, я не уверен, что более развернутый ответ в принципе возможен

                        Вообще-то тут в теме как минимум два таких приводили.

                        Цитата D_KEY @
                        Почему?

                        Что "почему"? Почему разработчикам линукса не фиолетово, на чём линукс разрабатывается? :lol:
                          Цитата JoeUser @
                          В голом С++ нормальной реализации этой идиомы нету.
                          Именно поэтому для реализации "сигнал-слот" Qt запилило свой moc.
                          Мне кажется, вы не понимаете, что такое обмен сообщениями в ОП. В ОП вообще ничего нет, кроме объектов, которые взаимодействуют посредством обмена сообщениями. Именно это и реализуют экземпляры классов посредством вызова методов в ООП.
                          А то, что вы, ну вот сейчас конкретно ты, JoeUser, считаешь за обмен сообщениями, это не те сообщения, и не те обмены между объектами. Широковещательный, групповой итп обмены – это уже не принцип, а паттерн.
                            Цитата Qraizer @
                            что такое обмен сообщениями в ОП

                            А что такое обмен сообщениями в ОП?
                              Цитата OpenGL @
                              Цитата D_KEY @
                              Почему?

                              Что "почему"? Почему разработчикам линукса не фиолетово, на чём линукс разрабатывается? :lol:

                              Нет, почему они заслуживают более развернутого ответа, чем посылания в задницу?

                              Добавлено
                              Цитата Qraizer @
                              Именно это и реализуют экземпляры классов посредством вызова методов в ООП.

                              Таки не совсем. Вызов метода - это реакция на прием сообщения :)
                                Цитата Qraizer @
                                Вызовы методов.

                                Не совсем. В случае чистого обмена сообщениями

                                1) мы можем послать любому объекту любое сообщение. В динамически-типизированных языках так и есть, но в статически-типизированных мы хотим-таки некоторый контроль со стороны системы типов, поэтому классы (часто) являются типами, вводятся интерфейсы и т.п. Только (в случае Java) это реализовано криво: явный implements интерфейсов, в итоге интерфейсы превратились там в некие самостоятельные сущности с кучей религии проектирования вокруг них, их правильного дизайна и применения. Смешение в одну кашу типизации и ООП привело к куче костылей, паттернов и прочего ненужного бойлерплейта. Между тем, всё правильно сделали в OCaml.

                                2) из первого вытекает второе: в ООП-системе не может быть null/nil в том виде в котором он есть в Java: некая спец.сущность, имеющая любой объектный тип, соответственно позволяющая системе типов успешно валидировать вызов метода к такой сущности и приводить к NPE (NullPointerException (Java), NullDereferenceException (C#), etc) в рантайме. Т.е., вкратце: в динамических языках должен быть объект nil (так и есть, например в Ruby, SmallTalk, etc. И ему можно добавить методов), в статических — его не должно быть вообще (use option/Maybe/so-on), или он не должен входить в тип, т.е. быть спец-сущностью поверх объектов (как ? в Kotlin, например, или Swift).

                                В Java этого нет, поэтому невозможно её систему виртуальных методов назвать объектной. Ещё немного портят картину всякие «спец.фичи» Java-объектов, типа возможность использовать любой объект как lock. Но это уже совсем Java-специфичное дерьмо.
                                Сообщение отредактировано: korvin -
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (21) « Первая ... 17 18 [19] 20 21 


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0598 ]   [ 15 queries used ]   [ Generated: 28.03.24, 08:00 GMT ]