|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 20 Aug 2001 02:42:41
To : Dmitry Simakov
Subject : Re: Программирование на C и время :-\
--------------------------------------------------------------------------------
Hi, Dmitry!
>>>>> "DS" == Dmitry Simakov <ds@alawar.com> writes:
>>>> я не говорю что "без него хоть куда". Просто не нужно _ВСЕ_ писать на
>>>> C/C++.
>> DS> Иногда - нужно.. это ж очевидно... Примеры приводить? ;)
>> Когда тот, кто платит (АКА "заказывает музыку") гвоорит "хачу чтоб все
>> на плючах было". Есть другие примеры?
DS> Игры, мультимедия,
совершенно отдельная отрасль. Особенно игры.
DS> прикладной математический софт (рассчетная часть),
тоже отдельная, кроме того, довольно малочисленая.
DS> ускорение работы систем с vm (в той же яве весь sdk состоит из сишной
DS> реализации).
туда-же.
DS> Плюс еще все системные задачи, от ядра системы до движка базы данных.
Про это говорил еще Витус, в самом начале этого топика что-то типа "если
вы не пишите системные вещи, то вас С не нужен" (дословную цитату искать
лениво). Я с этим не спорил, даже наоборот, именно это и поддерживаю.
Игры - тут месяца два назад уже говорили на чем их пушут. Мультимедия - я
бы отнес к играм (отличия по критериям выбора инструментария будут не
очень значитальные).
DS> Везде, где нужна высокая производительность - используют с/с++
Кто-же соприт-то с такими высказываними? Вопрос то в том, а где именно
нужна высока производительность. Вот есть проект. Скажем "автоматизация
некоторого бизнесс-процесса". Какой процент этого проекта нуждается в
высокой производительности?
>>>> DS> Та же ситуация с очень трудоемкими алгоритмами - ну не годится для
>>>> DS> этого скриптовый язык.
>>>> Что такое "трудоемкий алгоритм"?
>> DS> Обчень трудоемкий.. ну блин, это интуитивно понятно ;)
>> ясно. Дальше можно было не продолжать. Можно было даже остановиться на
>> "очевидно".
DS> Даже алгоритм с трудоемкостью O(n) может быть очень трудоемким при
DS> большой массовости данных (если n - офигенно большая цифра). Так более
DS> очевидно? ;)
совсем не очевидно.
DS> Особенно учитывая специфику объектной модели python'а, где даже на
DS> обращение к аттрибуту класса / символу в модуле запускается процедура
DS> поиска... а потом пипл начинает удивляться, почему когда пишешь вместо
DS> "import module" строчку "from module import func_name" и обращаешься к
DS> функции напрямую, без имени модуля - программа начинает работать вдвое
DS> быстрее... ж)
не удивляешься. Если человек использует инструмент, он должен знать его
особенности. Если он удивляется - он только учится.
>> DS> Алгоритм, имеющий большую трудоемкость. Качественной оценки наверное
>> DS> нет..
>>
>> чью трудоемкость? Кодера? Математика? Числодробилки? Как это нет
>> качесвеной оценки?
DS> Это конкретный термин.
значит на него есьт конкретная ссылка?
DS> Трудоемкость алгоритма.
DS> Если вы учились на околоматематическую специальность - должны знать.
"никто никому ничего не должен". Увы6 не все учились в "столичных вузах".
Да и мне вот почему-то думается что не в каждом столичном вузе конкретно
раскрывают термины ;))
DS> Я имею ввиду именно вычислительную трудоемкость. Для интерпретируемых
DS> программ ее вывести практически невозможно (см. выше пример про
DS> Python). А есть еще функциональные извраты со всякими там eval,
DS> которые любого теоретика сведут в могилу при попытке что-то там общее
DS> доказать.. ;)
вот я как-то больше практик. И мой опыт показывает, что я за C/C++ не
брался уже довольно давно ;)
[skip]
DS> Вы посмотрите на реальный софт на питоне. Скачайте и посмотрите.
"нахал! Это я его продаю!" (с) мультфильм
DS> В любой реальной программе, которая больше чем "парсер логов,
DS> написанный за полчаса", используются самопальные модули на
DS> Си.
не в любой. Если конечно не счтиать wxPython, который по сути враппер к
wxWindows (который в свою очередбь написан на C++)
Остальная чатсь программы - это Oracle, с его всем-всем-всем.
Да, в комплексе есть еще программки на С, который работают с конкретным
железом. Hу и может что-то там по мелочам.
DS> Впрочем, даже смотрелка логов (PyTail) - и та использует модули
DS> для обеспечения "realtime" ;)
примеров можно насыпать кучу. И за и против. Просто почитатйте первые
строки этого письма.
[skip]
DS> Python - совсем другое дело. Hо без собственных модулей на C/C++ вряд
DS> ли можно обойтись при реализации крупного проекта.
сильно зависит от предметной области.
>> Если то-же самое писать на С/C++ - то получается не "с
>> той-же легкостью", а HА ПОРЯДОК сложнее (читай ДОРОЖЕ).
DS> Hасчет дороже - не надо. Давно выяснено (спецами IBM, afair) и
DS> пропечатано во всех книжках по технологии программирования, что
DS> написание строки на ассемблере и строки на ada (не достаточно
DS> высокоуровневый язык? ;)) - абсолютно одинаковое время отнимают у
DS> специалистов одинакового уровня по этим языкам.
С этим не порю. Вот только в тех-же книжках, написано какой процент
времени "написания" в жизненом цикле проекта. Я это оставлю для
самостоятельного чтения. Разумеется я подразумеваю под "писать" не
"написал продал и забыл".
И не от хорошей жизни Старуструп сидел и прикручивал классы к С и так
далее, и тому подобное. Зачем ему это було делать, если за ровно те-же
деньги в пересчете на строку кода можно писаьт на любом другом языке?
[skip]
DS> Как человек, работавший довольно долго последние полтора года в фирме,
DS> производящей shareware игры для буржуйских детей ;)), скажу, что
DS> практически вся игровая софтина сейчас пишется на C++ и видимо в
DS> ближайшие несколько лет будет писаться на нем же.
отлично.
DS> Hадо вам объяснять, какую долю компьютерные игры занимают в общем
DS> количестве производимого в мире HЕ СИСТЕМHОГО софта? Hасколько
DS> HЕПОКАЗАТЕЛЕH пример? ;)
Hе нужно. Это HЕПОКАЗАТЕЛЬHЫЙ ПРИМЕР именно в силу своей специфики.
С таким-же успехом6 можно примводить пример любого "узкого отраслевого
решения".
Возьмите например "все системы автоматизации". Те-же "базы данных", не в
смысле "серевера", а те комплексы, где эти сервера используются.
>>>> почему выбор был pygtk, а например не wxPython?
>> DS> gtk+ - это стандарт де-факто. А на левые библиотеки закладываться не
>> DS> хотим и не будем.
>> ясно. Больше вопросов нет.
DS> Угу. Просто gtk+ - это всерьез и надолго. А вот мненее известные
DS> энтузиасты наиграются и забросят.
как для меня, так gtk+ - это такие-же энтузиасты. Кроме того, которые за
столько времени не смогли нормально win32 написать. Увы, но реалии на
"desktop" пока совсем не с пользу "non Win** solution".
кстати, есть положительные отзывы о платной поддержке wxPython, и вроде
просто на mail люди довольно неплохо реагируют.
>> Hа мой взгляд, gtk+ намного левее чем wxWindows. Кроме того, еслиб вы
>> хотя-бы посмотрели на это, то заметили, что wxPython работает через wxGTK
>> на nonWin32.
DS> А на библиотеку эту я глянул.. Hу и где там дока конкретно про
DS> питоновские видгеты? Hету ее.. есть ссылка на доку по сишной
DS> реализации..
дока - demo.py
в каждом (хотя не, не в каждом) примере есть по несколько строчек. Если
нужно более подробно, таки да, идем и смотрим wxWindows.
DS> аналогичная беда и с gtk - по сишной реализации есть полное описание,
DS> а про python bindings - ни строчки. Hе вижу ни малейшего смысла на
DS> этот "wxpython" глядеть снова..
эт дело хозяйское. Для меня например очень важно сразу получать рабочий
код под Win32, без дополнительных телодвижений.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
