Здравствуйте, nikov, Вы писали:
L>>>В случае F# — все просто, есть примеры использования, положительные отзывы, известный вендор, литература.
VD>>Что за примеры?
N>Здесь, раздел Industrial applications
На примеры использования тянет очень плохо. Книги, три библиотеки (вообще не ясно зачем было их под F# затачивать?). "Investment banks such as Morgan Stanley, Credit Suisse and UBS already employ hundreds of F# programmers who build in-house software." — просто прогон какой-то.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>>>Что за примеры?
N>>Здесь, раздел Industrial applications
VD>На примеры использования тянет очень плохо. Книги, три библиотеки (вообще не ясно зачем было их под F# затачивать?). "Investment banks such as Morgan Stanley, Credit Suisse and UBS already employ hundreds of F# programmers who build in-house software." — просто прогон какой-то.
Вот буквально сейчас мне прислали предложение работы в каком-то инвестиционном банке в Лондоне на позиции Senior F# Developer.
Здравствуйте, nikov, Вы писали:
N>Вот буквально сейчас мне прислали предложение работы в каком-то инвестиционном банке в Лондоне на позиции Senior F# Developer.
И какая связь с имеющимися продуктами?
Продуктах на F# и на Nemerle написано примерно одинаковое количество. Чуть больше нуля. Но кончено после такого промоушена от МС найти работу на F# будет намного проще. И это при том, что писать программы проще как раз на Nemerle.
В общем, это еще раз подверждает что бабвло всегда побиждает бабро.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Продуктах на F# и на Nemerle написано примерно одинаковое количество. Чуть больше нуля. Но кончено после такого промоушена от МС найти работу на F# будет намного проще. И это при том, что писать программы проще как раз на Nemerle.
VD>В общем, это еще раз подверждает что бабвло всегда побиждает бабро.
Эххх. Не угадал Немерл с целевой аудиторией. .NET-чики не любят синтаксис изобретать. Им подавай сертифицированный МСом стандарт. Надо было с С++ дружить. Там и потребность есть, и опыт кастомизации синтаксиса через шаблоны и перегрузку опреаторов, и сообщество более к опенсорсу привычное, не так боятся что "не стоит серьезной организации".
Вот не так давно обсуждали: A как насчет LINQ?
Здравствуйте, Mazay, Вы писали:
M>Эххх. Не угадал Немерл с целевой аудиторией. .NET-чики не любят синтаксис изобретать. Им подавай сертифицированный МСом стандарт. Надо было с С++ дружить. Там и потребность есть, и опыт кастомизации синтаксиса через шаблоны и перегрузку опреаторов, и сообщество более к опенсорсу привычное, не так боятся что "не стоит серьезной организации".
Согласен, только с одной оговоркой. Не к С++, а к Ява-сообществу... скорее.
M>Вот не так давно обсуждали: A как насчет LINQ?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mazay, Вы писали:
M>>Эххх. Не угадал Немерл с целевой аудиторией. .NET-чики не любят синтаксис изобретать. Им подавай сертифицированный МСом стандарт. Надо было с С++ дружить. Там и потребность есть, и опыт кастомизации синтаксиса через шаблоны и перегрузку опреаторов, и сообщество более к опенсорсу привычное, не так боятся что "не стоит серьезной организации".
VD>Согласен, только с одной оговоркой. Не к С++, а к Ява-сообществу... скорее.
Ява — это только привычка к опенсорсу. Традиции кастомизации синтаксиса там нет, опять же захотят "серьёзную организацию" и потребность там не столь острая как в плюсах. И вообще, как мне кажется, Ява сообщество более инертное — индусам же нельзя такие мощные инструменты давать.
С++ имеет кучу проблем, но поскольку это лучшее что сегодня есть для программирования нативного кода, все колятся, но продложают жрать. ИМХО если откатиться к C как к базовому языку и сделать все высокоуровневые фичи как макросы Немерла, то это будет вполне человеческим решением. Или, как я уже говорил, сделать компилятор в LLVM.
M>>Вот не так давно обсуждали: A как насчет LINQ?
. Ты же вроде говоил, что весь LINQ можно реализовать на макросах Немерла?
VD>Дык он давно реализован. Причем в виде тех самых макросов: VD>http://nemerle.googlecode.com/svn/nemerle/trunk/Linq
Ну вот в дотнете он уже не нужен (в смысле уже есть), а в плюсах бы пригодился.
Главное гармония ...
Re[12]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Ява — это только привычка к опенсорсу.
Не. Ява — это неплохой рантайм и никуда не годный (убогий) язык. Причем язык с весьма близкой системой типов и рантаймом. Этот набор качеств создает и среду и аудиторию.
С++ же он совсем другой. Да и реализоовать язык типа немерла без виртуальной машины во много раз сложнее. Ведь нужен GC, работа с метаданными сборок, рефлексия, библиотеки и т.п. В общем, объем работы увеличивается в разы. А сил и так мало.
M>Традиции кастомизации синтаксиса там нет, опять же захотят "серьёзную организацию" и потребность там не столь острая как в плюсах.
Ну, синтаксис то в С++ изменить тоже нельзя. Скорее можно вести речь о семантике.
Тут да, С++ с метапрограммироанием на шаблонах кое что позволяет сделать.
Дык ява-программистам это тоже нужно! У них этого нет совершенно. Что делате значимость фичи еще большей.
M> И вообще, как мне кажется, Ява сообщество более инертное — индусам же нельзя такие мощные инструменты давать.
Как скзать. Большинство новых дотнета технологий пришло из явы. Гибернэйт, Спринг и т.п. Опен-сорс в ява-комьюнити развит очень сильно. И от части многие открытые проекты (как и в случае С++) решают проблемы которые создает язык.
M>С++ имеет кучу проблем, но поскольку это лучшее что сегодня есть для программирования нативного кода, все колятся, но продложают жрать.
На счет "лучшего" я бы сильно поспорил. Я считаю ОКамл и Ди более мощьными языками. Просто инертность мышления и привязанность к разрекламмированным технологиям, плюс поддержка больших фирм делают свое дело. Но эта же проблема есть и в дотнете.
M>ИМХО если откатиться к C как к базовому языку и сделать все высокоуровневые фичи как макросы Немерла, то это будет вполне человеческим решением. Или, как я уже говорил, сделать компилятор в LLVM.
С — никудышная основа для языка вроде немерл. Немерл типобезопасный высокоуровневый язык с семантикой которая позволяет писать код близкий к С по скорости. Ему С будет как костыль. Собственно проблемы С++ вызваны в основном наследием С и отказом от некоторых фич Симулы (например, сборщика мусора). Это конено обепечило ему приемственность, низкоуровневость и скорость кода, но при этом стало диким тормозом в развитии.
Гы. Он и реализован на базе дотнета. Если бы в дотнете не было его реализации. Или если хотя бы не было реализации провайдеров, то объем работы увеличился бы многократно.
Надо же понимать, что фрэймворк это не только джит-компилятор и сборщик мусора. Это еще куча кода и утилит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
M>>Ява — это только привычка к опенсорсу.
VD>Не. Ява — это неплохой рантайм и никуда не годный (убогий) язык. Причем язык с весьма близкой системой типов и рантаймом. Этот набор качеств создает и среду и аудиторию.
VD>С++ же он совсем другой. Да и реализоовать язык типа немерла без виртуальной машины во много раз сложнее. Ведь нужен GC, работа с метаданными сборок, рефлексия, библиотеки и т.п. В общем, объем работы увеличивается в разы. А сил и так мало.
Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё.
M>>Традиции кастомизации синтаксиса там нет, опять же захотят "серьёзную организацию" и потребность там не столь острая как в плюсах.
VD>Ну, синтаксис то в С++ изменить тоже нельзя. Скорее можно вести речь о семантике. VD>Тут да, С++ с метапрограммироанием на шаблонах кое что позволяет сделать. VD>Дык ява-программистам это тоже нужно! У них этого нет совершенно. Что делате значимость фичи еще большей.
M>> И вообще, как мне кажется, Ява сообщество более инертное — индусам же нельзя такие мощные инструменты давать.
VD>Как скзать. Большинство новых дотнета технологий пришло из явы. Гибернэйт, Спринг и т.п. Опен-сорс в ява-комьюнити развит очень сильно. И от части многие открытые проекты (как и в случае С++) решают проблемы которые создает язык.
Ну да. Гибернейт и Спринг — это когда сто тыщь мильёнов велосипедов написали, тогда софтверные компании наконец разродились чем-то более-менее стандартным.
M>>С++ имеет кучу проблем, но поскольку это лучшее что сегодня есть для программирования нативного кода, все колятся, но продложают жрать.
VD>На счет "лучшего" я бы сильно поспорил. Я считаю ОКамл и Ди более мощьными языками. Просто инертность мышления и привязанность к разрекламмированным технологиям, плюс поддержка больших фирм делают свое дело. Но эта же проблема есть и в дотнете.
Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода).
M>>ИМХО если откатиться к C как к базовому языку и сделать все высокоуровневые фичи как макросы Немерла, то это будет вполне человеческим решением. Или, как я уже говорил, сделать компилятор в LLVM.
VD>С — никудышная основа для языка вроде немерл. Немерл типобезопасный высокоуровневый язык с семантикой которая позволяет писать код близкий к С по скорости. Ему С будет как костыль. Собственно проблемы С++ вызваны в основном наследием С и отказом от некоторых фич Симулы (например, сборщика мусора). Это конено обепечило ему приемственность, низкоуровневость и скорость кода, но при этом стало диким тормозом в развитии.
Это всё понятно. Просто есть некоторый спектр задач, где сборщик мусора как-то не очень важен (мне например умных указателей за глаза хватает, им бы ещё синтаксис человеческий), зато важен прямой доступ к памяти, скорость кода, портабельность. В Си с типобезопасностью и контролем памяти как-нибудь разобраться можно, требуется лишь средство расширения синтаксиса.
Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет. Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз.
Главное гармония ...
Re[13]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>С++ же он совсем другой. Да и реализоовать язык типа немерла без виртуальной машины во много раз сложнее. Ведь нужен GC, работа с метаданными сборок, рефлексия, библиотеки и т.п. В общем, объем работы увеличивается в разы. А сил и так мало.
Я, конечно плохо представляю кишки Немерла, но разве нельзя сначала реализовать чисто систему макросов без привязки к GC, метаданным, рефлексии и тем более библиотекам?
Главное гармония ...
Re[14]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё.
А зачем тебе нативность?
Нативность и производительность понятия не связанные.
M>Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода).
А зачем тебе прямой доступ к памяти вообще и shared memory multithreading в частности?
M>Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет. Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз.
Аааааа!!!!!!!!! Шареная память в распределенной системе
Прощай защита от сбоев. А если учесть что в больших кластерах компы мрут довольно часто то как в таком состоянии вообще что-то посчитать можно?
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: [Голосование] Почему я не использую Nemerle
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Mazay, Вы писали:
M>>Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё. WH>А зачем тебе нативность? WH>Нативность и производительность понятия не связанные.
Это в теории. А на практике — посмотри в шутаут. Кроме того, виртуальные машины есть не везде.
M>>Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода). WH>А зачем тебе прямой доступ к памяти вообще и shared memory multithreading в частности?
Для производительности. Пока компиляторы много чего не умеют делать. Вон remark в форумах по С++ много интересного на эту тему пишет. И Интел делает ставку именно на многоядерность и разделяемую память (глянь на tbb library — она вся на общей памяти основана). И для видеокарт не очень ясно как должна выглядеть managed память, ибо память там важна ещё больше чем в CPU. Короче это не мой каприз, а объективная потребность.
M>>Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет. Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз. WH>Аааааа!!!!!!!!! Шареная память в распределенной системе WH>Прощай защита от сбоев. А если учесть что в больших кластерах компы мрут довольно часто то как в таком состоянии вообще что-то посчитать можно?
Ничего не мрут (если это не Beowulf из списаных персоналок). Нормально считается. Кластер это всё-таки не облако.
Главное гармония ...
Re[14]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё.
А что за расчеты?
M>Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода).
Ты ничего не путаешь. Как минимум Ди весьма шустрый код порождает. Про многопоточность у ОКамла не скажу, но тоже звучит странно. Язык весьма императивный. С нэйтив-интерфейсом сишным. Не думаю, что там очень уж сложно сделать то что нужно. Хотя сама идея разделять память в многозадачности весьма спорная. Грабель можно лбом собрать тысячи...
M>Это всё понятно. Просто есть некоторый спектр задач, где сборщик мусора как-то не очень важен (мне например умных указателей за глаза хватает, им бы ещё синтаксис человеческий),
Это так только кажется. Даже сама необходимость возиться с умными указателями уже отнимает часть потенциала твоего мозга.
M>зато важен прямой доступ к памяти, скорость кода, портабельность.
Тогда Ди мог бы тебе подойти. Там как раз совещены многие вкусности из типобезопасных языков и прямой доступ в стиле С, если это нужно.
Может и окалм подойдет.
Поять же всегда можно действительно требовательные куски и на С реализовать, а объемную логику на более высокоуровневом язке.
M> В Си с типобезопасностью и контролем памяти как-нибудь разобраться можно, требуется лишь средство расширения синтаксиса.
Тут одно за другое цепляется. Чтобы получить такие средства расширения синтаксиса как в немреле желательно иметь в языке на котором это все пишется фичи которые без того же ЖЦ реализовать будет не так то просто.
Собственно как вариант можно предложить кроскомпиляцию. Когда вместо того чтобы писать на одном языке все, писать макросы на Немерле или Лиспе, а уже по ним генерировать код на С. Но это потребует создания некоторой инфраструктуры.
M>Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет.
Ну, почему нет? Есть. Просто они видимо выходят за твое кругозор. В том же четвертом фрэймворке добавили качественных костылей в виде задач (Task) и PLink-а.
В F#, Хаскеле и Nemerle (в последнем реализовано на макросах) есть Async который позволяет оперировать кодом как объектом. Например, останавливать вычисления в одном потоке и возобновлять в другом.
Кроме того есть иделогия акторов. Не для всех случаев жизни подходит (так как общение происходит только через посылку сообщений), но в некоторых вариантах использования очень рулит.
M> Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз.
А что за синтаксическая поддержка там нужна?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Я, конечно плохо представляю кишки Немерла, но разве нельзя сначала реализовать чисто систему макросов без привязки к GC, метаданным, рефлексии и тем более библиотекам?
Она на нем самом и написана.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: [Голосование] Почему я не использую Nemerle
VD>Ты ничего не путаешь. Как минимум Ди весьма шустрый код порождает. Про многопоточность у ОКамла не скажу, но тоже звучит странно. Язык весьма императивный. С нэйтив-интерфейсом сишным. Не думаю, что там очень уж сложно сделать то что нужно. Хотя сама идея разделять память в многозадачности весьма спорная. Грабель можно лбом собрать тысячи...
У D такая проблема у базового компилятора backend построен на базе digital mars C++ который по оптимизации чуть лучше bcc,
то есть слабоват (обогнать на том же окамле часто без проблем). Был компилятор gdc http://dgcc.sourceforge.net/ на базе
gcc, и первого D, но он заглох, вот он да очень часто обгонял g++ на одинаковых задачах, за счет того что у D front end лучше
и более агрессивно выносит все что можно в conpile time. Но перед смертью gdc все завещал внуку, то есть LLVM D Compiler http://www.dsource.org/projects/ldc пока он совсем сырой, но по шустрости не уступает gdc. В общем все непросто
У OCaml'а с многопоточностью такая же любовь как у питона и руби, то есть аналог GIL. Правда в отличии от интерпретаторов
это вполне можно развязать, но пока авторы не торопятся. Но в тех же кластерах использовать это не мешает, библиотеки
для межпроцессного взаимодействия есть.
Re[15]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
M>>Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё.
VD>А что за расчеты?
Молекулярное моделирование.
M>>Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода).
VD>Ты ничего не путаешь. Как минимум Ди весьма шустрый код порождает. Про многопоточность у ОКамла не скажу, но тоже звучит странно. Язык весьма императивный. С нэйтив-интерфейсом сишным. Не думаю, что там очень уж сложно сделать то что нужно. Хотя сама идея разделять память в многозадачности весьма спорная. Грабель можно лбом собрать тысячи...
FR уже описал ситуацию с D и c OCaml. Только про OCaml следует подчеркнуть, что узлы в кластерах тоже имеют несколько ядер с общей памятью, а OCaml не даёт возможности воспользоваться этой общностью в корыстных целях. Про грабли разговор отдельный.
M>>Это всё понятно. Просто есть некоторый спектр задач, где сборщик мусора как-то не очень важен (мне например умных указателей за глаза хватает, им бы ещё синтаксис человеческий),
VD>Это так только кажется. Даже сама необходимость возиться с умными указателями уже отнимает часть потенциала твоего мозга.
Ээээ. Что значит возиться? Больше текста писать при объявлении и инициализации? Сравни:
int *pi;
pi = new int(123);
int *pi(new int(321));
...
delete pi;
delete pj;
Действительно, синтаксис громоздок. Потому я и хочу макросы Немерла, что бы можно было написать например вот так:
int ^pi;
pi = snew int(123);
int ^pi(snew int(321));
...
С нормальным ситаксисом всё будет легко и просто.
VD>Поять же всегда можно действительно требовательные куски и на С реализовать, а объемную логику на более высокоуровневом язке.
Проблема в том, что даже в не слишком большой программе не всегда очевидно какой кусок окажется самым дорогим. В ходе модификации программы, изменения требований и даже значений входных параметров картинка в профайлере может сильно меняться. Со временем скатываешься к тому, что больше усилий тратишь на борьбу с глюками интеропа.
M>> В Си с типобезопасностью и контролем памяти как-нибудь разобраться можно, требуется лишь средство расширения синтаксиса.
VD>Тут одно за другое цепляется. Чтобы получить такие средства расширения синтаксиса как в немреле желательно иметь в языке на котором это все пишется фичи которые без того же ЖЦ реализовать будет не так то просто.
VD>Собственно как вариант можно предложить кроскомпиляцию. Когда вместо того чтобы писать на одном языке все, писать макросы на Немерле или Лиспе, а уже по ним генерировать код на С. Но это потребует создания некоторой инфраструктуры.
Угу.
M>>Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет.
VD>Ну, почему нет? Есть. Просто они видимо выходят за твое кругозор. В том же четвертом фрэймворке добавили качественных костылей в виде задач (Task) и PLink-а.
Не видел. Это именно над MPI обертки?
VD>В F#, Хаскеле и Nemerle (в последнем реализовано на макросах) есть Async который позволяет оперировать кодом как объектом. Например, останавливать вычисления в одном потоке и возобновлять в другом.
Да это и так не проблема.
VD>Кроме того есть иделогия акторов. Не для всех случаев жизни подходит (так как общение происходит только через посылку сообщений), но в некоторых вариантах использования очень рулит.
Идеология это конечно хорошо, но чего-нить более материального хочется. В смысле языковой поддержки, желательно не отдельным языком а расширением C++.
Всё это похоже на симптоматическое лечение — лишь оттягивает проблемы.
M>> Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз.
VD>А что за синтаксическая поддержка там нужна?
Вот такое апи есть в SHMEM ():
void shmem_double_p(double *addr, double value, int pe)
addr The remotely accessible array element or scalar data object which
will receive the data on the remote PE.
value The value to be transferred to addr on the remote PE.
pe The number of the remote PE where value will be transferred.
These routines provide a very low latency remote write capability for single elements
of most basic types.
Это же жесть. Чтобы просто записать один double мне нужно звать функцию. Хочу как-то так:
pe_x.data.x = 3.14; //pe_x - PE, что-то вроде прокси к удалённому процессу, data - удалённая структура, объявленная выше.
И чтоб компилятор побольше багов отлавливал.
Главное гармония ...
Re[2]: [Голосование] Почему я не использую Nemerle
T>Ребята, продумайте лучше грамотный PR, распишите чем он лучше других, какие его плюсы, какая его ниша.
У них было достаточно времени, чтобы это придумать. Но результатов нет. Нет ниши, и никто на нём не программирует, только вопят, что это самый лучший язык.
Опрос не понравился — подбор ответов странный, не содержит вариантов, с которыми я бы согласился, и многие ответы явно глупые. Получается, что Nemerle не используют по глупости, но это всего лишь эффект от подбора вариантов ответа. Это всё равно, что опрос: "Почему вы не ходите на гей-парад" с вариантами ответа:
1 Я не люблю веселье
2 Боюсь, что будет плохая погода
Правильный ответ (среди вариантов отсутствует) — у нормального человека не может возникнуть желание пойти на гей-парад, и он не должен это никак объяснять. Вот и Nemerle нормальный человек не станет использовать, и по той же причине (ИМХО).
Бросили бы эти немерлисты заниматься фигнёй — она только отвлекает от изучения нужных для работы тем в программировании.
Re[3]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Partisan, Вы писали:
P>Опрос не понравился — подбор ответов странный, не содержит вариантов, с которыми я бы согласился, и многие ответы явно глупые.
Тебе конечно виднее. Но эти ответы добавляли сами голосующие.
Кстити, подсказка... ты тоже можешь свой вариант добавить.
P>Получается, что Nemerle не используют по глупости,
О, как?
P>но это всего лишь эффект от подбора вариантов ответа. Это всё равно, что опрос: "Почему вы не ходите на гей-парад" с вариантами ответа: P>1 Я не люблю веселье P>2 Боюсь, что будет плохая погода P>Правильный ответ (среди вариантов отсутствует) — у нормального человека не может возникнуть желание пойти на гей-парад, и он не должен это никак объяснять. Вот и Nemerle нормальный человек не станет использовать, и по той же причине (ИМХО).
Ну, так кто мешал добавить свой ответ, то?
P>Бросили бы эти немерлисты заниматься фигнёй — она только отвлекает от изучения нужных для работы тем в программировании.
Да кто тебе мешает то? Проходи мимо и изучай что хочешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Голосование] Почему я не использую Nemerle
Ну, геями немерлистов называло достаточно много людей, но раньше это было завуалированно через публичное объявление себя д'Артаньяном. Но чтобы вот так открыто... Поздравляю, вы первый... Месье
P>Бросили бы эти немерлисты заниматься фигнёй — она только отвлекает от изучения нужных для работы тем в программировании.
А вот это просто убило. Позвольте я продолжу логическую цепочку: "раз отвлекает от изучения нужных тем, значит препятствует профессиональному росту. Раз препятствует профессиональному росту, значит уменьшает стоимость специалиста на рынке труда. Раз уменьшает стоимость, значит повышения зарплаты ему не видать... ГРАЖДАНЕ!!! Из-за этих клятых немерлистов мне зарплату не повышают!!!"
Шареная память в распределенной системе 
Кроме того, виртуальные машины есть не везде. 
