|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 28 Jan 2003 00:05:36
To : Valentin Nechayev
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Jan 27 10:45 03, Valentin Nechayev wrote to Zahar Kiselev:
VN>>> (Hе люблю я Питон, но...)
ZK>> Интересно - почему тебе можно не любить питон, а мне - нет? :-)
VN> Одно - не любить, другое - не признавать того, что это его
VN> преимущество по сравнению с C действительно есть.
А я вполне признаю. Hо не в задачах, связанных с обработкой поступающих
"снаружи" данных. В частности я бы сам не стал писать какую-нибудь
учетно-бухгалтерскую задачу на Си. Вот в таких задачах питонам и прочим
пресмыкающимся самое место.
ZK>> критерий - это простота внесения изменений. Сам понимаешь кого проще
ZK>> найти - программиста на Си или на Питоне.
VN> А сколько времени этот программист потом будет писать объёмный по
VN> функциональности кусок? А отлаживать?
Я думаю - столько же, сколько придется искать программиста на Питоне.
ZK>>>> Естественно предположить, что в системе, разные детали которой
ZK>>>> написаны разными людьми, это выражено еще больше. В чем я и
ZK>>>> убедился на примере с капризом линкера.
VN>>> Угу. Давно хочу увидеть что-то похожее на COM.
ZK>> Я плохо себе представляю что такое COM и с чем его едят. И главное -
ZK>> для каких задач его "едят".
VN> Винда. То же что OLE и ActiveX. Общий метод взаимосвязи компонент в
VN> околообъектном духе. С общей на всех calling convention.
Да уж... Чайник я в этом. Слово OLE я слышал - обычно с матерным продолжением и
применительно к файлу от Ворда, в который "встроили OLE объект", после чего файл
перенесли на другую машину и там он нормально не читается:)
VN>>> И чтобы были решены все грабли с динамической линковкой. Hапример,
VN>>> чтобы разные модули могли каждый видеть свою libc.
ZK>> И как это использовать? Как средство собирания бутербродов из кусков
ZK>> кода, написанных в разное время и под разные версии системы? Будет ли
ZK>> такой вариант решения проблемы совместимости вообще работоспособен?
VN> Вполне.
Тебе виднее. Вот уж это точно не для простых смертных.
ZK>> Может лучше все же подогнать код под имеющуюся в системе libc? Это ведь
ZK>> один раз делать придется, а ловить глюки упомянутого тобой хитрого
ZK>> подхода можно дооолго.
VN> Это придётся не делать один раз, а пересобирать каждые полгода под
VN> новый апгрейд системы, причём без шанса пройти этот процесс безглючно.
VN> Обязательно где-то полезут грабли...
Я думаю, что если посильнее надавить на разработчиков libc, чтобы поменьше
проявляли инициативы и строже соблюдали стандартизованный интерфейс - то глюков
не будет. Сколько лет уже libc существует - что там еще можно менять и зачем? Да
еще так, чтобы несовместимость "снаружи" видно было.
Видел когда-нибудь как "одной командой" собираются программы на Аде, даже если
их делали на другой системе и с другим компилятором?
Так что вопрос скорее в технической дисциплине.
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.1
* Origin: Остров Большой Березовый: http://birch-island.spb.ru (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
