Доступно и всерьез о людях и  взаимоотношениях между ними
Добро пожаловать в Socionics.org Войти | Регистрация | Помощь
in Найти
.

Программирование и соционика

Последний ответ: DarkJackLondon   01/05/2017, 5:26   Ответов: 103
Страница 3 из 7 [Всего 104 записей]   « 1 2 3 4 5 » ... Последняя »
Сортировать сообщения: Previous Next
  •  10/06/2004, 9:49 684072 in reply to 684042

    QUOTE (pax @ Oct 6 2004, 13:36 ) На чем же написан движок .NET?

    Вероятно, пока на C++ :)
    Точнее, предполагаю, что .NET Framework на MSVC написан.
    Mono - на чистом Си написан (не Си++). Вот mod_mono уже во многом на C# написан.

    А так - первые компиляторы Си писались на ассемблере :)

    QUOTE Этот вопрос мы уже выясняли.


    Угу. А про алгоритмическую сложность (и в ту же степь - сложность отладки и т.п.) ты профильтровал? :)

    Твоё 13-милионное число в одну строчку алгоритма вычисляется? :)
  •  10/06/2004, 9:58 684073 in reply to 684042

    QUOTE (Balancer @ Oct 6 2004, 13:49 ) QUOTE (pax @ Oct 6 2004, 13:36 ) На чем же написан движок .NET?

    Вероятно, пока на C++ :)
    Точнее, предполагаю, что .NET Framework на MSVC написан.
    Mono - на чистом Си написан (не Си++). Вот mod_mono уже во многом на C# написан.

    А так - первые компиляторы Си писались на ассемблере :)

    Ну вот. Куда мы без него?
    QUOTE QUOTE Этот вопрос мы уже выясняли.

    Угу. А про алгоритмическую сложность (и в ту же степь - сложность отладки и т.п.) ты профильтровал? :)

    Эти вопросы зависят не от языка, а от того, кто на нем пишет. Плохоработающую программу можно написать на любом языке.

    QUOTE Твоё 13-милионное число в одну строчку алгоритма вычисляется? :)

    y = fib(x). Куда уж короче?
  •  10/06/2004, 10:10 684074 in reply to 684042

    QUOTE (pax @ Oct 6 2004, 13:58 ) Ну вот. Куда мы без него?

    Только не говори, что думаешь, что сегодняшние C++ компиляторы пишутся на ассемблере :D

    QUOTE Эти вопросы зависят не от языка, а от того, кто на нем пишет. Плохоработающую программу можно написать на любом языке.


    В первую очередь - от языка. Напиши мне qsort на ассемблере хотя бы для целых чисел :D

    Бедные языки стимулируют использование простых и неэффективных алгоритмов.

    QUOTE y = fib(x). Куда уж короче?


    Ну тупить не надо, да? :)
    Ты прекрасно понял, что речь о реализации этой функции средствами языка.
  •  10/06/2004, 10:22 684075 in reply to 684042

    QUOTE (Balancer @ Oct 6 2004, 14:10 ) В первую очередь - от языка. Напиши мне qsort на ассемблере хотя бы для целых чисел :D

    Да. Исправляюсь. Если в языке есть соответствующие конструкции, то эффективность их работы от программиста совершенно не зависит.
    QUOTE Бедные языки стимулируют использование простых и неэффективных алгоритмов.

    Опять-таки, зависит исключительно от программиста.
    QUOTE Ты прекрасно понял, что речь о реализации этой функции средствами языка.

    Хм... Мне выкинуть сюда исходник?
  •  10/06/2004, 10:23 684076 in reply to 684042

    QUOTE (Balancer @ Oct 6 2004, 13:10 ) QUOTE y = fib(x). Куда уж короче?


    Ну тупить не надо, да? :)
    Ты прекрасно понял, что речь о реализации этой функции средствами языка.

    А мне показалось, что это был намек...
    И в общем-то обоснованный... ленивые вычисления над элементами массивов в хаскеле - тоже встроенное средство. По сути там определяется (конфигурируется) только формула применяемая над каждым шагом, но не алгоритм вывода.

    Вообще, говорить о быстродействии, применительно к языкам высокого уровня, IMHO некорректно. Оно всегда (если откорвенно не тупить) будет определяться быстродействием используемых кирпичиков. Например, алгоритмы работающие над "отображениями" в TCL дадут разницу быстродействия в два порядка в зависимости от того, реализованы они над array или над keylist. И ни то ни другое ничего не будет говорить собственно о "быстродействии TCL". IMHO уж что нибудь одно: или язык высокого уровня и удобство, или бенчмарки... А привычка мерять быстродействие языков высокого уровня - пережиток того же самого "универсализма", который породил C++...

    P/S
    Одновременно написали ответ.
  •  10/06/2004, 11:00 684077 in reply to 684042

    QUOTE (pax @ Oct 6 2004, 14:22 ) Да. Исправляюсь. Если в языке есть соответствующие конструкции, то эффективность их работы от программиста совершенно не зависит.

    Принимается :)
    Но тогда вытекает очевидная (если нет - возрази) цепочка:
    - конструктивно более богатый язык упрощает разработку
    - упрощение разработки высвобождает ресурсы программиста
    - эти ресурсы можно направить на улучшенную алгоритмизацию

    Так? Нет?


    QUOTE Опять-таки, зависит исключительно от программиста.


    Мы рассматриваем программистов одного уровня, иначе всё теряет смысл :) Профессионал на PHP может уделать ламера на ассемблере, а профессионал на ассемблере уделает ламера на Java :)

    При равном уровне программистов менее богатый язык толкает на использование более примитивных алгоритмов? Так? Нет? Почему?

    QUOTE Хм... Мне выкинуть сюда исходник?


    Если он более ... ну, скажем, пяти строк, то можно не кидать. Т.к. эргономический проигрышь одной строчке Хаскелла тогда уже очевиден :)
  •  10/06/2004, 11:17 684078 in reply to 684042

    QUOTE (Alex Soff @ Oct 6 2004, 14:23 ) А мне показалось, что это был намек...

    Однако последующий ответ не показал этого :)

    QUOTE И в общем-то обоснованный... ленивые вычисления над элементами массивов в хаскеле - тоже встроенное средство.


    Но соль тут не в ленивых вычислениях, хотя алгоритм и базируется на них.

    Если в язык изначально встроена эффективная функция fib() - то это далеко не то же самое, как встроенные в язык средства для её реализации. В первом случае мы просто получаем заточенное под задачу решение, во втором - средство создания таких решений. Первый случай нам в этом споре неинтересен (хотя во многом именно по этой причине я последнее время много программирую на PHP :)). Интереснее второй случай, с которым мы всё равно возвращаемся к моему первоначальному тезису.

    Более продвинутый язык, пусть и уступающий в скорости, упрощает разработку настолько, что при равных затратах программиста можно получить более быстрый, а зачастую _намного_ более быстрый и надёжный код, чем на конструктивно более простом и скоростном языке.

    Во многих же случаях дело доходит до совершенно неприемлимых затрат для решения на более примитивном и скоростном средстве. Пусть Хаскелл на три порядка медленнее предельно оптимизированного нативного кода. Но программа на нём пишется не просто быстрее и проще, а быстрее и проще настолько, что на ассемблере, скажем, аналогичный по функциональности код никто в здравом уме и твёрдой памяти писать просто не будет :)

    QUOTE Вообще, говорить о быстродействии, применительно к языкам высокого уровня, IMHO некорректно.


    Корректно говорить о качественной эффективности того или иного средства разработки под конкретную задачу. Грубо говоря - на каком языке быстрее будет получено решение требуемого уровня быстродействия для той или иной задачи.

    QUOTE Оно всегда (если откорвенно не тупить) будет определяться быстродействием используемых кирпичиков.


    Не всегда. Потому что эти кирпичики в разных языках можно (и придётся) соединять по-разному :)

    Это правило будет верно для языков одного класса. Скажем (условно), Си++ с библиотеками классов и Дельфи, VBS и JScript и т.п. В этом смысле C++ и C# - уже языки разного класса, т.к. позволяют обходиться уже разными алгоритмическими приёмами (сборка мусора, боксинг, контроль массивов, массивы переменных размеров и массивы массивов и т.п. - это всё очень упрощает алгоритмизацию). В этом смысле C# - даже бОльший шаг впреёд по сравнению с Си++, чем Си++ по сравнению с Си :)

    QUOTE А привычка мерять быстродействие языков высокого уровня - пережиток того же самого "универсализма", который породил C++...


    Тем более интересен .NET, т.к. позволяет в рамках одной платформы отойти от "универсализма" :) .NET - это же не только C#, но уже сегодня с дюжину альтернативных языков, от того же Fortran'а до чисто функционального F# :)
  •  10/06/2004, 11:29 684079 in reply to 684042

    QUOTE (Balancer @ Oct 6 2004, 15:00 )Но тогда вытекает очевидная (если нет - возрази) цепочка:
    - конструктивно более богатый язык упрощает разработку
    - упрощение разработки высвобождает ресурсы программиста
    - эти ресурсы можно направить на улучшенную алгоритмизацию

    Так? Нет?

    Могу предложить другую цепочку:
    - конструктивно не богатый язык не ограничивает программиста в эффективности алгоритма (слабая - сильная )
    - эффективные алгоритмы упрощают разработку ( сильная -> сильная )
    - упрощение разработки высвобождает ресурсы программиста ( )
    - эти ресурсы можно направить на создание новых продуктов, а не на переделку существующих ( )

    QUOTE При равном уровне программистов менее богатый язык толкает на использование более примитивных алгоритмов? Так? Нет? Почему?

    В случае с ламерами - да. В случае с профессионалами - нет.

    QUOTE QUOTE Хм... Мне выкинуть сюда исходник?

    Если он более ... ну, скажем, пяти строк, то можно не кидать. Т.к. эргономический проигрышь одной строчке Хаскелла тогда уже очевиден :)

    Что будем делать с выигрышем в производительности в 256 раз?
  •  10/06/2004, 11:31 684080 in reply to 684042

    QUOTE (pax @ Oct 6 2004, 15:29 ) Что будем делать с выигрышем в производительности в 256 раз?

    Направим высвободившееся время на писанину в Оргии :)
  •  10/06/2004, 11:41 684081 in reply to 684042

    QUOTE (Balancer @ Oct 6 2004, 15:31 ) QUOTE (pax @ Oct 6 2004, 15:29 ) Что будем делать с выигрышем в производительности в 256 раз?

    Направим высвободившееся время на писанину в Оргии :)

    И получим неэффективную программу.
  •  10/06/2004, 12:58 684082 in reply to 684042

    QUOTE (pax @ Oct 6 2004, 15:41 ) И получим неэффективную программу.

    Нет, ты уж определись тогда с мухами и котлетами :)

    Нужна эффективная программа - ну так ты на её оптимизацию тогда в 256 раз больше времени сможешь потратить :)
  •  10/06/2004, 13:40 684083 in reply to 684042

    QUOTE (Balancer @ Oct 6 2004, 16:58 ) Нет, ты уж определись тогда с мухами и котлетами :)
    Нужна эффективная программа - ну так ты на её оптимизацию тогда в 256 раз больше времени сможешь потратить :)

    Я ленивый. Мне лучше сто раз подумать и один раз сделать раз и на всегда, чем потом чего-то там оптимизировать. И если из-за функциональных особенностей языка моя идеальная программа будет работать неэффективно, то грош цена такому языку. В результате, все те деньги, которые должны были пойти на гигабайты и терафлопы ресурсов, идут мне в карман.

    Вобщем я выбираю котлеты.
  •  10/06/2004, 14:05 684084 in reply to 684042

    QUOTE (Balancer @ Oct 6 2004, 15:58)
    Нужна эффективная программа - ну так ты на её оптимизацию тогда в 256 раз больше времени сможешь потратить :)


    DirectX managed не озабоченный обратной совместимостью, с меньшим количеством вызовов функций и передаваемых аргументов, медленнее на 40-60%. Наверняка Микрософт портируя стандартные примеры из С++ в С# просто потратила высвобожденное время на что-то другое :)
  •  10/06/2004, 16:25 684085 in reply to 684042

    QUOTE (pax @ Oct 6 2004, 17:40 ) Я ленивый. Мне лучше сто раз подумать и один раз сделать раз и на всегда, чем потом чего-то там оптимизировать.

    Сто раз подумать и один раз сделать - это и есть оптимизация :) Не говорится же нигде, что оптимизировать можно только уже работающую программу.

    Имея более выразительные и мощные средства, можно меньше заботиться о мелочах и сосредоточиться на главном.

    Стратег ты, в конце концов, или тактик, я что-то не понимаю! :)

    QUOTE Вобщем я выбираю котлеты. !--QuoteEnd-->


    Я тоже
  •  10/06/2004, 19:08 684086 in reply to 684042

    QUOTE (Balancer @ Oct 6 2004, 20:25 ) Сто раз подумать и один раз сделать - это и есть оптимизация :) Не говорится же нигде, что оптимизировать можно только уже работающую программу.

    Имея более выразительные и мощные средства, можно меньше заботиться о мелочах и сосредоточиться на главном.

    А в чем тогда проблема? В "лишних 50 команд"? В чем разница между "fib !! 50" и "fib(50)"?
Страница 3 из 7 [Всего 104 записей]   « 1 2 3 4 5 » ... Последняя »
Показать как RSS feed в формате XML


visits

Community Server