Ответ на »сообщение 2784« (Сергей Перовский)
___________________________

И пока этих идей нет, стучать по клавишам бесполезно...

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

Ответ на »сообщение 2783« (Сергей Перовский)
___________________________

Всем советую: если вам предлагают ТЗ на половинке листа бумаги, увольнятся нужно сразу - дешевле обойдется. Слава богу, работа теперь меня сама ищет.
Слишком простой путь, хоть и весьма разумный. Но мы не ищем легких путей :) К тому же не всегда вот так просто уволиться (подставляются и другие люди).

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

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

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

Ответ на »сообщение 2780« (Руслан Богатырев)
___________________________
>>>Нужны нетривиальные идеи усиления игры программы в миттельшпиле
И пока этих идей нет, стучать по клавишам бесполезно...
А сделать оболочку для хранения и отображения позиции не проблема, достаточно знать шахматные правила.
Да и написано их не мало.
Так что осталось "всего навсего" подставить функцию оценки позиции.
Между прочим, я считаю, что наиболее мощные идеи были заложены в Пионер, разработанный Ботвинником - это к вопросу о том, что шахматисты не нужны.
У него не было таких вычислительных ресурсов, как у конкурентов, но те, что были, использовались очень эффективно.

Ответ на »сообщение 2778« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2774« (Сергей Перовский)
___________________________

А пример можно? Просто интересно, в каких областях можно написать что-то путное не разбираясь в этом предварительно.

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

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

...А сам класс является метаклассовой константой, которую можно присваивать метаклассовым переменным.

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

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

...А сам класс является метаклассовой константой, которую можно присваивать метаклассовым переменным.

Ответ на »сообщение 2777« (Сергей Перовский)
___________________________

И что, без шахматистов в команде?

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

Ответ на »сообщение 2711« (AVC)

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

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

Ответ на »сообщение 2774« (Сергей Перовский)
___________________________

А пример можно? Просто интересно, в каких областях можно написать что-то путное не разбираясь в этом предварительно.

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

Ответ на »сообщение 2775« (Руслан Богатырев)
___________________________
И что, без шахматистов в команде?