T>>Почему это?
AVK>Потому что моя личность к теме топика не имеет никакого отношения, и переход на личности это грубый демагогический прием.

Упоминание об ангажированности не переход на личности. Ангажированность не свойство личности, это свойство позиции, занимаемой личностью.

T>> Ангажированность не свойство личности. Это может быть следствием заблуждений.
AVK>Здесь не обсуждаются мои заблуждения.

Оба-на!

Да на всём RSDN только и делают, что обсуждают чьи-то заблуждения.

Здесь попались твои. Вот мы их и обсуждаем. В частности, заблуждения насчёт обсуждения заблуждений.

T>>>>Кстати, а ты знаешь, что творится-то в Parallel Haskell?
AVK>>>Нет, это мне на данный момент не очень интересно.
T>>Однако имеешь уверенность что-то утверждать насчёт "100 рублей".
AVK>Потому что у меня есть кое какая информация, которой я здесь поделиться, к сожалению, не могу, NDA.

Ну, так и не делись. Лучше всего вообще.

А то только домыслы и слухи порождаешь.

T>>Потому, что в нём никогда (практически никогда) не будет чего-то типа монады IO Хаскеля.
G>Монада IO в хаскеле не от хорошей жизни. ИМХО язык должен давать возможность писать имеративный код там где надо и иметь возвожность декларативно ограничивать запуск такого кода.

То, что ты описал, и есть монада IO. Вглядись.

T>>В нём не будет разделения типов выражений с эффектом и без.
G>И зачем оно надо?

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

T>>Да и неизменяемых значений тоже не будет. А без них не будет и сравнения с образцом.
G>Неизменяемые значения есть. Более того в составе Axum есть компилятор C# с какими-то эксперементалтными фичами, связанными как раз с иммутабельностью.

Ну, к 2012-му году, может быть, и дотянут.

Что для нормальных людей означает практическую невероятность. За три года можно добить до полностью рабочего состояния Agda2, тогда .Net окажется ненужным.

T>>>>Строгая типизация страдает.
G>>>Чем страдает?
T>>Ухудшением проверок. Неужто непонятно? У тебя часть на строготипизированном ЯП, другая на менее строготипизированном ЯП (вообще на скриптовом языке, как в пределе).
G>Ни разу не страдал от ухудшения проверок в .NET. Может пример адекватный приведешь?

Примем, что современный Хаскель и современный C# работают в улучшенной .Net, где ХАскель, всё-таки, работает.

А вот и пример: тип, параметризованный структурой данных.

Например, генератор XML деревьев, параметризованный схемой. data XMLTree xmlScheme where ...

На современном Хаскеле я могу написать такое (ну, почти), как мне использовать это в современном C#?

T>>Чем и хороши DSeL, что они пользуются всей мощью проверок типов базового языка.
G>Дык в Axum проверки более сильные, чем в C#. Так что про DSEL мимо кассы.

Значит, будет небезопасным использование C#/библиотек .Net в целом. Делов-то.

Это же палка о двух концах.

G>>>>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке?
T>>>>Нет. Попробуй написать на Хаскеле, должно хорошо получиться.
G>>>Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром.
T>>Но без удобных вещей типа синтаксиса, системы типов, чистого кода и сравнения с образцом.
G>Угу, сомневаюсь что в исследовательском проекте это все необходимо.

А могло оказаться совершенно бесплатно.

G>А если уж необходимо то есть F#.

Ты его использовал-то, хоть раз?

T>>Ты, вообще, HOF пользовался?
G>что есть HOF?

Higher-order functions.

T>>>>Горячая замена кода.
G>>>Горячая замена кода есть и в .NET, только больше приседаний для нее надо.
T>>И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии.
G>И что это меняет?

Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима. Fault-tolerance у ней слабый и тп.

T>>Да вообще о нём забыть надо.
G>А то вдруг .NET задавит erlang и haskell.

Меня больше волнует количество работы у людей, с .Net связанных. Оно превышает разумные пределы.

Это мешает им заниматься самообразованием, хотя с помощью (само)образования можно увеличить свой уровень на 50%. Из среднего человека стать гением.

А я не люблю, когда людям не дают реализовать себя в полной мере.

