О более новых парадигмах программирования, чем ООП

К сожалению не нашел другого более подходящего раздела для этой новой темы.

Немного о себе: я не считаю себя программистом, так как я не создавал программы с более сложными объектами, чем стандартные визуальные (кнопки, лэйблы, окна и т.д.). Если уделить программированию годы, то наверняка я освою любую методологию программирования. Ведь у меня за плечами: Spectrum48k (Basic, Assembler), немного Delphi7 (Pascal), программирование в промышленных логических языках LD, FBD, SFC. Сейчас пытаюсь освоить С++ (готовность уже на 70%) и среду Qt. Именно в таком порядке я осваивал методологии/технологии программирования.
Из всего ряда особенным образом выделяются языки LD, FBD, SFC. Эти языки привносят в программирование нечто новое, что я постоянно пытаюсь осмыслить. FBD - близок к модели взаимодействия UML. SFC - это аналог модели состояний UML. Помимо этих особенных языков программирования в сфере промышленности используется кибернетическое мышление, системный подход - это тоже отразилось существенно на моем мировоззрении.

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

Что я хочу получить от общения в этой теме?
1) Я хочу узнать о более новых парадигмах, нежели стандартный ООП. Мне нужны ссылки. Когда-то давно меня обрадовали некоторой парадигмой под названием "Аспектно-ориентированное программирование". Интересная штучка! Она некоторым образом соотносится с моим ходом мысли, но к сожалению нет хорошей литературы, которая бы раскрывала, что собственно дает среда разработки с АОП.
2) Я хочу узнать о более развитых средах разработки нежели QtDesigner и IDE Delphi7. Какая среда в настоящий момент позволяет более эффективно работать с объектами, библиотеками объектов? Где можно более удобно структурировать и переструктурировать приложение?
3) Я хочу рассказать о своих простых и непростых идеях, которые можно было бы применить для повышения эффективности программирования. Но это чуть позже, т.к. может быть я чего-то не знаю.

0

Сообщение от Mikhaylo Позвольте поставить задачу более широко - разработать более удобный интерфейс, а не разработать новую парадигму.

1. Интерфейс вообще не относится к парадигме и парадигма к интерфейсу.
2. Шире как раз парадигма.

Добавлено через 7 минут

Сообщение от Mikhaylo Вполне возможно, что в целом такая постановка задачи может дать новую парадигму?

Нет. Вот смотри: раскрасил ты инструменты, подобрал эргономичную форму ручек - это всего лишь интерфейс. А сосед выбросил молотки, рубанки и поставил 3D-принтер - это уже другая парадигма, потому что твои столяры по прежнему перед изготовлением каждой детали думают, что делать, просто инструменты им держать удобнее, чем раньше (а может и наоборот, если эргономичность новых ручек кажущаяся), а сотрудники соседа думают, что хотят сделать. Как и что - это разные парадигмы, а чем - это всего лишь интерфейс.

Добавлено через 2 минуты

Сообщение от Mikhaylo Очень вероятно, но я бы попробовал в действии.

А чего пробовать? Просто засеки, сколько времени толковые программисты тратят на то, чтоб возвращаться к декларациям переменных и читать тип. Не опытные, а именно толковые. В том числе, перспективные новички.

0

Сообщение от taras atavin Нет. Вот смотри: раскрасил ты инструменты, подобрал эргономичную форму ручек - это всего лишь интерфейс. А сосед выбросил молотки, рубанки и поставил 3D-принтер - это уже другая парадигма, потому что твои столяры по прежнему перед изготовлением каждой детали думают, что делать, просто инструменты им держать удобнее, чем раньше (а может и наоборот, если эргономичность новых ручек кажущаяся), а сотрудники соседа думают, что хотят сделать. Как и что - это разные парадигмы, а чем - это всего лишь интерфейс.

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

Сообщение от taras atavin А чего пробовать? Просто засеки, сколько времени толковые программисты тратят на то, чтоб возвращаться к декларациям переменных и читать тип. Не опытные, а именно толковые. В том числе, перспективные новички.

Если несколько перестроить изображение - тип данных помещать слева или справа, то можно уменьшить размер кода по горизонтали. В этом случае можно пробовать фиксировать положительный или почти нейтральный результат нововведения. Если результат есть, то можно его рекомендовать. Но все же надо пробовать. Возможен неоднозначный результат, который зависит от специфики и размера кода.
Можно придумать несколько иное "изобретение": переменные помечать графическими префиксами, например, переменная типа bool помечается звездочкой, переменные целочисленных типов - квадратиками, переменные вещественных типов - кружочками, строка - линией, массивы - группой точек 5х5, объекты - облаками и т.п. Оценка эффекта от внедрения только через эксперимент. Конечно, подобные идеи наверняка встретят гул, освистывание и улюлюкание со стороны профессионалов.... )))

