Критерии хорошей, годной архитектуры

> Это самый старый, жирный и зелёный тролль ЛОРа, ты разве не знал?

Читал я всякие баталии за разные года, и этот перс постоянно выступал за императивщиков.

> Мне она не нравится. Я понимаю, что находят в ней другие, почему они становятся фанбоями разной степени вменяемости, но сам я по доброй воле не стану пользоваться никаким из Лиспов.

Ну, собственно, ничего и не изменилось с тех пор.

Я могу предложить объективный критерий (целевую функцию) - минимазиця числа строк кода (с нормальным форматированием ес. но), обеспечивающий заданную функциональность;-)

Даешь J!

> Я могу предложить объективный критерий (целевую функцию) - минимазиця числа строк кода (с нормальным форматированием ес. но), обеспечивающий заданную функциональность;-)

Очень плохой критерий. Слишком простой.

> Очень плохой критерий. Слишком простой.

Все красивые и правильные решения обычно очень простые;-)

J ф топку, Связка Python и C++ форевер! Начнем рождественский холвиар?;-) На самом деле прописные ж истины - нет хороших универсальных языков, каждый язык имеет свою нишу. Любую задачу можно сделать на любом языке, вопрос в том чего это потребует... Правильная архитектура подразумевает в частности применеие правильных инструментов, в частности правильных ЯП, для решения конкретных подзадач, что приводит в итоге к уменьшению чиcла строк кода;-)

> Связка Python и C++ форевер! Начнем рождественский холвиар?

Зови Antichrist'а, он тебе такой холивар устроит. Особенно за C++.

J — это пример языка, который по твоему критерию как минимум заткнет за пояс 95% ЯП на 95% задач. Что есть очевидный фейл критерия. А ты думал, что я тупо фанат J?

> Все красивые и правильные решения обычно очень простые;-)

«Every complex problem has a solution that is simple, neat and wrong» (c)

1) Питон будет не слабее

2) Если ты добавишь к критериям производительность, то от 95% останется 5...15%;-)

3) Хорошо, ты не тупо, ту утонченно фанат J;-)

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

Принцип Калашникова: «Избыточная сложность — это уязвимость»

Связка Python и C++ форевер

человек, Вы в чьём сейчас уме, какой С++? посмотрите как «просто» связываются шаблонные классы и подумайте, может то просто С вместо С++ был?

Слышал мнение, что по сути проблема в разработке сложных программных систем - это сильная связанность. Все остальное - второстепенно.

Принцип похожий с другими системами, механическими, электрическими:

1. Не крутить две ручки сразу. (eg, cравни систему управления вертолёта и самолёта. У самолёта крен/тангаж/ускорение, у вертолёта — углы наклона винтов и обороты, 2 ручки, которые надо крутить *одновременно*, чтобы взлететь, сделать манёвр и т.п.) — см. пример в Pragmatic Programmer

2. Минимизировать количество подвижных частей. Например, те же паттерны проектирования — это идея зафиксировать стандатные запчасти (идиомы, паттерны) и выделить подвижные (применение паттернов). В разных языках программирования и паттерны получаются разные, из-за различных возможностей языков. Поэтому тут ещё за кадром ещё остаются неявные «встроенные фичи языка», для преодоления ограничений которых служат паттерны и их применение.

3. Модульность, сильная/слабая связанность, ортогональность — это не самоцель, а средство реализации 1. и 2. вот здесь, несмотря на некоторую архаичность и проч., высказана здравая мысль: модульность и однородность чего-то — связаны. То есть, архитектура получается модульной, если модульность реализует различными модулями ортогональные, однородные какие-то фичи.

4. Ну то есть, ортогональность важнее модульности. Потому что модульность это средство реализации некоторой ортогональности, однородности внутренне присущей задаче. А реализована она может быть наиболее подходящим способом для языка и для задачи: ООП какого-то вида и паттернами проектирования, модулями или компонентами, аспектами или контекстами, и т.п.

