FR>Сложно сказать, может на пике моды стать и вполне востребованным, может и незаметно пройти. Но по любому если человек смог освоить F# это показатель достаточно высокой квалификации, так что лишним это в резюме по моему не будет.
Что есть строчка в резюме без реальных проектов? Я этот язык могу добавить в свое резюме хоть сейчас.
Выучить-то можно. Только вопрос нужно ли. Меня интересует будет ли работа на Ф-шарпе или нет, кто что думает. Лично мое мнение таково: этот язык не нужен, по крайней мере на данный момент. Уже все написано и сделано. Майкрософту нужно генерировать разные идеи чтобы делать деньги. Виста провалилась. Большинство довольствуется Виндоусом ХР и продолжили бы сидеть на нем и дальше если бы Майкрософт не выкручивал руки. Вот я и думаю стоит ли тратить время чтобы серьезно изучать этот язык. Не ради простого интереса а ради того чтобы в будущем зарабатывать на нем деньги. Ну и оставаться competitive на рынке труда.
Здравствуйте, skeptik_, Вы писали:
_>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>сейчас идёт хорошо заметный ФП hype, в связи с тем что это более высокоуровневый подход к программированию вообще и его хорошей приспособленностью к многопоточности в частности. я несколько лет назад предполагал, что 2010-е станут десятилетием ФП, но ошибся. так же, как и в прошлый раз, переход идёт в два этапа. на первом чистые ООП языки бкдкт сменены смешанными, включая F# и вероятно Скалу. и только на втором этапе, в следующем десятилетии, я думаю, программисты уже достаточно привыкнут к ФП чтобы перейти к чистым ФП языкам
_>Я думаю, что чистый ФП никогда не будет массовым. Искусственные ограничения никому не нужны, чтобы потом мужественно их преодолевать, выдумывая всякие монады и т.п.. За смешанными языками будущее.
Интересно, ограничение адресной арифметики в языках с GC — естественное или искусственное ограничение?
А что что я не могу просто написать return new X() в языке без GC, а должен вернуть обертку, считающую ссылки или (о ужас) договориться с вызывающим о том кто и как будет освобождать память, это не искусственное ограничение?
То что в большинстве языков нельзя написать fibs = 1 : 1 : zipWith (+) fibs (tail fibs) без того чтобы создавать итераторы\генераторы, кешировать результаты каким-то образом, это естественное или искусственное ограничение?
Почему какое-то ограничение языка естественное или искусственное? Наверное это зависит от уровня абстракции.
Для нормальной работы ленивости по-умолчанию, которая обеспечивает более высокий уровень абстракции, (пример выше) необходимо отсутствие побочных эффектов (это естественное ограничение на данном уровне абстракции), а так как побочные эффекты необходимы, без них программы не имеют смысла, то надо эти самые побочные эффекты выражать явно.
Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым".
Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.
Здравствуйте, Олег К., Вы писали:
ОК> Интересно будут ли востребованны программисты со знанием этого языка и примерно когда?
Есть мнение, что программисты со знанием этого языка в среднем будут и более хорошими программистами на том же C#. Даже если не будут использовать F# на практике. Для хорошего программиста вопрос изучать язык или не изучать стоять вообще не должен — конечно же изучать, всегда, любой новый язык, сколько бы их ни было.
OK> Если вообще этот язык кому-то (работодатели, имеется в виду) нужен...
Да, конечно же. Уже полно таких работ, правда, для OCaml пока ещё заметно больше.
OK> Ваши мнения и прогнозы на счет этого языка и работы с ним и у нас и в Штатах (особенно в финансовой индустрии), господа?
В финансовой индустрии OCaml любят (e.g., Jane Street Capital). Так что, могут и F# полюбить.
Здравствуйте, QrystaL, Вы писали:
QL>Есть новые мысли по теме? =)
Есть. Нужен единый и простой язык реализующий преимущества как императивного, функционального и логических языков. Почему про логические забыли? Есть очень удачные решения. И вообще нужен свежий взгляд на проблемы языка. Их стало слишком много, функционально разница нулевая, только синтаксическая мозговздрочь. Ну, и понты..Я на Ruby а тот на питоне.. Бейсик это позор.. А фукциональные возможности одинаковые. Чуть в стороне java. Удачно подмечены и реализованы общие подходы к классам, свойствам и объектам и плюс апплеты. А в остальном тот же хрен. Ассемблеры и С плюсы обсуждать не буду. У них свои задачи. Необсуждаемые. Да.. Есть еще графические для микроконтроллеров..Это к ассемблерам.. с макросами удобренные макросами с визуальным представлением. Принципиально нового нет ничего. Движение в сторону усложения приведет к упрощению и выработке единых концепций. Я так думаю.
Есть еще куча специализированых языков.. Для технологов, бухгалтеров и т.п. ну, это жалкое подобие левой руки.. Нет смысла даже обсуждать
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Mazay, Вы писали: M>>>Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы. G>>Платформа у всех одна — x86 (x64)
К>Ты уверен, что у всех?
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, gandjustas, Вы писали: G>>Если так хочется в это верить, то пожалуйста. N_>Эт увас суждения на вере основываются, а уменя многочисленный опыт.
Какой опыт, переписывания с управляемого языка на С?
G>>На деле оказывается что оптимизация требуется максимум 20% программы, причем в основном не за счет "пидарасинья тактов" на низкоуровневом языке, N_>Ага, тока когда эти 20% размазаны по всему проекту, посмотрим как ты задолбаешься выносить их в отдельные модули написанные на другом языке, придумывать им адекватный интерфейс и стыковать с остальным приложением. А всегото требовалось в высокооровневый язык добавить возможность при необходимости обращаться к низкоуровневым средствам куча гимороя с этим разделением на модули на раздных языках как рукой снимет.
Это многочисленный опыт подсказывает? А мне постоянно профайлер подсказывает что тормоза по большей части сосредоточены в одном месте.
G>> а за счет выбора правильного алгоритма. N_>Только вот некоторые высокоуровневые языки, включая сабжевый, не имеют требуемых низкоуровневых инструментов для реализации этого "правильного алгоритма".
Вот именно именно сабжевый имеет все необходимые средства.
G>> Поэтому даже при подходе "выкинуть и переписать на ассемблере" придется 10% программы. N_>Зачем асемблер? Что привычка делить все на черное и белое Есть с++, который весьма высокоуровневый, но в все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости.
"Высокоуровневый С++" оказывается медленнее (часто) и гораздо менее надежным (всегда) того же .NET или java. Холивар на эту тему уже был в КСВ, повторяться не будем.
"Высокоуровневый С++" стоит применять как "C с классами" для ограниченного набора задач.
Ты до сих пор не понял что "все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости" — это связывание компилятора по рукам и ногам, потому что он не способен доказать ни одно утверждение в твоей программе. Именно отказ от многих низкоуровневых средств повышает не только безопасность, но и быстродействие.
Здравствуйте, Олег К., Вы писали:
ОК>Майкрософт недавно выпустил F#. Хочется услышать что думает народ о проникновении очередного языка
я несколько лет назад писал в философию, теперь гляжу этот вопрос интересует уже более широкий круг программистов. чтобы ответить на него — советую заглянуть в историю
в 80-е годы наиболее популярными промышленными языками были процедурные — си и паскаль. потом стал нарастать ООП hype, и их вытеснили ппрямые наследники — процедурные языки с ооп-элементами, с++ и delphi. в 90-е годы ооп доказала свою жизнеспособность и следующее поколение языков — ява и c# были уже ооп-ными
сейчас идёт хорошо заметный ФП hype, в связи с тем что это более высокоуровневый подход к программированию вообще и его хорошей приспособленностью к многопоточности в частности. я несколько лет назад предполагал, что 2010-е станут десятилетием ФП, но ошибся. так же, как и в прошлый раз, переход идёт в два этапа. на первом чистые ООП языки бкдкт сменены смешанными, включая F# и вероятно Скалу. и только на втором этапе, в следующем десятилетии, я думаю, программисты уже достаточно привыкнут к ФП чтобы перейти к чистым ФП языкам
на данный момент F# ещё мало востребован в реальной работе, но имхо признаком хорошего программиста уже становится что он знает хаскел (чисто для понтов, сумел выучить — значит не дурак), а реальные задачи способен писать на f#. проекты будут постепенно перетекать на него, благо что .net позволяет писать разные части приложения на разных языках. ФП hype и в частности F# hype будут усиливаться
так что советую изучать его чтобы не отстать от модного тренда. с другой стороны, пока ты не начнёшь считать что f# лучше чем c#, а хаскел ещё лучше, ты не будешь походить на человека, который вкурил фп. как там у пелевина — есть пидорасы, а есть те, кто только косит под пидорасов
Здравствуйте, Олег К., Вы писали:
ОК>Интересная мысль. Возможно все так и будет но меня "настораживают" несколько моментов. До примерно 2000-го было куда расти. Языки был несовершенны. Не было такого массового развитиях информационных технологий. Виндоус был нов. Интернет был нов. Hype окружающая Джаву была намного сильнее чем когда появился Си шарп. Может потому что ниша была уже занята. А сейчас все есть. Си шарп и дот нет справляются с поставленными задачами. Бизнесам нужно видеть что дадут функциональные языки чтобы начать повсеместное использование. Большинство ведь используют какое-то небольшое подмножество С++/Джавы/Шарпа/.НЕТа.
Вообще настроение из разряда "конец физики".
Просто завершилась еще одна попытка индустриализации программирования с помощью простых языков (ява и первый шарп) с мощными фреймфорками на которых могут писать и малоквалифицированные кодеры. Выпуск второго и третьего шарпа показывает что попытка с треском провалилась.
Здравствуйте, gandjustas, Вы писали:
G>Почему какое-то ограничение языка естественное или искусственное? Наверное это зависит от уровня абстракции.
Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы. Например, возможность изменять значение в ячейках памяти. Средства обеспечения локальности доступа к памяти (возможность размещать объекты в памяти с требуемым выравниванием и в требуемом порядке).
G>Для нормальной работы ленивости по-умолчанию, которая обеспечивает более высокий уровень абстракции, (пример выше) необходимо отсутствие побочных эффектов (это естественное ограничение на данном уровне абстракции), а так как побочные эффекты необходимы, без них программы не имеют смысла, то надо эти самые побочные эффекты выражать явно.
Ну вот. Явное управление памятью это плохо, а явные побочные эффекты это хорошо?
G>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым". G>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.
Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Почему какое-то ограничение языка естественное или искусственное? Наверное это зависит от уровня абстракции. M>Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы.
Платформа у всех одна — x86 (x64)
Не надо начинать разговор о том что считать платформой. Это бесконечный разговор.
G>>Для нормальной работы ленивости по-умолчанию, которая обеспечивает более высокий уровень абстракции, (пример выше) необходимо отсутствие побочных эффектов (это естественное ограничение на данном уровне абстракции), а так как побочные эффекты необходимы, без них программы не имеют смысла, то надо эти самые побочные эффекты выражать явно. M>Ну вот. Явное управление памятью это плохо, а явные побочные эффекты это хорошо?
Да, неявное управление памятью, как и явное управление побочными эффектами хорошо так как и то и другое позволяет меньше ошибаться.
G>>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым". G>>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье. M>Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи.
Ну да, а примеры можно?
Можно привести такой пример: существуют довольно интересные языки
программирования Haxe и Boo.Они во многом похожи, например, строгой стати-
ческой типизацией и выводом типов. Первый язык реализован преимуществен-
но на OCaml, второй—на C#.
Реализация системы типов в Boo, написанном на C#, занимает более семна-
дцати тысяч строк кода (более половины мегабайта кода на высокоуровневом
языке), размещающихся в ста двадцати двух файлах. При этом представлявший
наибольший интерес алгоритм вывода типов надежно декомпозирован на слои
и «шаблоны проектирования» и код, который его реализует является вполне
идиоматичнымдля этого класса языков. Задача идентифицировать основной код
алгоритма и понять его не выглядела решаемой за разумное время и была остав-
лена.
Ни одной понятной реализации системы типов и алгоритма выведения на
императивных языках найдено не было (были рассмотрены варианты на C#, С++
и даже Perl).
Реализация системы типов в языке Haxe, занимает 4088 строк (127624 байт
кода) на OCaml и размещается в трех файлах, при этом интересующий алгоритм
идентифицируется сразу же и представляет собой, в основном, свертку списков
с применением сопоставления с образцом. Прочитать и понять его было доста-
точно легко, несмотря на то, что на тот момент опыт разработки и чтения кода,
написанного на императивных языках, сильно превосходил аналогичный опыт
для функциональных.
Даже со всеми возможными оговорками разница в функциональности си-
стем типов Boo и Haxe гораздо меньше, чем разница в количестве кода, эту функ-
циональность реализующего: 100072 строки (2955595 байт) кода текущей реали-
зации Boo убивали всякую надежду, что подобный проект может вообще быть
реализован самостоятельно.
Здравствуйте, Mazay, Вы писали:
M>Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных.
Явные побочные эффекты сильно упрощают композицию кода и отладку.
От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.
M>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого?
Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС.
Запрещено только ручное управление managed-памятью.
M>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования.
Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков.
G>>>>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым". G>>>>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье. M>>>Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи. G>>Ну да, а примеры можно? M>Я уже привёл: M>
M>Средства обеспечения локальности доступа к памяти (возможность размещать объекты в памяти с требуемым выравниванием и в требуемом порядке)
А причем тут функциональные языки? Это прерогатива компилятора и рантайма. В .NET для структуры это возможно, в другом языке можно будет сделать такое и для других объектов.
M>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память?
А ты придумай скачала адекватную задачу для чего такое понадобится.
M>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти?
Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.
Ты себя загоняешь в рамки императивных алгоритмов, а потом пытаешься эти алгоритмы на чистые языки натянуть.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память? G>>А ты придумай скачала адекватную задачу для чего такое понадобится. M>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?
Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.
M>>>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти? G>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка. M>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору?
Индексная сортировка.
G>>Ты себя загоняешь в рамки императивных алгоритмов, а потом пытаешься эти алгоритмы на чистые языки натянуть. M>Я себя загоняю в рамки той архитектуры ЭВМ которой располагаю. И я хочу использовать эту архитектуру на всю катушку. А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа.
Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.
Здравствуйте, gandjustas, Вы писали: G>Если так хочется в это верить, то пожалуйста.
Эт увас суждения на вере основываются, а уменя многочисленный опыт. G>На деле оказывается что оптимизация требуется максимум 20% программы, причем в основном не за счет "пидарасинья тактов" на низкоуровневом языке,
Ага, тока когда эти 20% размазаны по всему проекту, посмотрим как ты задолбаешься выносить их в отдельные модули написанные на другом языке, придумывать им адекватный интерфейс и стыковать с остальным приложением. А всегото требовалось в высокооровневый язык добавить возможность при необходимости обращаться к низкоуровневым средствам куча гимороя с этим разделением на модули на раздных языках как рукой снимет. G> а за счет выбора правильного алгоритма.
Только вот некоторые высокоуровневые языки, включая сабжевый, не имеют требуемых низкоуровневых инструментов для реализации этого "правильного алгоритма". G> Поэтому даже при подходе "выкинуть и переписать на ассемблере" придется 10% программы.
Зачем асемблер? Что привычка делить все на черное и белое Есть с++, который весьма высокоуровневый, но в все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости.
Здравствуйте, gandjustas, Вы писали:
G>>>PS. Дополнительные log(n) — стандартная проблема при использовании immutable. M>>+1
M>>Ну вот собссно и весь разговор. Просто есть задачи, где дополнительные log(n) неприемлемы. У меня подозрение, что многие программисты не переваривают ФП именно из-за того, что не в состоянии принять решение с таким пенальти.
G>Ну тут избрали неверный подход. Если тупо императивный алгоритм переписать с immutable объектами, то он получит дополнительный log(n), если писать алгоритм изначально в функциональном подходе, то можно не только не получать дополнительные множители, но и ускорить программу за счет ленивости, сократив при этом текст программы, к тому же получить простоту распараллеливания.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Mazay, Вы писали:
M>>Здравствуйте, gandjustas, Вы писали:
G>>>Почему какое-то ограничение языка естественное или искусственное? Наверное это зависит от уровня абстракции. M>>Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы. G>Платформа у всех одна — x86 (x64) G>Не надо начинать разговор о том что считать платформой. Это бесконечный разговор.
По крайней мере RAM с кэшем есть везде. Причём read-write. По крайней мере для определённых задач.
G>>>Для нормальной работы ленивости по-умолчанию, которая обеспечивает более высокий уровень абстракции, (пример выше) необходимо отсутствие побочных эффектов (это естественное ограничение на данном уровне абстракции), а так как побочные эффекты необходимы, без них программы не имеют смысла, то надо эти самые побочные эффекты выражать явно. M>>Ну вот. Явное управление памятью это плохо, а явные побочные эффекты это хорошо? G>Да, неявное управление памятью, как и явное управление побочными эффектами хорошо так как и то и другое позволяет меньше ошибаться.
Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных.
Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого? На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования.
G>>>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым". G>>>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье. M>>Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи. G>Ну да, а примеры можно?
Я уже привёл:
Средства обеспечения локальности доступа к памяти (возможность размещать объекты в памяти с требуемым выравниванием и в требуемом порядке)
Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память?
Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти?
Здравствуйте, Олег К., Вы писали:
ОК>Ваши мнения и прогнозы на счет этого языка и работы с ним и у нас и в Штатах (особенно в финансовой индустрии), господа?
Пока это все баловство. Туи (в финансовой индустрии) народ от ужаса глаза таращит, когда говоришь, что проект планируешь делать на дотнете 3.5, куча народу сидит еще на 1.1 и слезать не собирается в ближайшее время. Какой там F#, разве что у квантов.
Думаю лет 10 до массового внедрения есть, если оно вообще будет, подход спорный и не факт, что закрепится в индустрии.
На данный момен на дайсе есть всего 5 позиций по F#, причем F# в списке второстепенных скиллов. Вообщем ради развлекухи и хобби стоит поизучать, реально вакансий на нем считай, что и нет. И не факт, что будут, вполне вероятен результат "поигрались и забросили".
Здравствуйте, Олег К., Вы писали:
ОК>Интересная мысль. Возможно все так и будет но меня "настораживают" несколько моментов. До примерно 2000-го было куда расти. Языки был несовершенны. Не было такого массового развитиях информационных технологий. Виндоус был нов. Интернет был нов.
Да раньше трава была гораздо зеленее а девушки моложе.
ОК>Hype окружающая Джаву была намного сильнее чем когда появился Си шарп. Может потому что ниша была уже занята. А сейчас все есть. Си шарп и дот нет справляются с поставленными задачами. Бизнесам нужно видеть что дадут функциональные языки чтобы начать повсеместное использование. Большинство ведь используют какое-то небольшое подмножество С++/Джавы/Шарпа/.НЕТа.
За это время параллельно прошел например вал по питону и руби, который ты не заметил.
ОК>Я, конечно, понимаю что отдельные личности/компании стараются использовать последние технологии но вот насколько массово это будет? То что создается сейчас заметный функциональный hype — это ведь только самим программистам и интересно. А бизнесам что до этого? Я уже привел пример с Виндоусом ХР. Большинство бы так на нем и сидело, хотя ему уже 8 лет, если бы Майкрософт не выкручивал руки.
Тут все просто если тебе интересно изучай, нет забей. Польза от изучения всегда будет пусть даже и косвенная.
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, gandjustas, Вы писали: G>>Не 100% конечно, но подавляющее большинство.
N_>Мобильные устройства сейчас занели довольно существенную ддолю рынка разработки ПО, а АРМ не имеет ничего общего с х86
Какое отношение это имеет к функциональным языкам?
Просто захотелось эрудицией блеснуть?
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, gandjustas, Вы писали: G>>Этот разговор уже миллионы раз поднимался. Если быстродействия для миллионов пользователей достаточно, то не нужно тратить эти самые месяцы. Но чтобы узнать это — надо сначала выпустить программу, а потом уже тратить время на оптимизацию. В этом как раз более высокоуровневые языки помогают. N_>Ага, только если программа написана на чемнить типа шарпа, то когда упрутся в то что производительность недостаточная, придется выкинуть все написанное и переписать программу с нуля на плюсах. Так что зарание подумать тоже не лишне
Если так хочется в это верить, то пожалуйста. На деле оказывается что оптимизация требуется максимум 20% программы, причем в основном не за счет "пидарасинья тактов" на низкоуровневом языке, а за счет выбора правильного алгоритма. Поэтому даже при подходе "выкинуть и переписать на ассемблере" придется 10% программы. Это гораздо лучше чем пытаться сразу писать все на ассемблере.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>>>Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных. G>>>>Явные побочные эффекты сильно упрощают композицию кода и отладку. G>>>>От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.
M>>>>>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого? G>>>>Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС. G>>>>Запрещено только ручное управление managed-памятью. M>>>То есть если мне понадобилось вручную выровнять одну структуру данных, то весь код, который от неё зависит, становится неуправляемым? G>>Конечно нет. M>Да ну? Вот мне нужен непрерывный кусок данных...
Пока ты так думаешь, то выше уровня С не поднимишься.
Хотя может тебе и не надо, но такие задачи далеко не у всех и со временем их становится меньше.
M>>>>>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования. G>>>>Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков. M>>>Во-первых я не про .NET, а про ФП. G>>А тема то про f# M>Ну а F# не функциональный что-ли? И вообще — не перебивай
Именно функциональный и на .NET. Так что в нем доступно то самое выравнивание структур.
M>>>Во-вторых, дело не в "быстрее". Быстроту всегда можно обеспечить ручной аллокацией там где укажет профилировщик. Дело в локальности данных. G>>Как раз сборщиком мусора типа .NETовского локальность данных получается идеальная. Блоки памяти в основном хипе выделяются строго последовательно. G>>И от языка это вообще говоря не зависит. M>Знать бы ещё, что такое идеальная локальность . Ну вот если я набиваю список в F#, у меня разве есть гарантии, что элементы будут лежать последовательно в памяти? А если я заменил последний элемент и продолжил набивать список?
Блоки памяти в .NET выделяются последовательно. Хотя что тебе это даст? Ты все равно не сможешь писать на F#, C# и другом .NET языке как на С.
M>>>AFAIK с этим в .NET как-то можно работать, я, опять же, говорю про ФП. G>>Тема то про f# M>Как мне в F# вручную задать размещение объектов "в памяти с требуемым выравниванием и в требуемом порядке" (3-й раз уже повторяю)?
На F# не знаю, я таким не занимался, на C# — берешь unsafe и указателем бегаешь как захочется.
Хотя я твой вопрос могу понять так "как мне на <любой ФЯП> писать как на C" — в общем случае ответ "НИКАК". И пока ты этого не поймешь, ты не сможешь получить преимуществ от функциональных языков, да и вообще от managed языков.
Очень мало современных языков позволяют писать как на С, и это их преимущество, а не недостаток.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Олег К., Вы писали:
ОК>>Майкрософт недавно выпустил F#. Хочется услышать что думает народ о проникновении очередного языка
[скип]
BZ>я несколько лет назад писал в философию, теперь гляжу этот вопрос интересует уже более широкий круг программистов. чтобы ответить на него — советую заглянуть в историю
BZ>на данный момент F# ещё мало востребован в реальной работе, но имхо признаком хорошего программиста уже становится что он знает хаскел (чисто для понтов, сумел выучить — значит не дурак), а реальные задачи способен писать на f#. проекты будут постепенно перетекать на него, благо что .net позволяет писать разные части приложения на разных языках. ФП hype и в частности F# hype будут усиливаться
[скип]
Просто напрашивается перефразировать.
"...но имхо признаком хорошего {бульдозериста} уже становится что он знает {как управлять вертолётом} (чисто для понтов, сумел выучить — значит не дурак)"
Здравствуйте, Олег К., Вы писали:
ОК>Майкрософт недавно выпустил F#. Хочется услышать что думает народ о проникновении очередного языка от Майкрософт в индустрию. Есть C#, есть VB .NET. Нужен ли еще один? .NET-у уже 7-8 лет, но Java все равно популярнее. Интересно будут ли востребованны программисты со знанием этого языка и примерно когда? Если вообще этот язык кому-то (работодатели, имеется в виду) нужен... Ваши мнения и прогнозы на счет этого языка и работы с ним и у нас и в Штатах (особенно в финансовой индустрии), господа?
F# — это реализация языка OCaml под .NET. Сам я на нем не писал, но один из моих знакомых (один из лучших программистов, которых я когда-либо встречал) очень хорошего мнения об этом языке и написал на нем программу типа Sendmail и ряд других. (Мэйлер был объемом 10000 строк кода на OCaml, аналогичная программа на C, по его мнению, была бы в 10 раз длиннее).
Кстати, этот программист уже несколько лет занимается применением таких языков как OCaml и Haskell в банковской сфере и в настоящее время является начальником отдела Research & Development одного из европейских банков.
Интересная мысль. Возможно все так и будет но меня "настораживают" несколько моментов. До примерно 2000-го было куда расти. Языки был несовершенны. Не было такого массового развитиях информационных технологий. Виндоус был нов. Интернет был нов. Hype окружающая Джаву была намного сильнее чем когда появился Си шарп. Может потому что ниша была уже занята. А сейчас все есть. Си шарп и дот нет справляются с поставленными задачами. Бизнесам нужно видеть что дадут функциональные языки чтобы начать повсеместное использование. Большинство ведь используют какое-то небольшое подмножество С++/Джавы/Шарпа/.НЕТа.
Я, конечно, понимаю что отдельные личности/компании стараются использовать последние технологии но вот насколько массово это будет? То что создается сейчас заметный функциональный hype — это ведь только самим программистам и интересно. А бизнесам что до этого? Я уже привел пример с Виндоусом ХР. Большинство бы так на нем и сидело, хотя ему уже 8 лет, если бы Майкрософт не выкручивал руки.
Здравствуйте, Good Looking Man, Вы писали:
GLM>Это ж просто набор красивых слов. GLM>А есть информация как его компания/департамент использует новые языки например для "high-frequency trading platforms"?
Здравствуйте, Gatwick, Вы писали:
M>>конечно же изучать, всегда, любой новый язык, сколько бы их ни было.
G>Ну да, конечно, а жизнь за пределами компа ему ни к чему. "Вместо солнца нам партия светит, вместо хлеба работу давай".
Ну так изучать то в рабочее время надо. Это только повышает эффективность работы (и, соответственно, доступное количество этой самой жизни за пределами работы в том числе).
Здравствуйте, BulatZiganshin, Вы писали:
BZ>сейчас идёт хорошо заметный ФП hype, в связи с тем что это более высокоуровневый подход к программированию вообще и его хорошей приспособленностью к многопоточности в частности. я несколько лет назад предполагал, что 2010-е станут десятилетием ФП, но ошибся. так же, как и в прошлый раз, переход идёт в два этапа. на первом чистые ООП языки бкдкт сменены смешанными, включая F# и вероятно Скалу. и только на втором этапе, в следующем десятилетии, я думаю, программисты уже достаточно привыкнут к ФП чтобы перейти к чистым ФП языкам
Я думаю, что чистый ФП никогда не будет массовым. Искусственные ограничения никому не нужны, чтобы потом мужественно их преодолевать, выдумывая всякие монады и т.п.. За смешанными языками будущее.
M>>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память? G>А ты придумай скачала адекватную задачу для чего такое понадобится.
Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?
M>>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти? G>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.
Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору?
G>Ты себя загоняешь в рамки императивных алгоритмов, а потом пытаешься эти алгоритмы на чистые языки натянуть.
Я себя загоняю в рамки той архитектуры ЭВМ которой располагаю. И я хочу использовать эту архитектуру на всю катушку. А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа.
Здравствуйте, Nik_1, Вы писали:
N_>Ага, "к унитазу не подходи, утонешь". Жизнь вообще опастная штука. Они безопастны лишь за счет полного обрубания всех возможностей у программиста и помещения его в весьма аграниченную песочницу.
"аграниченная песочница" позволяет мне возвращать ссылку из метода и совершенно не париться над временем жизни объекта.
"аграниченная песочница" позволяет не использовать блокировки и свободно передавать объекты между потоками.
"аграниченная песочница" банально уменьшает затраты на отладку приложений.
Поменьше эмоций и придет просветление, настоящий джедай должен быть спокоен.
N_>Это как с вирусами бороться полностью отрубив сеть и выламав дисководы и юсб порты. От вирусов конечно хорошо защещен, тока вот нафиг не нужен такой комп потому что защита отрезала 99% его функционала.
Необоснованные аналогии как всегда идут лесом.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>>>>>А ты придумай скачала адекватную задачу для чего такое понадобится. M>>>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле? G>>>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.
M>>>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов? G>>Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету. M>Бгыг. Ну так покажи как их нету. На любом императивном языке этот алгоритм занимает полэкрана текста. А у immutable hashtable какой пенальти по памяти? Это при условии, что каждый элемент в массиве — один байт (ну 4 байта). И "пересоздавать отдельные блоки" это однозначно перебор. Каков размер блока? Хотя ты сейчас опять скажешь что у меня мышление императивное. Давай код уже.
Ну так приведи эти "полэкрана", напишем тебе аналог на чем-нить функциональном. А то я пока и задачу с трудом себе представляю.
G>>>>>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка. M>>>>>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору? G>>>>Индексная сортировка. M>>>Пример на любом ЯФП есть? G>>Вообще любая сортировка объектов в куче именно так работает, ибо перемещаются ссылки. M>Это я понял. Покажи функциональный код.
sort xs, что тебе еще надо?
M>>>>> А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа. G>>>>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно. M>>> Ну да. То есть для HPC и вообще для задач, где железо реально является ограничивающим фактором, функциональные языки пока не подходят. M>Ну то есть про HPC возражений нет?
Про HPC как раз есть, оно вполне успешно делается и на функциональных языках, ибо параллелить проще. А вот там где надо "пидарасить такты\байты" нужен именно инструмент, который позволяет это делать, без этого никуда. Но таких задач предельно мало и все меньше становится.
M>>>И что понимается под потенциалом программиста? G>>Способность писать корректный код с максимальной скоростью. M>А если код завершает работу уже после того, как был нужен результат (например прогноз погоды)?
Код, написанный на высокоуровневом языке завершает работу до того как будет дописан код на низкоуровневом
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, gandjustas, Вы писали: N_>>>Ага, "к унитазу не подходи, утонешь". Жизнь вообще опастная штука. Они безопастны лишь за счет полного обрубания всех возможностей у программиста и помещения его в весьма аграниченную песочницу. G>>"аграниченная песочница" позволяет мне возвращать ссылку из метода и совершенно не париться над временем жизни объекта. N_>смартпоинтер?
Ага, подсчет ссылок, блокировки при многопоточном доступе... и все это начинает в разы медленее "аграниченной песочницы" работать.
G>>"аграниченная песочница" позволяет не использовать блокировки и свободно передавать объекты между потоками. N_>смартпоинтер со встроенной потоковой защитой?
А как это поможет передавать объекты между потоками?
G>>"аграниченная песочница" банально уменьшает затраты на отладку приложений. N_>Так как ничего по существу тут не написал, додумаем сами : наверно тем что ущербный не поддерживает шаблоны
Кто не поддерживает? На F# есть compile-time duck typing, есть Template Haskell, есть Nemerle с макросами.
Здравствуйте, gandjustas, Вы писали: G>Ты до сих пор не понял что "все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости" — это связывание компилятора по рукам и ногам, потому что он не способен доказать ни одно утверждение в твоей программе.
Ой бида-бида!!
Здравствуйте, gandjustas, Вы писали:
G>Тупой вариант — не изменять значения в массиве, а хранить их в отдельном Map. Получим дополнительные log(n), где n — количество прошедших. G>Чуть более навороченный вариант — при превышении некоторого порога пересоздавать массив с новыми значениями. G>Я не особо спец в хаскеле, если время будет — напишу код.
Да ладно. С дополнительным log(n) я и сам напишу.
G>PS. Дополнительные log(n) — стандартная проблема при использовании immutable.
+1
Ну вот собссно и весь разговор. Просто есть задачи, где дополнительные log(n) неприемлемы. У меня подозрение, что многие программисты не переваривают ФП именно из-за того, что не в состоянии принять решение с таким пенальти.
Майкрософт недавно выпустил F#. Хочется услышать что думает народ о проникновении очередного языка от Майкрософт в индустрию. Есть C#, есть VB .NET. Нужен ли еще один? .NET-у уже 7-8 лет, но Java все равно популярнее. Интересно будут ли востребованны программисты со знанием этого языка и примерно когда? Если вообще этот язык кому-то (работодатели, имеется в виду) нужен... Ваши мнения и прогнозы на счет этого языка и работы с ним и у нас и в Штатах (особенно в финансовой индустрии), господа?
Сегодня да, под финансы для умных заказчиков. Завтра если не понядобятся, сократим или пусть переквалифицируются. Короче сегодня нужно одно, завтра другое, программисты — это приходящее (и уходящее) явление. Так что идите на F#, но если вдруг понадобится Python, то уж извините.
Здравствуйте, blumenkraft, Вы писали:
B>Сегодня да, под финансы для умных заказчиков. Завтра если не понядобятся, сократим или пусть переквалифицируются. Короче сегодня нужно одно, завтра другое, программисты — это приходящее (и уходящее) явление. Так что идите на F#, но если вдруг понадобится Python, то уж извините.
C F# переквалифицироваться на питон будет проще, чем наоборот.
Здравствуйте, Олег К., Вы писали:
ОК>Майкрософт недавно выпустил F#. Хочется услышать что думает народ о проникновении очередного языка от Майкрософт в индустрию. Есть C#, есть VB .NET. Нужен ли еще один? .NET-у уже 7-8 лет, но Java все равно популярнее. Интересно будут ли востребованны программисты со знанием этого языка и примерно когда? Если вообще этот язык кому-то (работодатели, имеется в виду) нужен... Ваши мнения и прогнозы на счет этого языка и работы с ним и у нас и в Штатах (особенно в финансовой индустрии), господа?
Сложно сказать, может на пике моды стать и вполне востребованным, может и незаметно пройти. Но по любому если человек смог освоить F# это показатель достаточно высокой квалификации, так что лишним это в резюме по моему не будет.
Здравствуйте, Олег К., Вы писали:
ОК>Что есть строчка в резюме без реальных проектов? Я этот язык могу добавить в свое резюме хоть сейчас.
Язык на старте, так что даже небольшой сделанный для себя или open source проект будет вполне нормальным.
ОК>Выучить-то можно. Только вопрос нужно ли. Меня интересует будет ли работа на Ф-шарпе или нет, кто что думает. Лично мое мнение таково: этот язык не нужен, по крайней мере на данный момент. Уже все написано и сделано. Майкрософту нужно генерировать разные идеи чтобы делать деньги. Виста провалилась. Большинство довольствуется Виндоусом ХР и продолжили бы сидеть на нем и дальше если бы Майкрософт не выкручивал руки. Вот я и думаю стоит ли тратить время чтобы серьезно изучать этот язык. Не ради простого интереса а ради того чтобы в будущем зарабатывать на нем деньги. Ну и оставаться competitive на рынке труда.
Только ради денег наверно не стоит, слишком рискованно.
Я понимаю что отдельные личности могут проталкивать новейшие технологии у себя в компаниях, но насколько массово это будет?
FD>F# — это реализация языка OCaml под .NET. Сам я на нем не писал, но один из моих знакомых (один из лучших программистов, которых я когда-либо встречал) очень хорошего мнения об этом языке и написал на нем программу типа Sendmail и ряд других. (Мэйлер был объемом 10000 строк кода на OCaml, аналогичная программа на C, по его мнению, была бы в 10 раз длиннее).
Ну а если сравнить с Си шарпом?
FD>Кстати, этот программист уже несколько лет занимается применением таких языков как OCaml и Haskell в банковской сфере и в настоящее время является начальником отдела Research & Development одного из европейских банков.
А можно узнать для каких таких задач они используют эти языки?
Здравствуйте, Олег К., Вы писали:
ОК>Ну а если сравнить с Си шарпом?
OCaml выше уровнем чем шарп, так что выигрыш в объеме кода будет, конечно меньше чем с си, но зависит от задач чем больше сложной логики тем больше выигрыш.
FD>>Кстати, этот программист уже несколько лет занимается применением таких языков как OCaml и Haskell в банковской сфере и в настоящее время является начальником отдела Research & Development одного из европейских банков. ОК>А можно узнать для каких таких задач они используют эти языки?
Его специализация — Quantitative Finance. Также он занимается следующими вещами: Financial mathematics, volatility theory, derivatives and structured products (interest rates, FX, equity, commodities), market risk management, quantitative software development, pay-off languages, high-frequency trading platforms. Он также преподает все это в различных европейских университетах.
Здравствуйте, Flying Dutchman, Вы писали:
FD>>>Кстати, этот программист уже несколько лет занимается применением таких языков как OCaml и Haskell в банковской сфере и в настоящее время является начальником отдела Research & Development одного из европейских банков. ОК>>А можно узнать для каких таких задач они используют эти языки?
FD>Его специализация — Quantitative Finance. Также он занимается следующими вещами: Financial mathematics, volatility theory, derivatives and structured products (interest rates, FX, equity, commodities), market risk management, quantitative software development, pay-off languages, high-frequency trading platforms. Он также преподает все это в различных европейских университетах.
Это ж просто набор красивых слов.
А есть информация как его компания/департамент использует новые языки например для "high-frequency trading platforms"?
Здравствуйте, Good Looking Man, Вы писали:
GLM>Здравствуйте, Flying Dutchman, Вы писали:
FD>>>>Кстати, этот программист уже несколько лет занимается применением таких языков как OCaml и Haskell в банковской сфере и в настоящее время является начальником отдела Research & Development одного из европейских банков. ОК>>>А можно узнать для каких таких задач они используют эти языки?
FD>>Его специализация — Quantitative Finance. Также он занимается следующими вещами: Financial mathematics, volatility theory, derivatives and structured products (interest rates, FX, equity, commodities), market risk management, quantitative software development, pay-off languages, high-frequency trading platforms. Он также преподает все это в различных европейских университетах.
GLM>Это ж просто набор красивых слов. GLM>А есть информация как его компания/департамент использует новые языки например для "high-frequency trading platforms"?
К сожалению, это все, что я знаю. Я с этим человеком давно не общался.
Здравствуйте, Good Looking Man, Вы писали:
GLM>Здравствуйте, Flying Dutchman, Вы писали:
FD>>>>Кстати, этот программист уже несколько лет занимается применением таких языков как OCaml и Haskell в банковской сфере и в настоящее время является начальником отдела Research & Development одного из европейских банков. ОК>>>А можно узнать для каких таких задач они используют эти языки?
FD>>Его специализация — Quantitative Finance. Также он занимается следующими вещами: Financial mathematics, volatility theory, derivatives and structured products (interest rates, FX, equity, commodities), market risk management, quantitative software development, pay-off languages, high-frequency trading platforms. Он также преподает все это в различных европейских университетах.
GLM>Это ж просто набор красивых слов. GLM>А есть информация как его компания/департамент использует новые языки например для "high-frequency trading platforms"?
В общих чертах — тут. Посмотрите Barclays, Deutsche, Credit Suisse, etc. Насколько мне известно Barclays были первыми кто до хаскелла додумался — теперь все дружно развлекаются одним и тем же. А вот тут дядька, автор HBC компилятора, рассказывает немного подробнее про то, как они хаскелл к трейдингу прикрутили (ближе к середине презентации).
Здравствуйте, blblx, Вы писали:
B>...А вот тут дядька, автор HBC компилятора, рассказывает немного подробнее про то, как они хаскелл к трейдингу прикрутили (ближе к середине презентации).
Сорри, с дядькой обманул немного — он в той презентации только про LLVM DSEL в основном рассказывает. Зато нашел ссылку с достаточно интересным описанием использования хаскелла в Barclays. Самое главное — авторы указываеют свои причины выбора функционального языка для данной области.
Здравствуйте, blblx, Вы писали:
GLM>>Это ж просто набор красивых слов. GLM>>А есть информация как его компания/департамент использует новые языки например для "high-frequency trading platforms"?
B>В общих чертах — тут. Посмотрите Barclays, Deutsche, Credit Suisse, etc. Насколько мне известно Barclays были первыми кто до хаскелла додумался — теперь все дружно развлекаются одним и тем же. А вот тут дядька, автор HBC компилятора, рассказывает немного подробнее про то, как они хаскелл к трейдингу прикрутили (ближе к середине презентации).
Спасибо за ссылку.
Но воющем правда, это пока сплошное баловство. В R&D отделах отдельные перцы балются, очки зарабатывают. В том же Барклайзе для квонтовых задач только используют. Это применение понятно. Хочется описывать модель не на языке типа C#, и уж не дай бог с++ . А хочется что-то более высокого уровня.
Но это никак не комерческий продукт, ни трейдинговая система, ни "high-frequency trading platforms".
Здравствуйте, Good Looking Man, Вы писали:
GLM>Здравствуйте, blblx, Вы писали:
GLM>>>Это ж просто набор красивых слов. GLM>>>А есть информация как его компания/департамент использует новые языки например для "high-frequency trading platforms"?
B>>В общих чертах — тут. Посмотрите Barclays, Deutsche, Credit Suisse, etc. Насколько мне известно Barclays были первыми кто до хаскелла додумался — теперь все дружно развлекаются одним и тем же. А вот тут дядька, автор HBC компилятора, рассказывает немного подробнее про то, как они хаскелл к трейдингу прикрутили (ближе к середине презентации).
GLM>Спасибо за ссылку.
GLM>Но воющем правда, это пока сплошное баловство. В R&D отделах отдельные перцы балются, очки зарабатывают. В том же Барклайзе для квонтовых задач только используют. Это применение понятно. Хочется описывать модель не на языке типа C#, и уж не дай бог с++ . А хочется что-то более высокого уровня. GLM>Но это никак не комерческий продукт, ни трейдинговая система, ни "high-frequency trading platforms".
Может вот это больше потянет на коммерческий продукт?
Здравствуйте, Курилка, Вы писали:
GLM>>Но воющем правда, это пока сплошное баловство. В R&D отделах отдельные перцы балются, очки зарабатывают. В том же Барклайзе для квонтовых задач только используют. Это применение понятно. Хочется описывать модель не на языке типа C#, и уж не дай бог с++ . А хочется что-то более высокого уровня.
Я бы не сказал, что это баловство — просходит весьма интенсивная интеграция с другими банковскими системами.
К>Может вот это больше потянет на коммерческий продукт?
Ну да. Интересно было бы в такой компании работать, хотя я к ФП никак не могу привыкнуть.
А в банках системы строятся очень похожие по возможностям.
GLM>А есть информация как его компания/департамент использует новые языки например для "high-frequency trading platforms"?
Было бы интересно, кстати, посмотреть как это используется, у меня постоянно спрашивают почему мы не использует какой-нибудь функциональный язык или DSL. Пока что для того что я видел непонятно чем функциональный язык будет лучше (для реальных production-стратегий, а не для демо). Опять же не очень понятно что насчет runtime для этого всего чтобы это не требовало бешеного количества железа (смотрю вот сейчас на народ, крутящий две тысячи стратегий).
Здравствуйте, kosmik, Вы писали:
K>Было бы интересно, кстати, посмотреть как это используется, у меня постоянно спрашивают почему мы не использует какой-нибудь функциональный язык или DSL. Пока что для того что я видел непонятно чем функциональный язык будет лучше (для реальных production-стратегий, а не для демо). Опять же не очень понятно что насчет runtime для этого всего чтобы это не требовало бешеного количества железа (смотрю вот сейчас на народ, крутящий две тысячи стратегий).
Насчет трейдинга не знаю, но OCaml достаточно шустрый (нативный код) и достаточно экономный по памяти (для языков с GC).
Здравствуйте, kosmik, Вы писали:
GLM>>А есть информация как его компания/департамент использует новые языки например для "high-frequency trading platforms"?
K>Было бы интересно, кстати, посмотреть как это используется, у меня постоянно спрашивают почему мы не использует какой-нибудь функциональный язык или DSL. Пока что для того что я видел непонятно чем функциональный язык будет лучше (для реальных production-стратегий, а не для демо). Опять же не очень понятно что насчет runtime для этого всего чтобы это не требовало бешеного количества железа (смотрю вот сейчас на народ, крутящий две тысячи стратегий).
На гриде все считается и особо никто не переживает о количестве железа.
ФЯ хорош тем, что позволяет в рантайме получить дерево выражения (AST), с
которым уже не обязательно оставаться в рантайме ФЯ. Например, при условии,
что набор функций для описания модели невелик, вполне можно сгенерировать более
эффективный нативный код на лету (т.е. как бы свой JIT для AST). При этом
сохраняется важное свойство такого подхода — на этапе создания/тестирования
cashflow-модель в любой момент вычислима в самом ФЯ.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, bl-blx, Вы писали:
BB>>ФЯ хорош тем, что позволяет в рантайме получить дерево выражения (AST)
AVK>Это слабо связано с ФЯ. Бывают функциональные языки без этой фичи, бывают нефункциональные с ней.
Да, безусловно так. Но это только один из факторов. Вкупе с остальными требованиями преимущество,
имхо, остается за ФЯ. Посмотрите (если еще не ) вот эту
ссылку про использование haskell в Barclays — не пожалеете. Авторы дают объяснение почему выбрали
haskell, что за этим стояло, какие требования. Я не большой сторонник ФЯ, но, тем не менее, не смог
с ходу придумать лучшей альтернативы с использованием не ФЯ. Вообще, было бы интересно обсудить эту тему.
O>Думаю лет 10 до массового внедрения есть, если оно вообще будет, подход спорный и не факт, что закрепится в индустрии.
Я примерно так и думаю. Поэтому создал эту тему.
Интересно чем Майкрософт руководствуется относительно Ф шарпа?
BB>ФЯ хорош тем, что позволяет в рантайме получить дерево выражения (AST), с BB>которым уже не обязательно оставаться в рантайме ФЯ. Например, при условии, BB>что набор функций для описания модели невелик, вполне можно сгенерировать более BB>эффективный нативный код на лету (т.е. как бы свой JIT для AST). При этом BB>сохраняется важное свойство такого подхода — на этапе создания/тестирования BB>cashflow-модель в любой момент вычислима в самом ФЯ.
Сдается мне, что успешный high-frequency trading базируется в-основном не на сложновычисляемых математических моделях, а на микроструктуре рынка.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Mazay, Вы писали: M>>Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы. G>Платформа у всех одна — x86 (x64)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Mazay, Вы писали:
M>>Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных. G>Явные побочные эффекты сильно упрощают композицию кода и отладку. G>От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.
M>>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого? G>Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС. G>Запрещено только ручное управление managed-памятью.
То есть если мне понадобилось вручную выровнять одну структуру данных, то весь код, который от неё зависит, становится неуправляемым?
M>>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования. G>Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков.
Во-первых я не про .NET, а про ФП. Во-вторых, дело не в "быстрее". Быстроту всегда можно обеспечить ручной аллокацией там где укажет профилировщик. Дело в локальности данных.
G>>>>>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым". G>>>>>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье. M>>>>Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи. G>>>Ну да, а примеры можно? M>>Я уже привёл: M>>
M>>Средства обеспечения локальности доступа к памяти (возможность размещать объекты в памяти с требуемым выравниванием и в требуемом порядке)
G>А причем тут функциональные языки? Это прерогатива компилятора и рантайма. В .NET для структуры это возможно, в другом языке можно будет сделать такое и для других объектов.
AFAIK с этим в .NET как-то можно работать, я, опять же, говорю про ФП. Только не надо расказывать сказки про офигенно умные компиляторы и рантаймы, которые сами знают как размещать объекты в памяти. Разумеется, они заточены под 90% стандартных кейсов, но зачем отбирать возможность самостоятельно управлять такими вещами? Делают же изменяемые переменные в ФЯП, так почему не дать возможность ручного управления памятью? Мне в этом смысле нравится подход Немерла и C++ — есть низкоуровневый язык, хорошо управляющий платформой (императивное подмножество типа С# и C) и есть высокоуровневые средства, реализованые на базе низкоуровневых. Вторые создаются и допиливаются с помощью первых и проблемы интреопа вообше нет.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Mazay, Вы писали:
M>>>Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных. G>>Явные побочные эффекты сильно упрощают композицию кода и отладку. G>>От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.
M>>>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого? G>>Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС. G>>Запрещено только ручное управление managed-памятью. M>То есть если мне понадобилось вручную выровнять одну структуру данных, то весь код, который от неё зависит, становится неуправляемым?
Конечно нет.
M>>>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования. G>>Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков. M>Во-первых я не про .NET, а про ФП.
А тема то про f#
M>Во-вторых, дело не в "быстрее". Быстроту всегда можно обеспечить ручной аллокацией там где укажет профилировщик. Дело в локальности данных.
Как раз сборщиком мусора типа .NETовского локальность данных получается идеальная. Блоки памяти в основном хипе выделяются строго последовательно.
И от языка это вообще говоря не зависит.
M>AFAIK с этим в .NET как-то можно работать, я, опять же, говорю про ФП.
Тема то про f#
Здравствуйте, gandjustas, Вы писали: G>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.
Это если ты пишешь прогу которой пользуется 1 человек, если же прогой пользуются милионы — то дешевле какраз прогеру потратить несколько лишних месяцев на разработку
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, gandjustas, Вы писали: G>>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.
N_>Это если ты пишешь прогу которой пользуется 1 человек, если же прогой пользуются милионы — то дешевле какраз прогеру потратить несколько лишних месяцев на разработку
Этот разговор уже миллионы раз поднимался. Если быстродействия для миллионов пользователей достаточно, то не нужно тратить эти самые месяцы. Но чтобы узнать это — надо сначала выпустить программу, а потом уже тратить время на оптимизацию. В этом как раз более высокоуровневые языки помогают.
Здравствуйте, gandjustas, Вы писали: G>Этот разговор уже миллионы раз поднимался. Если быстродействия для миллионов пользователей достаточно, то не нужно тратить эти самые месяцы. Но чтобы узнать это — надо сначала выпустить программу, а потом уже тратить время на оптимизацию. В этом как раз более высокоуровневые языки помогают.
Ага, только если программа написана на чемнить типа шарпа, то когда упрутся в то что производительность недостаточная, придется выкинуть все написанное и переписать программу с нуля на плюсах. Так что зарание подумать тоже не лишне
Здравствуйте, gandjustas, Вы писали:
M>>>>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память? G>>>А ты придумай скачала адекватную задачу для чего такое понадобится. M>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле? G>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.
Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов?
M>>>>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти? G>>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка. M>>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору? G>Индексная сортировка.
Пример на любом ЯФП есть?
G>>>Ты себя загоняешь в рамки императивных алгоритмов, а потом пытаешься эти алгоритмы на чистые языки натянуть. M>>Я себя загоняю в рамки той архитектуры ЭВМ которой располагаю. И я хочу использовать эту архитектуру на всю катушку. А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа. G>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно. Ну да. То есть для HPC и вообще для задач, где железо реально является ограничивающим фактором, функциональные языки пока не подходят.
И что понимается под потенциалом программиста?
Здравствуйте, gandjustas, Вы писали:
M>>>>Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных. G>>>Явные побочные эффекты сильно упрощают композицию кода и отладку. G>>>От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.
M>>>>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого? G>>>Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС. G>>>Запрещено только ручное управление managed-памятью. M>>То есть если мне понадобилось вручную выровнять одну структуру данных, то весь код, который от неё зависит, становится неуправляемым? G>Конечно нет.
Да ну? Вот мне нужен непрерывный кусок данных, в котором лежат выровненые на 64 байта подмассивы. Мне изредка надо менять, и часто читать данные из этих подмассивов. Крайне желательно, чтобы всё это хозйство кучно легло в 4 метра процессорного кэша и в 256 KB кэша ядра и не растягивалось в списки по всей памяти при модификации. Я могу гвоздями прибить такое поведение рантайма или остаётся только надеятся что рантайм сам до этого догадается? Я примерно представляю как это можно сделать в C#, но как это организовать в F# и при этом сохранить возможность работать со структурой в функциональном стиле?
M>>>>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования. G>>>Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков. M>>Во-первых я не про .NET, а про ФП. G>А тема то про f#
Ну а F# не функциональный что-ли? И вообще — не перебивай
M>>Во-вторых, дело не в "быстрее". Быстроту всегда можно обеспечить ручной аллокацией там где укажет профилировщик. Дело в локальности данных. G>Как раз сборщиком мусора типа .NETовского локальность данных получается идеальная. Блоки памяти в основном хипе выделяются строго последовательно. G>И от языка это вообще говоря не зависит.
Знать бы ещё, что такое идеальная локальность . Ну вот если я набиваю список в F#, у меня разве есть гарантии, что элементы будут лежать последовательно в памяти? А если я заменил последний элемент и продолжил набивать список?
M>>AFAIK с этим в .NET как-то можно работать, я, опять же, говорю про ФП. G>Тема то про f#
Как мне в F# вручную задать размещение объектов "в памяти с требуемым выравниванием и в требуемом порядке" (3-й раз уже повторяю)?
Здравствуйте, Mazay, Вы писали:
M>Как мне в F# вручную задать размещение объектов "в памяти с требуемым выравниванием и в требуемом порядке" (3-й раз уже повторяю)?
module CInterop =
[<Struct; StructLayout(LayoutKind.Sequential)>]
type Complex =
val mutable re:double
val mutable im:double
new(r,i) = { re = r; im = i; }
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>>>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память? G>>>>А ты придумай скачала адекватную задачу для чего такое понадобится. M>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле? G>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.
M>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов?
Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету.
M>>>>>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти? G>>>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка. M>>>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору? G>>Индексная сортировка. M>Пример на любом ЯФП есть?
Вообще любая сортировка объектов в куче именно так работает, ибо перемещаются ссылки.
G>>>>Ты себя загоняешь в рамки императивных алгоритмов, а потом пытаешься эти алгоритмы на чистые языки натянуть. M>>>Я себя загоняю в рамки той архитектуры ЭВМ которой располагаю. И я хочу использовать эту архитектуру на всю катушку. А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа. G>>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно. M> Ну да. То есть для HPC и вообще для задач, где железо реально является ограничивающим фактором, функциональные языки пока не подходят. M>И что понимается под потенциалом программиста?
Способность писать корректный код с максимальной скоростью.
Здравствуйте, gandjustas, Вы писали: G>"Высокоуровневый С++" оказывается медленнее (часто) G>и гораздо менее надежным (всегда) того же .NET или java.
Ага, "к унитазу не подходи, утонешь". Жизнь вообще опастная штука. Они безопастны лишь за счет полного обрубания всех возможностей у программиста и помещения его в весьма аграниченную песочницу. Это как с вирусами бороться полностью отрубив сеть и выламав дисководы и юсб порты. От вирусов конечно хорошо защещен, тока вот нафиг не нужен такой комп потому что защита отрезала 99% его функционала.
G>Холивар на эту тему уже был в КСВ, повторяться не будем.
Да да, помним, плюсы там раз в 10 всех обогнали, это повашиму "медленнее (часто) " G>Ты до сих пор не понял что "все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости" это где они в шарпе открыты?
Здравствуйте, gandjustas, Вы писали:
G>>>>>А ты придумай скачала адекватную задачу для чего такое понадобится. M>>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле? G>>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.
M>>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов? G>Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету.
Бгыг. Ну так покажи как их нету. На любом императивном языке этот алгоритм занимает полэкрана текста. А у immutable hashtable какой пенальти по памяти? Это при условии, что каждый элемент в массиве — один байт (ну 4 байта). И "пересоздавать отдельные блоки" это однозначно перебор. Каков размер блока? Хотя ты сейчас опять скажешь что у меня мышление императивное. Давай код уже.
G>>>>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка. M>>>>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору? G>>>Индексная сортировка. M>>Пример на любом ЯФП есть? G>Вообще любая сортировка объектов в куче именно так работает, ибо перемещаются ссылки.
Это я понял. Покажи функциональный код.
M>>>> А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа. G>>>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно. M>> Ну да. То есть для HPC и вообще для задач, где железо реально является ограничивающим фактором, функциональные языки пока не подходят.
Ну то есть про HPC возражений нет?
M>>И что понимается под потенциалом программиста? G>Способность писать корректный код с максимальной скоростью.
А если код завершает работу уже после того, как был нужен результат (например прогноз погоды)?
Здравствуйте, gandjustas, Вы писали: N_>>Ага, "к унитазу не подходи, утонешь". Жизнь вообще опастная штука. Они безопастны лишь за счет полного обрубания всех возможностей у программиста и помещения его в весьма аграниченную песочницу. G>"аграниченная песочница" позволяет мне возвращать ссылку из метода и совершенно не париться над временем жизни объекта.
смартпоинтер? G>"аграниченная песочница" позволяет не использовать блокировки и свободно передавать объекты между потоками.
смартпоинтер со встроенной потоковой защитой? G>"аграниченная песочница" банально уменьшает затраты на отладку приложений.
Так как ничего по существу тут не написал, додумаем сами : наверно тем что ущербный не поддерживает шаблоны
G>Поменьше эмоций и придет просветление, настоящий джедай должен быть спокоен. G>Необоснованные аналогии как всегда идут лесом.
А по существу опять таки есть что сказать? Иль тролим?
Здравствуйте, gandjustas, Вы писали:
G>>>>>>>А ты придумай скачала адекватную задачу для чего такое понадобится. M>>>>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле? G>>>>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз. M>>>>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов? G>>>Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету. M>>Бгыг. Ну так покажи как их нету. На любом императивном языке этот алгоритм занимает полэкрана текста. А у immutable hashtable какой пенальти по памяти? Это при условии, что каждый элемент в массиве — один байт (ну 4 байта). И "пересоздавать отдельные блоки" это однозначно перебор. Каков размер блока? Хотя ты сейчас опять скажешь что у меня мышление императивное. Давай код уже. G>Ну так приведи эти "полэкрана", напишем тебе аналог на чем-нить функциональном. А то я пока и задачу с трудом себе представляю.
Ладно, чуть больше чем полэкрана, но всё равно тривиально.
#include <cmath>
#include <iostream>
#include <boost/array.hpp>
#include <boost/random.hpp>
using std::cout;
using std::endl;
using boost::array;
const int N = 40; // field sizeconst double J = 0.1; //interaction energyconst double beta = 6; // try values 6, 4, 2. Higher value corresponds to lower temperature.
boost::array<boost::array<char, N>, N > S;
boost::minstd_rand generator(time(0));
boost::uniform_01<> uni_1;
boost::uniform_int<> uni_N(0,N-1);
int cycl(int x) // cyclyc boundary conditions
{
if (x < 0)
return x + N;
if (x >= N)
return x - N;
return x;
}
double energy(int x, int y) //evaluate energy of one element
{
int s = S[cycl(x-1)][y] + S[cycl(x+1)][y]
+ S[x][cycl(y-1)] + S[x][cycl(y+1)];
return (-J) * s * S[x][y];
}
void init() // random init S
{
for (int x = 0; x < N; ++x)
{
for (int y = 0; y < N; ++y)
{
S[x][y] = (uni_1(generator) > 0.5) ? -1 : 1;
}
}
}
bool check(double dE) // Gibbs distribution
{
return exp(-dE*beta) > uni_1(generator);
}
void print()
{
for (int x = 0; x < N; ++x)
{
for (int y = 0; y < N; ++y)
{
cout<< ((S[x][y] > 0) ? '|' : '-') << ' ';
}
cout<<endl;
}
}
int main()
{
init();
print(); // initial Sfor (int i = 0 ; i < 999999; ++i)
{
int x = uni_N(generator);
int y = uni_N(generator);
double E_o = energy(x, y); // old Energy
S[x][y] = - S[x][y]; // trial stepdouble E_n = energy(x, y); // new Energyif (!check(E_n-E_o)) // accept or decline trial step according to Gibbs
{
S[x][y] = - S[x][y]; // trial step declined, rollback the change
}
else
{
// trial step accepted, keep the change
}
}
cout<<endl;
print(); // equlibrium Sreturn 0;
}
Вот была бы возможность использовать нормальный функциональный язык вместо init() и print() а остальное можно оставить как есть А так получается на Хаскеле не напишешь (?), а на плюсах только с boost::lambda извращаться.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>>>>>>>А ты придумай скачала адекватную задачу для чего такое понадобится. M>>>>>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле? G>>>>>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз. M>>>>>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов? G>>>>Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету. M>>>Бгыг. Ну так покажи как их нету. На любом императивном языке этот алгоритм занимает полэкрана текста. А у immutable hashtable какой пенальти по памяти? Это при условии, что каждый элемент в массиве — один байт (ну 4 байта). И "пересоздавать отдельные блоки" это однозначно перебор. Каков размер блока? Хотя ты сейчас опять скажешь что у меня мышление императивное. Давай код уже. G>>Ну так приведи эти "полэкрана", напишем тебе аналог на чем-нить функциональном. А то я пока и задачу с трудом себе представляю.
M>Ладно, чуть больше чем полэкрана, но всё равно тривиально. M>
M>//skipped
M>
Тупой вариант — не изменять значения в массиве, а хранить их в отдельном Map. Получим дополнительные log(n), где n — количество прошедших.
Чуть более навороченный вариант — при превышении некоторого порога пересоздавать массив с новыми значениями.
Я не особо спец в хаскеле, если время будет — напишу код.
PS. Дополнительные log(n) — стандартная проблема при использовании immutable.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Тупой вариант — не изменять значения в массиве, а хранить их в отдельном Map. Получим дополнительные log(n), где n — количество прошедших. G>>Чуть более навороченный вариант — при превышении некоторого порога пересоздавать массив с новыми значениями. G>>Я не особо спец в хаскеле, если время будет — напишу код. M>Да ладно. С дополнительным log(n) я и сам напишу.
G>>PS. Дополнительные log(n) — стандартная проблема при использовании immutable. M>+1
M>Ну вот собссно и весь разговор. Просто есть задачи, где дополнительные log(n) неприемлемы. У меня подозрение, что многие программисты не переваривают ФП именно из-за того, что не в состоянии принять решение с таким пенальти.
Ну тут избрали неверный подход. Если тупо императивный алгоритм переписать с immutable объектами, то он получит дополнительный log(n), если писать алгоритм изначально в функциональном подходе, то можно не только не получать дополнительные множители, но и ускорить программу за счет ленивости, сократив при этом текст программы, к тому же получить простоту распараллеливания.
Здравствуйте, Mazay, Вы писали:
M>Вот была бы возможность использовать нормальный функциональный язык вместо init() и print() а остальное можно оставить как есть А так получается на Хаскеле не напишешь (?), а на плюсах только с boost::lambda извращаться.
Ну на том же F# или OCaml можно почти в один — один (императивно) переписать, но с лямбдами
Хотя на OCaml в свете новых батарейных тенденций лучше чуть перевернуть логику и оформить массив в виде перечисления
(http://thelema.github.com/AAA-batteries/hdoc/BatEnum.html) с которым уже спокойно работать привычными функциональными
фолдами и мапами.
Да и на C++ на том же VC 2010 (или gcc 4) уже можно и с почти человеческим лямбдами все соорудить.
Конечно для подобных задач D от digitalmars был бы очень хорош, жаль застрял в разработке.
Здравствуйте, samius, Вы писали:
M>>Как мне в F# вручную задать размещение объектов "в памяти с требуемым выравниванием и в требуемом порядке" (3-й раз уже повторяю)? S>
S>module CInterop =
S> [<Struct; StructLayout(LayoutKind.Sequential)>]
S> type Complex =
S> val mutable re:double
S> val mutable im:double
S> new(r,i) = { re = r; im = i; }
S>
Здравствуйте, Олег К., Вы писали:
ОК>Ваши мнения и прогнозы на счет этого языка и работы с ним и у нас и в Штатах (особенно в финансовой индустрии), господа?
Есть кое-какие подвижки в Сити во Front Office IB IT, но они в основном связаны с личными факторами. В частности, в CS ушел Лука Болонезе и туда же иногда Дон Сайм иногда заглядывает, и в Barclays кое-какое движение есть. Отсюда есть определенный, небольшой спрос на людей которые хорошо в финансах разбираются и смогут F# к WPF/WinForms быстренько прикрутить для быстрой разработки прототипа, но в основном это пока всего лишь забава для квантов, которым Математика и R наскучили.
Здравствуйте, Олег К., Вы писали:
ОК>Майкрософт недавно выпустил F#. Хочется услышать что думает народ о проникновении очередного языка от Майкрософт в индустрию.
Здравствуйте, Darkprotoss, Вы писали:
D>>Вопрос с другой стороны баррикады — а есть ли перспектива у Скалы?
D>Даже технически скала более правильна. А уж верить в маркетинговую силу майкрософт — сейчас уже никто не верит... D>http://www.developer.com/article.php/3883051
Автор статьи похоже не писал ничего кроме "hello world" на F# и вообще языках семейства ML. Ну и приводить множественное
наследование и миксины как преимущество при сравнении функциональных подмножеств языков это уже вообще за гранью.
Здравствуйте, Mna, Вы писали: Mna>Изменилось. F# стал опенсорсным, на опеннете было Mna>Изменилось. F# 2 стал опенсорсным, на опеннете было
и скала 2.8.x вышла
Здравствуйте, Wolverrum, Вы писали:
Mna>>Изменилось. F# стал опенсорсным, на опеннете было Mna>>Изменилось. F# 2 стал опенсорсным, на опеннете было W>и скала 2.8.x вышла
Помогло?
Есть с++, который весьма высокоуровневый, но в все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости.
. Ну вот если я набиваю список в F#, у меня разве есть гарантии, что элементы будут лежать последовательно в памяти? А если я заменил последний элемент и продолжил набивать список?
это где они в шарпе открыты?
