Здравствуйте, gandjustas, Вы писали:
E>>Более 100KLOC
G>На моей первой работе как раз был такой проект. Сейчас я знаю что тоже самое на .NET можно повторить с 10-кратным уменьшением объема. G>Так что размер — совсем необъективный поазатель.
Имелось в виду 100KLOC на Хаскеле. Для остальных можно смело умножать.
T>>>>MPI лучше, чем агенты, поскольку дольше существует. Поэтому он лучше отработан на кластерах. E>>>Тогда, надо полагать, PVM еще лучше MPI, поскольку существует еще дольше. А Java лучше .NET. А Oberon лучше Java... T>>Агенты ничем от MPI не отличаются, за исключением отсутствия стандарта. E>Тогда на основании чего было сделано утверждение, что
Использовать агенты в HPC — немного совсем малоэффективное решение.
E>?
За счёт малой проработанности и отсутствия стандарта.
Вот придумал ты агентов, тебе они показались удобными, лучше, чем MPI. Ты уверен, что на них лягут любые HPC задачи?
Лично я уверен, что нет. Даже большинство не ляжет. А на MPI ляжет, поскольку за ней, пока, опыт.
E>>>И ни слова об автоматическом распараллеливании MPI. Что и не удивительно, т.к. автоматическое распараллеливание и MPI -- это, имхо, взаимоисключающие подходы.
T>>"Let me see..." (C) The Incredibles T>>
E>Therefore, we refer to our scheme as partial-replication. Data replication comes at the cost of limiting the data scalability of programs that is, programs will not be able to handle n-times larger data sets on n processors.
E>А ведь MPI как раз и рулит в области больших вычислений на сотнях и более узлов.
Ну, это преодолимо. Там всего ещё один этап анализа нужен.
T>> а для OpenMP автоматическое распараллеливание существует. E>OpenMP изначально предназначалась для того, чтобы компилятор/runtime распараллеливал те куски, на которые указал программист. Но распараллеливал автоматически. Однако, речь сейчас не об OpenMP.
OpenMP Только переходник. И ещё: есть алгоритмы автоматического вставления прагм OpenMP.
T>>В принципе, товарищи из Майкрософт пытаются облегчить перенос последовательных программ на параллельные системы, это видно по приводимым здесь примерам кода.
T>>С моей точки зрения, это не очень хорошо, поскольку разработчику даётся ещё одно средство прострелить себе ногу. Лучше бы они занялись автоматическим анализом и преобразованиями, чем вот так вот. E>Ну конечно, пусть MS потратит еще десяток-другой лет на поиск хороших решений для автоматического распараллеливания кода. У них же денег много. А еще пусть Haskell вместо C# продвигает, ведь это более прогрессивный подход
Ты серьёзно так думаешь? Очень удивительно слышать от тебя такие слова. Прямо бальзам на душу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>--ушел изучать хаскел чтобы понять что там написано--
G>
Вот ссылка по теме: http://okmij.org/ftp/Haskell/number-parameterized-types.html
T>>В сети мне не встречались ограничения на дизайн .Net. Не подкинешь ссылку? Я имею в виду именно саму .Net, а не написание программ под неё. Про Эрланг это описано в диссертации Джо Армстронга, про Haskell — в History of Haskell. А про .Net такого нет (пардон за каламбур). T>>Вот про .Net такое будет, там всё видно будет. G>Дык твой тезис — тебе и доказывать.
Да. Пожалуй, тут я оставлю позиции.
T>>Вот, например, тесты — когда это нужная работа? G>Много от чего зависит. Например в TDD тесты — средство дизайна кода.
Это хорошо?
http://grundik.livejournal.com/208883.html
G>>>Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы? T>>Кардинально уменьшит количество тестов. G>Я использую TDD, от чего произойдет уменьшение количества тестов?
Уменьшение тестов произойдёт от увеличения проверок.
Типы Хаскеля закрыты (closed), поэтому ты можешь перечислить все интересные случаи на входе.
Тестирование правильности поведения заключается в вызове функции в REPL и входит в цикл разработки. Отдельного этапа создания тестов нет.
Побочных эффектов нет, поэтому композиция правильных функций всегда тоже правильна.
В общей сумме получится, что у тебя есть разработка функций и функциональные тесты программы в целом.
Функциональных тестов получится много меньше.
Надо, что ли, курс какой создать по этому поводу.
T>>>>Ты, например, не знаешь о легкости соединения кода двух независимо работающих разработчиков, когда они пишут на чистом языке. T>>>>У тебя этого под рукой нет. G>>>Ты так говоришь как-будто нету других способов достигнуть такой же легкости. T>>Для императивного программирования и для языков типа OCaml/F# эти "другие способы" переносят сложность в другую область. Например, на тесты. Или на документацию. Или на code review. G>При условии хорошей автоматизации "других областей" это проблемой не является.
Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck).
T>>>>Ты не писал большой проект на скриптовом языке. G>>>Слава богу. T>>Мой критерий уверенного знания языка: ты должен оптимизировать большую программу по скорости. T>>Без большого проекта это невозможно. G>А теперь критерий большого проекта?
2+ разработчика, 6+ месяцев работы. Там получится достаточно чужого кода, проблемы с которым и придётся выяснять.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>За счёт малой проработанности
Понятно.
T>и отсутствия стандарта.
Отсутствие стандарта сложно считать сколь-нибудь серьезным препятствием. Например, у C++ до сих пор нет компиляторов, которые бы на 100% поддерживали стандарт 1998-го года (уж не знаю, насколько всерьез можно воспринимать Comeau). Для Java/Python/Ruby вообще никогда не было стандарта. А вот стандарт ODMG-93 был, только мертворожденный.
T>Вот придумал ты агентов, тебе они показались удобными, лучше, чем MPI. Ты уверен, что на них лягут любые HPC задачи?
Те агенты, которыми пользуюсь я, вообще для HPC не предназначены. А вот что получится из Axum и что попадает потом в C# еще не известно.
T>>>С моей точки зрения, это не очень хорошо, поскольку разработчику даётся ещё одно средство прострелить себе ногу. Лучше бы они занялись автоматическим анализом и преобразованиями, чем вот так вот. E>>Ну конечно, пусть MS потратит еще десяток-другой лет на поиск хороших решений для автоматического распараллеливания кода. У них же денег много. А еще пусть Haskell вместо C# продвигает, ведь это более прогрессивный подход
T>Ты серьёзно так думаешь?
Нет, это сарказм.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
IT>>"Не такое уж и извратство" и "Применять вполне можно" может характеризовать какую-нибудь второстепенную фичу какой-нибудь малоиспользуемой библиотеки, но никак не одну из основных конструкций языка.
AVK>Основную конструкцию ломать уже поздно. Тебе шашечки или ехать?
Да там не конструкцию, там весь язык ломать нужно. Конструкция — это так, вершина айсберга.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>>>Для императивного программирования и для языков типа OCaml/F# эти "другие способы" переносят сложность в другую область. Например, на тесты. Или на документацию. Или на code review. G>>При условии хорошей автоматизации "других областей" это проблемой не является.
T>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck).
Вот тут вопрос...
Эрланг же вроде как не совсем чтоб сильно чистый (процессы, ИО и т.п.), но QuickCheck вроде как интенсивно используют.
Правда тут хрен знает как рассуждать, т.к. QuviQ QuickCheck — вещь закрытая
VE>Не can avoid, а avoids. Можно ли написать на C# такую лямбду, чтобы она _гарантированно_ avoids state and mutable data? До тех пор, пока за это ответственнен автор лямбды и компилятор это не проверяет, функциональным языком будет и Паскаль, где никто не мешает мне написать function foo(x) result := x*x
Тогда OCaml не функциональный язык, а D функциональный
Здравствуйте, thesz, Вы писали:
T>>>Вот, например, тесты — когда это нужная работа? G>>Много от чего зависит. Например в TDD тесты — средство дизайна кода.
T>Это хорошо?
Это прекрасно.
T>http://grundik.livejournal.com/208883.html
У человка видимо неправльные тесты. Даже сама постановка вопроса "надо поменять строчку и для этого понадобилось переписать кучу тестов" неправильная.
G>>>>Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы? T>>>Кардинально уменьшит количество тестов. G>>Я использую TDD, от чего произойдет уменьшение количества тестов?
T>Уменьшение тестов произойдёт от увеличения проверок.
Если и проиойдет, то совсем незначительно. Unit-тесты тестируют функционал, функционала то меньше не станет и в разряд тривиального он не перейдет.
T>Тестирование правильности поведения заключается в вызове функции в REPL и входит в цикл разработки. Отдельного этапа создания тестов нет.
И регрессионного тестирования нет. Это почти 100% проблемы при работе с чужим кодом.
T>Побочных эффектов нет, поэтому композиция правильных функций всегда тоже правильна.
А проверкой того что композиция составлена правильно кто будет заниматься? Обычно эту роль играют интеграционные тесты.
T>Надо, что ли, курс какой создать по этому поводу.
Надо, я прям интересно за счет чего произойдет значительное уменьшение.
T>>>>>Ты, например, не знаешь о легкости соединения кода двух независимо работающих разработчиков, когда они пишут на чистом языке. T>>>>>У тебя этого под рукой нет. G>>>>Ты так говоришь как-будто нету других способов достигнуть такой же легкости. T>>>Для императивного программирования и для языков типа OCaml/F# эти "другие способы" переносят сложность в другую область. Например, на тесты. Или на документацию. Или на code review. G>>При условии хорошей автоматизации "других областей" это проблемой не является.
T>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck). http://research.microsoft.com/en-us/projects/Pex/
Только вот как-то слова о том, что чистые функции могут аллоцировать память (ну это наверное не сильно важно) и бросать исключения как минимум смущают.
И проверка поведения на совести автора кода, я так понимаю?
Здравствуйте, Курилка, Вы писали:
К>Только вот как-то слова о том, что чистые функции могут аллоцировать память (ну это наверное не сильно важно) и бросать исключения как минимум смущают.
Исключения можно запретить.
Память могут и выделяют чистые функции на любом языке.
К>И проверка поведения на совести автора кода, я так понимаю?
Здравствуйте, Курилка, Вы писали:
FR>>В D есть http://www.digitalmars.com/d/2.0/function.html#pure-functions
К>Только вот как-то слова о том, что чистые функции могут аллоцировать память (ну это наверное не сильно важно) и бросать исключения как минимум смущают.
А с исключениями какие проблемы? Вот функция sqrt для вычисления квадратного корня. Она перестанет быть чистой, если будет выбрасывать исключение при получении отрицательного аргумента?
К>И проверка поведения на совести автора кода, я так понимаю?
В компиляторе D реализованы какие-то проверки чистоты функции. Об этом говорится даже в примере:
int x;
invariant int y;
const int* pz;
pure int foo(int i, // ok, implicitly convertible to invariantchar* p, // error, not invariantconst char* q, // error, not invariant
invariant int* s // ok, invariant
)
{
x = i; // error, modifying global state
i = x; // error, reading mutable global state
i = y; // ok, reading invariant global state
i = *pz; // error, reading const global statereturn i;
}
Но вот насколько эти проверки полные -- это вопрос.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
E>>Но вот насколько эти проверки полные -- это вопрос.
FR>Если нужна совершенно чистая функциональщина, то в D это тоже есть в виде FR>Compile Time Function Execution
FR>http://www.digitalmars.com/d/2.0/function.html#interpretation
Да я как бы в курсе
Про полноту проверок я сказал потому, что где-то встречал описания ошибок в DMD, связанных с определением чистоты. Понятно, что это баги и их количество должно уменьшаться со временем. Но пока DMD не стабилизировался есть шанс, что компилятор воспримет как чистую функцию, которая таковой не является.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck). К>Вот тут вопрос... К>Эрланг же вроде как не совсем чтоб сильно чистый (процессы, ИО и т.п.), но QuickCheck вроде как интенсивно используют.
Опять же, из тезиса Джо Армстронга. Функции эрланговских процессов достаточно чисты. В принципе, их можно рассматривать, как state monad над состоянием процесса, включая и очередь сообщений, и посылку оных.
Получается функция вида InputMessage -> ProcessState -> -> FunctionState -> FunctionInput -> (OutputMessage,ProcessState,FunctionState).
Не такой уж и сложный тип.
К>Правда тут хрен знает как рассуждать, т.к. QuviQ QuickCheck — вещь закрытая
Я посмотрел. Довольно забавно. Видео у меня нет, я посмотрел на названия примеров и на флайер.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Вот, например, тесты — когда это нужная работа? G>>>Много от чего зависит. Например в TDD тесты — средство дизайна кода. T>>Это хорошо? G>Это прекрасно.
Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа.
Это не постановка вопроса, это жизнь.
G>>>>>Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы? T>>>>Кардинально уменьшит количество тестов. G>>>Я использую TDD, от чего произойдет уменьшение количества тестов? T>>Уменьшение тестов произойдёт от увеличения проверок. G>Если и проиойдет, то совсем незначительно. Unit-тесты тестируют функционал, функционала то меньше не станет и в разряд тривиального он не перейдет.
Тебе потребуется меньше тестировать функционал, поскольку его правильность проверяется компилятором.
Сравнение с образцом проверяется на полноту, типы проверяются строже. Вообще, проверок больше.
И их проще сделать самому.
T>>Тестирование правильности поведения заключается в вызове функции в REPL и входит в цикл разработки. Отдельного этапа создания тестов нет. G>И регрессионного тестирования нет. Это почти 100% проблемы при работе с чужим кодом. T>>Побочных эффектов нет, поэтому композиция правильных функций всегда тоже правильна. G>А проверкой того что композиция составлена правильно кто будет заниматься? Обычно эту роль играют интеграционные тесты.
У тебя есть типы. Интерфейсы должны по типам совпадать. Если совпали — переходи к функциональным тестам.
Интеграционные тесты требуются для проверки на правильность поддержания инвариантов.
T>>Надо, что ли, курс какой создать по этому поводу. G>Надо, я прям интересно за счет чего произойдет значительное уменьшение.
Да уж думаю.
T>>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck). G>http://research.microsoft.com/en-us/projects/Pex/
Сравни с QuickCheck, которая вообще библиотекой выполнена.
При желании можно разобраться и добавить функционала. С Pex у тебя такой возможности нет (в поставке нет исходного кода). И ещё: с Pex у тебя создаются юнит-тесты, которые ты должен сохранить и прогнать, в QuickCheck ты задаёшь свойства, прогонкой занимается QuickCheck.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>>>Вот, например, тесты — когда это нужная работа? G>>>>Много от чего зависит. Например в TDD тесты — средство дизайна кода. T>>>Это хорошо? G>>Это прекрасно.
T>Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа.
Хм... например тест проверяет что функция возвращает список объектов, упорядоченных по одному из полей.
Как это одной строкой типа записать?
T>>>http://grundik.livejournal.com/208883.html G>>У человка видимо неправльные тесты. Даже сама постановка вопроса "надо поменять строчку и для этого понадобилось переписать кучу тестов" неправильная. T>Это не постановка вопроса, это жизнь.
Хреновая жизнь. Вероятнее всего вызванная тем, что человек гонялся за code coverage.
T>Тебе потребуется меньше тестировать функционал, поскольку его правильность проверяется компилятором.
На примере выше показать можно?
T>>>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck). G>>http://research.microsoft.com/en-us/projects/Pex/
T>Сравни с QuickCheck, которая вообще библиотекой выполнена.
Pex выполняет анализ кода, а не тестирование случаными данными.
Для тестирования случайными данными в .NET можно тоже просто библиотеку написать.
T>При желании можно разобраться и добавить функционала. С Pex у тебя такой возможности нет (в поставке нет исходного кода). И ещё: с Pex у тебя создаются юнит-тесты, которые ты должен сохранить и прогнать, в QuickCheck ты задаёшь свойства, прогонкой занимается QuickCheck.
В pex есть тоже самое. Свойства задаются контрактами (code contracts) и параметризованными тестами. Pex генерит тесты так как анализ выполняется достаточно долго, тесты фактически являются кешированными результатами анализа.
При этом тесты гораздо удобнее в использовании чем отдельные утилиты.
T>>Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа. G>Хм... например тест проверяет что функция возвращает список объектов, упорядоченных по одному из полей. G>Как это одной строкой типа записать?
В Хаскеле к этому (см. раздел 5.1 Evidence is Ordering) только идут.
Хотя могу.
class Ordered order a where
mkOrder :: order -> a -> a -> (a,a)
data ByField1
instance Ordered ByField1 Obj
mkOrder _ a b = if field1 a > field1 b then (a,b) else (b,a)
data OrderedBy ordering a where
OrderedBy :: Ordered ordering a => ordering -> a -> a -> OrderedBy ordering a
mkOrderedBy :: Ordered ordering a => ordering -> a -> a -> OrderedBy ordering a
mkOrderedBy ordering x y = OrderedBy ordering low high
where
(low,high) = mkOrder ordering x y
fromOrderedBy (OrderedBy _ a b) = (a,b)
Упорядоченную пару я создал, из неё можно сделать упорядоченный список похожим образом.
Заметь, что упорядочение у меня протягивает и доказательство тоже. То есть, достаточно создать правильное создание упорядоченного списка (пары) и сделать несколько instance Ordered, и всё со всеми заработает. Правильность кода доказана.
T>>>>http://grundik.livejournal.com/208883.html G>>>У человка видимо неправльные тесты. Даже сама постановка вопроса "надо поменять строчку и для этого понадобилось переписать кучу тестов" неправильная. T>>Это не постановка вопроса, это жизнь. G>Хреновая жизнь. Вероятнее всего вызванная тем, что человек гонялся за code coverage.
По-моему, он старался проверить возможные пути.
T>>Тебе потребуется меньше тестировать функционал, поскольку его правильность проверяется компилятором. G>На примере выше показать можно?
Ну, sized types мы уже рассмотрели. Упорядочение тоже.
Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns).
T>>Сравни с QuickCheck, которая вообще библиотекой выполнена. G>Pex выполняет анализ кода, а не тестирование случаными данными. G>Для тестирования случайными данными в .NET можно тоже просто библиотеку написать.
И как ты проверишь все возможные пути изменения состояния?
G>При этом тесты гораздо удобнее в использовании чем отдельные утилиты.
Ну, я в подробных тестах не силен, поскольку не использую. Спорить не буду.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа. G>>Хм... например тест проверяет что функция возвращает список объектов, упорядоченных по одному из полей. G>>Как это одной строкой типа записать?
T>В Хаскеле к этому (см. раздел 5.1 Evidence is Ordering) только идут.
T>Хотя могу.
T>
T>class Ordered order a where
T> mkOrder :: order -> a -> a -> (a,a)
T>data ByField1
T>instance Ordered ByField1 Obj
T> mkOrder _ a b = if field1 a > field1 b then (a,b) else (b,a)
T>data OrderedBy ordering a where
T> OrderedBy :: Ordered ordering a => ordering -> a -> a -> OrderedBy ordering a
T>mkOrderedBy :: Ordered ordering a => ordering -> a -> a -> OrderedBy ordering a
T>mkOrderedBy ordering x y = OrderedBy ordering low high
T> where
T> (low,high) = mkOrder ordering x y
T>fromOrderedBy (OrderedBy _ a b) = (a,b)
T>
T>Упорядоченную пару я создал, из неё можно сделать упорядоченный список похожим образом.
Да уж... одна строка типа...
T>Заметь, что упорядочение у меня протягивает и доказательство тоже. То есть, достаточно создать правильное создание упорядоченного списка (пары) и сделать несколько instance Ordered, и всё со всеми заработает. Правильность кода доказана.
ИХМО приседаний многовато. Хотя надо на реальном проекте сравнить.
T>>>>>http://grundik.livejournal.com/208883.html G>>>>У человка видимо неправльные тесты. Даже сама постановка вопроса "надо поменять строчку и для этого понадобилось переписать кучу тестов" неправильная. T>>>Это не постановка вопроса, это жизнь. G>>Хреновая жизнь. Вероятнее всего вызванная тем, что человек гонялся за code coverage. T>По-моему, он старался проверить возможные пути.
Это и есть погоня за code coverage. Тесты должны не пути проверять, а функционал.
T>Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns).
Вне контекста pattern-matching такое рассматривать смысла нет.
T>>>Сравни с QuickCheck, которая вообще библиотекой выполнена. G>>Pex выполняет анализ кода, а не тестирование случаными данными. G>>Для тестирования случайными данными в .NET можно тоже просто библиотеку написать. T>И как ты проверишь все возможные пути изменения состояния?
Я — никак, а pex умеет.
Если нам не помогут, то мы тоже никого не пощадим.
