All streams
Search
Write a publication
Pull to refresh
13
0
Сергей Роговцев @lair

Архитектор

Send message
А вот скажите, пожалуйста, каким образом DSL решает проблемы, описанные вами в самом первом списке («проблемы традиционного подхода»)?
Да, приблизительно так. Спасибо.
Ну вот например, автор не знает, как сделать так, чтобы одновременно было и простое наследование (And и Or наследуют от Bool, конструкторы принимают Bool), и одновременно простое управление памятью. Вот с этим он и борется мучительно.
Просто в этом смысле паттерны — все, и сравнивать музыку с программированием настолько же осмысленно, насколько осмысленон сравнивать программирование с копанием ям: и то, и другое — бихевиористские шаблоны, несомненно.
Просто данное вами определение не имеет отношения к тому, что «нормальные люди» понимают под словом «паттерн». Ваше определение подходит вообще к любой деятельности, и, как следствие, бессмысленно.
«Только чтобы одинаковая терминология: паттерн есть внешнее проявление какого-то процесса, некий сингнал, который возникает одновременно с проходящим процессом.»
А. Привет бихевиоризму.

Все, что дальше — это подмена словом «паттерн» других слов без сохранения собственно смысла слова «паттерн».

То есть, вы можете называть паттернами что угодно, конечно.
… так то нормальные языки. А у людей тут C++, все такое, «не использовать указатели».
Так вы это расскажите автору топика, а не мне.
Забыв, видимо, при этом, что сначала учатся писать обычные.
«Два умных разработчика всегда найдут способ договориться.»
Особенно когда один из них недоступен.

«Я думаю, вам лучше подождать, когда я выпущу release, и тогда, пожалуй, критикуйте хоть до посинения.»
Вот именно об этом я и говорю, да. И комментарий про «когда буду думать над Not, тогда и» ниже — тоже об этом же.

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

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

«То есть код, сгенерированный группой паттернов под названием «скиллы по созданию музыки». Из чего следует что музыка — набор паттернов.»
Очевидно, что нет. Даже если считать навыки по созданию чего-то группой паттернов (что уже само по себе не верно), как мы все понимаем, результат работы группы паттернов никак не обязан сам быть набором паттернов.

«встроенные в организм человека системы распознавания паттернов уловили некоторый знакомый «рисунок», знакомый паттерн, и поставили ему в соответствие слово «музыка».

Вывод: музыка — набор паттернов.»
Тоже излишне быстрый вывод. Тот факт, что музыка содержит закономерности, узнаваемые слухом, совершенно не означает, что она является только набором таких закономерностей.

«И у паттернов ООП есть свой конкретный синтаксис, который мы должны форсировать любой ценой, чтобы программа на паттернах ООП заработала.»
Удивительно, но я с вами согласен. А вот топикстартер от этого синтаксиса уходит.
Вот понимаете, для меня такое заявление — это как раз указание на то, что вы не думали, как другой человек будет поддерживать вашу разработку.
«И стихи писать научить можно?»
Да, можно.

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

Во-вторых, как это не надо вставлять в наследование? Поскольку Not — логическая операция, даром что унарная, она должна использоваться везде, где раньше можно было использовать And и Not.
«Я понял, что смысл статьи — возможность мыслить и дизайнить с использованием ООП вне зависимости от того, какие возможности для реализации даны.»
Мы, собственно, о том и спорим, что тут превалирует — ООП или желание получить конкретный синтаксис любой ценой.

«Музыка — это тоже набор паттернов.»
Нет.

«Сыграйте музыку на гитаре, оцифруйте ее как миди — и потом можно будет проиграть ее голосом любого инструмента.»
И что? Это всего лишь говорит о том, что нотная запись является интерпретируемой, и может быть интерпретирована различными способами.

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

Вам не кажется, что мы по кругу ходим?
"
— Я не использую наследование, чтобы не выделять память явно.
— Возьмите auto_ptr.
— В этой задаче указатели ни к чему.
— Тогда можно было бы использовать наследование.
— Я не использую наследование, чтобы…
"
Что-то я не вижу простоты системе классов аж вообще. Как уже неоднократно говорилось, все это прекрасно делается банальным деревом наследования Expression — BooleanExpression — AndExpression/OrExpression. Безо всяких шаблонов.

Вот это — просто. И понятно. И расширяемо в любой момент в любую сторону.

(нет, ну правда, AST придумали не на пустом месте)
Вот именно поэтому научить творческой деятельности можно, а научить писать произведения искусства — нельзя.

Information

Rating
Does not participate
Location
Montreal, Quebec, Канада
Date of birth
Registered
Activity