Фраза о Лиспе...

> А вот для реальных проектов современные лиспы имхо мало подходят. И несмотря на всю свою идеальность и универсальность всё равно сливают более специализированным и прагматичным "быдлоязыкам", как только дело доходит до реальных проектов.

имхо на имхо: да, в _большинстве_ (что значит "не везде" :) - да, "сливает", но 1. по причине "отсутствия наличия" массы кодеров; 2. таки меньшим количеством законченных "батареек".

P.S. Вот если бы LW и/или ACL пошли по пути Trolltech... :) (опять имхо ;)

> А лисперы действительно почему-то молчат.

1. Отсутствие спортивного интереса. 2. Задачка таки вышла совсем небольшая - при едином алгоритме получается сравнение функциональный возможностей имеющихся либ, а не "выразительных свойств" самого языка. 3. Для меня "поддержка" "неофита" (хотя я и сам "зилотом" не являюсь) eugine_kosenko гораздо важнее, чем результат конкурса :)

> Современные языки (python, ruby) очень сильно приблизились к нему по возможностям (я не спорю, что достигнуть лиспа им не удастся (хотя бы в метапрограммировании из-за лиспового синтаксиса)), поэтому лисп не дает такого преимущества, как давал когда-то по сравнению с фортраном и C.

Ну, говорить о различиях "на порядок" можно только о численных характеристиках :) Всё, что я хотел сказать - это то, что в данный момент (на сколько я знаю) _только_ у CL есть _встроенная_ в сам язык возможность переопределения синтаксиса (read-table) и настолько мощная система макропрограммирования (действительно только благодаря синтаксису лиспа). Всё. Что конкретно эти две возможности могут дать кодеру - очень сильно зависит от самого кодера (говорю без ехидства, предвзятого отношения и каких-либо собственных претензий).

По поводу сравнения конкретных реализаций языков - очень хотелось бы сравнить скорострельность/потребление памяти питона+psyco и sbcl :)

На shootout-е есть и sbcl и python + psyco

>1. S-выражения труднее читать и понимать, чем код на том же Питоне. >Во всяком случае, подавляющему большинству людей. :)

Как же народ пишет на Лиспе, если его так трудно понимать ? Может быть Вы не те S-выражения читали ? ;-) IMHO важна не "интуитивно понятная" читабельность, а предельная производительность. Вон Перл вообще не читается "человеком с улицы", но на нем почему-то пишет не малое множество людей.

>2. До сих пор нет нормальных свободных реализаций Лиспа, пригодных >для моих задач.

Так судя по Вашим словам, вообще нет ни одного языка, который был бы полностью пригоден для Ваших задач: для числодробления используете привязки Питона к C/C++/Fortran, для GUI также привязки к Qt (С++) и т.д. Lush по крайней мере позволяет все иметь в одном флаконе, писать высокопроизводительный код прямо на Лиспе, а не цеплять его со стороны.

>Сейчас я занимаюсь гуями на (Py)Qt, и здесь Лисп отпадает хотя бы >по той причине, что нет лисповских привязок для Qt. :)

А я занимаюсь гуями на LispWorks и Qt мне не особо нужен и что ? Кто-то успешно использует CELLS-GTK (пример свободной реализации GUI для CL) и скорей всего по продуктивности обставляет всех остальных (за счет CELLS). Кто-то вообще морды пишет на Java и пристыковывает к Лиспу. А ведь нет никаких противопоказаний сделать Лисповые привязки к Qt, нешто это доказательство, что Лисп такой плохой язык.

>Довольно естественным казалось писать всё это на Лиспе, потом с >Лиспа я плавно перешёл на OCaml, потому что его статическая >типизация в таких задачах рулит.

С чего это она там рулит ?

>Хотя, если вы приведёте мне пример реального проекта, где Лисп >объективно заруливает всех остальных, буду благодарен. :)

Ну например почти все системы символьной алгебры так или иначе являются лиспообразными. IMHO символьное программирование на других языках явно проигрывает Лиспу, т.к. он по сути является DSL для этой области. Учитывая, что эта область не маленькая, то Лисп сразу зарулил в Human Genom Project, насколько я знаю для представления цепочек ДНК и правил оперирования ими ничего лучше Лиспа не нашли. И вообще в биоинформатике он похоже рулит. Вот ссылка посвященная одному из таких проектов: http://nostoc.stanford.edu/Docs/whylisp.html объясняют почему используют Лисп.

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

Потом, если почитать comp.lang.lisp там железячники частно хвалят Лисп, утверждая, что он позволяет верифицировать спецификации и вообще лего вытворять всякие штуки, которые на других языках было бы сделать проблематично.

Вот например одна из историй железячника в comp.lang.lisp http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/1ba1e868...

> На shootout-е есть и sbcl и python + psyco

На каком? На http://shootout.alioth.debian.org/debian/benchmark.php не нашёл

А, нашёл

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=...

Слил psyco :)

> С чего это она там рулит ?

Вообще-то рулит не именно статическая типизация, а наличие в OCaml
алгебраических типов данных. Кстати, на сколько я знаю, для Lisp'а
тоже есть что-то, позволяющее поиметь алгебраические типы.

> В общем Лисп явно рулит там, где сложность проекта зашкаливает, а
> изменчивость спецификации предательски высокая.

Мне кажется, что здесь подойдет любой высокоуровневый (желательно
функциональный) язык с динамической типизацией.

> Слил psyco :)

Кажется ты спрашивал про сравнение скорости работы _и_ требующуюся память.

Однако про потребление памяти (по которому SBCL слил), ты как-то забыл...

И разница по скорости работы в среднем три-пять или около того раз не существенна.

> А я занимаюсь гуями на LispWorks

И на что похожи гуи на LispWorks? У них свой тулкит, или это обёртка вокруг какой-то другой либы?

> Потом, если почитать comp.lang.lisp там железячники частно хвалят Лисп, утверждая, что он позволяет верифицировать спецификации и вообще лего вытворять всякие штуки, которые на других языках было бы сделать проблематично.

Ну и что, я и сам железячник (наверное, бывший :-). И я думаю что если ты слаще C/VHDL ничего в жизни не ел, а это типично для железячника, то и Лисп мёдом покажется.

>И на что похожи гуи на LispWorks? У них свой тулкит, или это >обёртка вокруг какой-то другой либы?

Под разными платформами могут быть разные обертки, но Look and feel совпадает с платформой. Под винду вообще никаких оберток нет, выглядит как обычное виндовое приложение. Под Linux вроде Motif был, под Mac OS может быть тоже над чем-то обертнуто. Главное что написал один раз, работает везде одинаково и выглядит привычно для той платформы, под которую пишется.

>Ну и что, я и сам железячник (наверное, бывший :-). И я думаю что >если ты слаще C/VHDL ничего в жизни не ел, а это типично для >железячника, то и Лисп мёдом покажется.

Там человек ясно пишет, что все он ел и сыт по горло. Ну может Haskell не пробовал, но его трудно позиционировать как средство для создания tool configuring tool. Он однозначно утверждает, что именно макры ему очень помогают и остальные фичи Лиспа.

>Вообще-то рулит не именно статическая типизация, а наличие в OCaml >алгебраических типов данных. Кстати, на сколько я знаю, для Lisp'а >тоже есть что-то, позволяющее поиметь алгебраические типы.

Интересовался не так давно темой обработки текстов на ЕЯ. Да, алгебраические типы могли бы очень полезны, но не необходимы, достаточно средств для символьного программирования. Да и нечто вроде Пролога встроенного также было бы полезным, что в коммерческих Лиспах является нормой.

>Мне кажется, что здесь подойдет любой высокоуровневый (желательно >функциональный) язык с динамической типизацией.

В Лиспе есть динамическая типизация, но посредством макр можно генерить и код со статической типизацией, поэтому: 1) По быстродействию он будет всяко рулить перед просто ФЯ с динамической типизацией 2) Макры позволяют формировать DSL, опираясь на который обеспечить эволюцию программы гораздо легче, чем на базовом языке.

> Кажется ты спрашивал про сравнение скорости работы _и_ требующуюся память.

> Однако про потребление памяти (по которому SBCL слил), ты как-то забыл...

> И разница по скорости работы в среднем три-пять или около того раз не существенна.

Там же смайлик стоял.

А преимущество в скорости имеет просто знаковый характер: sbcl при определённом преимуществе в _самом языке_ ещё и по скорости уделывает _компилируемую_ версию питона. Ничего личного. :)

> Интересовался не так давно темой обработки текстов на ЕЯ. Да,
> алгебраические типы могли бы очень полезны, но не необходимы,
> достаточно средств для символьного программирования. Да и нечто вроде 
> Пролога встроенного также было бы полезным, что в коммерческих Лиспах 
> является нормой.

Но полезны! А средства для символьного программирования есть и в OCaml.
А производительность? Практически используемые средства обработки
текстов на ЕЯ написаны на C++, так как на практике скорость важна. И
здесь OCaml может составить реальную конкуренцию!

P. S. Я не против лиспа, как я уже говорил. Я только за! Это
действительно хороший язык, совокупности возможностей которого нет ни в
одном языке. И для большого количества приложений - это отличный выбор.
Но главный инструмент программиста - его мозг!!! Поэтому хороший
специалист сделает эксклюзивную вещь на асме (просто потратит на это
неоправданно много времени), а идиоту и лисп не поможет.

>Но полезны! А средства для символьного программирования есть и в >OCaml. >А производительность? Практически используемые средства обработки >текстов на ЕЯ написаны на C++, так как на практике скорость важна. И >здесь OCaml может составить реальную конкуренцию!

Ну SBCL вполне может потягаться с С++ как по скорости исполнения, так и тем более по скорости разработки. И OCaml по сумме этих параметров выглядит намного лучше С++. Только почему-то считается, что С++ настолько быстр, что этим даже оправдывается тормознутость разработки на нем. По моим наблюдениям как раз скорость разработки всегда намного важнее скорости выполнения кода, пока чешешься на С++ клиент уже уходит. Т.е. прототипирование очень важно в современном мире, где объективные качества товара менее важны, чем возможность своевременной раскрутки и привлечения клиента.

>Но главный инструмент программиста - его мозг!!! Поэтому хороший >специалист сделает эксклюзивную вещь на асме (просто потратит на это >неоправданно много времени), а идиоту и лисп не поможет.

Согласен. И на С++ есть немало очень хороших вещей, но какой ценой они были созданы, сколько времени хороших специалистов было угроблено этим низкоуровневым языком. А еще некоторые плюсисты говорят, что наличие GC является признаком плохого дизайна языка и приложения, на нем написанного. А отсутствие в своем Blabе нормальных замыканий они просто не видят и городят для компенсации этого весьма жуткие конструкции.

Гы :-)

Таки пробили меня на "слабо", засел оптимизировать. Оказалось, что при
работе с потоками нужно вначале форматировать структуру в строку, тогда
не возникает неожиданных возвратов каретки и концов файла, и сама
программа становится короче. В результате получил общую длину около
1500. Потом оптимизнул еще в паре месть, получил примерно следующее:

Total length                                         1301
Meaning length                                        387
Total thesaurus                                       191
Meaning thesaurus                                     113
Total saturation (%)                                   30
Thesaurus saturation (%)                               59
Total expressiveness (%)                               15
Meaning expressiveness (%)                             29

Думаю, если оптимизировать волновой алгоритм, то Лисп таки обгонит Питон
;-). Попробую щас это сделать.

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

Млин, ну почему в таком случае HOL написана на MoscowML? Если б оно было на Лиспе, так я бы еще лет пять назад к нему пришел.

Сейчас вот подумываю переписать HOL на Лиспе, но уж дюже много работы там, явно задача неподъемная... По крайней мере, страшная. ;-(

> Во-первых, мне 27 лет, и намёки на юношеское-там-что-то идут в сад вместе со своим отправителем.

Дыкть ведь, вьюношество -- это не возраст. Это состояние души ;-).

> Во-вторых, на личности переходите именно Вы, поскольку аргументов у Вас в виде красивого кода, как я вижу, нет.

Теперь есть. То, что Вы слегка торопитесь с выводами, так это еще как бы один аргумент в пользу сами знаете чего ;-).

> И в четвёртых, про "не боитесь и т.д.": не боюсь. Мне Вашего кода боятся нечего :) Вы из тех людей, что любят всех учить и теоретизировать, как нужно делать, а как до дела доходит... начинаются гнилые отмазки, мол, это жизнь, заказчики, небо голубое, и т.д. Ведите себя по-мужски, умейте проигрывать молча.

Вы поторопились приписать мне поражение :-). Как минимум по одному параметру Лисп уже вернул свои позиции, при необходимости вернет и другие.

Насчет "учить и теоретизировать" возражать не буду. Вполне возможно, что Вам и не приходилось общаться с реальными заказчиками. Очень даже может быть, что это Вам и не нужно. Так что, оставайтесь в счастливом неведении :-).

> Очередная версия на питоне:

Total length 1754 Meaning length 714 Total thesaurus 218 Meaning thesaurus 175 Total saturation (%) 41 Thesaurus saturation (%) 80 Total expressiveness (%) 12 Meaning expressiveness (%) 25

> Будем добавлять новые фичи, ну там монстров, NPC, прокачку персонажа?

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

В этих условиях нужно менять условия соревнования. Но еще раз повторюсь: я думаю, что оно того не стоит.

> Очередная версия на питоне:

Total length                                         1754
Meaning length                                        714
Total thesaurus                                       218
Meaning thesaurus                                     175
Total saturation (%)                                   41
Thesaurus saturation (%)                               80
Total expressiveness (%)                               12
Meaning expressiveness (%)                             25

> Будем добавлять новые фичи, ну там монстров, NPC, прокачку
> персонажа?

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

В этих условиях нужно менять условия соревнования. Но еще раз
повторюсь: я думаю, что оно того не стоит.

> Ну лично я вообще в синтаксическом анализе/разборе вообще ни в зуб копытом. Это узкоспецифическая задача.

А сетевое взаимодействие не? Бо лично для меня реализация "мультиплексирования" и "многопользовательских" приложений -- почти такие же специфические задачи.

> Т.е. преимущества лиспа проявляются только на крупных проектах, которых не существует :-)

Опять за рыбу гроши ;-).

Я ж уже упоминал, что типичное преимущество лиспа проявилось на таком крупном проекте, как Autocad. После того, как мы поигрались с роботами, стало еще и понятно, почему там рулит именно Лисп. Попробуйте представить себе Питон в качестве языка управления САПР :-).

> Как минимум есть множество разношерстных codewalkers

Хотя бы один, в качестве примера?

Думаю последняя версия на OCaml, изменения чисто косметические,
алгоритмы не менялись вообще. Если будет новая более сложная и _четко
сформулированная_ задача, то в свободное время возьмусь.

[adv_world.ml]
let find map c =
  let rec find_aux i =
    if i = Array.length map then raise Not_found
    else try (i, String.index map.(i) c) with Not_found -> find_aux (i + 1)
  in find_aux 0

let get_items map =
  let rec get_items_aux accu = function
      (i, j) when i = Array.length map      -> accu
    | (i, j) when j = String.length map.(i) -> get_items_aux accu (i + 1, 0)
    | (i, j) -> get_items_aux (if map.(i).[j] = '$' then (i, j) :: accu else accu) (i, j + 1)
  in
  get_items_aux [] (0, 0) ;;

let num_of_items map = List.length (get_items map) ;;

[adv_world.mli]
val find : string array -> char -> int * int
val get_items : string array -> (int * int) list
val num_of_items : string array -> int 

[advserver.ml]
let serve_cmd map ((x, y), is_empty) = function
    "pickup" when is_empty && map.(x).[y] = '$' ->
      map.(x).[y] <- ' ' ;
      ((x, y), false)
  | "drop" when not is_empty && map.(x).[y] <> '$' ->
      if map.(x).[y] <> '.' then map.(x).[y] <- '$' ;
      ((x, y), true)
  | cmd ->
      let cmds = [("north", (-1, 0)); ("south", (1, 0)); ("west", (0, -1)); ("east", (0, 1))] in
      let x', y' = (function (dx, dy) -> x + dx, y + dy) (try List.assoc cmd cmds with Not_found -> 0, 0) in
      ( if (try ignore map.(x).[y]; false with Invalid_argument _ -> true) || map.(x').[y'] = '#' then
          x, y else x', y' ), is_empty

let send_stat out_channel map ((x, y), is_empty) =
  let map' = Array.map (function line -> String.copy line) map in
  map'.(x).[y] <- '@' ;
  Marshal.to_channel out_channel map' [] ;
  Marshal.to_channel out_channel
    [ if Adv_world.num_of_items map = 0 && is_empty then "You won!" else "Game is in progress";
      if is_empty then "Your hand are empty" else "You carry an item";
      if map.(x).[y] = '$' then "Here lies 1 item" else "Here lies 0 items" ] [] ;
  flush out_channel

let rec input ic =
  try let line = input_line ic in line :: input ic with End_of_file -> []

let serve in_channel out_channel =
  let map = Array.of_list (input (open_in Sys.argv.(1))) in
  let rec loop state =
    send_stat out_channel map state ;
    try loop (serve_cmd map state (input_line in_channel)) with
      End_of_file -> ()
  in
  loop ((Adv_world.find map '.'), true) ;;

