Здравствуйте, LVE, Вы писали:

LVE>(я боюсь, что вообще не туда попал. Здесь все очень серьёзные)
Мне кажется, тут обратная ситуация.

LVE>За 20 лет моей работы в сфере ИТ, 80% работы было связано с рисованием и управлением, — то есть с интерактивной графикой. Это были всякого рода редакторы, GUI и игрушки.
Я вообще не в этой теме.

LVE>- При отображении графических примитивов и организации управления ими, необходимо учитывать множество вариантов. Это я называю «способностью компонента». Сюда относятся такие вещи, как способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, эффекты, связки, стрелочки и т.п.
LVE>Таким образом проявляется эффект комбинаторного взрыва.
LVE>Крупные компании могут себе позволить форсирование этой проблемы, нанимая 10, 100 и 1000 программистов, для обслуживания всех частных случаев. Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.
...
LVE>Итак. Мы рассмотрели 4 пространства классов, которые можно обозначить k, l, m, n. При нахрапистом подходе потребуется написать код примерно для k * l * m * n методов!

Но тут у меня появились дилетантские вопросы. Вот эти крупные компании нанимают толпы разработчиков, но не могут вырастить и/или нанять немного архитекторов? И даже если так — не могу себе представить, что можно нанять 1000 студентов разрабов, все как один упорно месяцами строящих архитектуру на неких принципах комбинаторного взрыва. Ну — т.е. это даже специально невозможно так сделать.

LVE>При тензорной архитектуре, которую я нарисовал, Вам достаточно написать примерно k + l + m + n методов. Ещё можно написать ряд методов для настройки компонентов. Единообразие гарантировано самой архитектурой.

Да при обычной архитектуре средней руки будет то же самое. Я бы, вот реально, лучше бы на архитектуру с k * l * m * n методами взглянул — дико любопытно, особенно внутри продукта от компании, нанимающей 1000 разработчиков на доходы от продажи этого продукта.

Здравствуйте, vmpire, Вы писали:

V>Никакая это не "тензорная архитектура", обыкновенный частный случай Separation of Concerns

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

Здравствуйте, viellsky, Вы писали:

V>Но тут у меня появились дилетантские вопросы. Вот эти крупные компании нанимают толпы разработчиков, но не могут вырастить и/или нанять немного архитекторов? И даже если так — не могу себе представить, что можно нанять 1000 студентов разрабов, все как один упорно месяцами строящих архитектуру на неких принципах комбинаторного взрыва. Ну — т.е. это даже специально невозможно так сделать.

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

V>Да при обычной архитектуре средней руки будет то же самое. Я бы, вот реально, лучше бы на архитектуру с k * l * m * n методами взглянул — дико любопытно, особенно внутри продукта от компании, нанимающей 1000 разработчиков на доходы от продажи этого продукта.

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

Здравствуйте, LVE, Вы писали:

V>>Никакая это не "тензорная архитектура", обыкновенный частный случай Separation of Concerns
LVE>Почему бы Вам не заявить, что я у них всё слизал?
У кого "у них"?

LVE>Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию!
LVE>Ведь именно это у нас является национальной традицией.
Опа, в качестве аргументации уже политика и патриотизм пошли...
Я так понимаю, других аргументов больше нет.

Здравствуйте, LVE, Вы писали:

LVE>Дело в том, что множество фирм имеют либо избыток ресурсов, либо тырят готовые компоненты без оглядки.

Ни первое, ни второе не соответствует действительности.

Здравствуйте, vmpire, Вы писали:

LVE>>Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию!
LVE>>Ведь именно это у нас является национальной традицией.
V>Опа, в качестве аргументации уже политика и патриотизм пошли...
V>Я так понимаю, других аргументов больше нет.

Это, чисто культурно-лингвистический аспект.
У вас есть знакомый англичанин?
Попробуйте ему сказать при каком либо несогласии — "you're wrong", и посмотрите на его реакцию.

Если у вас нет такой возможности — то я вам скажу, что для английской культуры это большая грубость.
Это всё равно что на х*й послать. Разговор будет сразу окончен.

Однако мы привыкли говорить друг другу:
— бла-бла, ты не прав.
— бла-бла, нет, ты не прав.

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

Вы знаете — я просто устал спорить. Я это дело никогда не любил и всегда старался понять людей.
Теперь я понял — русский человек ВСЕГДА неправ.
Это как первородный грех.
Родился русским? Тогда ты не прав.

Спасибо, если прочитали мою исповедь до конца.

Здравствуйте, LVE, Вы писали:

LVE>Делают так. Я Вас уверяю. Полно продуктов, в которых дублируется функционал и нарушается системный подход.
Полно, все верно. Системность нарушают, дублируют функционал. Но комбинаторики и близко при этом нет.

LVE>Т.е. происходит именно форсирование вопросов проектировки через привлечение дополнительного числа разработчиков.
Неверная причинно-следственная связь, подмена понятий. Количество разработчиков растет вследствие роста объема задач. Разве рост числа задач обусловлен только (или хотя бы в основном!) необходимостью форсировать вопросы проектировки? Нет конечно.

V>>Да при обычной архитектуре средней руки будет то же самое. Я бы, вот реально, лучше бы на архитектуру с k * l * m * n методами взглянул — дико любопытно, особенно внутри продукта от компании, нанимающей 1000 разработчиков на доходы от продажи этого продукта.
LVE>Наймитесь в крупную контору и Вам предложат писать методы для огромного количества частных случаев.
Понятие "огромное" — оно субъективное. И собственно я как раз о том, что будет k + l + m + n + "огромное", а вовсе не k * l * m * n.

LVE>Причём, без какой либо систематизации.
Т.е. сидит некто, у кого в голове нет никакой системы и предлагает закрывать каждый отдельный случай. Продукта на выходе не будет. Никакого.
В реальности конечно же системность есть, она превалирует и выходит за рамки архитектуры кода, есть и исключения сплошь и рядом — вызванные рациональным подходом в разработке продукта.

LVE>Потому что время — деньги.
LVE>Решения нужны конкретные, а не общие.
LVE>Причём нужны уже вчера.
Вы удивитесь, но что с "тензорной архитектурой" что с любой другой в хоть сколько то крупном коммерческом продукте будет то же самое. Будут в результате и частные решения, нужные "уже вчера" и будет некая "средняя" архитектура. Перефразируя, архитектура — это процесс, а не состояние. Она будет адаптироваться под реальные, не лабораторные, условия. Будет способна терпеть разработчиков, текучку кадров, ошибки архитектора, терпеть "срочно надо вчера" и многое другое. Если не будет — не будет этого продукта и не будет компании.
Концепт архитектуры это красиво — но только потому, что кажется будто весь поток задач и реальный процесс разработки в него вписываются.

Здравствуйте, LVE, Вы писали:

LVE>Здравствуйте, vmpire, Вы писали:

LVE>>>Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию!
LVE>>>Ведь именно это у нас является национальной традицией.
V>>Опа, в качестве аргументации уже политика и патриотизм пошли...
V>>Я так понимаю, других аргументов больше нет.
LVE>Это, чисто культурно-лингвистический аспект.
LVE>У вас есть знакомый англичанин?
LVE>Попробуйте ему сказать при каком либо несогласии — "you're wrong", и посмотрите на его реакцию.
LVE><...>
Я постоянно общаюсь с англоговорящими уже много лет. То, что Вы написали для меня очевидно, но никоим образом не относится к сути обсуждаемого вопроса.
Так же, как не относятся политика, национальность и патриотизм.

