Символьный язык программирования.

        Преамбула.
    В этом маленьком тексте я попробую описать идею, которая у меня родилась 
буквально вчера. Просьба сильно не пинать и, по возможности воздержаться от 
критики, если тема покажется Вам не интересной. Конечно, в дальнейшем без 
критики будет не обойтись, но на данном этапе она может только помешать.
    Оговорка. Каких-либо других наработок, кроме идей, на данный момент нет.
все будет пережевываться не одну тыщу раз, прежде чем появится то, что можно будет
действительно "заюзать".
    Зачем мне это ? Ни зачем. Но работать над проектом я собираюсь все свободное 
время. Это, для меня, действительно интересно.

        Немного о brainfuck
    Кратко рассмотрим язык под названием "brainfuck". Суть его, кто еще не в курсе - 
написание последовательности символов, которая выполняет какое-то одно действие. К сожалению
он имеет некоторые недостатки и недоработки. Данный язык может выполнять только примитивные 
операции и имеет мизерный набор символов. Максимум, что Вы можете сделать на нем - это вывод
приветствия ("Hello world !"). Однако, замечу, если бы для brainfuck была нормальная среда
разработки, его можно было бы использовать. Скажем огромная команда echo "Hello World" 
занимала бы не сотни строк кода на Си, а несколько символов на brainfuck. Подытожу недостатки 
brainfuck. Первое и самое главное - не серьезный подход к языку. Что и следует из названия.
Отсутствие среды разработки. По идее, все что надо для этого языка - редактор и симулятор.
Наличие встроенного симулятора в данном случае критично, ибо иначе для отладки приходилось бы 
вызывать не очень быструю команду, которая бы выполняла код... Так же к недостаткам нужно отнести
абсолютную минималистичность и "низкоуровненность".
    
        Проблемы современных языков.
    Во всех известных языках программирования используется такой подход. Есть команды.
которые состоят из слов. Прчем слова состоят из крайне мизерного запаса английских букв. Для 
команд приходится подбирать соответствующее команде слово. Это работает, если у вас пара тыщ строк
 кода. Это работает и дальше, но в какой-то момент наступает полный абздец. Английских слов просто 
начинает нехватать. Плюс трудно подобрать "правильнрое" слово. И пошло... Сначала команды из нескольких
слов, потом префиксы к командам. Потом документация по командам. Потом документация по префиксам....
В итоге получаем код, в котором надо разбираться самому разработчику.
    Следующие проблемы - необходимость "анализа" программы и компиляция в машинный код. Да,
программа после этого выполняется очень быстро, но в этом есть один очень неприятный момент. Всё это 
занимает драгоченное время программиста. Да и "отладка" кода порой убивает времени на порядок больше,
чем требовалось для написания самого кода.

        Что я предлагаю ?
    Я предлагаю разработать систему программирвония, в которой используются комбинации символов не 
одного английского языка, а всего спектра utf-8 символов. Исключая символы, которые трудны для восприятия.
К примеру - символы арабского, китайского, японского и аналогичных языков.
    К чему сведется программирование в итоге ? Программист будет выбирать нужный символ (при необходимости
читая документацию) и вставлять его в программу. Вывод сообщения вроде "Hello World" будет сводится к поиску 
(на первых порах) симовола-команды вывода текста, вставки его в программу, и дописывания нужной фразы "Hello World !"
    

Пока все,
Олег Пучинин.

Это сообщение отредактировал(а) GrayCardinal - 12.6.2011, 17:10

Не совсем понятно какие у этого плюсы, кроме компактных сорцев? Может их сжимать просто? Хотя сорцы обычно и так немольшие, кроме асма

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

Это сообщение отредактировал(а) GrayCardinal - 12.6.2011, 18:16

Как бы так помягче выразиться... идея несколько неудачна, причем этот факт давно экспериментально проверен. Посмотрите на APL.

Фантом, 
Отклонено 

