Здравствуйте, BulatZiganshin, Вы писали:

FR>>Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.

BZ>по моим наблюдениям хаскел как раз очень хорош для описания сложных алгоритмов

Угу так и есть, но если за день выхлоп 30 — 100 отлаженных строк то от того что при той же функциональности строк станет 20 — 50 не тепло не холодно

Здравствуйте, BulatZiganshin, Вы писали:

BZ>metalua видел? почитай metalua-manual.pdf в http://metalua.luaforge.net/metalua-0.4.1-rc1.tgz
BZ>наиболее ФП из всех скриптовых языков, с расширяемым синтаксисом
Я готов поспорить, что "наиболее ФП из всех скриптовых языков, с расширяемым синтаксисом" — это Scheme
Применительно к вебу, конкретно — PLT Scheme.

Я люблю луа, но функциональный язык без списков — нонсенс

Автор металуа, кстати, писал:

Here's a remark for functional programmers: this API is very imperative; you might cringe at seeing the `Call nodes transformed in-place. Well, I tend to agree but it's generally counter-productive to work against the grain of the wood: Lua is imperative at heart, and design attempts at doing this functionally sucked more than approaches that embraced imperativeness.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, BulatZiganshin, Вы писали:

FR>>>Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.

BZ>>по моим наблюдениям хаскел как раз очень хорош для описания сложных алгоритмов

FR>Угу так и есть, но если за день выхлоп 30 — 100 отлаженных строк то от того что при той же функциональности строк станет 20 — 50 не тепло не холодно

Т.е. если производительность увеличится в 2 раза, то ни тепло ни холодно?
Или я не понял какие цифры к чему ты относишь

Здравствуйте, Курилка, Вы писали:

FR>>Угу так и есть, но если за день выхлоп 30 — 100 отлаженных строк то от того что при той же функциональности строк станет 20 — 50 не тепло не холодно

К>Т.е. если производительность увеличится в 2 раза, то ни тепло ни холодно?

А с чего ты взял что производительность увиличится в два раза?
Если в день пишется 50 строк вместо 100 на одинаковую функциональность то это в лучшем случае
увеличит производительность на доли процента.

К>Или я не понял какие цифры к чему ты относишь

Конечно не понял основная работа именно разработать алгоритм, затраты на кодирование стремятся к
нулю.

Здравствуйте, z00n, Вы писали:

Z>Я люблю луа, но функциональный язык без списков — нонсенс

Рефал

Здравствуйте, Daevaorn, Вы писали:
D>Нет, конечно, дело ваше. Только на мой взгляд, это был кусок имплицитности, от которого правильно что избавились.

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

Здравствуйте, FR, Вы писали:
FR>Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.

Ну тут все от алгоритмов зависит и от того, как Вы их будете реализовывать. В конце концов, тот же хаскель позволяет загнать все под IO или ST — и вовсю "императивничать". Если совсем припрет — критичные куски кода можнопереписать на C, а хаскель использовать как удобный скриптовый язык.

Здравствуйте, Mr.Cat, Вы писали:

MC>Ну тут все от алгоритмов зависит и от того, как Вы их будете реализовывать. В конце концов, тот же хаскель позволяет загнать все под IO или ST — и вовсю "императивничать". Если совсем припрет — критичные куски кода можнопереписать на C, а хаскель использовать как удобный скриптовый язык.

Я тут пытаюсь объяснить что есть задачи для которых язык (практически любой высокого уровня) не важен. У меня они в недавнем прошлом были у тех кто не понимает похоже нет.
Если за день пишется 100 строк на си то хаскель на котором пусть будет даже 20 строк ничего ни изменит.

Здравствуйте, FR, Вы писали:
Z>>Я люблю луа, но функциональный язык без списков — нонсенс
FR>Рефал

Рефал, скорее, терм-рерайтер, типа Q или Maude. Да и эта их главная датаструктура, которую можно матчить в двух концов — явно не массив (кстати что?).

Я под впечатлением от Рефала и Tom'a сделал для луа паттерн-матчинг, который может матчить array с обоих концов, и, конечно, быстро обнаружил, что для мутабельной структуры данных это практически ничего не дает.

Здравствуйте, z00n, Вы писали:

Z>Рефал, скорее, терм-рерайтер, типа Q или Maude. Да и эта их главная датаструктура, которую можно матчить в двух концов — явно не массив (кстати что?).

Структурное дерево.

Z>Я под впечатлением от Рефала и Tom'a сделал для луа паттерн-матчинг, который может матчить array с обоих концов, и, конечно, быстро обнаружил, что для мутабельной структуры данных это практически ничего не дает.

Так там не просто с двух концов можно матчить, а сразу структурой, это намного мощнее и списков и массивов.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Курилка, Вы писали:

FR>>>Угу так и есть, но если за день выхлоп 30 — 100 отлаженных строк то от того что при той же функциональности строк станет 20 — 50 не тепло не холодно

К>>Т.е. если производительность увеличится в 2 раза, то ни тепло ни холодно?

FR>А с чего ты взял что производительность увиличится в два раза?
FR>Если в день пишется 50 строк вместо 100 на одинаковую функциональность то это в лучшем случае
FR>увеличит производительность на доли процента.

Только вот согласно исследованиям как раз выхлоп меряется как раз в строчках (ну или в более внятных единицах, аля операторы и т.п.), без заметного влияния языка программирования.
Т.е. если у тебя было раньше 100 строчек, а теперь станет 50 строчек, то сделаешь ты их как минимум быстрее.

К>>Или я не понял какие цифры к чему ты относишь

FR>Конечно не понял основная работа именно разработать алгоритм, затраты на кодирование стремятся к
FR>нулю.

Если ты о затратах набирания букв на клавиатуре — безусловно, только к сути вопроса это не относится. Речь же идёт по-моему о решении задачи в рамках средств, предоставляемых языком (вместе с принятыми для него приёмами, парадигмами и т.п.)

Здравствуйте, FR, Вы писали:

FR>Так там не просто с двух концов можно матчить, а сразу структурой, это намного мощнее и списков и массивов.

Можно развернуть? Что значит "сразу структурой".

Здравствуйте, Курилка, Вы писали:

FR>>А с чего ты взял что производительность увиличится в два раза?
FR>>Если в день пишется 50 строк вместо 100 на одинаковую функциональность то это в лучшем случае
FR>>увеличит производительность на доли процента.

К>Только вот согласно исследованиям как раз выхлоп меряется как раз в строчках (ну или в более внятных единицах, аля операторы и т.п.), без заметного влияния языка программирования.
К>Т.е. если у тебя было раньше 100 строчек, а теперь станет 50 строчек, то сделаешь ты их как минимум быстрее.

Выхлоп меняется в функциональности. Закодировать эту функциональность на языке си займет скажем полчаса, найти способ как это сделать 7.5 часов. Если я использую хаскель то закодирую за 15 минут, спасибо очень большая экономия.

К>>>Или я не понял какие цифры к чему ты относишь

FR>>Конечно не понял основная работа именно разработать алгоритм, затраты на кодирование стремятся к
FR>>нулю.

К>Если ты о затратах набирания букв на клавиатуре — безусловно, только к сути вопроса это не относится. Речь же идёт по-моему о решении задачи в рамках средств, предоставляемых языком (вместе с принятыми для него приёмами, парадигмами и т.п.)

А если для решения задачи более чем достаточно средств представляемых любым высокоуровневым языком?
Ладно похоже бесполезно, мы просто не понимаем друг друга

Здравствуйте, z00n, Вы писали:

FR>>Так там не просто с двух концов можно матчить, а сразу структурой, это намного мощнее и списков и массивов.

Z>Можно развернуть? Что значит "сразу структурой".

В рефале скобки в выражении задают сразу структуру дерева.

Например выражение

((a + b) * (c + d))

в языке со списками невозможно разобрать одним сопоставлением,
в рефале же легко:

Tst {
    ((e.0 '+' e.1) '*' (e.2 '+' e.3)) = 1;
    e.9 = 0;
};

Здравствуйте, FR, Вы писали:

FR>А если для решения задачи более чем достаточно средств представляемых любым высокоуровневым языком?
FR>Ладно похоже бесполезно, мы просто не понимаем друг друга

