Обсудим идеи как можно радикально облегчить и упростить программирование?

[Pavia]

Исмаил Прокопенко
Я рад что до вас наконец-то дошла моя мысль, которую я вам говорил полгода-год назад: ООП не уменьшает числа связей!
Но всё-же мощь ООП в другом. Первым языком ООП был Smalltalk и в отличии от других языков он был дикларативным, а не императивным.
ООП позволяет человеку пользоваться домыслами. Правильно подобранные название позволяют не вникать в суть не изучать внутренности, а догадываться и домысливать как оно там устроенно. Т.е. отсечение связи делает человек в меру своих знаний о окружающем мире.

Цитата Исмаил Прокопенко @ 06.11.16, 18:58

Надеюсь Вы не будете отрицать, что сейчас студент троечник 2-го курса, который учится на программиста ЗАПРОСТО напишет программу над которой 40 лет назад бились огромные коллективы лучших программистов?

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

Цитата

Почему бред?

Число веток в программе не уменьшается. Как и 40 лет назад их все надо продумать, закодить, проверить.
Больше 1 МБ в год 1 кодер не напишет - физически. И время необходимое для обучения человека тоже не изменилось.

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

Сообщение отредактировано: Pavia - 06.11.16, 21:24

[applegame]

Цитата Исмаил Прокопенко @ 06.11.16, 17:53

Я говорил про то, что НЕВОЗМОЖНО менять КАК УГОДНО (хошь интерфейс, хошь реализацию) класс-параметр и класс-поле "без оглядки" на класс, в котором находятся эти параметры и поля. Т.е. налицо ЗАВИСИМОСТЬ.
А то, что я НЕ говорил - не надо мне приписывать или ДОДУМЫВАТЬ.

Хорошо, вы считаете это проблемой и считаете, что она свойственна именно ООП. Вопрос: какая парадигма, по вашему, лишена этого "недостатка"?

[wind]

в смехогрехе санитарный день?

[Исмаил Прокопенко]

Цитата AVA12 @ 06.11.16, 20:33

Голые декларации в духе "все пропало, куда катится мир!",

Вы троллите?
Я же написал:

Цитата Исмаил Прокопенко @ 06.11.16, 09:50

А что такое «интерфейс» класса?
А это ни что иное как список заголовков PUBLIC методов.
А что такое «заголовок метода»?
Это имя метода плюс список ТИПОВ его параметров.
И вот мы подходим к ключевому моменту: А что такое «типы параметров»?
А это не что иное как КЛАССЫ, которые описаны вне данного класса, и которые также имеет интерфейс.

Бинго!
Получается, что раскрутив всю логическую цепочку, мы видим, что фактически интерфейсом класса является СПИСОК ОПИСАННЫХ ВОВНЕ ДРУГИХ КЛАССОВ. А у тех классов интерфейс – это тоже список описанных вне их классов. И т.д.

Куда уж конкретней?
Что в этом тексте у Вас вызывает непонимание?

Добавлено 06.11.16, 22:47

Цитата Pavia @ 06.11.16, 21:22

ООП не уменьшает числа связей!

Вот именно.

Добавлено 06.11.16, 22:57

Цитата Pavia @ 06.11.16, 21:22

Число веток в программе не уменьшается. Как и 40 лет назад их все надо продумать, закодить, проверить.

Тут Вы не совсем правы.
Число IF-ов, которые программист должен ВРУЧНУЮ "разрулить" при переходе от языков низкого уровня к языкам высокого уровня сокращается.
Чтобы понять это достаточно заглянуть в исходник на С++ и посмотреть сколько в нем IF-ов. А потом заглянуть в машинный код, который получается после компиляции исходника на С++, и посмотреть сколько там инструкций условных переходов. Их там на порядок больше.
Просто они в исходнике оказываются "ниже уровня абстракции" и генерятся автоматически компилятором без участия программиста.

Полагаю, что при переходе от языков высокого уровня (типа С++) к языкам СВЕРХвысокого уровня число IF-ов, которые вручную должен "разрулить" программист будет еще меньше.

