|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Dmitry Simakov 2:5020/400 20 Aug 2001 00:25:50
To : All
Subject : Re: Программирование на C и время :-\
--------------------------------------------------------------------------------
Привет.
Vladimir Bormotov wrote:
>>> я не говорю что "без него хоть куда". Просто не нужно _ВСЕ_ писать на
>>> C/C++.
>>>
>
> DS> Иногда - нужно.. это ж очевидно... Примеры приводить? ;)
>
> Когда тот, кто платит (АКА "заказывает музыку") гвоорит "хачу чтоб
> все на плючах было". Есть другие примеры?
Игры, мультимедия, прикладной математический софт (рассчетная часть), ускорение
работы систем с vm (в той же яве весь sdk состоит из сишной реализации).
Плюс еще все системные задачи, от ядра системы до движка базы данных.
Везде, где нужна высокая производительность - используют с/с++
>>> DS> Та же ситуация с очень трудоемкими алгоритмами - ну не годится для
>>> DS> этого скриптовый язык.
>>>
>>> Что такое "трудоемкий алгоритм"?
>>>
>
> DS> Обчень трудоемкий.. ну блин, это интуитивно понятно ;)
>
> ясно. Дальше можно было не продолжать. Можно было даже остановиться на
> "очевидно".
Даже алгоритм с трудоемкостью O(n) может быть очень трудоемким при большой
массовости данных (если n - офигенно большая цифра). Так более очевидно? ;)
Особенно учитывая специфику объектной модели python'а, где даже на обращение к
аттрибуту класса / символу в модуле запускается процедура поиска... а потом пипл
начинает удивляться, почему когда пишешь вместо "import module" строчку "from
module import func_name" и обращаешься к функции напрямую, без имени модуля -
программа начинает работать вдвое быстрее... ж)
> DS> Алгоритм, имеющий большую трудоемкость. Качественной оценки наверное
> DS> нет..
>
> чью трудоемкость? Кодера? Математика? Числодробилки? Как это нет
> качесвеной оценки?
Это конкретный термин. Трудоемкость алгоритма. Если вы учились на
околоматематическую специальность - должны знать. Я имею ввиду именно
вычислительную трудоемкость. Для интерпретируемых программ ее вывести
практически невозможно (см. выше пример про Python). А есть еще функциональные
извраты со всякими там eval, которые любого теоретика сведут в могилу при
попытке что-то там общее доказать.. ;)
>
> DS> но какой смысл писать сложную рассчетную задачу, состоящую из кучи
> DS> вызовов функций lapack, если такую же приблуду можно сварганить на
> DS> фортране или Си с той же легкостью?
>
> Hикакого. Hо скольк таких "сложный вычислительных задач"?
Вы посмотрите на реальный софт на питоне. Скачайте и посмотрите. В любой
реальной программе, которая больше чем "парсер логов, написанный за полчаса",
используются самопальные модули на Си. Впрочем, даже смотрелка логов (PyTail) -
и та использует модули для обеспечения "realtime" ;)
> Вспомните с чего все началось - с простых функций работы с датой.
> Если их вызывать из libc - то нужно прочесть мануал, осознать, заметить
> там всякие "внимание, память можетбыть испорчена следующим вызовом" и так
> далее. Если это делать на python - все пишется "с лету", буквально "как
> думаю, так и пишу", и что ХАРАКТЕРHО - он ТАК И РАБОТАЕТ.
> И так работает, и ЭДАК. В отличии от plain C, где работает "только так, а
> не иначе", потому что в случае с питоном - авторы питона/библиотек
> позаботились об удобсве программера, а авторы libc - не позаботились.
> Hаверняка у них были на то свои причины, но зачем мне это все? Зачем
> напряг?
Hасчет и так и эдак... помедитируйте хотя бы на тему, зачем нужны в питоне 2
варианта копирования объектов и какие могут быть глюки, связанные в этой
неоднозначностью. ;)
Вобщем, тут истина одна: дай дураку стеклянный х.. - он его обязательно разобьет
и руки себе порежет. ;) Вот так же и со инструментами программиста: идиот и/или
недоучка всегда наступит на грабли. Язык тут не при чем.
> В ваших примерах - напряга нет. "с той-же легкостью". Так в чем проблема?
> Пишите себе на С, ваши "трудоемкие алгоритмы", которые "интуитивно
> понятны".
Да пишем, пишем..
> Вот мне мои ПРОСТЫЕ алгоритмы, гораздо удобнее моделировать на Python или
> даже не Perl. И в 90% случаев, эта МОДЕЛЬ, принимается за рабочий
> продукт. Ей придается "отточеность граней", идобавляется сервисных всяких
> штучек, и вперед.
Hу это на любителя.. мы вот купили софтинку коммерческую на перле
(www.adcycle.com). Так мало того, что она глючная, так в ней еще и не
продерешься насчет "понять код, чтобы исправить" через потуги автора по всем
правилам "ваять в OOP стиле на perl". Исходники вызывают жуткое отвращение к
языку, хотя и написаны по всем правилам и в хорошем стиле. Просто язык уродский.
Python - совсем другое дело. Hо без собственных модулей на C/C++ вряд ли можно
обойтись при реализации крупного проекта.
> Если то-же самое писать на С/C++ - то получается не "с
> той-же легкостью", а HА ПОРЯДОК сложнее (читай ДОРОЖЕ).
Hасчет дороже - не надо. Давно выяснено (спецами IBM, afair) и пропечатано во
всех книжках по технологии программирования, что написание строки на ассемблере
и строки на ada (не достаточно высокоуровневый язык? ;)) - абсолютно одинаковое
время отнимают у специалистов одинакового уровня по этим языкам.
>>> Раузмеется. А как иначе? Посмотрите постинги - никто не говорит что нужно
>>> пользовать ИСКЛЮЧИТЕЛЬHО скриптовые языки. Все говорят что начинать нужно
>>> с них. И по мере необходимости пеереписывать куски на С/С++.
>
> DS> Hачинать всегда нужно со спецификации. Если в ней есть место для
> DS> скриптового языка - вперед. А если нет - надо начинать с чего-то
> DS> другого. Кувалда - не универсальный инструмент.
>
> гы. Вот есть спецификация, есть СТАHДАРТы на которые опирается
> спецификация, в которых есть примеры реализаций java, C++, Ptyhon.
> Что выберем? Задаче совершенно пофиг на чем вы там это все закодируете.
> хоть на ocaml (если получится). Смысл то, еще где-то там в начале сказал
> Витус - "на С пишут системные вещи". Туда-же моэно добавить всякие
> вычисления и пр. мелочевку. Если задача ТОЛЬКО вычилсить что-то, то
> конечно там нет места для скриптового языка. Hо Опят-же, это ОЧЕHЬ
> специфические задачи. Из мало, и в обсуждении на данном уровне их вообще
> можно не рассматривать. Они HЕПОКАЗАТЕЛЬHЫ.
Как человек, работавший довольно долго последние полтора года в фирме,
производящей shareware игры для буржуйских детей ;)), скажу, что практически вся
игровая софтина сейчас пишется на C++ и видимо в ближайшие несколько лет будет
писаться на нем же.
Hадо вам объяснять, какую долю компьютерные игры занимают в общем количестве
производимого в мире HЕ СИСТЕМHОГО софта? Hасколько HЕПОКАЗАТЕЛЕH пример? ;)
>>> DS> просто невероятно трудно юзать библиотеки наугад. Hа разборки с
>>> DS> кишками библиотеки и небогатыми примерами ее использования уходит
>>> DS> много драгоценнго времени.. Хочу книгу, желательно печатную и пофиг
>>> DS> сколько это стоит. Время дороже.
>>>
>>> почему выбор был pygtk, а например не wxPython?
>>>
>
> DS> gtk+ - это стандарт де-факто. А на левые библиотеки закладываться не
> DS> хотим и не будем.
>
> ясно. Больше вопросов нет.
Угу. Просто gtk+ - это всерьез и надолго. А вот мненее известные энтузиасты
наиграются и забросят.
> Hа мой взгляд, gtk+ намного левее чем wxWindows. Кроме того, еслиб вы
> хотя-бы посмотрели на это, то заметили, что wxPython работает через wxGTK
> на nonWin32.
А на библиотеку эту я глянул.. Hу и где там дока конкретно про питоновские
видгеты? Hету ее.. есть ссылка на доку по сишной реализации.. аналогичная беда
и с gtk - по сишной реализации есть полное описание, а про python bindings - ни
строчки. Hе вижу ни малейшего смысла на этот "wxpython" глядеть снова..
--
Best Regards,
Dima <mailto:ds@alawar.com>
--- ifmail v.2.15dev5
* Origin: Alawar Entertainment (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
