Сам я ярый C#-повец, но ведь нашелся среди ThirdParty языков язык задевший меня за живое — функциональный язык SML.NET
Не скажу, что он стал моим основным, но по крайней мере я ощутил, что на нем можно писать и не просто писать, а еще и с рядом явных инаковостей и приемуществ / недостатков с C#
Что понравилось
1. Он реально .NET-овский, без всякого интеропа, как например ActiveState Perl для .NET, который без .NET и шустрее и полезнее или тот же P#(пролог)
2. Код поначалу непривычен на вид, но он как хороший код лиспера — непонятно как работает, но при этом сразу какой-то красивый
3. функциональность без идейных завихов — есть и циклы и вся прочая процедурная оснастка
4. код получается по сути обфусцированным, разобраться что же делает класс крайне сложно так как компилятор не тупо разбирает функции на перегруженные методы с фасадом, а стряпает из них эдакую лапшу, т.с. план исполнения, если не сам писал код, понять получаемый IL просто не получается (лично у меня)
5. передача функций как параметров хорошая замена доволно громоздким в С#/VB/C++ исполнении явным делегатам
Но вот не понравилось крайне долгое время работы компилятора — линковщика. Это видимо беда любых функциональных языков, где внутри кода сплошное "позднее связывание", рекурсия, функции как параметры и проч.
В общем мне понравилось.
Вообще мне кажется давно пора поднять и обсудить тему альтернативных языков.
25.11.04 12:44: Перенесено модератором из 'Общий форум [GDN]' — TK
SML.NET и засилие C#
От:
Аноним
Дата:
25.11.04 01:26
Оценка:
Обратные стороны достоинств:
1. Честно сказать, просто не понял, в чём достоинство
2. Код, который "непонятно как работает", очень трудно поддерживать.
3. Зачем тогда нужна такая функциональность? Идейная "нечистота" всегда приводит к "грязным" программам, это точно.
4. Если вы хотите получить обфусцированный код, то есть же специальные средства, а если не хотите — тогда в чём преимущество? Скорее наоборот, если непонятно, что делает класс, труднее будет вашему клиенту.
5. Передача функций как параметров заметно снижает вероятность обнаружения ошибок во время компиляции.
А что бы вы хотели обсудить на "тему альтернативных языков"?
Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, вы соглашаетесь с тем, что (i) Майкрософт не несет ответственности за использование вами данной информации и (ii) вы принимаете на себя весь риск, связанный с использованием данной информации.
Обратные стороны достоинств:
> 1. Честно сказать, просто не понял, в чём достоинство > 2. Код, который "непонятно как работает", очень трудно поддерживать. > 3. Зачем тогда нужна такая функциональность? Идейная "нечистота" всегда приводит к "грязным" программам, это точно. > 4. Если вы хотите получить обфусцированный код, то есть же специальные средства, а если не хотите — тогда в чём преимущество? > > Скорее наоборот, если непонятно, что делает класс, труднее будет вашему клиенту. > 5. Передача функций как параметров заметно снижает вероятность обнаружения ошибок во время компиляции.
> А что бы вы хотели обсудить на "тему альтернативных языков"?
===========================================
1. Достоинство в том, что откомпилированный код не требует ни наличия неуправляемых DLL как Perl.NET, ни отреферированных специальных языковых сборок, также как и С# или VB.NET язык остается языком без претензий на включение своих интерпретаторов или еще чего в итоговую программу. Тот же перл и лисп (в виденных мною реализациях) требуют.
2. Код понятно как работает и читается хорошо. Я другое имел в виду. ЧТо после долгой работы на таких языках как C#/VB/Delphi/C++ лямбда исчисление, организация каласса как функции, наличие в первую голову операторов из области множеств и функционального исчисления а не из области алгоритмов и управления порядком исполнения — это хорошая встряска, котрая заставляет по другому взглянуть на свой код на других языках, но по началу, да, непонятно многое, другая организация.
3. В "чистый" ЛИСП последователи привнесли массу разрозненных включений процедурного характера "для удобства". Нормпальный язык, даже имея какую-то направленность должен быть сбалансирован. На том же вполне алгоритмическом процедурном языке каким является С# (понятно, что он ОО, но сам синтаксис методов и проч вполне явный наследник паскаля/C) можно писать декларативно (используя атрибуты) и в функциональном стиле, благо есть перегрузка операторов, методов, делегаты. Синтаксис SML прежде всего повязан на функциональном исчислении, а класс это структура, организующая класс функций, но это не значит, что в нем не должно быть возможности описывать процесс исполнения в терминах условного перехода, цикла и т.д. Здесь это уже просто органично вписанов в язык.
4. Мне и не нужна обфускация, это так бесплатный "откат" компилятора. Мне больше понравилось то, что создатели не сделали тупой парсер SML->C#(C++,VB) по принципу оператор в оператор, метод в метод, а остались верными своему языку, который увязывает функции в неки план исполнения, в IL это может выглядеть как лапша.
5. Да снижает, но SML — строго типизирвоанный во всем что касается как параметров, переменных, так и функций. Компилятор повторюсь отрабатывает очень долго, но при этом проверяет все возможные сценарии вызовов и запретит передачу некорректной функции
Если честно я в SML далеко не АС, но мне он просто понравился.
Что я хочу обсуждать на тему альтернативных языков.
1) Просто обмен мнениями кто что видел, пробовал, как оценивает, для чего пригождается.
2)Разработка анализаторов, парсеров, новых языков, преобразований XML (скажем через XSLT) в код прямо на IL или на ином языке, шаблоны различные, генерики простеньких приложений и т.п.
Концепции всяких скриптовых и проч языков.
Для примера: мне сейчас нужен и я веду его разработку для себя языка для описания процедур автоматического обхода интернета с закачками,парсингом, закачкой в базу и т.д. Пока у меня есть только XML схемы по которой определенный класс организует запрос и возвращет его клиенту. Он также может быть настроен на использование моего (был в примерах) регекс-преобразователя плоского текста в XML и выдавать ответ в виде XPathNodeIterator — это позволяет встраивать данный класс в качестве расширения в XSLT-преобразования и делать таким образом обращения к INET частью трансформации. Но хотелось бы иметь что-то вроде (в качестве например ежедневно исполняемого скрипта):
deftargetDir = "c:\download\news\{DateTime.Today}";
def requestfront_page{url"http://someurl/page.aspx?date={DateTime.Today}&category=";
with aspnet,//специфический способ работы с редиректом и кукки keep cookies for domain;}for link linkToNew byregex[topic=(?<topicid>\d+)] of ^front_page{ text response = ^linkToNew; xml xResponse = response|"news_parsing_regex.txt"|"normalize_news.xslt"; xResponse.Save("{targetDir}Новость {$topicid}.xml");if xResponse isxpath[/new[keyword='имя нашей конторы']] { sqlexec{ query xResponse|"news_to_sql.xslt";withdefault connection, log on error } }}
Здравствуйте, Аноним, Вы писали:
А>Но вот не понравилось крайне долгое время работы компилятора — линковщика. Это видимо беда любых функциональных языков, где внутри кода сплошное "позднее связывание", рекурсия, функции как параметры и проч. А>В общем мне понравилось.
SML NJ компилятор тоже тормозной. Не знаю откуда растет версия для .NET, может от него, в этом случае ничего удивительного в его тормознутости нет.
Компиляторы для других языков работают побыстрее. Кроме того, очень желательно упрощать работу компилятора — указывать явно типы функций. В этом случае ему не придется заниматься выводом типов, что ускорит компиляцию.
Re: SML.NET и засилие C#
От:
Аноним
Дата:
25.11.04 11:54
Оценка:
Спасибо, скорость увеличивается в разы (для маленького пробного проекта).
Компилятор .NET растет из SML NJ, но только делает IL
Здравствуйте, TK, Вы писали:
TK>Hello, "Fagim" >> >> Вообще мне кажется давно пора поднять и обсудить тему альтернативных языков. >>
TK>http://gzip.rsdn.ru/Forum/?group=decl
А>>Но вот не понравилось крайне долгое время работы компилятора — линковщика. Это видимо беда любых функциональных языков, где внутри кода сплошное "позднее связывание", рекурсия, функции как параметры и проч. А>>В общем мне понравилось.
Q>SML NJ компилятор тоже тормозной. Не знаю откуда растет версия для .NET, может от него, в этом случае ничего удивительного в его тормознутости нет.
Если говорить в общем а не о этом конкретном компиляторе, то для ФЯ скорее лучше чтобы компилятор работал подольше но оптимизировал получше, там есть что оптимизировать.
Это если говорить о реальном промышленном применении. А применение такое скорее всего в 90% случаев будет в виде написания отдельных кусков(которые на ФЯ делаются легче), а остальная часть будет сделана в традиционных системах.
Есть у них в описании такая фраза.. "...bla-bla-bla..... This improves performance of the generated code, but significantly increases (re)compilation times."
Здравствуйте, Silver_s, Вы писали:
S_>Если говорить в общем а не о этом конкретном компиляторе, то для ФЯ скорее лучше чтобы компилятор работал подольше но оптимизировал получше, там есть что оптимизировать.
В ФЯ настолько есть что оптимизировать, что процедура компиляции вообще, по-хорошему, должна быть принципиально иной. И сильно зависящей от ситуации.
Например, на этапе отладки — быстрая компиляция, медленное исполнение. Например, как интерпретация.
После отладки — оптимизирующая компиляция с глубоким (и, следовательно, длительным) анализом кода.
А далее самое интересное — профайлинг реального использования кода и оптимизация на основе этого профайлинга. Это позволит получать код, который одновременно более абстрактен и более быстр, чем ИЯ аналоги.
Только когда этот этап будет реализован я буду считать, что ФЯ состоялись и имеют практическое значение.
Re[3]: SML.NET и засилие C#
От:
Аноним
Дата:
29.11.04 07:22
Оценка:
Ам... Скажем так. В моем ВУЗе SML.NET читался студентам второго курса в течении семестра. Мое мнение слудеющее:
1) Лямбда исчисление, КАМ и пр. это тяжеловато для студентов, не из-за математики, а из-за того, что им это читалось как курс "Языки программирования" и они не видели применения этим идеям. (Я про второй курс).
2) В результаете сейчас читается только C# а вместо SML.NET стали давать больше C/C++...
P.S> Кто-нибудь вообще заставил работать компилятор SML.NET под 2003/2005 студию?
mihoshi :
Только когда этот этап будет реализован я буду считать, что ФЯ состоялись и имеют практическое значение.
Ну прямо скажем, что и может без самых эффективных компиляторов ФЯ имеют практическое значение,
1. надеюсь что XSLT у вас в этом плане сомнения не вызывают?
2. на клоне LISP построены системы спутников, и это язык AUTOCAD
3. на языках подобных CLIPS пишут реальные рабочие экспертные системы для той же медицины
Ведь то что тот же C# транслируется не в самый, далеко не самый эффективный IL, и никакого автоматического профпайлинга по нему не ведется не уменьшает его "практическое значение".
Практическое значение языков, особенно если учесть нехилую производительность нонешних есть функция огт их выразительности, предметной нацеленности или наоборот независисмости и легкости сопровождения.
И значение функциональных языков и их практическое значение проявляется там, где принципиально и критично декларативное программирование, когда более эфективным оказывается сосредоточение на формулировке правил и анализа среды, а не на формировании собственно плана выполнения программы, когда алгоритм работы движка менее критичен чем сами данные, которые он должен перемолоть.
А отладка и оптимизация это конечно хорошо, но тут нет специфики ФЯ — они по природе своей языки более высокого уровня чем ИЯ и в большинстве реализаций исполняются в некоем рантаймовом окружении которое и призвано оптимизировать планы выполнения.
Мы же не говорим что практическое значение SQL невелико, если какие-то движки не способны составить нормальный быстрый план выполнения запроса. ФЯ не меньше обычно зависят от среды исполнения или как раз от первичной компиляции, которая идет долго, но зато прослеживает различные взаимовызовы функций, расплетая этот клубок в отдельные нити.
Здравствуйте, Аноним, Вы писали:
А>mihoshi : А>Только когда этот этап будет реализован я буду считать, что ФЯ состоялись и имеют практическое значение.
А>Ну прямо скажем, что и может без самых эффективных компиляторов ФЯ имеют практическое значение,
А>1. надеюсь что XSLT у вас в этом плане сомнения не вызывают? А>2. на клоне LISP построены системы спутников, и это язык AUTOCAD А>3. на языках подобных CLIPS пишут реальные рабочие экспертные системы для той же медицины
Понял, уточняю. Будут иметь практическое значение как языки общего назначения.
На данный момент реально они рулят только в тех областях, для которых они были изначально созданы. Т.е. системы proof assistance (ML), скрипты (Lisp) и преобразования (XSLT).
А>Мы же не говорим что практическое значение SQL невелико, если какие-то движки не способны составить нормальный быстрый план выполнения запроса. ФЯ не меньше обычно зависят от среды исполнения или как раз от первичной компиляции, которая идет долго, но зато прослеживает различные взаимовызовы функций, расплетая этот клубок в отдельные нити.
Вот только пока что я не видел ни одной реализации, которая бы это делала достаточно эффективно. Проблема понижения эффективности при повышении абстрактности так и не решена.
Re[4]: SML.NET и засилие C#
От:
Аноним
Дата:
30.11.04 04:17
Оценка:
===Понял, уточняю. Будут иметь практическое значение как языки общего назначения.
В уточненной формулировке принимается и даже поддерживается ибо "обзие задачи" обычно и не включают в себя рекурсии, сложых процедур выбора стратегии и т.п. Там ФЯ только затрудняют восприятие.
=========На данный момент реально они рулят только в тех областях, для которых они были изначально созданы. Т.е. системы proof assistance (ML), скрипты (Lisp) и преобразования (XSLT).
ВСЕ на свете рулит в том, для чего оно и создано шофер- в машине, летчик — в самолете, а XSLT — в преобразованиях.
Хотя по XSLT не совсем согласен, в сочетании с .NET он вообще РУЛИТ, учитывая возможность сочленения его со сборками на любом .NET языке.
Я уж молчу про добавление регексов к XPath функциям, но у меня на XSLT пашут все генераторы запросов, роботы обхода интернета типа
<xsl:template match="/">
<xsl:apply-templates select="my:text_to_xml(my:http_request($url,$enc,$postdata),$regex)/result/links/link"/>
</xsl:template>
<xsl:template match="link">
<xsl:variable name="stub_call" select="my:download(.,$path)"/>
</xsl:template>
Вот так у меня выглядит простейший робот для локализации сайта на диск. То есть сам термин "преобразование XML данных" благодаря расширениям можно протолковать ОЧЧЕНЬ расширительно до такой степени, что XSLT (для меня по крайней мере ) — это язык если не общего, но и не слишком уж специального значения. Этакий скриптово-функциональный язык рулящий ЛЮБЫЕ преобразования.
F> ...это язык если не общего, но и не слишком уж специального значения. Этакий скриптово-функциональный язык рулящий ЛЮБЫЕ преобразования.
Эта... А квиксорт с решетом эратосфена на нем написать можно? А то мне тут AndrewVK обещался показать, но так и не смог.
Re[5]: SML.NET и засилие C#
От:
Аноним
Дата:
01.12.04 04:37
Оценка:
Если честно, то я его наверное сходу ни на каком языке не напишу .
Я же не фанатик какой-то мол все через XSLT и ФЯ надо делать. Хотя скорее всего можно... такой что раз в 10 медленнее аналогичного на любом ИЯ будет работать...
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Fagim, Вы писали:
F>>Это просто рассуждения, может кто еще пробовал пользовать SML http://www.cl.cam.ac.uk/Research/TSG/SMLNET/
А>Пробовал F# (потомок Ocaml). Очень понравилось. Качественный intellysense, рожден в недрах microsoft. А>Стоит обратить внимание
Подскажите пожалуйста, как в VS.NET 2003 к проекту на F# подключать сборки? open System;; — прокатывает, а
open SdlDotNet;; — The namespace or module 'SdlDotNet' is not defined.
Хотя в GAC она есть.
Здравствуйте, Barlog M., Вы писали:
BM>Подскажите пожалуйста, как в VS.NET 2003 к проекту на F# подключать сборки? open System;; — прокатывает, а BM>open SdlDotNet;; — The namespace or module 'SdlDotNet' is not defined. BM>Хотя в GAC она есть.
Скорее всего как-то нужно подключить ссылку (Reference).
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Barlog M., Вы писали:
BM>>Подскажите пожалуйста, как в VS.NET 2003 к проекту на F# подключать сборки? open System;; — прокатывает, а BM>>open SdlDotNet;; — The namespace or module 'SdlDotNet' is not defined. BM>>Хотя в GAC она есть.
VD>Скорее всего как-то нужно подключить ссылку (Reference).
Это понятно. Но вот проект этого не предусматривает помоему.
Хотя вот соизволил заглянуть в свойства проекта (ужас, какой невнимательный. )
Там есть: DLL references and paths, прописал туда -r "C:\Program Files\SdlDotNet\binassemblies\SdlDotNet.dll"
Все заработало.
А то мне тут AndrewVK обещался показать, но так и не смог. 
.