5. Про аспекты и парадигмы, законы эргономики: сложность сильной связанности в том, что она заставляет мыслить сразу на нескольких уровнях одновременно, а человеки этого не любят (см. Закон Хика, закон Фиттса, закон про 7+-2 ячеек в оперативной памяти человека (запамятовал название)). В свете этих законов, смысл улучшения модульности, более слабой связанности — чтобы пришлось отслеживать меньше таких параллельных иерархий одновременно, меньше скакать между разными уровнями сложности. Смысл аспектов, контекстов, слоёв архитектуры, literate programming weave — в том, чтобы выделить метаданные, связывающие слои на первое место.

6. DRY принцип, Don't Repeat Yourself — подробности в Pragmatic Programmer.

7. maintainability, scalability — да, важны в долгосрочной перспективе. В долгосрочной перспективе архитектура хорошая, если эти вопросы упрощает. Тут важно не переусердствовать (проблема второй модели, планируйте одну версию выкинуть, You Ain't Gonna Need It, и т.п.)

8. В общем сферическо-вакуумном смысле, задача *хорошей* архитектуры — упрощение ненужной, избыточной сложности настолько просто, насколько это возможно, но не проще этого. Избыточная сложность — это уязвимость, некрасивый самолёт не летает, и т.п. Здесь надо разделять внутренне присущую задаче системную сложность, и сложность в смысле громоздкость реализации решения. Второе не должно заслонять первое.

А по теме, книжки: Pragmatic Programmer, Programmer's Stone

http://en.wikipedia.org/wiki/AntiPatterns , http://en.wikipedia.org/wiki/Anti-pattern

> закон про 7+-2 ячеек в оперативной памяти человека (запамятовал название)

http://ru.wikipedia.org/wiki/Магическое_число_семь_плюс-минус_два

А по теме, книжки

http://ru.wikipedia.org/wiki/ТРИЗ

> посмотрите как «просто» связываются шаблонные классы и подумайте, может то просто С вместо С++ был?

Они действительно просто связываются, без всяких кавычек. SWIG RTFM, или вот если хотите http://a-iv.ru/pyart/cpp2py.pdf

ога, ога

Поскольку C++ код должен быть скомпилирован перед импортом в Python, все необходимые реализации шаблонов должны быть инстацированы.

пуфф, и нет шаблонов :) Вы когда-нибудь пробовали нагруженный шаблонами код вот таким образом обрабатывать?

> Принцип Калашникова: «Избыточная сложность — это уязвимость»

Калашникову предъявлялись хорошо понятные и _фиксированные_ требования. Сколько там существенно разных версий автомата вышло за 60 лет?

> пуфф, и нет шаблонов :) Вы когда-нибудь пробовали нагруженный шаблонами код вот таким образом обрабатывать?

Я не то что пробовал - я каждый день этим плотно занимаюсь;-) Ядро библиотеки, на которой крутятся все наши вьюверы и не меньше половины счета именно так и устроено. И я бы с бааальшим интересом посмотрел на того, кто сможет воспроизвести что нить подобное без шаблонов - сколько бы строк кода у него ЭТО заняло и насколько бы этот код был читаемым...

Если и правда интересно, вот http://a-iv.ru/aivlib правда на сайте неск устаревшая версия.

> кто сможет воспроизвести что нить подобное без шаблонов - сколько бы строк кода у него ЭТО заняло и насколько бы этот код был читаемым...

У вас с++ головного мозга, советую расширить кругозор и освоить что-то ещё. Есть масса способов обойтись без шаблонов

> пуфф, и нет шаблонов :) Вы когда-нибудь пробовали нагруженный шаблонами код вот таким образом обрабатывать?

Я не то что пробовал - я каждый день этим плотно занимаюсь;-)

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

И я бы с бааальшим интересом посмотрел на того, кто сможет воспроизвести что нить подобное без шаблонов - сколько бы строк кода у него ЭТО заняло и насколько бы этот код был читаемым...

да тысячи проектов таких :) начиная со всяких lapack и иже с ними

да тысячи проектов таких

имеется в виду не использующих ни шаблоны, ни даже С++

С аналогичной гибкостью и производительностью? Как то не верится...

Вообще 90% холиваров связаны с тем, что народ смотрит на предлагаемый подход, примеряет его к СВОИМ задачам и говорит - фигняяя.... можно гораздо проще. Ребят, вы приложите свой супер-пупер подход к задаче оппонета и потом кричите про кругозор, болезни мосга и тд и тп.

