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

---

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

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

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

---

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

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

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). Куда уж короче?

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

---

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

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

---

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

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

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

---

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

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

---

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

---

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

---

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

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

---

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

---

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

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

P/S
Одновременно написали ответ.

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

---

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

Так? Нет?


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

---

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

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

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

---

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

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# :)

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

Так? Нет?

---

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

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

---

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

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

---

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

---

Что будем делать с выигрышем в производительности в 256 раз?

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

---

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

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

---

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

---

И получим неэффективную программу.

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

---

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

Нужна эффективная программа - ну так ты на её оптимизацию тогда в 256 раз больше времени сможешь потратить :)

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

---

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

Вобщем я выбираю котлеты.

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

---

DirectX managed не озабоченный обратной совместимостью, с меньшим количеством вызовов функций и передаваемых аргументов, медленнее на 40-60%. Наверняка Микрософт портируя стандартные примеры из С++ в С# просто потратила высвобожденное время на что-то другое :)

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

---

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

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

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

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

---

Я тоже

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

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

---

А в чем тогда проблема? В "лишних 50 команд"? В чем разница между "fib !! 50" и "fib(50)"?