Укажу ещё на гипотезу Сепира-Уорфа.
В принципе ты можешь и на ассемблере писать, только вот на языке более высокого уровня будет удобнее и проще, в следствие как раз более высокого уровня.
Т.е. у тебя выходит, что у нас есть алгорим "в голове" А. Потом алгоритмы на языке программирования, скажем Я1 (на Си) и Я2 (скажем, на хаскеле).
Ты утверждаешь, что разница между процессами кодирования А->Я1 и А->Я2 не имеет значения.
Я же говорю о том, что:
1) у 2 программистов на разных языках будут разные А1 и А2;
2) сами процессы А->Я1 и А->Я2 могут иметь разные лишние "заморочки" не относящиеся к задаче, вплоть до фиговой выразимости идеи программиста в коде;
3) на правах гипотезе: скорее всего в голове у программиста будет некая "смесь" А1/Я1 или А2/Я2, и программист будет или одновременно с решением алгоритма думать о том можно ли его в коде реализовать, или непосредственно уже представлять себе решение в рамках идиом языка.

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

Здравствуйте, Курилка, Вы писали:

FR>>А если для решения задачи более чем достаточно средств представляемых любым высокоуровневым языком?
FR>>Ладно похоже бесполезно, мы просто не понимаем друг друга

К>Укажу ещё на гипотезу Сепира-Уорфа.

Мне ближе гипотеза Эйнштейна, которая утверждает что мы мыслим не словами.

К>В принципе ты можешь и на ассемблере писать, только вот на языке более высокого уровня будет удобнее и проще, в следствие как раз более высокого уровня.
К>Т.е. у тебя выходит, что у нас есть алгорим "в голове" А. Потом алгоритмы на языке программирования, скажем Я1 (на Си) и Я2 (скажем, на хаскеле).
К>Ты утверждаешь, что разница между процессами кодирования А->Я1 и А->Я2 не имеет значения.
К>Я же говорю о том, что:
К>1) у 2 программистов на разных языках будут разные А1 и А2;
К>2) сами процессы А->Я1 и А->Я2 могут иметь разные лишние "заморочки" не относящиеся к задаче, вплоть до фиговой выразимости идеи программиста в коде;

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

http://russian.joelonsoftware.com/Articles/HighNotes.html

Так что дело не только в языке.

К>3) на правах гипотезе: скорее всего в голове у программиста будет некая "смесь" А1/Я1 или А2/Я2, и программист будет или одновременно с решением алгоритма думать о том можно ли его в коде реализовать, или непосредственно уже представлять себе решение в рамках идиом языка.

Да такое явление есть. Но есть задачи которым все это фиолетово. При их решении можно совершенно не учитывать на каком языке они будут кодироватся.

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

По моему опыт и знание парадигм влияет на результат намного сильнее чем язык реализации.

Здравствуйте, FR, Вы писали:

FR>По моему опыт и знание парадигм влияет на результат намного сильнее чем язык реализации.

Согласен, только хороший специалист, использующий неэффективный инструмент для меня выглядит по меньшей мере странно...

Здравствуйте, FR, Вы писали:
FR>Я тут пытаюсь объяснить что есть задачи для которых язык (практически любой высокого уровня) не важен.

Мммм, сорри, перепутал алгоритмическую сложность с вычислительной.

Здравствуйте, FR, Вы писали:

FR>Например выражение

FR>((a + b) * (c + d))

FR>в языке со списками невозможно разобрать одним сопоставлением,
FR>в рефале же легко:
FR>

FR>Tst {
FR>    ((e.0 '+' e.1) '*' (e.2 '+' e.3)) = 1;
FR>    e.9 = 0;
FR>};
FR>

А в чем принципиальная разница?

-- hyperlua :)

fun foo
  | (a :: "+" :: b :: []) :: "*" :: (c :: "+" :: d :: []) :: [] -> 1
  | x -> 0
end

print$ foo([ [1,"+",2],"*",[3,"+",4] ]) ---> 1
print$ foo([1,"+",2])                   ---> 0

Здравствуйте, Курилка, Вы писали:

К>Согласен, только хороший специалист, использующий неэффективный инструмент для меня выглядит по меньшей мере странно...

Я бы понял если это сказал Влад у которого программирование в общем-то ближе к хобби чем к работе.