Конкретно в нашей области сухие факты: 1) наши коды самые быстрые - отрыв от конкурентов на порядки, и никто ни на каком другом ЯП ничего даже близкого по производительности создать не смог (я не про приведенный выше пример библиотеки говорю, а напр. про код который считает 3D синтетич. сейсмограммы на персоналке без всяких GPU). 2) они написаны на связке C++ (с шаблонами) и Питон. 3) мы думаем как уйти от шаблонов, но пока ничего кроме кодогенератора (на питоне) в голову не пришло - да и там шаблоны остануться...

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

Считаете что можно сделать лучше? Давайте, OCaml (или J;-))))) Вам скажем в зубы и попробуйте реализовать напр. метод FDTD для 3D ур-й Максвелла в ваккуме с производительностью хотя бы 20 тактов на ячейку на шаг для области хотя бы 512x512x512 ячеек на одной машине. Если выйдет - нам (и мировому сообществу тоже) это будет ОЧЕНЬ ИНТЕРЕСНО (без ухмылок), а лично я Вам свой ноутбук подарю;-))))))))))

А так... как говорил мой друг «3.14-ть - не мешки ворочать», или если культурнее «обсуждать архитектуру - не конкретные задачи решать»;-))))))

Да, и я не заблуждаюсь на счет шаблонов - это просто костыль в С++ для обхода сильной типизации (или как там оно называется). В других языках эта проблема наверное решена куда более изящно, не спорю. Но лучший ЯП - тот который лучше знаешь;-)

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

У Вас какое то извращенное понятие идеи шаблонов. В любом случае будет раскручиваться и использоваться конкретная реализация, просто внутри С++ компилер делает это сам, а тут его надо попросить (одна строчка, это немного, тем более что из питон и той писать не надо при правильной системе сборки). Шаблоны позволяют порождать семейства классов и функций и избегать дублирования кода, если их не сипользовать в данном случае объем С++ кода возрасатет на порядки. Хотя можно конечно дефайны скажем привлечь;-)))))))

С аналогичной гибкостью и производительностью

аналогичной чему? :)

Как то не верится...

это не вопрос веры, я Вам конкретный пример привёл - смотрите

Конкретно в нашей области сухие факты: 1) наши коды самые быстрые - отрыв от конкурентов на порядки, и никто ни на каком другом ЯП ничего даже близкого по производительности создать не смог (я не про приведенный выше пример библиотеки говорю, а напр. про код который считает 3D синтетич. сейсмограммы на персоналке без всяких GPU). 2) они написаны на связке C++ (с шаблонами) и Питон. 3) мы думаем как уйти от шаблонов, но пока ничего кроме кодогенератора (на питоне) в голову не пришло - да и там шаблоны остануться...

простите, но в качестве обоснования почему Вы выбрали С++ почему он для решения Ваших задач лучше прочих языков эти факты не годятся

И я пока не собираюсь учить какие то другие ЯП и расширять кругозор

ну и не учите - мне то что? я Вас к этому не подталкиваю и не агитирую

Считаете что можно сделать лучше?

считаю что Вас не в ту степь занесло :)

«обсуждать архитектуру - не конкретные задачи решать»

мнение дилетанта в области проектирования систем, так и запишем :)

У Вас какое то извращенное понятие идеи шаблонов. В любом случае будет раскручиваться и использоваться конкретная реализация, просто внутри С++ компилер делает это сам, а тут его надо попросить (одна строчка, это немного, тем более что из питон и той писать не надо при правильной системе сборки).

Вы и правда не видите разницу между автоматической генерацией реализации средствами компилятора и деланием того же самого ручками?

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

бред :) откройте для себя наследование, которые Вы сейчас описываете, называя почему-то шаблонами

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

бред :) откройте для себя наследование, которые Вы сейчас описываете, называя почему-то шаблонами

Да? Ну вот Вам пример контейнера list из stl - это шаблон вроде? Вроде позволяет порождать семейство (множество) классов списков для различных типов. Откройте ка мне, жалкому дилетанту, как сие можно сотворить на С/С++ при помощи наследования без шаблонов (вариант с дефайнами я сам знаю).