ПРОГРАММИРОВАНИЕ БЕЗ IF-ов

Добавлено 06.11.16, 23:00

Цитата Pavia @ 06.11.16, 21:22

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

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

Добавлено 06.11.16, 23:02

Цитата Pavia @ 06.11.16, 21:22

Больше 1 МБ в год 1 кодер не напишет - физически.

Смотря как считать эти мегабайты.
А то если считать суммарный объем DLL и EXE-шников (а ведь это является конечным продуктом труда кодера), то кодер и ГИГАБАЙТЫ за год может наваять

Добавлено 06.11.16, 23:06

Цитата Pavia @ 06.11.16, 21:22

За всё время развития информатики и программирования, только структуры+алгоритмы имеют чёткое обоснование

Только вот форма представления "структур+алгоритмов" может быть разной.
А ведь она НАПРЯМУЮ влияет на скорость решения задачи.

К примеру преставление задачи в виде исходника на С++ 10, занимающее всего 10 строчек кода, на ассемблере выльется в 100 и более строк

Добавлено 06.11.16, 23:08

Цитата applegame @ 06.11.16, 21:23

Хорошо, вы считаете это проблемой и считаете, что она свойственна именно ООП. Вопрос: какая парадигма, по вашему, лишена этого "недостатка"?

Я не говорил "именно" или "только" ООП.
Я просто сказал что такая проблема в ООП существует.
И все.
По остальным Вашим вопросам ничего сказать не могу, поскольку пока не размышлял над ними

Сообщение отредактировано: Исмаил Прокопенко - 06.11.16, 23:19

[AVA12]

Pavia:

Цитата

Первым языком ООП был Smalltalk и в отличии от других языков он был дикларативным, а не императивным.

Это действительно так? Я со смолтоком не имел дела, но из его описания и примеров кода можно сделать вывод, что это императивный язык: есть глобальное состояние (объекты), есть типичный цикл из повторяющегося чтения/обработки/записи состояния.

Исмаил Прокопенко:
Насчет орграфа зависимостей я знаю, мне непонятно только, ПОЧЕМУ непременно должны получаться хрупкие монстры, малейшие изменения в которых рушат весь код?!

Цитата

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

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

[Flex Ferrum]

Ух, как нажористо то... Идея придумывать (и описывать) интерфейсы, по которым компоненты системы взаимодействуют между собой, кажется Исмаилу контрпродуктивной. Ну-ну. Тут можно было бы рассказать про техники уменьшения связности, проектирование на уровне абстрактных интерфейсов и проч., но не буду. Зачем осквернять такой бурный фонтан откровений толикой здравого смысла?

Добавлено 07.11.16, 06:53
Но ладно. Представим себе такую ситуевину - серебряную пулю изобрели и интерфейсы (и контракты) стало можно менять незаметно для пользователей. И вот однажды приходит Исмаил к себе домой, а там вся техника - сгоревшая. Это просто электрики (никого не предупредив) изменили контракт интерфейса - вместо 220 начали подавать 380. Не, нуачо? Можно ведь... Или вот яблочники - нет, чтобы пользоваться стандартным Micro-USB, изобретают вот новые яблоки. Был разъём для ушей - и нету теперь. Нужно специальные адаптеры покупать. Не, нуачо? Явочным образом менять контракты и интерфейсы - это ведь так здорово!

[Исмаил Прокопенко]

Цитата AVA12 @ 06.11.16, 23:21

Насчет орграфа зависимостей я знаю, мне непонятно только, ПОЧЕМУ непременно должны получаться хрупкие монстры, малейшие изменения в которых рушат весь код?!

Естественно не ЛЮБЫЕ изменения "рушат код".
Но ситуация выглядит так: программист, в худшем случае, должен БЕЗОШИБОЧНО написать СРАЗУ ВСЕ кортежи сразу ВСЕХ зависимых классов {кортеж - в смысле список вида: имя_метода(параметр1, параметр2, ..., параметрN}, а потом не может их менять. Так как эти кортежи уже много где используются. При желании, конечно можно и мпх сломать изменить состав методов, их имена и сигнатуры. Формально этого никто не запрещает.
Но в сложных случаях это так гиморно, что по затратам сравнимо с проектированием системы классов с нуля.

Добавлено 07.11.16, 07:29

Цитата AVA12 @ 06.11.16, 23:21

Короче, есть много способов кардинально изменить интерфейс, при этом не порушив уже использующий его код.

Примеры в студию.

Как можно изменить имя метода класса X, чтобы использующие его другие классы "не заметили" этого?

Как можно изменить типа параметра в классе X или вообще его убрать, чтобы использующие его другие классы "не заметили" этого?

Как можно вообще удалить из интерфейса некоторый метод в классе X, чтобы использующие его другие классы "не заметили" этого?

Цитата AVA12 @ 06.11.16, 23:21

Короче, есть много способов кардинально изменить интерфейс, при этом не порушив уже использующий его код.

Только все эти способы основаны на том, что программист ЗАРАНЕЕ должен знать, что будет, возможно, изменяться. ЗАРАНЕЕ, Карл.

Т.е. мало того, что программист должен ПРОДУМАТЬ интерфейсы СРАЗУ ВСЕХ зависимых (в т.ч. косвенно) классов, так он при проектировании должен ЗАРАНЕЕ предусмотреть какие изменения возможны в системе интерфейсов.
Т.е. задача еще больше усложняется.

Добавлено 07.11.16, 07:35

Цитата Flex Ferrum @ 07.11.16, 06:41

Идея придумывать (и описывать) интерфейсы, по которым компоненты системы взаимодействуют между собой, кажется Исмаилу контрпродуктивной. Ну-ну.

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

[Flex Ferrum]

Цитата Исмаил Прокопенко @ 07.11.16, 07:21

Т.е. мало того, что программист должен ПРОДУМАТЬ интерфейсы СРАЗУ ВСЕХ зависимых (в т.ч. косвенно) классов, так он при проектировании должен ЗАРАНЕЕ предусмотреть какие изменения возможны в системе интерфейсов.
Т.е. задача еще больше усложняется.

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

Добавлено 07.11.16, 07:39

Цитата Исмаил Прокопенко @ 07.11.16, 07:21

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

Исмаил, вы плохо понимаете, о чём говорите. Я бы вам порекомендовал начать с букварей, в которых "детям пудрят мозги", а конкретно - с тех их разделов, где пудрят мозги на предмет forward declaration, abstract classes и (pure) virtual functions. Есть масса техник уменьшения связности кода в C++. Эти техники просто надо уметь использовать. И к ООП всё это имеет довольно слабое отношение.

[Исмаил Прокопенко]

Цитата Flex Ferrum @ 07.11.16, 06:41

Тут можно было бы рассказать про техники уменьшения связности

Что за техники такие?

Цитата Flex Ferrum @ 07.11.16, 06:41

но не буду

Понятно. Они должны остаться известными только членам секты свидетелей Йоговы.
Но подозреваю тут другое. Вы просто боитесь, что я разобью все Ваши контраргументы в пух и прах, когда Вы от общих "умных слов" перейдете к конкретике.

Цитата Flex Ferrum @ 07.11.16, 06:41

проектирование на уровне абстрактных интерфейсов

Ну да. Куда нам. Конечно же я не в курсе про абстрактные классы и чисто виртуальные методы. Спасибо что открыли Америку.

[Flex Ferrum]

Исмаил, вы очень толсто троллите.

[Исмаил Прокопенко]

Цитата Flex Ferrum @ 07.11.16, 06:41

Но ладно. Представим себе такую ситуевину - серебряную пулю изобрели и интерфейсы (и контракты) стало можно менять незаметно для пользователей. И вот однажды приходит Исмаил к себе домой, а там вся техника - сгоревшая. Это просто электрики (никого не предупредив) изменили контракт интерфейса - вместо 220 начали подавать 380. Не, нуачо? Можно ведь... Или вот яблочники - нет, чтобы пользоваться стандартным Micro-USB, изобретают вот новые яблоки. Был разъём для ушей - и нету теперь. Нужно специальные адаптеры покупать. Не, нуачо? Явочным образом менять контракты и интерфейсы - это ведь так здорово!

Вы передергиваете.
Программирование это все же не электрика.
Поэтому и назвали software в противоположность hardware.
И проблемы, существующие в hardware, сглажены или вообще отсутствуют в software. И в software допустимы такие трюки, которые в hardware привели бы к катастрофе или огромным затратам.

[Flex Ferrum]

Цитата Исмаил Прокопенко @ 07.11.16, 07:40

Ну да. Куда нам. Конечно же я не в курсе про абстрактные классы и чисто виртуальные методы. Спасибо что открыли Америку.

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

[Исмаил Прокопенко]

Цитата Flex Ferrum @ 07.11.16, 07:41

Исмаил, вы очень толсто троллите.

Когда у человека нет доводов в споре, он скатывается на хамство и оскорбления. Например, начинает обвинять оппонента в троллинге.
Т.е. у Вас реально аргументов нет получается?

Добавлено 07.11.16, 07:46

Цитата Flex Ferrum @ 07.11.16, 07:43

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

Вы кроме всего прочего еще и телепат?

[Flex Ferrum]

Цитата Исмаил Прокопенко @ 07.11.16, 07:43

Вы передергиваете.
Программирование это все же не электрика.
Поэтому и назвали software в противоположность hardware.
И проблемы, существующие в hardware, сглажены или вообще отсутствуют в software. И в software допустимы такие трюки, которые в hardware привели бы к катастрофе или огромным затратам.

Я не передёргиваю. Проблема одностороннего нарушения контракта - она существует как в software, так и в hardware. Да и вообще, она существует. Чаще всего в software (в силу того, что подавляющее число программ ничего критически-важного не делают) эта проблема не так серьёзна, как в hardware. Но для софта, применяемого в областях, где от работоспособности программы зависят жизни людей или функционирование вполне себе реальных объектов, contract violation так же серьёзен, как и в области hardware.

Добавлено 07.11.16, 07:47

Цитата Исмаил Прокопенко @ 07.11.16, 07:45

Вы кроме всего прочего еще и телепат?

Ага. Есть у меня такой скилл.

Сообщение отредактировано: Flex Ferrum - 07.11.16, 07:47

[Исмаил Прокопенко]

Цитата Flex Ferrum @ 07.11.16, 07:36

Вообще то именно для этого и существует этап проектирования

Вы так говорите, как будто рады этому.
Ну правильно. Я писал об этом.

Цитата Исмаил Прокопенко @ 06.11.16, 17:53

Годами и ДЕСЯТИЛЕТИЯМИ создается то, что можно было создавать за пару недель.
Зато все счастливы и программисты чувствуют себя важными людьми, надувают щёки и получают хорошие зарплаты.

Хотя можно было из 10 тыс. программистов оставить одного который бы делал даже больше.

Т.е. программисты САМИ НЕ ЗАИНТЕРЕСОВАНЫ, чтобы программирование упростилось, чтобы программировать мог любой и чтобы один программист мог заменить 1000. Ведь тогда они уже не смогут быть незаменимыми, "надувать щеки" от важности и получать хорошие зарплаты

Добавлено 07.11.16, 07:54

Цитата Flex Ferrum @ 07.11.16, 07:47

Я не передёргиваю. Проблема одностороннего нарушения контракта - она существует как в software, так и в hardware. Да и вообще, она существует. Чаще всего в software (в силу того, что подавляющее число программ ничего критически-важного не делают) эта проблема не так серьёзна, как в hardware. Но для софта, применяемого в областях, где от работоспособности программы зависят жизни людей или функционирование вполне себе реальных объектов, contract violation так же серьёзен, как и в области hardware.

А Вам не приходило в голову, что в software можно изменить само понятия "контракта"?
И уйти от представления интерфейса в виде списка кортежей