Я знаю у нас тут есть ценители разнообразия в мире языков программирования, так что не мог удержаться
Flix, не то что бы новый язык, коммиты в репозитории с 2015 года, но упоминание его я впервые увидел сегодня. Выглядит как Scala здорового человека, с вкраплениями Python, Go, Haskell... уже странно, да?
Из положительных моментов:
а) на JVM
б) есть зеленые потоки и CSP
в) ООП порезали к херам
г) есть хвостовая рекурсия, таки хоть кто-то победил JVM
д) развивает не хрен с горы, а Орхусский университет (впервые слышу про них, но то что университет — это хорошо)
Запуск зеленого потока и чтение/запись в канал:
/// A function that sends every element of a list
def send(c: Channel[Int32], l: List[Int32]): Unit & Impure =
match l {
case Nil => ()
case x :: xs => c <- x; send(c, xs)
}
/// A function that receives n elements
/// and collects them into a list.
def recv(c: Channel[Int32], n: Int32): List[Int32] & Impure =
match n {
case 0 => Nil
case _ => (<- c) :: recv(c, n - 1)
}
/// Spawn a process for send and wait, and print the result.
def main(_args: Array[String]): Int32 & Impure = {
let l = 1 :: 2 :: 3 :: Nil;
let c = chan Int 100;
spawn send(c, l);
spawn recv(c, List.length(l));
0 // exit code
}
Здравствуйте, kaa.python, Вы писали:
KP>Из положительных моментов: KP>а) на JVM
Немного оффтоп, но вот я сейчас не уверен, что это положительно. То есть бутстрап конечно проще, но вот в долгой перспективе
Clojure/Scala довольно старые истории, а что у нас там пробивается сейчас? Go, Rust, Julia...
N>Clojure/Scala довольно старые истории, а что у нас там пробивается сейчас? Go, Rust, Julia...
Они тоже обрастают жирком, так что скоро сравняются.
Что интереснее, так это удобство синтаксиса в плане pattern match, receive statements и т.п.. Работает ли selective receive? Насколько быстро? Можно ли легко трансформировать существующий код (с того же эрланга) на это чудо?
Здравствуйте, novitk, Вы писали:
N>Немного оффтоп, но вот я сейчас не уверен, что это положительно. То есть бутстрап конечно проще, но вот в долгой перспективе N>Clojure/Scala довольно старые истории, а что у нас там пробивается сейчас? Go, Rust, Julia...
В целом я согласен, сделать что-то на базе LLVM выглядит заманчивее, работать будет сильно быстрее и с переносимостью может оказаться лучше. Но что делать с набором библиотек? Как бы прекрасен не был язык, без набора библиотек им никто не начнет пользоваться.
За Go стоит Гугл и использует его для своих нужд, за Rust стоит Мозилла и что интересно вмести со сдуванием Мозиллы сдувается и шумиха вокруг Rust. Разве что Julia выбивается из этого ряда, похоже что этот язык решает действительно уникальную проблему и люди согласны сами создавать библиотеки, т.е. язык узкоспециализированный. Ну а для языка общего назначения только "присосаться" к какой-то существующей VM и остается, а у нас на данный момент есть разве что .NET, JVM да BEAM. Имея такой выбор JVM кажется наиболее разумным вариантом.
Здравствуйте, kaa.python, Вы писали:
KP>б) есть зеленые потоки и CSP
А управлять этими потоками как-то можно? Например, задать приоритет. Здесь у нас обслуживание веб-запросов, это нужно активнее крутить. А здесь — фоновый процесс докатки упавших операций, его можно гонять менее активно. Или все запросы будут в общую кучу свалены и тормозить тоже все будет равномерно?
KP>в) ООП порезали к херам
Судя по стандартной документации, они там вообще сильно полиморфизм порезали. List.map — получается обычная фунцкия:
map[a, b, e](f: a -> b & e, xs: List[a]): List[b] & e
Это что, как в Ocaml, мне каждый раз нужно будет писать, что список у меня, список?
def addOne(l: List[Int32]): List[Int32] & Pure =
List.map(x => x + 1, l)
Я же уже в сигнатурах сказал, что l — это список. И в 95% map в применении к списку будет именно List.map. Ocaml хотя бы сигнатуру метода сам выведет (можно не писать типы). А здесь? Но даже в Ocaml это повторение модулей (List.map, Set.map, Whatever.map) очень быстро начинает бесить (я проверял!). Или есть какой-то секретный синтаксический сахар, который x.method(<args>) разворачивает в typeOfX.method(<args>, x)? Я вот смотрю на UFCS в Principles, так оно по первому аргументу идет а не по последнему.
Еще сразу отмечу, что у них функция стоит на первом месте в аргументах. Т.е. если там что-то нетривиальное (две-три строчки), читать все это будет сложно (список будет далеко). Хотя ладно, я нашел костыль:
def addOne(l: List[Int32]): List[Int32] & Pure =
l |> List.map(x => x + 1)
но проблему с повторением List это не решает.
KP>г) есть хвостовая рекурсия, таки хоть кто-то победил JVM
Просто рекурсия или взаимная рекурсия (mutually recursive)? Scala тоже умеет обычную рекурсию если объявить @tailrec.
KP>д) развивает не хрен с горы, а Орхусский университет (впервые слышу про них, но то что университет — это хорошо)
Это и хорошо, и плохо. Плохо то, что они теоретики и не знают реалий промышленного программирования. Судя по их примерам на главной странице, они сделали тайпклассы прямо как в Хаскеле. Но это же ужас . Экземпляры тайпкласса (typeclass instances) гвоздями прибиты к типу. В Scala это контекстные абстракции (contextural abstraction) и привязаны к контексту использования а не типу. Здесь у меня сразу три примера.
Первый вообще чуть-ли не из учебника (я в курсах по Scala его привожу). Вот есть у нас множество целых чисел. И есть тайпкласс моноид (Monoid). В нем есть нулевой элемент и ассоциативная операция. Вопрос — ну и какой из двух моноидов на целых числах (по сложению и по умножению) лучше? И как быть, если где-то нам нужно использовать второй моноид? Хаскель для этого гениальное решение предлагает. Нужно все числа завернуть в обертку и на ней определить второй моноид. А обертку компилятор соптимизирует. Ну ладно, допустим это теоретический пример...
Второй пример — асинхронное выполнение. Future в Scala. Это, конечно, монада. Но при реализации за ней стоит какой-то пул потоков. И очень бы хотелось иметь возможность использовать разные пулы для разных операций (см. выше, один для веб-запросов, другой — для фоновых). Т.е. в приложении нужно несколько разных экземпляров тайпкласса (typeclass instances). Документация Фликса этот вопрос совсем обходит. Хорошо, во flix есть встроенные абстракции для зеленых потоков. Допустим даже, что это — аргумент. Хотя в реальных приложениях "встроенной" асинхронности недостаточно, нужно иметь строить абстракции сверху. Банальное распределенное трассирование (distributed tracing) в асинхронных приложениях мало кто умеет делать. А ведь концептуально это всего-лишь State+Future (даже не целый State, достаточно половины).
Третий пример. UI. Типичный Observable — это монада (в большинстве случаев оно все же как аппликатив используется). Например, можно взять два Observable и сделать их обозримую сумму. И все бы было хорошо, но в реальных приложениях граф данных не статический. Пользователь может открыть диалоговое окно, посмотреть на что-то, закрыть окно. Или даже открыть много диалоговых окон одного типа. Вот как в таких условиях управлять временем жизни всех связей (bindings)? В Scala я делаю BindingContext на каждый независимый контекст (lifetime/scope). Диалоговое окно будет иметь свой контекст. При уничтожении контекста (закрытие окна) все созданные в контексте связи уничтожаются. Монада для Observable как раз реализуется этим контекстом. А вот как это глобально и удобно сделать — я не представляю.
Из других непрактичных вещей. У них в факе заявлена строковая интерполяция. Но она захардкожена в язык и не расширяема. Поэтому вопрос — как предполагается работать с базой данных? Долго и грустно через PreparedStatement? В той же Scala я на основе интерполяции и неявных преобразований могу сделать безопасный (без sql injection) синтаксис для запросов:
def getEntity(id: String): Option[Entity] =
sql"""
SELECT *
FROM entities
WHERE id = ${id}
""" select maybe(entity)
private def entity(r: ResultRow): Entity =
Entity(id = r.id, name = r.name, ...)
Да, забыл про динамики (dynamics). Они в парсере используются. Попробуйте такое на jdbc во Flix записать...
KP>Налитай пока горячее
Только для экспериментов над ее фичами. Datalog constraints выглядит интересным. Purity/impurity (наконец-то, язык с двумя системами типов — одна для данных, вторая для purity) — тоже. А для практического применения он Scala пока не заменит. Хотя если на Flix кто-то напишет хорошие библиотеки, можно будет их из Scala использовать (наверное).
KP>>д) развивает не хрен с горы, а Орхусский университет (впервые слышу про них, но то что университет — это хорошо)
M>Это и хорошо, и плохо. Плохо то, что они теоретики и не знают реалий промышленного программирования.
Здравствуйте, vaa, Вы писали:
vaa>Scala тоже университетский проект. к слову.
У Scala есть план развития, а вот у Flix вообще не ясно что, когда и как они собираются добавлять или править. Чисто академической проект, но может жить очень долго за счёт университета.
Здравствуйте, vaa, Вы писали:
vaa>Scala тоже университетский проект. к слову.
Да, я в курсе. Это язык, в котором специально хотели сделать самую сложную систему типов. Сложную — с теоретической точки зрения. Её дальнейшее разрешение очень быстро приводит к неразрешимым системам (Тьюринг-полная система с проблемой останова). И долгое время язык искал себя.
Потом в 2010-м году (шесть с половиной лет языку) в Scala 2.8 добавили акторы. На них прекрасно ложатся некоторые специфические задачи с глобальным изменяемым состоянием. Использование сопоставления с образцом (pattern matching) является большим преимуществом при написании обработчика всяких сообщений (в Java был бы длинный if/else-if с проверками типов и прочими гадостями). Продвинутая система типов здесь совсем не при делах (акторы вообще принимают нетипизированные сообщения, akka typed с контролем типов сообщений появилась гораздо позже). Полезны только case classes для определения сообщений.
В 2011-м году выходит Scala 2.9. Команда основывает компанию Typesafe (теперь уже Lightbend) для коммерческой поддержки языка. И это было одним из решающих факторов в дальнейшей успешности языка. Компании берут Scala для использования акторов и активно предоставляют обратную связь и запросы на улучшение через коммерческую поддержку. В результате в 2013-м году выходит Scala 2.10. Из нее выкинуты акторы (которые реализуются библиотекой). Зато добавлено много языковых возможностей, включая строковую интерполяцию (string interpolation), динамики (dynamics) и прочий полезный сахар. Посмотреть можно здесь. Именно этот набор изменений сделал язык очень удобным для практических задач. А higher kinds является просто дополнительным бонусом, который можно использовать, раз уж он есть. Я лично не уверен, что готов был бы агитировать за использование Scala 2.9 в реальной компании. Там для практических задач (прочитать из базы, отправить json) не так много преимуществ по сравнению с Java было бы. А вот в 2.10 улучшения заметны и на Java я обратно ну совсем не хочу.
Хотя сложная система тоже сыграла свою роль. Добавлять типизацию для новых синтаксических конструкций было бы очень больно. Поэтому все новые возможности в 2.10 сводятся к преобразованию кода в вызов функций. Оно может быть в несколько этапов (for-comprehension + implicit conversion + implicit resolution, например). Но зато в вычислительной модели там по сути лямбда-исчисление и еще несколько специальных конструкций (блоки, if, while, do, скобки, объявления в блоках, try/catch/return, match). На этом фоне типичная для Java экосистема Spring кажется жутко сложной. Там все на аннотациях, которые обрабатываются черной магией по своим правилам.
Так что Scala в современном виде сложилась в результате обработки обратной связи, возникшей при применении языка для решения узкого класса практических задач. Для Flix пока не хватает какого-нибудь убедительного примера, использующего его основные возможности. Ну например, сделать алерты на основе входящего потока метрик. Алерты записывать как предикаты на прологе, метрики — читать из каналов и генерировать факты. И показать, что, например, можно это делать лучше, чем в существующих системах мониторинга (проще читать или можно выразить гораздо больше полезных условий). Или сделать какой-нибудь автоматизированный поиск основной причины отказа. Например, упала база. Из-за нее упало два сервиса. А потом по цепочке упало еще двадцать. В типичном мониторинге будет 23 красных сервиса. А хотелось бы одну красную базу и 22 "оранжевых" (не работают, но проблема скорее всего не в них) сервиса. И вот чтобы топологию и критерии "root cause" описывать на прологе, а потом к этому прикручивать ввод/вывод через каналы. Задачи мониторинга сейчас как раз актуальны. И ограничения языка (отсутствие полиморфизма, например) здесь не важны. И вот уже на основе реальных применений можно было бы тоже понять, что получилось хорошо, а что еще стоило бы улучшить.
Здравствуйте, kaa.python, Вы писали: KP>д) развивает не хрен с горы, а Орхусский университет (впервые слышу про них, но то что университет — это хорошо)
ну здрасьте... это же альма-матер Страуструпа!
Здравствуйте, kaa.python, Вы писали:
KP>Из положительных моментов: KP>а) на JVM KP>б) есть зеленые потоки и CSP KP>в) ООП порезали к херам KP>г) есть хвостовая рекурсия, таки хоть кто-то победил JVM KP>д) развивает не хрен с горы, а Орхусский университет (впервые слышу про них, но то что университет — это хорошо)
Чё-то ты какую-то херню перечислил. Беглый взгляд показал, что самое интересное там
first-class datalog constraints
polymorphic datalog predicates
constraints with lattice semantics
т.е. встроенный пролого-подобный язык, о чем ты буквально недавно писал.
Ну, и тайплассы разные в купе с возможностью явного протаскивания чистоты функций через типы.
Ну, а то что привычный ООП выкинут это двоякое решение. Ведь если тебе придется писать какой-нибудь ГУЙ, то ФП и неизменяемость данных для этого не очень то подходит.
Мне кажется хорошим решением было бы изоляция императивно-ООП-ного кода в эдаких песочницах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Чё-то ты какую-то херню перечислил. Беглый взгляд показал, что самое интересное там VD>first-class datalog constraints VD>polymorphic datalog predicates VD>constraints with lattice semantics
Я вот понял, что на очень примитивном уровне использую языки программирования, ну либо языки что я использую крайне примитивные, но вот то что ты перечислил для меня как белый шум. Видимо поэтому и не оценил фичи
VD>Ну, а то что привычный ООП выкинут это двоякое решение. Ведь если тебе придется писать какой-нибудь ГУЙ, то ФП и неизменяемость данных для этого не очень то подходит.
Да, я слышал что для ООП прям очень хорошо заходит для гуя. Видимо т.к. гуй не писал надцать лет, то уже и не могу заценить. Но, кстати, сейчас подавляющее большинство гуя на JS, и там вроде как ООП нет, но гуй пишется. Это из-за динамики или для гуя ООП не так уж и важен?
а где язык, который можно читать как сказку пушкина, без закорючек и сотен разнобразных стрелочек и скобочек
чтобы читаешь то что написали другие, и вносишь чтото от себя — новое и красивое, прям словами, вот как здесь мы все общаемся.
Здравствуйте, kaa.python, Вы писали:
KP>Да, я слышал что для ООП прям очень хорошо заходит для гуя. Видимо т.к. гуй не писал надцать лет, то уже и не могу заценить. Но, кстати, сейчас подавляющее большинство гуя на JS, и там вроде как ООП нет, но гуй пишется. Это из-за динамики или для гуя ООП не так уж и важен?
Ну здрасте... Есть конечно в JS ООП, хоть и специфическое, плюс многие сейчас гуи пишут на TypeScript, где с ООП еще лучше.
Здравствуйте, Wawan, Вы писали:
W>а где язык, который можно читать как сказку пушкина, без закорючек и сотен разнобразных стрелочек и скобочек W>чтобы читаешь то что написали другие, и вносишь чтото от себя — новое и красивое, прям словами, вот как здесь мы все общаемся.
Go довольно давно существует. Один в один как описал ты. Если вносить новое хочется и при этом иметь хорошую читабельность, то Elixir.
Здравствуйте, Wawan, Вы писали:
W>а где язык, который можно читать как сказку пушкина, без закорючек и сотен разнобразных стрелочек и скобочек W>чтобы читаешь то что написали другие, и вносишь чтото от себя — новое и красивое, прям словами, вот как здесь мы все общаемся.
IDENTIFICATION DIVISION.
PROGRAM-ID. FIZZBUZZ.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 X PIC 999.
01 Y PIC 999.
01 REM3 PIC 999.
01 REM5 PIC 999.
PROCEDURE DIVISION.
PERFORM VARYING X FROM 1 BY 1 UNTIL X > 100
DIVIDE X BY 3 GIVING Y REMAINDER REM3
DIVIDE X BY 5 GIVING Y REMAINDER REM5
EVALUATE REM3 ALSO REM5
WHEN ZERO ALSO ZERO
DISPLAY "FizzBuzz"
WHEN ZERO ALSO ANY
DISPLAY "Fizz"
WHEN ANY ALSO ZERO
DISPLAY "Buzz"
WHEN OTHER
DISPLAY X
END-EVALUATE
END-PERFORM
STOP RUN
Здравствуйте, VladD2, Вы писали:
VD>с возможностью явного протаскивания чистоты функций через типы.
Автоматическая purity интересна только с точки зрения компилятора. На практике она полезна только в ограниченном количестве случаев. А в остальных создает кучу неудобств.
Например, возьмем проверку jwt token в приложении.
def createJwtCheck(config: Config): ((String, Long) -> Bool & Pure) & Pure = ...
val checkJwt: (String, Long) -> Bool & Pure = createJwtCheck(appConfig)
val webAuth = createAuth(checkJwt, ...)
val handler = createSomeHandler(webAuth, ...)
Здесь мы будем смотреть на checkJwt. Она получает токен, текущее время и возвращает true (токен валиден в текущий момент) или false (токен не валиден). Сама по себе функция — замыкание на конфигурацию (ключи проверки и т.п.). Реализация вполне даже pure — там парсинг из строки и куча математики. Ввод/вывод не требуется, все конфиги уже распарсены и есть в нужном виде. И вроде бы все хорошо, но это только до первого изменения требований.
JWT может провалит авторизацию по нескольким причинам. Может быть неверный формат, неверная подпись или срок действия. И было бы интересно получать какую-то статистику отказов. Т.е. знать, что кто-то пытается подобрать подпись или просто не умеет работать с календарем. С точки зрения аутентификатора и прочего слоя обработки исходная сигнатура (String, Long) -> Bool удобна. Им не нужен детальный результат. Поэтому логично было бы писать метрики внутри фабрики и экспортировать их с прочими:
def createJwtCheck(config: Config): (((String, Long) -> Bool & Impure), () -> Metrics) & Pure = ...
val (checkJwt, jwtMetrics) = createJwtCheck(appConfig)
val webAuth = createAuth(checkJwt, ...)
val handler = createSomeHandler(webAuth, ...)
val metricsExproter = Metrics.combine(jwtMetrics, ...)
Metrics.export(metricsExporter, appConfig)
Функция изменяет метрики. И автоматически становится Impure. Хотя с точки зрения пользователя (webAuth) она все-таки используется как чистая (нет обнаруживаемых побочных эффектов). Что приводит к идее о том, что "чистоту" нужно рассматривать в рамках инкапсуляции. "Интерфейс" общения с системой может быть чистым (нет обнаруживаемого состояния), а вот реализация — грязной.
И таких сценариев, когда функция (зависимость компонента!) превращается из чистой в грязную много. Кэширование результатов "пачкает" функцию. Логирование — тоже. И при этом impurity очень заразное и распространяется очень далеко от начального изменения. Переход pure->impure не локален. Хуже того, нет возможности его ограничить! Если я меняю тип результата существующей функции, то могу написать обертку и в определенных пределах сконвертировать данные. Можно "миграцию" делать постепенно. А вот в случае impurity придется менять и всех пользователей. Банальный отладочный println внутри quicksort может затронуть типы половины программы.
С учетом вышесказанного проще всего считать все функции в программе Impure. И только в ограниченных пределах использовать pure. Будет не так больно, когда в дальнейшем придется менять код.
Здравствуйте, kaa.python, Вы писали:
KP>Но, кстати, сейчас подавляющее большинство гуя на JS, и там вроде как ООП нет, но гуй пишется. Это из-за динамики или для гуя ООП не так уж и важен?
Что же там как не ООП? DOM-модель это ООП. А все эти фреймворки только надстройка над ним. Как бы верх ООПщины — MVVM.
В принципе, у меня были идеи как ГУЙ натянуть на идею зависимых вычислений. Но самое виденье их у меня несколько на ООП похоже. Эдакий объект свойства которого могут изменяться только один раз и сбрасываться в нужный момент по графу зависимостей (для нового пересчета). Вот там можно добиться высокой декларативности и для ГУЯ. Жаль только мне на это денег никто не даст.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В принципе, у меня были идеи как ГУЙ натянуть на идею зависимых вычислений. Но самое виденье их у меня несколько на ООП похоже. Эдакий объект свойства которого могут изменяться только один раз и сбрасываться в нужный момент по графу зависимостей (для нового пересчета). Вот там можно добиться высокой декларативности и для ГУЯ. Жаль только мне на это денег никто не даст.
. Экземпляры тайпкласса (typeclass instances) гвоздями прибиты к типу. В Scala это контекстные абстракции (contextural abstraction) и привязаны к контексту использования а не типу. Здесь у меня сразу три примера. 
