Здравствуйте, VladD2, Вы писали:
CU>>А можно забыть про "нравится/не нравится" в отношении ЯП? А то сразу приходит на ум, что женщины выбирают автомобиль в первую очередь по цвету.
VD>И правильно делаю. Им на него ведь еще долго смотреть прийдется. Да и вторая очередь у них тоже иногда есть...
Ага — как она будет выглядить сидя в такой машине и размер зеркал...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>>>Нет там потоков. К>>>>В том весь и смысл, что параллельность получается не на потоках ОС, т.е. нет постоянных переключений контекста, что позволяет ускорить работу приложения (при наличии нескольких процессов).
VD>>>Ты бы разобрался в том что обсуждаешь, а потом бы разговоры вел. Чушь ведь несешь. К>>Ты бы читал сначала, прежде чем отвечать, Влад, это уже просто из раза в раз повторяется.
VD>Я то читаю очень даже внимательно. Погляди на выделенное. Это заблуждения. Ничего ускорить они не позволяют (Эрлэнг не волшебная палочка). Они позволяют реализовать параллельное (точнее псевда-параллельное) исполнение нескольких зеленых потоков (Эрлэнг-процессы). Но они будут исполняться на одном физическом потоке ОС. И для реального распараллеливания прийдется создать втрой поток ОС и запустить на нем другие зеленые потоки.
Получается, что мы говорим о сферических конях в вакууме...
Наверное фраза "несколько процессов" не совсем корректная, точнее было бы говорить о хотябы сотнях процессов
К>> Я же гововорил, что нет постоянного переключения между тредами
VD>Да, но и нет ускорения выполнения на многопроцессором железе по сравнению с тупым созданием несколькоих потоков ОС.
Влад, ты пытаешься говорить о параллельности не беря в расчёт характер решаемой задачи совсем? Несколько странный подход
К>> (что было бы в реализации процессов чисто на потоках). И именно засчёт этого и получается выигрыш.
VD>Ну, что же. Предлагаю тупо провести эксперемент. Берем классичкий алгоритм QuickSort и реализуем его на Эрлэнг и каком-то языке дотнета (Шарпе или Немерле). Причем в дотнетом языке вручную распараллелим выполнение метода на потоках (по числу процессоров в системе). Уверен, что Эрлэнг сольет.
Т.е. всё сошлось на многопроцессорности?
В данной задаче узким местом может оказаться, конечно пересылка сообщений (если массив достаточно большой), но никто и не позиционирует Эрланг как числодробилку или инструмент для обработки данных заметного объёма.
Но в Немерле/Скале нет OTP, поэтому для массовой параллелизации Эрланг вещь заметно более подходящая.
К>>И твои слова как раз являются описанием того, что я имел в виду. Чуть более подробным.
VD>Я бы так не сказал.
К>>Просто фантом сказал, что будет много круче из-за разницы между потоками явы и .нет. Я же сказал, что это тут совсем не существенно (возможно многопроцессорность сделает это более значимым, но это другая тема).
VD>Вы оба не правы. Эрлэнг хорош не тем что он куруто распараллеливает выполнение на разных процессорах. Эрлэнг крут своей моделью паралеллизма. Он обеспечивает автоматическое и безконфликтное распараллеливание. Это позволяет выполнять (псевдо) параллельно множество нерисорсоемких задач. При этом мы избавлены от необходимости думать о синхронизации. Но за это мы платим разбиением алгоритма на отдельные процессы и обязаны обемниваться данными между ними с помощью сообщений. Такой подход очень хорош когда надо обеспечить отклик множеству параллельных клиентов. Но практически ничего не дает в алгоритмическом плане.
Блин, кто говорил про выполнение на разных процессорах?
Речь шла именно о паралеллизме и как раз о множетве задач. Эрланг далеко не серебрянная пуля, но в своей нише он даёт очень хорошие преимущества, но платить приходится именно другим подходом к реализации решения задачи.
PI>>регекспы, особенно с look-behind/look-forward условиями, сдохнут и на мегабайтной строке
VD>Если только они написаны очень криво. Вообще-то регексы переводятся в ДКА, а это дин из самых эффективных средств прасинга.
ну не знаю... пост-фактум они тормозили, причём так, что я не поленился, и переписал их в оптимизированные строковые версии..
Здравствуйте, VladD2, Вы писали:
С>>Это все можно сказать и про любые другие инструменты. А если есть опыт работы с unix-системами, то изучать дополнительно ничего и не надо — они аналогичны одноменным никсовым утилитам. VD>А если нет? Мне однобуквенные сокращения совсем не нравятся. А комплита и т.п. нет.
Здравствуйте, IT, Вы писали:
IT>Вменяемый персонал переобучивается с C# на Немерле за считанные часы. В этом вся фишка. Самая большая проблема — это усвоить, что типы теперь указываются не так:
Персонал можно вообще не переучивать при переходе с Java 1.4 на Java 1.5. Однако, позиция руководства, весьма понятная и трудно поколебимая, мне ясна. Написан и выпущен продукт, который прошел полномасштабное тестирование на 1.4. Зачем. Повторюсь, зачем подвергать себя (руководство) риску и переходить на Java 1.5 и выпускать новую перекомпилированную версию (а если этого не сделать, то будет несовместимость с обновлениями), иметь дополнительные трудности с объяснением заказчику разницы между 1.4 и 1.5 и что надо устанавливать последнюю и иметь несколько потенциальных ошибок (как мелких, так и, возможно, очень досадных)? Или зачем опять тратиться на полномасштабное тестирование продукта и замедление развитие оного? ЗАЧЕМ?
К>Блин, кто говорил про выполнение на разных процессорах? К>Речь шла именно о паралеллизме и как раз о множетве задач. Эрланг далеко не серебрянная пуля, но в своей нише он даёт очень хорошие преимущества, но платить приходится именно другим подходом к реализации решения задачи.
чето я не понимаю, Эрланг работает реально на нескольких процессорах или нет?
потому что я когда говорю о параллельности, я понимаю несколько ядер/процессоров
хотя и не реализовывал что-либо, круто заваренное на параллельности, но в будущем — вполне возможно
за пяток лет я надеюсь, подтянутся 4-8-16-ядерные процы и 2-4-процессорные матери для них (по приемлемой цене)
тогда будет интересно, ага.. хотелось бы заранее знать, что изучать/дорабатывать придётся, чтобы воспользоваться этой мощёй в распараллеливаемых вычислительных задачах...
таким образом, в условиях тяжеловычислительных задач, которые необходимо запускать сразу на многих:
— ядрах
— процах
— машинах (сетках с различающимися скоростями обмена — локальные/инет)
хотелось бы знать, какие существуют (удобные) решения для разруливания подобных задач
или находящиеся в стадии разработки/исследований проектов, типа скаловской конкаррент-библиотеки
короче, обзорно в 2 словах кто-нибудь может сказать чёнить определённое?
Здравствуйте, PhantomIvan, Вы писали:
К>>Блин, кто говорил про выполнение на разных процессорах? К>>Речь шла именно о паралеллизме и как раз о множетве задач. Эрланг далеко не серебрянная пуля, но в своей нише он даёт очень хорошие преимущества, но платить приходится именно другим подходом к реализации решения задачи.
PI>чето я не понимаю, Эрланг работает реально на нескольких процессорах или нет?
Работает, правда поддержку добавили не так давно Но можно было с лёгкостью запустить несколько инстансов ВМ эрланга на разных процах, если ОС это поддерживает. Возможно накладные расходы на пересылку сообщений были бы побольше, конкретики не знаю, не скажу. Сижу на однопроцессорном селероне
PI>потому что я когда говорю о параллельности, я понимаю несколько ядер/процессоров
Т.е. многозадачность не считается уже совсем?
Скажем вебсервер на однопроцессорной системе без гипертрединга уже параллельно запросы обслуживать не может?
Я понимаю, что будущее за многопроцессорностью, но всёже многозадачность всёже играет значительную роль.
PI>таким образом, в условиях тяжеловычислительных задач, которые необходимо запускать сразу на многих: PI>- ядрах PI>- процах PI>- машинах (сетках с различающимися скоростями обмена — локальные/инет) PI>хотелось бы знать, какие существуют (удобные) решения для разруливания подобных задач PI>или находящиеся в стадии разработки/исследований проектов, типа скаловской конкаррент-библиотеки
PI>короче, обзорно в 2 словах кто-нибудь может сказать чёнить определённое?
А что такое "тяжёловычислительные задачи"? Или ты предпочитаешь писаль большие сильносвязные проекты, про которые, где-то Влад тут рядом говорил? Как ты относишься к правилу "разделяй и влавствуй"?
Я думаю гораздо правильней разбить задачу на части, чтобы уже их параллелить. А не далать какие-нибудь "финты ушами" с большими монолитными системами.
По поводу разработок — кроме того, что я тут уже упоминал могу ещё сказать, что есть Stackless, на Хаскеле наработки были (но я не спец по этому языку, поэтому ), ещё какие-то линки по поводу пи-исчисления видел (тоже вроде на Хаскеле).
А что-нибудь определённое ты по поводу чего конкретно хотел, а?
Здравствуйте, eao197, Вы писали:
IT>>Да и, если често, скажи мне, к какой документации ты обращаешься чаще, к документации по библитекам или по языку?
E>На момент обучения -- к документации по языку. Мне, например, существующая документация по Scala не понравилась.
Скалу не видел, но из твоих слов могу предположить, что между ней и джавой гораздо больше внешних различий чем между N и C#. К тому же в C# есть такие вещи как делегаты, в том числе анонимные, понимание которых и умение работать с ними делают вхождение в FP более гладким.
E>Часть слишком поверхностная, часть слишком сложная. От документации по Nemerle у меня пока тоже впечатление не ахти.
Мне было достаточно, но я под .NET на C# пишу уже много лет. Если же ты не знаком с .NET достаточно хорошо и пытаешься перейти с Java или C++ на Nemerle, то основной проблемой у тебя будут не сам Nemerle как таковой, а именно платформа. При этом неважно, начинаешь ли ты с VB.NET, C# или Nemerle. Именно по этой причине я не знаю и не очень стремлюсь познать джаву. Думаю, с языком у меня проблем не будет (кроме, конечно, некоторых разочарований), но вот на изучение платформы я могу потратить массу времени, что мне абсолютно ни к чему.
IT>>Вменяемый персонал переобучивается с C# на Немерле за считанные часы. В этом вся фишка. Самая большая проблема — это усвоить, что типы теперь указываются не так:
E>Это и все? Единственный аргумент к руководству?
К какому руководству?
E>А Java начилась с апплетов, которые вообще ни на чем писать нельзя было. Затем был опять Web, но уже серверная часть, которую на Java было делать проще, чем CGI C/Perl. Так что шел переход программистов в новую нишу с использованием новых языков.
Это не словом прогресс случайно называется? Зачем им вообще было куда-то переходить? Сидели бы себе на плюсах или турбо-паскеле под досом
IT>>Заслуга же самого язык в том, что он максимально приближен к C# и позволяет осуществлять переход с него очень плавно и безболезненно. Мне лично понадобилось всего пару часов для ознакомления с Немерле, после чего потекли слюнки и зачесались руки.
E>Я так и не понял зачем кто-то будет менять C# на Nemerle сейчас.
Если ты не понимаешь в свои годы, что означает слово прогресс, то мне сложно будет тебе это объяснить. Зачем люди придумывают новые машины и самолёты, зачем постоянно из года в год увеличивают быстродействие компрьютеров, зачем увеличивают размеры плазменных телевизоров? Зачем всё это?
Очевидно, чтобы быстрее, дешевле, качетсвеннее, удобнее. Вот и Nemerle позволяет писать софт быстрее, дешевле, качественнее и удобнее.
E>Не всем же нужна compile-time генерация в собственном фреймворке.
Ты не говори за всех. Ты лучше для себя определись, тебе лично нужна compile-time генерация? Мне нужна и я очень чётко представляю себе границы её применения уже сегодня. Но подозреваю, что завтра она будет использоваться в таких местах, о которых я пока ещё даже и не подозреваю.
Если нам не помогут, то мы тоже никого не пощадим.
К>Т.е. многозадачность не считается уже совсем? К>Скажем вебсервер на однопроцессорной системе без гипертрединга уже параллельно запросы обслуживать не может? К>Я понимаю, что будущее за многопроцессорностью, но всёже многозадачность всёже играет значительную роль.
ну, многозадачность — это то, что само собой разумеется, оно уже есть в робастном виде в осях — разделение на процессы
а вебсервер в рамках одного процесса — это вопрос скорее параллельный, нежели многозадачный
К>А что такое "тяжёловычислительные задачи"?
ну, это такие задачи, где нагружаешь свой комп, выжимаешь из него всё, что можно, но этого не хватает
потому если есть доступ к сетке из компов, начинаешь распределять вычисления на компы
а в некоторых случаях вообще суперкомпьютеры нагружать...
иногда приходится упрощать постановку задачи или вводить эмпирику в работу, и всё равно, ресурсов мало и мало...
ну, навскидку:
— задача коммивояжера (поиск гамильтонового цикла в графе)
— трассировки (строительная, приведение графа к плоскому)
— моделирование турбулентности (как пример особо тяжёлых симуляций)
К> Или ты предпочитаешь писаль большие сильносвязные проекты, про которые, где-то Влад тут рядом говорил?
да, именно такие — большой слабосвязный проект на мой взгляд это не проект, а набор простых проектов
в этом ничего военного нет, поэтому мне особенно интересны такие проекты, которые требуют от меня больше, чем просто хороший кодинг (вплоть до макросов и пр.) и знания технологии
К> Как ты относишься к правилу "разделяй и влавствуй"?
очень положительно
тем не менее, с алгоритмической точки зрения, он не всегда применим
а с точки зрения идеологической, я стараюсь интегрировать в некотором смысле, обобщать, нежели реализовывать конвейер частных случаев...
К>А что-нибудь определённое ты по поводу чего конкретно хотел, а?
не, пока так, интереса ради
плюс осознаю, что мало понимаю в том, какой правильный путь хренячить мультипоточные программы
в своей качалке, например, у меня раз в 10 часов происходит глюк из-за того, что я где-то не додумал что-то лочить...
но искать багло мне в лень, уж лучше дождусь, когда разбогатею и куплю железо с 2 процами или хотя бы 2 ядрами
тогда будет, я думаю, очень просто ловить мультитредовые баги (типа отладки гуи на 2 мониторах)
Здравствуйте, Turtle.BAZON.Group, Вы писали:
IT>>Вменяемый персонал переобучивается с C# на Немерле за считанные часы. В этом вся фишка. Самая большая проблема — это усвоить, что типы теперь указываются не так:
TBG>Персонал можно вообще не переучивать при переходе с Java 1.4 на Java 1.5. Однако, позиция руководства, весьма понятная и трудно поколебимая, мне ясна. Написан и выпущен продукт, который прошел полномасштабное тестирование на 1.4. Зачем. Повторюсь, зачем подвергать себя (руководство) риску и переходить на Java 1.5 и выпускать новую перекомпилированную версию (а если этого не сделать, то будет несовместимость с обновлениями), иметь дополнительные трудности с объяснением заказчику разницы между 1.4 и 1.5 и что надо устанавливать последнюю и иметь несколько потенциальных ошибок (как мелких, так и, возможно, очень досадных)? Или зачем опять тратиться на полномасштабное тестирование продукта и замедление развитие оного? ЗАЧЕМ?
Насколько мне известно у джавы проблемы совместимости версий — это обычное дело. В таких условиях позиция руководства вполне разумна как минимум до релиза. А если продукт не предполагается в дальнейшем сопровождать и развивать в течени нескольких лет, то переходить на новую версию платформы в конце пути вообще никакого смысла не имеет.
Но вот что твоё руководство скажет при начале работ над новыми проектами — это очень хороший вопрос. Лет десять назад моё руководство сказало — лучшее враг хорошего. Через год мы остались без заказов и практически вылетели из бизнеса, контора только чудом уцелела. Тогда это был переход с DOS на Windows и случай, конечно не совсем равноценный. Но зато очень поучительный.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, PhantomIvan, Вы писали:
VD>>Это зависит от качества реализации.
PI>я имел в виду тождественные реализации
Ладно. Выяснюсь яснее. Скорость работы подобных фрэймворков намного больше (можно сказать несравнимо больше) зависти алгоритмического решения и используемых примитивово синхронизации нежели от того на базе какой платформы реализуется фрэймворк.
PI>(а вообще, когда я говорю о параллельности, я имею в виду параллельность на основе нормальных потоков оси)
Ох, ох, ох...
Ладно. Видимо и по этому вопросу прийдется говорить развернуто.
Есть две основные проблемы параллелизма.
1. Для распараллеливания вычислений современными средствами (то есть потоками ОС) необходимо прикладывать много усилий.
2. При распараллеливании современными средствами приходится пользоваться синхронизацией которая очень часто сводит на нет приемущество от параллельного выполнения на разных процессорах.
Создание сложного и качественного софта и так сложная проблема, а перечисленные выше проблемы еще более ее усложняют. Именно по этому на рынке крайне мало софта получающего приемущество от увеличения числа процессоров. И почти нет софта который бы хорошо масштабировался.
Есть два пути решения этих проблем.
1. Создание языков и компиляторов которые автоматически выявляли бы участки кода которые можно выполнять параллельно и генерировали бы "параллельный" код. Тут множество сложностей. Начиная с того, что на разных машинах разыное число прцессоров (тут помог бы джит и преп-джит), до того что компилятор может часто ошибаться распараллеливая участки кода которые выполняются стольк быстро, что разделение вычислений и синхронизация будет отнимать больше времени нежели вычисления произведенные на одном камне.
2. Явное разделение задач на подзадачи и организация фрэймворков позволяющих бесшовно связывать эти параллельные задачи.
Эрлэнг и акторы Скалы как раз пытаются идти по втрому пути. За счет полного раделения областей памяти (процессов в терминалогии Эрлэнга) они позволяют отказаться от явной синхронизации. Общение межу процессами (опять же в терминлогии Эрлэнга) при этом ведется по средствам ассинхронных сообщений. Урощенно это можно предствать так как будто у каждого такого процесса (изолированного графа объектов, или области памяти, как кому проще предствалять) есть своя очередь сообщений. Если кто-то хочет передать данные этому процессу, то он формирует сообщение (независимый граф объектов который не может изменяться в процессе передачи и обработки) которое помещается в эту очередь. Псевдо процесс пасет эту очередь и выгребает из нее сообщения. При помещении в очередь и при извлечении из нее данных производится легкая синхронизация. А возможно используются хитрые структуры котрые позволяют вообще обойтись без синхронизации.
Проблема такого подхода заключается в том, что с одной стораны фактически распараллеливанием занимаемся мы вручную. Фрэймворк позволяет упростить это, но не снимает с нас задачи ручного разбиения алгоритмов на састовляющие. Такой подход хорош для сайтов идргих систем обрботки данных для множества пользователей или источников (та же телекомуникация), но не приемлем для вычислительных задач (или плох для них).
Вторая проблема подхода заключается в том, что данные фактически сериализуются (копируются). Это требует времени и памяти.
Выигрышь же заключется в том, что очень легко организовать как псевдо-параллелизм (на зеленых потоках, файберах или ручном переключении упрощенного контекста), лекго запустить параллельное выполнение на отдельных потках ОС или даже на разных компьютерах в разных "физических" процессах ОС (для программ это прозрачно, они не видят разницы).
В общем, решение это не уриверсальное, но в некоторых случаях оно намного эффективнее ручного решения (на потокх ОС).
Ктогда кто-то говорит о неворятной эффективности Эрлэнга, то они или не допонимают то о чем говорят, или намеренно лгут. Дело в том, что единственное в чем имеет приемущетсво Эрлэнг — это в том, что его упрощенный контекст очень мал. Это позволяет организовать очень дешевый псевда-параллелизм, то есть псевда-параллельное вполнение (на одном процессоре с переключением между задачами) большого количеста задач. Происходит это от части от того, что Эрлэнг функциональный язык (а они в принципе весь контекст держат в стеке) и от того, что Эрлэнг специально проектировался под уменьшение контекста. По сем организация подобных фрэймворков на универсальных ЯП общего назначения не простая задача. Но вполне выполнимая.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Так уж повелось, что в ИТ технологии, которые "лучше", и технологии, которые "используются" связаны друг с другом весьма слабо.
Думаю, что они именно что "лучше", т.п. в ковычках лчше.
V> Примеров тому можно найти вагон и маленькую тележку. И если Майкрософт не решит вдруг заменить свое детище C# на Немерле, то последнего ожидает в лучшем случае судьба смолтолка, каким бы он не был замечательным.
Не МС-ом единым. Думаю если наших сил хватит, то Немерле и так вылезет. Но почти уверен, что если он начнет набирать популярность, то МС, Сан и ИБМ быстренько спохватятся и начнут делать "свой Немерле, но другой" (с).
V> А причину, которая смогла бы заставить Майкрософт отказаться от С# в пользу Немерле я не могу себе представить. Если у тебя фантазия богаче, поделись
Шарп уже идет по направлению к Немрле. 3.0 уже обладает довольно достойной реализацией функций как первокласных объектов. В 4.0 глядишь добавят паттерн-матчинг и алгеброические типы. А в 5.0 может и макросы увидим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Синтаксически, это, конечно, не "классический list comprehension", но семантически — вполне себе.
Не, это ты продемонстриовал набор функций аля ЛИНКС. В коментариях у тебя вообще был почти сиквел-запрос. А лист-компрехеншон это фича из Хасклея которую реализовали в некоторых языках (в том числе на макросах в Немерле).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Хм. Читал недавно толстую книжку про регэкспы. Автор утверждает, что в Java и .Net — НКА.
За Яву не скажу, а в дотнете НКА. От того и тормозят даже в скомпилированном виде (сильно).
А качественные регексы в LEX/FLEX. Их там и использовать проще. Они правда по проще. Но для большинства задач их за глаза хватает.
ANS> Наиболее продвинутый движок в Tcl — ДКА/НКА в зависимости от. Где регэкспы ДКА уже не помню. Может в grep?
Продвинутых море. Но они не так известны как стандартыне бибилотеки дотнета и Явы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _rasta, Вы писали:
VD>>Греп не более чем утилита.
_>и тем не менее работает. изначально предпологалось что она отвалится.
Да по фигу отвалится или нет. Важно что это просто утилита. Написать код кторый перемалывает 10 гиг можно на чем угодно. Была бы потребность. Ну, и время на перемалывание этих 10 гиг.
VD>>К самим шел-скриптам отношения не имеет.
_>хм... а что имеет?
Собственно встроенные команды. Знаешь какой главный недостаток make был озвучен при создании Ant-а? Зависимость от утилит ОС. Вот та же фигня в скриптах шела. Не перенесли утилитку на другую ОС и приши пропало.
Если же утилита реализована на управляемом языке она будет доступна везде где он есть.
_>если конструкции вида _>x=`cat ~/log/log.log` _>y=`echo $x | grep bla` _>отработают, значит имеет
Ну, и какая разница если тот же греп будет объектом?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, raskin, Вы писали:
R>Вполне имеет. Shell-скрипты пишут для исполнения на unix-подобных R>системах, которые должны примерно быть похожими хоть на какой-то R>стандарт: POSIX, SUS, SysV. И в любом случае grep должен быть. Так что в R>shell-скриптах наличие grep считается гарантированным.
Ну, а что будешь делать если грепа не хватит? Ну, нужна тебе другая функциональность?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Скалу не видел, но из твоих слов могу предположить, что между ней и джавой гораздо больше внешних различий чем между N и C#. К тому же в C# есть такие вещи как делегаты, в том числе анонимные, понимание которых и умение работать с ними делают вхождение в FP более гладким.
Гладким, но не достаточно глубоким. Вопросы хвостовой рекурсии, паттерн-матчинга (и способов избежания спаггети кода в случае паттерн-матчинга), различных fold-ов и map-ов -- все это требует серьезного изучения.
IT>>>Вменяемый персонал переобучивается с C# на Немерле за считанные часы. В этом вся фишка. Самая большая проблема — это усвоить, что типы теперь указываются не так:
E>>Это и все? Единственный аргумент к руководству?
IT>К какому руководству?
Хороший вопрос. У тебя, как я понял, руководства нет. Зато есть у других, в том числе и у меня.
E>>Я так и не понял зачем кто-то будет менять C# на Nemerle сейчас.
IT>Если ты не понимаешь в свои годы, что означает слово прогресс, то мне сложно будет тебе это объяснить.
Извини, это демагогия с помощью общих слов.
Sun в свое время очень нехило поспособствовало тому, что ты называешь прогрессом. Даже еще до изобретения Java, просто начав выпуск своего Unix-а и разработав NFS. MS так же двигает прогресс, выпуская .NET и C#. Причем они не останавливаются. И тут на их фоне появляется что-то интересное, но нераскрученное и не поддерженное серьезными игроками. Ты решил рискнуть и поставить на эту темную лошадку.
А как ту думаешь, сколько предпочтут очередного шага в стророну прогресса от более солидных игроков? И, зная, что эти игроки не замедлят себя ждать, какой смысл сейчас рисковать?
IT>Очевидно, чтобы быстрее, дешевле, качетсвеннее, удобнее. Вот и Nemerle позволяет писать софт быстрее, дешевле, качественнее и удобнее.
Я думаю, это в твоих частных условиях так.
E>>Не всем же нужна compile-time генерация в собственном фреймворке.
IT>Ты не говори за всех. Ты лучше для себя определись, тебе лично нужна compile-time генерация?
Мне нет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Если нам не помогут, то мы тоже никого не пощадим.
