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

[Flex Ferrum]

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

Т.е. я и про полиморфизм не в курсе?

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

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

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

Что такое ООП на самом деле, как правильно декомпозировать проектируемую систему/предметную область на объекты/подсистемы, как выстраивать между ними взаимосвязи, как проектировать фасады подсистем, как вообще проектировать интерфейсы. Как-то так.

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

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

Цитата Flex Ferrum @ 07.11.16, 17:20

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

Т.е. я и про полиморфизм не в курсе?

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

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

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

Цитата Flex Ferrum @ 07.11.16, 17:20

как вообще проектировать интерфейсы.

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

Конкретно в коде как он выглядит и что из себя представляет

Сообщение отредактировано: Исмаил Прокопенко - 07.11.16, 17:29

[Flex Ferrum]

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

Я точно с программистом разговариваю?

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

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

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

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

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

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

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

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

Цитата Flex Ferrum @ 07.11.16, 17:42

В общем случае - это набор методов, для каждого из которого сформулирован чёткий контракт

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

И кстати, Вы правильно сказали:

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

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

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

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

[amk]

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

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

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

[Flex Ferrum]

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

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

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

Добавлено 08.11.16, 07:28

Цитата amk @ 07.11.16, 21:36

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

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

[OpenGL]

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

Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры.

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

[Flex Ferrum]

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

Это понятно. Но при этом в программирование вносится достаточно сложный и трудоемкий процесс проектирования архитекуры.

Как-то я это пропустил.
Ну да, вносится. Вы можете, не обладая архитектурными навыками, построить халупу у себя на даче. И она даже не развалится (наверное). Но чтобы построить что-то серьёзное - надо таки знать, как строить.

[applegame]

Отстаньте от Исмаила Прокопенко. Я хочу приобщиться к новому!
Исмаил, вы говорите ООП - это плохо. Допустим вы правы и ООП - действительно плохо.

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

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

Я прочитал этот текст и бросил ООП, и теперь внимательно слушаю, как можно написать за пару недель, то что Flex Ferrum пишет десятилетиями. Я верю, что вы не пустословите и такое действительно возможно, осталось самая мелочь: ответить в общих чертах на вопрос КАК?
А то я уже получил деньги на разработку двух новых операционных систем в течение месяца (по две недели на каждую ОС), не хотелось бы их возвращать.

[prografix]

Мне тоже интересно. Вот Исмаил Прокопенко доказал себе, что ООП - это плохо. Дальше то что?

[wind]

программирование - зло, что же ещё

[Gus_Tarantoga]

Захотелось высказаться, что даже зарегистрировался. Тема застоя в ИТ.
Исмаил Прокопенко поднял интересную тему, но как обычно толкового разговора не получилось, с некоторой страницы пошло не то. У проф. программистов несколько суженое видение ситуации, это правда.
Хотя то о чем ТС говорил – plain text не лучшее и не единственное представление кода вполне обосновано.
Простой пример все знают, но почему-то не приводят – построение пользовательского интерфейса. Мышкой в основном, ага. Кропотливая задача превратилась в развлечение для школьника. Ну и чем не реализация этой идеи? В матлабе есть возможность строить блок-схемы для вычислений, которые затем трансформируются в исполняемый код. Так что кое, что уже давно реализовано и даже отлично работает. Генерация кода из UML реализована давно.
Вот, к примеру, задача. Есть пользовательский интерфейс описанный в xml. Задача – создать некий компилятор, который это описание трансформирует в С++ код. Qt это удалось.
Текст программы структурирован? Да. Какие из этого следуют выводы? Видимо этим надо как-то воспользоваться. Как?
Как то пришла идея (не мне первому и последнему) хранить код в некоей БД. С++ в реляционной, потому, что ООП имхо неплохо под нее ложится. Тогда некоторые задачи типа рефакторинг, построение разных диаграмм, IntelliSense решаются на раз-два. Парня, который высказал подобное (не помню где) конечно же обсмеяли. Хотя Qt нечто в этом роде и реализовали (использовали xml для построения GUI) и получилось весьма толково.
Как сделать с любым кодом? Пока вопрос, но думаю разрешимый. Например, одна функция это одна таблица. Тело функции запихать в поле мемо (в зазипованом виде?), плюс поля – сигнатура + флаги разные. Класс – таблица с реляционными связями на функции и другие классы. В общем, вполне можно, нужно только отбросить стереотипы и подумать. Сделать специализированную IDE не проблема, готовые компоненты для создания простой IDE (типа codeblock) есть, осталось только скрутить все вместе + прилада, которая будет из БД выдергивать или записывать текст по необходимости. Изменили интерфейс класса/сигнатуру функции? IDE либо изменит все дальше сама, по цепочке (если простой случай), либо покажет куда дальше лезть исправлять. Несколько толковых людей даже не самого высокого уровня вполне смогут реализовать подобное.
Максима: какой бы не был язык программирования, структурированный текст должен хранится в соответствующем удобном контейнере. Контейнер может быть даже текстовый, как html или xml, не суть. Придумали новый язык – придумайте и контейнер для него. И компилятор/интерпретатор должен его (контейнер) понимать. “Plain text” – прошлое.

[amk]

Gus_Tarantoga
Если отбросить в сторону рисование GUI, то из перечисленных задач остаются: моделирование систем в MATLAB, генерация кода на основе UML-диаграмм, формирование запросов к БД.
И даже при этом большую часть сгенерированного кода (кроме разве MATLAB-а) приходится вводить вручную, либо непосредственно, либо в виде параметров.
При этом как-то забывается, что и блок-схема в MATLAB, и UML-диаграмма, и описание формы GUI физически на диске представлены пусть и размеченным, но тем-же самым Plain Text.

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

Добавлено 30.04.17, 15:58
Кстати, написать класс генерации диалога на том же wxWidget вручную не намного сложнее, чем набросать его в визуальном редакторе. Мешает в основном плохое знание библиотеки - при пользовании визуальным редактором подробно знать библиотеку нет нужды. Однако многие возможности библиотеки в редакторе остаются недоступны. Хотя бы потому, что редактор может работать только со статическими формами, а библиотека создаёт их динамически.

[Flex Ferrum]

amk, к слову, UML-диаграммы на работе я пишу, а не рисую. Их так элементарно проще версионировать.

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

Цитата Gus_Tarantoga @ 30.04.17, 14:04

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

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

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



"

Добавлено 30.04.17, 17:50

Цитата Gus_Tarantoga @ 30.04.17, 14:04

“Plain text” – прошлое.

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

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

Добавлено 30.04.17, 17:53

Цитата Flex Ferrum @ 30.04.17, 17:24

Их так элементарно проще версионировать.

А почему. А потому что CVS застряли в каменном веке