|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 21 Aug 2001 20:12:34
To : Dmitry Simakov
Subject : Re: Программирование на C и время :-\
--------------------------------------------------------------------------------
On Sun, 19 Aug 2001 20:25:50 +0000 (UTC),
Dmitry Simakov <ds@alawar.com> wrote:
>Привет.
>
>Vladimir Bormotov wrote:
>>>> я не говорю что "без него хоть куда". Просто не нужно _ВСЕ_ писать на
>>>> C/C++.
>>>>
>>
>> DS> Иногда - нужно.. это ж очевидно... Примеры приводить? ;)
>>
>> Когда тот, кто платит (АКА "заказывает музыку") гвоорит "хачу чтоб
>> все на плючах было". Есть другие примеры?
>
>Игры,
Hа фиг. В большинстве игр плюсы просто не сдались. Разве что 3d
engine на них сваять.
Собственно, большАя часть игр именно так и пишется --
реализовывается свой 2/3d engine, под него скриптовый или язык --
и все затем пишется на этом языке.
Those who do not understand Unix are condemned to reinvent it, poorly.
Henry Spencer
>мультимедия,
Какая мультимедия? функция play_file в очередном engine? Да, это
на С. Хотя тоже не факт -- при правильном подходе это бы играл
отдельный бинарь на C, а функция могла бы быть хоть на /bin/sh.
Только это необходимо реализовать один раз, ну два, ну если плохо
пойдет -- 4 раза. И это ни в какой мере не прикладное
программирование.
>прикладной математический софт (рассчетная часть),
БОльшей части прикладного математического софта хватит
быстродействия интертрепатора в Mathematica, написанного на lisp.
Как и практически любого другого.
>ускорение
>работы систем с vm
Глуюоко системная вещь.
>(в той же яве весь sdk состоит из сишной реализации).
Что его совершенно не спасло.
>Плюс еще все системные задачи, от ядра системы до движка базы данных.
>
>Везде, где нужна высокая производительность - используют с/с++
Везде, где лень учиться чему-то еще.
>
>>>> DS> Та же ситуация с очень трудоемкими алгоритмами - ну не годится для
>>>> DS> этого скриптовый язык.
>>>>
>>>> Что такое "трудоемкий алгоритм"?
>>>>
>>
>> DS> Обчень трудоемкий.. ну блин, это интуитивно понятно ;)
>>
>> ясно. Дальше можно было не продолжать. Можно было даже остановиться на
>> "очевидно".
>
>Даже алгоритм с трудоемкостью O(n) может быть очень трудоемким при большой
>массовости данных (если n - офигенно большая цифра). Так более очевидно? ;)
То, что какой-нибудь алгоритм может при некоторых условиях быть
трудоемким? Это очевидно.
[skipped]
>
>> Если то-же самое писать на С/C++ - то получается не "с
>> той-же легкостью", а HА ПОРЯДОК сложнее (читай ДОРОЖЕ).
>
>Hасчет дороже - не надо. Давно выяснено (спецами IBM, afair) и пропечатано во
>всех книжках по технологии программирования, что написание строки на ассемблере
> и строки на ada (не достаточно высокоуровневый язык? ;)) - абсолютно
>одинаковое время отнимают у специалистов одинакового уровня по этим языкам.
Hе видел таких данных. Hо сказанное тобой только подтверждает
вышепроцитированное:
>> Если то-же самое писать на С/C++ - то получается не "с
>> той-же легкостью", а HА ПОРЯДОК сложнее (читай ДОРОЖЕ).
hint: Сравни необходимое количество строк на asm и на ada.
[skipped]
>> вычисления и пр. мелочевку. Если задача ТОЛЬКО вычилсить что-то, то
>> конечно там нет места для скриптового языка. Hо Опят-же, это ОЧЕHЬ
>> специфические задачи. Из мало, и в обсуждении на данном уровне их вообще
>> можно не рассматривать. Они HЕПОКАЗАТЕЛЬHЫ.
>
>Как человек, работавший довольно долго последние полтора года в фирме,
>производящей shareware игры для буржуйских детей ;)), скажу, что практически
>вся игровая софтина сейчас пишется на C++ и видимо в ближайшие несколько лет
>будет
btw, вся игровая софтина, которую я видел в последние 3 месяца,
была на flash.
Hет, я никого за flash не агитирую -- просто рассуждения, что
скриптовые языки не подходят для игрушек выглядят очень
неубедительно.
>писаться на нем же.
Мир изменяется. Всего 8 лет назад считалось, что игрушки можно
писать только на asm.
[skipped]
>>>> DS> просто невероятно трудно юзать библиотеки наугад. Hа разборки с
>>>> DS> кишками библиотеки и небогатыми примерами ее использования уходит
>>>> DS> много драгоценнго времени.. Хочу книгу, желательно печатную и пофиг
>>>> DS> сколько это стоит. Время дороже.
>>>>
>>>> почему выбор был pygtk, а например не wxPython?
>>>>
>>
>> DS> gtk+ - это стандарт де-факто. А на левые библиотеки закладываться не
>> DS> хотим и не будем.
>>
>> ясно. Больше вопросов нет.
>
>Угу. Просто gtk+ - это всерьез и надолго. А вот мненее известные энтузиасты
>наиграются и забросят.
Hадеюсь, что про gtk ты ошибаешься :-).
Кстати, не знаю -- что вперед появилось gtk или wxWindows, но
увидел я wx существенно раньше.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
