На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Страницы: (10) [1] 2 3 ...  9 10 все  ( Перейти к последнему сообщению )  
> Обсудим идеи как можно радикально облегчить и упростить программирование?
    Обсудим идеи как можно облегчить и упростить программирование? Есть ли языки без функций и "IF...THEN...ELSE"?

    Не для кого не секрет что не смотря на то, что на заре развития инструментов программирования говорилось, что скоро языки программирования настолько приблизятся к языкам естественного общения, что программировать сможет даже домохозяйка это не произошло. Писать большие программы все так же мучительно и долго. Хотя уже более 50 лет инструментарий развивается.

    Мне кажется что сложность программирования объясняется выбранной формой представления программы.

    Из-за которой большую часть времени программист разбирается в тысячах "IF..THEN..ELSE" и сотнях функций. Даже в программе, написанной на объектно-ориентированном языке

    А можно ли придумать какую-то форму представления программы, в которой бы не надо этого было делать?

    Ну или хотя бы чтобы часть "IF..THEN..ELSE" и функций среда разработки генерировала сама.

    Какие это могут быть формы?

    Ну типа тоже текст, но более близкий к языку естественного общения.

    Ну или графического представление.

    Человек нарисовал световым пером на планшете картинку - а система распознала её и сгенерировала код.

    Или программировать просто разговаривая с компьютером на человеческом разговорном языке. Ты говоришь компу - а он тебя понимает и генерит код.

    Вообщем давайте подумаем вместе: что не дает в разы упростить и ускорить процесс программирования и снизить на порядки число багов?
      Цитата Исмаил Прокопенко @
      что не дает в разы упростить и ускорить процесс программирования и снизить на порядки число багов?
      Именно наличие кучи случаев, необходимых для индивидуального анализа, превращающиеся в if..else не дают упростить всё в разы. Смотрите на типичнейшем примере:
      A) программа = схема с таким-то входом и ожидаемым выходом.
      Б) аналог в жизни - поход за хлебом в магазин.
      Имеем:
      1.человек может увидеть, что денег не хватает, а тогда надо поискать в ином кармане. Это if..else в программе.
      2.чел может уронить деньги, кладя их в карман, а тогда не надо сразу идти в магаз, а надо их подобрать. Снова if..else.
      3.чел может почуять холод на ул-ке, а тогда можно вернуться за шарфиком, можно побежать быстрее, можно выбрать магаз поближе, хоть и выбор там меньше. Вагоны if..else'ов.
      И так далее.
      Посему, когда мы пишем print(3.5+5), то какие-то подпрограммы уже знают куда и как выводить и что написать, если сопроцессора нет, если экрана нет, если там не плюс, а деление на ноль и т.д.
      Т.е. со временем код будет короче, т.к. многие лёгкие схемы поведения будут описаны! :yes:
        Я понял Вашу мысль.

        Но можно (наверное) придумать инструмент работы с ветвистой логикой программы методом постепенного уточнения.Чтобы среда тебе в этом помогала

        В ООП это и пытались сделать, но все равно программирование хоть и упростилось но не радикально. К тому же в ООП появились сложности и проблемы, которых не было при обычном структурном программировании.

        Вот не хочу я сразу до конца продумывать все ветвления и всю структуру программы.

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

        Добавлено
        Т.е. сначала на некоем метаязыке описать "правила игры" и суть идеи.
        А уж потом "играться" с собственно языком программирования
          Цитата Исмаил Прокопенко @
          Т.е. сначала на некоем метаязыке описать "правила игры" и суть идеи.
          А уж потом "играться" с собственно языком программирования
          Ну вот не получится такая схема! Ибо всегда будет давать ошибки, а все просто наплюют на неё тогда. Пример:
          у меня сейчас в одном алгоритме надо было посчитать (-8), так вот машина вывалила этакую ошибку, хотя корень = -2. Это оттого, что 1/3 там приближённо считается и в итоге косяк машинного представления таких чисел. А теперь представьте, что вы описали задачу на метаязыке, но только она у вас идёт выполняться, как тут же возникают особые случаи, кои будут либо в BSOD прогу вашу выводить, либо вечно спрашивать "что делать сейчас?". А т.к. программирование развивается как наука, то как и наука оно растёт деревом, от маленьких подпрограмм, модулей, ко всё более совершенным. Т.е. снизу вверх, а вовсе не наоборот. ;)
            Вообще-то языки программирования уже приблизились к человеческим. И эти самые if/then/else с функциями позволяют писать легко читаемые человеком программы. Что еще нужно? "Сделай базу данных, чтоб работало"?
            Цитата
            Человек нарисовал световым пером на планшете картинку - а система распознала её и сгенерировала код.

            Какую картинку? Как ты себе это представляешь? Дай пример картинки, которая, по твоему мнению, представляет какую-нибудь нетривиальную программу точнее и человекопонятнее, чем текст на высокоуровневом языке программирования, и при этом требует от программиста меньше усилий, чем написание текста.
              Цитата AVA12 @
              Какую картинку? Как ты себе это представляешь? Дай пример картинки, которая, по твоему мнению, представляет какую-нибудь нетривиальную программу точнее и человекопонятнее, чем текст на высокоуровневом языке программирования, и при этом требует от программиста меньше усилий, чем написание текста.
              Да ну запросто народ нарисует таких картинок. Я не люблю рисовать, а потому просто словами напишу: "вот листик в клеточку, по ним ходит человечек; как только попадёт на клетку с цифрой, то оказывается на клетке с цифрой+1; когда на 9 в ноль переходит. Цель - побродить". Мне видится, что сие нетривиально, понятнее, "чем текст на высокоуровневом языке программирования" и т.д. Но пока прогресс не готов воплотить такую задумку махом. :yes-sad:
                Цитата AVA12 @
                И эти самые if/then/else с функциями позволяют писать легко читаемые человеком программы. Что еще нужно?


                Т.е. Вы считаете что такая форма представления программы идеальна и ничего лучше уже придумать невозможно? Конец прогрессу?
                --------------
                Если программа маленькая - то да. Больше ничего не нужно.

                А если у тебя программа в несколько десятков тысяч строк кода?
                Пусть даже написанная с использованием ООП.

                Очень трудно такой управлять.

                А если ещё программа не твоя?
                ------

                Я думаю что форма представления программ будет меняться.
                Уже давно назрела необходимость.
                Потому что сложность программ и решаемых ими задач растет.

                Поэтому нужно искать более адекватное, чем PLAIN-текст, представление программы (средства её обзора), её логики, структуры и смысла.

                Так и средства разработки и контроля изменений

                Добавлено
                Просто мы продолжаем даже на высоких уровнях абстракции использовать всю ту же модель: "If...Then...else"

                Может пора придумать что-то ещё?

                Добавлено
                Это примерно как в каламбуре "СИ-программист на любом языке программирования напишет СИ-программу"
                  Цитата
                  Т.е. Вы считаете что такая форма представления программы идеальна и ничего лучше уже придумать невозможно? Конец прогрессу?
                  Вообще-то претензия была:
                  Цитата
                  говорилось, что скоро языки программирования настолько приблизятся к языкам естественного общения, что программировать сможет даже домохозяйка это не произошло

                  Читай внимательнее то, что пишешь.

                  Цитата
                  А если у тебя программа в несколько десятков тысяч строк кода?
                  Пусть даже написанная с использованием ООП.

                  Очень трудно такой управлять.

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

                  Хочется "сжать" запись программы без потерь? Не получится. Можно лишь разрезать запись на части и распихать по углам, чтобы не мозолили глаза. Для этого есть декомпозиция, уровни абстракций, библиотеки и ООП. Если программист написал миллион строк кода - это вовсе не значит, что он должен уметь в три часа ночи подробно объяснить, что именно делает любая строка.

                  Цитата
                  Просто мы продолжаем даже на высоких уровнях абстракции использовать всю ту же модель: "If...Then...else"

                  Что подразумевается под "моделью"? Ветвление алгоритма в зависимости от входных данных? Ну так ветвление все равно будет, и описывать его как-то надо.

                  Кстати, о картинках. Есть такая вещь, как BPMN, вот пример простенькой "программы". Вместо жутких if-then-else - миленькие интуитивно понятные пиктограммы. Правда, это только верхний уровень абстракции, вместо описания объектов и процедур лишь мерзкие и непонятные текстовые метки. Для развития идеи нужно придумать, как описывать эти процедуры в графической нотации - думаю, нескольких сотен разновидностей интуитивно понятных пиктограмм хватит, и если рисовать помельче и покомпактнее, то "программа" вполне уместится на ватманском листе, так что любой сможет окинуть ее взглядом и получить эстетическое удовольствие. В данном случае задача упрощается, так как "программа" эта нарисована для людей, а вот с программами для машин все будет сложнее.
                    Цитата AVA12 @
                    Однако же, профессионалы умудряются как-то писать программы на миллионы строк кода

                    Вот именно что профессионалы. Я бы даже сказал СУПЕР профессионалы.Путем гигантских усилий.
                    А хотелось бы чтобы "легко и просто", чтобы "любая домохозяйка..."

                    Цитата AVA12 @
                    И эти миллионы строк действительно нужны (по большей части)

                    Но ведь в свое время изобрели же ЯВУ, которые позволяют сжать/упаковать десятки миллионов строк АСМ-кода в единицы миллионов строк на ЯВУ и написание целого ряда ветвлений поручить компилятору.

                    Так что возможно можно что-то ещё придумать, чтобы миллионы строк на ЯВУ превратились в сотни тысяч ЯСВУ.

                    А может быть даже не строк.

                    Я думаю, что представление программы в виде "чисто PLAIN-текст и больше ничего кроме текста" скоро уйдет, так как оно уже тормозит прогресс: сложные задачи решать очень сложно с таким преставлением.Потому что оно не очень наглядно и удобно. А ведь сложность задач постоянно растет.

                    Цитата AVA12 @
                    Программа - это аналог конструкторской документации на какой-нибудь механизм. Вроде бы, еще никто не жаловался на то, что, к примеру, самолет состоит из десятков тысяч деталей, и для каждой требуются технические требования и чертежи (или хотя бы ссылки на каталоги производителей), плюс схемы сборки и регламенты тестирования деталей, узлов и самолета в сборе.

                    И даже в самолете есть т.н. "стандартные детали", которые никто заново каждый раз не прорисовывает. И программа - это не аналог КД. Это скорей инструкция рабочему что нужно сделать. Низкоквалифицированному рабочему Вам придется объяснять даже как закрутить винт. А высококвалифицированному достаточно в паре слов обрисовать задачу

                    Цитата AVA12 @
                    Хочется "сжать" запись программы без потерь? Не получится. Можно лишь разрезать запись на части и распихать по углам, чтобы не мозолили глаза. Для этого есть декомпозиция, уровни абстракций, библиотеки и ООП.

                    См. выше пример про рабочих. Если компилятор обладает достаточным "интеллектом", то описание задачи и способа её решения может быть кратким.И НЕЧЕТКИМ
                    И потом. "Умный" компилятор САМ уточнит у тебя если ему что-то не понятно.

                    "Разрезать" говорите? И "распихать"?
                    Так ведь это тоже не тривиальная задача. Почему бы её компилятору не поручить?

                    А если Вы сами "режете" то компилятор должен отслеживать целостность программы и её логики при всех Ваших экспериментах.

                    Цитата AVA12 @
                    Если программист написал миллион строк кода - это вовсе не значит, что он должен уметь в три часа ночи подробно объяснить, что именно делает любая строка.

                    Я в курсе. Но согласитесь - это есть слабое место и является потенциальным источником ошибок. Что человек не помнит все связи и не может охватить все связи и зависимости в целом. Но ведь компилятор может. Он же железный.
                    Разве не будет правильным поручить компилятору эту функцию?
                    Отслеживать ВСЕ зависимости и логико/семантические связи и что при правках они не рушатся и концептуальная целостность программы не нарушается?
                    ************************
                    ************************
                    Хотелось бы все таки чтобы компиляторы поддерживали нечеткую логику и образно-ассоциативную модель мышления человека. Ведь человек в жизни мысли образами и нечетко. И не продумывает задачу сразу всю до мелочей. И постоянно перескакивает с одной задачи на другую даже не закончив до конца первую.


                    Чтобы было не как в IF..THEN..ELSE было только "Да" или "Нет"

                    Чтобы можно было написать "Возможно", "Скорей всего", "Маловероятно", "Наверное так".

                    И по мере наполения кода компилятор сам путем анализа находил что же все-таки подставить "Да" или "нет".

                    Т.е. компилятор должен уметь действовать при нехватке исходных данных, поддерживать нечеткую логику,поддерживать постепенное уточнение, поддерживать "ПЕРЕСКОКИ" человека с разных уровней абстракции (т.е. НЕ НАВЯЗЫВАТЬ человеку жестко заданную модель разработки: типо делай сначала это, а потом это и никак иначе)

                    Добавлено
                    Цитата Исмаил Прокопенко @
                    сложные задачи решать очень сложно с таким преставлением

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

                    Ибо человек может удерживать в своей голове во всех деталях от силы пол экрана.
                    А если представление/форма отображения программы занимает 1000 экранов то весьма трудно разобраться в этом

                    Добавлено
                    Цитата AVA12 @
                    Кстати, о картинках. Есть такая вещь, как BPMN, вот пример простенькой "программы". Вместо жутких if-then-else - миленькие интуитивно понятные пиктограммы. Правда, это только верхний уровень абстракции, вместо описания объектов и процедур лишь мерзкие и непонятные текстовые метки. Для развития идеи нужно придумать, как описывать эти процедуры в графической нотации - думаю, нескольких сотен разновидностей интуитивно понятных пиктограмм хватит, и если рисовать помельче и покомпактнее, то "программа" вполне уместится на ватманском листе, так что любой сможет окинуть ее взглядом и получить эстетическое удовольствие. В данном случае задача упрощается, так как "программа" эта нарисована для людей, а вот с программами для машин все будет сложнее.

                    А ещё можно использовать "свертки" когда несколько значков сворачиваются в один. И могут обратно развернуться по клику по значку.

                    Хотя чисто графическое представление тоже не всегда самое удачное.

                    Я думаю что нужен некий гибрид графики, PLAIN-текста, HYPER-текста с кликабельными сслыками, Excel-ских таблиц, TiddlyWiki формата с тегами и многооконного интерфейса со всплывающими в пузырях подсказками

                    Добавлено
                    Цитата Исмаил Прокопенко @
                    Чтобы было не как в IF..THEN..ELSE было только "Да" или "Нет"

                    Чтобы можно было написать "Возможно", "Скорей всего", "Маловероятно", "Наверное так".

                    И по мере наполения кода компилятор сам путем анализа находил что же все-таки подставить "Да" или "нет".

                    Более того, чтобы можно было написать варианты ветвления не записывая условия ветвления.

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

                    Хотелось бы чтобы "язык будущего" поддерживал и такой стиль написания кода и не впадал в ступор от того, что варианты ветвления написаны, а само условие - нет
                    Сообщение отредактировано: Исмаил Прокопенко -
                      Исмаил Прокопенко
                      Цитата Исмаил Прокопенко @
                      Более того, чтобы можно было написать варианты ветвления не записывая условия ветвления.

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

                      Хотелось бы чтобы "язык будущего" поддерживал и такой стиль написания кода и не впадал в ступор от того, что варианты ветвления написаны, а само условие - нет

                      Отвечу как анимешник.
                      http://online.anidub.com/anime_tv/anime_on...t-01-iz-24.html
                      Серия 16. ИИ не будет работать из-за вечных ошибок которые надо будет исправлять.
                      В итоге ИИ+человек исправляющий его код проигрывает, талантливому человеку(коллективу).

                      Я не верю в совпадения. Так уж совпало что вы подняли ту тему которуя я сейчас активно продумываю. Видимо мое послание дошло до людей.

                      Цитата
                      Т.е. как минимум нужен какой-то браузер, который умеет отображать программу в миллионы строк в нужном акценте и с нужной степенью подробности.

                      Согласен нужен обзор программы в другом плане или срезе. Что касается бесконечных If Then Else.
                      То очевидно что такая форма есть дерево.
                      Есть хороший способ отображения дерева.
                      user posted image

                      Цитата Исмаил Прокопенко @
                      Но ведь в свое время изобрели же ЯВУ, которые позволяют сжать/упаковать десятки миллионов строк АСМ-кода в единицы миллионов строк на ЯВУ и написание целого ряда ветвлений поручить компилятору.

                      Увы но ЯВУ не сжал код. Разве что длинный код стал широким. Если в ассемблере операторы писались в столбик то в ЯВУ в строчку.
                      Но даже так появились требования на снижение ширины. И как следствие правила.

                      Вирт учил структурировать программы. Так что это такое структурированная программа? Это когда программист разложил куски по полочкам. Словно расставить вещи по феншую.
                      К примеру не делать повторов более трёх заменить их циклом. Два цикла в функции не писать разбить на 2 функции.

                      Код становится само документированным и включается в работу семантическое угадывания смысла функции по названию.

                      Лично я пошёл дальше. Давно известно такое словечко как "мажоритарный код". Есть алгоритм - модель которая выполняет основную работу.
                      А есть куча проверок по входным параметрам. Вывод логов. И прочего. Вот все эти проверки и зовутся мажоритарным кодом.

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

                      Следующим шагом была попытка писать код без мажоритарных проверок. Что привело к проблеме. Скорость ловли ошибок снизилось.
                      Отсюда очевидным является, что такой код нужен. Следующий шаг это генерация.
                      Делается это нетрудно. Но пожалуй я не буду рассказывать как.

                      Проблемы 2:
                      1) Большие-данные не работают. Мало данных.
                      2) Сложность написания программ возрастает. Для исправления ошибок ИИ нужен элитник.

                      Зато время сокращается.

                      Цитата
                      Excel-ских таблиц
                      - да нужна автоматизация. Выделил код сказал генерируй. Выделил другой часть сказал вставь отладку.
                      Для изучения потребностей надо как у магов. Маг сам выбирает на какой палец, на какой жест повесить макрос-заклинание.
                      Когда наберётся нужный функционал можно будет внедрять в среду.
                      Сообщение отредактировано: Pavia -
                        Цитата AVA12 @
                        думаю, нескольких сотен разновидностей интуитивно понятных пиктограмм хватит, и если рисовать помельче и покомпактнее, то "программа" вполне уместится на ватманском листе, так что любой сможет окинуть ее взглядом и получить эстетическое удовольствие.
                        Только подозреваю, каждая пиктограмма будет представлена где-то ещё одним листом ватмана.
                        Цитата Исмаил Прокопенко @
                        даже в самолете есть т.н. "стандартные детали", которые никто заново каждый раз не прорисовывает.
                        Так и тебя никто не заставляет каждый раз заново переписывать стандартную библиотеку.
                        Цитата Pavia @
                        Согласен нужен обзор программы в другом плане или срезе. Что касается бесконечных If Then Else.
                        То очевидно что такая форма есть дерево.
                        Не дерево, ветви часто потом опять срастаются.

                        Если представить программу в графическом виде, получится что-то наподобие тех блок-схем, которые заставляли программистов рисовать лет тридцать назад (была такая разновидность пытки). Небольшие программы состоящие из единственной процедуры так представить можно, но как только программа становится чуть больше толку от блок схемы становится ноль.
                        Куда полезнее представление программы в виде потоков данных. Особенно удобно такое представление для аппаратной реализации алгоритмов.
                          Цитата Pavia @
                          Увы но ЯВУ не сжал код. Разве что длинный код стал широким.

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

                          Добавлено
                          Цитата Pavia @
                          Вирт учил структурировать программы. Так что это такое структурированная программа? Это когда программист разложил куски по полочкам. Словно расставить вещи по феншую.

                          Это все хорошо работает для искусственных синтетических задач.

                          А для реальных же задач попытка разложить все по полочкам (причем с первого раза) выглядит как попытка натянуть презерватив через голову.
                          Проблема в том, что зачастую объект/сущность нельзя отнести ни к одной полочке.
                          Или напротив, он относится сразу к нескольким полочкам.

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

                          Добавлено
                          Цитата Pavia @
                          Лично я пошёл дальше. Давно известно такое словечко как "мажоритарный код". Есть алгоритм - модель которая выполняет основную работу.
                          А есть куча проверок по входным параметрам. Вывод логов. И прочего. Вот все эти проверки и зовутся мажоритарным кодом.

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

                          Следующим шагом была попытка писать код без мажоритарных проверок. Что привело к проблеме. Скорость ловли ошибок снизилось.
                          Отсюда очевидным является, что такой код нужен. Следующий шаг это генерация.
                          Делается это нетрудно. Но пожалуй я не буду рассказывать как.

                          Это называется статический и динамический анализатор кода.
                          Соглашусь что в будущем компилятор должен проверять не просто синтаксис языка, а и его логику и семантику.

                          Я о чем-то подобном уже писал выше:
                          Цитата Исмаил Прокопенко @
                          сначала на некоем метаязыке описать "правила игры" и суть идеи.
                          А уж потом "играться" с собственно языком программирования


                          Добавлено
                          Цитата amk @
                          Не дерево, ветви часто потом опять срастаются.

                          Кстати. О дереве. Которое правильней назвать "направленный граф" ибо в нем есть циклы.

                          Его программист тоже не может охватить во всей полноте.
                          И поэтому зачастую программист делает лишние "IF...THEN...ELSE" поскольку не может в голове просчитать и удержать все возможные пути прихода в данную точку программы и каким наборам условий она соответствует. Поэтому "на всякий случай" пишет ещё один "IF...THEN...ELSE" хотя при данной топологии тут ВСЕГДА только "ELSE" реализуется.
                          А система могла бы оптимизировать топологию: свернуть, поменять местами, удалить некоторые условия и т.п.

                          Добавлено
                          Цитата amk @
                          Куда полезнее представление программы в виде потоков данных. Особенно удобно такое представление для аппаратной реализации алгоритмов.

                          Я думаю что IDE должна обеспечивать несколько "полезных представлений" программы, в зависимости от того, что (какой аспект)в данный момент интересует программиста: "Завязка" по данным, топология "IF-ов" или что-то ещё :thanks:

                          Добавлено
                          Цитата amk @
                          но как только программа становится чуть больше толку от блок схемы становится ноль


                          Писал:
                          Цитата Исмаил Прокопенко @
                          А ещё можно использовать "свертки" когда несколько значков сворачиваются в один. И могут обратно развернуться по клику по значку.


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

                            Нельзя строить дом на гнилом фундаменте. Забывая о основах и они потом бьют по голове.

                            Цитата Исмаил Прокопенко @
                            Проблема в том, что зачастую объект/сущность нельзя отнести ни к одной полочке.
                            Или напротив, он относится сразу к нескольким полочкам.

                            Вот именно! Это основы. Реальные объекты противоречивы.
                            От сюда вывод нельзя сократить код. Как бы вы не раскладывали по полочкам всегда будут те самые IF которые будут пробовать загнать объект в рамки в которые он не лезет.

                            Вы можете сравнить код на ассемблере и на паскале или си. Размеры кода для одинаковых программ одинаков!
                            Число If не изменилось. Число функций сопоставимо.
                            Число структур данных осталось прежним.
                            Вот циклы да немного сократились.

                            Но в целом на объем программ не повлияло. Отсюда вывод. Декомпозиция нужна не для сокращения кода!

                            Цитата Исмаил Прокопенко @

                            Как раз таки декомпозиция хорошо себя зарекомендовала на реальных задачах. Мы разбиваем задачу до тех пор пока задачи не станут настолько простыми что исключат саму возможность ошибки.
                            За счёт чего это достигается? За счёт наглядности когда мы видим, что ветки одного рода собраны вместе. Человек быстро обучается и быстро может их проверить.

                            К примеру регулярные выражения. Очень мощный инструмент. Можно написать код быстро и 3 дня искать ошибку.

                            Так почему способ декомпозиции не поручить машине? Человек пользуется около 10 правил. Всех их можно записать и поручить поиск оптиума машине. Функция минимизации известна. Чем меньше не классифицированных IF тем лучше декомпозиция. При равном числе стоит руководствоваться, известностью способом разделения. Под известностью понимается частота встречи у других программистов.

                            Добавлено
                            Цитата Исмаил Прокопенко @
                            Кстати. О дереве. Которое правильней назвать "направленный граф" ибо в нем есть циклы.

                            Циклы не относятся к мажеретарному коду и должны быть выделены в алгоритмическую часть.
                            Циклы на графике только путают. Поэтому графическое представление должно быть древовидным.
                            Дерево проще проверить. Дойдя до конца ветки.
                            Сообщение отредактировано: Pavia -
                              Цитата Pavia @
                              Нельзя строить дом на гнилом фундаменте. Забывая о основах и они потом бьют по голове.

                              Это не фундамент. Это частный случай более сложных вещей.
                              Помните как в физике было? Все верили в незыблемость и фундаментальность классической ("механистической") физики.
                              А потом поняли что т.н. "фундамент" в виде классической физике на самом деле не фундамент, а частный случай квантовой физики+теории относительности+теории неопределенности Гейзенберга+физики элементарных частиц

                              Добавлено
                              Цитата Pavia @
                              Вы можете сравнить код на ассемблере и на паскале или си. Размеры кода для одинаковых программ одинаков!
                              Число If не изменилось. Число функций сопоставимо.
                              Число структур данных осталось прежним.

                              Это, мягко говоря, неправда.
                              Ибо я писал и на Асм и на Си и на Паскале.
                              Но спорить с Вами не буду, чтобы нам не погрязнуть в деталях и не уйти от основной темы.
                                amk
                                По поводу блок схем. Это тупизм наших учителей. Блок схемы нужны для развития фантазии. Они не ограничивают возможного представления программы. Но наши учителя не понимали этого и заставляли делать единообразно.
                                Посмотри ГОСТ на блоксхемы они не говорят на какие блоки надо разбивать программы. И более не говорят, что рисовать.

                                UML предлагает около 20 разновидностей схем!

                                Цитата Исмаил Прокопенко @
                                В этом-то вся и юзюминка, что система программирования должна уметь сворачивать программу до максимально компактного и обобщенного вида и разворачивать программу до самого детального уровня

                                Я считаю что стоит не сворачивать, а дать посмотреть под другим углом.
                                Есть такая интересная фраза как "регион интереса".

                                Дерево это один способ представления из 20 видов UML. Свертка это выбор интересующего региона.

                                Наверно видели сферу ключевых слов(тегов). Когда на передней план вытягивается и укрупняется определённый объект. Так же и в программировании должна быть возможность выбрать правильное представление и детальность. Выбрать область.

                                Думаю нужен код для автоматического построения схем.
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (10) [1] 2 3 ...  9 10 все


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0709 ]   [ 15 queries used ]   [ Generated: 10.12.24, 18:40 GMT ]