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

KP>В Хроме, кроме того, каждый процесс запускает потоки для различных фоновых операций. Куда ж без этого?

С фоновыми потоками никаких проблем http://caml.inria.fr/pub/docs/manual-ocaml/libref/Thread.html

KP>Сейчас идет тенденция к увеличению количества процессоров. Зачем же целенаправленно вводить какие-то ограничения и усложнять самому себе жизнь?

Язык стал заложником реализации. Когда он появился на горизонте массовых многопроцессорных систем видно не было.

DM>>Для однопоточных программ тоже немало применений есть. Например, я делал на окамле интерактивный анализатор логов с веб-интерфейсом. Не представляю, где бы мне там пригодились параллельные потоки (с диска читать лучше последовательно, а пользователь один, и много запросов сразу не посылает). Еще делал компилятор, он и без потоков очень быстрый получился.

KP>Там бы они пригодились для раздельного чтения и анализа. Пользователей может быть больше чем 1.

С этим никаких проблем, системные потоки как уже выше писал использовать можно.
Кроме того есть очень неплохие реализации легковесных потоков например — http://ocsigen.org/lwt/manual/

Здравствуйте, Аноним, Вы писали:


А>пока я вижу только один выход — если ест что-то ресурсоемкое (или просто длинное) фоновое, то можно запускать в отдельно окамловском потоке, который будет дергать С-callback, в котором будет сначала освобождаться gil, а только потом выполняться та самая ресурсоемкая задача.

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

А>честно говоря, не ожидал — тут столько лет разговоры были о окамле, как о полноценной замене С++, а когда руки дошли повозиться — получите, распишитесь

Реально OCaml никогда ни мог быть полноценной заменой C++, компиляторы C++ всегда лучше оптимизировали, и у C++
есть низкоуровневые возможности.
Но во времена когда массовыми компилятороми были VC 6 и gcc 2.x да и борландовские и ваткомовские компиляторы не
были антиквариатом позиция у OCaml была на порядок лучше.

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

FR>С потоками никаких проблем при этом нет, есть только проблемы с реальным одновременным выполнением на нескольких ядрах/процессорах.

Я вижу противоречие в этом предложении

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

FR>>С потоками никаких проблем при этом нет, есть только проблемы с реальным одновременным выполнением на нескольких ядрах/процессорах.

AP>Я вижу противоречие в этом предложении

Как я понял у выше писавших создалось впечатление что потоки использовать в OCaml совершенно невозможно.
Это не так, потоки использовать можно и для однопроцессорных машин (и для фоновых мало загруженных потоков на
многопроцессорных) никаких различий с другими языками не будет.

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

FR>Здравствуйте, Alexander Poluektov, Вы писали:

FR>>>С потоками никаких проблем при этом нет, есть только проблемы с реальным одновременным выполнением на нескольких ядрах/процессорах.

AP>>Я вижу противоречие в этом предложении

FR>Как я понял у выше писавших создалось впечатление что потоки использовать в OCaml совершенно невозможно.
FR>Это не так, потоки использовать можно и для однопроцессорных машин (и для фоновых мало загруженных потоков на
FR>многопроцессорных) никаких различий с другими языками не будет.

Да понял, понял. Это был "мягкий ненавязчивый юмор"

FR>Язык стал заложником реализации. Когда он появился на горизонте массовых многопроцессорных систем видно не было.

Так легко в логику разработчиков окамловского рантайма не проникнуть. Дело в том, что 32-битная версия малоюзабельна из-за отсутствия нормальный массивов и даже чисел. А ведь массовая 64-битность тогда не просматривалась в точно такой же степени. Получается, что при создании рантайма было принято сразу два решения, одно из которых делало окамл малополезным в настоящем, а другое — должно было его сделать малополезным в будущем. Чем это можно объяснить — не понятно, разве только шуткой про инженера, который не только не должен делать ничего полезного, но даже еще немного вредить.

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

K>Так легко в логику разработчиков окамловского рантайма не проникнуть. Дело в том, что 32-битная версия малоюзабельна из-за отсутствия нормальный массивов и даже чисел. А ведь массовая 64-битность тогда не просматривалась в точно такой же степени. Получается, что при создании рантайма было принято сразу два решения, одно из которых делало окамл малополезным в настоящем, а другое — должно было его сделать малополезным в будущем. Чем это можно объяснить — не понятно, разве только шуткой про инженера, который не только не должен делать ничего полезного, но даже еще немного вредить.