Вы и правда не видите разницу между автоматической генерацией реализации средствами компилятора и деланием того же самого ручками?

А Вы и правда считаете, что строка в .i файле

%template (list_int) list<int>;

есть создание класса списка целых чисел ручками???

А как Вам понравится констуркция в Питон Vctr(1,2,3, pi, sqrt(2) ) - создает C++ объект (на основе параметризованного класса) - вектор в пятимерном декартовом пространстве, при этом инстанцирование классов и импорт соответствующих модулей производится при необходимсот и автоматически? Где здесь ручки? И у кого из нас сейчас бред? Ну почитали хоть мануал по свигу внимательное, е-мое... для профессионала Вы как то странно себя ведете;-)))))))))))

Тэкс... lapack значит... в огороде бузина а в киеве дядька. Если предметно - aivlib и lapack сравнивать нельзя, так как они предназначены для совершенно разных задач. Если для Вас все численное моделирование сводится к решению задач линейной алгебры - там вроде кто то кому то предлагал расширить свой кругозор...

Выбор связки C++ и Python для описанных задач основан на скромном 12-ти летнем личном опыте и примерно на 50ти летнем опыте нашей рабочей группы (из ИПМ им МВ Келдыша РАН) в области численного моделирования. Из опять таки скромного личного опыта эта связка обспечивает максимально возможную производительность кода и максимально возможную скорость разработки. Лично я сотрудничал с довольно большим количеством рабочих групп как у нас, так и за рубежом, и не видел ни у кого более эффективной архитектуры (у кого то такая же, у кого то Python + Fortran напр - отчасти дело вкуса, отчасти определяется спецификой конкретной задачи). Более подробные аргументы приведены например в статье, на которую я давал ссылку выше (в самом начале), если интересутесь мнением дилетанта можете почитать.

Почему именоо С++ - потому что оно позволяет с одной тстороны делать очень низкоуровневые вещи, с другой писать очень высокоуровневый код. Кроме того под С++ очень хорошие компиляторы. ЯЗык с огромным количеством недостатков, но ничего лучше я пока не видел (хотя и смотрел).

Вообще забавная дискуссия..

- Кто как строит и из чего?
Д (дилетант): - ну мы вот строим высокие такие штуки из напряженного железобетона...
ХП (хор Профессионалов): - Да вы что, это ж неудобно, железо ж ржавеет! Есть много других вариатов, вот там лиственница скажем..
Д: Ну нам удобно, у нас вот комплекс антикоррозийных мер, катодная защита...
ХП: бред... катодная защита от удара молний! Неудобно так делать, ржавеет!
Д: Да не ржавеет ничего, вон мы построили самую высокую телевышку, и стоит себе, и строить было очень удобно, а вам так из лиственницы слабо?
ХП: Нет, это все не аргументы... Почему именно железобетон? Посмотрите, вон из лиственницы свам в Венеции - в принципе не ржавеет и никакой защиты не надо! Вам учится надо...

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

> Почему только большинство актуальных вещей пишется именно дилетантами

В какой реальности?

P.S. SWIG говно.

В окружающей. Профессионалы написали виндовс;-)

SWIG не большее г-но, чем фортран - но тем не менее на фортране писали, пишут и будут писать. Ни разу не аргумент.

>>> Почему только большинство актуальных вещей пишется именно дилетантами

В какой реальности?

В окружающей. Профессионалы написали виндовс;-)

Иии... что? Или ты знаешь, какую задачу ставили этим профессионалам? Насколько я помню Кастер, перед NT ставилась задача завоевания рынка. Задача бестяще выполнена.

SWIG не большее г-но, чем фортран - но тем не менее на фортране писали, пишут и будут писать. Ни разу не аргумент.

Как раз то, что «писали и будут писать» - это не аргумент. Если есть выбор, то я бы дважды подумал, прежде чем использовать SWIG. Впрочем, я профессионал %)

Ну ес-но. Дело профессионалов - думать и завоевывать рынки. Мы дилетанты куда скромнее - нам бы сделать так, что б работало;-))))

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

Меня всегда умиляло отношение профессионалов к нам, дилетантам...

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

