QUOTE (pax @ Oct 6 2004, 23:08 ) А в чем тогда проблема? В "лишних 50 команд"? В чем разница между "fib !! 50" и "fib(50)"?

---

pax, не хулигань.
Разница в самом fibz.

В Хаскелле это: CODE fibz = 1 : 1 : [ x+y | (x,y) <- zip fibz (tail fibz)]

---

А у тебя?

QUOTE (Balancer @ Oct 7 2004, 12:18 ) В Хаскелле это: CODE fibz = 1 : 1 : [ x+y | (x,y) <- zip fibz (tail fibz)]

---

---

Не пойдет. Тут оптимизировать нечего, а надо.
QUOTE А у тебя?

---

А у меня в 50 раз больше, работающее в 200 раз быстрее. Проблема "лишних команд"?

QUOTE (pax @ Oct 7 2004, 14:50 ) Не пойдет. Тут оптимизировать нечего, а надо.

---

Хм. Почему надо? :) В любом деле главное - дойти до нужного места и вовремя остановиться.

QUOTE А у меня в 50 раз больше, работающее в 200 раз быстрее. Проблема "лишних команд"?

---

Сюда ещё нужно добавить время, которое уйдёт у тебя на написание. Если ты свой вариант сделаешь, скажем, всего в 10 раз медленнее, чем мой (т.е., скажем, за минуту) - то можно условно считать, что твой вариант лучше. Если на него уйдёт час (естественно, включая отладку и т.п.) - то всё зависит уже от задачи. Для простого теста или одноразовой задачи - это уже чрезмерные затраты. За час моя программа, написанная за минуту, даже боюсь представить, что насчитать сможет :D

Баланс! Во всём нужен баланс!

Ну и, само собой, под каждую задачу нужен свой инструмент. Конечно, ловко, когда человек мастерски всё делает топором, и лес рубит, и статуэтки вырезает, и врагов убивает. Но я предпочту бензопилу, стамеску и пулемёт :D

QUOTE (Balancer @ Oct 7 2004, 15:40 )QUOTE (pax @ Oct 7 2004, 14:50 ) Не пойдет. Тут оптимизировать нечего, а надо.

---

Хм. Почему надо? :) В любом деле главное - дойти до нужного места и вовремя остановиться.

---

Почему надо? Хм.. Да потому что медленно.
QUOTE QUOTE А у меня в 50 раз больше, работающее в 200 раз быстрее. Проблема "лишних команд"?

---

Сюда ещё нужно добавить время, которое уйдёт у тебя на написание. Если ты свой вариант сделаешь, скажем, всего в 10 раз медленнее, чем мой (т.е., скажем, за минуту) - то можно условно считать, что твой вариант лучше. Если на него уйдёт час (естественно, включая отладку и т.п.) - то всё зависит уже от задачи. Для простого теста или одноразовой задачи - это уже чрезмерные затраты. За час моя программа, написанная за минуту, даже боюсь представить, что насчитать сможет :D

---

На написание программы в 50 раз больше твоей у меня уйдет в 50 раз больше времени. Считаем? Твой случай - минута плюс час. Мой случай - 50 минут + минута. Итого?
QUOTE Для простого теста или одноразовой задачи - это уже чрезмерные затраты.

---

Речь о котлетах - реальных задачах, за которые деньги платят. Про мух мы речь не ведем.

QUOTE Ну и, само собой, под каждую задачу нужен свой инструмент. Конечно, ловко, когда человек мастерски всё делает топором, и лес рубит, и статуэтки вырезает, и врагов убивает. Но я предпочту бензопилу, стамеску и пулемёт :D

---

Само собой.

QUOTE (pax @ Oct 7 2004, 15:42)
На написание программы в 50 раз больше твоей у меня уйдет в 50 раз больше времени. Считаем? Твой случай - минута плюс час. Мой случай - 50 минут + минута. Итого?

---

И запускаем программу 50 раз...

QUOTE (pax @ Oct 7 2004, 16:42 ) На написание программы в 50 раз больше твоей у меня уйдет в 50 раз больше времени. Считаем?

---

Нет. В 50 раз бОльшая программа не в 50 раз, а на несколько порядков сложнее :)

QUOTE Речь о котлетах - реальных задачах, за которые деньги платят. Про мух мы речь не ведем.

---

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

Впрочем, при чём тут деньги? И, вообще, под Бальзака косим? :D

QUOTE (pax @ Oct 6 2004, 00:44 ) QUOTE (Negative @ Oct 5 2004, 18:03 ) Не все не все.... хотелось бы и на Буча (Booch) посмотреть. 

---

---

Гы, UML - будет жить!!!....

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

---