Логика вполне просматривается, создавали максимально эффективную реализацию для текущего массового железа.
Массивы вполне покрывали размеры тогдашней памяти.
Потом уже реализацию стало трудно изменить, хотя разработчики конечно не особо старались, вот сейчас этим
озаботились в OCamlPro (http://www.ocamlpro.com/code/2011-05-06-longval.html) и оказалось что это и не
так уж и сложно.

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

FR>Логика вполне просматривается, создавали максимально эффективную реализацию для текущего массового железа.

Но не создали. Скорее уж они создавали максимльно простую реализацию (уровня "добротная дипломная работа") с более-менее разумными возможностями и производительностью.

FR>Массивы вполне покрывали размеры тогдашней памяти.

Ну, как раз где-то во время появления и перестали покрывать. Кто же мог подумать, что окамл будут использовать на следующий год после появления? Или — страшно сказать! — через два года? А числа, с числами как? В этой колбасе тоже потребности не было?

FR>хотя разработчики конечно не особо старались

Вот то-то и оно.

FR>озаботились в OCamlPro (http://www.ocamlpro.com/code/2011-05-06-longval.html) и оказалось что это и не
FR>так уж и сложно.

Потрясающе. Только линукс, только байткод-интерпретатор и в 2011-ом году! Самая, понимаете ли, bleeding edge, прямо как китайская космонавтика. Ну, или скорее как северокорейская космонавтика.

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

FR>>Логика вполне просматривается, создавали максимально эффективную реализацию для текущего массового железа.

K>Но не создали. Скорее уж они создавали максимльно простую реализацию (уровня "добротная дипломная работа") с более-менее разумными возможностями и производительностью.

Да цели две все-таки простота и эффективность. На фоне тогдашних высокоуровневых языков вполне достигли.

FR>>Массивы вполне покрывали размеры тогдашней памяти.

K>Ну, как раз где-то во время появления и перестали покрывать. Кто же мог подумать, что окамл будут использовать на следующий год после появления? Или — страшно сказать! — через два года? А числа, с числами как? В этой колбасе тоже потребности не было?

Ну все-таки ноги растут у OCaml'а из восьмидесятых. И рантайм был создан не с нуля, а как развитие рантайма от Caml Light.
А с числами не такая и проблема, я например и с 16 битным int еще программировал.

FR>>озаботились в OCamlPro (http://www.ocamlpro.com/code/2011-05-06-longval.html) и оказалось что это и не
FR>>так уж и сложно.

K>Потрясающе. Только линукс, только байткод-интерпретатор и в 2011-ом году! Самая, понимаете ли, bleeding edge, прямо как китайская космонавтика. Ну, или скорее как северокорейская космонавтика.

Ну не нравится жалуйся в спортлото

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

FR>Ну все-таки ноги растут у OCaml'а из восьмидесятых. И рантайм был создан не с нуля, а как развитие рантайма от Caml Light.

Ну, в 80-х у камла была совсем другая реализация, SK-машина (если память не изменяет — это вообще один из самых тормозных способов реализации ФЯ) да еще и на лиспе написанная. Так что из 80-х у окамла только диковинный, по меркам остальных ML, синтаксис. А Caml Light Лерой написал уже ближе к середине 90-х. Не такая у него с Окамлом и разница в возрасте.

FR>А с числами не такая и проблема, я например и с 16 битным int еще программировал.

Я тоже. В школе и университете.

FR>Ну не нравится жалуйся в спортлото

Так я, собственно, для этого сюда и пишу. Тут же форум техподдержки спортлото, вы не знали разве?

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

FR>>Ну все-таки ноги растут у OCaml'а из восьмидесятых. И рантайм был создан не с нуля, а как развитие рантайма от Caml Light.

K>Ну, в 80-х у камла была совсем другая реализация, SK-машина (если память не изменяет — это вообще один из самых тормозных способов реализации ФЯ) да еще и на лиспе написанная. Так что из 80-х у окамла только диковинный, по меркам остальных ML, синтаксис. А Caml Light Лерой написал уже ближе к середине 90-х. Не такая у него с Окамлом и разница в возрасте.

Нет 90-91 http://caml.inria.fr/about/history.html#id2268637 для тех времен очень шустрый и экономичный.
В 95 он уже написал Caml Special Light это практически OCaml только без 'O' части.

FR>>Ну не нравится жалуйся в спортлото

K>Так я, собственно, для этого сюда и пишу. Тут же форум техподдержки спортлото, вы не знали разве?

Здравствуйте, Аноним, Вы писали:

А>Много раз читал в ДП рекомендации попробовать OCaml, как единственную альтернативу С++ в качестве языка общего назначения.

А>http://caml.inria.fr/pub/distrib/ocaml-3.12/ocaml-3.12-refman.txt

А> The Caml run-time system is not reentrant: at any time, at most one thread
А>can be executing Caml code or C code that uses the Caml run-time system.
А>Technically, this is enforced by a "master lock" that any thread must hold
А>while executing such code.

А>это ставит крест на очень многих возможных применениях

А>
Ну так скажите, стоит ли его изучать или нет как язык для практического применения? А то я тут начал уже, вроде неплохо.

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

FR>Нет 90-91 http://caml.inria.fr/about/history.html#id2268637 для тех времен очень шустрый и экономичный.
FR>В 95 он уже написал Caml Special Light это практически OCaml только без 'O' части.

Все равно компилятор в нативный код ведь только для Special появился. Ну и какой разговор о шустрости может идти в случае интепретатора байткода?
Рантайм, кстати, явно не расчитан на широко распространенный компьютер 91-го года, а вот уже в 95 совершенно ясно, что из таких коротких штанишек язык вот-вот вырастет.

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

K>Ну так скажите, стоит ли его изучать

Да.

K>как язык для практического применения?

Нет.

Вопрос, кстати — провокация флейма в чистом виде.

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


А>>
K>Ну так скажите, стоит ли его изучать или нет как язык для практического применения? А то я тут начал уже, вроде неплохо.

Изучать стоит, хороший гибридный язык, очень интересная ОО подсистема.
С практическим применением сложнее, главная проблема очень мало библиотек.

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

K>Все равно компилятор в нативный код ведь только для Special появился. Ну и какой разговор о шустрости может идти в случае интепретатора байткода?

Это вообще один из самых шустрых интерпретаторов, быстрее того же питона в среднем в несколько раз.
Ну и тогда вообще по моему было мало функциональных языков нормально работающих на микрокомпьютерах.

K>Рантайм, кстати, явно не расчитан на широко распространенный компьютер 91-го года, а вот уже в 95 совершенно ясно, что из таких коротких штанишек язык вот-вот вырастет.

Да ну для тех объемов памяти более чем адекватно.

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

K>Ну так скажите, стоит ли его изучать или нет как язык для практического применения? А то я тут начал уже, вроде неплохо.

Я когда-то начал. За бесполезностью бросил. На данный момент думаю что если хочется чего-то практичного и более-менее универсального (само собой, если говорить о функциональных языках), то стоит посмотреть на Haskell. Ну а если ты занимаешься сетевым ПО то на Erlang.

Здравствуйте, Аноним, Вы писали:

А>Я когда-то начал. За бесполезностью бросил. На данный момент думаю что если хочется чего-то практичного и более-менее универсального (само собой, если говорить о функциональных языках), то стоит посмотреть на Haskell. Ну а если ты занимаешься сетевым ПО то на Erlang.

Хаскель бы я практичным не назвал, не смотря на гораздо более широкое комьюнити и популярность, чуть лучше окамла.
По моему более-менее практичны F# и Scala.

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

FR>Хаскель бы я практичным не назвал, не смотря на гораздо более широкое комьюнити и популярность, чуть лучше окамла.
FR>По моему более-менее практичны F# и Scala.

почему? меня в нём по-большому счёту не устраивает отсутсвие 64-битного компилера, и слабость gui бибилиотек. но те же претензии можно предъявить к любому языку не из первой десятки. на мой взгляд, он не менее практичен чем руби или та же скала

если ты под практичностью понимаешь поддержку jvm/clr, то да — тут даже С++ рожей не вышел

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

BZ>почему? меня в нём по-большому счёту не устраивает отсутсвие 64-битного компилера, и слабость gui бибилиотек. но те же претензии можно предъявить к любому языку не из первой десятки. на мой взгляд, он не менее практичен чем руби или та же скала

BZ>если ты под практичностью понимаешь поддержку jvm/clr, то да — тут даже С++ рожей не вышел

Под практичностью я в первую очередь понимаю широкий выбор достаточно качественных библиотек, с этим не только
у jvm/clr все в порядке, но и у C++ вполне нормально и у питона.
Хаскелю не только до них но и до скажем Delphi/С++ Builder далековато.