[Uneex] Статья из Dr Dobb's

[Fr. Br. George]

On Tue, Dec 21, 2004 at 10:21:28AM +0300, Vladimir Prus wrote:
> On Monday 20 December 2004 20:11, Fr. Br. George wrote:
> 
> Отвечу только на самый важный вопрос.
> 
> > > Я имел в виду что как среда разработки Visual Studio ничем не хуже
> > > упомянутой связки и все (в разумном смысле "всего") что может упомянутая
> > > связка, тоже может.
> >
> >  Я всё-таки думаю, что у них разные и задачи, и спектр
> > возможностей. Повторяю, многое из того, что умеет vi, не умеет больше
> > никто. То есть: если сревнивать, то на каком-то урезанном подмножестве.
> > А тогда зачем сравнивать?
> 
> Затем, чтобы не думать, что существующие в Unix инструменты идеальны и ничего 
> менять не надо. Они не идеальны, и как минимум, это надо знать. Конечно, как 
> максимум надо пытаться их улучшить, но на это не у всех хватит 
> времени/терпения/знаний.
	Кто-то говорил, что они идеальны? Они чудовищны! Допотопны!
Переписывать надо буквально всё, начиная от libc, libX11, и заканчивая
KOM и прочим. Но это -- инструменты. А как должен выглядеть современный
-- пускай неидеальный -- инструмент, не знает никто. И отчасти в этом
повинно повальное увлечние конструкторами, которые только схематизируют
пройденное, не открывая нового.

	Год назад в Альте был на семинаре некий человек. Он показывал
нечто, напоминающее такой ``инструмент нового поколения''. К сожалению,
человек этот был Кулибин-самоучка, зато не до конца испорченный
конструкторами. В его обширной поделке было всё, начиная от дичайшего
хардкода, и до замечательной идеи, которая, собственно, и держит всю его
систему в рабочем состоянии.

	Идея такова: современные программы настолько сложны, что один
тлько текст (на процудерном объектно-ориентированном языке) не даёт
программисту полного представления о том, что же она такое. Программист
должен мыслить объектами (даже семинары видал по object thinking).
Поэтому во всех средах предусматриваются всякие дополнительные броузеры
-- классовый, отношений и т. д., кто во что горазд, см. UML. Но ведь
тогда основной носитель информации -- не код на C++, а _сам объект_. Ну
так давайте делать среду _редактирования объектов_, в которой всё будет
зачёсано на то, чтобы программист отлично представлял себе объектную
структуру, отношения и т. п. При этом _код_ на C++ -- это побочный
эффект, одна из множества форм _представления_ объекта. Этот код вообще
не используется в работе, так как работает сам созданный объект,
созданный вовсе не программированием на C++. Бонус: поскольку работающий
объект -- это не "промежуточный код", а _первичный_ носитель информации,
именно его и надо передавать друг другу на дискетке -- и он заработает в
любой исполняющей системе. Там народ редактирует работающие программы,
не останавливая их.

	Мужик даже про Design Patterns не знал. А ведь для описанного
способа DP -- это как операторы для процедурного ЯП. Но в его сторону
никто не думает пока. Пирамидки складывают.
http://www.altlinux.ru/index.php?module=press&action=showfull&newsid=65

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at po_cs_msu_su