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

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

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

Сообщение от CheshireCat Так это получается отнюдь не "новая парадигма программирования", а всего лишь некоторые новые фичи IDE.

Кстати да, господа вы отвлеклись от основной темы - "О более новых парадигмах программирования, чем ООП", хотя ТС как-о изначально свёл разговор к автоматизации набора кода и удобстве средств разработки, что мало связано с парадигмами программирования.

Хотелось бы услышать мнения тех, кто ушёл с ООП на АОП. В чём радости и огорчения такого перехода?

0

Сообщение от CheshireCat это получается отнюдь не "новая парадигма программирования", а всего лишь некоторые новые фичи IDE. Которые, кстати, тоже отнюдь не "новые"

Это да. Ну "соседняя" же тема все-таки, я и написал. Тем более, "о парадигмах" это в названии темы, а в содержании первого сообщения уже более обобщённо, "о методах" что ли.

0

Сообщение от MLPMan "о парадигмах" это в названии темы, а в содержании первого сообщения уже более обобщённо, "о методах" что ли.

Темам нужно давать осмысленные названия, об этом написано в правилах, а то получается "на заборе ... написано, посмотрел, а там дрова лежат"

0

А это и есть более новая парадигма программирования - когда ты, например, 100% работаешь с мышкой, а не 100% печатаешь на клавиатуре. Когда ты 50% рисуешь мышкой, 50% печатаешь, то это тоже новая парадигма, но всего на 50%... Новизна парадигмы заключается в новом понимании того, что языком программирования является не текст программы в текстовом формате, а все-таки способ общения программиста с компьютером при создании проекта. И программа - это не текст, а любого рода информация, которая определяет, как должна работать программа.
1) Соответственно после всего этого должно возникнуть понимание, что для программиста предпочтительны (и таковые имеются!) более нативные способы передачи информации компьютеру. Например, передача информации указанием мышью.
2) Вторая часть понимания заключается в том, что программист не должен утруждать себя передачей некоторой дублированной и излишней информацией, которую компьютер и так способен идентифицировать по косвенным признакам. Сюда относится Intellisense.
3) Третья часть понимания должна подвести к тому, чтобы поток информации от программиста к компьютеру не обязан идти сразу полноценный, абсолютно точный и т.д. Процесс разработки все равно итеративный: можно сначала обрисовывать общие черты программы, а лишь затем - уточнять и т.д. Этот момент вы наверное посчитаете за фантастику, однако это отнюдь неправда. У меня есть конкретные примеры.
4) Ну и наконец, четвертый момент: мы должны осознать, что мы можем давать больше информации компьютеру при программировании, чем делаем это сейчас с помощью стандартных языков программирования. Например, если мы определили переменную ABC типа int, то мы помимо этого можем указать реальный диапазон значений этой величины для того, чтобы компилятор мог подобрать оптимальный машинный код для данного конкретного случая.

0

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

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

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

Это называется повторное использование кода и Intellisence сюда ну никак не относится.

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

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

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

Это называется range-типами и уже давно известно.

0

Сообщение от korvin_ Предлагаю тебе в реальной жизни вместо разговора общаться с людьми жестами или показывая им картинки. Тогда и посмотрим, что более естественно.

Не всегда аналогии уместны. Где Ваши нормальные доказательства? Несомненно самым лучшим способом общения является "мышь+клавиатура". Но вопрос - в какой пропорции.

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

0

Сообщение от Mikhaylo agile - это термин из другой области, из управления софтверными проектами и относится к менеджменту.

Это методология разработки, ни больше, ни меньше. Любое программирование -- это некоторый "софтверный проект", так что область та самая.

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

А у меня выдает.

Сообщение от Mikhaylo но мне кажется, что здесь Вы не поняли мой посыл

Когда кажется, курить маны надо. Например техники оптимизации в современных компиляторах.

Добавлено через 53 секунды

Сообщение от Mikhaylo Не всегда аналогии уместны

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

0

Сообщение от korvin_ Речь (хоть устная, хоть письменная) является наиболее простым, удобным и точным способом выражения мыслей "общего назначения" для человека.

Я понял Вас. Продолжайте быть уверенными в этом. ))))

0

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

Ох! У меня тоже. ("Все уже украдено до нас." (с) ) Например, советские ГОСТы тысяча-девятьсот-замшелого года именно так и предписывают организацию ОКР вообще и разработки ПО в частности....

0

Сообщение от Mikhaylo Продолжайте быть уверенными в этом. ))))

Не-не-не, это ты продолжаешь ломать поломанные копья.

0

Вот, что я нашел в книге Мартина Фаулера "UML. Основы" (2005 г.):

