Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.97.9.168] |
|
Сообщ.
#1
,
|
|
|
Обсудим идеи как можно облегчить и упростить программирование? Есть ли языки без функций и "IF...THEN...ELSE"?
Не для кого не секрет что не смотря на то, что на заре развития инструментов программирования говорилось, что скоро языки программирования настолько приблизятся к языкам естественного общения, что программировать сможет даже домохозяйка это не произошло. Писать большие программы все так же мучительно и долго. Хотя уже более 50 лет инструментарий развивается. Мне кажется что сложность программирования объясняется выбранной формой представления программы. Из-за которой большую часть времени программист разбирается в тысячах "IF..THEN..ELSE" и сотнях функций. Даже в программе, написанной на объектно-ориентированном языке А можно ли придумать какую-то форму представления программы, в которой бы не надо этого было делать? Ну или хотя бы чтобы часть "IF..THEN..ELSE" и функций среда разработки генерировала сама. Какие это могут быть формы? Ну типа тоже текст, но более близкий к языку естественного общения. Ну или графического представление. Человек нарисовал световым пером на планшете картинку - а система распознала её и сгенерировала код. Или программировать просто разговаривая с компьютером на человеческом разговорном языке. Ты говоришь компу - а он тебя понимает и генерит код. Вообщем давайте подумаем вместе: что не дает в разы упростить и ускорить процесс программирования и снизить на порядки число багов? |
Сообщ.
#2
,
|
|
|
Цитата Исмаил Прокопенко @ Именно наличие кучи случаев, необходимых для индивидуального анализа, превращающиеся в if..else не дают упростить всё в разы. Смотрите на типичнейшем примере:что не дает в разы упростить и ускорить процесс программирования и снизить на порядки число багов? A) программа = схема с таким-то входом и ожидаемым выходом. Б) аналог в жизни - поход за хлебом в магазин. Имеем: 1.человек может увидеть, что денег не хватает, а тогда надо поискать в ином кармане. Это if..else в программе. 2.чел может уронить деньги, кладя их в карман, а тогда не надо сразу идти в магаз, а надо их подобрать. Снова if..else. 3.чел может почуять холод на ул-ке, а тогда можно вернуться за шарфиком, можно побежать быстрее, можно выбрать магаз поближе, хоть и выбор там меньше. Вагоны if..else'ов. И так далее. Посему, когда мы пишем print(3.5+5), то какие-то подпрограммы уже знают куда и как выводить и что написать, если сопроцессора нет, если экрана нет, если там не плюс, а деление на ноль и т.д. Т.е. со временем код будет короче, т.к. многие лёгкие схемы поведения будут описаны! |
Сообщ.
#3
,
|
|
|
Я понял Вашу мысль.
Но можно (наверное) придумать инструмент работы с ветвистой логикой программы методом постепенного уточнения.Чтобы среда тебе в этом помогала В ООП это и пытались сделать, но все равно программирование хоть и упростилось но не радикально. К тому же в ООП появились сложности и проблемы, которых не было при обычном структурном программировании. Вот не хочу я сразу до конца продумывать все ветвления и всю структуру программы. Я хочу, чтобы "легким движением руки" можно было перекраивать структуру программы причем на любых уровнях абстракции и обобщения и при этом чтобы основная идея не рушилась благодаря тому, что дружественная среда следит за этим Добавлено Т.е. сначала на некоем метаязыке описать "правила игры" и суть идеи. А уж потом "играться" с собственно языком программирования |
Сообщ.
#4
,
|
|
|
Цитата Исмаил Прокопенко @ Ну вот не получится такая схема! Ибо всегда будет давать ошибки, а все просто наплюют на неё тогда. Пример:Т.е. сначала на некоем метаязыке описать "правила игры" и суть идеи. А уж потом "играться" с собственно языком программирования у меня сейчас в одном алгоритме надо было посчитать (-8)⅓, так вот машина вывалила этакую ошибку, хотя корень = -2. Это оттого, что 1/3 там приближённо считается и в итоге косяк машинного представления таких чисел. А теперь представьте, что вы описали задачу на метаязыке, но только она у вас идёт выполняться, как тут же возникают особые случаи, кои будут либо в BSOD прогу вашу выводить, либо вечно спрашивать "что делать сейчас?". А т.к. программирование развивается как наука, то как и наука оно растёт деревом, от маленьких подпрограмм, модулей, ко всё более совершенным. Т.е. снизу вверх, а вовсе не наоборот. |
Сообщ.
#5
,
|
|
|
Вообще-то языки программирования уже приблизились к человеческим. И эти самые if/then/else с функциями позволяют писать легко читаемые человеком программы. Что еще нужно? "Сделай базу данных, чтоб работало"?
Цитата Человек нарисовал световым пером на планшете картинку - а система распознала её и сгенерировала код. Какую картинку? Как ты себе это представляешь? Дай пример картинки, которая, по твоему мнению, представляет какую-нибудь нетривиальную программу точнее и человекопонятнее, чем текст на высокоуровневом языке программирования, и при этом требует от программиста меньше усилий, чем написание текста. |
Сообщ.
#6
,
|
|
|
Цитата AVA12 @ Да ну запросто народ нарисует таких картинок. Я не люблю рисовать, а потому просто словами напишу: "вот листик в клеточку, по ним ходит человечек; как только попадёт на клетку с цифрой, то оказывается на клетке с цифрой+1; когда на 9 в ноль переходит. Цель - побродить". Мне видится, что сие нетривиально, понятнее, "чем текст на высокоуровневом языке программирования" и т.д. Но пока прогресс не готов воплотить такую задумку махом. Какую картинку? Как ты себе это представляешь? Дай пример картинки, которая, по твоему мнению, представляет какую-нибудь нетривиальную программу точнее и человекопонятнее, чем текст на высокоуровневом языке программирования, и при этом требует от программиста меньше усилий, чем написание текста. |
Сообщ.
#7
,
|
|
|
Цитата AVA12 @ И эти самые if/then/else с функциями позволяют писать легко читаемые человеком программы. Что еще нужно? Т.е. Вы считаете что такая форма представления программы идеальна и ничего лучше уже придумать невозможно? Конец прогрессу? -------------- Если программа маленькая - то да. Больше ничего не нужно. А если у тебя программа в несколько десятков тысяч строк кода? Пусть даже написанная с использованием ООП. Очень трудно такой управлять. А если ещё программа не твоя? ------ Я думаю что форма представления программ будет меняться. Уже давно назрела необходимость. Потому что сложность программ и решаемых ими задач растет. Поэтому нужно искать более адекватное, чем PLAIN-текст, представление программы (средства её обзора), её логики, структуры и смысла. Так и средства разработки и контроля изменений Добавлено Просто мы продолжаем даже на высоких уровнях абстракции использовать всю ту же модель: "If...Then...else" Может пора придумать что-то ещё? Добавлено Это примерно как в каламбуре "СИ-программист на любом языке программирования напишет СИ-программу" |
Сообщ.
#8
,
|
|
|
Цитата Вообще-то претензия была:Т.е. Вы считаете что такая форма представления программы идеальна и ничего лучше уже придумать невозможно? Конец прогрессу? Цитата говорилось, что скоро языки программирования настолько приблизятся к языкам естественного общения, что программировать сможет даже домохозяйка это не произошло Читай внимательнее то, что пишешь. Цитата А если у тебя программа в несколько десятков тысяч строк кода? Пусть даже написанная с использованием ООП. Очень трудно такой управлять. Однако же, профессионалы умудряются как-то писать программы на миллионы строк кода - и как-то справляются. И эти миллионы строк действительно нужны (по большей части), их количество зависит от сложности программы и детальности ее проработки. Программа - это аналог конструкторской документации на какой-нибудь механизм. Вроде бы, еще никто не жаловался на то, что, к примеру, самолет состоит из десятков тысяч деталей, и для каждой требуются технические требования и чертежи (или хотя бы ссылки на каталоги производителей), плюс схемы сборки и регламенты тестирования деталей, узлов и самолета в сборе. Хочется "сжать" запись программы без потерь? Не получится. Можно лишь разрезать запись на части и распихать по углам, чтобы не мозолили глаза. Для этого есть декомпозиция, уровни абстракций, библиотеки и ООП. Если программист написал миллион строк кода - это вовсе не значит, что он должен уметь в три часа ночи подробно объяснить, что именно делает любая строка. Цитата Просто мы продолжаем даже на высоких уровнях абстракции использовать всю ту же модель: "If...Then...else" Что подразумевается под "моделью"? Ветвление алгоритма в зависимости от входных данных? Ну так ветвление все равно будет, и описывать его как-то надо. Кстати, о картинках. Есть такая вещь, как BPMN, вот пример простенькой "программы". Вместо жутких if-then-else - миленькие интуитивно понятные пиктограммы. Правда, это только верхний уровень абстракции, вместо описания объектов и процедур лишь мерзкие и непонятные текстовые метки. Для развития идеи нужно придумать, как описывать эти процедуры в графической нотации - думаю, нескольких сотен разновидностей интуитивно понятных пиктограмм хватит, и если рисовать помельче и покомпактнее, то "программа" вполне уместится на ватманском листе, так что любой сможет окинуть ее взглядом и получить эстетическое удовольствие. В данном случае задача упрощается, так как "программа" эта нарисована для людей, а вот с программами для машин все будет сложнее. |
Сообщ.
#9
,
|
|
|
Цитата AVA12 @ Однако же, профессионалы умудряются как-то писать программы на миллионы строк кода Вот именно что профессионалы. Я бы даже сказал СУПЕР профессионалы.Путем гигантских усилий. А хотелось бы чтобы "легко и просто", чтобы "любая домохозяйка..." Цитата AVA12 @ И эти миллионы строк действительно нужны (по большей части) Но ведь в свое время изобрели же ЯВУ, которые позволяют сжать/упаковать десятки миллионов строк АСМ-кода в единицы миллионов строк на ЯВУ и написание целого ряда ветвлений поручить компилятору. Так что возможно можно что-то ещё придумать, чтобы миллионы строк на ЯВУ превратились в сотни тысяч ЯСВУ. А может быть даже не строк. Я думаю, что представление программы в виде "чисто PLAIN-текст и больше ничего кроме текста" скоро уйдет, так как оно уже тормозит прогресс: сложные задачи решать очень сложно с таким преставлением.Потому что оно не очень наглядно и удобно. А ведь сложность задач постоянно растет. Цитата AVA12 @ Программа - это аналог конструкторской документации на какой-нибудь механизм. Вроде бы, еще никто не жаловался на то, что, к примеру, самолет состоит из десятков тысяч деталей, и для каждой требуются технические требования и чертежи (или хотя бы ссылки на каталоги производителей), плюс схемы сборки и регламенты тестирования деталей, узлов и самолета в сборе. И даже в самолете есть т.н. "стандартные детали", которые никто заново каждый раз не прорисовывает. И программа - это не аналог КД. Это скорей инструкция рабочему что нужно сделать. Низкоквалифицированному рабочему Вам придется объяснять даже как закрутить винт. А высококвалифицированному достаточно в паре слов обрисовать задачу Цитата AVA12 @ Хочется "сжать" запись программы без потерь? Не получится. Можно лишь разрезать запись на части и распихать по углам, чтобы не мозолили глаза. Для этого есть декомпозиция, уровни абстракций, библиотеки и ООП. См. выше пример про рабочих. Если компилятор обладает достаточным "интеллектом", то описание задачи и способа её решения может быть кратким.И НЕЧЕТКИМ И потом. "Умный" компилятор САМ уточнит у тебя если ему что-то не понятно. "Разрезать" говорите? И "распихать"? Так ведь это тоже не тривиальная задача. Почему бы её компилятору не поручить? А если Вы сами "режете" то компилятор должен отслеживать целостность программы и её логики при всех Ваших экспериментах. Цитата AVA12 @ Если программист написал миллион строк кода - это вовсе не значит, что он должен уметь в три часа ночи подробно объяснить, что именно делает любая строка. Я в курсе. Но согласитесь - это есть слабое место и является потенциальным источником ошибок. Что человек не помнит все связи и не может охватить все связи и зависимости в целом. Но ведь компилятор может. Он же железный. Разве не будет правильным поручить компилятору эту функцию? Отслеживать ВСЕ зависимости и логико/семантические связи и что при правках они не рушатся и концептуальная целостность программы не нарушается? ************************ ************************ Хотелось бы все таки чтобы компиляторы поддерживали нечеткую логику и образно-ассоциативную модель мышления человека. Ведь человек в жизни мысли образами и нечетко. И не продумывает задачу сразу всю до мелочей. И постоянно перескакивает с одной задачи на другую даже не закончив до конца первую. Чтобы было не как в IF..THEN..ELSE было только "Да" или "Нет" Чтобы можно было написать "Возможно", "Скорей всего", "Маловероятно", "Наверное так". И по мере наполения кода компилятор сам путем анализа находил что же все-таки подставить "Да" или "нет". Т.е. компилятор должен уметь действовать при нехватке исходных данных, поддерживать нечеткую логику,поддерживать постепенное уточнение, поддерживать "ПЕРЕСКОКИ" человека с разных уровней абстракции (т.е. НЕ НАВЯЗЫВАТЬ человеку жестко заданную модель разработки: типо делай сначала это, а потом это и никак иначе) Добавлено Цитата Исмаил Прокопенко @ сложные задачи решать очень сложно с таким преставлением Т.е. как минимум нужен какой-то браузер, который умеет отображать программу в миллионы строк в нужном акценте и с нужной степенью подробности. Ибо человек может удерживать в своей голове во всех деталях от силы пол экрана. А если представление/форма отображения программы занимает 1000 экранов то весьма трудно разобраться в этом Добавлено Цитата AVA12 @ Кстати, о картинках. Есть такая вещь, как BPMN, вот пример простенькой "программы". Вместо жутких if-then-else - миленькие интуитивно понятные пиктограммы. Правда, это только верхний уровень абстракции, вместо описания объектов и процедур лишь мерзкие и непонятные текстовые метки. Для развития идеи нужно придумать, как описывать эти процедуры в графической нотации - думаю, нескольких сотен разновидностей интуитивно понятных пиктограмм хватит, и если рисовать помельче и покомпактнее, то "программа" вполне уместится на ватманском листе, так что любой сможет окинуть ее взглядом и получить эстетическое удовольствие. В данном случае задача упрощается, так как "программа" эта нарисована для людей, а вот с программами для машин все будет сложнее. А ещё можно использовать "свертки" когда несколько значков сворачиваются в один. И могут обратно развернуться по клику по значку. Хотя чисто графическое представление тоже не всегда самое удачное. Я думаю что нужен некий гибрид графики, PLAIN-текста, HYPER-текста с кликабельными сслыками, Excel-ских таблиц, TiddlyWiki формата с тегами и многооконного интерфейса со всплывающими в пузырях подсказками Добавлено Цитата Исмаил Прокопенко @ Чтобы было не как в IF..THEN..ELSE было только "Да" или "Нет" Чтобы можно было написать "Возможно", "Скорей всего", "Маловероятно", "Наверное так". И по мере наполения кода компилятор сам путем анализа находил что же все-таки подставить "Да" или "нет". Более того, чтобы можно было написать варианты ветвления не записывая условия ветвления. Ведь в жизни так часто бывает: мы знаем варианты развития событий, но не можем точно записать условия при каких будет реализован тот или иной вариант. Хотелось бы чтобы "язык будущего" поддерживал и такой стиль написания кода и не впадал в ступор от того, что варианты ветвления написаны, а само условие - нет |
Сообщ.
#10
,
|
|
|
Исмаил Прокопенко
Цитата Исмаил Прокопенко @ Более того, чтобы можно было написать варианты ветвления не записывая условия ветвления. Ведь в жизни так часто бывает: мы знаем варианты развития событий, но не можем точно записать условия при каких будет реализован тот или иной вариант. Хотелось бы чтобы "язык будущего" поддерживал и такой стиль написания кода и не впадал в ступор от того, что варианты ветвления написаны, а само условие - нет Отвечу как анимешник. http://online.anidub.com/anime_tv/anime_on...t-01-iz-24.html Серия 16. ИИ не будет работать из-за вечных ошибок которые надо будет исправлять. В итоге ИИ+человек исправляющий его код проигрывает, талантливому человеку(коллективу). Я не верю в совпадения. Так уж совпало что вы подняли ту тему которуя я сейчас активно продумываю. Видимо мое послание дошло до людей. Цитата Т.е. как минимум нужен какой-то браузер, который умеет отображать программу в миллионы строк в нужном акценте и с нужной степенью подробности. Согласен нужен обзор программы в другом плане или срезе. Что касается бесконечных If Then Else. То очевидно что такая форма есть дерево. Есть хороший способ отображения дерева. Цитата Исмаил Прокопенко @ Но ведь в свое время изобрели же ЯВУ, которые позволяют сжать/упаковать десятки миллионов строк АСМ-кода в единицы миллионов строк на ЯВУ и написание целого ряда ветвлений поручить компилятору. Увы но ЯВУ не сжал код. Разве что длинный код стал широким. Если в ассемблере операторы писались в столбик то в ЯВУ в строчку. Но даже так появились требования на снижение ширины. И как следствие правила. Вирт учил структурировать программы. Так что это такое структурированная программа? Это когда программист разложил куски по полочкам. Словно расставить вещи по феншую. К примеру не делать повторов более трёх заменить их циклом. Два цикла в функции не писать разбить на 2 функции. Код становится само документированным и включается в работу семантическое угадывания смысла функции по названию. Лично я пошёл дальше. Давно известно такое словечко как "мажоритарный код". Есть алгоритм - модель которая выполняет основную работу. А есть куча проверок по входным параметрам. Вывод логов. И прочего. Вот все эти проверки и зовутся мажоритарным кодом. Я взял и вынес его в отдельные функции. Отделив словно кожуру от зёрен. Алгоритмы стали более простыми и понятными. Но вот мажоритарный код стал настолько запутанный, насколько это возможно. Следующим шагом была попытка писать код без мажоритарных проверок. Что привело к проблеме. Скорость ловли ошибок снизилось. Отсюда очевидным является, что такой код нужен. Следующий шаг это генерация. Делается это нетрудно. Но пожалуй я не буду рассказывать как. Проблемы 2: 1) Большие-данные не работают. Мало данных. 2) Сложность написания программ возрастает. Для исправления ошибок ИИ нужен элитник. Зато время сокращается. Цитата - да нужна автоматизация. Выделил код сказал генерируй. Выделил другой часть сказал вставь отладку. Excel-ских таблиц Для изучения потребностей надо как у магов. Маг сам выбирает на какой палец, на какой жест повесить макрос-заклинание. Когда наберётся нужный функционал можно будет внедрять в среду. |
Сообщ.
#11
,
|
|
|
Цитата AVA12 @ Только подозреваю, каждая пиктограмма будет представлена где-то ещё одним листом ватмана.думаю, нескольких сотен разновидностей интуитивно понятных пиктограмм хватит, и если рисовать помельче и покомпактнее, то "программа" вполне уместится на ватманском листе, так что любой сможет окинуть ее взглядом и получить эстетическое удовольствие. Цитата Исмаил Прокопенко @ Так и тебя никто не заставляет каждый раз заново переписывать стандартную библиотеку.даже в самолете есть т.н. "стандартные детали", которые никто заново каждый раз не прорисовывает. Цитата Pavia @ Не дерево, ветви часто потом опять срастаются.Согласен нужен обзор программы в другом плане или срезе. Что касается бесконечных If Then Else. То очевидно что такая форма есть дерево. Если представить программу в графическом виде, получится что-то наподобие тех блок-схем, которые заставляли программистов рисовать лет тридцать назад (была такая разновидность пытки). Небольшие программы состоящие из единственной процедуры так представить можно, но как только программа становится чуть больше толку от блок схемы становится ноль. Куда полезнее представление программы в виде потоков данных. Особенно удобно такое представление для аппаратной реализации алгоритмов. |
Сообщ.
#12
,
|
|
|
Цитата Pavia @ Увы но ЯВУ не сжал код. Разве что длинный код стал широким. Сжал. За счет того, что многие действия теперь стали как бы "за кадром" и делаются компилятором в фоне без участия человека. Добавлено Цитата Pavia @ Вирт учил структурировать программы. Так что это такое структурированная программа? Это когда программист разложил куски по полочкам. Словно расставить вещи по феншую. Это все хорошо работает для искусственных синтетических задач. А для реальных же задач попытка разложить все по полочкам (причем с первого раза) выглядит как попытка натянуть презерватив через голову. Проблема в том, что зачастую объект/сущность нельзя отнести ни к одной полочке. Или напротив, он относится сразу к нескольким полочкам. И потом не забывайте, труд Вирта - это колыбель программирования.Тогда о многих вещах даже не задумывались, считая их фантастикой Но нельзя же вечно находится в колыбели? Нужно расти Добавлено Цитата Pavia @ Лично я пошёл дальше. Давно известно такое словечко как "мажоритарный код". Есть алгоритм - модель которая выполняет основную работу. А есть куча проверок по входным параметрам. Вывод логов. И прочего. Вот все эти проверки и зовутся мажоритарным кодом. Я взял и вынес его в отдельные функции. Отделив словно кожуру от зёрен. Алгоритмы стали более простыми и понятными. Но вот мажоритарный код стал настолько запутанный, насколько это возможно. Следующим шагом была попытка писать код без мажоритарных проверок. Что привело к проблеме. Скорость ловли ошибок снизилось. Отсюда очевидным является, что такой код нужен. Следующий шаг это генерация. Делается это нетрудно. Но пожалуй я не буду рассказывать как. Это называется статический и динамический анализатор кода. Соглашусь что в будущем компилятор должен проверять не просто синтаксис языка, а и его логику и семантику. Я о чем-то подобном уже писал выше: Цитата Исмаил Прокопенко @ сначала на некоем метаязыке описать "правила игры" и суть идеи. А уж потом "играться" с собственно языком программирования Добавлено Цитата amk @ Не дерево, ветви часто потом опять срастаются. Кстати. О дереве. Которое правильней назвать "направленный граф" ибо в нем есть циклы. Его программист тоже не может охватить во всей полноте. И поэтому зачастую программист делает лишние "IF...THEN...ELSE" поскольку не может в голове просчитать и удержать все возможные пути прихода в данную точку программы и каким наборам условий она соответствует. Поэтому "на всякий случай" пишет ещё один "IF...THEN...ELSE" хотя при данной топологии тут ВСЕГДА только "ELSE" реализуется. А система могла бы оптимизировать топологию: свернуть, поменять местами, удалить некоторые условия и т.п. Добавлено Цитата amk @ Куда полезнее представление программы в виде потоков данных. Особенно удобно такое представление для аппаратной реализации алгоритмов. Я думаю что IDE должна обеспечивать несколько "полезных представлений" программы, в зависимости от того, что (какой аспект)в данный момент интересует программиста: "Завязка" по данным, топология "IF-ов" или что-то ещё Добавлено Цитата amk @ но как только программа становится чуть больше толку от блок схемы становится ноль Писал: Цитата Исмаил Прокопенко @ А ещё можно использовать "свертки" когда несколько значков сворачиваются в один. И могут обратно развернуться по клику по значку. Добавлено В этом-то вся и юзюминка, что система программирования должна уметь сворачивать программу до максимально компактного и обобщенного вида и разворачивать программу до самого детального уровня |
Сообщ.
#13
,
|
|
|
Исмаил Прокопенко
Цитата Исмаил Прокопенко @ И потом не забывайте, труд Вирта - это колыбель программирования.Тогда о многих вещах даже не задумывались, считая их фантастикой Но нельзя же вечно находится в колыбели? Нельзя строить дом на гнилом фундаменте. Забывая о основах и они потом бьют по голове. Цитата Исмаил Прокопенко @ Проблема в том, что зачастую объект/сущность нельзя отнести ни к одной полочке. Или напротив, он относится сразу к нескольким полочкам. Вот именно! Это основы. Реальные объекты противоречивы. От сюда вывод нельзя сократить код. Как бы вы не раскладывали по полочкам всегда будут те самые IF которые будут пробовать загнать объект в рамки в которые он не лезет. Вы можете сравнить код на ассемблере и на паскале или си. Размеры кода для одинаковых программ одинаков! Число If не изменилось. Число функций сопоставимо. Число структур данных осталось прежним. Вот циклы да немного сократились. Но в целом на объем программ не повлияло. Отсюда вывод. Декомпозиция нужна не для сокращения кода! Цитата Исмаил Прокопенко @ Как раз таки декомпозиция хорошо себя зарекомендовала на реальных задачах. Мы разбиваем задачу до тех пор пока задачи не станут настолько простыми что исключат саму возможность ошибки. За счёт чего это достигается? За счёт наглядности когда мы видим, что ветки одного рода собраны вместе. Человек быстро обучается и быстро может их проверить. К примеру регулярные выражения. Очень мощный инструмент. Можно написать код быстро и 3 дня искать ошибку. Так почему способ декомпозиции не поручить машине? Человек пользуется около 10 правил. Всех их можно записать и поручить поиск оптиума машине. Функция минимизации известна. Чем меньше не классифицированных IF тем лучше декомпозиция. При равном числе стоит руководствоваться, известностью способом разделения. Под известностью понимается частота встречи у других программистов. Добавлено Цитата Исмаил Прокопенко @ Кстати. О дереве. Которое правильней назвать "направленный граф" ибо в нем есть циклы. Циклы не относятся к мажеретарному коду и должны быть выделены в алгоритмическую часть. Циклы на графике только путают. Поэтому графическое представление должно быть древовидным. Дерево проще проверить. Дойдя до конца ветки. |
Сообщ.
#14
,
|
|
|
Цитата Pavia @ Нельзя строить дом на гнилом фундаменте. Забывая о основах и они потом бьют по голове. Это не фундамент. Это частный случай более сложных вещей. Помните как в физике было? Все верили в незыблемость и фундаментальность классической ("механистической") физики. А потом поняли что т.н. "фундамент" в виде классической физике на самом деле не фундамент, а частный случай квантовой физики+теории относительности+теории неопределенности Гейзенберга+физики элементарных частиц Добавлено Цитата Pavia @ Вы можете сравнить код на ассемблере и на паскале или си. Размеры кода для одинаковых программ одинаков! Число If не изменилось. Число функций сопоставимо. Число структур данных осталось прежним. Это, мягко говоря, неправда. Ибо я писал и на Асм и на Си и на Паскале. Но спорить с Вами не буду, чтобы нам не погрязнуть в деталях и не уйти от основной темы. |
Сообщ.
#15
,
|
|
|
amk
По поводу блок схем. Это тупизм наших учителей. Блок схемы нужны для развития фантазии. Они не ограничивают возможного представления программы. Но наши учителя не понимали этого и заставляли делать единообразно. Посмотри ГОСТ на блоксхемы они не говорят на какие блоки надо разбивать программы. И более не говорят, что рисовать. UML предлагает около 20 разновидностей схем! Цитата Исмаил Прокопенко @ В этом-то вся и юзюминка, что система программирования должна уметь сворачивать программу до максимально компактного и обобщенного вида и разворачивать программу до самого детального уровня Я считаю что стоит не сворачивать, а дать посмотреть под другим углом. Есть такая интересная фраза как "регион интереса". Дерево это один способ представления из 20 видов UML. Свертка это выбор интересующего региона. Наверно видели сферу ключевых слов(тегов). Когда на передней план вытягивается и укрупняется определённый объект. Так же и в программировании должна быть возможность выбрать правильное представление и детальность. Выбрать область. Думаю нужен код для автоматического построения схем. |
Сообщ.
#16
,
|
|
|
Цитата Pavia @ Мы разбиваем задачу до тех пор пока задачи не станут настолько простыми что исключат саму возможность ошибки. Но их количество при этом становится столь велико, что вероятность ошибки растет. Недаром же есть закон Бритвы Оккама: "не плоди лишние сущности" Добавлено Цитата Pavia @ Так почему способ декомпозиции не поручить машине? Человек пользуется около 10 правил. Всех их можно записать и поручить поиск оптиума машине. Функция минимизации известна. Чем меньше не классифицированных IF тем лучше декомпозиция. При равном числе стоит руководствоваться, известностью способом разделения. Под известностью понимается частота встречи у других программистов. О чем и речь: Цитата Исмаил Прокопенко @ Вот не хочу я сразу до конца продумывать все ветвления и всю структуру программы. Я хочу, чтобы "легким движением руки" можно было перекраивать структуру программы причем на любых уровнях абстракции и обобщения и при этом чтобы основная идея не рушилась благодаря тому, что дружественная среда следит за этим Цитата Исмаил Прокопенко @ "Разрезать" говорите? И "распихать"? Так ведь это тоже не тривиальная задача. Почему бы её компилятору не поручить? А если Вы сами "режете" то компилятор должен отслеживать целостность программы и её логики при всех Ваших экспериментах. **************************** Цитата Pavia @ UML. Кстати. Раз уж Вы заговориле о нем. Я слышал что в UML и MatCad-е система умеет сама генерить СИ-шный код по нарисованной блок-схеме. Это так? Добавлено Pavia Ведь в чем опасность классической "правильной и строгой" разработки: пока ты возишься с деталями и придумываешь как обозвать ту или иную переменную или пытаешься записать условие ветвления ты можешь потерять "нить рассуждений" более высокого плана (уровня абстракции) погрязнув в деталях. |
Сообщ.
#17
,
|
|
|
Цитата Исмаил Прокопенко @ Но их количество при этом становится столь велико, что вероятность ошибки растет. Недаром же есть закон Бритвы Оккама: "не плоди лишние сущности" Я давно играю в ГО. И давно понимаю что это одно правило. Разделяй и властвуй. Вместе мы сила. Помните сказочку про прутик и веточку. Попробуй сломать веточку и прутик. Так вот общие правило звучит так. Слабые места надо объединять. Трудные разрезать. Да бритва Оккамы говорит не плоди лишних сущностей. Но это относится к ТЗ. А когда надо написать программы вы пишете уже по готовому ТЗ. А теория моделирования нас учит, что все правила исходят из задания. Т.е из ТЗ. Они уже есть и все сущности там есть. Цитата Исмаил Прокопенко @ Я слышал что в UML и MatCad-е система умеет сама генерить СИ-шный код по нарисованной блок-схеме. Это так? Мы в вузе это делали. Только не MathCad, а MathLab. Код из UML представления приводился в MathCAD. А затем собирали бинарник. Есть инструменты для перевода UML в СИ. Но на самом деле стоит понимать что UML это рекомендации, а не строгие правила. Он создан с целью стандартиризации общения между людьми. Что-бы один человек мог написать а другой прочитать и правильно понять. А то иначе, будет как в Школе Клоунов. Так что в код можно перевести только определённые UML реализации. И то не все разновидности схем. |
Сообщ.
#18
,
|
|
|
чем не естественный язык?
Добавлено Цитата Исмаил Прокопенко @ Т.е. сначала на некоем метаязыке описать "правила игры" и суть идеи. А уж потом "играться" с собственно языком программирования https://ru.wikipedia.org/wiki/%D0%94%D0%A0%...%9A%D0%9E%D0%9D Добавлено Цитата AVA12 @ Кстати, о картинках. Есть такая вещь, как BPMN писал я недавно статью об этом чуде. так вот там все далеко не так однозначно как бы хотелось. одно действие может изображаться разными блоками. плюс к тому все это дело слабо формализовано т.к. эта схема предназначена описывать бизнес процессы в относительно укрупненном виде. и да, только для понимания человеком. |
Сообщ.
#19
,
|
|
|
Исмаил Прокопенко
Цитата Исмаил Прокопенко @ Ведь в чем опасность классической "правильной и строгой" разработки: пока ты возишься с деталями и придумываешь как обозвать ту или иную переменную или пытаешься записать условие ветвления ты можешь потерять "нить рассуждений" более высокого плана (уровня абстракции) погрязнув в деталях. Верно. ГО учит мыслить и побеждать. В игре все имеют равные шансы выиграть. Но почему-то более сильный игрок всегда побеждает более слабого. Нужно делать наиболее срочный ход. Разумеется вы будете забывать и ошибаться. Все программы поставляются AS IS(как есть). Но у вас есть возможность после исправиться и устранить ошибку. Существует очень трудная задача говорят что ей придумал Альберт Эйнштейна и предлагал всем желающим решить её в уме без использования бумаги. Цитата Задача А. Эйнштейна: С другой стороны улицы подряд стоят пять домов, каждый — своего цвета. В каждом живёт человек, все пять — разных национальностей. Каждый человек предпочитает уникальную марку сигарет, напиток и домашнее животное. Кроме того: 1. Норвежец живёт в первом доме. 2. Англичанин живёт в красном доме. 3. Зелёный дом находится слева от белого. 4. Датчанин пьет чай. 5. Тот, кто курит Marlboro, живёт рядом с тем, кто выращивает кошек. 6. Тот, кто живёт в жёлтом доме, курит Dunhill. 7. Немец курит Ротманс. 8. Тот, кто живёт в центре, пьет молоко. 9. Сосед того, кто курит Marlboro, пьет воду. 10. Тот, кто курит Pall Mall, выращивает птиц. 11. Швед выращивает собак. 12. Норвежец живёт рядом с синим домом. 13. Тот, кто выращивает лошадей, живёт в синем доме. 14. Тот, кто курит Winfield, пьет пиво. 15. В зелёном доме пьют кофе. Вопрос: кто разводит рыбок? Только 2% людей могут решить эту задачу правильно. Но стоит нарисовать табличку и задача становится довольно простой. |
Сообщ.
#20
,
|
|
|
Цитата Pavia @ Только 2% людей могут решить эту задачу правильно. Но стоит нарисовать табличку и задача становится довольно простой. Я постоянно об этом твержу. Важность формы представления задачи трудно переоценить. Иногда чтобы решить задачу достаточно выбрать правильную форму её представления и решение станет очевидным. Поэтому то так важно, чтобы разрабатываемую программу можно было представить в компактной, наглядной и удобной для анализа форме. PLAIN-текст такой формой не является ни с какой стороны. Цитата Исмаил Прокопенко @ сложность программирования объясняется <НЕУДАЧНО> выбранной формой представления программы. |
Сообщ.
#21
,
|
|
|
Цитата Исмаил Прокопенко @ Поэтому то так важно, чтобы разрабатываемую программу можно было представить в компактной, наглядной и удобной для анализа форме. PLAIN-текст такой формой не является ни с какой стороны. Тут прочитал анекдот. Сишники могут на любом языке программирования написать Си программу. Искусство рождается только в ограничении. Так вот плоский-текст и есть ограничение. Если человек не может написать нормально в текстовом представлении, то он не сможет сделать это при помощи схем. Вот тут можно посмотреть на машину состояний. Большинство программистов делают её неправильно, а именно не структурируют свой код. http://habrahabr.ru/post/241941/ Кстати в статье тоже есть ошибки, автор падает в другую крайность делать всё табличкой. Когда как удобно комбинировать. PS. Ссылку вначале не ту дал. Потом долго искал правильную. Вставил. |
Сообщ.
#22
,
|
|
|
Цитата Исмаил Прокопенко @ не знаю о чем Вы. я яву не знаю но навскидку она не очень то и отличается от любого другого алгоритмического языка. ну кроме неслабых аппетитов аппаратного обеспеченияНо ведь в свое время изобрели же ЯВУ, которые позволяют сжать/упаковать десятки миллионов строк АСМ-кода в единицы миллионов строк на ЯВУ и написание целого ряда ветвлений поручить компилятору. Цитата Исмаил Прокопенко @ на нечеткую инструкцию компилятор нечетко и отреагирует)описание задачи и способа её решения может быть кратким.И НЕЧЕТКИМ Цитата Исмаил Прокопенко @ по моему такие технологии еще не реализованны на платформе обычной персоналки. банально не хватит скорости работы. а про правильность интерпретации я вообще молчу Хотелось бы все таки чтобы компиляторы поддерживали нечеткую логику и образно-ассоциативную модель мышления человека. Ведь человек в жизни мысли образами и нечетко. И не продумывает задачу сразу всю до мелочей. И постоянно перескакивает с одной задачи на другую даже не закончив до конца первую. |
Сообщ.
#23
,
|
|
|
p486
ЯВУ - это сокращение от слов: Язык Высокого Уровня. |
Сообщ.
#24
,
|
|
|
Цитата Хотелось бы все таки чтобы компиляторы поддерживали нечеткую логику и образно-ассоциативную модель мышления человека. Ведь человек в жизни мысли образами и нечетко. И не продумывает задачу сразу всю до мелочей. И постоянно перескакивает с одной задачи на другую даже не закончив до конца первую. Чтобы было не как в IF..THEN..ELSE было только "Да" или "Нет" Чтобы можно было написать "Возможно", "Скорей всего", "Маловероятно", "Наверное так". Нечеткие формулировки годятся в редких случаях, когда же речь заходит о вычислительных задачах, даже простейших, как дважды два - никаких "возможно" или "маловероятно" быть не может. И даже в этих редких случаях человек может выполнять нечеткую "программу" лишь потому, что у него в мозгу уже есть гигантская "программа", с кучей библиотек, с распознаванием образов и коррекцией ошибок. Современные системы по интеллектуальным возможностям стоят не выше насекомых, "программы" которых очень легко ломаются. Например, ночной мотылек может принять лампу за луну и сбиться с курса, муравьи, движущиеся колонной, могут образовать бесконечный цикл смерти, летающие насекомые уже который десяток миллионов лет попадаются в паутину. Можно ли доверить такому ненадежному устройству расшифровку туманных человеческих хотелок? Я лично считаю, что нет. |
Сообщ.
#25
,
|
|
|
Цитата Pavia @ Так вот плоский-текст и есть ограничение. Если человек не может написать нормально в текстовом представлении, то он не сможет сделать это при помощи схем. Ограничением выступает время и сложность задачи. При некотором уровне сложности задачи Вы используя лишь текст, Notepad и компилятор командной строки для написания кода Вы не решите задачу НЕ ЗА КАКОЕ ВРЕМЯ Добавлено Цитата Pavia @ Тут прочитал анекдот. Сишники могут на любом языке программирования написать Си программу. У меня дежавю? Потому что мне кажется, что именно я это писал Добавлено Цитата AVA12 @ Нечеткие формулировки годятся в редких случаях, когда же речь заходит о вычислительных задачах, даже простейших Нечеткая логика для простейших задач не годится. Только для сверхсложных и объемных от неё будет пруфит Добавлено Цитата AVA12 @ "программы" которых очень легко ломаются. Вот вот. Одно неловкое движение и вся программа рушится как карточный домик. А все потому что нет нормальной среды поддержки программирования, которая бы отслеживала корректность вносимых изменений не только на уровне синтаксиса, но и но более высоких уровнях абстракции |
Сообщ.
#26
,
|
|
|
Цитата А все потому что нет нормальной среды поддержки программирования, которая бы отслеживала корректность вносимых изменений не только на уровне синтаксиса, но и но более высоких уровнях абстракции Еще раз: Цитата Можно ли доверить такому ненадежному устройству расшифровку туманных человеческих хотелок? |
Сообщ.
#27
,
|
|
|
Почитал. Это очень близко к моему мировоззрению: Цитата Проблема сложности Важной проблемой является сложность программирования и поиск путей её преодоления. По мнению кандидата технических наук, доцента Евгения Пышкина, изучение структурного программирования исключительно как инструмента разработки текстов программ, построенных на базе основной «структурной триады» (линейная последовательность, ветвление и цикл), является недостаточным и, по сути дела, сводит на нет анализ преимуществ структурного подхода[29]. В процессе преодоления существенной сложности программного обеспечения важнейшим инструментом является визуализация проектирования и программирования[29]. Визуализация как инструмент преодоления сложности лежит в основе языка ДРАКОН. |
Сообщ.
#28
,
|
|
|
Цитата Исмаил Прокопенко @ Нечеткая логика для простейших задач не годится. почему же не годится? все замечательно работает. но вот достаточно ли точны такие методы, чтобы строить на них компилятор? в этом я очень сомневаюсь Добавлено https://www.youtube.com/watch?v=cOu4BkuvBM0 |
Сообщ.
#29
,
|
|
|
Цитата Исмаил Прокопенко @ Ты тексты сообщений полностью читаешь читаешь, или "увидел знакомое слово - написал ответ"?Вот вот. Одно неловкое движение и вся программа рушится как карточный домик. Там речь о интеллекте насекомых, а не о написании программ. На сегодня исследования в области ИИ недалеко продвинулись от интеллекта насекомых. А главное, обучив ту же нейронную сеть, никогда не знаешь, чему же ты её, собственно, обучил. |
Сообщ.
#30
,
|
|
|
Цитата Исмаил Прокопенко @ А можно ли придумать какую-то форму представления программы, в которой бы не надо этого было делать? Ну или хотя бы чтобы часть "IF..THEN..ELSE" и функций среда разработки генерировала сама. Какие это могут быть формы? Можно. Вы получите язык, близкий к функциональной парадигме. Там нет IF/THEN/ELSE. Там есть pattern matching. |
Сообщ.
#31
,
|
|
|
Цитата pattern matching Появился ещё в 70-х годах прошлого века. Это наше будущее? |
Сообщ.
#32
,
|
|
|
И это форум программистов
Прикреплённый файл_____________________________________.png (34,46 Кбайт, скачиваний: 1293) Добавлено [img]http://forum.sources.ru/index.php?act=Attach&type=post&id=3652736&attach_id=48774[/img] |
Сообщ.
#33
,
|
|
|
Цитата Исмаил Прокопенко @ Важность формы представления задачи трудно переоценить. Иногда чтобы решить задачу достаточно выбрать правильную форму её представления и решение станет очевидным. Неверно. Форма представления всего-лишь определяет путь решения задачи. А после этого этим путем нужно пройти, то есть, написать тот самый миллион строк plain text. И, хотя путь будет очевиден, работающей программы (и решения задачи) по-прежнему не будет, пока plain text не будет написан. Цитата Исмаил Прокопенко @ Поэтому то так важно, чтобы разрабатываемую программу можно было представить в компактной, наглядной и удобной для анализа форме. Опять неверно. Изменение точки зрения (залезть на колокольню) всего-лишь облегчает выбор пути, расширяя горизонты. Но это не является решением задачи. Экономия времени существует лишь одна - если с колокольни видно, что уже существует программа, которая решает ТЗ с приемлемой точностью. А для этого нужно, чтобы прога была уже написана. Все это поняли еще в прошлом веке, когда изобрели модуль под названием "библиотека". То есть, начали повторно использовать код, написанный кем-то другим. Но тут (как обычно) возникает задача "не увидеть за деревьями леса". То есть, в этом хламе из готового кода, нужно ориентироваться. И эту задачу с собственных плеч все время пытаются переложить на чужие - то на компилятор, то на ИИ. И по-прежнему безуспешно. И далее все будет точно также мрачно и беспросветно. Потому что критерии точности и приемлемости выходных данных можно определить только лично. А вот желания это сделать - нет. Отсюда и проблемы. И это - вечные проблемы. Они нерешаемы в принципе. Цитата Исмаил Прокопенко @ PLAIN-текст такой формой не является ни с какой стороны. Plain text является абсолютно точным инструментом изложения алгоритма, поэтому он незаменим (как и клавиатура). Все попытки подменить точность какой-то бредовой аморфной нечеткой логикой обречены на провал. Pavia очень хорошо упомянул об ограниченности любой программы. Я лишь скажу больше - всякая программа статична. То есть, она верна только на момент ее создания и только на входных данных, используемых при тестировании. А в реальных условиях эксплуатации в ней начинают всплывать баги. Потому что она начинает работать с другими данными. И прога бессильна снять с себя эти ограничения, которые в нее были заложены программистом. Ни ИИ, ни прочие CASE-средства (Computer Aided Software Engineering) самостоятельно это решить не могут, потому что творцом программы всегда является человек, а они (CASE и прочее) - всего-лишь инструменты помощи. Которые можно юзать, а можно на них забить. Но есть сроки, в которые нужно уложиться. И тут действительно есть фактор не уложиться в сроки. Но это не означает, что не придется писать код. К тому же, этот уже готовый код может продаваться по такой цене, что все сразу решат, что потратить в три раза больше времени на собственную разработку - очень выгодно. |
Сообщ.
#34
,
|
|
|
Вообще тема - баян.
Еще в 1975 году была издана книжка "Мифический человеко-месяц", которая по-прежнему актуальна. Все попытки попереливать из пустого в порожнее закончатся также бесперспективно - серебряной пули нет. И не будет. |
Сообщ.
#35
,
|
|
|
Когда появится такая супер система, то не нужны будут врачи, судьи, программисты и т.д.
Достаточно будет какого-нибудь верховного или конституционного суда (системного программиста, консилиума врачей и т.д.), чтобы давать пояснения на применение закона в случаях, где законодатель (системный программист и т.д.) нечетко что-то прописал или пропустил или были сделаны новые открытия в медицине и т.д. Абстракция растет, никто не загорает пикселы, чтобы нарисовать линию. Уже есть линии в квадрат, квадрат в куб и еще вращаться это может уже и т.д. Но даже с заливкой текстур это будет только мультфильм (вектор), а не кинофильм (растр), который передает всё многообразие окружающего мира да и то в плоскости. Как из векторов построить требуемый растр? Попиксельно только... Хотя сейчас по сути все программы - это мультики, собранные из кирпичиков. Только много этих разных кирпичиков, и не сложней ли в них ориентироваться будет в общем случае. Один человек не может знать всего даже уже известное человечеству. Нужна специализация и т.д. и что-то это уже напоминает идущую эволюцию. Хорошо, если на новом ветке ее спирали. Сколько всего в WinAPI, Net Frameworke'e, а есть еще и много всего разного и на разных платформах и с разной степенью абстракции и вложенности. А ближе к реальности - это юридические законы надо переписывать на алгоритмических языках, а не программы переписывать на естественном языке. На данном уровне развития. А потом появился 3D принтер, который строит дома. Только строит он их по другому принципу, а не из кирпичиков и слоя цемента между ними. А потом появился 3Д принтер, который напечатал другой 3Д принтер. Прогресс в ИИ не стоит на месте, куда-то все движется с разной степенью успешности. Краткосрочно - видно, долгосрочно - поживем, увидим мы или далекие потомки. А пока ссылка на ДРАКОН вот была. Может это и есть не самая плохая реализация этих идей на данном уровне развития. |
Сообщ.
#36
,
|
|
|
Цитата nash @ Только представьте во что превратится раскрытие строки:А ближе к реальности - это юридические законы надо переписывать на алгоритмических языках if( езда_в_пьяном_виде ) |
Сообщ.
#37
,
|
|
|
Цитата Славян @ Не осилить. с нечеткой логикой это делается на раз |
Сообщ.
#38
,
|
|
|
Цитата Даже в программе, написанной на объектно-ориентированном языке Именно ООП и есть зло. То обстоятельство, что многие пытаются запаковать в черный ящик свой код и выдать для других на выходе КОНФЕТКУ, а на деле получается что большинству нужна именно то что запрятано... И лезут более продвинутые через одно место поправлять, то что сделано другим. Отсюда и все беды. Ведь для того что бы сделать объект, который просто повторно использовать - тратится в десятки раз больше времени, нежели, если просто скопировать и вставить нужный код и обойтись функциональным программированием. |
Сообщ.
#39
,
|
|
|
Цитата cezar @ Именно ООП и есть зло. ну не знаю, не знаю. большинства стандартных компонентов мне хватало для своих нужд и править чето-там потребности не было. правда я уже давненько отошел от "десктопного" и системного программирования. пишу в основном для контроллеров |
Сообщ.
#40
,
|
|
|
Цитата cezar @ Именно ООП и есть зло. Поддержу коллегу. Вот существует стереотип, что якобы ООП якобы помогает бороться со сложностью задачи. Что в ООП путем разбивки задачи на классы и уменьшения связности/зависимости мы уменьшаем сложность задачи. Что разделение задачи на «интерфейс» и «реализацию» упрощает решение задачи. Вообщем, не буду рассказывать все стереотипы об ООП, про которые мы все знаем. Но давайте разберемся и вникнем в детали (реализации). Ведь, как известно, «дьявол в деталях»©. Говорят «интерфейс» и «реализация». А что такое «интерфейс» класса? А это ни что иное как список заголовков PUBLIC методов. А что такое «заголовок метода»? Это имя метода плюс список ТИПОВ его параметров. И вот мы подходим к ключевому моменту: А что такое «типы параметров»? А это не что иное как КЛАССЫ, которые описаны вне данного класса, и которые также имеет интерфейс. Бинго! Получается, что раскрутив всю логическую цепочку, мы видим, что фактически интерфейсом класса является СПИСОК ОПИСАННЫХ ВОВНЕ ДРУГИХ КЛАССОВ. А у тех классов интерфейс – это тоже список описанных вне их классов. И т.д. Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ. Т.е. при ООП никакого упрощения программирования не происходит. Напротив, из-за того, что «ВСЕ СВЯЗАНО СО ВСЕМ» произошло существенное усложнение программирования. Миф об ООП развенчан. Спасибо за внимание. © Все права защищены. При цитировании этой информации где-бы то ни было, ссылки на меня обязательны |
Сообщ.
#41
,
|
|
|
Цитата Исмаил Прокопенко @ Так это ж круто, это ж как получить 2=2 : и красиво, и понятно, и ничему не противоречит! Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ. Цитата Исмаил Прокопенко @ А это почему? Откуда появился этот вывод "Т.е." ? Т.е. при ООП никакого упрощения программирования не происходит. |
Сообщ.
#42
,
|
|
|
Цитата Славян @ Откуда появился этот вывод А поднять глаза на сообщение выше Вашего никак? Добавлено Цитата Славян @ Так это ж круто Ага. До тех пор пока не возникнет потребность что-то изменить. А такая потребность возникает постоянно Добавлено Цитата Славян @ Цитата Исмаил Прокопенко @ Так это ж круто Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ. Если кто не понял - это была "гипербола" (литературный прием такой). Естественно что буквально когда "все связано со всем" реально не бывает. Я просто так эмоционально хотел показать свой негатив по поводу большого кол-ва возникающих запутанных связей при ООП. Так как хоть и не "все связано со всем" но реально кол-во связей при ООП возникает гораздо больше, чем пишут в книжках и учебниках Добавлено И получается что никакой "инкапсуляции" по факту нет Так ты не можешь изменить внешний класс "без оглядки" на тот, где он используется как параметр, поле или базовый. Например, в общем случае, ты не можешь НЕЗАВИСИМО изменять число методов, их имена и сигнатуры Добавлено Т.е. при проектировании ты должен, как минимум, продумывать имена и сигнатуры методов СРАЗУ ВСЕХ взаимосвязанных классов и потом не можешь их менять. Вот где попа. СРАЗУ ВСЕХ, Карл. И это называется "решать задачу по частям"? |
Сообщ.
#43
,
|
|
|
Цитата Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ. Вообще-то иерархия классов и интерфейсов строится так, что зависимости образуют ацикличный орграф, так что никаких "все со всеми" быть не может. Цитата из-за того, что «ВСЕ СВЯЗАНО СО ВСЕМ» произошло существенное усложнение программирования Нифига. В прцедурном подходе тоже есть граф зависимостей структур данных и процедур/функций для их обработки. Цитата И получается что никакой "инкапсуляции" по факту нет А что тут подразумевается под "инкапсуляцией"? Чем не нравится сокрытие деталей реализации? Цитата Т.е. при проектировании ты должен, как минимум, продумывать имена и сигнатуры методов СРАЗУ ВСЕХ взаимосвязанных классов и потом не можешь их менять. Не могу представить такую ситуацию. Разве что наложить кучу божественных классов, каждый из которых и шьет, и жнет, и на дуде играет. Но ведь это неправильный подход! Похожее поведение у разных по сути классов? Есть интерфейсы и примеси. Одинаковые имена методов с разным поведением? Это можно предвидеть заранее и сразу давать методам понятные имена, чем специфичнее поведение, тем специфичнее имя. |
Сообщ.
#44
,
|
|
|
Цитата AVA12 @ Вообще-то иерархия А классы-параметры? А классы-поля? Или "тут видим, а тут не видим"(с)? Добавлено Цитата AVA12 @ так что никаких "все со всеми" быть не может "Тут читаем, а тут не читаем"(с)? Я же написал: Цитата Исмаил Прокопенко @ Если кто не понял - это была "гипербола" (литературный прием такой). Естественно что буквально когда "все связано со всем" реально не бывает. Я просто так эмоционально хотел показать свой негатив по поводу большого кол-ва возникающих запутанных связей при ООП. Добавлено Цитата AVA12 @ Нифига. В прцедурном подходе А при чем тут он? Я о нем не говорил. Добавлено Цитата AVA12 @ Чем не нравится сокрытие деталей реализации? Тем что эти "детали" зависят от внешних классов. А значит не инкапсуляция это никакая |
Сообщ.
#45
,
|
|
|
Цитата Исмаил Прокопенко @ Почему обязательно классы? Это могут быть интерфейсы или вовсе параметры шаблона неведомого типа. А классы-параметры? А классы-поля? Или "тут видим, а тут не видим"(с)? |
Сообщ.
#46
,
|
|
|
Цитата AVA12 @ Не могу представить такую ситуацию. Вот и я не могу. Представить, чтобы кто-то смог сразу безошибочно определить все кортежи всех взаимосвязанных классов. А ООП именно этого требует. |
Сообщ.
#47
,
|
|
|
Цитата Исмаил Прокопенко @ Далеко не всегда зависят. Писать надо грамотно, чтобы не связанные классы не зависели от реализации друг-друга. Тем что эти "детали" зависят от реализации внешних классов |
Сообщ.
#48
,
|
|
|
Цитата applegame @ Почему обязательно классы? Ну если пишем простые программы уровня "Халлоу! Ворлд!" и используем только базовые/зарезервированнные типы параметров и полей то да,проблем нет. А если писать что-то сложней "Халлоу! Ворлд!"? Добавлено Цитата applegame @ Писать надо грамотно, чтобы не связанные классы не зависели от реализации друг-друга. Просветите как. Как можно написать класс-параметр метода другого класса так, чтобы его можно было менять как угодно "не оглядываясь" на класс, в котором этот класс используется как параметр (соответственно внутри класса юсается интерфейс класс-параметра) |
Сообщ.
#49
,
|
|
|
Цитата Исмаил Прокопенко @ Я же написал - интерфейсы и параметры шаблона. Что непонятного? Определение класса зависит от интерфейса, но не от реализации внешнего класса. Эта реализация вообще может быть в другой библиотеке. О какой зависимости вы тут глаголете? Ну если пишем простые программы уровня "Халлоу! Ворлд!" и используем только базовые/зарезервированнные типы параметров и полей то да,проблем нет. А если писать что-то сложней "Халлоу! Ворлд!"? Добавлено Цитата Исмаил Прокопенко @ На каком языке вам написать пример? Просветите как. Как можно написать класс-параметр метода другого класса так, чтобы его можно было менять как угодно "не оглядываясь" на класс, в котором этот класс используется как параметр (соответственно внутри класса юсается интерфейс класс-параметра) |
Сообщ.
#50
,
|
|
|
Ведь что получается.
Если ты в методе класса Y в типе параметра указал некий класс Z, то для Z это означает, что ты не можешь менять его без оглядки на Y (без "согласия" на это класса Y). Добавлено Цитата applegame @ Я же написал - интерфейсы и параметры шаблона. Что непонятного? ВСЁ непонятно. Наверное я дурак. Извольте объяснить "на пальцах" |
Сообщ.
#51
,
|
|
|
Цитата Исмаил Прокопенко @ Что именно менять нельзя? Реализацию можно менять без всякой оглядки. Интерфейс менять нельзя, но это уже не проблема конкретно ООП, это ограничение работает для любой парадигмы. Но я бы вообще это проблемаой не называл. Ведь программы для того и пишутся, чтобы строить связи между компонентами. Ведь что получается. Если ты в методе класса Y в типе параметра указал некий класс Z, то для Z это означает, что ты не можешь менять его без оглядки на Y (без "согласия" на это класса Y). |
Сообщ.
#52
,
|
|
|
Цитата applegame @ На каком языке вам написать пример? На С++ естественно. Тут 84% участников в основном на нем пишут |
Сообщ.
#53
,
|
|
|
Цитата А классы-параметры? А классы-поля? Я не совсем точно выразился. Я имел в виду не только иерархию наследования, но и прочие зависимости. Цитата Цитата А при чем тут он?Нифига. В прцедурном подходе Я о нем не говорил. Хорошо, тогда ООП усложнил программирование по сравнению с чем? Цитата Цитата Тем что эти "детали" зависят от реализации внешних классовЧем не нравится сокрытие деталей реализации? И как же детали реализации одного класса зависят от деталей реализации другого класса? Можно пример? Цитата Если ты в методе класса Y в типе параметра указал некий класс Z, то для Z это означает, что ты не можешь менять его без оглядки на Y (без "согласия" на это класса Y). Неверно. Можно вносить изменения, не противоречащие исходному контракту. А если контракт изначально хреновый, значит проектировщик никудышный. Это не проблема ООП, при других подходах тоже могут быть ошибки проектирования. |
Сообщ.
#54
,
|
|
|
Цитата applegame @ Что именно менять нельзя? ....Интерфейс менять нельзя, Вот вот. А я разве про это не сказал? Цитата Исмаил Прокопенко @ Т.е. при проектировании ты должен, как минимум, продумывать имена и сигнатуры методов СРАЗУ ВСЕХ взаимосвязанных классов и потом не можешь их менять. Вот где попа. СРАЗУ ВСЕХ, Карл. И это называется "решать задачу по частям"? Не читали? Но осудили Добавлено Цитата AVA12 @ И как же детали реализации одного класса зависят от деталей реализации другого класса? Можно пример? Да ради Бога. К примеру в списке параметров метода g класса X есть объект h класса Y. И теле g по полной юсается интерфейс класса Y. А теперь скажите мне: как Вы сможете "КАК УГОДНО" менять интерфейс класса Y не оглядываясь на класс X? Добавлено Цитата AVA12 @ Можно вносить изменения, не противоречащие исходному контракту. А если контракт изначально хреновый, значит проектировщик никудышный. Это не проблема ООП, Это проблема ООП. Так как программист вынужден СРАЗУ/ОДНОВРЕМЕННО продумывать контракты (в Вашей терминологии) СРАЗУ ВСЕХ взаимодействующих классов. И потом уже не может их безболезненно менять |
Сообщ.
#55
,
|
|
|
Цитата Исмаил Прокопенко @ А что у вас есть альтернативы ООП, у которых есть возможность менять интерфейсы без каких-либо последствий? Вот вот. А я разве про это не сказал? Добавлено Цитата Исмаил Прокопенко @ Вы не путайте интерфейс и реализацию - это разные вещи. А то вас трудно понять. Говорят про реализацию, а вы толкаете про интерфейсы. Да ради Бога. К примеру в списке параметров метода g класса X есть объект h класса Y. И теле g по полной юсается интерфейс класса Y. А теперь скажите мне: как Вы сможете "КАК УГОДНО" менять интерфейс класса Y не оглядываясь на класс X? |
Сообщ.
#56
,
|
|
|
Цитата К примеру в списке параметров метода g класса X есть объект h класса Y. И теле g по полной юсается интерфейс класса Y. А теперь скажите мне: как Вы сможете "КАК УГОДНО" менять интерфейс класса Y не оглядываясь на класс X? Слишком абстрактно. Парадигма не позволяет кодеру творить все, что вздумается? Ну так это нормально. Компилятор, вон, тоже ограничивает кодера синтаксисом языка. Раз уж речь идет о малопригодности парадигмы, значит есть реальные, конкретные причины для таких жалоб? Нужен конкретный пример: исходные классы/инерфейсы/примеси, исходный контракт (что на входе, что на выходе, поподробнее), итоговая ситуация, при которой необходимо переделывать контракты. А иначе эти жалобы - пустой треп. Цитата Это проблема ООП. Нет, это проблема кодера. Нет и никогда не было (и, думаю, никогда не будет) никаких магических парадигм, позволяющих стучать пяткой по клавиатуре и сразу получать работающий код. Цитата Так как программист вынужден СРАЗУ/ОДНОВРЕМЕННО продумывать контракты (в Вашей терминологии) СРАЗУ ВСЕХ взаимодействующих классов. И потом уже не может их безболезненно менять Однако же огромные программные комплексы как-то создаются, причем не отдельными программистами, а коллективами (это дополнительные затраты на всякие согласования). Если парадигма работать не может, как же она тогда работает? P. S. И все-таки, по сравнению с чем ООП усложнил программирование? |
Сообщ.
#57
,
|
|
|
Цитата applegame @ шаблона Шаблоны - это уже не ООП, другая парадигма. МЕТАпрограммирование Добавлено Цитата AVA12 @ Вы не путайте интерфейс и реализацию - это разные вещи. А то вас трудно понять. Говорят про реализацию, а вы толкаете про интерфейсы. Я говорил про то, что НЕВОЗМОЖНО менять КАК УГОДНО (хошь интерфейс, хошь реализацию) класс-параметр и класс-поле "без оглядки" на класс, в котором находятся эти параметры и поля. Т.е. налицо ЗАВИСИМОСТЬ. А то, что я НЕ говорил - не надо мне приписывать или ДОДУМЫВАТЬ. Добавлено Цитата AVA12 @ Слишком абстрактно. Парадигма не позволяет кодеру творить все, что вздумается? Ну так это нормально. Компилятор, вон, тоже ограничивает кодера синтаксисом языка. Не надо передергивать. Если "парадигма" говорит, что можно разбивать задачу на НЕЗАВИСИМЫЕ куски и прорабатывать их по отдельности (они же независимы), а по факту это не так, то ДЕРЬМО это, а не парадигма. И по факту получается, что никакого облегчения нет. И программист должен решать задачу не по частям, не по методу "последовательного уточнения", а должен БЕЗОШИБОЧНО расписать СРАЗУ ВСЕ кортежи зависимых классов. А если классов больше сотни и в каждом по 10 и более кортежей? А в каждом кортеже по 5 и более слотов? Получается полная задница Добавлено И не дай Бог вам ошибиться хотя бы в одном слоте из нескольких тысяч. Обретете такой гимор, что проклянете тот день, когда родились на свет Добавлено Цитата AVA12 @ Нет и никогда не было (и, думаю, никогда не будет) никаких магических парадигм, позволяющих стучать пяткой по клавиатуре и сразу получать работающий код. "В огороде бузина, а в Киеве - дядько"(с) Давайте все же Вы не будете скатываться на откровенный троллинг Добавлено Цитата AVA12 @ Однако же огромные программные комплексы как-то создаются Вот именно "как-то". Годами и ДЕСЯТИЛЕТИЯМИ создается то, что можно было создавать за пару недель. Зато все счастливы и программисты чувствуют себя важными людьми, надувают щёки и получают хорошие зарплаты. Хотя можно было из 10 тыс. программистов оставить одного который бы делал даже больше. |
Сообщ.
#58
,
|
|
|
Исмаил Прокопенко, как же это вы так проектируете систему, что у вас не получается придумать нормальные интерфейсы и приходится городить больше сотни хрупких жестко связанных классов? Может, вы используете классы и объекты, но не используете ООП? Пример в студию! Распишите, как вам пришлось столкнуться с подобными проблемами, что это были за классы, что они делали, почему пришлось все переделывать. А кликушествовать любой дурак может.
Цитата Давайте все же Вы не будете скатываться на откровенный троллинг Если кодер не может придумать простые, надежные и легко расширяемые интерфейсы, а сразу городит неподдерживаемого монстра, то с моей точки зрения это как раз "пяткой по клавиатуре". Цитата Годами и ДЕСЯТИЛЕТИЯМИ создается то, что можно было создавать за пару недель. Mwa-ha-ha! Нынче любой школьник знает, что корень из двух - число иррациональное, а пифагорейцы долго дотумкать не могли. Во идиоты! Заменить десятилетия коллективного труда на две недели индивидуального - это бред. Кнопку "сделать базу данных, чтоб работала" еще не изобрели. P. S. И еще раз: по сравнению с чем ООП усложнила программирование? |
Сообщ.
#59
,
|
|
|
Цитата AVA12 @ Исмаил Прокопенко, как же это вы так проектируете систему, что у вас не получается придумать нормальные интерфейсы и приходится городить больше сотни хрупких жестко связанных классов? Кто Вам сказал не получается? Получается. Если долго мучиться можно и баобаб в 3 обхвата спилить зубочисткой. Я лишь пытаюсь донести мысль, что это гиморно. "Почему" повторять? Или Вы все же потрудитесь прочитать и, главное, понять, то, что я сегодня написал в этой теме? Или будете даже не попытавшись разобраться в том, что я пишу, продолжать уверять меня, что я не прав (по принципу "не читал, но осуждаю"(с)) задавать мне миллион вопросов? Добавлено Цитата AVA12 @ Заменить десятилетия коллективного труда на две недели индивидуального - это бред. Почему бред? Вы же сами сказали Цитата AVA12 @ Нынче любой школьник знает, что корень из двух - число иррациональное, а пифагорейцы долго дотумкать не могли. Добавлю лишь, что сейчас студент окончивший первый курс технического ВУЗа знает больше об устройстве вселенной, чем лучшие умы, академики 17-го века. Добавлено Цитата AVA12 @ Кнопку "сделать базу данных, чтоб работала" еще не изобрели. Надеюсь Вы не будете отрицать, что сейчас студент троечник 2-го курса, который учится на программиста ЗАПРОСТО напишет программу над которой 40 лет назад бились огромные коллективы лучших программистов? |
Сообщ.
#60
,
|
|
|
Цитата Или Вы все же потрудитесь прочитать и, главное, понять, то, что я сегодня написал в этой теме? Что ж тут понимать? Голые декларации в духе "все пропало, куда катится мир!", без реальных примеров. Оснований доверять вашим словам нет никаких. Цитата Почему бред? Вы же сами сказали Извиняйте, таблички "сарказм" у меня при себе нет. Цитата сейчас студент троечник 2-го курса, который учится на программиста ЗАПРОСТО напишет программу над которой 40 лет назад бились огромные коллективы лучших программистов? С помощью ООП? Ну вот, а говорите, что ООП все только усложняет! Над чем могли 40 лет назад трудиться целые коллективы программистов? Операционные системы, потребляющие минимум ресурсов тогдашних машин и дающие максимальную производительность и функциональность? Боюсь, даже в наши дни такие задачи далеко не тривиальны. Специфические расчетные задачи? Ну, при наличии специфических библиотек и на современном железе, пожалуй, можно осилить. А вот с нуля и чтоб сразу работало - сомневаюсь. Технологический разрыв между нынешним днем и, скажем, прошлым десятилетием совсем мал, так что вместить несколько человековеков в две человеконедели (угу, миллион строк отлаженного и документированного кода в день) - это наивно. Даже если снизить планку в разы - все равно нереально. Сможете ли вы за две недели воспроизвести с нуля, скажем, MS-DOS 6.22? Боюсь, только на чтение документации (что гораздо легче, чем написание документации) уйдет больше времени. P. S. Ну, вы поняли. |
Сообщ.
#61
,
|
|
|
Исмаил Прокопенко
Я рад что до вас наконец-то дошла моя мысль, которую я вам говорил полгода-год назад: ООП не уменьшает числа связей! Но всё-же мощь ООП в другом. Первым языком ООП был Smalltalk и в отличии от других языков он был дикларативным, а не императивным. ООП позволяет человеку пользоваться домыслами. Правильно подобранные название позволяют не вникать в суть не изучать внутренности, а догадываться и домысливать как оно там устроенно. Т.е. отсечение связи делает человек в меру своих знаний о окружающем мире. Цитата Исмаил Прокопенко @ Надеюсь Вы не будете отрицать, что сейчас студент троечник 2-го курса, который учится на программиста ЗАПРОСТО напишет программу над которой 40 лет назад бились огромные коллективы лучших программистов? Недавно пробегался по программам которые 40 лет назад делались. Скажу честно не напишет. Цитата Почему бред? Число веток в программе не уменьшается. Как и 40 лет назад их все надо продумать, закодить, проверить. Больше 1 МБ в год 1 кодер не напишет - физически. И время необходимое для обучения человека тоже не изменилось. По-поводу упростить. За всё время развития информатики и программирования, только структуры+алгоритмы имеют чёткое обоснование которое позволяет ускорить если не разработку так работу конечной программы. |
Сообщ.
#62
,
|
|
|
Цитата Исмаил Прокопенко @ Я говорил про то, что НЕВОЗМОЖНО менять КАК УГОДНО (хошь интерфейс, хошь реализацию) класс-параметр и класс-поле "без оглядки" на класс, в котором находятся эти параметры и поля. Т.е. налицо ЗАВИСИМОСТЬ. А то, что я НЕ говорил - не надо мне приписывать или ДОДУМЫВАТЬ. Хорошо, вы считаете это проблемой и считаете, что она свойственна именно ООП. Вопрос: какая парадигма, по вашему, лишена этого "недостатка"? |
Сообщ.
#63
,
|
|
|
в смехогрехе санитарный день?
|
Сообщ.
#64
,
|
|
|
Цитата AVA12 @ Голые декларации в духе "все пропало, куда катится мир!", Вы троллите? Я же написал: Цитата Исмаил Прокопенко @ А что такое «интерфейс» класса? А это ни что иное как список заголовков PUBLIC методов. А что такое «заголовок метода»? Это имя метода плюс список ТИПОВ его параметров. И вот мы подходим к ключевому моменту: А что такое «типы параметров»? А это не что иное как КЛАССЫ, которые описаны вне данного класса, и которые также имеет интерфейс. Бинго! Получается, что раскрутив всю логическую цепочку, мы видим, что фактически интерфейсом класса является СПИСОК ОПИСАННЫХ ВОВНЕ ДРУГИХ КЛАССОВ. А у тех классов интерфейс – это тоже список описанных вне их классов. И т.д. Куда уж конкретней? Что в этом тексте у Вас вызывает непонимание? Добавлено Цитата Pavia @ ООП не уменьшает числа связей! Вот именно. Добавлено Цитата Pavia @ Число веток в программе не уменьшается. Как и 40 лет назад их все надо продумать, закодить, проверить. Тут Вы не совсем правы. Число IF-ов, которые программист должен ВРУЧНУЮ "разрулить" при переходе от языков низкого уровня к языкам высокого уровня сокращается. Чтобы понять это достаточно заглянуть в исходник на С++ и посмотреть сколько в нем IF-ов. А потом заглянуть в машинный код, который получается после компиляции исходника на С++, и посмотреть сколько там инструкций условных переходов. Их там на порядок больше. Просто они в исходнике оказываются "ниже уровня абстракции" и генерятся автоматически компилятором без участия программиста. Полагаю, что при переходе от языков высокого уровня (типа С++) к языкам СВЕРХвысокого уровня число IF-ов, которые вручную должен "разрулить" программист будет еще меньше. ПРОГРАММИРОВАНИЕ БЕЗ IF-ов Добавлено Цитата Pavia @ Правильно подобранные название позволяют не вникать в суть не изучать внутренности, а догадываться и домысливать как оно там устроенно. Не спорю. Но проблемы начинаются когда нужно изменить интерфейс класс, а класс используется прямо или косвенно во многих других классах как базовый, как параметр или как поле Добавлено Цитата Pavia @ Больше 1 МБ в год 1 кодер не напишет - физически. Смотря как считать эти мегабайты. А то если считать суммарный объем DLL и EXE-шников (а ведь это является конечным продуктом труда кодера), то кодер и ГИГАБАЙТЫ за год может наваять Добавлено Цитата Pavia @ За всё время развития информатики и программирования, только структуры+алгоритмы имеют чёткое обоснование Только вот форма представления "структур+алгоритмов" может быть разной. А ведь она НАПРЯМУЮ влияет на скорость решения задачи. К примеру преставление задачи в виде исходника на С++ 10, занимающее всего 10 строчек кода, на ассемблере выльется в 100 и более строк Добавлено Цитата applegame @ Хорошо, вы считаете это проблемой и считаете, что она свойственна именно ООП. Вопрос: какая парадигма, по вашему, лишена этого "недостатка"? Я не говорил "именно" или "только" ООП. Я просто сказал что такая проблема в ООП существует. И все. По остальным Вашим вопросам ничего сказать не могу, поскольку пока не размышлял над ними |
Сообщ.
#65
,
|
|
|
Pavia:
Цитата Первым языком ООП был Smalltalk и в отличии от других языков он был дикларативным, а не императивным. Это действительно так? Я со смолтоком не имел дела, но из его описания и примеров кода можно сделать вывод, что это императивный язык: есть глобальное состояние (объекты), есть типичный цикл из повторяющегося чтения/обработки/записи состояния. Исмаил Прокопенко: Насчет орграфа зависимостей я знаю, мне непонятно только, ПОЧЕМУ непременно должны получаться хрупкие монстры, малейшие изменения в которых рушат весь код?! Цитата Но проблемы начинаются когда нужно изменить интерфейс класс, а класс используется прямо или косвенно во многих других классах как базовый, как параметр или как поле Можно расширить типы принимаемых параметров. Можно сузить тип результата. Можно добавить дополнительные параметры (со значениями по умолчанию) - с их помощью даже можно расширить тип результата метода. Про дополнительные методы вообще молчу. Короче, есть много способов кардинально изменить интерфейс, при этом не порушив уже использующий его код. Как (и, главное, зачем) же нужно извращаться, чтобы код все-таки сломался? Пример, пожалуйста! |
Сообщ.
#66
,
|
|
|
Ух, как нажористо то... Идея придумывать (и описывать) интерфейсы, по которым компоненты системы взаимодействуют между собой, кажется Исмаилу контрпродуктивной. Ну-ну. Тут можно было бы рассказать про техники уменьшения связности, проектирование на уровне абстрактных интерфейсов и проч., но не буду. Зачем осквернять такой бурный фонтан откровений толикой здравого смысла?
Добавлено Но ладно. Представим себе такую ситуевину - серебряную пулю изобрели и интерфейсы (и контракты) стало можно менять незаметно для пользователей. И вот однажды приходит Исмаил к себе домой, а там вся техника - сгоревшая. Это просто электрики (никого не предупредив) изменили контракт интерфейса - вместо 220 начали подавать 380. Не, нуачо? Можно ведь... Или вот яблочники - нет, чтобы пользоваться стандартным Micro-USB, изобретают вот новые яблоки. Был разъём для ушей - и нету теперь. Нужно специальные адаптеры покупать. Не, нуачо? Явочным образом менять контракты и интерфейсы - это ведь так здорово! |
Сообщ.
#67
,
|
|
|
Цитата AVA12 @ Насчет орграфа зависимостей я знаю, мне непонятно только, ПОЧЕМУ непременно должны получаться хрупкие монстры, малейшие изменения в которых рушат весь код?! Естественно не ЛЮБЫЕ изменения "рушат код". Но ситуация выглядит так: программист, в худшем случае, должен БЕЗОШИБОЧНО написать СРАЗУ ВСЕ кортежи сразу ВСЕХ зависимых классов {кортеж - в смысле список вида: имя_метода(параметр1, параметр2, ..., параметрN}, а потом не может их менять. Так как эти кортежи уже много где используются. При желании, конечно можно и Но в сложных случаях это так гиморно, что по затратам сравнимо с проектированием системы классов с нуля. Добавлено Цитата AVA12 @ Короче, есть много способов кардинально изменить интерфейс, при этом не порушив уже использующий его код. Примеры в студию. Как можно изменить имя метода класса X, чтобы использующие его другие классы "не заметили" этого? Как можно изменить типа параметра в классе X или вообще его убрать, чтобы использующие его другие классы "не заметили" этого? Как можно вообще удалить из интерфейса некоторый метод в классе X, чтобы использующие его другие классы "не заметили" этого? Цитата AVA12 @ Короче, есть много способов кардинально изменить интерфейс, при этом не порушив уже использующий его код. Только все эти способы основаны на том, что программист ЗАРАНЕЕ должен знать, что будет, возможно, изменяться. ЗАРАНЕЕ, Карл. Т.е. мало того, что программист должен ПРОДУМАТЬ интерфейсы СРАЗУ ВСЕХ зависимых (в т.ч. косвенно) классов, так он при проектировании должен ЗАРАНЕЕ предусмотреть какие изменения возможны в системе интерфейсов. Т.е. задача еще больше усложняется. Добавлено Цитата Flex Ferrum @ Идея придумывать (и описывать) интерфейсы, по которым компоненты системы взаимодействуют между собой, кажется Исмаилу контрпродуктивной. Ну-ну. Я об этом не говорил. Не надо передергивать. Я лишь хотел сказать, что в книжках по ООП в С++ детям пудрят мозги. В этом, собственно, все что я хотел сказать. Что на самом деле если в методах класс параметры и поля тоже классы, то никакой инкапсуляции уже нет, так как "кишки" твоего класса зависят от "кишок" других ("внешних") классов. И на самом-то деле интерфейсом твоего класса является список заголовков методов не только "твоего" класса, но и ВСЕХ внешних классов, которые прямо или косвенно "используются" в твоем классе в качестве параметров, полей или базовых классов. |
Сообщ.
#68
,
|
|
|
Цитата Исмаил Прокопенко @ Т.е. мало того, что программист должен ПРОДУМАТЬ интерфейсы СРАЗУ ВСЕХ зависимых (в т.ч. косвенно) классов, так он при проектировании должен ЗАРАНЕЕ предусмотреть какие изменения возможны в системе интерфейсов. Т.е. задача еще больше усложняется. Вообще то именно для этого и существует этап проектирования - собираются требования, выделяются компоненты/классы, прорабатываются интерфейсы их взаимодействия. Чем ответственней и качественнее будет выполнена эта работа, тем меньше гемора будет на последующих этапах разработки. И! После того, как интерфейс начал использоваться, стоимость его изменения должна быть относительно высока. В идеале, весь код, использующий интерфейс, должен стать некомпилируемым при малейшем изменении контракта. Это гарантирует, что все пользователи интерфейса перейдут с одной его версии на другую. Добавлено Цитата Исмаил Прокопенко @ В этом, собственно, все что я хотел сказать. Что на самом деле если в методах класс параметры и поля тоже классы, то никакой инкапсуляции уже нет, так как "кишки" твоего класса зависят от "кишок" других ("внешних") классов. И на самом-то деле интерфейсом твоего класса является список заголовков методов не только "твоего" класса, но и ВСЕХ внешних классов, которые прямо или косвенно "используются" в твоем классе в качестве параметров, полей или базовых классов. Исмаил, вы плохо понимаете, о чём говорите. Я бы вам порекомендовал начать с букварей, в которых "детям пудрят мозги", а конкретно - с тех их разделов, где пудрят мозги на предмет forward declaration, abstract classes и (pure) virtual functions. Есть масса техник уменьшения связности кода в C++. Эти техники просто надо уметь использовать. И к ООП всё это имеет довольно слабое отношение. |
Сообщ.
#69
,
|
|
|
Цитата Flex Ferrum @ Тут можно было бы рассказать про техники уменьшения связности Что за техники такие? Цитата Flex Ferrum @ но не буду Понятно. Они должны остаться известными только членам секты свидетелей Йоговы. Но подозреваю тут другое. Вы просто боитесь, что я разобью все Ваши контраргументы в пух и прах, когда Вы от общих "умных слов" перейдете к конкретике. Цитата Flex Ferrum @ проектирование на уровне абстрактных интерфейсов Ну да. Куда нам. Конечно же я не в курсе про абстрактные классы и чисто виртуальные методы. Спасибо что открыли Америку. |
Сообщ.
#70
,
|
|
|
Исмаил, вы очень толсто троллите.
|
Сообщ.
#71
,
|
|
|
Цитата Flex Ferrum @ Но ладно. Представим себе такую ситуевину - серебряную пулю изобрели и интерфейсы (и контракты) стало можно менять незаметно для пользователей. И вот однажды приходит Исмаил к себе домой, а там вся техника - сгоревшая. Это просто электрики (никого не предупредив) изменили контракт интерфейса - вместо 220 начали подавать 380. Не, нуачо? Можно ведь... Или вот яблочники - нет, чтобы пользоваться стандартным Micro-USB, изобретают вот новые яблоки. Был разъём для ушей - и нету теперь. Нужно специальные адаптеры покупать. Не, нуачо? Явочным образом менять контракты и интерфейсы - это ведь так здорово! Вы передергиваете. Программирование это все же не электрика. Поэтому и назвали software в противоположность hardware. И проблемы, существующие в hardware, сглажены или вообще отсутствуют в software. И в software допустимы такие трюки, которые в hardware привели бы к катастрофе или огромным затратам. |
Сообщ.
#72
,
|
|
|
Цитата Исмаил Прокопенко @ Ну да. Куда нам. Конечно же я не в курсе про абстрактные классы и чисто виртуальные методы. Спасибо что открыли Америку. Вы, возможно, и в курсе. Но сдаётся мне, что не умеете всем этим пользоваться. |
Сообщ.
#73
,
|
|
|
Цитата Flex Ferrum @ Исмаил, вы очень толсто троллите. Когда у человека нет доводов в споре, он скатывается на хамство и оскорбления. Например, начинает обвинять оппонента в троллинге. Т.е. у Вас реально аргументов нет получается? Добавлено Цитата Flex Ferrum @ Вы, возможно, и в курсе. Но сдаётся мне, что не умеете всем этим пользоваться. Вы кроме всего прочего еще и телепат? |
Сообщ.
#74
,
|
|
|
Цитата Исмаил Прокопенко @ Вы передергиваете. Программирование это все же не электрика. Поэтому и назвали software в противоположность hardware. И проблемы, существующие в hardware, сглажены или вообще отсутствуют в software. И в software допустимы такие трюки, которые в hardware привели бы к катастрофе или огромным затратам. Я не передёргиваю. Проблема одностороннего нарушения контракта - она существует как в software, так и в hardware. Да и вообще, она существует. Чаще всего в software (в силу того, что подавляющее число программ ничего критически-важного не делают) эта проблема не так серьёзна, как в hardware. Но для софта, применяемого в областях, где от работоспособности программы зависят жизни людей или функционирование вполне себе реальных объектов, contract violation так же серьёзен, как и в области hardware. Добавлено Цитата Исмаил Прокопенко @ Вы кроме всего прочего еще и телепат? Ага. Есть у меня такой скилл. |
Сообщ.
#75
,
|
|
|
Цитата Flex Ferrum @ Вообще то именно для этого и существует этап проектирования Вы так говорите, как будто рады этому. Ну правильно. Я писал об этом. Цитата Исмаил Прокопенко @ Годами и ДЕСЯТИЛЕТИЯМИ создается то, что можно было создавать за пару недель. Зато все счастливы и программисты чувствуют себя важными людьми, надувают щёки и получают хорошие зарплаты. Хотя можно было из 10 тыс. программистов оставить одного который бы делал даже больше. Т.е. программисты САМИ НЕ ЗАИНТЕРЕСОВАНЫ, чтобы программирование упростилось, чтобы программировать мог любой и чтобы один программист мог заменить 1000. Ведь тогда они уже не смогут быть незаменимыми, "надувать щеки" от важности и получать хорошие зарплаты Добавлено Цитата Flex Ferrum @ Я не передёргиваю. Проблема одностороннего нарушения контракта - она существует как в software, так и в hardware. Да и вообще, она существует. Чаще всего в software (в силу того, что подавляющее число программ ничего критически-важного не делают) эта проблема не так серьёзна, как в hardware. Но для софта, применяемого в областях, где от работоспособности программы зависят жизни людей или функционирование вполне себе реальных объектов, contract violation так же серьёзен, как и в области hardware. А Вам не приходило в голову, что в software можно изменить само понятия "контракта"? И уйти от представления интерфейса в виде списка кортежей |
Сообщ.
#76
,
|
|
|
Цитата Исмаил Прокопенко @ Вы так говорите, как будто рады этому. Нет. Я это говорю, потому что перед тем, как что-либо делать, надо бы подумать, как именно это делать. Ну или делать как-то так: Скрытый текст - это специально для обладателя скилла "Не хочу думать, хочу программировать". |
Сообщ.
#77
,
|
|
|
Цитата Flex Ferrum @ Ага. Есть у меня такой скилл. Понятно. Значит никакой конкретики/деталей от Вас не будет. Ну что ж. Произнести с умным видом какой-нибудь специальный термин (типа "абстрактные интерфейсы"), причем ни к месту, а потом "уйти в тень" - так очень просто выглядеть умным. |
Сообщ.
#78
,
|
|
|
Цитата Исмаил Прокопенко @ А Вам не приходило в голову, что в software можно изменить само понятия "контракта"? И уйти от представления интерфейса в виде списка кортежей А вам не приходило в голову, что понятие контракта - оно универсально и представление (даже в области разработки ПО) в виде списка кортежей - это лишь одно из? Вам не приходило в голову, что сигнатура метода - это лишь часть контракта? Не приходило в голову, что вы далеко не всегда можете описать контракт средствами языка программирования? |
Сообщ.
#79
,
|
|
|
Цитата Flex Ferrum @ для обладателя скилла "Не хочу думать, хочу программировать". Нужно не только думать. А еще и задумываться. А что дальше? А как этого можно избежать/обойти? А что еще можно придумать? |
Сообщ.
#80
,
|
|
|
Цитата Исмаил Прокопенко @ А что дальше? А как этого можно избежать/обойти? А что еще можно придумать? Читать умные книжки про принципы проектирования систем, системный анализ, архитектуру, паттерны проектирования и т. п. Хотя бы осилить букварь Гарди Буча "Объектно-ориентированный анализ и проектирование". |
Сообщ.
#81
,
|
|
|
Flex Ferrum
Ладно. Я с Вами достаточно пообщался. А полезной инфы вынес ноль. Играть с Вами в "угадайку" (попробуй угадай, что я имел в виду) и игру "я умный - ты дурак" (где роль "умного" Вы без всяких на то оснований выбрали для себя) мне не интересно. Давно уже вышел из детсадовского возраста. Вы либо нормальным языком рассказываете, либо я пас общаться с Вами. Впрочем, я по любому, пас. |
Сообщ.
#82
,
|
|
|
Цитата Исмаил Прокопенко @ Вы либо нормальным языком рассказываете, либо я пас общаться с Вами. А чего рассказать то? Как программы на C++ писать? Интерфейсы классов прорабатывать? Поймите - вы делаете вброс, из которого видно, что вы совершенно не разбираетесь в предмете. Примерно как "Зачем лечить воспаление антибиотиками, когда подорожник приложить можно". А потом просите что-то вам объяснить, опровергнуть очевидную глупость. Зачем? |
Сообщ.
#83
,
|
|
|
Цитата Flex Ferrum @ Поймите - вы делаете вброс, из которого видно, что вы совершенно не разбираетесь в предмете. Вы делаете вброс, из которого видно, что Вы вообще не въехали, о чем речь. Но при этом сразу стали "надувать щеки" и давать рецепты лечения и наклеивать ярлыки. Досвиданья |
Сообщ.
#84
,
|
|
|
Добавлено Цитата Исмаил Прокопенко @ Вы делаете вброс, из которого видно, что Вы вообще не въехали, о чем речь. Так и о чём же речь? Я то грешным делом подумал про проектирование ПО и приложение этой дисциплины к языку С++. А вы про что? Добавлено Эх... Ну вот... Спугнул... |
Сообщ.
#85
,
|
|
|
Цитата Flex Ferrum @ Читать умные книжки про принципы проектирования систем, системный анализ, архитектуру, паттерны проектирования и т. п. Хотя бы осилить букварь Гарди Буча "Объектно-ориентированный анализ и проектирование". А вот кстати - какие бы ты книги посоветовал на эту тему, кроме уже упомянутой? |
Сообщ.
#86
,
|
|
|
Исмаил Прокопенко:
Цитата Но ситуация выглядит так: программист, в худшем случае, должен БЕЗОШИБОЧНО написать СРАЗУ ВСЕ кортежи сразу ВСЕХ зависимых классов Ну предъявите же этот худший случай! Я просто не представляю, как можно так влипнуть. Мне ни разу не приходилось продумывать одновременно все контракты (тем более, что программы развиваются, порой непредсказуемым образом). Я не держу в голове детали работы всех-всех классов, мне вполне хватает "кэша" на несколько нужных в данный момент. Да, мне приходится иногда перелопачивать интерфейсы и зависящие от них классы, но только для новых интерфейсов, когда "примеряю" их на новые классы, а далее приходится только расширять, ничего не ломая. Правда, я пишу не энерпрайзные мегапроекты и не на плюсах, так что, возможно, в плюсах все действительно так плохо. Ну так покажите пример! Вообще же самые серьезные проблемы создания правильных интерфейсов возникают при проектировании всяких API. Вот тут действительно приходится вертеться, ведь готовые приложения уже не перепишешь. Документация по Win32 API, например, читается, как приключенческий роман - четко видна история развития и то, как разработчики стелили соломку и обходили грабли. И ведь справлялись же! А если следовать вашей логике, то никакие API в принципе невозможны. Цитата Примеры в студию. Вы же утверждаете, что граблепад неизбежен, я же только сомневаюсь, так что примеры с вас. Цитата Как можно изменить имя метода класса X, чтобы использующие его другие классы "не заметили" этого? Зачем это делать? Коллизия имен? Ну так это можно заранее предусмотреть - чем специфичнее поведение, тем специфичнее имя. Цитата Как можно изменить типа параметра в классе X или вообще его убрать, чтобы использующие его другие классы "не заметили" этого? Зачем это делать? Устаревший параметр? Ну так можно просто его игнорировать. Или просто убрать, и пусть устаревший код не компилируется. Цитата Как можно вообще удалить из интерфейса некоторый метод в классе X, чтобы использующие его другие классы "не заметили" этого? Зачем это делать? Устаревший метод? Опять же, поставить заглушку или пусть не компилируется. |
Сообщ.
#87
,
|
|
|
Цитата AVA12 @ Ну предъявите же этот худший случай! Я просто не представляю, как можно так влипнуть. Цитата "ИсмаилПркопенко Ну ладно. Раз Вы так умоляете (хотя ей Богу не пойму: что непонятного-то в том, что я написал выше?) Самой простой случай. Есть класс X. В нем метод g(Y,Z) Классы Y,Z описаны, естественно, вне класса X. В теле g вызываются метод h(W) класса Y и метод j(U) класса Z. Таким образом, класс X уже "завязался" на 4 класса: Y,Z,W,U. А ведь это очень примитивный пример. В реале все гораздо сложней и запутанней. |
Сообщ.
#88
,
|
|
|
Цитата OpenGL @ А вот кстати - какие бы ты книги посоветовал на эту тему, кроме уже упомянутой? Помимо этого - "Object-Oriented Software Construction" Мэйера. Но лично у меня основные знания - от прослушанных курсов по RUP. |
Сообщ.
#89
,
|
|
|
Цитата AVA12 @ Мне ни разу не приходилось продумывать одновременно все контракты Кто-то не знаком с такими литературными приемами как "гипербола", "аллегория" и "сарказм"? Нельзя же все буквально понимать. Естественно чтобы АБСОЛЮТНО ВСЕ И СРАЗУ - такое редко бывает. А вот что несколько классов завязаны друг на друга - такое сплошь и рядом. Когда класс нельзя изменить "без оглядки" на другие Добавлено Цитата AVA12 @ А если следовать вашей логике, то никакие API в принципе невозможны. Ну это уже передергивание. "Сложно" не значит "невозможно" Добавлено Цитата AVA12 @ Зачем это делать? Я понимаю чем вызвано Ваше недоумение. Потому что Вас приучили (надрессировали) к стилю программирования, когда не стоит что-то менять в архитектуре даже если ошибся или знаешь как ее улучшить. Так как это повлечет изрядный гимор и большой объем по переделке кода. Поэтому процветает такой подход, когда баги в архитектуре не исправляются, а обходятся и завуалируются. Разного рода обертками, переопределениями в потомках и т.п. Вот поэтому я и говорю. Что мало того, что нужно сразу продумать довольно большой набор кортежей вида имя_метода_класса(класс1, класс2, ..., классN). А если ошибся - потом уже не исправишь. Слишком большой гимор потому что будет. И обычная практика это не исправлять баги проектирования. А завуалировать и обходить их. Разного рода обертками, переопределениями в потомках и т.п. Добавлено Цитата AVA12 @ Вообще же самые серьезные проблемы создания правильных интерфейсов возникают при проектировании всяких API. Вот тут действительно приходится вертеться, ведь готовые приложения уже не перепишешь. Документация по Win32 API, например, читается, как приключенческий роман - четко видна история развития и то, как разработчики стелили соломку и обходили грабли. Да я в курсе. Изучал для общего развития исходники MFC. Там гавнокод на гавнокоде. И никакой книжной красоты ОО-архитектуры и в помине нет |
Сообщ.
#90
,
|
|
|
Цитата Таким образом, класс X уже "завязался" на 4 класса: Y,Z,W,U. И чо? Один класс зависит от других - это нормально. Вы лучше расскажите, какой из этих классов вам пришлось перелопачивать, зачем пришлось это делать и почему именно так, а не иначе. Вот это будет пример. Цитата Кто-то не знаком с такими литературными приемами как "гипербола", "аллегория" и "сарказм"? Нельзя же все буквально понимать. Так может все, что вы написали - это гиперболическая аллегория, и воспринимать это всерьез не нужно? Цитата Вас приучили (надрессировали) к стилю программирования, когда не стоит что-то менять в архитектуре даже если ошибся или знаешь как ее улучшить. Да как же у вас получается настолько ошибаться? Вы что, сразу плодите божественных монстров на все случаи жизни, а потом выясняете, что случаи бывают очень разные? Ну так не надо этого делать. |
Сообщ.
#91
,
|
|
|
AVA12
Ладно. Закончим с Вами. Вижу что серьезного вдумчивого разговора о проблемах с Вами не получится. Как не получилось с Flex Ferrum. Вы тоже начинаете передергивать, подтролливать и играть в игру "я умный ты дурак" и "ты дурак потому что дурак". Вместо того, чтобы попытаться найти рациональное зерно в том, что я пишу. Да я "консерваториев не кончал" может коряво выражаюсь. Ну так я же не программист. Никогда на него не учился. И никогда им не работал. Я самоучка. Но тем не менее. Код пописывал довольно долго. И книжечки почитывал. И о многих вещах, о которых никто не задумывался, задумывался. Вообще, пока не вижу смысла с Вами общаться. Все что хотел Вам сказать, я сказал. А принимать это или не принимать - Ваше дело. А вести спор ради спора, чтобы поразвлечь Вас, мне не интересно |
Сообщ.
#92
,
|
|
|
Цитата Исмаил Прокопенко @ Да я "консерваториев не кончал" может коряво выражаюсь. Ну так я же не программист. Никогда на него не учился. И никогда им не работал. Я самоучка. Но тем не менее. Код пописывал довольно долго. И книжечки почитывал. И о многих вещах, о которых никто не задумывался, задумывался. ЧДТ. То, что вы говорили в этой теме, очень похоже на советы бабулек в очереди к терапевту. Примерно тот же уровень компетенции, о чём вам и было мною сказано несколько постов назад. Если хотите поговорить о том, как ООП используется в реальных проектах - нет проблем, задавайте вопросы, обсудим. А приходить и с умным видом вещать, что через микроскоп звёзды не видно и им гвозди неудобно забивать - ну так, эмм, пардон, аудитория не та. |
Сообщ.
#93
,
|
|
|
Цитата wind @ День открытых дверей. в смехогрехе санитарный день? |
Сообщ.
#94
,
|
|
|
Цитата Flex Ferrum @ То, что вы говорили в этой теме, очень похоже на советы бабулек в очереди к терапевту. Примерно тот же уровень компетенции Докажите. Если Вы не тролль. Дам Вам еще один шанс. Распишите, где я допустил ошибку в своих рассуждениях. Только без хамства, "переходов на личности" и без общих фраз типа "как всем известно ..." и жонглирования терминологией. Гы Про "терминологию" На другом форуме один из участников, желая меня "уесть" и показать мне свою крутость скопипастил из википедии "интерфейс - это абстрактный класс". Когда я его спросил: "а что? Не абстрактный класс не имеет интерфейса?" он сразу стал хамить и в конце концов слился так и не сумев ответить на вопрос. Надеюсь Вы так не сделаете когда я Вам начну задавать "неудобные вопросы" А то Ваши сентенции в стиле "мне кажется" и "переходы на личности" убедительности Вашим словам не добавляют. Может мой взгляд и отличается от Вашего на некоторые вещи, но это не говорит о том, что Ваша точка зрения правильная, а моя нет. А то, что у меня в трудовой книжке нет записи "программист" - это еще не значит, что я ничего не смыслю в программировании. |
Сообщ.
#95
,
|
|
|
Цитата Исмаил Прокопенко @ Докажите. Если Вы не тролль. Дам Вам еще один шанс. О как! Исмаил, тут вам в пору доказывать, что вы - не тролль. Цитата Исмаил Прокопенко @ Распишите, где я допустил ошибку в своих рассуждениях. Эм... Как бы так сказать, по-культурнее. Ваши рассуждения - рассуждения дилетанта. Если конкретно, то ошибка вот в этом переходе: Цитата Исмаил Прокопенко @ Бинго! Получается, что раскрутив всю логическую цепочку, мы видим, что фактически интерфейсом класса является СПИСОК ОПИСАННЫХ ВОВНЕ ДРУГИХ КЛАССОВ. А у тех классов интерфейс – это тоже список описанных вне их классов. И т.д. Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ. Т.е. при ООП никакого упрощения программирования не происходит. То, что при описании интерфейса одного класса могут использоваться другие классы (или интерфейсы), ещё не означает, что "всё связано со всем". Более того, использование в интерфейсах любых доступных классов будет скорее говорить о низком качестве проектирования. В реальной жизни и реальных же задачах в интерфейсе класса используется ограниченное количество других сущностей (классов, типов), что достаточно сильно улучшает управляемость всей конструкции. Вся совокупность классов в проектируемой системе разбивается на пакеты с высокой степенью изолированности друг от друга. Связи между пакетами - по строго специфицированным интерфейсам, при описании которых используется ограниченное число публичных (для пакета) типов. Внутренние (для пакетов) классы наружу не лезут. Ну и всё в том же духе. В результате не получается, что "всё связано со всем". Если при этом проектировщик специально заботится о количестве и качестве связей между пакетами - то система выходит достаточно стройной и легко управляемой. Такие дела. Вообще же, уменьшение внутренней связности проектируемой системы - это одна из основных задач и целей ООП/ООД. Пресловутая аббревиатура SOLID - как раз об этом. |
Сообщ.
#96
,
|
|
|
Цитата Flex Ferrum @ То, что при описании интерфейса одного класса могут использоваться другие классы (или интерфейсы), ещё не означает, что "всё связано со всем". Более того, использование в интерфейсах любых доступных классов будет скорее говорить о низком качестве проектирования. Повторю, что на подобные возражения я говорил на другом форуме: Цитата Ну если ограничиваться только базовыми/встроенными типами (имеются в виду типы формальных параметров у методов) и писать программы уровня "Халоу Ворлд" - то нет проблем. А если ты разрабатываешь (как я) систему искусственного разума, то быстро упираешься в ограничения и проблемы ООП Т.е., как я понял, Вы предлагаете НЕ использовать параметры-объекты? Использовать только базовые/встроенные типы (int, char, float, ...) или в крайнем случает 1-2 класса на все классы программы? Так? В этом заключена сермяжная правда ООП? Добавлено Цитата Flex Ferrum @ Ваши рассуждения - рассуждения дилетанта Иногда дилетант решает проблему, которую не могли решить профи. Просто потому, что профи полагали, что задача не имеет решения. |
Сообщ.
#97
,
|
|
|
Исмаил Прокопенко, вы внимательно меня читаете? Где я предложил использовать в интерфейсах только базовые типы? Правильно, нигде. Я писал, что набор типов/классов, используемых в интерфейсах, ограничевается на этапе проектирования этого самого интерфейса как раз, чтобы избежать ситуации, когда все связаны со всеми. Вы разбиваете все, что у вас есть, на группы классов, объединяете эти группы в пакеты/модули и выбираете - что будет использоваться на границе пакета/модуля, а что всегда будет внутри. Или опять не понятно?
|
Сообщ.
#98
,
|
|
|
Отвечу на это.
Цитата Flex Ferrum @ что вы говорили в этой теме, очень похоже на советы бабулек в очереди к терапевту. Примерно тот же уровень компетенции Цитата Flex Ferrum @ Ваши рассуждения - рассуждения дилетанта Цитата Flex Ferrum @ вы совершенно не разбираетесь в предмете. Вот Вы, типа, как профи себя позиционируете. Только возникает вопрос: вот у Вас 30 лет опыта коддинга, куча сделанных проектов, куча законченных курсов и сертификатов. И прочая и прочая. Казалось бы такой как Вы должен уже иметь свое направление в программировании, кучу учеников из США, которые ездят послушать Ваш курс лекции и получше освоить предложенную Вами новую концепцию в программировании. А что мы видим? Оказывается Вы до сих пор ходите на курсы (упоминалась аббревиатура RUP). Сколько можно учиться? Может пора уже учить? А? Иметь свою научную школу. Учеников, которые ездят на Ваш курс со всего мира. Не? Придумать наконец СВОЮ СОБСТВЕННУЮ концепцию в программировании. Не? Сколько можно? Почему все новое в АйТи идет к нам с запада, а мы только на осваиваем и на курсы ходим. Неужели же мы, россияне, сами настолько слабоумные дауны, что имея 30 лет опыта в коддинге, не может свою собственную концепцию/парадигму в программировании разработать и чтобы у нас весь мир учился. А? Добавлено Цитата Flex Ferrum @ В результате не получается, что "всё связано со всем". Да что вы все докопались до этой фразы? Я же сказал что это бал сарказм, гипербола, аллегория. Просто выражение негативных эмоций по поводу большого числа трудно прослеживаемых зависимостей между классами. Мне написать это себе на лбу, чтобы мне каждый раз не тыкали этой фразой: "все связано со всем". А главное негатив относился к тому, почему в книжках ВРУТ про интерфейс и инкапсуляцию. Почему не говорят, что в общем случае интерфейс класса - это не только список заголовков его методов. А в общем случае еще и список заголовков методов всех классов, которые данный класс использует как поля, параметры или базовые Почему врут про инкапсуляцию? Ведь на самом деле инкапсуляции никакой нет если ты юсаешь объекты в качестве параметров. Так как ты НЕ МОЖЕШЬ менять внешний, по отношению к классу код классов-параметров, как тебе вздумается Добавлено Цитата Flex Ferrum @ Вообще же, уменьшение внутренней связности проектируемой системы - это одна из основных задач и целей ООП/ООД. Я в курсе. Поэтому меня и возмутило: декларируется одно, а по факту имеем куча запутанных трудно прослеживаемых зависимостей. В которых только профи путем многолетнего натаскивания могут разобраться. А казалось бы с такими декларациями "любая домохозяйка ...". Ан нет. Выкуси. Не любая. И никакого упрощения не произошло Добавлено Цитата Flex Ferrum @ Я писал, что набор типов/классов, используемых в интерфейсах, ограничевается на этапе проектирования этого самого интерфейса как раз, чтобы избежать ситуации, когда все связаны со всеми. Вы разбиваете все, что у вас есть, на группы классов, объединяете эти группы в пакеты/модули и выбираете - что будет использоваться на границе пакета/модуля, а что всегда будет внутри. Или опять не понятно? Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры. Как я уже писал,программист должен определить кортежи СРАЗУ многих классов и он не имеет права на ошибку. Т.е. по частям проектировать архитектуру не получится. А если архитектура очень большая? Вот где раздолье для багов. Это по вашему упрощение? А переделка архитектуры на этапе когда код уже почти написан - тот еще геморрой. Добавлено Цитата Flex Ferrum @ Где я предложил использовать в интерфейсах только базовые типы? Правильно, нигде. Я писал, что набор типов/классов, используемых в интерфейсах, ограничевается на этапе проектирования этого самого интерфейса Так я же и говорил: Цитата Исмаил Прокопенко @ или в крайнем случает 1-2 класса на все классы программы? Не заметили? |
Сообщ.
#99
,
|
|
|
Исмаил Прокопенко, на пассаж про собственную школу отвечать не буду. Считайте, что я лузер, если вам от этого будет легче. Мне то всё равно пофиг, что вы там для себя решите.
На счёт фразы - ну, вы сами виноваты, что выделили её капсом. Вас никто не заставлял это делать. Про инкапсуляцию... Вы явно путаете этот термин со связностью. Потому что инкапсуляция - это совсем про другое. А то, что пользователь класса зависит от того, какие типы используются в интерфейсе класса - ну да, факт. Так, собственно, и задумано. Это нормально. Но в ваших руках, руках проектировщика интерфейса, не превратить эту зависимость в ад. Для этого существует несколько техник, но вам для начала нужно разобраться с тем, что есть такое инкапсуляция, что - связность, что - полиморфизм. Ну, коль скоро боретесь рассуждать на такие темы. |
Сообщ.
#100
,
|
|
|
Цитата Flex Ferrum @ Исмаил Прокопенко, на пассаж про собственную школу отвечать не буду. Считайте, что я лузер, если вам от этого будет легче. Мне то всё равно пофиг, что вы там для себя решите. Что неприятно? Что же Вы совершенно незнакомого человека, об опыте и знаниях которого Вы не имеете НИКАКИХ представлений, фактически лузером называете? Даже толком не разобравшись в том, что он предлагает и даже не попытавшись найти рациональное зерно в его рассуждениях. Быстры вы на суд |
Сообщ.
#101
,
|
|
|
Цитата Оказывается Вы до сих пор ходите на курсы (упоминалась аббревиатура RUP). Сколько можно учиться? Хе-хе. Ну прям анекдот про студентку и Эйнштейна. |
Сообщ.
#102
,
|
|
|
Цитата Исмаил Прокопенко @ декларируется одно, а по факту имеем куча запутанных трудно прослеживаемых зависимостей. В которых только профи путем многолетнего натаскивания могут разобраться. Мало про инструмент знать. Надо ещё уметь им пользоваться. А ООП - не самая простая в освоении методология. Цитата Исмаил Прокопенко @ программист должен определить кортежи СРАЗУ многих классов и он не имеет права на ошибку. Т.е. по частям проектировать архитектуру не получится. А если архитектура очень большая? Если архитектура "очень большая", то она строится методом декомпозиции. На каждом уровне иерархии системы определяются интерфейсы, и только в их терминах происходит/формулируется взаимодействие. Как таковой проблемы нет. И да, я строил такие архитектуры. Цитата Исмаил Прокопенко @ Так как переделка архитектуры на этапе когда код уже почти написан - тот еще геморрой. Не такой геморрой, как кажется. Если связи и высокоуровневые интерфейсы изначально выстраивались грамотно, то всё относительно несложно. |
Сообщ.
#103
,
|
|
|
Цитата Flex Ferrum @ А то, что пользователь класса зависит от того, какие типы используются в интерфейсе класса - ну да, факт Только почему об этом никто не пишет, не орет на каждом углу? Зачем детям врут? Почему не говорят всей правды? |
Сообщ.
#104
,
|
|
|
Цитата Исмаил Прокопенко @ Что же Вы совершенно незнакомого человека, об опыте и знаниях которого Вы не имеете НИКАКИХ представлений, фактически лузером называете? Вы знаете, я достаточно в своей жизни провёл собеседований, чтобы по тому, как и что человек говорит, делать выводы о его квалификации. Добавлено Цитата Исмаил Прокопенко @ Только почему об этом никто не пишет, не орет на каждом углу? Зачем детям врут? Почему не говорят всей правды? Мне кажется, проблема не в том, что детям врут, а в том, как вы поняли то, что прочитали. |
Сообщ.
#105
,
|
|
|
Цитата Flex Ferrum @ что - полиморфизм Т.е. я и про полиморфизм не в курсе? Хотя о нем пока разговора не было, но Вы уже как-то поняли, что и про него я НИЧЕГО не понимаю. Опять телепатия? Что еще (из того что я НЕ говорил, но Вы используя телепатию узнали) я не знаю? Не. Не получится у нас с Вами разговора. Вы телепат, а я нет. Силы не равные. Будьте здравы. |
Сообщ.
#106
,
|
|
|
Цитата Исмаил Прокопенко @ Т.е. я и про полиморфизм не в курсе? С учётом того, как вы употребляйте термины - высока вероятность, что нет, не в курсе. Цитата Исмаил Прокопенко @ Что еще (из того что я НЕ говорил, но Вы используя телепатию узнали) я не знаю? Что такое ООП на самом деле, как правильно декомпозировать проектируемую систему/предметную область на объекты/подсистемы, как выстраивать между ними взаимосвязи, как проектировать фасады подсистем, как вообще проектировать интерфейсы. Как-то так. |
Сообщ.
#107
,
|
|
|
Цитата Flex Ferrum @ Цитата Исмаил Прокопенко @ Т.е. я и про полиморфизм не в курсе? С учётом того, как вы употребляйте <прим. СОВСЕМ ДРУГИЕ. НЕ ОТНОСЯЩИЕСЯ К ПОЛИМОРФИЗМУ> термины - высока вероятность, что нет, не в курсе. Телепатия, вероятность,.. Я точно с программистом разговариваю? Добавлено Цитата Flex Ferrum @ как вообще проектировать интерфейсы. Тогда вопрос от "дилетанта". Что такое "интерфейс" в Вашем понимании. Конкретно в коде как он выглядит и что из себя представляет |
Сообщ.
#108
,
|
|
|
Цитата Исмаил Прокопенко @ Я точно с программистом разговариваю? Не, не с программистом. С архитектором. Цитата Исмаил Прокопенко @ Тогда вопрос от "дилетанта". Что такое "интерфейс" в Вашем понимании. Интерфейс - это формализованный способ взаимодействия объектов в проектируемой системы. В общем случае - это набор методов, для каждого из которого сформулирован чёткий контракт - Какие варианты входных параметров к каким результатам приводят. Если приводят. В коде (в зависимости от характера интерфейса) он описывается либо в виде абстрактного класса, если это интерфейс крупной подсистемы, либо совокупностью публичных/защищенных/свободных/статических методов класса, если речь о конкретном классе. Предвосхищая вопрос. Классы, которые являются параметрами этих методов, тоже являются частью интерфейса, так как у них есть свои контракты, на которые полагаются взаимодействующие стороны. |
Сообщ.
#109
,
|
|
|
Цитата Flex Ferrum @ В общем случае - это набор методов, для каждого из которого сформулирован чёткий контракт Давайте не будем затуманивать детям мозги. И скажем проще: набор методов для каждого из которых определена "морда лица" и для чего нужен (за что отвечает) каждый элемент "морды" в отдельности или в совокупности с другими элементами. И кстати, Вы правильно сказали: Цитата Flex Ferrum @ Вам не приходило в голову, что сигнатура метода - это лишь часть контракта? Не приходило в голову, что вы далеко не всегда можете описать контракт средствами языка программирования? Мне это "приходило в голову". Более того. Я кричал об этом на программистских форумах программистам, уверявшим меня, что для работы с классом им ничего кроме его "морды" знать не надо. Что имя метода уже содержит достаточно инфы. Я же пытался убедить их, что интерфейс это не только "морда лица", что в интерфейс также входит инфа (опять раздувание интерфейса) для чего нужен (за что отвечает) каждый элемент "морды". За что они отвечают по отдельности и/или в совокупности. А чтобы получить эту инфу нужно либо лезть в исходный код класса либо курить какое-то описалово. А значит только имени НЕЗНАКОМОГО метода в НЕЗНАКОМОЙ программе недостаточно, для его правильного использования. |
Сообщ.
#110
,
|
|
|
Цитата Исмаил Прокопенко @ А при процедурном подходе, этого что, знать не нужно? Только при процедурном подходе вся эта "морда" размазана по всей программе и имеет длиннющие имена процедур, за которыми приходится следить. Я же пытался убедить их, что интерфейс это не только "морда лица", что в интерфейс также входит инфа (опять раздувание интерфейса) для чего нужен (за что отвечает) каждый элемент "морды". |
Сообщ.
#111
,
|
|
|
Цитата Исмаил Прокопенко @ Давайте не будем затуманивать детям мозги. И скажем проще: набор методов для каждого из которых определена "морда лица" и для чего нужен (за что отвечает) каждый элемент "морды" в отдельности или в совокупности с другими элементами. А давайте без "давайте". Вы спросили как я считаю. Я ответил так, как считаю, без излишней примитивизации. Добавлено Цитата amk @ А при процедурном подходе, этого что, знать не нужно? Только при процедурном подходе вся эта "морда" размазана по всей программе и имеет длиннющие имена процедур, за которыми приходится следить. Да это при любом подходе нужно. Если есть взаимодействующие сущности - значит, нужен специфицированный протокол их взаимодействия, ака интерфейс. На какую музыку этот протокол будет переложен - это уже вопрос реализации. |
Сообщ.
#112
,
|
|
|
Цитата Исмаил Прокопенко @ Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры. Ну да. И что? Или вы можете предложить какой-то способ избежать этот этап, сохранив при этом плюсы его наличия? |
Сообщ.
#113
,
|
|
|
Цитата Исмаил Прокопенко @ Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры. Как-то я это пропустил. Ну да, вносится. Вы можете, не обладая архитектурными навыками, построить халупу у себя на даче. И она даже не развалится (наверное). Но чтобы построить что-то серьёзное - надо таки знать, как строить. |
Сообщ.
#114
,
|
|
|
Отстаньте от Исмаила Прокопенко. Я хочу приобщиться к новому!
Исмаил, вы говорите ООП - это плохо. Допустим вы правы и ООП - действительно плохо. Цитата Исмаил Прокопенко @ Я прочитал этот текст и бросил ООП, и теперь внимательно слушаю, как можно написать за пару недель, то что Flex Ferrum пишет десятилетиями. Я верю, что вы не пустословите и такое действительно возможно, осталось самая мелочь: ответить в общих чертах на вопрос КАК?Годами и ДЕСЯТИЛЕТИЯМИ создается то, что можно было создавать за пару недель. А то я уже получил деньги на разработку двух новых операционных систем в течение месяца (по две недели на каждую ОС), не хотелось бы их возвращать. |
Сообщ.
#115
,
|
|
|
Мне тоже интересно. Вот Исмаил Прокопенко доказал себе, что ООП - это плохо. Дальше то что?
|
Сообщ.
#116
,
|
|
|
программирование - зло, что же ещё
|
Сообщ.
#117
,
|
|
|
Захотелось высказаться, что даже зарегистрировался. Тема застоя в ИТ.
Исмаил Прокопенко поднял интересную тему, но как обычно толкового разговора не получилось, с некоторой страницы пошло не то. У проф. программистов несколько суженое видение ситуации, это правда. Хотя то о чем ТС говорил – plain text не лучшее и не единственное представление кода вполне обосновано. Простой пример все знают, но почему-то не приводят – построение пользовательского интерфейса. Мышкой в основном, ага. Кропотливая задача превратилась в развлечение для школьника. Ну и чем не реализация этой идеи? В матлабе есть возможность строить блок-схемы для вычислений, которые затем трансформируются в исполняемый код. Так что кое, что уже давно реализовано и даже отлично работает. Генерация кода из UML реализована давно. Вот, к примеру, задача. Есть пользовательский интерфейс описанный в xml. Задача – создать некий компилятор, который это описание трансформирует в С++ код. Qt это удалось. Текст программы структурирован? Да. Какие из этого следуют выводы? Видимо этим надо как-то воспользоваться. Как? Как то пришла идея (не мне первому и последнему) хранить код в некоей БД. С++ в реляционной, потому, что ООП имхо неплохо под нее ложится. Тогда некоторые задачи типа рефакторинг, построение разных диаграмм, IntelliSense решаются на раз-два. Парня, который высказал подобное (не помню где) конечно же обсмеяли. Хотя Qt нечто в этом роде и реализовали (использовали xml для построения GUI) и получилось весьма толково. Как сделать с любым кодом? Пока вопрос, но думаю разрешимый. Например, одна функция это одна таблица. Тело функции запихать в поле мемо (в зазипованом виде?), плюс поля – сигнатура + флаги разные. Класс – таблица с реляционными связями на функции и другие классы. В общем, вполне можно, нужно только отбросить стереотипы и подумать. Сделать специализированную IDE не проблема, готовые компоненты для создания простой IDE (типа codeblock) есть, осталось только скрутить все вместе + прилада, которая будет из БД выдергивать или записывать текст по необходимости. Изменили интерфейс класса/сигнатуру функции? IDE либо изменит все дальше сама, по цепочке (если простой случай), либо покажет куда дальше лезть исправлять. Несколько толковых людей даже не самого высокого уровня вполне смогут реализовать подобное. Максима: какой бы не был язык программирования, структурированный текст должен хранится в соответствующем удобном контейнере. Контейнер может быть даже текстовый, как html или xml, не суть. Придумали новый язык – придумайте и контейнер для него. И компилятор/интерпретатор должен его (контейнер) понимать. “Plain text” – прошлое. |
Сообщ.
#118
,
|
|
|
Gus_Tarantoga
Если отбросить в сторону рисование GUI, то из перечисленных задач остаются: моделирование систем в MATLAB, генерация кода на основе UML-диаграмм, формирование запросов к БД. И даже при этом большую часть сгенерированного кода (кроме разве MATLAB-а) приходится вводить вручную, либо непосредственно, либо в виде параметров. При этом как-то забывается, что и блок-схема в MATLAB, и UML-диаграмма, и описание формы GUI физически на диске представлены пусть и размеченным, но тем-же самым Plain Text. Было время (во времена FORTRAN-66), когда при сдаче программы требовалось обязательно предоставить её блок-схему. Но с появлением структурных языков типа Algol, Pascal, C внезапно обнаружилось, что разбираться с работой программы по этой блок-схеме труднее, чем непосредственно по грамотно оформленному тексту. Предлагаешь вернуться в те времена? Добавлено Кстати, написать класс генерации диалога на том же wxWidget вручную не намного сложнее, чем набросать его в визуальном редакторе. Мешает в основном плохое знание библиотеки - при пользовании визуальным редактором подробно знать библиотеку нет нужды. Однако многие возможности библиотеки в редакторе остаются недоступны. Хотя бы потому, что редактор может работать только со статическими формами, а библиотека создаёт их динамически. |
Сообщ.
#119
,
|
|
|
amk, к слову, UML-диаграммы на работе я пишу, а не рисую. Их так элементарно проще версионировать.
|
Сообщ.
#120
,
|
|
|
Цитата Gus_Tarantoga @ Парня, который высказал подобное (не помню где) конечно же обсмеяли. Не удивительно. Как говаривал, ЕМНИП, старина Нильс Бор (нобелевский лауреат): "Все новые революционные научные идеи проходят 3 этапа отношения к ним людей: 1. Да это же полная чушь ("да это же курам насмех") 2. А ведь в этом что-то есть 3. А разве можно иначе? " Добавлено Цитата Gus_Tarantoga @ “Plain text” – прошлое. А современные системы контроля версий? Это же каменный век. Настоящие системы контроля версий должны показывать не разницу в тексте, а разницу в СЕМАНТИКЕ Добавлено Вот переименовал я идентификатор в 157-ми местах. Обычная CVS покажет 157 изменений. А семантический диф вифер покажэт "отличий нет" Добавлено Цитата Flex Ferrum @ Их так элементарно проще версионировать. А почему. А потому что CVS застряли в каменном веке |
Сообщ.
#121
,
|
|
|
Цитата Flex Ferrum @ Это говорит о том, что описание диаграммы хранится в текстовом файле. Если визуальный редактор не пересортировывает блоки диаграммы, то и его выход тоже должен неплохо версионироваться. Хуже, если он сортирует их в каком-нибудь порядке отображения на экране. Тогда простое перемещение блока вызывает не просто изменение его координат в тексте, а перетасовывает половину текста.к слову, UML-диаграммы на работе я пишу, а не рисую. Их так элементарно проще версионировать. Цитата Исмаил Прокопенко @ Настоящие системы контроля версий должны показывать не разницу в тексте, а разницу в СЕМАНТИКЕ Цитата Исмаил Прокопенко @ Как это нет? А переименованный идентификатор? Хотя бы одно это изменение всё равно должно отображаться.Обычная CVS покажет 157 изменений. А семантический диф вифер покажэт "отличий нет" Зато существующие CVS-системы хорошо работают с файлами с неизвестной им семантикой. |
Сообщ.
#122
,
|
|
|
Цитата amk @ Зато существующие CVS-системы хорошо работают с файлами с неизвестной им семантикой. А толку? |
Сообщ.
#123
,
|
|
|
Цитата Исмаил Прокопенко @ За их изменениями тоже приходится следить. А чтобы семантику отследить, надо инструмент сравнимый по сложности с компилятором делать. Фактически это и есть полный компилятор, только без генерации кода. А толку? |
Сообщ.
#124
,
|
|
|
Цитата amk @ А чтобы семантику отследить, надо инструмент сравнимый по сложности с компилятором А никто не говорил, что будет легко. Но мы же не в 19-в веке живём, а почти что в 22-м. "Будущее наступило"© Повсюду внедряются системы искусственного разума. ... Значит CVS должна подерживать язык описания семантики языков и прикладной области |
Сообщ.
#125
,
|
|
|
Да я не против. Главное, чтобы она с простым и текстами продолжала работать. Иначе она нафиг никому не нужна.
Так же как визуальные среды разработки. Они хороши, пока остаётся возможность напрямую работать с текстом. Только вот где ты увидел системы искусственного разума? Тем более "повсюду". И вообще надо было написать "почти в 30-м". Круче выглядело бы. |
Сообщ.
#126
,
|
|
|
Цитата amk @ Да я не против. Не понял. Что значит ты не против. Ты что? Ждёшь когда её кто-то спроектирует за тебя? А ты тогда зачем нужен? Какой-же ты тогда программист? Вобщем давай, "вперёд и с песней"© Чтобы через месяц семантическая система контроля версий тобой была сделана. |
Сообщ.
#127
,
|
|
|
Суровый уже тут ваял свою ОС. Результаты плачевны, сколько я помню...
|
Сообщ.
#128
,
|
|
|
Славян А ВЫ что ваяете?
Семантическую систему контроля версий сможете запилить за месяц? Программист Вы или где? |
Сообщ.
#129
,
|
|
|
Не программист, к счастью.
|
Сообщ.
#130
,
|
|
|
Цитата Исмаил Прокопенко @ У меня версионируется слишком много неструктурированных данных. В этом случае выигрыш от "умной" системы будет исчезающе мал. так стоит ли тратить силы?Ждёшь когда её кто-то спроектирует за тебя? К тому же, даже в программах у меня редко встречается переименование переменных. И никогда такая переменная не встречалась аж в 50 местах. Судя по такой встречаемости, это глобальная переменная, используемая для связи процедур, а я глобальными переменными стараюсь для этой цели не пользоваться. |
Сообщ.
#131
,
|
|
|
amk Да я просто первый пришедший в голову простейший пример привел.
Можно придумать и другие. Когда например над кодом делают ревью, рефакторинг и т.п. Короче причесывают и приводят в Божеский Вид. Семантика при этом мало меняется. А вот внешний вид может поменяться радикально |
Сообщ.
#132
,
|
|
|
Цитата Исмаил Прокопенко @ А вот это для существующих систем действительно проблема. Сколько раз приходилось переформатировать чужой код, чтобы его элементарно можно было читать. Сем антика при этом правда совсем не меняется, но CVS при этом мне показывает, что я вообще весь файл переписал. Хотя я только некоторые строки на несколько разбил, и пробелы в начало строк вставлял, и кое-где внутри.Когда например над кодом делают ревью, рефакторинг и т.п. Короче причесывают и приводят в Божеский Вид. Семантика при этом мало меняется. А вот внешний вид может поменяться радикально С другой стороны, текст я всё-таки изменил, и мне нужно видеть эти изменения. Даже если я только пробелы в конце строк убрал. |
Сообщ.
#133
,
|
|
|
Цитата amk @ Сколько раз приходилось переформатировать чужой код, чтобы его элементарно можно было читать. Сем антика при этом правда совсем не меняется, но CVS при этом мне показывает, что я вообще весь файл переписал. О том и речь. Если у тебя в репозитории ЧУЖОГО код только основные версии, и от версии в версии программисты увлекались рефакторингом, то встроенным (или внешним - без разницы) диф. вьювером определить "чем же версии отличаются?" практически невозможно. Т.е. понять "что изменилось в семантике, идеологии, логике приложения?" как правило невозможно. Потому что это займет столько времени, что проще переписать весь код с нуля |
Сообщ.
#134
,
|
|
|
Цитата Исмаил Прокопенко @ Ждёшь когда её кто-то спроектирует за тебя? А ты тогда зачем нужен? Какой-же ты тогда программист? Программисты же тупые. Как можно ожидать от них решение этой задачи? Такое под силу только инженерам с зарплатой не более 25 тысяч |
Сообщ.
#135
,
|
|
|
Тут я сделал пару намёков "куда дальше двигаться".
Умному и по фантику от конфеты разгадает устройство вселенной, а дураку сколько не объясняй.... Вообщем смотрите ссылку. Кому надо - тот поймет. А кто не поймёт о чем я - значит тому и не надо Добавлено Цитата OpenGL @ Такое под силу только инженерам с зарплатой не более 25 тысяч Медсестра в Йошкар-Оле получает 5 тысяч, выполняет свою работу на "5+" и не жужит. Добавлено Цитата OpenGL @ Программисты же тупые. Как можно ожидать от них решение этой задачи? Вот и докажите, что это не так. Что Вы не зря едите свой хлеб и называете себя гордо "ПРОГРАММИСТ". Разработайте семантик вьювер и диф. вифер |
Сообщ.
#136
,
|
|
|
Нучо там?
Какие идеи? |
Сообщ.
#137
,
|
|
|
Цитата Исмаил Прокопенко @ > Обсудим идеи как можно радикально облегчить и упростить программирование? В случае с вэбом, неплохой вариант начинать с создания толкового языка гипертекстовой разметки (соответственно и браузера, понимающего как html-css-js, так и более толковый формат). В данный момент html(в широком смысле слова) - огромная жопа, с довольно таки вольно интерпретируемыми правилами. Впрочем, это вроде как обо всём и ни о чём. |
Сообщ.
#138
,
Сообщение отклонено: Flex Ferrum -
|
Сообщ.
#139
,
Сообщение отклонено: Flex Ferrum -
|
Сообщ.
#140
,
Сообщение отклонено: B.V. -
|