0

Сообщение от Mikhaylo В реальности никакого 3D-принтера у соседа может не оказаться, т.к. этот принтер еще надо изобрести.

Уже изобретён и даже не один.

0

А изобретена ли Парадигма, которая лучше цветных инструментов?

0

Сообщение от Mikhaylo Можно придумать несколько иное "изобретение": переменные помечать графическими префиксами, например, переменная типа bool помечается звездочкой, переменные целочисленных типов - квадратиками, переменные вещественных типов - кружочками, строка - линией, массивы - группой точек 5х5, объекты - облаками и т.п.

когдато, когда динозавры еще жили, жила была венгерская нотация, в разы нагляднее предложеного способа....

Оценка эффекта от внедрения только через эксперимент.

... ее внедрили, попиарили, оценили и выкинули хлам на свалку истории.

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

Добавлено через 1 минуту

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

не встретят . это давно история. никому не интересно уже...

0

pycture, пиктограммы вместо строк должны наоборот меньше места забирать. Хотя это касается толко базовых. Mikhaylo, такая проблема, потом придумывать для каждого нового типа свой значок? Если собирать из простых в соответствии со структурой, то такие монстры вполне будут четой стенам текста.

0

Здесь другая проблема: информативность. Текст позволяет выразить всё, что угодно и не требует для этого заучивания миллионов значков, достаточно некоторым образом их комбинировать в слова, пиктограмма же - символ с самостоятельной семантикой, почти иероглиф, только ещё хуже. Сколько пиктограммами можно обозначить действий? Иди, открой, закрой, возьми, брось, зажги, потуши, дуй, пей, ешь, сотри, ищи, печатай, настрой, нажми. При этом ИТ-тишных открой, закрой, иди, сотри, ищи, печатай и настрой. Всего 7 штук и нет главных - вычисли и присвой. Сколько типов можно обозначить пиктограммами? Список выбора, выпадающий список, картинка, кнопка, флаг без вида, линейка прокрутки, стрелочный индикатор, поле ввода, экранный лэйбл, папка, диски трёх видов. Всё остальное вроде двух видов флагов разве что иероглифически. При этом типы появляются быстрее, чем можно рисовать новые иероглифы, не говоря о введении их в IDE. А как обозначить целое, число с плавающей точкой, строку, отдельно от ней символ, булевый тип, иттератор? Ну массив ладно, допустим, хороший иероглиф, запоминающийся.

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

0

Сообщение от pycture жила была венгерская нотация, в разы нагляднее предложеного способа

Венгерская нотация предполагает встраивание префикса в имя идентификатора. Меня вообще раздражают все эти методы классификации идентификаторов путем повсеместного внедрения программистского этикета: TImage - класс Image в объектном паскале, CImage - класс Image у Майкрософт, QImage - класс Image в Qt... GetName, SetName, IsEmpty. А тут еще венгерская нотация bIsEmpty, вообще печаль наводит. У меня задумана хитрая мысль - избавиться от символьных префиксов вообще: Name, Name, Empty. Почему это будет работать? Да потому что соблюдение программистского этикета должно стать заботой среды разработки. Если программистский этикет - это достаточно жесткие правила, то их можно зашить в жесткий алгоритм. Я хочу уничтожить все книги и статьи по программистскому этикету, они должны стать частью истории.

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

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

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

Ну мы имеем уже то, что Вы описываете. Правильно?
Я уверен на 100% на данный момент лишь в следующем: имена идентификаторов должны остаться текстовыми. Это имена переменных, объектов, классов, функций. Символьные префиксы в топку, заменить какими-нибудь иероглифами. А все остальное текстовое в языках подлежит пересмотру.
Вот такая вот "революция".

0

Сообщение от pycture жила была венгерская нотация,

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

Добавлено через 1 минуту

Сообщение от Mikhaylo Я уверен на 100% на данный момент лишь в следующем: имена идентификаторов должны остаться текстовыми.

Так типы то тоже обозначены идентификаторами.

0

Сообщение от taras atavin Так типы то тоже обозначены идентификаторами.

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

0

