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

У нас гайдлайн - брать все из Qt, а не из STL. Зло вымещаю :) В остальном вроде все ок.

Вот с такой чертой характера в Германии было бы сложно. Тут очень любят "средняк". Не знаю правда как в Ирландии.

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

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

Я бы не сказал, что в Германии любят "средняк". Здесь, как и везде, не любят умников, которые много балаболят, но мало делают.
Что же касается интервью, то я лично согласен с Джоелом -

Что же касается Мурра, то по его постингам на форуме у меня есть определённые сомнения насчёт "Get things done"...

Murr get things done... and in time.
Ну если не сделает - никто в компании не сделает за приемлемое время.

>>В живых проектах с объемом кода более 15-20Мб в любом случае будет иметь место ООП концепция, а различия будут определятся доступным инструментарием.
пять балов.
Для тех кто вс╦ ещ╦ сомневается: ваще язык програмирования не играет роли. ооп концепт не имеет с языком ничего общего. в литературе эта тема широко освещена.

>> У нас гайдлайн - брать все из Qt, а не из STL. Зло вымещаю :) В остальном вроде все ок.
вправду гадлайн.

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

....ооп концепт не имеет с языком ничего общего.
Концепт да, а вот реализация...
------
А что с реализацией? На чем надо - на том и реализуется, в соответствии с имеющимися возможностями.
К примеру, годике этак в 1999, когда меня сильно прижало по срокам, использовал ООП-концепцию при...
только не падать... программировании на ASP... и ничего - все работало как должно... все 5 Мб активного
кода написанные за неполные три месяца... Разумеется, никаких виртуальностей и прямого наследования
не имелось, но это уже детали реализации...

На всем чем попало мне кажется не получится. И думаю мы еще немного по разному термины трактуем.
Ну допустим сделал я дизайнчик, тама полно классов. Надо их реализовывать. А в реализации ни наследования ни полиморфизма. Че тогда делать? Кастрировать дизайн или делать все через жопу?
Можно конечно, найти какой-то компромисс, который назвать объектным, но у меня просто не повернется язык это сделать.

А в реализации ни наследования ни полиморфизма.
------
Ну нету. Так что, и реализовать невозможно? Жили же как-то несколько десятков лет без наследования и полиморфизма... :)
Кастрировать дизайн или делать все через жопу?
------
Ну если написание и поддержка ап-то-дэйт одного "метода" через примитивный набор switch-case-case (при отсутствии указателей на функции) есть "делать через жопу", то - "тады ой...". :)

\Жили же как-то несколько десятков лет без....
Да и без Интернета жили тоже поболе, А забери его счас от тебя....
Реализовать то можно, а зачем?
\Ну если написание и поддержка ап-то-дэйт одного "метода" через примитивный набор switch-case-case
Я тута по быстрому примерчик набросал, может и с ошибками, но как тест пойдет. Не знаю как это на С красиво сделать. Не только что бы работало, но и что бы любая обезъяна могла править и добавлять.
Может покажешь как твой волшебный свитч это все сдеалает. И что бы компайлер ругался когда четкую херню порешь. Типа b.Store в майне вызвать. И строки хочу прибавлять а += "Тест".
И "стреам" куда хочу. Да много еще чего . Правда виртуального наследования не прошу у золотой рыбки, тъфу котика.

class A
{
	public:
		A(string Name) {m_Name = Name}
		virtual bool Compare(const a& Cmp) const = 0;
		virtual string GetName() const {return m_Name; }
		StoreToFile(string FileName) 
		{
			...
			Store(FileStream);
		}
	
	protected:
		virtual stream& Store(stream& DataStream)
		{
			DataStream << m_Name;
			return DataStream;
		}
	
	private:
		string m_Name;
};
class B: public A
{
	public:
		B(string Name, int Code): A(Name), m_Code(Code) {}
		static bool operator==(const B& Cmp1, const B& Cmp2 ) const
		{
			...
			Ret = Cmp1.Compare(Cmp2);
			...
		}
		virtual bool  Compare(const a& Cmp) const
		{
			...
		}
		int GetCode() const {return m_Code; }
	protected:
		virtual stream& Store(stream& DataStream)
		{
			A::Store(DataStream);
			DataStream << m_Code;
			return DataStream;
		}
	public;
		int m_Code;
};
class C: public B
{
....
		virtual string GetName() const {... }
}
main()
{
	A* pa = NULL;
	B b("Test",1);
	C c("Test","125");
	pa = &c;
  if(b == c)
  {
....
     x = pa->GetName();
  }
}

