IT>>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее.
Полностью абстрагируясь от эффективного вычисления процентов , отмечу лишь, что сделать код с помощью каких-то высокоуровненвых конструкций проще — можно, понятнее — тоже можно, а вот эффективнее — дудки. Потому что предельно эффективная программа — это наилучшим образом оптимизированная программа, написанная на ассемблере. А в этом самом ассемблере есть только презренные присваивания, if, с грехом пополам циклы, и ни одной лямбды
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее.
PD>Полностью абстрагируясь от эффективного вычисления процентов , отмечу лишь, что сделать код с помощью каких-то высокоуровненвых конструкций проще — можно, понятнее — тоже можно, а вот эффективнее — дудки. Потому что предельно эффективная программа — это наилучшим образом оптимизированная программа, написанная на ассемблере. А в этом самом ассемблере есть только презренные присваивания, if, с грехом пополам циклы, и ни одной лямбды
Если уж абстрагироваться полностью, то идеальный компилятор идеально (в плане эффективности) скомпилирует все наши лямбды и прочая в понятные процессору ифы и вайлы.
У меня нет Хаскеля, проверить не могу.
Пожалуйста, приведи данные по скорости работы алгоритма на Хаскеле и на С, если они есть. Обещано же (хоть и не вами обоими) — эффективнее
"Мы обслужим вас быстро, дешево и качественно. Выберите любые два из этих трех слов"
Здравствуйте, Aen Sidhe, Вы писали:
AS>Если уж абстрагироваться полностью, то идеальный компилятор идеально (в плане эффективности) скомпилирует все наши лямбды и прочая в понятные процессору ифы и вайлы.
Да. Но не более эффективно, чем собственно ассемблер. В лучшем случае (см. выделенное мной) — не хуже. А ведь обещали на порядок — вот я и смеюсь.
Здравствуйте, netch80, Вы писали:
_FR>>>>и факториал как пример рекурсии T>>>Убивать за такие примеры рекурсии. _FR>>За что? Только за то, что "навязло" в зубах? N>За методическую некорректность. Показывание рекурсии на примере факториала, при том, что рядом он считается просто и тривиально обычным циклом
Факториал — циклом? Реально считать надо таблицей (массивом), в котором индекс элемента — входное значение, а значение в массиве — результат. Но это так, ремарка, к делу отношения не имеющая.
N>Если бы я показывал рекурсию на каком-то примере, первый пример был бы взят максимально практический, причём такой, чтобы его нельзя было в одной функции свести в цикл. А уже после этого — числа Фибоначчи, а собственно факториал — уже в качестве упражнения (если на лекции — вызвать кого-то к доске и заставить преобразовать).
Например? Вот я точно знаю, что лично на меня лучше всего подействовал именно факториал, о нём и говорю. Какой может быть пример? Лучше сказать "такой-то", а я только слышу "какой-то не такой, другой" и т.п. Покажите, и дискуссия исчерпает себя. но помните, что про рекрсию надо рассказвать ещё школьникам (информатика в 10-11 классе).
N>И ещё одно — размахивание факториалом является косвенным указанием на то, что "рекурсия — это очень просто". Когда же выучивший такое сталкивается с реальной жизнью, когда перекладка алгоритма на рекурсивный лад в первую очередь крайне громоздка — следует шок.
Это уже к вопросу отношения не имеет: просто там вообще или нет. Бывает же по-разному.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>У меня нет Хаскеля, проверить не могу. PD>Пожалуйста, приведи данные по скорости работы алгоритма на Хаскеле и на С, если они есть. Обещано же (хоть и не вами обоими) — эффективнее
Программа на хаскеле конечно эффективнее, в смысле производительности пишущего (и читающего) код программиста.
В смысле производительности работы готового она малоэффективна. Но можно оптимизировать http://en.literateprograms.org/Quicksort_(Haskell) и все равно код будет проще сишного в разы а по производительности вполне к нему приблизится.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Если уж абстрагироваться полностью, то идеальный компилятор идеально (в плане эффективности) скомпилирует все наши лямбды и прочая в понятные процессору ифы и вайлы.
PD>Да. Но не более эффективно, чем собственно ассемблер. В лучшем случае (см. выделенное мной) — не хуже. А ведь обещали на порядок — вот я и смеюсь.
Там шёл разговор о том, что эффективнее будет твоя работа, как программиста. Вместо написания 30 ифов и 50 вайлов — пара хайлевел инструкций.
ЗЫ: следует понимать, что про 30 и 50 — утрирование.
Здравствуйте, _DAle_, Вы писали:
_DA>Есть такие программисты вроде меня, которые просто не могут понять, ну как можно "не вспомнить", как реализовывать бинарный поиск. Ну это же простейший кирпичик, который многие дети придумывают сами в школе на уроках информатики.
Как можно не помнить письмо Татьяны! Как можно не суметь выпить двадцать кружек пива за вечер! И т.д.… Про Холмса читали?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да. Но не более эффективно, чем собственно ассемблер. В лучшем случае (см. выделенное мной) — не хуже. А ведь обещали на порядок — вот я и смеюсь.
Некторые современные компиляторы настолько хорошо оптимизируют, в том числе и в compile time что вручную на ассемблере их очень сложно обставить, особенно на нетривиальном коде.
А на порядок обещали поднять эффективность програмиста а не кода. Хотя я думаю на порядок не будет, но в разы да вполне возможно.
Здравствуйте, Константин Л., Вы писали:
_FR>>То есть можно жертвовать надёжностью, модульностью, локализацией ради "читабельности"? Это при том, что мнение "чем локальнее объявление, тем лучше" можно считать верным (или нет?), а "читабельность" — величина субъективная?
КЛ>где ты увидел что я ими жертвую? private static. ни стейта, ни открытости.
Ну представь себе такой не очень маленький класс. Кому-то понадобилось дописать в него некий метод, в котором понадобился какой-то хелпер. Он смотрит: ага! кто-то добрый уже такой написал! и берёт его. Вот связанность и получилась. Когда же хелпер объявлен локально, "случайно", поошибке, "не правильно" заиспользовать его невозможно, нужно явно постараться.
КЛ>>>плюс от к захвату контекста все-же лучше прибегать с осторожностью.
_FR>>Вынося метод "наружу" ты позваляешь кому-то (а как ты запрещаешь? ага, никак!) к нему обратиться, тем самым увеличивая связаность. К лишней связаности надо относиться с ещё большим подозрением чем "к захвату контекста". Кстати, из за чего требуется осторожность? И, между прочим, мы же говорим о методах, не захватывающих контекст.
КЛ>связанность и там и там. только в одном случае по параметрам, в другом по локальным переменным. Наружу это куда? Я же написал — private.
Связанность с параметрами — нормальное дело. Это всё равно что утверждать, что класс связан со своими членами: конечно связан, только это "положительная связь", в том смысле, что не причиняет вреда и которую легко порвать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>а вот эффективнее — дудки.
Тут вопрос: эффективнее чем что? Чем идеально оптимизированная программа — действительно вряд ли. А чем обычная — легко.
Чем выше уровнем конструкция, тем ближе она к смыслу операции, а не деталям реализации ("что?" вместо "как?"), и тем больше шансов, что хороший компилятор найдет более удачное решение.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Там шёл разговор о том, что эффективнее будет твоя работа, как программиста.
Ну уж нет. Читай внимательно. Выделено мной.
IT>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>У меня нет Хаскеля, проверить не могу. PD>>Пожалуйста, приведи данные по скорости работы алгоритма на Хаскеле и на С, если они есть. Обещано же (хоть и не вами обоими) — эффективнее
FR>Программа на хаскеле конечно эффективнее, в смысле производительности пишущего (и читающего) код программиста.
А это не обсуждалось. Вот что писал IT
IT>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее
А в смысле работы программиста — вот тебе самое эффективное решение из незабвенного "Hello, World"
Bob, could you please write me a program that prints "Hello,
world."? I need it by tomorrow.
Здравствуйте, FR, Вы писали:
FR>А на порядок обещали поднять эффективность програмиста а не кода. Хотя я думаю на порядок не будет, но в разы да вполне возможно.
Слушайте, господа, вы чего это все как будто сговорились ? Мне в третий раз приходится цитировать
IT>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее.
Где тут про эффективность труда программиста ? Тут именно про эффективность кода. Русским по белому.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну уж нет. Читай внимательно. Выделено мной.
IT>>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее
PD>Код!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Там шёл разговор о том, что эффективнее будет твоя работа, как программиста.
PD>Ну уж нет. Читай внимательно. Выделено мной.
IT>>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее
PD>Код!
Придирки к словам, в случае, когда суть кристально понятна, вас не красит.
По моему тут только ты единственный его неправильно понял.
PD>А в смысле работы программиста — вот тебе самое эффективное решение из незабвенного "Hello, World"
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>а вот эффективнее — дудки.
Уф, хоть один нормальный ответ
DM>Тут вопрос: эффективнее чем что? Чем идеально оптимизированная программа — действительно вряд ли. А чем обычная — легко.
Все зависит от того, что делаем. Если употребить неэффективный алгоритм, то, конечно, да, но язык тут ни при чем. Если неэффективно кодировать — тоже да (например, лишние ненужные действия). Если же обычная программа написана как следует (ты же не будешь утверждать, что обычняа == плохо написанная), то тут уже зависит от оптимизирующих возможносте компилятора.
DM>Чем выше уровнем конструкция, тем ближе она к смыслу операции, а не деталям реализации ("что?" вместо "как?"), и тем больше шансов, что хороший компилятор найдет более удачное решение.
Черт знает. Чем выше уровень, тем больше вероятность, что этот самый компилятор применит стандартное решение, которое как раз в этом случае лучше бы и не применять, может быть. Либо в нем должны быть зашиты эти самые "что" (это в конечном счете эквивалентно набору встроенных высокоэффективных решений). Но все "что" не встроишь, а вот оптимизировать детали можно всегда — на то они и детали, их немного.
, отмечу лишь, что сделать код с помощью каких-то высокоуровненвых конструкций проще — можно, понятнее — тоже можно, а вот эффективнее — дудки. Потому что предельно эффективная программа — это наилучшим образом оптимизированная программа, написанная на ассемблере. А в этом самом ассемблере есть только презренные присваивания, if, с грехом пополам циклы, и ни одной лямбды 
Покажите, и дискуссия исчерпает себя. но помните, что про рекрсию надо рассказвать ещё школьникам (информатика в 10-11 классе).