Не сильно эффективная "ленивость"
И к тому же кто сказал, что программа должна быть написана на ОДНОМ языке? Если общеизвестно, что критично по быстродействию не более 20% кода...

Вначале - на языке высокого уровня, потом - критичные кусочки перенести в С. Таких кусочков будет немного, они простые и главное ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К НИМ УЖЕ ПОЛНОСТЬЮ ОПРЕДЕЛЕНЫ.

Вот поглядите на эту смесь TCL со "встроенным" С:


proc myFunc {lst y z} {
set ret ""
foreach x $lst { lappend ret [myFuncIncl $x $y $z] }
return $ret
}

# -----------------------------------------------
proc myFuncIncl {x y z} {
# C-code
return ((x&y)>>z);
# C-code end
}


Красным - С-шная вставка (отступы к сожалению проелись, ну да ладно)

QUOTE (Balancer @ Oct 7 2004, 16:52 ) В 50 раз бОльшая программа не в 50 раз, а на несколько порядков сложнее

Унифицированных реальных задач не бывает

---

Это все зависит от того, кто делает.
QUOTE И за то и за другое можно получить, порой, равные деньги

---

Ну и сколько реальных задач решено на Хаскелле?

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

---

Не сильно эффективная "ленивость"
И к тому же кто сказал, что программа должна быть написана на ОДНОМ языке? Если общеизвестно, что критично по быстродействию не более 20% кода...

---

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

Возмем твой пример. Совершенно очевидно, что операция над элементом списка эффективнее добавлению элемента к списку. Операции же бинарной логики уже приближены к машинному коду, а значит реализованы на любом языке очень просто и работают "быстрее не бывает". Напротив, вызов дополнительной функции и переключение контекста быстрой операцией никак не назовешь.

Другими словами, все тоже самое можно было сделать на самом TCL. Просто сначала нужно скопировать список, а затем над каждым элементом произвести необходимую операцию.

QUOTE (pax @ Oct 8 2004, 09:27 ) Я говорю прежде всего про алгоритмическую эффективность. Когда критичного к быстродействию кода нет в следствии простоты и приближенности всего кода к машинному.

Возмем твой пример. Совершенно очевидно, что операция над элементом списка эффективнее добавлению элемента к списку. Операции же бинарной логики уже приближены к машинному коду, а значит реализованы на любом языке очень просто и работают "быстрее не бывает". Напротив, вызов дополнительной функции и переключение контекста быстрой операцией никак не назовешь.

Другими словами, все тоже самое можно было сделать на самом TCL. Просто сначала нужно скопировать список, а затем над каждым элементом произвести необходимую операцию.

---

"Приближенность кода к машинному" - как раз С-шный подход. Именно за этим и сделана С-вставка. (В противном случае пришлось бы использовать утилиту binary, что медленнее.)

Да и кстати, правка списка на месте возможна только если есть возможность создания некоторого итератора, который хранит позицию в списке (иначе придется пробегать список с начала для доступа к каждому элементу).

QUOTE (pax @ Oct 8 2004, 09:57 )Ну и сколько реальных задач решено на Хаскелле?

---

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

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

Поэтому тот же O'Caml, превосходящий C++ практически по всем статьям (функционал, скорость) в наше время весьма малопопулярен.

QUOTE (Alex Soff @ Oct 8 2004, 10:40 ) "Приближенность кода к машинному" - как раз С-шный подход. Именно за этим и сделана С-вставка. (В противном случае пришлось бы использовать утилиту binary, что медленнее.)

---

Вот за это я и не люблю TCL.
QUOTE Да и кстати, правка списка на месте возможна только если есть возможность создания некоторого итератора, который хранит позицию в списке (иначе придется пробегать список с начала для доступа к каждому элементу).

---

Это не проблема.

QUOTE (Balancer @ Oct 8 2004, 11:12 ) QUOTE (pax @ Oct 8 2004, 09:57 )Ну и сколько реальных задач решено на Хаскелле?

---

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

---

Ну вот. Т.е. ты Хаскеллом не пользуешься. Как насчет других "крутых" языков?
QUOTE А о реальных проектах спрашивать глупо. Т.к. пишут обычно не на лучшем языке, а на том, который знают.

---

Вот. Правильно. А знают лучше всего тот, на котором пишут.

QUOTE (pax @ Oct 8 2004, 11:31 ) Вот за это я и не люблю TCL.

---

А в чем проблема? Логика программы практически во всех случаях на требует работы с бинарями, а низкоуровневую упаковку/распаковку - выносим в С.
В результате проигрышь по быстродействию минимален и программу сопровождать легко, бо компактная.
То есть программа пишется не на Tcl, а на Tcl + C

P/S
Да, да если бы обработка списка была критична - можно было бы вынести в С функцию целиком.