Сейчас думаю, что имеет смысл использовать английские термины, как самые международные. Но использовать их как своего рода естественный ключ, что в данном случае будет гораздо удобнее, чем какой нибудь GIUD или число.
Наверно в понятие «программирование на естественном языке» мы вкладываем разное понимание. Замена одних ключевых слов на другие (ЦИКЛ и КЦ), не далает такой язык естественным. Более того, на естественном языке хоть и можно описывать алгоритмы, но это далеко не единственное его предназначение.
Наверно мне следовало бы изначально более конкретизировать этот термин, т.к. все мы понимаем под ним что-то свое. Кто-то отсутствие необходимости уметь формализировать алгоритмы, кто-то замену одних терминов на другие, а третий устный диалоговый режим взаимодействия с компьютером.
Для меня ближе понимание именно третьего варианта, т.е. возможность коммуникации с компьютером без строгого формального синтаксиса и фиксированного набора ключевых слов, которые присущи почти каждому ЯП.
Язык разработчика — это его интерфейс со всеми деталями.
Мне кажется, что интерфейс к деталям, это структура классов и API объектов. А язык, это способ однозначной коммуникации между программистом и этим интерфейсом.
А про комментарии немного не согласен. Они имеют значение только в двух случаях, либо нужно изучить код с целью поиска бага, либо нужно изучить код понимания интерфейса к деталям реализации, если API отсутствует документация.
Для первого случая комментарии помогают редко. Конечно, если проблема не в выборе алгоритма реализации, когда в комментарии написано, что-то типа «сортировка пузырьковая и может тормозить на больших объемах данных». Ну а без документированного API действительно тяжело.
И как оценивать «правильность» комментария?
Согласен. Поэтому и предлагается отказаться от фиксированной лексики и зарезервированных слов, а выбирать их в зависимости от естественного языка пользователя.
Есть такое выражение «любая аналогия ложна».
Я не утверждал, а наоборот опровергал тезис, что на естественном языке может программировать любой, только нужно выучить алфавит.
В данном случае речь идет как раз о человеке, который умеет формализовать алгоритмы, но не знает языка. И вот в этом случае предложенный подход будет отличным выходом. Пусть пишет алгоритм на естественном языке, а с реализацией на конкретном языке можно не заморачиваться.
Промежуточные значения терминов безусловно придется использовать в том или ином виде.
Но мне кажется для этих целей не нужно придумывать отдельный язык символов или иероглифов. Будет достаточно использование уникального маркера, наличие бы которого и сигнализировало о том, что слово относится к внутренним терминам и его не нужно «переводить».
Большущее спасибо за развернутый комментарий!
Безусловно, пунктуация тоже не интернациональна, однако требуется выбрать какую нибудь точку отсчета.
Попробую ответить на высказанные замечания.
1. Отступы планируется использовать для форматирования списков (но реализация этого может быть сделана не с самого начала).
2. Фигурные скобки или обратные кавычки, это дело привычки. Может быть вы и правы, но данный момент не принципиальный и решается заменой двух символов в лексере.
3. Перевод строки используется для форматированных списков в несколько строк, а запятая для списков или разделения частей в одном предложении.
4. Динамическая грамматика — определенно! Причем грамматика рекурсивная с возможностью вложенного разбора.
5. Использование математических операторов сильно зависит от контекста. Минус как дефис, *- маркер списка и т. д.
6. Отмечать требуется для исключения неоднозначности с поиском псевдонимов и сокращений. Особенно с функциональностью игнорирования опечаток.
7. Нужно определить синоним системной переменной и склонять его как угодно.
8. Насчет приоритетов у символа @, незнаю, не обращал внимания на этот момент.
Что касается визуального программирования, то мне кажется, что его результат сложно сохранять в текстовом человекочитаемом виде.
Я с вами согласен, что для реальной разработки знаний условной домохозяйки будет мало, независимо от используемого языка (хоть родной, хоть C++). И это специально уточнили в одном из предыдущих комментариев про «не программиста».
Но если говорить не про полноценное программирование, а про приведенный вами пример с решением квадратного уравнения, то там школьных знаний будет вполне достаточно.
Замените «программистское» на «алгоритмическое».
Тогда вашу программу может сопровождать и дорабатывать не только программист на Билдере/Дельфи, а домохозяйка, которая объясняет сыну математику.
Причем не обязательно по русски, но и после преобразования на английском или эсперанто.
Сейчас я писал только про основные особенности, которыми должен обладать язык. Естественно, должны быть и библиотеки и IDE. И если сразу ориентироваться на реализацию в виде транспилера, а так же на возможность включения программных вставок на других языках, то с библиотеками не должно быть особых проблем.
А из основных применений видится следующие:
— Предметно ориентированное программирование за счет написания программ «не программистами». Фактически, это стирание грани между постановкой задачи (её текстовым описанием) и непосредственно написанием программного кода.
— Расширение и интернационализация открытых программных проектов за счет привлечения обычных пользователей, которые хотели бы внести свой вклад в развитие проекта, но не являются программистами или не знают используемого языка.
Уважаемая администрация Хабра, реализуйте пожалуйста «черный список авторов», чтобы из ленты можно было скрывать посты определенного автора (компании).
Вопрос поднимался уже давно qna.habr.com/q/154077, и продолжает оставаться очень актуальным, т.к. в рекламных материалах компаний рейтинговый механизм Хабра не работает в принципе, а видеть одно и тоже под разными соусами реально раздражает.
Уважаемая администрация Хабра, реализуйте пожалуйста «черный список авторов», чтобы из ленты можно было скрывать посты определенного автора (компании).
Вопрос поднимался уже давно qna.habr.com/q/154077, и продолжает оставаться очень актуальным, т.к. в рекламных материалах компаний рейтинговый механизм Хабра не работает в принципе, а видеть одно и тоже под разными соусами реально раздражает.
Можно попробовать почитать мотивирующую книгу или статью на хабре и потом приступить к работе.
Просто лежи и думай о проекте, как ты сделал бы ту или иную фичу. Если не получается об этом проекте — думай о том что ты вообще хотел бы написать.
Если на протяжении многих дней ты все время повышал продуктивность — неизбежно наступит момент, когда еще повысить ее уже невозможно (очень сложно). Это может расстраивать, в такой момент лучше устроить 1-2 выходных, чтоб обнулить результат и любой следующий день казался продуктивней.
Он выглядит как чёрно-белая плитка, через которую протекает сжиженный гелий — газ проходит через змеевик. При включении света «симулятор», как утверждают учёные, светит с интенсивностью в 20 раз выше солнечной (на каком расстоянии от светила, не указано), гелий поглощает тепло и вырывается из сопла, создавая таким образом реактивную тягу.
Я это понял, как обычный паровой двигатель, только в качестве нагревателя солнце (массив светодиодов), который нагревает рабочее тело — гелий.
Вот только в сомневаюсь в эффективности, поэтому скорее всего я что-то недопонял.
Наверно мне следовало бы изначально более конкретизировать этот термин, т.к. все мы понимаем под ним что-то свое. Кто-то отсутствие необходимости уметь формализировать алгоритмы, кто-то замену одних терминов на другие, а третий устный диалоговый режим взаимодействия с компьютером.
Для меня ближе понимание именно третьего варианта, т.е. возможность коммуникации с компьютером без строгого формального синтаксиса и фиксированного набора ключевых слов, которые присущи почти каждому ЯП.
А про комментарии немного не согласен. Они имеют значение только в двух случаях, либо нужно изучить код с целью поиска бага, либо нужно изучить код понимания интерфейса к деталям реализации, если API отсутствует документация.
Для первого случая комментарии помогают редко. Конечно, если проблема не в выборе алгоритма реализации, когда в комментарии написано, что-то типа «сортировка пузырьковая и может тормозить на больших объемах данных». Ну а без документированного API действительно тяжело.
И как оценивать «правильность» комментария?
Я не утверждал, а наоборот опровергал тезис, что на естественном языке может программировать любой, только нужно выучить алфавит.
В данном случае речь идет как раз о человеке, который умеет формализовать алгоритмы, но не знает языка. И вот в этом случае предложенный подход будет отличным выходом. Пусть пишет алгоритм на естественном языке, а с реализацией на конкретном языке можно не заморачиваться.
Но мне кажется для этих целей не нужно придумывать отдельный язык символов или иероглифов. Будет достаточно использование уникального маркера, наличие бы которого и сигнализировало о том, что слово относится к внутренним терминам и его не нужно «переводить».
Безусловно, пунктуация тоже не интернациональна, однако требуется выбрать какую нибудь точку отсчета.
Попробую ответить на высказанные замечания.
1. Отступы планируется использовать для форматирования списков (но реализация этого может быть сделана не с самого начала).
2. Фигурные скобки или обратные кавычки, это дело привычки. Может быть вы и правы, но данный момент не принципиальный и решается заменой двух символов в лексере.
3. Перевод строки используется для форматированных списков в несколько строк, а запятая для списков или разделения частей в одном предложении.
4. Динамическая грамматика — определенно! Причем грамматика рекурсивная с возможностью вложенного разбора.
5. Использование математических операторов сильно зависит от контекста. Минус как дефис, *- маркер списка и т. д.
6. Отмечать требуется для исключения неоднозначности с поиском псевдонимов и сокращений. Особенно с функциональностью игнорирования опечаток.
7. Нужно определить синоним системной переменной и склонять его как угодно.
8. Насчет приоритетов у символа @, незнаю, не обращал внимания на этот момент.
Что касается визуального программирования, то мне кажется, что его результат сложно сохранять в текстовом человекочитаемом виде.
Но если говорить не про полноценное программирование, а про приведенный вами пример с решением квадратного уравнения, то там школьных знаний будет вполне достаточно.
Тогда вашу программу может сопровождать и дорабатывать не только программист на Билдере/Дельфи, а домохозяйка, которая объясняет сыну математику.
Причем не обязательно по русски, но и после преобразования на английском или эсперанто.
В вашем примере, замените «Программист» на «Аналитик» или продвинутый пользователь, тогда будет все правильно.
А из основных применений видится следующие:
— Предметно ориентированное программирование за счет написания программ «не программистами». Фактически, это стирание грани между постановкой задачи (её текстовым описанием) и непосредственно написанием программного кода.
— Расширение и интернационализация открытых программных проектов за счет привлечения обычных пользователей, которые хотели бы внести свой вклад в развитие проекта, но не являются программистами или не знают используемого языка.
Вопрос поднимался уже давно qna.habr.com/q/154077, и продолжает оставаться очень актуальным, т.к. в рекламных материалах компаний рейтинговый механизм Хабра не работает в принципе, а видеть одно и тоже под разными соусами реально раздражает.
Вопрос поднимался уже давно qna.habr.com/q/154077, и продолжает оставаться очень актуальным, т.к. в рекламных материалах компаний рейтинговый механизм Хабра не работает в принципе, а видеть одно и тоже под разными соусами реально раздражает.
Вот только в сомневаюсь в эффективности, поэтому скорее всего я что-то недопонял.