Более фундаментальным аспектом является сама идея применения UML в качестве языка программирования. С моей точки зрения, использовать UML как язык программирования стоит, только если в результате получается нечто более продуктивное, чем в случае применения другого языка программирования. Однако исходя из своего опыта работы в различных графических средах разработки, я не стал бы это утверждать. Даже если UML и более продуктивен, надо еще накопить критическую массу пользователей, чтобы принять его в качестве основного направления. UML сам по себе представляет большое препятствие. Подобно многим пользователям, имеющим опыт работы с языком Smalltalk, я считаю его более продуктивным, чем многие современные основные языки. Но в настоящее время Smalltalk представляет только небольшую нишу в пространстве языков, и я не наблюдаю большого количества проектов, написанных на нем. Чтобы избежать судьбы языка Smalltalk, UML должен быть счастливчиком, даже если он самый лучший.

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

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

0

тема на самом деле отличная
люди начинают искать >нечто< новое
всё стремится к ускорению программирования, этот процесс неизбежен, иначе бы работали тысячи прогеров на перфокартах

0

Сообщение от Mikhaylo Мне нужны ссылки.

Навскидку:

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

Векторные языки, вот впечатляющее видео.

Функциональное программирование.

Я понимаю, что это глупый вопрос, но ты, конечно же, уже прослушал вот этот курс, прежде чем задавать вопрос, существуют ли языки лучше С++? Я не знаю, существуют ли хуже...

Вот еще пара ссылок вспомнилась сразу:
http://www.nestor.minsk.by/sr/2003/07/30710.html
http://russian.joelonsoftware.... enceC.html
http://boevo.ru/informatika_vt... ryali.html

0

Господа!

Все эти векторные, конкатенативные, функциональные языки - это конечно хорошо. Все эти "парадигмы программирования" объединяет одно - они определяют все новые и новые интересные объекты для языков (например, вектор, рекурсия, интерфейс, делегат, тензор, матрица и т.п.). Программист радуется, строчит на клавиатуре, сбивается, ищет, где пропустил точку с запятой, нашел ошибку, исправил, F5...
Стойте-стойте! В языке определен объект! Так какого черта этот объект соответствует сотне строго правильных ударов по клавишам?! Почему на экране этот вполне простой объект разбивается на объявление сигнатуры, инициализацию, использование, преобразование и все это разбросано в разных частях кода?
Ладно, хрен с ним, с объектом. Если программист сам его создал, то в принципе рано или поздно он запомнит все его вхождения в код и успешно использует его.
Чужой код, чужие объекты! Огромнейшие библиотеки чужого кода! Как с ними быть? Пишем:

не нашли? Тогда

О! Функция sin распознана компилятором! Здорово! Но сколько ударов по клавишам?!

Короче говоря, господа, наши IDE и языки программирования дают неплохие инструменты для работы. Эти инструменты комплексные, быстро работают, многое умеют. Но доступ к ним осуществляется исключительно разворотом к ним задом, при этом искать инструмент приходится на ощупь и только левой рукой. Так как инструментов очень много, в руку постоянно попадаются всякие ненужные инструменты. Проходят годы и ты с удивлением узнаешь о наличии молотка, до этого гвозди забивал микроскопом...
Да ладно библиотеки функций и объектов. Поговорим о встроенных средствах языка программирования. Элементарно, чтобы написать условный переход, приходится долбить одни и те же клавиши:

"Современные среды разработки" помогают создавать условные переходы автоматически. Ура! Объект "условный переход" создан! Однако программист рано или поздно устает и в процессе правки условного перехода может разрушить объект. Стер букву "f" в ключевом слове "if". "Современная среда" молчит, ей вообще пофигу, компилятор все равно обнаружит синтаксические и прочие ошибки... Любой объект вообще легко разрушить, достаточно один раз неправильно нажать на клавишу. При этом сделать это необычайно легко, синтаксисы языков этому просто прямо способствуют (см. далее).

Операторные скобки - это вообще чудо из 60-х годов прошлого века:
или

Чтобы эта буквотворная хрень удобно читалась, программисты придумали этику программирования. "Стукни по TAB несколько раз, выровняй табуляцию!" И пишут 500-страничные книги о том, как нельзя выстраивать код.

Господа! Удобство программирования не заключается лишь в хорошем языке программирования и библиотеках функций. Со времен изобретения компьютеров было не так много идей, которые реально улучшают интерфейс программиста. Например, Rapid Application Development (RAD).
Чтобы как-то улучшить интерфейс, нужно задаться вопросом: почему программирование представляется как стучание по клавишам и изучение операторных скобок?


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

0

Сначала хотел написать что-то конструктивное в ответ на последний пост, а потом махнул рукой на это бесполезное дело - я не знаю как комментировать чужие субъективные убеждения, которые мало пересекаются с тем, что я вижу в повседневной практике. Отвечу лишь на один вброс:

Сообщение от Mikhaylo почему программирование представляется как стучание по клавишам и изучение операторных скобок?

Это представления стороннего наблюдателя, не погруженного в процесс. Глядя на себя и своих коллег: основные силы мы тратим далеко не на изучение "операторных скобок". Сбор требований, аналитика, разработка архитектурных решений с готовностью к изменениям, сочетание различных технологий, развертывание инфраструктуры, взаимодействие различных систем. Нужно решить немало вопросов, чтобы проект жил. Чтобы не загнулся от непредвиденной нагрузки, не потребовал полного переписывания от незначительного изменений требований.

Естественно, мы же и занимаемся реализацией. Выбираем язык, набор библиотек и т. д. Вот только простота разработки и дальнейшего сопровождения определяется не языком, не свистелками ide, а квалификацией разработчика.

1

Сообщение от 0x10 Глядя на себя и своих коллег: основные силы мы тратим далеко не на изучение "операторных скобок". Сбор требований, аналитика, разработка архитектурных решений с готовностью к изменениям, сочетание различных технологий, развертывание инфраструктуры, взаимодействие различных систем.

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

0

Сообщение от Mikhaylo В языке определен объект

не определен, не фантазируйте. то что там определено к объектам отношения не имеет

Так какого черта этот объект соответствует сотне строго правильных ударов по клавишам?!

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

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

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

0

Воу, воу потише...

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

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

Конечно, вы все видели программирование под разными углами и много-много раз. Однако программирование гораздо многограннее, чем мы представляем и видели.
Взять, например:

Сообщение от 0x10 Bret Victor - Inventing on Principle - а это просто шикарный доклад, как раз по теме - взаимодействие разработчика и машины. Эффектная презентация, разнообразные примеры - одним словом, рекомендуется.

Полный зал программистов охает и ахает. Программисты ли это? Никакой новой грани программирования здесь нет. Просто применение основ моделирования систем к узкой задаче.

Я же ставлю вопрос несколько иначе: нужно вырабатывать идеи, которые превратят кодирование/программирование, нахождение ошибок, анализ чужого коверканного кода в удовольствие. Отчего нет удовольствия? Да потому что языки программирования и среды IDE не осуществляют даже элементарную поддержку-помощь. Это я констатирую безусловно и бесповоротно. Языки программирования ладно, но IDE в соответствии с моделью MVC должен предоставлять интерфейс бОльшей степени нативности, нежели интерфейс императивного кода существующих популярных языков программирования.
Нужно еще бОльшее приближение к той абстракции, которая в голове у программиста! Возможности для этого есть. Например, кириллица в именах-идентификаторах must be! Русским программистам следует работать с русскими переменными, объектами и т.п. Это их родной (нативный) язык. MVC легко решит проблему совместимости с существующим стандартом языка. MVC поможет в переходном периоде, до переиздания стандарта, которое должно стать просто неизбежным.
Пора прекратить мучения с проблемой, которую я назвал ранее "анализ операторных скобок". Если программист решил создать условный переход, то он добавляет объект IF нажатием на кнопку "Add IF"/"Добавить ЕСЛИ". Правой кнопкой можно добавить к этому условному переходу ELSE. Или при необходимости убрать. Все операторные скобки создаются и уничтожаются автоматически и только автоматически. Объект невозможно разрушить, нельзя стирать букву F в ключевом слове IF, т.к. это единый объект (супер-токен) с условием, действиями, операторными скобками. Либо нельзя что-то удалять, либо удалить весь объект. Мучения прекратятся не только у программиста, но и у компилятора, т.к. не нужен будет никакой парсинг.

Это лишь некоторая часть идей. А еще сколько можно нарыть?

0

Сообщение от Mikhaylo Однако программирование гораздо многограннее, чем мы представляем и видели.

"не мы, а вы" (с) классика
поясняю почему.

Например, кириллица в именах-идентификаторах must be!

уж лет 10 как есть практически у всех. никому кроме 1сников не надо.

Если программист решил создать условный переход, то он добавляет объект IF нажатием на кнопку "Add IF"/"Добавить ЕСЛИ".

любая вменяемая иде после "if<tab>" все это рисует, опять таки лет 10 как уже. при этом не надо терять врямя возюкая мышью что б прицелиться в этот иф и щелкать правой кнопкой. ваша модель в данном месте в разы мнее эффективна чем существующая.

нельзя стирать букву F в ключевом слове IF,

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

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

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

0

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

1