Unix.establish_server serve (Unix.ADDR_INET (Unix.inet_addr_loopback, int_of_string Sys.argv.(2))) ;; 

[hclient.ml]
let in_channel, out_channel = Unix.open_connection
  (Unix.ADDR_INET ((Unix.inet_addr_of_string Sys.argv.(1)), int_of_string Sys.argv.(2)))
in
while true do
  Array.iter (Printf.printf "%s\n") (Marshal.from_channel in_channel : string array) ;
  List.iter (Printf.printf "%s\n") (Marshal.from_channel in_channel : string list) ;
  flush stdout ;
  Printf.fprintf out_channel "%s\n" (read_line ()) ;
  flush out_channel
done ;; 

[roboclient.ml]
let dfs map (sx, sy) =
  let dxy = [(-1, 0); (1, 0); (0, -1); (0, 1)] in
  let f = Array.init
    (Array.length map) (function i -> Array.make (String.length map.(i)) (-1))
  in
  let q = Queue.create () in
  Queue.push (sx, sy) q ; f.(sx).(sy) <- 0 ;
  while not (Queue.is_empty q) do
    let x, y = Queue.pop q in
    List.iter
      (function (x', y') -> Queue.push (x', y') q ; f.(x').(y') <- f.(x).(y) + 1)
      ( List.filter
          ( function (x', y') ->
              (try ignore map.(x').[y']; true with Invalid_argument _ -> false) &&
                map.(x').[y'] <> '#' && f.(x').(y') = -1 )
          (List.map (function (dx, dy) -> x + dx, y + dy) dxy) )
  done ;
  f

let find_path f (x, y) =
  let rec find_path' (x, y) path rev_path =
    let dxy = [ ((-1, 0), ("south", "north")); ((1, 0), ("north", "south"));
                ((0, -1), ("east", "west")); ((0, 1), ("west", "east")) ] in
    if f.(x).(y) = 0 then path @ ["pickup"] @ (List.rev rev_path) @ ["drop"] else
      let find_path_aux (dx, dy) (dir, rev_dir) =
        if try f.(x + dx).(y + dy) + 1 = f.(x).(y) with Invalid_argument _ -> false then
          find_path' (x + dx, y + dy) (dir :: path) (rev_dir :: rev_path)
        else []
      in
      List.fold_right
        (function (d, dirs) -> (function [] -> find_path_aux d dirs | path -> path)) dxy []
  in
  find_path' (x, y) [] []

let in_channel, out_channel = Unix.open_connection
  (Unix.ADDR_INET ((Unix.inet_addr_of_string Sys.argv.(1)), int_of_string Sys.argv.(2)))
in

let map = (Marshal.from_channel in_channel : string array) in
Array.iter (Printf.printf "%s\n") map ;
List.iter (Printf.printf "%s\n") (Marshal.from_channel in_channel : string list) ;

List.iter
  ( function (x, y) ->
      List.iter
        ( function cmd ->
            Printf.fprintf out_channel "%s\n" cmd ;
            flush out_channel ;
            Array.iter (Printf.printf "%s\n") (Marshal.from_channel in_channel : string array) ;
            List.iter (Printf.printf "%s\n") (Marshal.from_channel in_channel : string list) )
        (find_path (dfs map (Adv_world.find map '@')) (x, y)) )
  ( Adv_world.get_items map ) ;;

Кстати, вы учитываете в своих подсчетах hclient?

> Попробуйте представить себе Питон в качестве языка управления САПР :-).

Превосходно себе представляю. В большинство САПР-ов в области FPGA/VHDL встроен интерпритатор TCL (тяжёлое наследие далёкого UNIX-ового прошлого). Это просто ужоснах. Бывают даже хреновины написаные на Tcl/Tk (Modelsim)

Так что питон там бы пахал превосходно это сто пудов. Однажды даже пришлось писать на питоне скрипт, который генерировал скрипты на TCL чтобы сделать одну штуку :-)

> Total length                                         1754
> Meaning length                                        714
> Total thesaurus                                       218
> Meaning thesaurus                                     175
> Total saturation (%)                                   41
> Thesaurus saturation (%)                               80
> Total expressiveness (%)                               12
> Meaning expressiveness (%)                             25

Wow, but is this good or bad? (c)

Может ты опубликуешь последнюю сводную таблицу  скомментариями, типа
больше лучше или меньше лучше. Вот например Thesaurus saturation 80%
это хорошо или плохо?

>> Будем добавлять новые фичи, ну там монстров, NPC, прокачку
>> персонажа?

> Думаю, оно того не стоит.

Да я, собственно, пошутил.

Может более другую задачу?

>Млин, ну почему в таком случае HOL написана на MoscowML

А почему Linux написан на Си ?

> Думаю последняя версия на OCaml

Total length                                         1340
Meaning length                                        437
Total thesaurus                                       151
Meaning thesaurus                                      99
Total saturation (%)                                   33
Thesaurus saturation (%)                               66
Total expressiveness (%)                               11
Meaning expressiveness (%)                             23

> Кстати, вы учитываете в своих подсчетах hclient?

Да, в подсчет идет весь код.

>> Млин, ну почему в таком случае HOL написана на MoscowML

> А почему Linux написан на Си?

Потому что это подходящий язык для соответствующей архитектуры. Для Лисп-машин он был бы написан на Лиспе.

HOL -- система символических вычислений (точнее, доказательства теорем). По идее, довольно удачная область приложения для Лиспа. Почему нет?

> Wow, but is this good or bad? (c)

По идее, плохо. Фактически по общей длине догнало неоптимизированную версию Лисп. Скорее всего, где-то есть лишний код.

> Вот например Thesaurus saturation 80% это хорошо или плохо?

Это значит, что 80% слов в программе не являются ключевыми. Я бы определил это, как то, что в программе вводится много новых сущностей, например, в разных местах одна и та же по смыслу переменная называется по разному, есть определенные, но неиспользуемые переменные и т.п. С другой стороны, это может обозначать синтаксическую бедность программы, небольшое число базовых конструкций.

Я, ведь определял это все несколько страниц назад.

> Может ты опубликуешь последнюю сводную таблицу скомментариями, типа больше лучше или меньше лучше.

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

> Может более другую задачу?

Не знаю. Может быть, не сейчас и в отдельной теме. Я пока пас. Если найдутся другие желающие, то могу оформить и опубликовать мерялку.

> Превосходно себе представляю.

Это немного не те САПР :-).

> Может ты опубликуешь последнюю сводную таблицу скомментариями, типа больше лучше или меньше лучше.

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

В общем, как оказалось, у нынешнего лидера есть два существенных недостатка. Во-первых, у клиента нет интерактивного режима, работает только робот. А во-вторых, я не обратил внимание, что большая часть "мусора" по работе с сокетами оказалась спрятана "под коврик" в нестандартном модуле async_io. Если считать код с этим модулем, то получается довольно таки грустно:

Total length 4442 Meaning length 2003 Total thesaurus 401 Meaning thesaurus 352 Total saturation (%) 45 Thesaurus saturation (%) 88 Total expressiveness (%) 9 Meaning expressiveness (%) 18

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

Пишу это не из вредности, а справедливости для. Если уж начали объявлять друг друга лузерами, так давайте тогда играть по правилам. Сейчас проверю Окамл и второго питона (от redvasily).

> Думаю последняя версия на OCaml

$ ocamlc -g unix.cma adv_world.cmo roboclient.ml -o roboclient
File "roboclient_new.ml", line 37, characters 0-2:
Syntax error

Предпоследняя версия робота пошла. Если ошибка не будет исправлена,
придется взять предпоследнюю версию.

Еще одно минорное замечание: похоже, программа принимает только
IP-адреса.

У меня вопрос по методике.

Что произойдёт если взять две версии одной программы:

1. В первой версии используются длинные функции

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

Как будут соотносится эти программы с точки зрения этой методики анализа?

Как в питоне оценивается return и '.'?

> Как будут соотносится эти программы с точки зрения этой методики анализа?

Во второй программе выше выразительность (это хорошо), но одновременно выше насыщенность (это плохо). Считается, что во втором случае читатель программы должен освоить больше понятий, то есть, потратить больше сил на осмысление (высокая насыщенность), но после этого он быстро поймет основную суть алгоритма (высокая выразительность). Конечно, недостатком является то, что в реальности многие "новые" (с точки зрения методики) понятия таковыми не считаются и доступны читателю из внешнего опыта и на интуитивном уровне. Однако, оценить формально "новизну" и "интуитивность" нереально, и жесткие условия приняты для того, чтобы наказывать попытки "оптимизации кода" в ущерб читабельности.

> Как в питоне оценивается return и '.'?

Как отдельные ключевые слова.

>> Как в питоне оценивается return и '.'?

> Как отдельные ключевые слова.

Имхо, это несправедливо. В таком случае программы написанные на языках в которых результат последней операции _автоматически_ счетается результатом функции (Ruby, Lisp) находятся в более выгодоном положении относительно языков где такого нет (Python, C).

Т.е. в Lisp implict return, который присутствует, но не идёт в зачёт.

И то что '.' считается как ключеввое слово, автоматически ставит программы написанные с ООП в невыгодное положение по сравнению с процедурными или функциональными программами (при данной методике).

P.S. Не выложишь последнюю лисповерсию на какую-нибудь rapidshar-у?

P.P.S. У тебя автоколлект происходит на сервере или на человеческом клиенте?

У меня это происходит на сервере, а потом скидывается назад сразу куча промежуточных состояний мира, елси это перенести в клиент, то это должно дать изрядное упрощение.

> Имхо, это несправедливо. В таком случае программы написанные на языках в которых результат последней операции _автоматически_ счетается результатом функции (Ruby, Lisp) находятся в более выгодоном положении относительно языков где такого нет (Python, C).

> Т.е. в Lisp implict return, который присутствует, но не идёт в зачёт.

Угу. А лисперы недавно точно так же заявляли о дискриминации Лиспа, ибо на выражении a+b обычные языки имеют всего три лексемы, а в Лиспе -- аж целых пять.

> И то что '.' считается как ключеввое слово, автоматически ставит программы написанные с ООП в невыгодное положение по сравнению с процедурными или функциональными программами (при данной методике).

Угу. А то, что скобки считаются, как ключевое слово, автоматически ставит программы, написанные на Лиспе в невыгодное положение с другими языками. Ибо при таком подходе обращение к элементам структуры в нем требует четырех лексем вместо трех. И потом, в C++ и Эйфеле, например, разрешено опускать обращения к экземпляру, а в Питоне -- нет. Будем жаловаться на дискриминацию отдельно взятого Питона?

Собственно, в предпоследнем варианте на Лиспе обращение к элементам структуры сожрало около 200 слов. Я удалил это грязным хаком, избавившись от структуры и определив параметры мира глобально. Мне это не нравится, так как при таком подходе невозможно организовать, например, разделение миров для пользователей. Но как заметил наш коллега, для победы в состязании все средства хороши, ведь разделения миров не было в начальной спецификации. Тем не менее, я надеялся решить эту проблему, перейдя на классы, но, как оказалось, CLOS органически к этому не приспособлен. Его единственная задача -- предоставление механизма виртуальных функций. В туториале так и написано: в CLOS данные -- отдельно, функции -- отдельно (там вообще сказано -- не решайте проблему классами, если ее можно решить структурами :-). С другой стороны, есть приятные макросы with-slot(s), по семантике эквивалентные паскалевскому with (будем обвинять методику в дискриминации C++ по отношению к Паскалю?), но работают они только для доступа к слотам. Тем не менее, поколдовав часок с макросами, мне удалось определить полноценные функции-члены. Принцип в том, что функция определяется через макро defun-with-self, который вызывает макро defun, добавляя неявный ключевой параметр self, а в теле производит неявное связывание по with-slots. Кроме того, для функции определяется макровызов с неявной подстановкой self, то есть, при вызове из другой функции-члена структура подставляется автоматически, как в C++ и Эйфеле. Получается, что прикрутить сокрытие экземпляра в Лиспе оказалось весьма несложно, чего, похоже, не скажешь о Питоне. Причем я подозреваю, что мое решение -- чудненький самодельный велосипед. Странно, что это до сих пор не включено в стандарт -- проблема ведь на виду.

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

> Не выложишь последнюю лисповерсию на какую-нибудь rapidshar-у?

Дыкть, она с моего сайта никуда и не уползала:

http://aroks.kiev.ua/pub/wiki/ProgrammaLabirinta?show_files=1#files

> P.P.S. У тебя автоколлект происходит на сервере или на человеческом клиенте?

На клиенте, но это несущественно. Библиотека общая, представление мира одинаковое.

>Странно, что это до сих пор не включено в стандарт -- проблема ведь >на виду.

Потому что в CL используются мультиметоды и self получается неоднозначный.

Вот последняя версия на питоне. Полностью соответствует спецификации. Свистелки и перделки вырезаны.

http://rapidshare.com/files/1245074/advworld2.rar.html

> >Странно, что это до сих пор не включено в стандарт -- проблема ведь >на виду.

