Re: Perl or Python?

[Aleksey Cheusov <vle@gmx.net>]

> Давай всё-таки не будем игнорировать разницу между утверждениями "99%
> алгоритмов -- императивные" и "1% алгоритмов -- функциональные".
Пардон, между этими утверждениями я разницы не вижу :-)

> Даже если второе верно, то не станешь же ты утверждать, что других
> парадигм вообще не существует
Конечно, не стану. И haskell и aldor и erlang и oz и т.д. изучать нужно
и весьма полезно.  _Как минимум_ мозг размять. Но не нужно предлагать их
в качестве безальтернативного первого ЯП. Эта мысль совсем не бесспорна.

> или что они входят в этот же 1% алгоритмов?
>
> Опять же: я не спорю, что 99% задач (и даже больше) можно решить
> императивным подходом. Я лишь говорю, что далеко не для 99% именно
> этот подход окажется оптимальным. Пример, который я лучше всего знаю:
> тот самый внутренний язык ABBYY, о котором я говорил выше.
Абсолютное большинство проблемно-ориентированных языков, с которыми по
работе (Invention Machine corp.) приходится сталкиваться мне --
декларативные.  Но при этом к функциональщине ни один их них не имеет
никакого отношения. А вот реализация практически всегда проще делается с
помощью императивных ЯП. Есть редкие исключения.

> Его задача -- поиск плавающих полей на документе, с целью их
> последующего распознавания. Изначально эта задача решалась на C/C++
> (это было ещё до меня). Со временем стало понятно, что нужен свой
> язык, который реализовали, насколько я знаю, на тех же C/C++. Язык
> менялся на протяжении времени, постепенно всё лучше затачиваясь под
> свои задачи; я застал одно фундаментальное изменение и множество
> косметических. Но ни в одной из реализаций я не назвал бы этот язык
> императивным даже приблизительно.

Чем-то до боли знакомым повеяло.

@inproceedings{cheusov_wre,
  author    = {Aleksey Vladimirovich Cheusov},
  title     = {The word-based regular expressions in Computational Linguistics},
  booktitle = {Proceedings of the 7th International conference, Pattern Recognition and Information},
  pages     = {208--213},
  volume    = {1},
  year      = {2003},
  location  = {Minsk},
}

Плюс еще finite state transducers и многое многое другое...

>> > А самая трудная категория обучаемых -- это как раз были люди,
>> > испорченные императивным подходом (в данном случае я отвечаю за свои
>> > слова).
>> Ну вот опять, "испорченные императивным подходом"...  Может, они были
>> просто испорченные, Безотносительно имеративного подхода?
> Если бы ты при цитировании не проигнорировал мою классификацию, то
> было бы видно, что корреляция достаточно убедительная. Повторюсь:
> возможно проблема в том, _как_ их учили. Но вот в учебниках по
> императивным языкам я эту проблему видел массово. Когда я преподавал
> основы Си, я каждую свою лекцию писал с нуля, потому что то, что мне
> дали, не удовлетворило меня ни в какой своей части. А вот лекции и
> учебники по функциональному или логическому программированию, которые
> я видел позже, не обладали этим недостатком за единственным
> исключением.
Учить нужно преимущественно не конкретным ЯП, и не только парадигмам, в
них заложенным. Но еще и правильному дизайну и общей культуре
программирования. И нет, правильный дизайн - это никакой не UML.  И
делать это можно с помощью open source. Open Source - это Большая
Школа. И этим можно и нужно было бы воспользоваться, вовлекая студентов
во всякие программы типа SoC (туда и некоторых преподавателей засунуть
не мешало бы :-/). На мой взгляд, Школа - это одна из главных функций
open source, как социального явления.

Я не против того, что книги по ФП как правило более академичны, чем по
конкретным императивным ЯП, это очевидно и сомнений не вызывает.  Но
хороших книг полно по другим, не менее важным, а скорее даже более
важным, темам, например, по алгоритмам. А книги по ФП на мой взгляд
довольно однобоки, практически все они об одном и том же: "Ребята,
рекурсия и строгое математическое определение (постановка, понимание,
...)  вашей задачи - это очень важно".  Это действительно важно и очень
помогает и при работе с императивными языками тоже, но это отнюдь не
серебряная пуля, и этого недостаточно. У фанатиков же всяких лиспов
формируется весьма однобокое представление об CS в целом.
Большинство их них даже не понимают, за что они борятся, за чистоту
функциональной парадигмы или за динамичность языка, совершенно не
понимая, что это абсолютно разные, никак не связанные, вещи.

>> > Они настолько привыкли мыслить линейно, что подняться над задачей и
>> > оценить картину в целом, а не только прокладывать отдельные маршруты,
>> > были не в состоянии; а там без этого никак.
>> Способность человека "подняться" над задачей - не зависит от того, что
>> он предпочитает, функциональный или императивный подход. Я, например,
>> предпочитаю декларативный, если это возможно. И это НИКАК не связано с
>> функциональщиной в общем случае. Умею я подняться над задачей в этом
>> случае?
> Мы ведь говорим не о предпочтениях, а об обучении, верно? ФП же, снова
> повторюсь, это только пример, и его многие советуют, на мой взгляд,
> ещё и потому, что хороших книг по нему больше, чем по тому же
> логическому.
И значительно меньше, чем, допустим, по алгоритмам. И?  Или вот, скажем,
Пратт, Зелковец "Языки программирования: разработка и реализация".
Отличная книга! Но не в качестве первой, конечно.  Я начинал изучать
программирование по книгам Вирта, Ахо, Рейнгольда, Нивергельда, Део,
Кнута, Ульмана и прочих в 80-х. Полно отличной литературы помимо книг по
ФП. И книги эти вообще не касались конкретного ЯП. У меня в распоряжении
был только MSX бейсик, не повезло мне родиться в столицах, увы.

Основа основ программирования -- это алгоритм. Функциональная же
парадигма -- всего лишь одна, далеко не всегда самая удачная, форма его
представления.

Человек, хорошо знающий базовые алгоритмы -- не только способен освоить
"современные технологии", но и создать их. И я не могу этого сказать про
специалиста по ФП. По моим наблюдениям лиспофилы в алгоритмах "плавают"
примерно как я в haskell-е.

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

-- 
Best regards, Aleksey Cheusov.