Comments 35
Отказ от обработки ошибок. Вместо их обработки упор делается на максимальную отказоустойчивость: Ошибки просто невозможны;
открыть несуществующий файл невозможно, его же не существует
Как константное поведение, если чего-то нет, то ничего не произойдёт. Абстрактный пример: "Я пошёл в другую комнату, там не было двери, но я просто прошёл дальше". Собственно, если мне действительно бы нужна была эта "дверь", то она бы была создана или я мог прописать "иные" механизмы на всякий случай.
Т.е. если я открываю файл, то дальше в коде должен предусмотреть проверку, открыт он или нет?
На данный момент RTS не имеет реализации работы с файлами, только самое необходимое, например описанное в данной статье. Но если мы предположим, что RTS предоставит стандартный доступ работы с файлами в ближайшем обновлении, т.к. это довольно важно, например записи в файл, проверки наличия файла. Ваш вопрос уходит дальше, в сторону создания библиотеки, допустим "fs" или собственной реализации. Это уже пользовательские реализации, однако мы можем предположить, что люди реализуют проверку на открытия файла. А в целом если вы в RTS обратитесь к чему-то, чего нет, то просто ничего не произойдёт, в иных же языках мы получили бы ошибку работы и возможно падение всей программы.
Не понял в чём ноу-хау.
Так же непонятно, в чём специфичность языка, почему он Real-Time, и причём здесь свободные структуры данных.
Real-Time он в силу того, что интерпретируется и имеет реактивность, т.е. все изменения и работа происходят в реальном времени. А свободные структуры, это о том, что язык не следует обычным структурам, такие как списки, массивы, методы и т.п. По сути это большая абстракция, которую программист волен написать под свою задачу, а не просто следовать чему-то принятому. Но всё же, если будет необходимость в стандартных конструкциях, то ты пишешь их либо сам, либо импортируешь готовые варианты. Так и код чище, да и дышится свободнее. Надеюсь теперь стало более понятно.
Real Time по определению - это гарантия того, что система гарантирует детерминированное время ответа на запрос. То есть он будет гарантированно выполнен (возможно в ошибкой) за заданное требованиями время. Как это соотносится с тем что представленный ЯП интерпретируемый и реактивный(что бы это не значило) - непонятно.
Абсолютно любую структуру или поведение я могу реализовать на другом интерпретируемом языке, для примера возьмём python. Также почти все структуры и поведения, которые я написал, могу изменять по ходу выполнения программы. Стремление к отказоустойчивости похоже на JavaScript, но более хардкорное. Моментальной best практикой станет использование проверенных библиотек (или переход на другой ЯП :) ), которые любой чих обмажут проверками и возвратят какую-то ошибку, в случае неудачи. То же чтение файла по хорошему ВСЕГДА нужно будет проверять на наличие этого файла, иначе что-там будет дальше, даже богу не известно. А использование чистого RTS будут отрекаться по примеру сырых указателей в C++. Отказ от ошибок поднимает производительность, но если нужна производительность выбор обычно падает на компилируемые языки.
Использование этого языка вижу так, нужно написать гибкое и быстрое приложение, а "сохранность ног" будет обеспечиваться сторонними анализаторами, статическими и/или рантайм. А рантайм не ускоряет выполнение... Иначе при текущем положении дел, другого сценария для хоть сколько-то полезной разработки не оторванной от реальности, не вижу.
Не знаю почему Хабр желает, чтобы я одобрил или не одобрил ваш комментарий. Ваше рассуждение правильно, но только в привычном для всех порядке вещей. RTS не пытается конкурировать с существующими языками или решениями, а предлагает альтернативу (новую парадигму) подхода к программированию. Это должно быть само собой разумеющееся как существование структурного программирования. Т.е. сравнивать достаточно проблематично, нужно скорее пробовать и улучшать.
Если же вы ознакомитесь с материалами по тому же Python или JavaScript, то увидите, что они не совсем то и реактивные, а такой функционал предоставляется в библиотеках. Кроме того, вы сами заметели, что "Также почти все структуры и поведения, которые я написал, могу изменять по ходу выполнения программы.". В случае с RTS, любая структура может именяться как угодно и реактивно.
Далее вы говорите о постоянной проверке, но обязательно ли вам что-то проверять, что точно всегда существует и вы знаете об этом? В случае необходимости, вы можете это проверить, в ином случае просто следуйте стандартному поведению RTS. Сравнение с сырыми указателями в данном случае не совсем верно, поскольку памятью RTS управляет автоматически, но если речь о поведении структур, то это право программиста писать кривой код или подумать над тем, что он пишет и решить, нужны ли ему проверки или нет, может ли работать что-то как он задумал или нет. Если он параноик, то так можно и весь код проверками забить, проблем не будет, но смысла мало.
Отказ от ошибок действительно повышает производительность, но ошибочно будет полагать, что только это увеличивает производительность в RTS. В основном это микроархитектура, минимальный интерфейс стандартного набора функций, а также реализация на Rust.
И последнее, про "сохранность ног", вы действительно могли бы иметь программу, которая проверит ваш код заранее на синтаксис и т.п.. В целом это минимально затратная вещь. Но не знаю будете ли вы проверять ваш проект только по написанию огромного количества кода, скорее всего распространён тот вариант, в котором вы проверяли его несколько раз на этапах разработки, а значит скорее всего могли заметить большинство изъянов в вашем коде. Кроме того, возможно вы не один кодер в комманде. В случае если вы не заметили, то RTS не будет вас ругать и запустит ваш код. Тогда вы получаете второй вариант, где вы можете заметить нежелаемое поведение вашего кода. Ну и в конечном итоге, вы могли бы вернуться к тем же проверкам, если не уверены в своём коде. Всё зависит только от вас, от того, следуете ли вы стандартному поведению RTS и смыслу вашей задачи.
предлагает альтернативу (новую парадигму) подхода к программированию
Вы не раскрыли в чём заключается новая парадигма, и какую задачу она решает.
Если говорить в общем, это отрицание ошибок, свобода программирования любых структур данных. Сама парадигма, которой следует RTS, говорит о том, что внимание должно быть уделено не меньше алгоритмам и правильному программированию. Т.е. не тот вариант, когда мы имеем пакетные менеджеры с кучей хлама, не понимаем как работают нейронные сети, пишем код лишь бы он просто работал. Сюда же входит и создание всё совершенных машин, когда мы даже не поняли, как можно программировать. Продолжая, это программирование в реальном времени и противопоставление структурному программированию, т.е. иной подход от текущей ветки развития, начавшейся с 1960-го года.
Отрицание ошибок - это понятно. Хотя, не ново.
А по остальному можно больше конкретики?
Я бы с радостью ответил на ваши вопросы, если вы их сформулируете более подробно.
свобода программирования любых структур данных
Как это реализовано синтаксически, как представляется в памяти, и в чём новизна?
Сама парадигма, которой следует RTS, говорит о том, что внимание должно быть уделено не меньше алгоритмам и правильному программированию.
Звучит как "за всё хорошее против всего плохого". Это не парадигма, а общие слова.
Не знаю почему вы этого не увидели в самой статье, возможно проблема в последовательности или сложности материала. Я понимаю, что сложно передать другую парадигму, отличную от разрабатываемой ветки с 1960-го года, это как говорить про совершенно далёкие вещи. На деле всё оказывается не так сложно и далеко.
Под "любой" структурой можно понимать реализацию чего-либо. Привычных нам массивов, списков, векторов, переменных, методов, в RTS их нет. В RTS есть минимальный функционал и примитивные типы данных. В статье упоминается модуль Structure, он отвечает за реализацию. Суть состоит в том, что структура может быть всем тем, чем вы её опишите. Это не когда вы следуете указке документации, как описать функцию или массив, а про подумать и написать то, что вы хотите, что вам надо, а не то, что вам говорит язык. Вы же не говорите на Русском языке, общаясь стандартными шаблонами и словами? В языке обычном, так и программирования, должна быть та самая расширяемость, а не изначальные рамки.
В статье были приведены примеры кода, как вложенные структуры, так и линейные. Были приведены методы, стандартные функции, а также примитивные типы данных. Если ещё проще, то строки кода образуют блоки кода, блоки кода вкладываются друг в друга, а с дополнительными маркерами они становятся структурами. Так мы можем создать тот же while или for если он нам нужен, а возможно нам нужен более продвинутый механизм, например с дополнительными условиями, итерациями и т.п. В этом плане RTS не следует "за всё хорошее против всего плохого", скорее за написание кода независимо от вашего скила в программировании.
Концепция также предполагает, что за место обработки всего, вы могли бы писать код следуя константному поведению в RTS. К тому же, об этом тоже говорилось в статье, теорема Бёма — Якопини, убивает альтернативу себе, что является глупым поступком, вы ведь пользуетесь теми же синхронными и асинхронными методами и воспринимаете это как должное. Попробуйте больше не пользоваться асинхронными функциями, такое положение в программировании сейчас. В добавок вам скажут, что компьютеры мощные и вам не зачем писать хороший код, главное чтобы он работал. А про заваленные хламом репозитории, я уже и не говорю.
На последок, та же теорема говорит нам о том, что есть блоки кода, условия и циклы, а также запрещается использовать конструкции типа goto. А RTS говорит нам о том, что циклов нет, но мы можем их создать, при необходимости. Вывод у всего этого один: мы не обязаны следовать рамкам готовых структур, мы должны их создавать сами, под наши нужны, и не захламлять наше окружение. Звучать наверное это будет, как Анархия — мать порядка. Прошу вас хотя бы просто подумать над такой альтернативой, что она есть, и как видите, уже начинает работать.
полагаю, вам придется по вкусу Lisp
мы не обязаны следовать рамкам готовых структур, мы должны их создавать сами, под наши нужны, и не захламлять наше окружение
Мы говорим о структурах данных или о структурах в смысле структурного программирования?
Звучать наверное это будет, как Анархия — мать порядка.
Ну да. А приведёт это к тому, что пользователи договорятся о некотором стандартном наборе структур, которым, для совместимости, будут пользоваться все. И создавать новые будут только ОЧЕНЬ редко и нишево.
Не знаю почему вы этого не увидели в самой статье, возможно проблема в последовательности или сложности материала.
Причина в отсутствии спецификации кода. Я не читаю код, спецификацию которого не видел.
Теперь посмотрел, продрался через чуждую для меня концепцию "изучения на примерах".
Так вот: вы предлагаете кортеж, вид сбоку.
Наверно, потому что это был мой первый комментарий :)
Прочитал статью, понял, но не до конца, пошёл дальше, пришли мысли, вернулся и обернул свои размышления в комментарий.
Получается зацепило, но нет ничего, с чем можно было бы поиграться. А так же вы правильно заметили, что нужны бы разъяснения про теорему о структурном программировании, и как из неё вытекает неструктурное программирование.
Посмотрите на LISP, Erlang, Haskell
Думаю имеет место быть схожести, но как человек, который создал RTS, отмечу, что не опирался на данные языки, хоть и знаком с ними. Скорее я даже вовсе не обращал на них внимание, как и на другие языки. Возможно, это говорит нам о том, что RTS идёт правильным путём на данный момент, решает собственную область задач в программировании, и уж точно не конкурирует с другими языками.
День открытых дверей в доме непризнанных гениев.
Молодой талантливый автор обнаружил фатальный недостаток во всех языках.
Большая часть статьи это списки в духе маркетинговых материалов. Быстрее, лучше ,сильнее. Указывается что быстрее работает в n раз. При этом без бенчмарков.
Как в этом языке обеспечивается модульность? Разделение пространств имен?
Любое имя может быть присвоено любой структуре. Будет ли использовать такое промышленная разработка? Видимо нет.
Заявляется некая новая парадигма, однако получается более медленный ( потому что интерпретируемый) , небезопасный ( ошибки игнорируем) и трудноподдерживаемый аналог Си.
На лисп или хаскел,хотелось бы похожим, но пока что обычное структурное программирование с динамическими структурами. Нет ни инструментов функционального и метапрограммирования. Если они есть то опишите в статье хотя бы минимальные примеры.
Не считаю, что для написания кода, нужен талант. Всё что я делаю в том же RTS, это просто создаю альтернативу, которая должна была быть и раньше, но этого никто не сделал. Почему? Об этом сказано как в статье, так и я пытался объяснить в комментариях другим людям. В целом, я понял, что вопросы в основном больше о самой парадигме, что не обсуждается в самой статье так сильно, возможно следует сделать статью, объясняющие принципы.
Дело совершенно не в том, что текущий интерпретатор быстрее и т.п., в статье я уже объяснил с чем это связано. А что касается бенчмарков, то это мой первый пост на Хабре, изначально я даже и не думал, что люди могут заинтересоваться больше скоростью, чем концепцией.
Про разделение пространств имён. В статье не было сказано про это, потому, что этого нет. Но это не значит, что это не планируется или не продумывалось. По факту возможен механизм, в котором вы пометите структуру как модуль, сможете вложить в неё необходимый вам функционал и будете его использовать. Пространство имён нужно только при путанице в именах. В RTS при импорте вы ссылаетесь на конкретные имена из паккета, на вряд ли вы не заметите сходство у себя в коде. А даже если и не заметите, то при тесте вы это точно увидите. Ближайший пример - импорты в NextJS. Пока что ни разу мне, как в NextJS, так и в RTS не приходила мысль использовать обётки пространств имён. В промышленной разработке проекты куда больше, но принципы схожи. Вы бы лучше подумали и предложили ожидаемый вами вариант решения.
Про небезопасность смысла говорить нет, если вы не поняли обратное из данной статьи или комментариев. Сравнивать компилируемые языки типа Си с RTS, это абсурд.
Нет ни инструментов функционального и метапрограммирования
На лисп и хаскел не хотелось бы быть похожим, у RTS свой путь и область использования. Необходимые вам функции и процедуры вы можете создать, об этом написано в статье. Про мета-программирование, скажу, что сейчас реализую похожий механизм, чтобы вы могли получить полный доступ к созданию структур.
Что-то мне вспомнилась BolgenOS... К чему бы...
Я так понял, что ошибки не нужно обрабатывать, потому что их не нужно совершать. Свежо! :))
Про Realtime... Чего-то у меня ощущение, что автор не совсем понимает, что такое Realtime. Ну или, в лучших традициях, переопределяет его как-то по-своему.
Хорошо, когда человек мыслит творчески. Плохо, когда весь пар уходит в свисток...
А можно получить ссылку на описание синтаксиса языка? Отрицание теоремы Бёма-Якопини мне не понятно - хотелось бы понять, в чём именно оно, отрицание, заключается? Утверждение о минимально-необходимом количестве управляющих структур не исключает использования прочих.
На данный момент, синтаксис можно посмотреть только в примерах и тестах языка, которые прикладываются к релизу, это самый простой вариант. Про новую парадигму, думаю сделать отдельную статью, поскольку люди больше задаются вопросом не языка, а о самой парадигме. В комментария я уже давал ответы на похожие вопросы по поводу работы структур, да и в статье это было.
Я правильно понимаю, что автор изобрёл https://en.wikipedia.org/wiki/MUMPS ?
open-source проект
что-то я ссылок на проект не наблюдаю
RTS — Реактивный язык программирования свободных структур данных