Почему только большинство актуальных вещей пишется именно дилетантами ума не приложу - видимо они лучше разбираются в предметной области?;-)

обоснуйте

> бред :) откройте для себя наследование, которые Вы сейчас описываете, называя почему-то шаблонами

Да? Ну вот Вам пример контейнера list из stl - это шаблон вроде? Вроде позволяет порождать семейство (множество) классов списков для различных типов.

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

Откройте ка мне, жалкому дилетанту,

не стоит отчаиваться комиссар Жюв :)

как сие можно сотворить на С/С++ при помощи наследования без шаблонов

Легко - абстрактный базовый класс определяющий интерфейс и иерархия классов реализующая данный интерфейс, как вариант. Скажу более того, шаблоны не дадут Вам адекватной замены данного решения (там где его применение обосновано). И в этом вопросе со мной согласен г-н А. Александреску и, как мне помнится, некоторые другие господа, например С. Мейерс.

//остальное завтра - спать хочется

> Вы и правда не видите разницу между автоматической генерацией реализации средствами компилятора и деланием того же самого ручками?

А Вы и правда считаете, что строка в .i файле

%template (list_int) list<int>;

есть создание класса списка целых чисел ручками???

да, конечно, потому что для того чтобы сделать то же самое с double придётся пересобирать библиотеку

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

А как Вам понравится констуркция в Питон Vctr(1,2,3, pi, sqrt(2) ) - создает C++ объект (на основе параметризованного класса) - вектор в пятимерном декартовом пространстве, при этом инстанцирование классов и импорт соответствующих модулей производится при необходимсот и автоматически?

и каким образом питон это делает? расскажите плиз, а то у меня стойкое подозрение что для осуществления такой операции компилятор С++ нужен

Тэкс... lapack значит... в огороде бузина а в киеве дядька. Если предметно - aivlib и lapack сравнивать нельзя, так как они предназначены для совершенно разных задач. Если для Вас все численное моделирование сводится к решению задач линейной алгебры - там вроде кто то кому то предлагал расширить свой кругозор...

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

итак, напоминаю, Ваши слова:

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

считаю что библиотеку привёл, написана не на С++, область применение более или менее та же (и не надо про различия численного моделирования и линейной алгебры - мы здесь не математические подходы, а реализацию на ЯП обсуждаем), шаблонов нет, читаемо... осталось Вам с «бааальшим» интересом посмотреть

более того, гляньте вот сюда, если разберётесь - тоже поди интерес проявится

чтобы у Вас не оставалось сомнений - разговор идёт не о том что у Вас там что-то не так, а о том что Ваши безапелляционные заявления по поводу С++ не имеют под собой никаких оснований

Выбор связки C++ и Python для описанных задач основан на [..]

верю, верю, ничего против не имею :) но другие люди выбирают по другим критериям и другие связки и ничего - тоже работает

нашей рабочей группы (из ИПМ им МВ Келдыша РАН)

а вот ты поди ж - коллега :)

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

1. разговор не идёт про архитектуру приложения, и тем более не про её эффективность, откуда Вы эту архитектуру тащите постоянно? напомню: обсуждаются применяемые инструменты

2. то что Вы что-то не видели не может считаться доказательством отсутствия оного, считал что это должно быть очевидно

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

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

*SURPRISE*

конечно лиственница не используется - дороговато, но тем не менее

и раз уж Вы подняли данную тему, считаю что человек сказавший:

«обсуждать архитектуру - не конкретные задачи решать»

ни разу не занимался проектированием (и обсуждением) реальной архитектуры хоть сколько-нибудь сложного приложения

> я вот хоть убей не понимаю с чего Вам пришло в голову называть себя дилетантом, но видимо что-то давит

Ааабсолютно ничего не давит, более того - я себя не считаю программистом (когда то считал, но давно). Ну сами ж говорите, терминология хромает...

как сие можно сотворить на С/С++ при помощи наследования без шаблонов

Легко - абстрактный базовый класс определяющий интерфейс и иерархия классов реализующая данный интерфейс, как вариант...

Вы, коллега, не путайте пожалуйста полиморфизЪм с параметризацией. То, что Вы предлагаете, ни разу не замена, потому как придется для КАЖДОГО типа ячейки писать список практически заново. А здесь один параметризованный класс создает семейство (множество - как хотите называйте) списков для разных типов ячеек. Можно конечно к параметризованному лкассу общего абстрактного прелдка прикрутить, я так по молодости развлекался - но в данном случае ненужно..

С гг-ми А и М я не знаком, но у меня сильное подозрение что Вы у них чего то не так поняли. Могу привести цитату и из Б.Страуструпа:

R.14 ШАБЛОНЫ ТИПА
R.14.1 Шаблоны типа
Шаблон типа определяет целое семейство типов или функций.

Если мы и правду коллеги, могу предложить Вам походить ко мне на кафедральный спецкурс «Совр технологии числ моделирования» для студетов МФТИ, а то Вас явно чему то не тому учили;-))))))))

> Ну ес-но. Дело профессионалов - думать и завоевывать рынки.

Ну в общем да. Я, правда, не тоб этих профессионалах говорил, но есть и такая профессия - рынки завоевывать.

Мы дилетанты куда скромнее

Показная скромность - это тоже вид чванства.

На мой дилетантский взгляд любое работающее г-но лучше неработающего слитка золота.

А на мой дилетантский взгляд, никто (кроме тебя, возможно) не сравнивал работающую программу с неработающей.

> да, конечно, потому что для того чтобы сделать то же самое с double придётся пересобирать библиотеку

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

А как Вам понравится констуркция в Питон ...

и каким образом питон это делает? расскажите плиз, а то у меня стойкое подозрение что для осуществления такой операции компилятор С++ нужен

Ес-но нужен. Но это не мешает.

считаю что библиотеку привёл, написана не на С++, область применение более или менее та же (и не надо про различия численного моделирования и линейной алгебры - мы здесь не математические подходы, а реализацию на ЯП обсуждаем)

НЕ ТА ЖЕ НИ РАЗУ. Если мы и правда коллеги, Вы должны чувствовать разницу между решением задач линейной алгебры и решением систем уравнений в частных производных при помощи явных численных схем. Что касается ЯП - мы делаем конкурентов благодаря локально-рекурсивным нелокально-асинхронным алгоритмам. Эти алгоритмы НЕВОЗМОЖНО РЕАЛИЗОВАТЬ НА ФОРТРАНЕ БЕЗ ПОТЕРИ ЭФФЕКТИВНОСТИ. И на паскале невозможно. Допускаю что есть ЯП на которых это возможно, но я о них не разу не слышал. За ссылку спасибо, но я не интересуюсь линейной алгеброй. ВООБЩЕ.

> 1. разговор не идёт про архитектуру приложения, и тем более не про её эффективность, откуда Вы эту архитектуру тащите постоянно? напомню: обсуждаются применяемые инструменты

Изначально разговор шел именно о критериях эффективной архитектуры, посмотрите выше что ли...

2. то что Вы что-то не видели не может считаться доказательством отсутствия оного, считал что это должно быть очевидно

Буквально на днях обсуждали обзор наиболее распространенных в мире кодов для моделирования плазмы. Применяемые в них ЯП: С++, fortran, Python. Может еще чего то было, типа явы вместо питона, не помню точно. Вы можете считать все что угодно, но никто (из тех кто добился каких то результатов в этой области), не пользуется Хаскелем или скажем О'Камлем. Для меня это аргумент. Возможно со временем появяться ЯП более подходящие (давеча аргументы были за OpenCL), но пока что нет.

считаю что человек сказавший:

«обсуждать архитектуру - не конкретные задачи решать»

ни разу не занимался проектированием (и обсуждением) реальной архитектуры хоть сколько-нибудь сложного приложения

Поначалу прочел и аж дух захватило - чем же мы по средам у доски тогда занимаемся??? Неужели наши приложения такие простые?????? Но потом успокоился - наверное меня не интересует мнение человека, путающего параметризацию и полиморфизм, урчепы и линал, проявляющего склероз и явный алогизм мышления... даже если у него одна звездочка на ЛОРе;-))))))))

>> На мой дилетантский взгляд любое работающее г-но лучше неработающего слитка золота.

А на мой дилетантский взгляд, никто (кроме тебя, возможно) не сравнивал работающую программу с неработающей.