T>>Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении.
G>И что? У лиспа пиписька длиннее стала?

Он стал удобней в работе.

T>>Вопрос: какой порядок упрощения в функциональном подмножестве C#?
G>Встречный вопрос: что это меняет?

Простоту рассуждений о программах.

G>Хоть форум и называется философией, но абстрактно-теоретические рассуждения мало кому нужны.

Я прагматичен до мозга костей. Поэтому я идеалист.

T>>Я привожу сравнение с Эрлангом, где всего для параллельного программирования больше.
G>Всего это чего? Паттерн-матчинга? А чем он параллельному программиррованию помогает?

Selective receive, если говорить только о параллельном программировании.

Но он помогает программированию в целом.

G>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность?

"Прозрачно" — это как?

T>>"Что это PR" следует из минимальности нововведений в Axum.
G>Теперь осталось доказать "минимальности нововведений в Axum".
G>Для начала можешь привести критерий минимальности, а потом список нововведений в Axum.

А ты перечислил. Из совсем нового только dataflows. Всё остальное где-то уже было.

Здравствуйте, vdimas, Вы писали:

V>Странно, а как же народ пользуется IDL, всякими ASN.1, да и просто, не побоюсь этого слова, XML-based DSL? Декларативные вещи на декларативном DSL должны быть написаны, ИМХО.

Ну вот, видимо исходя из такого опыта и не хотят.

V>И сдается мне, что написать компилятор подобного "тупого" DSL на Ruby попроще будет, чем подготовить на нем же встроенный DSL.

У меня получается наоборот. Встроенный DSL на Ruby делается гораздо быстрее. И если он не отдается широкой общественности, то так проще и дешевле.

<offtopic>
Вообще, после различных DSL я пришел к мнению, что для описаний лучше всего подходит Lisp/Curl/s-expression синтаксис. Поскольку при длительном использовании DSL его обязательно приходится расширять, да так, что заранее не предугадаешь. И оказывается, что ориентированный на теги синтаксис гораздо гибче в этом отношении, чем специально заточенный под предметную область синтаксис.
</offtopic>

V>Даже если заказчики против, подобный тул сэкономит время на старте проекта, когда надо "накидать" кучу агентов. Еще поинт в том, что "сочные" описания — документация сама по себе.

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

V>И кстати, не факт, что заполнять таблицу по столбцам удобнее, повторяющиеся обработчики скорее будут для одного сообщения, поэтому может оказаться удобным после объявления сообщения тут же указать обработчиков (в духе описанного выше):
V>

->> msg1 (args) <flags>
V>   state1|state2|state3 => handler1
V>   state4 => handler2
V>   :default => IGNORE
V>

Я с разными способами описания экспериментировал. Наиболее читабельная и, в тоже время, строгая форма получается именно в приведенном мной виде. Тогда при добавлении нового сообщения сразу легко определить, в каком состоянии его еще не обработали. Для этого даже никаких специализированных инструментов не нужно. А вот в предложенной тобой записи при изменении списка состояний/событий сложнее вносить правки в описания агентов.

Здравствуйте, vdimas, Вы писали:

G>>У меня получилось. Мой планироващик отрабатывает за O(1), независимо от количества задач. Так же, как планировщик в современной венде или Linux.

V>Тебе же недоступна вся та информация, которой располагает ОС, так? Например, сотни твоих потоков ждут чего-то от ввода-вывода, откуда ты знаешь, кому давать квант?

Я стараюсь устраивать так, чтобы ожидание ввода-вывода проходило в блокировке, о которой знает планировщик. А он в свою очередь, учитывает историю поведения тредов.

V>Разве что все вызовы АПИ оборачивать своими наворотами и плодить лишние примитивы синхронизации.

Если ты хочешь, чтобы у тебя в "легкие потоки" прерывались по вводу-выводу, то тебе было бы неплохо обернуть асинхронный ввод-вывод своим кодом.

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

Здравствуйте, vdimas, Вы писали:

G>>А вообще, нет проблем сделать и планировщик с жестким рилтаймом. Алгоритмы гибридных планировщиков, обеспечивающих хард рилтайм описывались еще в книге по оперсистемам Цикридзиса-Бернстайна. Другое дело, что в случае файберов жесткие гарантии обеспечить тяжело — не охота их насильственно прерывать. Хотя — и это можно.

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