> Потому что в CL используются мультиметоды и self получается неоднозначный.

И с "макровызовами" никак не состыкуешь apply/funcall, что накладывает определённые органичения (иногда, я бы сказал, непреодолимые - eval не прелагать ;)

Вот ещё на какое чудо наткнулся. Надо пощупать... ;)

http://www.ephemeralsecurity.com/mosquito-lisp

Или у кого уже есть опыт "общения"? :)

Вот работающая версия, в предыдущей не поставил знак ";;":
http://sigma.by.sigma.neolocation.net/satmech/LOR-contest-2006.10.30-23.36.tar

Кстати, ";;" - это одна лексема в OCaml.

Вот еще более новая версия, в которой убраны обертки вокруг функций, использующих хвостовую рекурсию.
http://sigma.by.sigma.neolocation.net/satmech/LOR-contest-2006.10.31-00.05.tar

Вопрос: Array.length учитывается как 3 лексемы в вашей программе?

Вообще то, думаю OCaml проиграет, так как в данной программе нет особого
применения фичам этого языка. А lisp все-таки язык более высокого уровня,
да и стандартная библиотека его побогаче.

>>> Как в питоне оценивается return и '.'?

>> Как отдельные ключевые слова.

> Имхо, это несправедливо.

ИМХО это справедливо, что недостаток наречия является недостатком наречия.

> И то что '.' считается как ключеввое слово, автоматически ставит программы написанные с ООП в невыгодное положение по сравнению с процедурными или функциональными программами (при данной методике).

ООП в невыгодном положении при любой методике. Или ты хочеш, чтобы на явные недостатки закрывали глоза только потому что ооп "это типо круто"?

> ИМХО это справедливо, что недостаток наречия является недостатком наречия.

Жжошь. А чёрное это чёрное, а белое это белое, а сепульки это сепульки. И т.д.

Какое это имеет отношение к теме разговора, к питону или лиспу?

> ООП в невыгодном положении при любой методике. Или ты хочеш, чтобы на явные недостатки закрывали глоза только потому что ооп "это типо круто"?

Пример:

ООП: sys.stdin.readline().strip().replace('a', 'b').lower()

VS

Функции: lower(replace('a', 'b', strip(readline(sys_stdin))))

Одно и то же, версия с ооп, имхо даже лучше читается, т.к. действия записыны в том порядке, в каком они производятся, но при данной методике подсчёта верия с ООП будет в пролёте из-за '.'

Кстати, я уже осилил первую главу SICP, а версии программы на лиспе с БД от тебя мы так и не дождались, хотя ты её обещал 'завтра' пару недель тому назад :-)

Этта, You talk-talk, do you walk-walk?

> Кстати, ";;" - это одна лексема в OCaml.

Знаю, не такой уж неуч. В свое время имел честь знакомиться с MosML, там тоже так.

> Array.length учитывается как 3 лексемы в вашей программе?

Да, причем все три -- как ключевые слова.

> Вообще то, думаю OCaml проиграет, так как в данной программе нет особого применения фичам этого языка.

Так ведь с Лиспом примерно та же история.

Так, этаво, статистику давай... ;)

> Какое это имеет отношение к теме разговора, к питону или лиспу?

Ну ты же предлагал галимый недостаток питона не считать недостатком потому что лисп этого недостатка лишён?

>> ООП в невыгодном положении при любой методике. Или ты хочеш, чтобы на явные недостатки закрывали глоза только потому что ооп "это типо круто"?

> Пример:

а попробуй пример позамысловатее

> Кстати, я уже осилил первую главу SICP, а версии программы на лиспе с БД от тебя мы так и не дождались, хотя ты её обещал 'завтра' пару недель тому назад :-)

Ну чё делать, некогда мне эту чюму асиливать :( И в ближайшем времени не предвидится. Хотя "пару недель назад" она всё равно была у меня в планах по несколько другим делам. А тебе разве не хватило того примера, где отсылаются письма всем престарелым? питон тамо слил почорному ведь...

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

Нифига он там не слил. На большем примере, прога с БД, adventure он смотрелся вполне неплохо (скажу, осторожно :-) по сравнению с лиспом.

Bugmaker, ты споришь по принципу женской логики, т.е. если всё время повторять что питон это отстой, то тот кто отправит пост последний, тот и прав.

Смотрел бы ЛОР не в опере, а в GoldEd-е, сделал бы на тебя TWIT