DRAKON.SU

Текущее время: Вторник, 03 Декабрь, 2024 18:32

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 9 ] 
Автор Сообщение
СообщениеДобавлено: Пятница, 27 Ноябрь, 2020 10:49 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
Коллеги!

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

1. Записываем команды сверху-вниз.
- входные переменные и значения наверху
- вызовы функций в середине
- выходные переменные внизу
2. Добавляем иерархию.
3. Следуем правилам дракона: убираем зрительный шум, применяем прямоугольные формы.



Фильмик: https://www.youtube.com/watch?v=K95V6sfYTFM

Прошу высказаться.

Вложение:
nassi-drakon.png
nassi-drakon.png [ 244.57 КБ | Просмотров: 13569 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Ноябрь, 2020 14:11 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1360
Плохое предложение.

Слишком много условностей, взамен естественной записи на языке программирования.

Так как, Вы же должны знать язык программирования, предложенные условности являются лишними.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Ноябрь, 2020 19:58 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
This is an excellent step in the right direction.
I myself found drakonLua and drakonJS unnatural at first, despite the unified syntax and relative lack of syntax. I assure everyone that after 8 hours of intense use, it feels more natural than lua or js syntax, and it takes much longer to acclimate back to lua or js syntax afterward. It just takes some adaptation.

This is probably going to be same thing. It will take some time to adjust to reading diagrams written in this manner but in the end will be faster. I don't think this is its final form though.

Изображение

Something like this is much better, especially this image

Изображение

There is no reason function names cannot have whitespace in drakon editor, and be converted to camelCase or under_score style at build time. There is no reason such names cannot have images as prefixes either.

Some functions which are used all the time, like logic operators or statement assignments, should have their own stylized version of a question or action icon. To the editor, the icons won't be any different than normal question or action icons, but to the human user, it will be of great help to distinguish them with 'syntax sugar', in diagram form, like the image above.

A major criticism I have though with the proposed syntax is that function names are underneath their operators, this is unnatural. Humans are used to reading from the top down, and usually left to write. Why not put function names above their operators, and also encompass the operators in a rectangle of a lighter color that the function name is to show its scope?

I think the reason the author created the way it is, is it shows the sequential steps taken by the expression at the top, but this would be like putting the body of a function above its name. When reading any icon we are concerned primarily with its name, not what it is going to do or in what order.

The most important thing I can say is that in order to have a good new syntax, you must start with good code. Including multiple steps in one icon is bad practice. It is the same problem as having a function that does two things. The silhouette is a bandaid for this problem. A better solution is to simply abstract out each step into their own diagram. It takes more time to write diagrams this way, but is easier to read.

For example,
Код:
randomString = Math.floor(Math.random(0, 100) * 200)

should become
Код:
randomNumber = getRandomNumberBetween(0, 200)

then inside the getRandomNumberBetween diagram, two action icons, one for each step
Код:
number = Math.random(min, 100) * max

Код:
flooredNumber = Math.floor(number)


By writing code like this it is easier to read, refactor, and structural editors really shine when every step is separated out because it is easier to build tooling around singular things happening in one icon.

Additional notes:
I don't think having text with varying colors is a good idea, because it makes it harder to come up with dark vs light themes.
White text on blue background is hard to read, etc.
Text should all be one color, only background colors should change.
If you want to indicate that text is different, prefix it with an image (like the blue circle). Font colors have a limited range before you run out of colors that work. Prefixed images will never run out even if you have 1000 use cases for a new image.

You can greatly reduce vertical height and complexity of icons by using image prefixes as they do not require large rectangles which require whitespace padding, adding more empty space and making it harder to fit more information on screen. Images also express meaning more intuitively than colors.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Ноябрь, 2020 20:55 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5944
Откуда: Москва
автоперевод
Luke Alan писал(а):
Это отличный шаг в правильном направлении.
Я сам сначала нашел drakonLua и drakonJS неестественными, несмотря на унифицированный синтаксис и относительное отсутствие синтаксиса. Я уверяю всех, что после 8 часов интенсивного использования он кажется более естественным, чем синтаксис lua или js, и после этого требуется гораздо больше времени, чтобы привыкнуть к синтаксису lua или js. Просто нужна некоторая адаптация.

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

Изображение

Что-то вроде этого намного лучше, особенно это изображение

Изображение

Нет причин, по которым имена функций не могут иметь пробелы в редакторе drakon и преобразовываться в стиль camelCase или under score во время сборки. Также нет причин, по которым такие имена не могут иметь изображения в качестве префиксов.

Некоторые функции, которые используются постоянно, например логические операторы или назначения операторов, должны иметь собственную стилизованную версию вопроса или значка действия. Для редактора значки не будут отличаться от обычных значков вопросов или действий, но для человека-пользователя будет очень полезно различать их с помощью «синтаксического сахара» в форме диаграммы, как на изображении выше.

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

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

Самое важное, что я могу сказать, это то, что для того, чтобы иметь хороший новый синтаксис, вы должны начать с хорошего кода. Включение нескольких шагов в один значок - плохая практика. Это та же проблема, что и функция, которая выполняет две функции. Силуэт - перевязка от этой проблемы. Лучшее решение - просто выделить каждый шаг в отдельную диаграмму. Такой способ написания диаграмм занимает больше времени, но его легче читать.

Например,
Код:
randomString = Math.floor (Math.random (0, 100) * 200)

должен стать
Код:
randomNumber = getRandomNumberBetween (0, 200)

затем внутри диаграммы getRandomNumberBetween два значка действий, по одному для каждого шага
Код:
number = Math.random(min, 100) * max


Код:
flooredNumber = Math.floor (number)


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

Дополнительные примечания:
я не думаю, что текст с разными цветами - хорошая идея, потому что это затрудняет создание темных и светлых тем.

Белый текст на синем фоне плохо читается и т. Д.
Весь текст должен быть одного цвета, должны меняться только цвета фона.

Если вы хотите указать, что текст отличается, поставьте перед ним изображение (например, синий кружок). Цвета шрифта имеют ограниченный диапазон, прежде чем у вас закончатся работающие цвета. Изображения с префиксом никогда не закончатся, даже если у вас есть 1000 вариантов использования нового изображения.

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



Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Ноябрь, 2020 05:38 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
Here is a mockup of what I envision a function call to a fibonacci function might look like. This is just a fancy 'action icon'.

Изображение

The name of the function is Fibonacci, the title at the top. This would be editable text hence the indented graphic.
The name is prefixed by a universal 'function' icon. If a user sees this icon they know a function name is to the right of it. There is no need for () syntax.

The parameters follow the function call below, one by one, in this case there is only one parameter. The user could remove it by clicking the "x", or add another parameter by clicking the "+".

The type expected for the first parameter is shown with a blue circle icon to indicate 'integer', as well as a text label stating so making it abundantly clear. This is read only. To the right, there is an edit box where placeholder text `n` exists and can be changed to some integer. Any invalid input such as a floating point number or a string is not allowed in this box, and its border would ideally turn red.

In the future, it would be ideal if these parameters auto-populate based on the function definition diagram. If there is no function definition diagram, it would be ideal if one was created automatically and live-updated to reflect the function invocation diagram based on its name and parameters the first time it is created.

Subsequent changes to a function definition or invocation icon should highlight in red if the number and type of parameters do not match between the definition and the invocation.

This is just a mockup of a simple action icon. A question icon would be very similar, except it would have a different border color, perhaps yellow instead of blue, and a different border shape, such as a perfect rectangle rather than a rounded rectangle.

The question icon would have an edit box in the title just like the action icon, but if the text in the editbox matched certain strings, such as drop down box, letting the user select the conditional operator, such as Less Than, Greater Than, Equal To, Less Than or Equal To, .. and so on, the icon would automatically change to reflect the conditional operator chosen, and the parameter count would be fixed to 2. It might be comparing two integers, or it might be comparing two variables, or an integer or a variable. The question icon title could also be a function call to another diagram which returns a boolean rather than a built in expression, such as 'Is Alive?' as the function for the question icon to run to evaluate, which may or may not have parameters below. In this case, the icon would remain a function icon and the only difference would be the border color and the border silhouette.

Изображение

The above is an example mockup of a question icon which evaluates to true or false depending on true/false orientation, only if all parameters are equal to each other (AND operator).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Ноябрь, 2020 09:37 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5944
Откуда: Москва
Luke Alan писал(а):
Вот макет того, как, по моему мнению, может выглядеть вызов функции функции Фибоначчи. Это просто причудливый «значок действия».

Изображение

Имя функции - Фибоначчи, заголовок вверху. Это будет редактируемый текст, следовательно, изображение с отступом.
Имя предваряется универсальным значком «функция». Если пользователь видит этот значок, он знает, что имя функции находится справа от него. В синтаксисе () нет необходимости.

Параметры следуют за вызовом функции ниже, один за другим, в этом случае есть только один параметр. Пользователь мог удалить его, щелкнув «x», или добавить другой параметр, нажав «+».

Тип, ожидаемый для первого параметра, показан значком синего круга, обозначающим «целое число», а также текстовой меткой, что делает его предельно понятным. Это только для чтения. Справа находится поле редактирования, в котором существует текст-заполнитель `n`, который можно изменить на некоторое целое число. Любой недопустимый ввод, такой как число с плавающей запятой или строка, в этом поле не допускается, и его граница в идеале должна стать красной.

В будущем было бы идеально, если бы эти параметры автоматически заполнялись на основе диаграммы определения функции. Если нет диаграммы определения функции, было бы идеально, если бы она создавалась автоматически и обновлялась в реальном времени, чтобы отражать диаграмму вызова функции на основе ее имени и параметров при первом создании.

Последующие изменения в определении функции или значке вызова должны выделяться красным цветом, если количество и тип параметров не совпадают между определением и вызовом.

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

Значок вопроса будет иметь поле редактирования в заголовке, как и значок действия, но если текст в поле редактирования соответствует определенным строкам, таким как раскрывающийся список, пользователь может выбрать условный оператор, такой как «Меньше, чем», «Больше, чем», Равно, Меньше или Равно и т. Д., Значок автоматически изменится, чтобы отразить выбранный условный оператор, а счетчик параметров будет зафиксирован на 2. Это может быть сравнение двух целых чисел или сравнение двух переменные, целое число или переменная. Заголовок значка вопроса также может быть вызовом функции другой диаграммы, которая возвращает логическое значение, а не встроенное выражение, например «Is Alive?». в качестве функции для значка вопроса, запускаемого для оценки, которая может иметь или не иметь параметры ниже. В этом случае,

Изображение

Выше приведен пример макета значка вопроса, который оценивается как истина или ложь в зависимости от ориентации истина / ложь, только если все параметры равны друг другу (оператор И).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Ноябрь, 2020 18:37 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
Here is an assignment action icon mockup, how it would be written in drakonLUA or drakonJS before is also included below

Изображение

Код:
Result = Fibonacci
    20


or more traditionally,

Код:
Result = Fibonacci(20)


suggestions:
Get inspiration from Lisp language, where everything is an s-expression, functions are prefixed with their operators and this is always constant underneath the hood, so it's easy to build tooling for in an IDE

Lisp is probably the 'least syntax' language, as it's all based on position. The hard part is remembering what position means what, which is where visual cues aid the user, like images or read-only labels which auto populate, or dropdowns which are auto-completed.

(add 5 6)
11
(+ 5 6)
11
(* 5 6)
30
(Fibonacci 20)
6765
(Assign Result (Fibonacci 20))
Result = 6765

At first a function like add which only accepts numbers as arguments seems limiting, since you can no longer use infix arithmetic. But the solution is simple, create a function called infix which evaluates an infix expression and takes numbers as well as mathematical operators as arguments, like this

(Infix 5 + 6)
11

With visual cues, it becomes much easier to work with s-expressions, and it will be very structurally consistent, no special cases

Here is a factorial function written in lisp

Код:
(function (factorial n)
  (if (less-than-or-equal-to n 1)
    1
    (multiply n (factorial (subtract n 1)))))


as you can see the only syntax are parentheses, which in diagrams would be abstracted by icons and other visual cues. All of the hidden control flow and type information would be exposed by visual cues also.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Ноябрь, 2020 19:54 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5944
Откуда: Москва
Luke Alan писал(а):
Вот макет значка действия назначения, как он был бы написан на drakonLUA или drakonJS раньше, также включен ниже

Изображение

Код:
Результат =
20 Фибоначчи


или более традиционно,

Код:
Результат = Фибоначчи (20)


предложения:
почерпните вдохновение из языка Lisp, где все является s-выражением, функции имеют префиксы с их операторами, и это всегда константа под капотом, поэтому легко создать инструменты для IDE

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

(добавить 5 6)
11
(+ 5 6)
11
(* 5 6)
30
(Фибоначчи 20)
6765
(Назначить результат (20 Фибоначчи))
Результат = 6765

Сначала такая функция, как add, которая принимает только числа в качестве аргументов, кажется ограничивающей, поскольку вы больше не можете использовать инфиксную арифметику. Но решение простое: создайте функцию под названием infix, которая оценивает инфиксное выражение и принимает числа, а также математические операторы в качестве аргументов, как это

(Infix 5 + 6)
11

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

Вот факториальная функция, написанная на lisp

Код:
(функция (факториал n)
(если (меньше или равно n 1)
1
(умножить n (факториал (вычесть n 1)))))


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Ноябрь, 2020 22:51 

Зарегистрирован: Пятница, 18 Январь, 2019 12:03
Сообщения: 52
Цитата:
3. Следуем правилам дракона: убираем зрительный шум, применяем прямоугольные формы.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 9 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB