и сделали repl для c#

а для VB есть репл?

нет вроде

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

https://benchmarksgame.alioth.debian.org/u64q/fsharp.html

так это многопоточный бенчмарк

а речь была про "производительность однопоточных приложений"

но производительность у окамла не особо хорошая, конечно, но сносная

тем более ему теперь и оптимизатор сделали еще

подскажите пожалуйста. Вот есть библиотека создающая чарты: https://fslab.org/FSharp.Charting/index.html Так указаны примеры различных графиков. Но не написано как и куда их выводить. Подскажите, как и куда это можно сделать?

и что будет проще? Быть может гуи как-то создать, или в .png файл как-то можно

и что будет проще? Быть может гуи как-то создать, или в .png файл как-то можно

сам себе отвечу. Если вкратце: let chart = [ for row in msft.Rows -> row.Date, row.Open ] |> Chart.FastLine Chart.Show chart

после этого появится окошко с графиком. Но это я если честно, просто по-наитию нашел.

все этой же библиотекой для графиков пользуются?

Много кто пользуется http://muehlhaus.github.io/FSharp.Plotly .

Но в Charting можно графики реактивно генерить, если вдруг что-то в реальном времени делаешь. С Plotly если и можно, то надо повозиться.

а речь была про "производительность однопоточных приложений"

разница то какая?

в тех исходниках которые там есть обычно никаких наворотов нет

разница то какая?

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

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

ты веришь что если шарп и камл запустить в один поток , то чтото существенно изменится?

кроме учеличения времени в 4 раза

кроме учеличения времени в 4 раза

ну у одного время в четыре раза увеличится а у другого нет

но понятно что в таком вот запотимизированном коде имплементация индустриального качества победит наколеночную окамловскую

Много кто пользуется http://muehlhaus.github.io/FSharp.Plotly .

о, наверное то что надо. Спасибо)

про то что у окамла хорошая производительность не я говорил, сам так не считаю

У нас на прошлой работе был окамл

Я бы не сказал, что там что-то сверхъестественное в плане производительности

Цифры, к сожалению, дать не могу

но вот в сколько нибудь высокоуровневом коде не так вручную замученном уже может окамл победить, у него теперь оптимизатор есть, в отличие от F#

имеется в виду оптимизатор, который как-то оптимизирует ФП код, естественно коровский джит тут никак не поможет, если ему придется иметь дело со всем этим адским выхлопом F#-ного компилятора для неоптимизированного вручную кода

ну у одного время в четыре раза увеличится а у другого нет

с чего бы? там загрузка камней указана. в обоих случаях увеличится

в том и дело что указана, например окамл 0% 1% 0% 100% F# 98% 100% 99% 98%

в том и дело что указана, например окамл 0% 1% 0% 100% F# 98% 100% 99% 98%

где?

мандельборт чтоли?

7 * 4 = 28 против 55

это mandelbrot. некоторые там и для окамла распараллелены, но там разделяемой памяти нет, так что понятно что там не в 4 раза производительность упадет

но вот в сколько нибудь высокоуровневом коде не так вручную замученном уже может окамл победить, у него теперь оптимизатор есть, в отличие от F#

Да, в F# полагаются на людей, которые пилят рантайм и жит.

но рантайм и джит пилят не для ФЯ так что полагаться на него можно только если писать как на фортране, а не как на эмеле

но рантайм и джит пилят не для ФЯ так что полагаться на него можно только если писать как на фортране, а не как на эмеле

а для чего ж его пилят? для фя и пилят если никто не заметил

а для чего ж его пилят? для фя и пилят если никто не заметил

ФЯ язык под который его пилят только со второй версии стал, да и то, пилильщики джита и рантайма не сказать что это заметили

ФЯ рантаймы, например имеют оптимизации под замыкания и карринг, как первое энкодилось в C# и F# а второе в F# думаю, объяснять не надо, это и так все декомпайлерами смотрели

в этом смысле JVM и то больше под ФЯ оптимизирована

ФЯ рантаймы, например имеют оптимизации под замыкания и карринг, как первое энкодилось в C# и F# а второе в F# думаю, объяснять не надо, это и так все декомпайлерами смотрели

ф классы рожает на каждый чих. а вот в с чет не посмотрел. надо глянуть кстати

F# рожает классы на каждое замыкание. C# на кадый метод, где есть замыкания. Результат - F# захватывает только нужные переменный, а C# все, которые в хоть одно замыкание входили. Отсюда и Resharper предупреждение о impicit capture. В принципе можно теперь оптимизировать при компиляции через таплы, но народу у нас этим мало занимаются.

https://twitter.com/lenadroid/status/951982166946201601

А оптимизация ФП проводится именно на этапе компиляции, а не как не JIT. У последнего слишком мало времени и информации.

