Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Здравствуйте, vdimas, Вы писали:
V>>n+1 надо сделать у кеш-счетчика каждого элемента списка ГА>Нет, не надо. Точно так же, как не надо это в С++. ГА>А спорить дальше не вижу смысла, уже все сказал и не знаю, как по-другому:
Извини, но я как программист могу захотеть получить cdddr списка и далее работать с ним. Твоя кешированная схема не сработала. А если делать коррекцию n+1 каждого элемента списка, после вставки в конец, то это все теряет свой первоначальный смысл.
ГА>Вам нравится утверждать, что С++, Ява и C# — достаточно универсальные языки, и все остальные можно посылать подальше, даже не попробовав их на тех задачах, в которых они сильны (кстати, вы писали, что разрабатываете парсеры — так это же задача номер раз для ML-языков, примеров найдете немало).
Да, находил. И пробовал (правда давно). Быстродействие не выдерживало никакой критики и ресурсы тоже. Когда-то это было критично, поэтому я писал парсеры/лексеры на С/С++.
Понимаешь, если делать парсер по классике (лексический + синтаксический анализ, автоматные модели или с предпросмотром K), то глубоко пофиг на чем его писать. Другое дело, что на некоторых инструментах удобно моделировать (играть) с грамматикой. Это есть и именно для этого и использовалось.
Кстати, когда-то я подобную "игруху" делал и на С++, т.е. программа выглядела примерно так:
NTerm A, B, C;
A = 'a' | 'b';
A = C & B;
C = 'c' | C & 'c';
B = A & C | C & C & A | A;
B = 'b'
И нисходящий разбор к нему. Вполне позволяла "играть", менять приоритет правил и т.д. Куда уж минимальнее.
ГА>Я убежден в обратном.
Я вообще ни в чем не убежден и по-сути действую по обстоятельствам.
Виртуально есть обсуждение подходов, реально у меня стоит задача подбора людей в свою команду и я даже не могу найти нормальных спецов на С++/C#/Java. Про обсуждаемые языки вообще говорить не приходится. Не все, к сожалению живут в Москве, где срабатывают законы больших чисел, и находятся несколько человек даже на экзотику.
--------
Сам я слежу за ходом дисскуссий с удовольствием и уже планирую "как только так сразу" поближе познакомиться с Haskel.
Здравствуйте, reductor, Вы писали:
V>>Да верю, только нафига это все? Если для каких-то задач потребуется ежемиллисекундно узнавать длину вектора, то лучше взять подходящий язык, не правда ли?
R>и
V>>Понимаешь, универсальные языки потому и являются универсальными, что на них легко делать весьма многое, V>>вот за пол-часа на С# (мини-лисп, к нему легко прикрутить парсинг входного потока):
R>Я или чего-то не понимаю или здесь утверждение, что окамл или лисп менее универсальны, чем С#?
OCaml — нет (насколько я понял из вчерашнего моего первого знакомства с ним), Лисп — да, менее универсален. То, что я показал, позволяет прямо в C# программе "орудовать" по лисповым правилам игры. Я даже уже продумал как обыграть макросы Нетрудно это все превратить в интерпретатор или даже в компилятор Лиспа (там и макросы легче будет сделать). Сделать же наоборот на Лиспе — прямо в коде писать по правилам C# (или интерпретатор или компилятор C#) не так уж просто. Первое — вообще нереально.
V>Извини, но я как программист могу захотеть получить cdddr списка и далее работать с ним. Твоя кешированная схема не сработала. А если делать коррекцию n+1 каждого элемента списка, после вставки в конец, то это все теряет свой первоначальный смысл.
Это потому что вы не заметили пары функций (они очень короткие, легко не заметить):
let cs_list_head (CSList (lst, _)) = List.hd lst
let cs_list_tail (CSList (lst, n)) = CSList (List.tl lst, n-1)
Про инкапсуляцию в модуль я тоже вроде говорил. (Да, в С++ я могу откастить итератор к какому-нибудь _ListNode<T>* и вперед, к новым вершинам, зачем мне insert(), когда есть _ListNode<T>* Pnext , это разве аргумент?).
V>Кстати, когда-то я подобную "игруху" делал и на С++, т.е. программа выглядела примерно так:
V>
V>NTerm A, B, C;
V>A = 'a' | 'b';
V>A = C & B;
V>C = 'c' | C & 'c';
V>B = A & C | C & C & A | A;
V>B = 'b'
V>
V>И нисходящий разбор к нему. Вполне позволяла "играть", менять приоритет правил и т.д. Куда уж минимальнее.
Симпатишно! Еще чуть-чуть, и будет буст::спирт . Жаль только, вы реализацию этой красоты не привели.
Ладно, не буду играть на чужом поле, я компиляторы не пишу.
V>Я вообще ни в чем не убежден и по-сути действую по обстоятельствам.
V>Виртуально есть обсуждение подходов, реально у меня стоит задача подбора людей в свою команду и я даже не могу найти нормальных спецов на С++/C#/Java. Про обсуждаемые языки вообще говорить не приходится. V>Не все, к сожалению живут в Москве, где срабатывают законы больших чисел, и находятся несколько человек даже на экзотику.
Я нашел нишу ФЯ лично для себя — прототипирование. Здесь эти причины не действуют.
V>Сам я слежу за ходом дисскуссий с удовольствием и уже планирую "как только так сразу" поближе познакомиться с Haskel.
Аналогично!
Здравствуйте, eao197, Вы писали:
ГА>>Я нашел нишу ФЯ лично для себя — прототипирование. Здесь эти причины не действуют. E>А почему не эту роль, к примеру, Smalltalk не подошел?
Я Smalltalk не знаю. Мнения на его счет не имею никакого. И никогда не слышал, чтобы смоллток был хорош для прототипирования научных и алгоритмических задач. Дело в том, что на основной работе я занимаюсь Win32/GUI/C++ + все понемножку (коммуникация по COM-порту с устройством, OPC-сервер и т.д., все эта солянка применяется в последнем проекте). А вот в аспирантуре (рекламировать себя не буду, т.к. ни черта толкового еще не вышло, и неизвестно, защищусь ли в результате) столкнулся с Natural Language Processing. С верой в буст и непогрешимость святого стандарта, кинулся я на это дело с С++ наперевес. Затея провалилась, все время ударяюсь в какие-то частности. Первые скромные результаты с применением (пока малознакомого!!!) ОКамла получены быстрее и выглядят значительно более многообещающе (тьфу-тьфу, чтоб не сглазить). Такие вот дела.
Здравствуйте, vdimas, Вы писали:
V>OCaml — нет (насколько я понял из вчерашнего моего первого знакомства с ним), Лисп — да, менее универсален. То, что я показал, позволяет прямо в C# программе "орудовать" по лисповым правилам игры. Я даже уже продумал как обыграть макросы :) Нетрудно это все превратить в интерпретатор или даже в компилятор Лиспа (там и макросы легче будет сделать).
Написать компилятор лиспа на чем угодно несложно, только это не его недостаток, а достоинство :)
V>Сделать же наоборот на Лиспе — прямо в коде писать по правилам C# (или интерпретатор или компилятор C#) не так уж просто. Первое — вообще нереально.
Конечно же реально.
Макросы в лиспе — это полноценный же лисп и есть.
Даже если мы на них напишем LR-парсер, то все равно это будет только парсер, рантайм, интероп с лиспом и некоторые оптимизации мы получим даром. Весь разбор C#-синтаксиса будет идти при компиляции.
Что в случае с C# не так.
Это очень важный момент вообще — лисп сам по себе представляет из себя мета-платформу для быстрого создания множества языков.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>>>Я нашел нишу ФЯ лично для себя — прототипирование. Здесь эти причины не действуют. E>>А почему не эту роль, к примеру, Smalltalk не подошел?
ГА>Я Smalltalk не знаю.
Вопрос. Откуда ты можешь знать, что решаешь некую задачу оптимально, если ты просто банально не знаешь, какие еще подходы к ее решению существуют?
Может Smalltalk был бы еще эффективнее
ГА>столкнулся с Natural Language Processing.
Тогда все становится на свои места.
ГА> С верой в буст и непогрешимость святого стандарта, кинулся я на это дело с С++ наперевес.
А вот вера в Буст -- это напрасно, имхо.
ГА>Первые скромные результаты с применением (пока малознакомого!!!) ОКамла получены быстрее и выглядят значительно более многообещающе (тьфу-тьфу, чтоб не сглазить).
Удачи!
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Вопрос. Откуда ты можешь знать, что решаешь некую задачу оптимально, если ты просто банально не знаешь, какие еще подходы к ее решению существуют?
E>Может Smalltalk был бы еще эффективнее
Сомневаюсь, но мого быть, попробую. Потом, когда время будет. Если вы заметили, я целиком и полностью согласен с Арамисом (ой, с WFrag'ом): чтобы судить о языках, нужно на них попрограммировать (чуть не сказал пописать) чуток. Но не разорваться же мне, сначала одно, потом другое. А кроме того, в ОКамле меня привлекает мощная (а в Хаскеле — и того мощнее) система типов, которая не путается под ногами, а очень помогает при работе с навороченными структурами данных (если я не ошибаюсь, смолток — он динамически типизируемый, так?). А кроме того (опять же понаслышке, никакой категоричности), смолток — классика ОО, а ОО — не самое нужное при экспериментах со сложными алгоритмами. Пройтись по дереву в 3 строчки — вот что нужно.
ГА>>столкнулся с Natural Language Processing. E>Тогда все становится на свои места.
Кажется, на мне поставили клеймо .
ГА>> С верой в буст и непогрешимость святого стандарта, кинулся я на это дело с С++ наперевес. E>А вот вера в Буст -- это напрасно, имхо.
А я до сих пор уверен, что там масса полезных вещей. И знаете, в чем между нами разница? Я буст попробовал. Просто его оказалось недостаточно. (Тут я осознаю, что у Вас опыта побольше, и в Ваших условиях он может быть категорично неприменим, просто у меня сложилось впечатление, что с некоторых пор Вы встречаете в штыки все радикальные веяния: в С++ не нужны шаблонные навороты, ФЯ нормальному человеку тоже не нужны, программисты-прагматики любят С++, Руби и юнит-тесты . Просто впечатление, без обид).
ГА>>Первые скромные результаты с применением (пока малознакомого!!!) ОКамла получены быстрее и выглядят значительно более многообещающе (тьфу-тьфу, чтоб не сглазить). E>Удачи!
Спасибо огромное .
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>чтобы судить о языках, нужно на них попрограммировать (чуть не сказал пописать) чуток.
Собственно, похожие вещи я пытаюсь утверждать только относительно "знания" языка -- чтобы знать язык недостаточно прочитать пару книг о нем и написать несколько hello world-ов. Соответственно, чтобы знать много языков нужно много времени и усилий. Может быть даже слишком много.
ГА>А кроме того (опять же понаслышке, никакой категоричности), смолток — классика ОО, а ОО — не самое нужное при экспериментах со сложными алгоритмами. Пройтись по дереву в 3 строчки — вот что нужно.
Вполне возможно именно поэтому OCaml тебе и подошел. Но согласись, Natural Language Processing -- это отнюдь не самая распространенная предметная область.
E>>А вот вера в Буст -- это напрасно, имхо. ГА>А я до сих пор уверен, что там масса полезных вещей. И знаете, в чем между нами разница? Я буст попробовал. Просто его оказалось недостаточно. (Тут я осознаю, что у Вас опыта побольше, и в Ваших условиях он может быть категорично неприменим, просто у меня сложилось впечатление, что с некоторых пор Вы встречаете в штыки все радикальные веяния: в С++ не нужны шаблонные навороты, ФЯ нормальному человеку тоже не нужны, программисты-прагматики любят С++, Руби и юнит-тесты . Просто впечатление, без обид).
А я вообще по природе консервативен, Pink Floyd и Крематорий, к примеру, мне уже лет 15 нравятся. А Space и Jean-Michele Jarre еще больше
Если же серьезно, то я практически так и думаю. Имхо, сложные вещи должны решаться просто. И когда для решения сложных вещей предлагается сложный инструмент, который к тому же не тривиально использовать (я про Boost.Lambda), то мне кажется, что это не правильно. Уж лучше взять другой язык, где все это есть (здесь и твой личный опыт с OCaml в тему). Либо создать такой язык. Я имею в виду DSL с последующей кодогенерацией. Тот же yacc уже лет 30 актуален, потому что использовать его просто.
Что же касается опыта, то он не такой большой, как хотелось бы. Но показывает одну штуку: слишком хитрые и "изящные" решения приходится выбрасывать при сопровождении. Слишком неустойчивыми к изменению условий оказываются. Но это мой субъективный опыт.
А еще более прагматичные программисты, чем я, используют Java и юнит-тесты, и Ruby и юнит-тесты.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Глеб Алексеев, Вы писали:
E>>Может Smalltalk был бы еще эффективнее :) ГА>Сомневаюсь, но мого быть, попробую. Потом, когда время будет. Если вы заметили, я целиком и полностью согласен с Арамисом (ой, с WFrag'ом): чтобы судить о языках, нужно на них попрограммировать (чуть не сказал пописать) чуток. Но не разорваться же мне, сначала одно, потом другое.
Смоллтолк — это такой мутировавший в ОО лисп без скобочек :)
Интересен в первую очередь своим image-based подходом "все свое ношу с собой" и существующими на рынке средами.
RAD на стероидах для всяких внутрикорпоративной фигни.
Хотя, есть просто очень интересные приложения типа Seaside (очень мощный web-фреймворк)
Ложками дегтя служат плохая совместимость между реализациями, древний стандарт, сильная коммерческая направленность коммьюнити и неуемный фанатизм некоторых представителей :)
И упаси бог где-нибудь что-нибудь сказать не так про Алана Кея.
Тем не менее, Squeak — довольно милая штука и хороший пример некоторых идей в области GUI (Он там правда вроде из self'a взят, но смешно — такая взбесившаяся динамичная рефлексивность)
ГА>А кроме того, в ОКамле меня привлекает мощная (а в Хаскеле — и того мощнее) система типов, которая не путается под ногами, а очень помогает при работе с навороченными структурами данных (если я не ошибаюсь, смолток — он динамически типизируемый, так?). А кроме того (опять же понаслышке, никакой категоричности), смолток — классика ОО, а ОО — не самое нужное при экспериментах со сложными алгоритмами. Пройтись по дереву в 3 строчки — вот что нужно.
ОО да, ОО напрягает в смоллтолке больше всего.
Правда за счет динамической направленности это не настолько давит как в Java, но все же.
И из-за этого в большинстве своем смоллтолкеры уверены, что отсутствие статической типизации — единственно верный путь :)
(это я все по материалам чтения конференций и фанклубов друзей смоллтолка :)
Кстати, я упомянул, что в смоллтолк-коммьюнити принято считать, что Java произошла от смоллтолка, а не от С++ или Оберона? ;)
ГА>А я до сих пор уверен, что там масса полезных вещей. И знаете, в чем между нами разница? Я буст попробовал. Просто его оказалось недостаточно. (Тут я осознаю, что у Вас опыта побольше, и в Ваших условиях он может быть категорично неприменим, просто у меня сложилось впечатление, что с некоторых пор Вы встречаете в штыки все радикальные веяния: в С++ не нужны шаблонные навороты, ФЯ нормальному человеку тоже не нужны, программисты-прагматики любят С++, Руби и юнит-тесты :). Просто впечатление, без обид).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Глеб Алексеев, Вы писали:
ГА>>чтобы судить о языках, нужно на них попрограммировать (чуть не сказал пописать) чуток.
E>Собственно, похожие вещи я пытаюсь утверждать только относительно "знания" языка -- чтобы знать язык недостаточно прочитать пару книг о нем и написать несколько hello world-ов. Соответственно, чтобы знать много языков нужно много времени и усилий. Может быть даже слишком много.
Много усилий нужно, чтобы знать 5 языков. Чтобы знать 20-30, нужно не сильно больше.
E>Вполне возможно именно поэтому OCaml тебе и подошел. Но согласись, Natural Language Processing -- это отнюдь не самая распространенная предметная область.
Интересно, а какая самая? любой language processing — это очень важная часть программирования.
E>Если же серьезно, то я практически так и думаю. Имхо, сложные вещи должны решаться просто. И когда для решения сложных вещей предлагается сложный инструмент, который к тому же не тривиально использовать (я про Boost.Lambda), то мне кажется, что это не правильно. Уж лучше взять другой язык, где все это есть (здесь и твой личный опыт с OCaml в тему). Либо создать такой язык. Я имею в виду DSL с последующей кодогенерацией. Тот же yacc уже лет 30 актуален, потому что использовать его просто.
yacc просто использовать?!
видимо, придется попросить определить что такое просто.
А то после комбинаторов мне при виде якка хочется застрелиться.
Здравствуйте, reductor, Вы писали:
R>Смоллтолк — это такой мутировавший в ОО лисп без скобочек R>Интересен в первую очередь своим image-based подходом "все свое ношу с собой" и существующими на рынке средами. R>RAD на стероидах для всяких внутрикорпоративной фигни. R>ОО да, ОО напрягает в смоллтолке больше всего. R>Правда за счет динамической направленности это не настолько давит как в Java, но все же. R>И из-за этого в большинстве своем смоллтолкеры уверены, что отсутствие статической типизации — единственно верный путь
Не удивительно, что это говорит человек, которого даже от Ruby тошнит. А уж от чистого Smalltalk...
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Собственно, похожие вещи я пытаюсь утверждать только относительно "знания" языка -- чтобы знать язык недостаточно прочитать пару книг о нем и написать несколько hello world-ов. Соответственно, чтобы знать много языков нужно много времени и усилий. Может быть даже слишком много.
R>Много усилий нужно, чтобы знать 5 языков. Чтобы знать 20-30, нужно не сильно больше.
Без обид, но я не увидел, чтобы ты хорошо знал C++.
А знать хорошо C++ -- это может быть посложнее, чем знать 10-15 других языков.
E>>Тот же yacc уже лет 30 актуален, потому что использовать его просто.
R>yacc просто использовать?! R>видимо, придется попросить определить что такое просто.
А что сложного-то? Описываешь правила, прикручиваешь лексический анализатор. Проверяешь. Затем добавляешь синтаксические процедуры. И все дела.
R>Вот. Причем, прошу заметить — ничего не генерируется, это все на самом же языке и пишется. R>http://www.cs.uu.nl/~daan/download/parsec/parsec.html
Выглядит интересно. Но то, что синтаксические правила можно сразу на языке программирования описывать -- не новость: http://i.loveruby.net/en/projects/racc/ (их есть у нас ).
R>На последнем OSCON'e Autrijus Tang показывал как за 15 минут таким образом пишется полный разбор грамматики perl 6.
Уже известной грамматики. И после нескольких часов подготовки к демонстрации.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: офтоп - Брюс Эккель о Руби, эмишах и пр :)
R>>Много усилий нужно, чтобы знать 5 языков. Чтобы знать 20-30, нужно не сильно больше.
E>Без обид, но я не увидел, чтобы ты хорошо знал C++.
Хорошо или нет, я стараюсь на нем не писать и о нем не говорить.
И никому вообще знать его не обещал.
Не самая интересная для меня тема, без обид.
E>А знать хорошо C++ -- это может быть посложнее, чем знать 10-15 других языков.
Прошу прощения, но откуда такие сведения?
Неужели по собственному опыту? :)
E>>>Тот же yacc уже лет 30 актуален, потому что использовать его просто.
E>А что сложного-то? Описываешь правила, прикручиваешь лексический анализатор. Проверяешь. Затем добавляешь синтаксические процедуры. И все дела.
А можно просто — описываешь прямо на месте правила и все? А то мне так привычнее.
R>>Вот. Причем, прошу заметить — ничего не генерируется, это все на самом же языке и пишется. R>>http://www.cs.uu.nl/~daan/download/parsec/parsec.html
E>Выглядит интересно. Но то, что синтаксические правила можно сразу на языке программирования описывать -- не новость: http://i.loveruby.net/en/projects/racc/ (их есть у нас :) ).
Racc (Ruby yACC) is a LALR(1) parser generator for Ruby [..]
Parsers generated by Racc requires "Racc Runtime Module".
Это называется "на языке"?
R>>На последнем OSCON'e Autrijus Tang показывал как за 15 минут таким образом пишется полный разбор грамматики perl 6.
E>Уже известной грамматики. И после нескольких часов подготовки к демонстрации.
Ну с удовольствием посмотрю здесь на разбор этой грамматике на yacc+С++.
Время можно будет прикинуть по количеству строчек там и там.
Здравствуйте, eao197, Вы писали:
R>>Смоллтолк — это такой мутировавший в ОО лисп без скобочек R>>Интересен в первую очередь своим image-based подходом "все свое ношу с собой" и существующими на рынке средами. R>>RAD на стероидах для всяких внутрикорпоративной фигни. R>>ОО да, ОО напрягает в смоллтолке больше всего. R>>Правда за счет динамической направленности это не настолько давит как в Java, но все же. R>>И из-за этого в большинстве своем смоллтолкеры уверены, что отсутствие статической типизации — единственно верный путь
E>Не удивительно, что это говорит человек, которого даже от Ruby тошнит. А уж от чистого Smalltalk...
R>Да чем это все отличается от самого крайнего случая с тем же окамлом — написанием модуля на Си и линковкой с ним. R>Это по-моему что-то психологическое, скорее
С этим спорить не буду, психологических барьеров нет, сам регулярно пишу нечто на универсальных С/С++, и подлинковываю то в VB, то в .Net, то в Windows ScriptHost, то в Дельфи и т.д.
Здравствуйте, reductor, Вы писали:
E>>А знать хорошо C++ -- это может быть посложнее, чем знать 10-15 других языков.
R>Прошу прощения, но откуда такие сведения? R>Неужели по собственному опыту?
Да. И не только моему. Думаю, что многие из учасников форума C/C++ со мной согласятся.
E>>Выглядит интересно. Но то, что синтаксические правила можно сразу на языке программирования описывать -- не новость: http://i.loveruby.net/en/projects/racc/ (их есть у нас ).
R>Это называется "на языке"?
Да, здесь я ошибся, раньше RACC рекламировался как инструмент, в котором правила прямо в Ruby декларировались. Все течет, все изменяется.
R>>>На последнем OSCON'e Autrijus Tang показывал как за 15 минут таким образом пишется полный разбор грамматики perl 6.
E>>Уже известной грамматики. И после нескольких часов подготовки к демонстрации.
R>Ну с удовольствием посмотрю здесь на разбор этой грамматике на yacc+С++. R>Время можно будет прикинуть по количеству строчек там и там.
Просто разбор? А какой в этом смысл, в простом разборе-то?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Не удивительно, что это говорит человек, которого даже от Ruby тошнит. А уж от чистого Smalltalk...
R>?? R>Можно попросить расшифровать мысль?
Ну просто разработчики Ruby не скрывают, что очень многое было взято из Smalltalk. Только язык попытались сделать прагматиченее.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