В чем проблема-то, я не пойму? Шедулер должен знать состояние всех очередей, и все.

Здравствуйте, thesz, Вы писали:

T>>>>>2) Использовать агенты в HPC — немного совсем малоэффективное решение.
E>>>>Агенты в HPC вполне могут заменить старый добрый MPI более современными решениями.
T>>>А чем они от него отличаются-то?

E>>Если речь об Axum, то там, насколько я могу судить, на уровне языка декларируются контракты между агентами.

T>Проблемы уровня библиотеки в нормальном языке.

Что-то мне подсказывает, что под нормальным языком для тебя является только Haskell.

Но мы несколько ушли в сторону. Мне интересно, считаешь ли ты, что MPI для HPC эффективное решение? И если да, то как по-твоему, если вместо MPI будут агенты, то почему агенты в HPC станут малоэффективным решением?

E>>Тогда как в MPI сборкой/разборкой сообщений программист занимается вручную. Соответственно, в MPI накосячить гораздо проще и косяки эти будут вылезать в run-time.

T>http://www.pgroup.com/products/workindex.htm

И что я по этой ссылке должен увидеть? То, что в природе существует "OpenMP and MPI parallel debugger/profiler"?

Здравствуйте, thesz, Вы писали:

G>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность?
T>"Прозрачно" — это как?
Некоторые лёгкие процессы магически превращаются в реальные процессы, работающие на своём ядре.

Здравствуйте, thesz, Вы писали:
T>Каким образом в Схеме могут изменить значение, связанное с x в функции g? Не саму "переменную" x, а значение, которое мы передадим в h.

Через set! (set-car!, set-cdr! и т.п.).

(define (h x gx)
  (display gx)(display x)(newline))

(define (f x)
  (h x ((lambda (y) (set-cdr! x y) "This is a scheme longcat: ") x)))

(f '(cat))

Здравствуйте, thesz, Вы писали:

T>>>Потому, что в нём никогда (практически никогда) не будет чего-то типа монады IO Хаскеля.
G>>Монада IO в хаскеле не от хорошей жизни. ИМХО язык должен давать возможность писать имеративный код там где надо и иметь возвожность декларативно ограничивать запуск такого кода.
T>То, что ты описал, и есть монада IO. Вглядись.

T>>>В нём не будет разделения типов выражений с эффектом и без.
G>>И зачем оно надо?
T>Для того, чтобы "иметь возможность писать императивный код там где надо и иметь возможность декларативно ограничивать запуск такого кода".

Хм... я бы предпочел что-то типа модификатора pure на функции. (как const в C++)

Хотя о таком применении монад в хаскеле я и не догадывался.. Наверное потому что хаскель не знаю.

T>>>Да и неизменяемых значений тоже не будет. А без них не будет и сравнения с образцом.
G>>Неизменяемые значения есть. Более того в составе Axum есть компилятор C# с какими-то эксперементалтными фичами, связанными как раз с иммутабельностью.
T>Ну, к 2012-му году, может быть, и дотянут.
Может быть. Я бы на более раннее сроки и не рассчитвал.
Хотя возможно в 2010 году появится более-менее стабильная версия Axum, которая обрастет всеми необходимыми фичами.

T>>>>>Строгая типизация страдает.
G>>>>Чем страдает?
T>>>Ухудшением проверок. Неужто непонятно? У тебя часть на строготипизированном ЯП, другая на менее строготипизированном ЯП (вообще на скриптовом языке, как в пределе).
G>>Ни разу не страдал от ухудшения проверок в .NET. Может пример адекватный приведешь?

T>Примем, что современный Хаскель и современный C# работают в улучшенной .Net, где ХАскель, всё-таки, работает.
T>А вот и пример: тип, параметризованный структурой данных.
T>Например, генератор XML деревьев, параметризованный схемой. data XMLTree xmlScheme where ...
T>На современном Хаскеле я могу написать такое (ну, почти), как мне использовать это в современном C#?
generics?

T>>>Чем и хороши DSeL, что они пользуются всей мощью проверок типов базового языка.
G>>Дык в Axum проверки более сильные, чем в C#. Так что про DSEL мимо кассы.
T>Значит, будет небезопасным использование C#/библиотек .Net в целом. Делов-то.
Ты неправ, уже сейчас прога на Axum не скомпилится, елси использование .NET библиотек будет опасным. Правда я не знаю как оно там работает сейчас.

T>Это же палка о двух концах.
Не факт, в компиляторе можно много чего ограничить для получения адекватного результата, в отличие от DSEL.
Ведь хаскель тоже работат на вдоску имепративном CPU с состоянием.

G>>>>>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке?
T>>>>>Нет. Попробуй написать на Хаскеле, должно хорошо получиться.
G>>>>Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром.
T>>>Но без удобных вещей типа синтаксиса, системы типов, чистого кода и сравнения с образцом.
G>>Угу, сомневаюсь что в исследовательском проекте это все необходимо.

T>А могло оказаться совершенно бесплатно.
Каким образом?

G>>А если уж необходимо то есть F#.
T>Ты его использовал-то, хоть раз?
Много раз.

T>>>Ты, вообще, HOF пользовался?
G>>что есть HOF?
T>Higher-order functions.
Я предпочитаю русское буквосочетание — ФВП.

T>>>>>Горячая замена кода.
G>>>>Горячая замена кода есть и в .NET, только больше приседаний для нее надо.
T>>>И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии.
G>>И что это меняет?

T>Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима.
"Можно" не означает "целесообразно". Мало где применима чаще всего означает низкий уровень пихальщиков .NET.
По твоей логике можно haskell везде запихнуть, только я софта на хаскеле не видел вообще.

T>Fault-tolerance у ней слабый и тп.
В чем это выражается? А то я вижну только одну цепочку рассуждений "нету средств как в Erlang -> Fault-tolerance слабый", почему нельзя сделать сильный Fault-tolerance другими средствами?

T>>>Да вообще о нём забыть надо.
G>>А то вдруг .NET задавит erlang и haskell.
T>Меня больше волнует количество работы у людей, с .Net связанных. Оно превышает разумные пределы.
Это же хорошо, люди деньги зарабатывают
Есть предложения как уменьшить количество работы?

T>Это мешает им заниматься самообразованием, хотя с помощью (само)образования можно увеличить свой уровень на 50%. Из среднего человека стать гением.
Странно. Как раз среда типа .NET, которая предлагает совершенно разные подходы к разработке, выраженные в разных языках и фреймворках, дает гораздо больше возможностей для развития, чем другие среды. Причем нету необходимости изучать что-то вне конкретного языка или платформы, так как база общая.
Кромем того можно изучение чего-то нового совмещать с основной работой.

Я например в ФП разобрался благодаря C# и F#, хрен бы у меня время нашлось для изучения OCaml с нуля. Теперь скриптовые языки изучаю, причем у меня нету необходимости изучать немалые фреймворки python или ruby чтобы писать на них части своих программ. Посмотрев библиотеки PFX, CCR\DSS и Axum я теперь немного понимаю в параллельном программировании во всех его проявлениях.

T>А я не люблю, когда людям не дают реализовать себя в полной мере.
Аналогично.

Здравствуйте, thesz, Вы писали:

T>>>Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении.
G>>И что? У лиспа пиписька длиннее стала?
T>Он стал удобней в работе.
Чем?

T>>>Вопрос: какой порядок упрощения в функциональном подмножестве C#?
G>>Встречный вопрос: что это меняет?
T>Простоту рассуждений о программах.
Зачем рассуждать о программах?

Здравствуйте, thesz, Вы писали:

T>>>Я привожу сравнение с Эрлангом, где всего для параллельного программирования больше.
G>>Всего это чего? Паттерн-матчинга? А чем он параллельному программиррованию помогает?

T>Selective receive, если говорить только о параллельном программировании.
В Axum подобная фича реализуется разными портами, если я вообще правильно понял о чем речь.

T>Но он помогает программированию в целом.
Не спорю. Вопрос в том насколько отсуствие ПМ критично для программирования в целом. Практика показывает что некритично.

G>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность?
T>"Прозрачно" — это как?
Ну так что программисту не надо ничего писать чтобы несколько "проснувшихся" агентов одновременно работали на нескольких ядрах.

T>>>"Что это PR" следует из минимальности нововведений в Axum.
G>>Теперь осталось доказать "минимальности нововведений в Axum".
G>>Для начала можешь привести критерий минимальности, а потом список нововведений в Axum.

T>А ты перечислил. Из совсем нового только dataflows. Всё остальное где-то уже было.
Ну там еще много много вчего попмио dataflows, явная изоляция с помощью domain. reader и writer агенты для синхронизации доступа к разделяемым данным.
И множесто боле мелких фишек.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, thesz, Вы писали:

G>>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность?
T>>"Прозрачно" — это как?
C>Некоторые лёгкие процессы магически превращаются в реальные процессы, работающие на своём ядре.
Не, такой хардкорной магии в Axum нету. Там просто тредпул по количеству доступных ядер, шедулер запускает все агенты в доступных потоках.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, thesz, Вы писали:

G>>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность?
T>>"Прозрачно" — это как?
G>Ну так что программисту не надо ничего писать чтобы несколько "проснувшихся" агентов одновременно работали на нескольких ядрах.

ну дак SMP давно в эрланге есть, некоторые издержки на многоядерность, конечно, есть, но их всё меньше, да и где их нет?

Здравствуйте, gandjustas, Вы писали:

T>>Fault-tolerance у ней слабый и тп.
G>В чем это выражается? А то я вижну только одну цепочку рассуждений "нету средств как в Erlang -> Fault-tolerance слабый", почему нельзя сделать сильный Fault-tolerance другими средствами?

Ой, ё. Какой наивный вопрос!

G>Я например в ФП разобрался благодаря C# и F#, хрен бы у меня время нашлось для изучения OCaml с нуля. Теперь скриптовые языки изучаю, причем у меня нету необходимости изучать немалые фреймворки python или ruby чтобы писать на них части своих программ. Посмотрев библиотеки PFX, CCR\DSS и Axum я теперь немного понимаю в параллельном программировании во всех его проявлениях.

Начинать знакомство с параллельным программированием, имхо, лучше было с вот таких статей, а не с PFX, CCR и Axum:
Introduction to Parallel Computing: Part 1
Introduction to Parallel Computing: Part 2
(ну и далее по ссылкам).

E>>>Если речь об Axum, то там, насколько я могу судить, на уровне языка декларируются контракты между агентами.
T>>Проблемы уровня библиотеки в нормальном языке.
E>Что-то мне подсказывает, что под нормальным языком для тебя является только Haskell.

Что могло натолкнуть тебя на эту мысль? Где я прокололся?

E>Но мы несколько ушли в сторону. Мне интересно, считаешь ли ты, что MPI для HPC эффективное решение? И если да, то как по-твоему, если вместо MPI будут агенты, то почему агенты в HPC станут малоэффективным решением?

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

MPI лучше, чем агенты, поскольку дольше существует. Поэтому он лучше отработан на кластерах.

E>>>Тогда как в MPI сборкой/разборкой сообщений программист занимается вручную. Соответственно, в MPI накосячить гораздо проще и косяки эти будут вылезать в run-time.

T>>http://www.pgroup.com/products/workindex.htm

E>И что я по этой ссылке должен увидеть? То, что в природе существует "OpenMP and MPI parallel debugger/profiler"?

Автоматическое распараллеливание программ для MPI.

Здравствуйте, eao197, Вы писали:

E>Начинать знакомство с параллельным программированием, имхо, лучше было с вот таких статей, а не с PFX, CCR и Axum:
E>Introduction to Parallel Computing: Part 1
E>Introduction to Parallel Computing: Part 2
E>(ну и далее по ссылкам).
Это теория, а как оно делается на практике — совершенно другой вопрос.

T>>Каким образом в Схеме могут изменить значение, связанное с x в функции g? Не саму "переменную" x, а значение, которое мы передадим в h.

MC>Через set! (set-car!, set-cdr! и т.п.).
MC>

MC>;(define (h x gx)
MC>;  (display gx)(display x)(newline))

MC>;(define (f x)
MC>;  (h x ((lambda (y) (set-cdr! x y) "This is a scheme longcat: ") x)))
MC>;

Здесь у тебя ошибка. для set-cdr нужна переменная, вот ты и используешь x. в теле g переменная x недоступна, доступно только значение.

MC>

MC>;(f '(cat))
MC>;

Вот мой вариант (бляха муха, я теперь ещё и Лисп теперь знаю лучше, чем мне бы хотелось):

(define (h x gx)
  (display gx)(display x)(newline))

(define (g x)
  set-cdr! x '(a b c))

(define (f1 x)
  (h x (g x)))
(define (f2 x)
  (h (g x) x))
(f1 '(cat dog))
(f2 '(cat dog))

Вывод:

(a b c)(cat dog)
(cat dog)(a b c)

То есть, значение x в f не изменилось.

Чтд.

T>>>>В нём не будет разделения типов выражений с эффектом и без.
G>>>И зачем оно надо?
T>>Для того, чтобы "иметь возможность писать императивный код там где надо и иметь возможность декларативно ограничивать запуск такого кода".
G>Хм... я бы предпочел что-то типа модификатора pure на функции. (как const в C++)

Вопрос умолчаний.

С выводом типов это вообще не вопрос.

T>>На современном Хаскеле я могу написать такое (ну, почти), как мне использовать это в современном C#?
G>generics?

Попробуй. Если я ещё и доказательства прикручу в виде типов классов, то никакие generics не спасут.

T>>Это же палка о двух концах.
G>Не факт, в компиляторе можно много чего ограничить для получения адекватного результата, в отличие от DSEL.

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

G>Ведь хаскель тоже работат на вдоску имепративном CPU с состоянием.

А всё написано на ассемблере, да-да.

T>>>>>>Горячая замена кода.
G>>>>>Горячая замена кода есть и в .NET, только больше приседаний для нее надо.
T>>>>И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии.
G>>>И что это меняет?

T>>Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима.
G>"Можно" не означает "целесообразно". Мало где применима чаще всего означает низкий уровень пихальщиков .NET.

Она такая по построению.

G>По твоей логике можно haskell везде запихнуть, только я софта на хаскеле не видел вообще.

Во, куда скатились. Круто! А про императивный CPU так вообще отпад.

Это аргумент середины 70-х про языки высокого уровня.

T>>>>Да вообще о нём забыть надо.
G>>>А то вдруг .NET задавит erlang и haskell.
T>>Меня больше волнует количество работы у людей, с .Net связанных. Оно превышает разумные пределы.
G>Это же хорошо, люди деньги зарабатывают

http://en.wikipedia.org/wiki/Parable_of_the_broken_window

G>Есть предложения как уменьшить количество работы?

Головой больше думать. Не делать ненужной работы. Не выбирать платформы и языки, где нужна ненужная работа.

T>>Это мешает им заниматься самообразованием, хотя с помощью (само)образования можно увеличить свой уровень на 50%. Из среднего человека стать гением.
G>Странно. Как раз среда типа .NET, которая предлагает совершенно разные подходы к разработке, выраженные в разных языках и фреймворках, дает гораздо больше возможностей для развития, чем другие среды. Причем нету необходимости изучать что-то вне конкретного языка или платформы, так как база общая.

1) Очень низка скорость внесения этого чего-то нового.
2) Чего-то новое обычно оказывается C#, вид в профиль. Даже старое им оказывается.

G>Я например в ФП разобрался благодаря C# и F#, хрен бы у меня время нашлось для изучения OCaml с нуля. Теперь скриптовые языки изучаю, причем у меня нету необходимости изучать немалые фреймворки python или ruby чтобы писать на них части своих программ. Посмотрев библиотеки PFX, CCR\DSS и Axum я теперь немного понимаю в параллельном программировании во всех его проявлениях.

Уверяю тебя, ты всё равно ничего не знаешь про ФП, про скриптовые языки и про параллельное программирование.

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

У тебя этого под рукой нет.

Ты не писал большой проект на скриптовом языке.

Ты знаешь о параллельном программировании только то, что в MS сочли нужным тебе показать.

Все эти знания приходится в тебя проталкивать, как вот в этом топике, и в других.