JVM оптимизирован под ФП от слова никак. Scala - да. Java - в некоторых местах. А JVM - никак. Хвостовая рекурсия, между прочим, разворачиваться должна компилятором. А у нас для ленивых - JIT разворачивает. Простите чья машина хоть что то умеет. (О дженериках я промолчу, пожалуй)

ФП рантаймы - они для конкретного языка. И оптимизация у них для конкретного языка. А VM типа JVM или .NET - они компьютер виртуализируют. Не среду исполнения языка. А операционку и железо. Так что ждать чудес от Runtime не приходится.

a знает кто как правильно такое написать на фшарпе use(dosmth()) { //somecode } я просто боюсь что если написать use unused = dosmth() то это вообще джит соптимизирует и удалит, а этого допустить нельзя

не удалит

не соптимизит. все равно в try catch разворачивается с переменной

ок, спасибо)

А оптимизация ФП проводится именно на этапе компиляции, а не как не JIT. У последнего слишком мало времени и информации.

ну у джита достаточно информации, но у фя которые как-то оптимизируют именно фп код типа ghc и mltonа джитов нет, там особо выбирать не приходится.

JVM оптимизирован под ФП от слова никак. Scala - да. Java - в некоторых местах. А JVM - никак. Хвостовая рекурсия, между прочим, разворачиваться должна компилятором. А у нас для ленивых - JIT разворачивает. Простите чья машина хоть что то умеет. (О дженериках я промолчу, пожалуй)

в жвм с 1.8 поддержка для лямбд, там они не просто в классы энкодятся. Хвостовая рекурсия да, в JVM хуже поддерживается, чем в CLR но и там, когда я писал еще на F# она была тормозная из-за безопасности. Ну и хвостовой рекрусии мало, с рантаймах которые под ФЯ разрабатывались вроде sml/nj и ghc используется стек в куче, так что не только хвостовая рекурсия рабочая Ну и CLR-ных дженериков для ФЯ мало, так что тут никакого преимущества у CLR перед JVM, если нормальный ФЯ делать все равно придется делать дженерики на универсальном представлении как в JVM окамле и гхц

В JVM дженериков нет вообще. Только метаданные, если я правильно помню. У CLR есть реально одна проблема - отсутствие поддержки HKT. Остальное можно решить компилятором. А сравнивать CLR с Глазго вообще нечестно. Они о т нас убежали лет на 10. От всех почти. Даже теория только только становится понятна хотя бы сколько нибудь определяющему количеству программистов, и то не до конца. А CLR - это прежде всего бизнес. Пока МЫ не переучимся, никто соломку бесплатно стелить не будет. А по моим соображениям - ФП уйдет в массы лет через 5, во всяком случае серьезный ФП, а не базовый.

Еще одна проблема - нет поддержки или типов

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

Сейчас есть все инструменты, даже прямое защищенное обращение к памяти, вопрос в сложности компилятора

может-то может, но на выскокоуровневой ВМ особо с собственным стеком в куче не разгуляешься, тормозить будет

При прямом ремапе можно. В конце концов процессор все равно работает императивно.

а сравнивать с ghc нормально, там просто полтора человека поработали над оптимизатором в свое время, ничего сверхестественного нет, никакого рокетсайенса, просто мало кто из имплементаторов ФЯ и старается. В том же окамле вон 20 лет доказывали что оптимизатор не нужен, а потом все-таки flambda стали делать

Если бы ФП ускоритель был реализован на железе - тогда да. Лисп машины к сожалению загнулись..

Здесь я не компетентен, не могу оценить уровень усилий. Для меня это все же пилотаж, возможный, но не тривиальный.

да на существующем железе можно сносно работающее рантаймы для ФЯ делать, просто над ФЯ вообще мало людей работает, проще существующий рантайм использовать, но вот всякие клры и жвмы для ФЯ адский ад

А с OCAML: язык не поддерживает конкуренцию в много потоков (не берем Concurrent OCAML). Сейчас это смерть

да, ну так там вообще рнтайм на коленке сделали в 90 со всеми этими ужасами с тегами и ограничением на длину массивов, о каком уж там SMP речь

рантаймы делать тяжело, когда над языком полтора человека фултайм работает

Однако я не знаю ничего более продвинутого в смыслке конкуренции, чем Concurrent OCAML/ По возможностям и проработке

У нас вон в телеграме больше 100 человек. Представим, что есть даже деньги. Возможно ли с этим нашим уровнем сделать что то значимое (средним уровнем)

не так давно читал оценку Арлекина сколько они потратили на рантайм MPS для RIP/лиспворкс/млворкс/дилана - 30 человеколет

Надо расти самим и растить других. Иначе не получится. Или все упадут на уровень Go lang.

