Author

Topic: Функциональный язык для смарт контракто&#1074 (Read 300 times)

member
Activity: 182
Merit: 17
¯\_(ツ)_/¯

Но насколько я понял из PureScript легко вызвать JS, а для песочницы это ненужное поведение и это небходимо как-то отключать. А у Elm по-умолчанию внешний мир недоступен. Или я ошибаюсь насчет PS?


Все правильно, но мне это как раз подходит. Я же делаю сандбуксинг из Java.
jr. member
Activity: 54
Merit: 1

Да не то чтобы плохо ложатся, но дополнительная работа по интеграции из-за портов. В PureScript практически просто вызывается функция.


Но насколько я понял из PureScript легко вызвать JS, а для песочницы это ненужное поведение и это небходимо как-то отключать. А у Elm по-умолчанию внешний мир недоступен. Или я ошибаюсь насчет PS?



member
Activity: 182
Merit: 17
¯\_(ツ)_/¯
Quote
А мне как раз-таки нравится его способ взаимодействия с JS ) Что именно вы имеете в виду и какие задачи плохо ложатся на его модель?

Да не то чтобы плохо ложатся, но дополнительная работа по интеграции из-за портов. В PureScript практически просто вызывается функция.

Спорно конечно.

Quote
У меня вызывает сомнение целесообразность вложения труда/ресурсов в Java-проекты в виду а) проприетарности, б) назревающей конкуренции с WASM и грядущей войне VM, в которой я ставлю на последнего )). Но это если говорить о самой Java, не сравнивая ее с Elm.

а) Кроме Oracle у  Java есть еще пара  коммерческих реализаций и одна open source - OpenJDK.
б) Популярные языки имеют обыкновение жить долго и умирать медленно. Грядущие войны, катастрофы, кто знает что произойдет. Да и привычно как то. Старая добрая Java.
jr. member
Activity: 54
Merit: 1
Хм... Но с Elm еще одна загвоздка, там интерфейс взаимодействия с JavaScript не очень прозрачный.

А мне как раз-таки нравится его способ взаимодействия с JS ) Что именно вы имеете в виду и какие задачи плохо ложатся на его модель?

По поводу песочницы - если использовать Nashorn из  JDK 10,  там есть возможность сандбоксинга. Можно подключить любые языки, которые компилируются в JavaScript.

У меня вызывает сомнение целесообразность вложения труда/ресурсов в Java-проекты в виду а) проприетарности, б) назревающей конкуренции с WASM и грядущей войне VM, в которой я ставлю на последнего )). Но это если говорить о самой Java, не сравнивая ее с Elm.
member
Activity: 182
Merit: 17
¯\_(ツ)_/¯

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

Насчет сообщества согласен пожалуй. Целевая группа пользователей Elm может заинтересоваться проектом.  Хм... Но с Elm еще одна загвоздка, там интерфейс взаимодействия с JavaScript не очень прозрачный.

По поводу песочницы - если использовать Nashorn из  JDK 10,  там есть возможность сандбоксинга. Можно подключить любые языки, которые компилируются в JavaScript.
jr. member
Activity: 54
Merit: 1
Мне нравится Elm, но с ним есть проблема, он поддерживается одним человеком. Как вариант рассматриваю PureScript.

Сам язык достаточно взрослый и уже не нуждается в регулярных исправлениях. А хороший проект может дать толчок к развитию сообщества. Для меня самым большим плюсом в нем является легкость создания песочницы.
member
Activity: 182
Merit: 17
¯\_(ツ)_/¯
Согласен, я думаю что язык разумнее выбрать более распространенный. Я сейчас использую в своем прототипе JavaScript но придерживаюсь подхода чистых функций.

Я выбрал elm. Советую присмотреться: очень лаконичный, минимум конструкций и сущностей. Помимо стандартных для js типов есть кортежи.

Мне нравится Elm, но с ним есть проблема, он поддерживается одним человеком. Как вариант рассматриваю PureScript.
jr. member
Activity: 54
Merit: 1
Согласен, я думаю что язык разумнее выбрать более распространенный. Я сейчас использую в своем прототипе JavaScript но придерживаюсь подхода чистых функций.

Я выбрал elm. Советую присмотреться: очень лаконичный, минимум конструкций и сущностей. Помимо стандартных для js типов есть кортежи.
newbie
Activity: 86
Merit: 0
Кардана обещают будет на Хаскелеподобном языке.
member
Activity: 182
Merit: 17
¯\_(ツ)_/¯
Забавно только начал делать нечто подобное, правда язык выбрал не такой низкоуровневый. Стало интересно что из этого может получиться. Все-таки функциональные языки содержат меньше абстракций и более предсказуемы.

Согласен, я думаю что язык разумнее выбрать более распространенный. Я сейчас использую в своем прототипе JavaScript но придерживаюсь подхода чистых функций.
jr. member
Activity: 54
Merit: 1
Забавно только начал делать нечто подобное, правда язык выбрал не такой низкоуровневый. Стало интересно что из этого может получиться. Все-таки функциональные языки содержат меньше абстракций и более предсказуемы.
jr. member
Activity: 168
Merit: 1
ImmVRse | Disrupting the VR industry
Как архитектор с 20-ти летним стажем в программировании - количество багов никогда не определяется средствами программирования, но всегда прослойкой между стулом и монитором. Даже на самом лучшем языке люди совершают грубые ошибки, и во многом из-за уверенности, что среда разработки за них все подправит.

Поэтому всегда нужен тот, кто сможет подправить тебя, устранить ошибки.
Не нужно надеяться только на себя, лучше подключить знающих людей, но и это конечно же не даст 100% реультата, но 99% все таки сможет дать.
member
Activity: 182
Merit: 17
¯\_(ツ)_/¯
В дополнение, как иллюстрация реальности проблемы https://support.okex.com/hc/en-us/articles/360003019292-ERC-20-Tokens-Deposit-Suspended
member
Activity: 182
Merit: 17
¯\_(ツ)_/¯
Как архитектор с 20-ти летним стажем в программировании - количество багов никогда не определяется средствами программирования, но всегда прослойкой между стулом и монитором. Даже на самом лучшем языке люди совершают грубые ошибки, и во многом из-за уверенности, что среда разработки за них все подправит.

Конечно, согласен полностью.

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



newbie
Activity: 2
Merit: 0
Как архитектор с 20-ти летним стажем в программировании - количество багов никогда не определяется средствами программирования, но всегда прослойкой между стулом и монитором. Даже на самом лучшем языке люди совершают грубые ошибки, и во многом из-за уверенности, что среда разработки за них все подправит.
member
Activity: 182
Merit: 17
¯\_(ツ)_/¯
Читал в последнее время о катастрофах, произошедших из за того, что смарт контракты были недостаточно хорошо протестированы, содержали баги итп.

Стало интересно, есть ли такая криптовалюта, в которой смарт контракты пишутся на функцинальном языке программирования, с использованием чистых функций? Что то типа Haskell, OCaml, F#?

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

Немного погугулил, нашел только https://www.fstar-lang.org/ - его вроде как потенциально планируют для этих целей, но это не совсем то.
Jump to: