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

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

Немного о себе: я не считаю себя программистом, так как я не создавал программы с более сложными объектами, чем стандартные визуальные (кнопки, лэйблы, окна и т.д.). Если уделить программированию годы, то наверняка я освою любую методологию программирования. Ведь у меня за плечами: 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

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

Абстрактно рассуждаете ВЫ! Попробуйте все это проделать сами, а потом уже говорите.

Сообщение от mporro Даю бесплатный совет: отправляйтесь на какой-нибудь политический или философский ресурс. Там наверняка ведётся дискуссия на тему "Почему в XXI веке люди ещё читают книги".

Вы только что провели аналогию между программированием и книгами. Для Вашего сведения: сейчас все больше и больше читают именно электронные книги. Поэтому я не могу Вас никак понять, к чему Вы клоните... ;-)

0

Сообщение от Mikhaylo Абстрактно рассуждаете ВЫ!

Ёда, что с Вами?

0

Mikhaylo,

Для Вашего сведения: сейчас все больше и больше читают именно электронные книги.

Для сведения: на перфокартах никто не программирует.

0

Сообщение от mporro Для сведения: на перфокартах никто не программирует.

Молодой человек продолжает составлять ассоциации, а они никак не работают. Для сведения: бумажные книги читают! И с перфокартами аналогии не получается. Ваше ассоциативное мышление прямо удивляет! Как Вы вообще пишете программы? ))

0

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

0

Сообщение от Mikhaylo Ну если Вы говорите о других задачах, выполняемых программистом, то следовательно и разговор этот должен быть для другой темы.

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

Сообщение от Mikhaylo Пора прекратить мучения с проблемой, которую я назвал ранее "анализ операторных скобок".

Проблема надумана.

Сообщение от Mikhaylo Мучения прекратятся не только у программиста, но и у компилятора, т.к. не нужен будет никакой парсинг.

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

Сообщение от Mikhaylo Правой кнопкой можно добавить к этому условному переходу ELSE.

На правах троллинга: не на всех системах вообще есть "правая кнопка".

1

Mikhaylo,

Молодой человек продолжает составлять ассоциации, а они никак не работают.

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

0

Сообщение от Mikhaylo Пора прекратить мучения с проблемой, которую я назвал ранее "анализ операторных скобок". Если программист решил создать условный переход, то он добавляет объект IF нажатием на кнопку "Add IF"/"Добавить ЕСЛИ". Правой кнопкой можно добавить к этому условному переходу ELSE. Или при необходимости убрать. Все операторные скобки создаются и уничтожаются автоматически и только автоматически. Объект невозможно разрушить, нельзя стирать букву F в ключевом слове IF, т.к. это единый объект (супер-токен) с условием, действиями, операторными скобками. Либо нельзя что-то удалять, либо удалить весь объект. Мучения прекратятся не только у программиста, но и у компилятора, т.к. не нужен будет никакой парсинг.

То есть внутри операторных скобок нельзя написать ни одного оператора? Иначе же задача парсинга такого объекта ни куда не денется. А если надо вложить скобку в скобку?

0

Сообщение от Mikhaylo Попробуйте все это проделать сами, а потом уже говорите

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

0

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

Я потихоньку пытаюсь начать. Пока надо сделать так много, что я не знаю, с чего начать... Идеи не вырисовываются сразу в единую картину, потому что надо предусмотреть место каждому из объектов языка - классу, объекту, массиву, простым типам, функциям, переменным и т.д. Ну вообще разработка языка программирования - не банальное дело, которым запросто можно заниматься в свободное от работы время. Поэтому меня интересуют готовые идеи.
На самом деле есть готовая реализация - UML, но она меня не впечатляет. UML хорош своей универсальностью и признанием во всем мире, но не как язык программирования. Чего-то в нем, видимо, не хватает. Какие-то вещи, видимо, он неудобно описывает.

Вообще искомое решение меня интересует как хобби. К сожалению, в моей профессии оно не пригодится.

