Пофигу, что раньше появилось. Русское "кодер" не имеет корней в "code monkeys".

> А так же надо знать/понимать, что и как будет делаться при выполнении SQL-запроса. И чем детальнее будет понимание процесса и того что в нем существенно, тем проще будет делать работу.
Я акцентировал внимание на том, что в функциональщине надо иметь только понимание того, что делается, а как делается, знать не надо, в этом е╦ суть. Отсутствие хороших оптимизаторов для SQL, приводящее к тому, что надо, вс╦-таки, о SQL профайлерах знать, является частным случаем и картину не меняет.

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

> И ещ╦ - ты не помешался часом на функциональщине?
Нет, не помешался, я вижу за ней будущее. Софт становится вс╦ сложнее, имеется потребность в увеличении производительности железа. В верхний предел тактовой частоты процессоров технологии уже уп╦рлись. Е╦, конечно, ещ╦ повысят, но скачка уже не будет, на порядки частоту не увеличат. Сейчас инженеры пошли по пути увеличения числа ядер в процессоре, но программисты к этому ещ╦ не готовы. Существующее море софта не расчитанно на параллельное исполнение. В императивных языках распараллеливание программы пут╦м использования тредов и объектов синхронизации это дикий костыль, который очень хреново в парадигму укладывается. В функциональных же, чистых языках распараллелить программу вообще безо всяких телодвижений со стороны программиста - нефиг делать.
> Ах, оказывается компайлеры и оптимизаторы должны из говна конфетку делать!
Да, именно так, иначе компайлеры не эволюцинировали бы, не находишь?
> А я-то думал, и программист кое что понимать должен.
Смотря что. Потребность в знании, во что разворачивается высокоуровневая конструкция, неуклонно уменьшается. Уже сейчас очень трудно / невозможно руками добиться такой же оптимизации, какую делают современные си++ компиляторы. Вообще, не подменяешь ли ты понятия? Программист всегда должен будет уметь оценивать сложность алгоритма, вот, с этим я спорить не буду, а необходимость знания всякой хрени, типа того, что постфиксный инкремент реализуется через префиксный в плюсах, это бред.
> Вот только их самих-то кто писать будет?
Компилятор, который будет оптимизировать код, используя все доступные методы оптимизации и особенности конкретного процессора написать можно будет всегда. Это очень узкая ниша, не стоит переходить на часности, мы говорим о программировании в целом.

Я акцентировал внимание на том, что в функциональщине надо иметь только понимание того, что делается, а как делается, знать не надо, в этом её суть.
-----
Т.е. "кодеры" имеют право на существование...
Эээ... сегодняшний пример... Босс (мой) слепил полгода назад класс для "анализа зависимостей"... четыре месяца я боролся с этим кодом, требуя, чтобы он был переписан. Сегодня наконец-то все "уперлось" в этот код... а решения - пока нету. Т.е. функциональщина - есть, а вот чуток ее поправить - не получается... Просто потому, что на момент первичного написания кое-какие мелочи были опущены...

> Т.е. "кодеры" имеют право на существование...
Ню-ню, попробуйте для ленивого языка отладчик аналогичный, хотя бы, gdb написать, а я посмеюсь.

а я посмеюсь.
------
Зря. Бо, если кто-то возьмется оплачивать - напишу - после написания компиляторов это не так сложно.

Нашёл говоришь серебрянную пулю? Ню-ню... Не ты первый.

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

Где ты увидел это в написанном?

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

Я вообще ни чём спорить не хочу. Функциональные языки не вчера на свет появились, и если бы это было наше будущее, то оно бы уже наступило.

Мы не на ядра, мы на кластер параллелим.

Я сказал, я вижу их перспективными, про серебрянную пулю заговорил не я в этом треде. Никто не утверждает, что ФЯ заменят собой вообще всё. Этому препятствует, хотя бы изучение Паскаля в некоторых универах. Что же до распараллеливания на кластер, то, представь, вот, вы там колупаетесь со своим распараллеливанием, работы научные пишете, а будет всё автоматом. Не для отдельных еденичных приложений, а вообще для всех, на самых обыкновенных десктопах, а не на кластерах. С С++ это фантастика, с каким-нибудь Haskell - уже реальность.
И растущий интерес к функциональщине у народа наблюдается. В создании F# от MS; Nemerle - не только ФЯ, но интересен наличием функциональных возможностей; Erlang, который стал промышленным языком в телекоммуникации. Да даже по STL было видно, что функциональный подход красив и часто удобен.

вот оказывается что надо учить! чистые языки !
а вы мне тут ООП, да ООП

Короче, ясно, каждый прочитал что-то сво╦.

Не обращай внимания, товарищ просто слегка помешался.

Не обращай внимания, товарищ просто слегка помешался.
------
Эээ... А ты когда-нибудь видел нормального программиста? Т.е. такого, который способен работать и не слегка, того, помешан...

Короче, ясно, каждый прочитал что-то своё.
-----
Не обращай внимания - два РНРшника, читающие один и тот же код понимают его по-своему...

А почему бы и нет?. Не всегда же Россия настолько отставала, было и наоборот. Давно, правда.