Целые знаковые:
1. smal.
2. short.
3. long.
4. long long.
Целые знаковые:
5. unsigned smal.
6. unsigned short.
7. unsigned long.
8. unsigned long long.
Действительные:
9. Простой.
10. Двойной.
11. Длинный.
Лоческий:
12. boolean.
Символьные:
13. char.
14. WideChar.
Строковые:
15. Нультеримнальная на char.
16. Нультеримнальная на WideChar.
17. Паскалевая короткая на char.
18. Паскалевая короткая на WideChar.
19. Паскалевая длинная на char.
20. Паскалевая длинная на WideChar.
Потоковые:
21. Консольного ввода.
22. Консольного вывода.
23. Файлового ввода.
24. Файлового вывода.
Это только те, которые желательно иметь в качестве встроенных. Уже больше двух десятков. А ещё множества, перечисления, списки, массивы, деревья, иттераторы, ограниченные целые, ограниченные символьные, комплексные, гиперкоплексные, классы всех мастей. Всё это тоже типы.

0

У программиста в каждом конкретном случае есть "любимые" типы, достаточно сделать список Favorite и проблема комбинаторного взрыва решена. Один раз занес в Favorite и забыл....

0

Сообщение от Mikhaylo Неправда. Программист ASM и C++ думают с разной скоростью.

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

Добавлено через 2 минуты

Сообщение от Mikhaylo А вот разноцветные инструменты - это просто и действительно удобно.

Если цвета выбраны правильно, а не по-инопланетянски.

Добавлено через 5 минут

Сообщение от Mikhaylo У программиста в каждом конкретном случае есть "любимые" типы, достаточно сделать список Favorite и проблема комбинаторного взрыва решена. Один раз занес в Favorite и забыл....

Я перечислил необходимые. А если ещё и любимые, то могут добавиться: матрица преобразования координат, кватернион, запрос к БД, таблица БД, текстовое поле БД, поле-картинка БД, трёхмерный вектор, двумерный вектор, оружие, стена, персонаж, кнопка, экранный лабел, таблица стрингов, главное меню, контекстное, два вида флагов, рисованная кнопка, выпадающий список, связный список, список выбора, поле ввода, экранный лэйбл, поле ввода пароля, полоса прокрутки, панель, картинка, два вида сокетов... И менее трёх десятков будет ровно в двух случаях: у новичка и у поделушника.

Добавлено через 4 минуты
А в команде средненького проекта их будет заведомо более ста и все должны будут понимать значки друг друга.

Добавлено через 15 минут

Сообщение от Mikhaylo Очень опасная и весьма сомнительная аналогия. (Наверное уже заметили, что я не очень люблю аналогии...)

Смысл в том, что если удобнее, или наоборот не удобнее оформлено, ила даже оформление того же качества, но другое - это интерфейс, даже не язык. А если сам принцип построения кода другой, то вот это уже парадигма. Есть программирование императивное, функциональное, декларативное и низкоуровневое. Императивное - это когда программа представляет из себя связный текст, описывающий последовательность операций. Функциональное - это когда программа описывает процесс вычисления функции в математическом понимании термина "функция". Декларативное - это когда программа описывает, что дано и что требуется получить, то есть саму задачу. Ну и низкоуровневое - это программы из ни как не связанных между собой кодов операций. А ещё есть разновидности. Например, процедурное программирование - это императивное программирование с разделением текста программы на разделы, некоторые, или все из которых представляют из себя подпрограммы, то есть программы решающие называемые подзадачами части общей задачи. ООП - это процедурное программирование с декомпозицией не только на основе составных операций, но и на основе типов данных, над которыми они выполняются. А есть ещё контекстное программирование.

0

Сообщение от Mikhaylo У меня задумана хитрая мысль - избавиться от символьных префиксов вообще: Name, Name, Empty.

еще раз. это давно уже случилось

Символьные префиксы в топку, заменить какими-нибудь иероглифами.

еще раз. префиксы даже в виде иероглефов захламляют пространство и никому не нужны.

у меня стойкое впечатление что вы боритесь с тем чего уже лет 10 как нет.

0

Сообщение от pycture у меня стойкое впечатление что вы боритесь с тем чего уже лет 10 как нет.

Нет. Он просто хочет переписать венгерский код по-японски и также по-японски воспитать коллег.

1

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

0

Сообщение от Vtulhu Все дружно читаем статью Джоэля Спольски о вонючем коде! __________________

Теперь позвольте мне предложить соглашение о кодировании, которое работает. У нас будет только одно правило: Все строки, которые приходят от пользователя, должны быть сохранены в переменных (или полях базы данных) с названием, начинающимся с приставки "us" (для Опасных (UnSafe) Строк). Все строки, которые были перекодированы для HTML или которые прибыли из заведомо-безопасного места, должны быть сохранены в переменных с названием, начинающимся с приставки "s" (для Безопасных (Safe) строк).

Вот только типы строк с их опасностью для веба ни как не связаны. Зато именование по назначению включает в себя, в том числе, и это соглашение.

Добавлено через 5 минут

Примечание переводчика (программиста): Более правильно будет автоматизировать процесс выявления подобных ошибок, либо вообще исключить возможность их появления. То есть создать типы safe_string и unsafe_string с операцией преобразования одного типа в другой. Функция Request должна возвращать тип unsafe_string, а функция Write должна получать тип safe_string. Таким образом компилятор (интерпертатор) гарантирует отсутствие ошибок использования непроверенных данных, и никакой "венгерской нотации" не понадобиться. Она нужна там, где средства языка не позволяют использовать достаточно чёткую типизацию - например, в VB, Си; в языке С++ возможно написание кода без использования венгерской нотации и без головной боли с проверкой кода вручную - проверка производится автоматически.

Нужны комментарии?

0

Сообщение от Vtulhu Все дружно читаем статью

10-ти летней давности... едиственное ценное в этой статье это примечания переводчика, который на бред автора что программер должен глазами сопоставлять типы в каждой строке, справедливо отмечает, что это задача компилятора а вовсе не человека.
и даже если абстрагироваться от примечания, то попытка навязать писанину в виде usName вместо адекватного unsafeName, отдает каменным веком. времена когда в компе было 640 кБ давно прошли, и программер не обязан угадывать что значит префикс перед именем (us... == unsigned short).
неактуально короче это давно

0

0

Но если вы видите тот же самый отрывок кода в C++, вы не можете сказать о нем ничего. Абсолютно ничего. Единственный способ узнать в C++, что же здесь действительно происходит, состоит в том, чтобы узнать, какие типы у i и j, что-то, что могло быть объявлено где-нибудь в другом месте. Это нужно потому что, в зависимости от типа j, перегруженный оператор * может сделать что-нибудь ужасно остроумное, когда вы пытаетесь выполнить простое умножение. Да и оператор = возле i тоже может быть перегруженным, типы могут быть несовместимыми, и в результате может быть автоматически вызвана функция приведения типов. И единственным способом разобраться во всем этом является не просто проверка типов, но и поиск кода, реализующего именно эти типы, и Бог вам в помощь, если вам попадется наследование, потому что теперь вы должны будете тащиться по всей иерархии класса, пытаясь найти, где все-таки на самом деле находится нужный вам код, а если где-нибудь есть полиморфизм, то вы действительно попали в беду, потому что тогда недостаточно знать, с какими типами объявлены i и j, надо точно знать, какие типы у них именно сейчас, и это может повлечь просмотр неизвестного количества кода, и вы никогда полностью не убедитесь в том, что полностью разобрались в какой-то проблеме (фу!).

Бред, кобыла отдыхает. Надо просто придерживаться правила: ни одна перегрузка чего бы то ни было не должна предписывать действий иной семантики, чем принятая в языке для использованного обозначения операций. В частности * может быть перегружен для умножения матриц, но ни когда не должен перегружаться ни для сложения матриц, ни для конкатенации строк, ни для реайза левого имейджа к правому. И тогда если написано , то будет сразу понятно, что это именно умножение. Просто если j - матрица, то умножение её даже на скаляр выполняется несколько иначе, чем перемножение двух скаляров. Но это тоже умножение. А вот для того, чтоб разобраться, что такое надо читать комментарий к функции, да и то при его наличии, а если его нет, то сам исходник функции и только тогда станет понятно, что третий параметр - это произведение, а первые два - множители, а не первый - произведение, а второй и третий - множители. А если ещё и нарушена связь имен с назначениями, то и для того, чтоб понять, что это именно умножение, а не сложение, или конкатенация. Но если оно может быть нарушено на c++ при перегрузке, то какие такие основания подозревать того же автора в способности правильно выбрать часть имени Mul для функции mimMul? У такого писаки в функции может быть всё что угодно вплоть до выделения память для матрицы, чьи размеры пятикратно больше среднего арифметчиеского размеров первого и третьего параметров, причём, указатели на строки матриц фактически начинаются на 2*sizeof(void*) дальше, чем указывают i и j.

0