На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
Страницы: (10) « Первая ... 6 7 [8] 9 10  все  ( Перейти к последнему сообщению )  
> Обсудим идеи как можно радикально облегчить и упростить программирование?
    Цитата Исмаил Прокопенко @
    Т.е. я и про полиморфизм не в курсе?

    С учётом того, как вы употребляйте термины - высока вероятность, что нет, не в курсе.

    Цитата Исмаил Прокопенко @
    Что еще (из того что я НЕ говорил, но Вы используя телепатию узнали) я не знаю?

    Что такое ООП на самом деле, как правильно декомпозировать проектируемую систему/предметную область на объекты/подсистемы, как выстраивать между ними взаимосвязи, как проектировать фасады подсистем, как вообще проектировать интерфейсы. Как-то так.
    Сообщение отредактировано: Flex Ferrum -
    "Математики думают, что Бог в уравнениях, нейрологи уверены, что Бог в мозге, а программисты уверены, что Бог — один из них."
    Морган Фриман
    Реализация шаблонов Jinja2 для C++ Jinja2 C++
      Цитата Flex Ferrum @
      Цитата Исмаил Прокопенко @
      Т.е. я и про полиморфизм не в курсе?

      С учётом того, как вы употребляйте <прим. СОВСЕМ ДРУГИЕ. НЕ ОТНОСЯЩИЕСЯ К ПОЛИМОРФИЗМУ> термины - высока вероятность, что нет, не в курсе.

      Телепатия, вероятность,..
      Я точно с программистом разговариваю?

      Добавлено
      Цитата Flex Ferrum @
      как вообще проектировать интерфейсы.

      Тогда вопрос от "дилетанта".
      Что такое "интерфейс" в Вашем понимании.

      Конкретно в коде как он выглядит и что из себя представляет
      Сообщение отредактировано: Исмаил Прокопенко -
      Написать код, понятный машине, и дурак сможет. И только хороший программист сможет написать код, понятный людям
        Цитата Исмаил Прокопенко @
        Я точно с программистом разговариваю?

        Не, не с программистом. С архитектором. :)

        Цитата Исмаил Прокопенко @
        Тогда вопрос от "дилетанта".
        Что такое "интерфейс" в Вашем понимании.

        Интерфейс - это формализованный способ взаимодействия объектов в проектируемой системы. В общем случае - это набор методов, для каждого из которого сформулирован чёткий контракт - Какие варианты входных параметров к каким результатам приводят. Если приводят.

        В коде (в зависимости от характера интерфейса) он описывается либо в виде абстрактного класса, если это интерфейс крупной подсистемы, либо совокупностью публичных/защищенных/свободных/статических методов класса, если речь о конкретном классе.

        Предвосхищая вопрос. Классы, которые являются параметрами этих методов, тоже являются частью интерфейса, так как у них есть свои контракты, на которые полагаются взаимодействующие стороны.
        Сообщение отредактировано: Flex Ferrum -
        "Математики думают, что Бог в уравнениях, нейрологи уверены, что Бог в мозге, а программисты уверены, что Бог — один из них."
        Морган Фриман
        Реализация шаблонов Jinja2 для C++ Jinja2 C++
          Цитата Flex Ferrum @
          В общем случае - это набор методов, для каждого из которого сформулирован чёткий контракт

          Давайте не будем затуманивать детям мозги.
          И скажем проще: набор методов для каждого из которых определена "морда лица" и для чего нужен (за что отвечает) каждый элемент "морды" в отдельности или в совокупности с другими элементами.

          И кстати, Вы правильно сказали:
          Цитата Flex Ferrum @
          Вам не приходило в голову, что сигнатура метода - это лишь часть контракта? Не приходило в голову, что вы далеко не всегда можете описать контракт средствами языка программирования?

          Мне это "приходило в голову".
          Более того. Я кричал об этом на программистских форумах программистам, уверявшим меня, что для работы с классом им ничего кроме его "морды" знать не надо. Что имя метода уже содержит достаточно инфы.
          Я же пытался убедить их, что интерфейс это не только "морда лица", что в интерфейс также входит инфа (опять раздувание интерфейса) для чего нужен (за что отвечает) каждый элемент "морды". За что они отвечают по отдельности и/или в совокупности.
          А чтобы получить эту инфу нужно либо лезть в исходный код класса либо курить какое-то описалово. А значит только имени НЕЗНАКОМОГО метода в НЕЗНАКОМОЙ программе недостаточно, для его правильного использования.
          Сообщение отредактировано: Исмаил Прокопенко -
          Написать код, понятный машине, и дурак сможет. И только хороший программист сможет написать код, понятный людям
            Цитата Исмаил Прокопенко @
            Я же пытался убедить их, что интерфейс это не только "морда лица", что в интерфейс также входит инфа (опять раздувание интерфейса) для чего нужен (за что отвечает) каждый элемент "морды".
            А при процедурном подходе, этого что, знать не нужно? Только при процедурном подходе вся эта "морда" размазана по всей программе и имеет длиннющие имена процедур, за которыми приходится следить.
            Всё написанное выше это всего лишь моё мнение, возможно ошибочное.
              Цитата Исмаил Прокопенко @
              Давайте не будем затуманивать детям мозги.
              И скажем проще: набор методов для каждого из которых определена "морда лица" и для чего нужен (за что отвечает) каждый элемент "морды" в отдельности или в совокупности с другими элементами.

              А давайте без "давайте". Вы спросили как я считаю. Я ответил так, как считаю, без излишней примитивизации.

              Добавлено
              Цитата amk @
              А при процедурном подходе, этого что, знать не нужно? Только при процедурном подходе вся эта "морда" размазана по всей программе и имеет длиннющие имена процедур, за которыми приходится следить.

              Да это при любом подходе нужно. Если есть взаимодействующие сущности - значит, нужен специфицированный протокол их взаимодействия, ака интерфейс. На какую музыку этот протокол будет переложен - это уже вопрос реализации.
              "Математики думают, что Бог в уравнениях, нейрологи уверены, что Бог в мозге, а программисты уверены, что Бог — один из них."
              Морган Фриман
              Реализация шаблонов Jinja2 для C++ Jinja2 C++
                Цитата Исмаил Прокопенко @
                Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры.

                Ну да. И что? Или вы можете предложить какой-то способ избежать этот этап, сохранив при этом плюсы его наличия?
                Подпись была включена в связи с окончанием срока наказания
                  Цитата Исмаил Прокопенко @
                  Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры.

                  Как-то я это пропустил.
                  Ну да, вносится. Вы можете, не обладая архитектурными навыками, построить халупу у себя на даче. И она даже не развалится (наверное). Но чтобы построить что-то серьёзное - надо таки знать, как строить.
                  "Математики думают, что Бог в уравнениях, нейрологи уверены, что Бог в мозге, а программисты уверены, что Бог — один из них."
                  Морган Фриман
                  Реализация шаблонов Jinja2 для C++ Jinja2 C++
                    Отстаньте от Исмаила Прокопенко. Я хочу приобщиться к новому!
                    Исмаил, вы говорите ООП - это плохо. Допустим вы правы и ООП - действительно плохо.
                    Цитата Исмаил Прокопенко @
                    Годами и ДЕСЯТИЛЕТИЯМИ создается то, что можно было создавать за пару недель.
                    Я прочитал этот текст и бросил ООП, и теперь внимательно слушаю, как можно написать за пару недель, то что Flex Ferrum пишет десятилетиями. Я верю, что вы не пустословите и такое действительно возможно, осталось самая мелочь: ответить в общих чертах на вопрос КАК?
                    А то я уже получил деньги на разработку двух новых операционных систем в течение месяца (по две недели на каждую ОС), не хотелось бы их возвращать.
                    error: 'long long long' is too long for GCC
                      Мне тоже интересно. Вот Исмаил Прокопенко доказал себе, что ООП - это плохо. Дальше то что?
                      Мой сайт - prografix.github.io
                        программирование - зло, что же ещё
                          Захотелось высказаться, что даже зарегистрировался. Тема застоя в ИТ.
                          Исмаил Прокопенко поднял интересную тему, но как обычно толкового разговора не получилось, с некоторой страницы пошло не то. У проф. программистов несколько суженое видение ситуации, это правда.
                          Хотя то о чем ТС говорил – plain text не лучшее и не единственное представление кода вполне обосновано.
                          Простой пример все знают, но почему-то не приводят – построение пользовательского интерфейса. Мышкой в основном, ага. Кропотливая задача превратилась в развлечение для школьника. Ну и чем не реализация этой идеи? В матлабе есть возможность строить блок-схемы для вычислений, которые затем трансформируются в исполняемый код. Так что кое, что уже давно реализовано и даже отлично работает. Генерация кода из UML реализована давно.
                          Вот, к примеру, задача. Есть пользовательский интерфейс описанный в xml. Задача – создать некий компилятор, который это описание трансформирует в С++ код. Qt это удалось.
                          Текст программы структурирован? Да. Какие из этого следуют выводы? Видимо этим надо как-то воспользоваться. Как?
                          Как то пришла идея (не мне первому и последнему) хранить код в некоей БД. С++ в реляционной, потому, что ООП имхо неплохо под нее ложится. Тогда некоторые задачи типа рефакторинг, построение разных диаграмм, IntelliSense решаются на раз-два. Парня, который высказал подобное (не помню где) конечно же обсмеяли. Хотя Qt нечто в этом роде и реализовали (использовали xml для построения GUI) и получилось весьма толково.
                          Как сделать с любым кодом? Пока вопрос, но думаю разрешимый. Например, одна функция это одна таблица. Тело функции запихать в поле мемо (в зазипованом виде?), плюс поля – сигнатура + флаги разные. Класс – таблица с реляционными связями на функции и другие классы. В общем, вполне можно, нужно только отбросить стереотипы и подумать. Сделать специализированную IDE не проблема, готовые компоненты для создания простой IDE (типа codeblock) есть, осталось только скрутить все вместе + прилада, которая будет из БД выдергивать или записывать текст по необходимости. Изменили интерфейс класса/сигнатуру функции? IDE либо изменит все дальше сама, по цепочке (если простой случай), либо покажет куда дальше лезть исправлять. Несколько толковых людей даже не самого высокого уровня вполне смогут реализовать подобное.
                          Максима: какой бы не был язык программирования, структурированный текст должен хранится в соответствующем удобном контейнере. Контейнер может быть даже текстовый, как html или xml, не суть. Придумали новый язык – придумайте и контейнер для него. И компилятор/интерпретатор должен его (контейнер) понимать. “Plain text” – прошлое.
                            Gus_Tarantoga
                            Если отбросить в сторону рисование GUI, то из перечисленных задач остаются: моделирование систем в MATLAB, генерация кода на основе UML-диаграмм, формирование запросов к БД.
                            И даже при этом большую часть сгенерированного кода (кроме разве MATLAB-а) приходится вводить вручную, либо непосредственно, либо в виде параметров.
                            При этом как-то забывается, что и блок-схема в MATLAB, и UML-диаграмма, и описание формы GUI физически на диске представлены пусть и размеченным, но тем-же самым Plain Text.

                            Было время (во времена FORTRAN-66), когда при сдаче программы требовалось обязательно предоставить её блок-схему. Но с появлением структурных языков типа Algol, Pascal, C внезапно обнаружилось, что разбираться с работой программы по этой блок-схеме труднее, чем непосредственно по грамотно оформленному тексту.
                            Предлагаешь вернуться в те времена?

                            Добавлено
                            Кстати, написать класс генерации диалога на том же wxWidget вручную не намного сложнее, чем набросать его в визуальном редакторе. Мешает в основном плохое знание библиотеки - при пользовании визуальным редактором подробно знать библиотеку нет нужды. Однако многие возможности библиотеки в редакторе остаются недоступны. Хотя бы потому, что редактор может работать только со статическими формами, а библиотека создаёт их динамически.
                            Всё написанное выше это всего лишь моё мнение, возможно ошибочное.
                              amk, к слову, UML-диаграммы на работе я пишу, а не рисую. Их так элементарно проще версионировать.
                              "Математики думают, что Бог в уравнениях, нейрологи уверены, что Бог в мозге, а программисты уверены, что Бог — один из них."
                              Морган Фриман
                              Реализация шаблонов Jinja2 для C++ Jinja2 C++
                                Цитата Gus_Tarantoga @
                                Парня, который высказал подобное (не помню где) конечно же обсмеяли.

                                Не удивительно.
                                Как говаривал, ЕМНИП, старина Нильс Бор (нобелевский лауреат): "Все новые революционные научные идеи проходят 3 этапа отношения к ним людей:

                                1. Да это же полная чушь ("да это же курам насмех")
                                2. А ведь в этом что-то есть
                                3. А разве можно иначе?



                                "

                                Добавлено
                                Цитата Gus_Tarantoga @
                                “Plain text” – прошлое.

                                А современные системы контроля версий?
                                Это же каменный век.
                                Настоящие системы контроля версий должны показывать не разницу в тексте, а разницу в СЕМАНТИКЕ

                                Добавлено
                                Вот переименовал я идентификатор в 157-ми местах.
                                Обычная CVS покажет 157 изменений.
                                А семантический диф вифер покажэт "отличий нет"

                                Добавлено
                                Цитата Flex Ferrum @
                                Их так элементарно проще версионировать.

                                А почему. А потому что CVS застряли в каменном веке
                                Написать код, понятный машине, и дурак сможет. И только хороший программист сможет написать код, понятный людям
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (10) « Первая ... 6 7 [8] 9 10  все


                                Рейтинг@Mail.ru
                                [ Script Execution time: 0,1801 ]   [ 17 queries used ]   [ Generated: 23.08.19, 09:13 GMT ]