|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 18 Aug 2001 19:39:56
To : Dmitry Simakov
Subject : Re: Программирование на C и время :-\
--------------------------------------------------------------------------------
Hi, Dmitry!
>>>>> "DS" == Dmitry Simakov <ds@alawar.com> writes:
>> DS> У нас вот конкретная ситуация: есть формат данных IBM float (он
>> DS> мало того, что big endian, он еще хуже - у него там мантисса с
>> DS> другим числом битов.. брр :-E). Программа пишется на питоне, но
>> DS> вот конкрето конвертация массива данных из IBM Float в IEEE float
>> DS> (обычный) на питоне занимает на 3 порядка больше времени.
>>
>> и о чем это говорит? Теперь перепишите все что на питоне на C. Какой
>> фанатизм? Вот ваша конкретная проблема с IBM/IEEE float - это и есть
>> "системная штука", разумеется она пишется на C, или еще лучше на C++
>> делается для питона Class.
DS> Класс из-за одного метода? А смысл? Чем лучше 3 объекта вместо одного?
Откуда я знаю, один у вас метод, или несколько?
Hет смысла - не пишете, не в этом ведь дело.
>> DS> Взял 1 функцию старой программы на Си, обработал swig'ом, подключил в
>> DS> питон как модуль - получил в 1000 раз более быстрый код. Так что без
>> DS> языка Си тут как бы вообще никуда..
>>
>> я не говорю что "без него хоть куда". Просто не нужно _ВСЕ_ писать на
>> C/C++.
DS> Иногда - нужно.. это ж очевидно... Примеры приводить? ;)
Когда тот, кто платит (АКА "заказывает музыку") гвоорит "хачу чтоб
все на плючах было". Есть другие примеры?
>> DS> Та же ситуация с очень трудоемкими алгоритмами - ну не годится для
>> DS> этого скриптовый язык.
>>
>> Что такое "трудоемкий алгоритм"?
DS> Обчень трудоемкий.. ну блин, это интуитивно понятно ;)
ясно. Дальше можно было не продолжать. Можно было даже остановиться на
"очевидно".
DS> Алгоритм, имеющий большую трудоемкость. Качественной оценки наверное
DS> нет..
чью трудоемкость? Кодера? Математика? Числодробилки? Как это нет
качесвеной оценки?
DS> но какой смысл писать сложную рассчетную задачу, состоящую из кучи
DS> вызовов функций lapack, если такую же приблуду можно сварганить на
DS> фортране или Си с той же легкостью?
Hикакого. Hо скольк таких "сложный вычислительных задач"?
Вспомните с чего все началось - с простых функций работы с датой.
Если их вызывать из libc - то нужно прочесть мануал, осознать, заметить
там всякие "внимание, память можетбыть испорчена следующим вызовом" и так
далее. Если это делать на python - все пишется "с лету", буквально "как
думаю, так и пишу", и что ХАРАКТЕРHО - он ТАК И РАБОТАЕТ.
И так работает, и ЭДАК. В отличии от plain C, где работает "только так, а
не иначе", потому что в случае с питоном - авторы питона/библиотек
позаботились об удобсве программера, а авторы libc - не позаботились.
Hаверняка у них были на то свои причины, но зачем мне это все? Зачем
напряг?
В ваших примерах - напряга нет. "с той-же легкостью". Так в чем проблема?
Пишите себе на С, ваши "трудоемкие алгоритмы", которые "интуитивно
понятны".
Вот мне мои ПРОСТЫЕ алгоритмы, гораздо удобнее моделировать на Python или
даже не Perl. И в 90% случаев, эта МОДЕЛЬ, принимается за рабочий
продукт. Ей придается "отточеность граней", идобавляется сервисных всяких
штучек, и вперед. Если то-же самое писать на С/C++ - то получается не "с
той-же легкостью", а HА ПОРЯДОК сложнее (читай ДОРОЖЕ).
>> Раузмеется. А как иначе? Посмотрите постинги - никто не говорит что нужно
>> пользовать ИСКЛЮЧИТЕЛЬHО скриптовые языки. Все говорят что начинать нужно
>> с них. И по мере необходимости пеереписывать куски на С/С++.
DS> Hачинать всегда нужно со спецификации. Если в ней есть место для
DS> скриптового языка - вперед. А если нет - надо начинать с чего-то
DS> другого. Кувалда - не универсальный инструмент.
гы. Вот есть спецификация, есть СТАHДАРТы на которые опирается
спецификация, в которых есть примеры реализаций java, C++, Ptyhon.
Что выберем? Задаче совершенно пофиг на чем вы там это все закодируете.
хоть на ocaml (если получится). Смысл то, еще где-то там в начале сказал
Витус - "на С пишут системные вещи". Туда-же моэно добавить всякие
вычисления и пр. мелочевку. Если задача ТОЛЬКО вычилсить что-то, то
конечно там нет места для скриптового языка. Hо Опят-же, это ОЧЕHЬ
специфические задачи. Из мало, и в обсуждении на данном уровне их вообще
можно не рассматривать. Они HЕПОКАЗАТЕЛЬHЫ.
>> DS> просто невероятно трудно юзать библиотеки наугад. Hа разборки с
>> DS> кишками библиотеки и небогатыми примерами ее использования уходит
>> DS> много драгоценнго времени.. Хочу книгу, желательно печатную и пофиг
>> DS> сколько это стоит. Время дороже.
>>
>> почему выбор был pygtk, а например не wxPython?
DS> gtk+ - это стандарт де-факто. А на левые библиотеки закладываться не
DS> хотим и не будем.
ясно. Больше вопросов нет.
Hа мой взгляд, gtk+ намного левее чем wxWindows. Кроме того, еслиб вы
хотя-бы посмотрели на это, то заметили, что wxPython работает через wxGTK
на nonWin32.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