LVE>Ну а кто мы ещё есть, если сходу отвергаем опыт друг друга.
Вы ещё ничего не написали, чтобы отвергать.
Сейчас для меня это всё выглядит как изобретение велосипеда после большого времени проведённого в изоляции от индустрии разработки ПО.
Которая (изоляция) недавно всё-таки закончилась (возможно, смена работы или окончание очень длинного проекта).
Изобретение, спору нет, нужное и полезное. Только вот давно не новое, а много лет назад освоенное промышленностью.
В частности, по приведённой мною ссылке Вы можете увидеть множество альтернативных способов уменьшения сложности в дополнение к Вашему.
Насколько я понимаю, он ближе всего к "Subject-oriented programming", но точно не сказать, так как у Вас только весьма общие рассуждения.

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

LVE>Вы знаете — я просто устал спорить. Я это дело никогда не любил и всегда старался понять людей.
Вы не спорите. Вы не приводите аргументов. Вы не опровергаете аргументы оппонентов.
Это не спор. Это размахивание флагами, выкрикивание лозунгов и навешивание ярлыков.
Извините за прямоту, как Вы написали, это национальная черта.

LVE>Теперь я понял — русский человек ВСЕГДА неправ.
LVE>Это как первородный грех.
LVE>Родился русским? Тогда ты не прав.
А кто неправ, если спорят двое русских?

Здравствуйте, viellsky, Вы писали:

Вы очень хорошо высказались. Согласен с большинством ваших умозаключений.
Однако вот в этом месте существует интересный аспект:

LVE>>Причём, без какой либо систематизации.
V>Т.е. сидит некто, у кого в голове нет никакой системы ...

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

Вот такая практика.

Как же в такой ситуации действуют управляющие?

В одной такой фирме управляющий нанимал людей для работы с чистого листа.
Т.е. рабочим контекстом был только принятый формат файлов.
Каждый работник сам писал код для работы с файлами и строил свою объектную модель.
Функциональная обвязка решалась с помощью копипасты.

Видите, какие ужасы бывают в жизни!

LVE>Родился русским? Тогда ты не прав.
LVE>Спасибо, если прочитали мою исповедь до конца.

В курсе ли многоуважаемый джин, что существует куча форумов по созданию русских языков программирования?
http://plana.mybb.ru/viewtopic.php?id=2

Здравствуйте, vmpire, Вы писали:

V>Сейчас для меня это всё выглядит как изобретение велосипеда после большого времени проведённого в изоляции от индустрии разработки ПО.
V>Которая (изоляция) недавно всё-таки закончилась (возможно, смена работы или окончание очень длинного проекта).
V>Изобретение, спору нет, нужное и полезное. Только вот давно не новое, а много лет назад освоенное промышленностью.

Да. Так оно и произошло. Причём именно из-за подобной интерактивной библиотеки.
Это была моя грандиозная катастрофа.
Я 15 лет собирал материал по этой теме.
Выдался такой случай, что я уволился с работы.
Заперся дома и за 3 месяца написал её — like.view.
Работал по 20 часов в сутки.

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

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

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

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

Как будь-то меня кто-то проклял.
Это как злой рок, как испорченная карма.

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

LVE>Твоё возмущение — Банальная зависть и личная неприязнь.

Два вопроса:
1) почему (по каким причинам) я тебе по-твоему завидую;
2) что именно вызывает во мне личную неприязнь к тебе?

Здравствуйте, LVE, Вы писали:

LVE>Тема актуальна для разработчиков всевозможных редакторов, САПР и игр.

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

Для начала опишу парадигмы программирования существующие в С++ из коробки, потому что не из коробки их ещё больше.
1. Процедурное программирование
2. Функциональное программирование
3. Объектно-ориентированное программирование
4. Обобщённое программирование (шаблоны C++)

Теперь, что касается связывания объектов:
1. Во время компиляции (compile time)
2. Во время исполнения (runtime)

Каждая парадигма реализует свои варианты связывания, да и объекты в данном случае условное понятие, скажем так это данные и методы работы с ними.

Object Management Group (OMG) и другие уже давно исследуют способы гибкого управления объектами, но если обобщить существуют всего два подхода:

1. Передача данных
2. Передача методов

Передача данных это то, что следует принципу CRUD, то есть REST, SQL и прочие. Передача методов соответственно XML-RPC, CORBA и так далее. И то и другое позволяет передать данные или методы, но делается это принципиально разными способами.

