Re: Perl or Python?
On Wed, 25.03.2009 00:14:12 , Alexey Pechnikov wrote:
> Hello!
>
> On Tuesday 24 March 2009 22:29:36 Тихон Тарнавский wrote:
> > Вы сказали что-то вроде "транспонирование матрицы -- это ерунда, это и
> > си с sql-ем сделать не сложнее". Я привёл другой пример. В файле 92
> > строки. Из них минимум треть добавена исключительно в целях, нужных
> > для статьи; в частности, для рассмотрения некоторых искуственно
> > введённых сюда приёмов и для удобства построчного комментирования.
> > Плюс многочисленные проверки, которые на функциональном языке тоже
> > выглядели бы лаконичнее. Итого строк 50 максимум. Добавим реализацию
> > матаппарата в том объёме, который нужен для этой функции -- пусть ещё
> > 50 строк (с большим запасом). Для императивного языка даю фору --
> > порядок. В тысячу строк уложитесь? Уверен, что нет. Если два порядка
> > форы дам -- тогда можно. Намного меньше вряд ли.
>
> Согласен, что для символьных преобразований императивный подход использовать
> противопоказано. Что касается функционального... пожалуй, в основном нужно
> динамическое выполнение кода, а map и apply просто удобные обертки для
> итератора и стэка. Но в случае
> apply #'map 'list matrix
> явно лучше обойтись без map и apply, если они в данном случае требуют каких-то
> "хаков" с комментированием (#) и апострофами (это что, игра на ошибке
> реализации какого-то диалекта лиспа?!).
>
> Пусть матрица содержит скалярное или векторное поле. Диффузионные уравнения и
> т.п. оперируют с элементом и его "соседями" (простое численное
> дифференцирование требует использования как минимум 1 соседней точки,
> симметричное - двух соседних), то есть обработка императивная по сути.
>
> Если в матрице находится нечто символьное, то возникнет задача индексации и
> различных выборок и оптимальнее будет использование SQL. Понятно, что в
> функциональном языке различные итерации и фильтры реализовать легко, но
> индексация и групповые функции (что-то вроде select sum(value) from test where
> value>1) станут проблемой. Я не видел функциональных реализаций b-tree и r-
> tree индексов и мне кажется проще их реализовать на императивных языках
> (интересно, существуют ли для них высокопроизводительные и устойчивые к сбоям
> реализации на функциональных языках).
Прошу прощения, но мне теперь уже с каждым письмом, чувствую, будет
стоить таких усилий вернуть дискуссиию к её теме от околичных
рассуждений, что я бросаю это неблагодарное занятие.
--
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru
Reply to: