Во-первых о визуальном и текстовом подходах:У обоих подходов есть плюсы и минусы, поэтому должна быть возможность пользоваться и тем, и другим.Например, справа от консоли/поля ввода можно отображать (вертикальный) список всех доступных команд, или операндов, предоставляя возможность курсором выбрать нужную, а при начале ввода команды отображать список команд, начинающихся с введённого текста, с возможностью выбрать нужную команду стрелками вверх/вниз.Стоит отметить, что при наличии списка всех доступных команд можно не учить язык вовсе, а при нарушении правил формальной логики оповещать моментально.К интерпретатору.Под интерпретатором я подразумеваю переводчик+визуализатор кода.Задачи интерпретатора:1. Переводить человеческий на программный и обратно (http://pastebin.com/wmnkFq9Q).2. Дополнять код.2.1 объявлять не объявленные переменные.3. Визуализировать код.3.1 Выделять условия, блоки и т.д. рамками/фонами.3.2 Возможность вставлять изображения, рисовать, прятать код в рисунки.3.3 Возможность отображать части кода не последовательно.Ваши идеи?
>>748665 (OP)>(http://pastebin.com/wmnkFq9Q).http://pastebin.com/wmnkFq9Q
>>2016Печатать программы на клавиатуре.
>>748778функции проще всего печатать на клавиатуре.а интерфейс – ясно дело, создавать визуально,
Когда ты немого покодишь, "научишься программировать", то быстро понимаешь, что крутить мышкой, искать блоки, тягать их туда-сюда и рисовать стрелочки - это слишком медленно и раздражает. Погугли scratch (визуальный язык/конструтор от мит), и напиши на нём что-нибудь относительно немаленькое, вроде платформера с врагами, возможностью стрелять, прыгать и подбирать предметы. Ты взвоешь уже через десять минут.
>>748980Он вообще не об этом.
>Например, справа от консоли/поля ввода можно отображать (вертикальный) список всех доступных команд,Чем это лучше автодополнения? >Переводить человеческий на программный и обратно Программный и есть человеческий. Машинам, внезапно, удобнее машинный код.>3.2 Возможность вставлять изображения, рисовать, прятать код в рисунки.Ты придумал ipython notebook.
>>748980не понял в чём ты подразумеваешь разницу между "крутить мышкой, искать блоки, тягать их туда-сюда" в обычном текстовом редакторе и тем же в среде программирования из моей идеи.рисовать стрелочки – это просто удобство для визуального представления, которым необязательно пользоваться.
>>749049А, по-моему, об этом. Только ещё существующее хрен знает сколько лет автодополнение прикрутил.
>>749052>Чем это лучше автодополнения? >Стоит отметить, что при наличии списка всех доступных команд можно не учить язык вовсеможно вообще работать исключительно курсором.>>749052>Программный и есть человеческий.Программные не дотягивают до человеческого, взять хотя бы обязательность наличия скобок, или "==" вместо "=", посмотри ссылку >>748669>>749052>Ты придумал ipython notebookдогадываюсь, что это для python, а не для любого языка. И придумал я больше, чем возможность работать с картинками.
>>749095как можно не отличать простое автодополнение от списка всех возможностей…возможности это то, в чём смысл программирования вообще.
А это не тот же ОП?>> 744461
>>749214Бля обосрался>>744461 (OP)
>>749214Нет.Тот о визуализации онли, а я о программировании на человеческом.
>>749217Ну, может ты передумал
>>749242Визуализация это очевидно нужная вещь, но это дополнение к программированию, а не её основание.
Самое годное что ты заметил, ОП, это отображение что можно сделать. Когда я нахожусь в определенном месте кода, должен возникать определенный контекст, и от него зависит что конкретно я могу добавить. Конечно можно кататься еблом по клавиатуре, но количество корректных кубиков ввода ограничено. В данном случае less is more.То есть сбоку от кода должен возникать список корректных конструкций. Стандартные конструкции + контекстные. Стандартные разделяются на стейсменты и экспрешены, когда ты в контексте экспрешена стейтменты из окна контекста изчезают. Рядом с контекстными конструкциями есть хоткеи для их быстрого ввода.Запретить печатать код напрямую, составлять вместо этого его из кубиков. Например, нужно создать сравнение. Сначала вставляем экспрешен "=", затем слева и справа от него появляются СЛОТЫ, в которые можно вставить выражения.
Что не так в "человеческом языке". Твоя интерпретация и современный код несут примерно одну и ту же плотность информации. Более того - ты заменил одно слово несколькими, размазав информацию еще больше. Простая замена слов не облегчит восприятия кода. Более того - конструкция for выделяется из остального кода и можно сразу ее выделить просто при скроллинге.Я думал над этим и пришел к выводу что лучше заменить стандартные конструкции иконками. Картинки несут еще большую плотность информации чем слова и можно стандартизировать иконки точно так же как и дорожные знаки. Конечно, это только затронет стандартные структуры, для остального нужно использовать именование. Вообще, имена это фундаментальная проблема программирования http://stackoverflow.com/questions/421965/anyone-else-find-naming-classes-and-methods-one-of-the-most-difficult-part-in-prhttps://www.quora.com/Why-is-naming-things-hard-in-computer-science-and-how-can-it-can-be-made-easierтак как каждая программа создает отдельный чукотский диалект и программист должен держать в своей голове сотню языков ебаных туземцев.Я думал над этим и пришел к выводу что мы фактически уперлись в ограничение письменного языка. Когда-то язык был самым важным изобретением человечества. Теперь он устарел, и нужно найти более эффективные способы выражать свою волю.
>>749565>Простая замена слов не облегчит восприятия кода.конечно облегчит, если код станет более человечно-читабельным.>конструкция for выделяется из остального кодаа при замене слова "for" на "перебрать" не выделяется?>>749565>можно стандартизировать иконки Любая стандартизация – ограничение свободы воли программистов.Есть возможности hardware – пусть ОС предоставляет список всех доступных команд СОФТУ, а в софте (в т.ч. для создания программ) этот список команд должен отображаться уже как пользователям угодно, т.е. максимально индивидуально.Вместо этого люди придумывают большое кол-во языков программирования… В то время как надо просто сделать своеобразный переводчик с пользовательскими словарями, в которые все смогут добавлять свои варианты, при этом можно собирать инфу о самых популярных вариантах.
таки в энтерпрайзе существуют всякие пеги, и вроде норм
>>749543Проблема в том, что с твоей идеей с кубиками - мы получаем синтаксические дерево.А у него пиздецки растут ветки лавинообразно, ну ты понел - сотни и тысячи стрелочек и линий.Собсно, это почему я ненавижу блок-схемы - даже простейшую вещь сложно нарисовать - стрелки, фигуры и ответвления растут лавинообразно, пересекаются - и т д.А код - он растет только по вертикали, в ширину же можно укладываться в 80 символов, что хорошо вписывается в формат бумажных листов и мониторов.
>>750016потому любая визуализация должна быть лишь дополнением.к примеру можно отображать в функциях кнопки перехода к тем местам кода, где она вызывается, по наведению на которую можно даже разворачивать ту часть кода (как с постами на дваче),
>>750109Так это было еще в 95 году в каком-нибудь Source Insight. И где теперь этот Source Insight?
>>750149удобства могли много где быть, а то, что среды программирования с удобствами стали неактуальными не умаляет сами удобства,
>>749096>догадываюсь, что это для python,Изначально да, а сейчас уже для чего угодно бэкэнды есть.
>>750192так или иначе, возможности изображений – ерунда, по сравнению с меню возможностей и программированием на человеческом.