Далее обратим внимание на классификацию вычислительных систем:


Осуществить передачу данных или методов можно разными способами, например, обратиться к оперативной памяти (стек, куча), по tcp/ip и тому подобное. Соответственно и скорость работы будет очень сильно различаться. Просто обращаясь к свойству объекта (передача данных) или вызывая метод (передача методов) мы уже делаем выбор в пользу того или иного способа работы.

Далее поговорим о двух конкретных платформах, это .NET и QT. Первое, что хотелось бы сказать, что с .NET нужно сваливать именно на Qt, если хочется приобрести в одних возможностях и при этом не потерять в других. Но в принципе тем кто работал с тем или другим будет понятно о чём дальше пойдёт речь.

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

Если нужно создать скоростную битомолку произведя связывание во время компиляции, то отлично подойдёт обобщённое программирование с теми же шаблонами C++. Во время же исполнения можно передавать интерфейсы, свойства, методы и сигналы-слоты (аналог событий). Пусть это и не так быстро и работает где-то на полиморфизме, где-то на свитчах (см. генерируемые moc файлы), зато открывает широкие возможности.

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

Всё это добавляет гибкости, но не избавляет от нудного написания компонентов. Теперь, что касается книг, в моей личной библиотеке тщательно отобранных книг есть Буч Гради (не считая более старых изданий):
1. Объектно-ориентированное проектирование с примерами применения
2. Объектно-ориентированный анализ и проектирование 3-е издание
3. Унифицированный процесс разработки программного обеспечения
4. UML Руководство пользователя 2-е издание

Но по архитектуре я бы рекомендовал Фаулер Мартин "Архитектура корпоративных программных приложений". Это именно про enterprise, чем собственно говоря и являются большие программы комбайны.

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

SVZ>Даже не представляю, как можно документально подтвердить квалификацию.
SVZ>

Сделать скриншоты разработанных технологий и их исходных текстов, заверить у нотариуса — чего тут непонятного?

Здравствуйте, LVE, Вы писали:

LVE>Здравствуйте, vmpire, Вы писали:

V>>Никакая это не "тензорная архитектура"...

LVE>ТЕНЗОРНАЯ АРХИТЕКТУРА (с) — Владимир Евгеньевич Липатов.

Idée fixe — (фр.) сверхценная идея

Здравствуйте, LVE, Вы писали:

LVE>Здравствуйте, vmpire, Вы писали:

V>>Никакая это не "тензорная архитектура", обыкновенный частный случай Separation of Concerns

LVE>Почему бы Вам не заявить, что я у них всё слизал?
LVE>Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию!

Только патент спасёт отца тензорной архитектуры!

Здравствуйте, Vladek, Вы писали:

V>Только патент спасёт отца тензорной архитектуры!

Между прочим NVidia анонсировала тензорные ядра в следующем поколении видеокарт на архитектуре Volta, потому в ближайшие годы ожидаемо возрастание интереса к TPU (Tensor Processor Unit).

https://www.opendesign.com Советую глянуть сюда, это серьезная библиотека для работы с автокадовскими чертежами, используется во многих проектах,
public api очень даже неплохо спроектирован. Есть некоторое пересечение с вашими идеями

Здравствуйте, Vladek, Вы писали:

LVE>>ТЕНЗОРНАЯ АРХИТЕКТУРА (с) — Владимир Евгеньевич Липатов.

V>Idée fixe — (фр.) сверхценная идея

Вовсе нет.

LVE>Я теперь понимаю, что в архитектурном новаторстве действительно отстал.

Здравствуйте, Vladek, Вы писали:

V>Только патент спасёт отца тензорной архитектуры!

Патент на программы не выдают.
Можно только зарегистрировать авторские права.
У нотариуса — это сделать проще и дешевле.
Только надо учитывать, что с лазерных распечаток тонер может посыпаться.
Поэтому лучше печатать на матричном принтере.