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

[Vladimir Prus]

On Tuesday 21 December 2004 11:41, Fr. Br. George wrote:

> > Затем, чтобы не думать, что существующие в Unix инструменты идеальны и
> > ничего менять не надо. Они не идеальны, и как минимум, это надо знать.
> > Конечно, как максимум надо пытаться их улучшить, но на это не у всех
> > хватит
> > времени/терпения/знаний.
>
>  Кто-то говорил, что они идеальны? Они чудовищны! Допотопны!
> Переписывать надо буквально всё, начиная от libc, libX11, и заканчивая
> KOM и прочим. Но это -- инструменты. А как должен выглядеть современный
> -- пускай неидеальный -- инструмент, не знает никто. И отчасти в этом
> повинно повальное увлечние конструкторами, которые только схематизируют
> пройденное, не открывая нового.

Мне кажется, это не очень точно. Вряд ли можно ожидать грандиозного скачка, 
вроде среды разработки, которой на русском языке можно говорить что делать.
Поэтому все развитие --- это не очень грандиозные, но важные детали. Удобный 
броузер документации, удобная работа с version control и так далее.

Самый банальный пример. В С++ если exception не ловится, то выполнение 
программы завершается. B gcc 3.3 это кончается сообщением "aborted". В 3.4 
--- более менее понятное сообщение. Мелочь, но из-за нее не нужно лишний раз 
запускать отладчик.

.......

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

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

>  Мужик даже про Design Patterns не знал. А ведь для описанного
> способа DP -- это как операторы для процедурного ЯП. 

Ehm.... без процедурного кода все равно ничего не сделать.

- Volodya