Здравствуйте, VladD2, Вы писали:
ЗХ>>Да вот я же это обсуждение и затеял, чтобы, как уже было сказано, "прикинуть, где Руби меня ограничиваеть и что с этим можно сделать". Мне вообще пофиг, мощнее ли А, чем Б. Для меня вопрос стоит так: "какие фичи А я еще не понимаю".
VD>Подход конструктивный, но боюсь, что без серьезной опробации языка поддерживающего возможности отсутсвующие в Руби ты не сможешь адекватно оценить эти возможности.
VD>Так что перед тем как расширять Руби было бы разумно освоить (хотя бы по минимуму) языки из которых берутся фичи. VD>Единственная проблема тут заключается в том, что это может затянуть.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>В заметке на Lambda the Ultimate пишут, что MIT переводит свои вводные курсы по программированию со схемы на Python , чтобы, среди прочего,
К>>
К>>to better prepare students for graduate school or real-world design challenges
VD>Проглесс! Еще 256 ведер и... Ну, думаю, что все и так все поняли.
Кстати MIT есть в списке тех кто используют "супер лисп" Qi, http://www.lambdassociates.org/users.htm и он очень мощный и одновременно родной их схеме, но почему-то его не тоже не взяли.
Здравствуйте, PhantomIvan, Вы писали:
PI>зачем-зачем, надо :) PI>я тут никого топтать в грязи не собираюсь PI>хочется понять, для каких задач Немерле не подходит
ОК. У меня линух, jvm, куча кода, который нет смысла переносить.
Думаю. этого достаточно, чтобы отказаться от Немерле? :-)
PI>впереди у меня — большой (несколько лет, как минимум) проект, для которого я собираюсь использовать немерле PI>вот, смотрю, нет ли чего лучше для моих целей...
Зачем сравнивать разные проекты? :-)
L>>Потому что он мощнее Немерле :-) PI>я бы так не сказал (я пробовал Хаскель)
Повторю, я считаю мощность достоточно субъективным понятием. По моему списку оценки мощности Хаскель мощнее. По твоему — нет. Мы оба правы, и нам не о чем спорить.
Здравствуйте, Андрей Хропов, Вы писали:
L>>Потому что он мощнее Немерле :-) АХ>Смело, обоснуй. Мне интересно. Я его еще пока подробно не изучал.
Хорошо. Хочется услышать что нибудь о Хаскеле, спросите, я расскажу, если знаю. Но спрашивать для того, чтобы сравнивать его с Немерле — это для меня не интересно. Это совсем другой инструмент. Не нравится, привыкли по другому — бога ради! Меряться смысла не вижу.
Итак. Меня спросили почему бы я выбрал Хаскель, если бы выбирал по мощности. Мощность — понятие субъективное. Для меня Хаскель мощнее, потому что он позволяет мне делать то, что мне нужно, и что не позволяет (делает это хуже) Немерле. Как наглый пример — даёт мне новые знания, которые мне интересны.
АХ>Пока я вижу преимущество Хаскеля в том, что на нем удобнее работать с бесконечными списками (хотя это и довольно нишевая задача).
У него все типы данных ленивы (если обратное не укажешь явно), списки — всего лишь один из типов.
В Хаскеле помимо этого много чего другого интересного.
L>ОК. У меня линух, jvm, куча кода, который нет смысла переносить. L>Думаю. этого достаточно, чтобы отказаться от Немерле?
ага, а как насчет экзотических языков? не пользуешься?
какое твое мнение о Скале и Моно?
L>Зачем сравнивать разные проекты?
иногда вдруг обнаруживается, что можно применить некоторую технику в неожиданном месте
или "случайно" наткнуться на более эффективную технику выполнения некоторых задач
L>Хорошо. Хочется услышать что нибудь о Хаскеле, спросите, я расскажу, если знаю.
о! ты попался!
что такое монада?
АХ>>Пока я вижу преимущество Хаскеля в том, что на нем удобнее работать с бесконечными списками (хотя это и довольно нишевая задача).
как насчет бесконечной решётки (двумерного списка)?
L>У него все типы данных ленивы (если обратное не укажешь явно),
а как указать обратное?
L> списки — всего лишь один из типов.
какие ещё есть?
L>>>что есть более подходящие языки для моих задач. PI>>а можно вкратце? язык — задача
L>зачем?
а вдруг я с выбором Немерле ошибся?
посмотрю на список, увижу аналогии — задам наводящие вопросы
изучу подробней технологию, на которой реализовано, и вдруг приму решение сменить инструмент
Здравствуйте, PhantomIvan, Вы писали:
L>>Хорошо. Хочется услышать что нибудь о Хаскеле, спросите, я расскажу, если знаю. PI>о! ты попался! PI>что такое монада?
Настоятельно рекомендую поиск по Декларативному программированию
L>> списки — всего лишь один из типов. PI>какие ещё есть?
Не проще ли взять книгу ? Допустим погуглить по Yet Another Haskell Tutorial.
... << RSDN@Home 1.2.0 Pink Floyd — Let There Be More Light >>
Здравствуйте, PhantomIvan, Вы писали:
PI>ага, а как насчет экзотических языков? не пользуешься?
Хочу наконец разобраться с J. Когда то баловался с бефунге. Когда смотрел задачу с последнего icfpc, то там был язычок диаграмм :-)) вот на нём тоже писал. Вроде больше извращениями не занимался. Но хочу, ага.
PI>какое твое мнение о Скале и Моно?
Скала симпатичнее, чем Ява. Но и пицца была симпатичнее, а с ней только баловались. Будем посмотреть. Применять пока не буду, а баловаться продолжу.
Насчёт моно ничего сказать не могу — совершенно этим не интересовался, я специализируюсь на Яве. Могу только прислушиваться к мнению специалистов.
PI>иногда вдруг обнаруживается, что можно применить некоторую технику в неожиданном месте PI>или "случайно" наткнуться на более эффективную технику выполнения некоторых задач
Здравствуйте, PhantomIvan, Вы писали:
L>>Хорошо. Хочется услышать что нибудь о Хаскеле, спросите, я расскажу, если знаю. PI>о! ты попался! :)) PI>что такое монада? :)
Ой, монада такой термин, который определить легко, а понять сложно. Хотя когда поймешь — видно, что на самом деле ничего сложного нет. Монада объединяет понятия значений и вычислений. Туториалов про неё масса. Simon Peyton-Jones в шутку сказал, что термин монада неверен и предложил называть её "warm fuzzy thing". Говоря про монаду приводят в пример астронавтов, монстров и ловеласов. Тебе стало понятнее? :-) Говорят о ней как о вычислении и как о контейнере. Последнее (похвастаюсь) я перевёл на русский, можешь почитать здесь. На самом деле пока не поработаешь, не получится понять.
АХ>>>Пока я вижу преимущество Хаскеля в том, что на нем удобнее работать с бесконечными списками (хотя это и довольно нишевая задача). PI>как насчет бесконечной решётки (двумерного списка)?
В принципе, любые бесконечные структуры, которые возможны на алгебраических типах данных.
L>>У него все типы данных ленивы (если обратное не укажешь явно), PI>а как указать обратное?
Перед типом надо поставить восклицательный знак. Это работает не только на конструкторах, но и на функциях.
a -> b -> c — функция с двумя параметрами, которые может быть и не будут вычислены.
a ->!b -> c — функция с двумя параметрами, второй из которых будет вычислен перед вызовом.
L>> списки — всего лишь один из типов. PI>какие ещё есть?
Простые (Int, Char, Bool), и алгебраические типы данных (по моему это аналог вариантного типа в Немерле, если я кого из вас правильно понял).
Здравствуйте, PhantomIvan, Вы писали:
L>>зачем? :)
PI>а вдруг я с выбором Немерле ошибся? ;)
Всё ищешь серебрянную пулю?
PI>посмотрю на список, увижу аналогии — задам наводящие вопросы PI>изучу подробней технологию, на которой реализовано, и вдруг приму решение сменить инструмент ;)
Не надо, Немерле хороший язык, тебе он нравится, подходит для твоих задач, чего ещё желать специалисту?
Здравствуйте, VladD2, Вы писали:
M>> опасения относительно обратной совместимости этц,
VD>Это чистые домыслы.
Дык я и не сопрю. Это ощущение из серии "чем-то задним чувствую, что могут быть проблемы". И буду только рад, если их не окажется.
VD>ИДЕ и т.п. скоро появятся. К сожалению, я боюсь, что после того как все что нужно появится все равно будут находитиься отмазки. Ведь лень и страх долеко не всегда двигают прогресс.
Смотря что считать отмазками. У меня текущи проект на Compact Framework. Немерле туда ну никак. Вернее в принципе то как, но для этого придется приложить туеву хучу усилий и времени.
VD>+1 VD>Но ведь постоянно появляются задачи которые пишутся в общем-то с нуля. Ну, или при использоватьнии только библиотек. И их без проблем можноп оппробовать решить на новом языке. Хотя бы ради развлечения. А там сам не заметишь как затянет.
Ну собственно так и делаю. Только пока больше затягивает Хаскел и Erlang Наверное потому что дот нета хватает на работе, хочется чего-то не такого.
M>>Кто-то боится, что на большом проекте могут возникнуть неожиданный грабли, связанные с Немерле. Это дополнительный риск в проекте, а от них стараются избавляться.
VD>Это тоже фобия.
Вполне может быть. см. пункт про "заднее ощущение"
VD>+1 VD>Отмазом "почему не надо пробовать" всегда больше чем стимулирующих факторов. Их по сути всего два. Возможность существенно повысить свои возможности или скорость разработки и банальный интерес к новому (любопытству). Посему конечно многие люди будут еще долго раскачиваться даже чтобы просто банально попробовать.
Ну насчет попробовать это меня уговаривать не надо. Правда могу сразу сказать один недостаток Немерле. Плохая документация. Она может быть лучше чем допустим у Ruby, но однозначно хуже чем MSDN К хорошему привыкаешь быстро. Допустим я не смог сходу найти как написать аналог C# кода
public T proofOfConcept<T,Q>(T a,Q b)
where T : Integral<T>,Eq<T>
where Q : Real<Q>
{
return a;
}
VD> Большинство людей просто пока не в курсе.
Ой-вей, имхо уже весь РСДН в курсе. По крайней мере все люди, которые хоть изредка читают Философию и ДП, точно в курсе. 100%
VD>
Все говорят что мы вместе, но не многие знают в каком...
Эххх. Так и чешутся руки ответить что-то типа
Три чукотских мудреца
Твердят, твердят мне без конца
металл не принесет плода
игра не стоит свеч
а результат труда
или
Покажи мне людей, уверенных в завтрашнем дне
Нарисуй мне портреты погибших на этом пути
Покажи мне того, кто выжил один из полка
Но кто-то должен стать дверью, а кто-то замком
А кто-то ключом от замка
Здравствуйте, lomeo, Вы писали:
PI>>что такое монада?
L>Ой, монада такой термин, который определить легко, а понять сложно. Хотя когда поймешь — видно, что на самом деле ничего сложного нет. Монада объединяет понятия значений и вычислений.
Ну не знаю. Имхо сложность монады преувеличена. Вернее даже не так. Имхо для первого знакомства с монадами абсолютно необязательно знать что это что-то из теории категорий.
Просто типизированный интерфейс. С методами return и bind.
Для людей пришедших из ООП, особенно нематематиков такое объяснение вполне устраивает, да и в первом приближении можно считать его верным.
Один вариант реализации на c# приводил я, другой был на Питоне И снова монадах
А после такого поврехностного знакомства можно уже объяснять что это жжжж неспроста, и на самом деле под этим простым интерфейсом есть некая математическая идея. Но это потом.
L> На самом деле пока не поработаешь, не получится понять.
Категорически не согласен. С Хаскелом практически не работал, больше читал. Но после проведения аналогии с интерфейсом, появилось понимание. Хотя это все личностное.
L>Простые (Int, Char, Bool), и алгебраические типы данных (по моему это аналог вариантного типа в Немерле, если я кого из вас правильно понял).
+1 аналог это Немерловые варианты.
Здравствуйте, Mirrorer, Вы писали:
L>>Ой, монада такой термин, который определить легко, а понять сложно. Хотя когда поймешь — видно, что на самом деле ничего сложного нет. Монада объединяет понятия значений и вычислений.
M>Ну не знаю. Имхо сложность монады преувеличена. Вернее даже не так. Имхо для первого знакомства с монадами абсолютно необязательно знать что это что-то из теории категорий. M>Просто типизированный интерфейс. С методами return и bind.
Это всего лишь определение. Важна ж семантика.
L>> На самом деле пока не поработаешь, не получится понять.
M>Категорически не согласен. :) С Хаскелом практически не работал, больше читал. Но после проведения аналогии с интерфейсом, появилось понимание. :xz: Хотя это все личностное.
Тогда извиняюсь, у меня было по другому. Почувствовал зачем она нужна только на примерах из собственного опыта.
M>ЗЫ. просьба к тебе как к человеку, знающему Хаскел покритиковать аналогии Type Classes & Параметризированные интерфейсы
Здравствуйте, eao197, Вы писали:
E>Ничего не одно и то же. foreach хорошо подходит для решения этой задачи по таким показателям, как компактность, скорость и ресурсоемкость. С одной стороны, комактность уменьшает вероятность ошибки. Но, с другой стороны, компактность уменьшает ее читабельность. И по этому показателю foreach хуже.
Пять балов! Надо будет повесить эти слова на стену как демонстрацию того до чего может довести демагогия.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Ничего не одно и то же. foreach хорошо подходит для решения этой задачи по таким показателям, как компактность, скорость и ресурсоемкость. С одной стороны, комактность уменьшает вероятность ошибки. Но, с другой стороны, компактность уменьшает ее читабельность. И по этому показателю foreach хуже.
VD>Пять балов! Надо будет повесить эти слова на стену как демонстрацию того до чего может довести демагогия.
Вот в такой формулировке, пожалуйста:
Объемный и простой код читается лучше, чем компактный и сложный.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, PhantomIvan, Вы писали:
PI>>>вот это самый большой, по-моему, наезд на полюзующихся динамикой PI>>>серьёзное утверждение, что на динамике реально больших проектов не написать
ANS>>С чего ты взял, что это есть "серьёзное утверждение"? Как по мне, то это просто "глупость несусветная" ((с) VladD2).
PI>потому что я тоже не слышал ни об одном достаточно большом (больше 10 человеко-лет) проекте на динамике PI>"серьёзное утверждение" заключается во фразе "динамику нельзя использовать для больших проектов, потому что она имеет фундаментальные ограничения на масштабиремость" PI>это автоматически объясняет, почему динамика не применяется в "серьёзном" энтерпрайзе
PI>и если кто-то имеет контр-примеры, пусть их приводит
код для свича AXD301 на динамическом (и функциональном) Эрланге в 1,7 млн. строк (на 2005 год). Вроде бы больше сотни человек в комманде разработчиков.
, чтобы, среди прочего, 