0

Сообщение от Mikhaylo Я потихоньку пытаюсь начать.

А я уже начал и разметка исходника уже вырисовалась, причём:
1. if then - единый токен.
2. Парсер не только ни куда не делся, но и стал по этой причине сложнее парсера, для которого это два раздельных токена.

0

Сообщение от taras atavin А я уже начал и разметка исходника уже вырисовалась, причём: 1. if then - единый токен.

Это простое совершенствование императивного кода. Простейший пример. Про парсеры извольте не согласиться, и к тому же это не суть.
Кстати, я не предлагаю полностью уходить от императивных элементов языка. Наоборот, я считаю, что довольно большой объем кода должен укладываться в эту модель или в этот способ представления кода, ибо последовательная группа действий (императив) - это понятно, просто, нативно. Часто сложно и запутанно становится, когда появляются ссылки, вызовы, переходы. В этой части можно и нужно что-то усовершенствовать, визуализировать...

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

0

Сообщение от Mikhaylo Это простое совершенствование императивного кода.

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

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

Сообщение от Mikhaylo ибо последовательная группа действий (императив) - это понятно, просто, нативно.

А разработчики компиляторов то и не знали, что перед ними задача вообще не стоит.

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

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

При чём здесь вообще игровые текстуры?

0

Сообщение от Mikhaylo определить необходимый уровень детализации

Сообщение от taras atavin При чём здесь вообще игровые текстуры?

Это пять) Убило)

0

Сообщение от 0x10 Это пять) Убило)

Вот именно это и убило.

0

Сообщение от 0x10 Это пять) Убило)

Сообщение от taras atavin Вот именно это и убило.

Вы не знаете слов "уровень" и "детализация"? DDD Для Вас это только картинки/графика???

0

Сообщение от Mikhaylo Вы не знаете слов "уровень" и "детализация"?

Понимаю.

Сообщение от Mikhaylo DDD Для Вас это только картинки/графика???

1. Речь была о графике.
2. Если Вы не знаете слова "приближение" и считаете его синонимом зума, то это не моя проблема.

0

Уровень детализации... В данном случае речь о том, сколько информации нужно выводить на экран. Вот, например, когда мы пишем вызов функции:
Мы не указываем типы данных Image1, Image2. Язык программирования позволяет, т.к. типы уже указаны в сигнатурах.
Среда разработки, дабы не нарушать "чистоту" языка программирования, не вносит никаких изменений в пресловутый "уровень детализации" кода.
Между тем, интересным был бы вариант, если бы под именами переменных уменьшенным шрифтом серым цветом был бы подписан тип данных. Примерно так:
Многие среды разработки решают эту проблему с помощью всплывающих хинтов. Это открытый вопрос, как лучше делать.

0

Сообщение от Mikhaylo Уровень детализации... В данном случае речь о том, сколько информации нужно выводить на экран. Вот, например, когда мы пишем вызов функции: Код Code 1 Image2 := ResizeImage(Image1); Мы не указываем типы данных Image1, Image2. Язык программирования позволяет, т.к. типы уже указаны в сигнатурах.

При чём здесь детализация? Типы просто указаны выше. И даже когда пишешь , не указывая внутреннего представления строки (хоть на списке символов), это тоже уровень абстракции, а не детализация. Детализация же показывает, на сколько хорошо видно представленную информацию. Если в игре часть текстуры танка загорожена домом - это ведь оклюзия, а не детализация, а вот если танк ближе/дальше отъехал и в связи с этим на него наложена более грубая/подробная текстура - вот это уже детализация.

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

Сообщение от Mikhaylo Между тем, интересным был бы вариант, если бы под именами переменных уменьшенным шрифтом серым цветом был бы подписан тип данных. Примерно так: Code 1 2 Image2 := ResizeImage(Image1); TImage TImage

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

0

Сообщение от taras atavin Во-первых это не парадигма.

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

Сообщение от taras atavin А во-вторых это нафиг ни кому не нужно.

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

0