Может покажешь как твой волшебный свитч это все сдеалает.
------
В чистом Си это сделается точно так же, как и в С++ - передачей методу дополнительного параметра.
Единственное отличие - параметр передается явно, а не скрыто как в С++. Т.е. вместо
b->GetName() будет GetName(b).
Даже Switch-Case не нужен.
Выше Я (вроде) писал, что Switch-Case нужен там, где нет укзателей на функции.
Не знаю как это на С красиво сделать.
Не только что бы работало, но и что бы любая обезъяна могла править и добавлять.
-----
Реализуешь пару раз подобное на чем-нибудь - помешь что не намного сложнее, чем на плюсах.
И Я говорю вполне серьезно - для реализации в Си там всего то один дополнительный массив указателей на функции,
ну а где указатели недоступны - Switch-Case.
И что бы компайлер ругался когда четкую херню порешь.
Типа b.Store в майне вызвать.
И строки хочу прибавлять а += "Тест".
И "стреам" куда хочу.
Да много еще чего
------
Спроектируй, плс, одну простую и полезную вещь - пусть выдает 6 чисел... которые выпадут в следующем розыгрыше... :)
Ну а то что ты хочешь - реализуемо средствами Си и дисциплиной программирования.

З.Ы. В другой раз попробуй не подменять релизацию ООП-концепта в каком-то языке требованиями выполнить копирование реализации концепта в другом языке.

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

Если операции с объектами подменять чем то другим то получится бардак.
-----
Получится не бардак, а имплементация ООП-концепта имеющимися средствами используемого языка.
Передавать надо будет любой "объект" из иерархии, значит тип прийдется два раза \туда и обратно\ принудительно преобразовывать.
-----
И это так трудно? VOID укзатель "кастировать" к какому то типу... Ну или добавить небольшой оверхед к реализации каждого объекта и получить хоть RTTY & dinamic_cast...
То бишь в любом случае мы должны что то потерять при преоразовании и то что получится
------
Будешь удивлен, но в С++, который ты позиционируешь на место ООП-концепта, ты имеешь тоже самое. Для примера - реализуй концепцию C#-интерфейсов на С++ или наоборот - множественное наследование в С#...
я бы в лучшем случае назвал моделью объекта, но никак не объектом.
-----
См. п.1. и говори - реализация объекта.

\а имплементация ООП-концепта имеющимися средствами используемого языка.
кому как, при "неподходящем" языке для меня будет именно бардак.
\И это так трудно? VOID укзатель "кастировать" к какому то типу..
Опять таки, с какой стороны посмотреть. Любая дополнительная операция преобразования увеличивает уровень потенциальных ошибок. Да и проверить соответствие указатель-функуция можно будет в лучшем случае на этапе выполнения программы, что совсем не хорошо. Ты просто рассматриваешь проблемы с точки зрения возможности реализации, а меня еще интересует возможность использования в долгом теам проекте.
\Будешь удивлен, но в С++, который ты позиционируешь на место ООП-концепта, ты имеешь тоже самое.
Ну не совсем. Важно что есть база а все остальное просто полезные вкусности. Всегда будет чего то не хватать.
Кстати, шарп я люблю больше чем плюсы.
\См. п.1. и говори - реализация объекта.
Максксмум - моделирование объекта.

кому как, при "неподходящем" языке для меня будет именно бардак.
------
Бардак это не от языка. Бардак это от программера. Я вполне в состоянии устроить бардак в С++, Жабе, C# и писать нормально в Сях, VB, JS и полусотне реликтовых языков... все - от программиста.
дополнительная операция преобразования увеличивает уровень потенциальных ошибок
------
Разумеется. Потому 100% этих операций и доверили строить компилятору.
Да и проверить соответствие указатель-функуция можно будет в лучшем случае на этапе выполнения программы
------
Если забираться в дебри Сей, то там есть возможность указать, что функция доступна в пределах компилируемой единицы. Так что вывалится на этапе линковки. Но опять - ты подменяешь концеп реализацией в конкретном языке.
Ты просто рассматриваешь проблемы с точки зрения возможности реализации, а меня еще интересует возможность использования в долгом теам проекте
------
Это - без разницы, при наличии квалифицированного персонала. Проблема будет при низкой квалификации, но в этом случае проблеммы всеравно будут. :) Недели три назад был на интервью в небольшой конторе. Тамошний шеф честно признался - его людям проще писать на VB6, чем на VB/С#.NET... но в коде у них - полный бардак - спагетти в стиле Аксесса...
Важно что есть база а все остальное просто полезные вкусности.
------
Резервируешь в каждой реализации объекта пару специфических методов - Конструктор и Деструктор и отсутствие базы тебя более не беспокоит.
Всегда будет чего то не хватать.
------
Ну хоть с этим проблем нет - реализация всегда ограничена используемым языком.