фронт-енд - это уже не для души. По крайней мере для меня

Но я к чему - не стоит критиковать ЯП за возможность отстрелить себе ногу в контексте разработки для души

Потому что этот параметр актуален для больших энтерпрайзных проектов

Да и вообще не стоит критиковать ЯП, если это не php

а ты пробовал писать на каком-нибудь typescript или flow?

Да и вообще не стоит критиковать ЯП, если это не php

?

Я на работе пишу на typescript only

и норм на самом деле

а ты пробовал писать на каком-нибудь typescript или flow?

а ты

мне больше тех же шарпов нравится

flow тоже круть

Давайте с JS в тематические чаты, пожалуйста.

Да, пардон, скатились во флейм

Спасибо.

Пытаюсь нагуглить сравнение F# с OCaml (в плане фич), ничего норм найти не могу. Может видел кто?

Пытаюсь нагуглить сравнение F# с OCaml (в плане фич), ничего норм найти не могу. Может видел кто?

Спрашивай, что тебя интересует.

Или можешь спросить в @reasonml_ru.

Так как раз и интересует овервью. Думаю, на что лучше свои временнЫе ресурсы потратить

Так как раз и интересует овервью. Думаю, на что лучше свои временнЫе ресурсы потратить

Какие аспекты важны? У OCaml система типов интереснее.

Но плохая история с Windows.

Производительность коробочных структур данных

И их многообразие

Количество синтаксического сахара - вот ещё что важно

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

Ещё мне бы помогли явные минусы одного ЯПа по сравнению с другим

Количество синтаксического сахара - вот ещё что важно

По сравнению с F#, наверное, сахара маловато. Но зато есть распространенная система для расширения синтаксиса.

Ещё мне бы помогли явные минусы одного ЯПа по сравнению с другим

Ну, слушай, это уже большая работа, такое сравнение сделать. :)

По сравнению с F#, наверное, сахара маловато. Но зато есть распространенная система для расширения синтаксиса.

Я ведь правильно понимаю, что F# разрабатывали глядя в сторону OCaml? Я сейчас читаю второй, и покка не вижу отличий, кроме labeled arguments

Я ведь правильно понимаю, что F# разрабатывали глядя в сторону OCaml? Я сейчас читаю второй, и покка не вижу отличий, кроме labeled arguments

Нет, неправильно.

?

F# очень рано пошел своим путём.

От OCaml там только самый базовый ML, без модулей.

в F# ни модулей окамловских ни объектов, т.е. ничего именно от ocaml, можно сказать что и тот и другой это caml light с расширениями

Всем снова привет) Решил вот попробовать f# и сразу вопрос- пошел по пути наименьшего сопротивления и поставил себе visual studio. И там указал f# как дополнительный компонент. Все очень клево- Проекты компилируются, запускаются. Но вот я смотрю https://fsharpforfunandprofit.com/installing-and-using/ , там в конце приведет пример f# как скриптового языка. Но как я понимаю для этого надо установить отдельные инструменты. Вообще это хорошая идея использовать интерпретатор?

Ясно, спасибо ). Видимо они мне кажутся похожими по той же причине, что и китайцы. Потому что я не шарю)

а caml light это совсем небольшой язык с самыми базовыми фичами

Всем снова привет) Решил вот попробовать f# и сразу вопрос- пошел по пути наименьшего сопротивления и поставил себе visual studio. И там указал f# как дополнительный компонент. Все очень клево- Проекты компилируются, запускаются. Но вот я смотрю https://fsharpforfunandprofit.com/installing-and-using/ , там в конце приведет пример f# как скриптового языка. Но как я понимаю для этого надо установить отдельные инструменты. Вообще это хорошая идея использовать интерпретатор?

Нормальная идея. На целевую систему нужно поставлять fsi.exe (или fsharpi для линукса, если не путаю), а дальше всё как обычно.

там не интерпретатор, эфшарповый репл все компилирует

там не интерпретатор, эфшарповый репл все компилирует

а, то есть просто компиляция перед исполнением?

Ну да, типа того.

не перед, там же jit

Однако, я не вижу, как внешний наблюдатель в данном случае может различить компиляцию и интерпретацию.

какая-то часть компиляции перед, остальное во время

не перед, там же jit