GrayCardinal, привет.
Идея интересная, но:
1) самая большая проблема программирования - не ограничения я.п. в ракурсе длинны команд, или ограниченности именного пространства. самая большая проблема программирования обычно находится между стулом и клавиатурой ;-)
2) существует несколько инoй интересный метод программирования, который по-моему перпендикулярен родному языку программиста (см. MIT Scratch)
3) с т.з. координации работы разработчиков, по-моему нет более удобного метода, чем словесное или как минимум письменное (ужасно хуже первого) общение, поэтому для нечитабельных кусков кода - есть комменты.
4) для непонятно написанного кода существует код-ревью. это делается сразу после или сразу ДО коммитов. Ессно делается более крутым чем ты девелопером (я конечно понимаю, что разрабатывая код самому, в одиночку, очень трудно расщепить личность, и сделать себе самому код ревью. Это причина обычно очень медленного роста программистов-одиночек)
5) очень удивило от тебя, т.к. ты вроде бы и с руби и с питоном имел какое-то трение... неужели с т.з. читаемости кода они тебя не устроили ? и с т.з. расширяемости языка.... ?
6) стоит как-то проверить насколько широта диапазона разрешенных символов я.п. (и разрешенных слов) воздействует на вычислительную сложность парсинга (и его время) 
7) удачи!



Это сообщение отредактировал(а) bilbobagginz - 12.6.2011, 20:41

А как насчет таких платформ как Java и .NET, где в коде можно использовать символы юникода?
Хотя я, после просмотра кода одной программки, за такое руки бы поотрывал, так как там были намешаны идентификаторы типа
newПокупатель и текущийDbConnection... Понятно что у автора с мозгами не лады, но все равно осадочек остался... 

kosmonaFFFt, 
Вы говорите я системах, где можно использовать _слова_ состоящие из любых букв. Я предлагаю (практически) полностью забить на слова и использовать символы. Везде. В командах, именах(символах) переменных etc. То есть речь идет о принципиально другом подходе.

В связи с личными проблемами выпуск ноль первой версии проекта временно откладывается... Приношу свои извинения.

            На чем будет реализована система.

    Прояснился следующий аспект разработки системы символьного языка. Сам интерпретатор будет разрабатываться на GoLang.  Выбор пал на него по нескольким причинам. Во-первых он быстрый и компилируемый. Плюс программы Гоу линкуются статически. Т.е. Вы сможете запускать интерпретатор сразу после загрузки ядра Linux. Так же язык Гоу достаточно высокоуровненный, что даст интерпретатору символьного языка те же свойства. На символьном языке можно будет писать как низкоуровневые так и высокоуровневые приложения с одинаковой легкостью. 
    Сама среда разработки будет писаться на Qt4. Просто на Qt4 можно сделать все что нужно. В среде не будет своего редактора. Будет использоваться любой доступный редактор от Vi и до LibreOffice. Взаимодействие среды с редактором будет осуществляться — через удаленное управление для Gvim и через dbus для остальных редакторов, поддерживающих эту шину (а это почти все).

Пока все.
Ваш.
Олег.

что самое страшное - что этот Олег сядет и сделает.
    

bilbobagginz, и дай бог, чтобы у него не было администртивного ресурса для продвижения написанного...

1000000dollars, 
Надо будет - сами продвинут...

GrayCardinal, 
теорема:
использование всего диапазона символов UTF8 в качестве символов языка не возможно при существовании схожих символов разных регистров (тут регистр = диапазон карактер сета какого-то языка "Х")

доказательство (на пальцах с элементами "от противного"):
для программирования нужны объекты хранения и команды с наименованиями (именное пространство)
для работы в именном пространстве нужно представления наименований в компьютере.
оставим команды языка, но для программирования нужна реализация "переменных",
т.е. штук, в которых мы можем хранить что-то в разные моменты запуска программы.
для этого нужно определение переменной, как единицы хранения.
в современных языках программирования принято определять переменные двумя измерениями (как минимум):

• именем
• адресом

т.к. разные переменные могут указывать на один и тот же адрес (разного рода ссылки), 
нужна уникальность имен переменных.

Уникальность переменных нужна для:

• программиста, для понимания и поддержки кода
• программы-переводчика текста программы в запускаемый код/данные (т.е. интерпретера/компилятора)

все свыше - это "Дано:"

При использовании более чем одного регистра юникода с одинаковыми по внешнему виду символами, 
свойство внешней уникальности имен теряется.
Человек по внешнему виду не знает какой символ у него перед глазами: 
о из латинницы, или кириллицы? 
п из кириллицы или из греческого алфавита ?
Естественно, при возможности ввода таких внешне схожих символов можно получать переменные, 
которые выглядят одинаково, но по сути (и strncmp()) разные.

Но к ступору и истерике это приводит не компьютер, а человека.

Напр. понять из ошибки, что переменная "кака" != "кaкa" (слева версия с обеими 'а' из кириллицы, а справа - буквы 'а' из латинницы)
практически ... невозможно (можно, но мы же не будем, в процессе работы преобразовывать имя каждой перменной в массив байтов!)

