Ответ на »сообщение 4845« (Илья Ермаков)
___________________________

А "тормознутость" Апача зависит не от Апача, а от низлежащих операционных систем вроде Винды/Юникса, которые строились сами знаете на идеях какой давности, и больше той самой пресловутой тысячи потоков в принципе держать не могут.

Ну не знаю, не знаю...
Я как-то запустил миллион потоков на Хаскелле, тормозило, но работало.
Правда, работой это назвать трудно - всего лишь увеличение на единицу одной глобальной переменной-счётчика. Тест, конечно, несерьёзный, но всё-же...

Ответ на »сообщение 4843« (Geniepro)
___________________________

Ответ на »сообщение 4842« (Илья Ермаков)
Недавно на RSDN'е огрмный флейм по этому поводу возник - насколько хороши десятки и сотни тысяч лёгких процессов Ерланга в сравнении с несколькими агентами (активными объектами), реализованными в тяжёлой многозадачности.
Основной довод ерлангеров - реактивность и надёжность системы с огромной кучей лёгких потоков, работающих с вводом/выводом (т.е. в условиях неопределённости их времени исполнения) гораздо выше, чем у нескольких тормозных агентов...
И это - на одноядерном компьютере...

Правы эрлангеры. Только "несколько тормозных агентов" - это не активные объекты... RSDN-щики-императившики не знают и не могут знать, что такое активные объекты - ибо акромя абстракций Явы, Шарпа и ВинАпи ничего особенно не нюхали... Их инструментарий не позволяет писать приложения с асинхронностью в сотни и тысячи агентов... Обероны позволяют. И мгновенный старт 16 тыс. активностей на Бутылке ничем не хуже, чем на Эрланге. Активный Блэкбокс я тоже затачиваю под гиперасинхронность, хотя выше тысячи активностей не прыгнуть - потолок нижележащей ОС... Однако есть изюминка - автоматическая остановка активных объектов, это должно дать такой же эффект, какой в свое время дала сборка мусора - приводит к радикальным изменениям в проектировании, т.к. можно забыть о централизованном управлении объектами, их не нужно держать больше на коротком поводке, отпустил в систему - и забыл.

Кстати, уважаемые наши коллеги ФП-шники, помните ваши примеры про веб-сервер на Эрланге, который "делает" апач во много раз? Вы не обратили внимание и умолчали такую вещь, что этот веб-сервер крутился на спец. ОС, которая и обеспечивает легкое диспетчерирование тысяч потоков... А "тормознутость" Апача зависит не от Апача, а от низлежащих операционных систем вроде Винды/Юникса, которые строились сами знаете на идеях какой давности, и больше той самой пресловутой тысячи потоков в принципе держать не могут. Их разработчикам и в голову прийти не может, что можно писать ПО с такой асинхронностью - еще бы, на Цях и API уровня CreateThread и Semaphore больше пяти-десяти агентов в системе построить невозможно...

Ответ на »сообщение 4841« (Jack Of Shadows)
___________________________

Ответ на »сообщение 4840« (Сергей Осколков)
___________________________
Механизм фильтрации и выборки данных из списков, массивов итд.
Нет, не только из списков массивов и т.д., но и из баз данных (DLINQ).


Вы что, никогда не пыьались выбрать из списка данные отвечающие определенному критерию ? Вы хотите сказать что эта задача является узко-специальной, так же как и доступ к базам данных ?
Как это соотносится с моими словами, не понял. Я разве написал, что это узкая задача? Я написал, что в C# вводят язык запросов. Да, это строго говоря, не SQL, но в части взаимодействия с базами данных он играет ту же роль, что и SQL и запросы преобразуются в SQL запросы к БД.

Ответ на »сообщение 4842« (Илья Ермаков)
___________________________

Недавно на RSDN'е огрмный флейм по этому поводу возник - насколько хороши десятки и сотни тысяч лёгких процессов Ерланга в сравнении с несколькими агентами (активными объектами), реализованными в тяжёлой многозадачности.
Основной довод ерлангеров - реактивность и надёжность системы с огромной кучей лёгких потоков, работающих с вводом/выводом (т.е. в условиях неопределённости их времени исполнения) гораздо выше, чем у нескольких тормозных агентов...
И это - на одноядерном компьютере...

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


А вот параллельные Обероны к этому готовы :-) Плюс в последних языках типа Зоннона и Композиты обкатывается столь мощный декларатив на протоколы, что...

Ну, посмотрим, посмотрим...

Ответ на »сообщение 4836« (Geniepro)
___________________________

Ответ на »сообщение 4827« (Илья Ермаков)
___________________________
В последнее время, со всё большим распространением многоядерных архитектур, всё болше начинает распространяться и мнение, что Си - уже устарел и не позволяет достаточно легко и просто использовать все возможности множества ядер...
Так что хочешь-не хочешь, а придётся постепенно перебираться на более высокоуровневые языки...
Не то, что бы Хаскелл в этом плане был лучше всех, но всё же... Время Си, Паскаля, Оберона постепенно проходит... Наступает время Ерланга, Data Parallel Haskell, Зонона, в конце концов...

Прекратите Вы, в конце концов, ссылаться на мультипроцессоры как на "могильщика" для Паскалей. Для Си - да, но не для нас - увольте :-) В вашей ветке я уже подробно ответил Джеку на его сентенции о том, что "циклы ручками параллелить утомитесь". Никто и не будет параллелить какждый цикл - какой смысл в "мелкорубленном фарше"? В любой системе всегда найдется множество объектов-агентов, которые можно запустить выполняться асинхронно - и незачем асинхронить отдельно взятые циклы... Паралельные Обероны готовы принять вызов и обеспечить гиперасинхронность - тысячи активных автономно живущих объектов, жизненный цикл которых контролируется автоматически, сборщиком мусора... Ядер не напасетесь, чтобы их реально запараллелить, но даже и без этого программирование существенно облегчается... К тому же сейчас в моду идет GRID и метакомпьютинг - там тоже отдельные циклы особо не "нарубаешь", все-таки не в едином адресном пространстве сидим... Те задачки, которые решались на MPI, например, - с малодинамическими данными, легко рубящиеся на отдельные диапазоны-подзадачи, ФП, конечно, отлично будет параллелить. Более сложные системы, с перманентным жизненным циклом - еще вопрос. А вот параллельные Обероны к этому готовы :-) Плюс в последних языках типа Зоннона и Композиты обкатывается столь мощный декларатив на протоколы, что...

Ответ на »сообщение 4840« (Сергей Осколков)
___________________________
Ну это не sql. Linq это list comprehensions.
Механизм фильтрации и выборки данных из списков, массивов итд.
Вы что, никогда не пыьались выбрать из списка данные отвечающие определенному критерию ? Вы хотите сказать что эта задача является узко-специальной, так же как и доступ к базам данных ?

Ответ на »сообщение 4839« (Сергей Перовский)
___________________________

Ответ на »сообщение 4832« (FR)
___________________________
Я уже упоминал тут SQL. Ни у кого не возникает поползновений включить синтаксис SQL прямо в Паскаль или C++. Зачем же включать синтаксис функционального подхода в императивный язык.

В паскаль и C++ может быть и не возникало, а в C# SQL вставить пытаются. :) Проект называется LINQ (Language Integrated Query)
Вот например
http://en.wikipedia.org/wiki/Language_Integrated_Query

Ответ на »сообщение 4832« (FR)
___________________________
Полно гибридных языков подерживающих как функциональщину так и императив например Ocaml
Я уже упоминал тут SQL. Ни у кого не возникает поползновений включить синтаксис SQL прямо в Паскаль или C++. Зачем же включать синтаксис функционального подхода в императивный язык. Выполнение функциональных фрагментов так же легко локализуется по месту и времени выполнения в императивном окружении, как и выполнение SQL запроса.
Если идти от императивного языка, то вставки могут быть реализованы на любом функциональном языке с минимальными соглашениями о совместимости.
А вот в функциональные языки приходится вводить императивность для общения с "окружающей средой", нарушая целостность и перетяжеляя язык.

Ответ на »сообщение 4829« (FR)
___________________________
Под сложностью имелось в виду в первую очередь реализация, то есть компилятор современного языка вряд ли может быть простым (как я понимаю по Вирту наооборот).
Во вторых сложность на самом деле позволяет более просто выражатся, многие абстракции в той же функциональщине сложнее и для понимания и по реализации и по теоритеческой базе большинства императивных конструкций, но они же позволяют делать код более кратким и понятным.
Чего-то я недопонял. Если удается просто выражаться, то с чего-бы компилятору быть сложным? Как будто простое для человека должно быть сложным для компилятора.
Может быть Вы имеете в виду сложность освоения? Тогда все зависит от базового образования и наработанных шаблонов. Извините за банальный пример "функциональщины", но в Excel'е можно научить программировать каждого ду..., ну просто каждого. И никакой проблемы с пониманием высоких абстракций не возникает.

Ответ на »сообщение 4836« (Geniepro)
___________________________

Не то, что бы Хаскелл в этом плане был лучше всех, но всё же... Время Си, Паскаля, Оберона постепенно проходит... Наступает время Ерланга, Data Parallel Haskell, Зонона, в конце концов...

Да не заморачивайтесь Вы на этот счет. Тот же Торвальдс в этой сфере ни ухом ни рылом. А потом, когда приспичило, стал задумываться, что моноядро должно как-то в такой обстановке работать... Параллельным программированием (concurrent, parallel и asynchronous) у нас занимались с 1960-х годов. Подходы разные. Микроуровень, макроуровень. Это епархия тех, кто занимался активно задачами real-time и научными расчетами. Сильный источник сконцентрирован тут: http://www.parallel.ru/

Собственно следующие версии Windows (или варианты) -- это заточка под многоядерные процессоры. Автоматическое распараллеливание -- весьма ограниченный подход. Нужна хинтовка со стороны программиста. Т.е. нужны средства для того, чтобы мозги человека были под это заточены. А вот тут вступают в игру более серьезные подходы. В том числе и архитектурные. Еще раз упомяну то, чем занимался 20 лет назад, когда изучал методологию Mascot-3 Минобороны Великобритании, кардинально переделывая ее на свой лад. Вся система разбивается на активные и пассивные элементы. Их могут быть тыщи и тыщи (мульоны и мульоны). Строятся схемы асинхронно-синхронного взаимодействия. А вот этот бульон уже полностью готов к распараллеливанию (автоматическому) с хорошим формальным анализом.

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

А что до Оберона, то нынешний компьютер фон Неймана в компактной форме реализован прилично только в Си и Обероне. Но Оберон выглядит предпочтительнее.