Классно.Тогда приведи пожалуйста как профи пример пакета, кторый для связки Питона и С++ лучше чем СВИГ. Без стеба, правда интересно, а то СВИГ местами и самому не нравится.

На ЛОРе конечнго принято орать - г-но.. ф топку... но ИМХО это неконструктивно. КОнструктивно говорить - «это г-но, потому что при решении таких то и таких то задач оно не может то то и то то, в то время как вот эта штука может».

> Тогда приведи пожалуйста как профи пример пакета, кторый для связки Питона и С++ лучше чем СВИГ

Эх. Тебе же говорят - «когда есть выбор». А если надо связывать именно Си++ и именно Python - я ничем, кроме SWIG, не пользовался (хотя другие средства есть - как минимум Boost.Python). И, если мне теперь понадобится связывать скриптовый и компилируемый в натив языки (заметь - не обязательно Python и Си++), я сначала посмотрю на что-то другое, не SWIG. И скорее всего, это будет родной FFI скриптового языка.

>> как сие можно сотворить на С/С++ при помощи наследования без шаблонов

Легко - абстрактный базовый класс определяющий интерфейс и иерархия классов реализующая данный интерфейс, как вариант...

Вы, коллега, не путайте пожалуйста полиморфизЪм с параметризацией.

о, коллега, я вовсе не путаю, некоторые разработчики, например, и вовсе чураются использования шаблонов, но тем не менее пишут нормальные программы - разные подходы, что тут сделаешь :) да, собственно говоря, сами шаблоны в нормальном виде начали появляться лет 15 назад, неужели до того жизни «на марсе» не было?

То, что Вы предлагаете, ни разу не замена, потому как придется для КАЖДОГО типа ячейки писать список практически заново.

ничего страшного, если всё правильно сделать - оверхеда практически не будет

С гг-ми А и М я не знаком, но у меня сильное подозрение что Вы у них чего то не так поняли.

цитирую А. Александреску по книге «Современное проектирование на С++», стр. 34:

Стратегии позволяют генерировать проекты, комбинируя варианты, не вникая в подробности их внутреннего устройства. [..] Разумеется, свойства стратегий делают их неудобными для динамического связывания и бинарных интерфейсов, поэтому, по существу, интерфейсы и стратегии дополняют друг друга, а не конкурируют.

//кстати, если Вы не знакомы с данной книгой - весьма рекомендую

собственно, сам тезис подтверждает библиотека stl (да и boost иже с ней) - все реализации распространяются через заголовочные файлы

Если мы и правду коллеги, могу предложить Вам походить ко мне на кафедральный спецкурс «Совр технологии числ моделирования» для студетов МФТИ, а то Вас явно чему то не тому учили;-))))))))

а я, знаете ли, с удовольствием, правда я не то чтобы математик, серьёзно последний раз это было лет 10 назад :) но походил бы с удовольствием

а когда Ваш спецкурс начинается? (предлагаю обсуждение по данной проблеме перенести в jabber, e-mail или в real life)

приведи пожалуйста как профи пример пакета, кторый для связки Питона и С++ лучше чем СВИГ. Без стеба, правда интересно, а то СВИГ местами и самому не нравится.

в практическом применении мне больше нравится SIP, хотя принцип тот же самый

следует сказать, что SIP'ом обёрнут весь Qt (проект PyQt)

Гы... с этого надо было начинать;-) Меня в свиге долбит три вещи:

1) здоровые обертки (компилятся долго);

2) довольно странная система контроля типов отвечающая в частности за перегруженные функции (при совместном юзании нескольких so-шек она иногда лажает и не узнает объект созданный в одной so-шке и пихаемый в другую so-шку);

3) ряд ограничений на хидеры C++ (валится на вложенных шаблонах и сложных константных вычислениях).

Но зато он двольно просто проводит связывание. Boost.Python толком не смотрел, но гляну, спасибо.

Принцип Калашникова: «Избыточная сложность — это уязвимость»

Наверно поэтому его пистолет-пулемёт метко стреляет только в режиме «пистолет» (одиночными), а в режиме «пулемёт» (очередями) может попасть только в стену, и то — с близкого расстояния. :))