Более того, такого рода ошибки будут вноситься, и отнимать не мало времени в отладке.

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

Поэтому придется остаться с ограниченным списком символов. 
Что интересно - как раз похожие регистры (напр. европейских языков) мешать нельзя. 
Можно мешать только очень внешне разные, напр. русский+китайский+иврит+арабский.
даже греческий не используешь, т.к. там есть буквы, похожие на кириллицу.

Грубо говоря "что и требовалось доказать".
(в математике обозначается черным квадратиком):
■

Это сообщение отредактировал(а) bilbobagginz - 17.6.2011, 10:10

bilbobagginz, 
Благодарю что подключился  (осмысливаю вышесказанное)

■


Это сообщение отредактировал(а) GrayCardinal - 17.6.2011, 02:16

Первый вариант решения описанной bilbobagginz, проблемы:
Все одинаковые буквы разных регистров будут синонимами. То есть одна команда. А,а,a,A - суть одно и тоже. Как хочешь так и пиши... (здесь первые две буквы -русские, вторые - английские). До синонимов дойдем, но на данном этапе они не нужны...

Добавлено через 3 минуты и 19 секунд
Второй вариант решения той же проблемы - специальный инструмент среды, который всегда подскажет какие именно коды стоят в данной строчке...

Добавлено через 3 минуты и 58 секунд
■
(текст)

Поправка. Среда будет разрабатываться на Java... К сожалению я ее пока плохо знаю, но это поправимо...

Добавлено через 56 секунд
■
(форум не воспринимает данный символ как текст, приходится что-то лишнее дописывать) 
(халтура, товарищи !!!)

Ну раз уж на то пошло, то могу уверенно сказать, что если мне показать китайский иероглиф, а через две минуты показать другой я не смогу с уверенностью ответить это тот же иероглиф или нет. Думаю, что для китайцев будет так же. В этом плане английский луче по ряду причин: он везде одинаковый (не зависимо от кодировки - первые 127 символов ASCII зафиксированы), он является языком международного общения, следовательно его знают и в Китае (а следовательно визуально те же "Q" и "O" не спутают), в третьих: символьный язык получится write-only, представь brainfuck (который, кстати, является Тьюринг-полным) в котором допустимы 2 166 912 символов из которых, кстати, разных только 2 097 152 - остальные маппятся в существующие - то есть являются одними и теми же, а не просто выглядят так же (про выглядят, кстати, тоже всё относительно - вряд ли нерусскоязычные поймут тонкую разницу между "и" и "й" или с каким-нибудь другим диакритическим знаком).

Честное слово, проще разобраться с длинными именами на английском языке, чем с короткими на "лунном языке".

GrayCardinal, я там дописал идею:
ты сначала придумываешь некрасивый спек "хочу все символы"
а потом подставляешь ему костыли (тулзу, которая будет определять синонимы)
проблема остра:
на первом этапе (1 файл, 1 программа) - это еще легкий костыль (т.е. не очень много кода).
а на втором этапе( когда в программе происходит запуск нескольких файлов), напр. написанных несколькими людьми.
в такой ситуации нужно будет твой синонимизатор расширить до довольно толстых размеров, чтобы проверить - когда синонимы - это вообще реально синонимы.
по моему "требование" что команда/переменная может быть на любом языке в 1 файле - не красиво. надо думать.

1000000dollars, 
Мнение принял. Спасибо. Обдумываю.

■

Добавлено через 2 минуты и 1 секунду
bilbobagginz, 
Костыль был как "вариант решения проблемы". (акцент на "вариант"). Вообще я думаю, конечно. На досуге все перечитаю. Пока ковыряю NetBeans/Eclipse...

■ 

кстати у Казимира Малевича тоже был прикольненький квадратик..

Предлагаю свернуть разработку. Причина: проблемы имен фактически не существует. Мне доказали. Могу сделать это Вам.

Ваш.
Олег.

Так. Стоп. Последнее предложение отменяется. Разработка будет идти полным ходом. Поступили новые оперативные предложения...

Добавлено через 17 секунд
PS
Про предложения чуть позже. Извините.

Добавлено через 1 минуту и 10 секунд
■  

Разработка свернута. Приношу свои изменения.

пожалуйста докажи.



Это сообщение отредактировал(а) bilbobagginz - 21.6.2011, 22:33