рантайм делать это не компилятор по книжке по вечерам за полгода как пурскрипт какой-нибудь

для ghc рантайм новый в 98 году начали делать, до более менее юзабельного состояния с SMP, сносным ГЦ и ио менеджером его только году в 11 - 12 довели

Значимый компилятор написать то же не нетривиальная задача. Особенно оптимизирующий. Такой о каком мечтается (со Старым Новым годом всех кстати). С гигиеническими макросами, HKT, implicit suggestions + среда разработки + инструментарий отладки. Я бы наверное сдулся бы раньше результата в одиночку.

На 3 уровне оптимизации он не очень сильно уступает C++, а сколько людей пишет на Haskel? хотя синтаксически он в сотни раз проще

Подскажите, в VS в интерактивном режиме F# почему-то > printf __SOURCE_DIRECTORY__ ;; C:\Users\n06ri\AppData\Local\Tempval it : unit = () А должен быть, как я понимаю, адрес открытого проекта. Разве нет?

Однако я не знаю ничего более продвинутого в смыслке конкуренции, чем Concurrent OCAML/ По возможностям и проработке

эрланг?

Подскажите, в VS в интерактивном режиме F# почему-то > printf __SOURCE_DIRECTORY__ ;; C:\Users\n06ri\AppData\Local\Tempval it : unit = () А должен быть, как я понимаю, адрес открытого проекта. Разве нет?

Не должен. Почему ты считаешь, что должен?

Не должен. Почему ты считаешь, что должен?

Ну просто казалось что логично было бы. Но если не должен, то ладно.

В JVM дженериков нет вообще. Только метаданные, если я правильно помню. У CLR есть реально одна проблема - отсутствие поддержки HKT. Остальное можно решить компилятором. А сравнивать CLR с Глазго вообще нечестно. Они о т нас убежали лет на 10. От всех почти. Даже теория только только становится понятна хотя бы сколько нибудь определяющему количеству программистов, и то не до конца. А CLR - это прежде всего бизнес. Пока МЫ не переучимся, никто соломку бесплатно стелить не будет. А по моим соображениям - ФП уйдет в массы лет через 5, во всяком случае серьезный ФП, а не базовый.

да ты прав, нет дженериков. только недавно лекции смотрел там говорится что в рантайме list<string> list<integer> это одно

вообще в этом чате имеет смысл задавать вопросы по языку?

или лучше на stackoverflow?

вообще в этом чате имеет смысл задавать вопросы по языку?

попробуй что тебе мешает

Ну просто казалось что логично было бы. Но если не должен, то ладно.

Это путь к текущему файлу с исходниками. Поскольку у интерактивного репла нету такого файла, то и путь показывается какой-то левый.

вообще в этом чате имеет смысл задавать вопросы по языку?

Да, конечно, имеет смысл.

На SO я обычно спрашиваю что-то более комплексное, что в чате в двух словах не объяснишь :)

попробуй что тебе мешает

ну просто мало ли)

> gazp.Headers;; val it : string [] option = Some [|"<TICKER>"; "<PER>"; "<DATE>"; "<TIME>"; "<CLOSE>"|] > match gazp.Headers with | Some i -> i |> Array.map (fun x -> printfn "head %A"x) | None -> printf "NONE!!!" ;; | None -> printf "NONE!!!" ---------------------^^^^^^^^^ stdin(8,22): error FS0001: This expression was expected to have type 'unit []' but here has type 'unit'

> gazp.Headers;; val it : string [] option = Some [|"<TICKER>"; "<PER>"; "<DATE>"; "<TIME>"; "<CLOSE>"|] > match gazp.Headers with | Some i -> i |> Array.map (fun x -> printfn "head %A"x) | None -> printf "NONE!!!" ;; | None -> printf "NONE!!!" ---------------------^^^^^^^^^ stdin(8,22): error FS0001: This expression was expected to have type 'unit []' but here has type 'unit'

Замени там Array.map на Array.iter

кто нибудь вообще под линуксом сидит ? я попробовал rider и чет как то после idea слабенько смотрится

Я эпизодически сижу под линуксом, но там обычно не программирую на F#, а только запускаю F#-софт.

На винде лично мне Rider кажется вполне ок после IDEA и Visual Studio.

На винде лично мне Rider кажется вполне ок после IDEA и Visual Studio.

ну я на винде не сижу, но чет он банально мне ничего не исправил ещё ток жалуется и все)

А что он должен был «исправить»?

ну выравнивание как минимум я думаю это вполне та задача

Замени там Array.map на Array.iter

Ага, действительно полетело) Подскажи пожалуйста, дело в том что iter возвращает unit, который является аналогом Null в других языках, а map возвращает обработанный массив, да?