MG
И лучше/хуже единственность "в GraphQL" против единственности "в базе" для внешнего агента?
Size: a a a
Типы в языках программирования, моделирования, представления знаний и жизни
384 membersпожаловаться на группу
2019 August 26
ON
Вот, кстати, смолтоковцы с этим работали — http://www.vpri.org/pdf/m2013002_experiments.pdf
да, отличное
VP
У GraphQL есть один замечательный юзкейс -- скрывать огромню инфраструктуру из кучи микросервисов с кучами разных видов БД за единым интерфейсом. И это только в случае, когда мы больше работаем с вложенными данными, чем с операциями. Других хороших кейсов я для него не увидел.
ON
У GraphQL есть один замечательный юзкейс -- скрывать огромню инфраструктуру из кучи микросервисов с кучами разных видов БД за единым интерфейсом. И это только в случае, когда мы больше работаем с вложенными данными, чем с операциями. Других хороших кейсов я для него не увидел.
операции в нем плохо выражаются, соглашусь
ON
ну т.е. это DSL для view-like query, а то что он сейчас в фазе "давайте забивать этим молотком все" - это пройдет)))
MG
Окей, возвращаясь к исходному вопросу: по сравнению с SQL не хватает триггеров и вообще change stream?
MG
И не сделать валидацию прям там же, где основная схема.
ON
И не сделать валидацию прям там же, где основная схема.
валидацию кстати можно, только это будет вторая схема
ON
graphql отлично формализует односторонний датафлоу, если хочется двусторонний то проще две схемы (имхо)
ON
состояние внутри коробки или ожидание от модели состояния снаружи он не формализует
VK
Ну вот дифференциальные уравнения оказались включены в Julia по факту не хуже, чем они включены в Modelica (и автор Modelica перешёл из-за этого на Julia). Насчёт FOL, так разных опытов по логике в той же Julia полно. Например, вот "типизированный пролог" (с вопросом "помогает ли типизирование хоть чему нибудь") — https://github.com/hessammehr/Logic.jl или стопятьсотый клон раннего Kanren — https://github.com/habemus-papadum/LilKanren.jl
При необходимости можно просто сделать то, что очень хочется — таким, как хочется.
Не думаю, что отсутствие FOL "из коробки" в расширяемом языке было бы проблемой. В любом случае, это не бОльшая проблема, чем отсутствие солвера для дифуров.
При необходимости можно просто сделать то, что очень хочется — таким, как хочется.
Не думаю, что отсутствие FOL "из коробки" в расширяемом языке было бы проблемой. В любом случае, это не бОльшая проблема, чем отсутствие солвера для дифуров.
Скажем так, по моей оценке язык Julia непригоден в _разработке_ программного обеспечения. Совсем. Разрабатывать на мейнстриме вроде C# - проще, быстрее, дешевле. При этом, в нише "модная замена Фортрану" Julia может быть ок, а может быть и нет, но это не важно. Если сама база это нишевый DSL, то никакие добавочные EDSL его не спасут.
ON
Скажем так, по моей оценке язык Julia непригоден в _разработке_ программного обеспечения. Совсем. Разрабатывать на мейнстриме вроде C# - проще, быстрее, дешевле. При этом, в нише "модная замена Фортрану" Julia может быть ок, а может быть и нет, но это не важно. Если сама база это нишевый DSL, то никакие добавочные EDSL его не спасут.
я тут на стороне Левенчука в смысле что можно рискнуть, и если его доведут (в ходе проекта) до ума в провисающих местах то будет здорово. выразительность-то отличная, реализация ужасная. scala вот кое-как довели
ON
меня в джулии очень радует язык концептуально, но хрупкий компилятор с breaking changes, очень сырая система пакетов (по сравнению с C#, JS, и даже с Python) и тормоза на старте (джит джулии почему-то в разы медленнее чем пересобрать весь немалый проект с библиотеками на дотнете)
ON
в скале с тормозами на старте и скоростью компилятора впрочем еще хуже, иначе бы я на ней писал
VK
@val_krylov Чем двойственность "в базе" / "в GraphQL" отличается от тройственности "в базе" / "в REST API v1" / "в REST API v2"?
Если брать REST, то ничем, там та же проблема "промежуточных представлений ради промежуточности".
MG
Аттрактор "обсуждаем языки программирования" достигнут за двое суток.
ON
Аттрактор "обсуждаем языки программирования" достигнут за двое суток.
простите
ON
для повышения качества дискуссии имхо стоит отдельно выделять свойства нотации и свойства инструмента работы с этой нотацией
ON
патамушо супер-IDE слабо поможет с языком который не имеет средств абстракции, а от супер-языка с кривым сложным компилятором тоже толку мало (кривой простой компилятор можно полезть и подкрутить)
ON
@ailevenchuk имхо говорит больше про нотацию, а @val_krylov - про конструкцию в целом, поправьте меня если что