Тогда уж и перед, и после :)

Однако, я не вижу, как внешний наблюдатель в данном случае может различить компиляцию и интерпретацию.

по скорости

по скорости

Сомнительно!

просто как вы работаете с f#, компилируете каждый раз?

просто как вы работаете с f#, компилируете каждый раз?

Да.

разница по скорости репла с скомпилированным кодом для всяких окамлов и хаскелей очевидна

по скорости

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

Я не вижу решения.

sml/nj репл тоже компилирует, а не интерпретирует

Более того, я не вижу решения, если ты не можешь её в обоих режимах прогнать.

так можешь же

В конце концов, JIT в дотнете необязателен, так что и про F# нельзя говорить, что он всегда компилируется JIT'ом.

Сегодня есть весь спектр развлечений: и AOT-компиляторы, и, наоборот, интерпретаторы байт-кода.

мне производительность не важна. Важно удобство. Я просто смотрю что проект компилируется в папку, а потом еще в папку, а потом еще в папку. В итоге с демо проектом получается масло маслянное в виде ConsoleApplication1\bin\Debug\ConsoleApplication1.exe

Слушайте, а в fsi можно как-то засунуть многофайловый проект?

написать скрипт который модули грузит

просто привык как с js- что вот он js-файлик, а рядом файлик который прочесть надо. А запускаешь просто node %имя_скрипта%

просто привык как с js- что вот он js-файлик, а рядом файлик который прочесть надо. А запускаешь просто node %имя_скрипта%

А я, наоборот, привык, что в JS обязательно компилировать и таскать с собой огромный node_modules :)

просто привык как с js- что вот он js-файлик, а рядом файлик который прочесть надо. А запускаешь просто node %имя_скрипта%

fsharpi %имя_скрипта% (для линукс)

написать скрипт который модули грузит

А как он это будет делать, например?

Мне просто не совсем ясен механизм. Там какой-нибудь eval есть, или придётся руками в памяти компилять сборки через сервис компилятора, и из памяти же их грузить?

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

А я, наоборот, привык, что в JS обязательно компилировать и таскать с собой огромный node_modules :)

это для фронтенда. Для бэка сборка проекта не нужна

это для фронтенда. Для бэка сборка проекта не нужна

Не могу с вами согласиться.

Но это уже оффтоп.

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

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

А что такое «модуль»? Другой fsx-файл?

Тогда больше вопросов не имею, понятно как это будет работать.

обычный fs

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

репл в F# больше для галочки

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

А что можно было бы улучшить?

да поиск и загрузку файлов для начала

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

В Haskell repl офигенный

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

Ну, там и структура проекта другая, насколько я помню? Не нужен отдельно задаваемый порядок файлов, можно просто каталог ему скормить, и он более или менее сам всё поймёт.

В Haskell repl офигенный

хотя если работать в vs, то с repl'ом тоже комфортно

Ну, там и структура проекта другая, насколько я помню? Не нужен отдельно задаваемый порядок файлов, можно просто каталог ему скормить, и он более или менее сам всё поймёт.

да, еще сильно способстует то, что в одном файле один модуль

Да, тоже верно. Наверное, ещё обязательно соответствие имени модуля и имени файла?

Тогда в интерактивном режиме компилятору будет понятно, в каком порядке это всё собирать.

это тоже

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

Решилась проблема?

но это все решаемо тулингом, просто для F# такой автоматизации не сделал никто (по крайней мере в те годы, когда я на нем писал)

Ну, автоматическая упорядочивалка файлов вот сейчас появилась.

В принципе, можно на её основе какие-то проблемы из представленных начинать решать, если хочется.

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

Пытаюсь нагуглить сравнение F# с OCaml (в плане фич), ничего норм найти не могу. Может видел кто?

Где-то было кстати

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

так целевая аудитория у F# это разработчкики которые на C# пишут на виндовс в студии, к реплу они вообще не приучены, фича поэтому это заброшенная и третьестепенная

// узнаю себя

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

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

Решилась проблема?

Нет

Нет

Не спрашивал на gitter фэйбловском?

Не спрашивал на gitter фэйбловском?

Спрашивал. Проигнорировали.

Спрашивал. Проигнорировали.

Ща не за компом попробую позже, пингани ещё раз потом, ок?

Ок