Программировать на русском...

[vasek123]

Не знаю как вам, но по мне- так на Английском удобнее... ИМХО.

[Izhic]

Согласен с vasek123.
Английские слова более короткие,
и код выглядит более строго как то..
ну и плюс более простая возможность переноса кода.

[JTG]

Сообщение от Utkin

Я почти такой и собрал . Из своего скромного опыта могу сказать, что парсер не мега-наворченный, склонения можно обойти некоторым образом, а человечность можно ввести искусственно....

Ну вообще выглядит не так уж нелепо, как в начале темы) Смесь лиспа и паскаля, гг, интересно, что на это скажут truЪ-функциональные программисты?

[vasek123]

Сообщение от Izhic

Согласен с vasek123.
Английские слова более короткие,
и код выглядит более строго как то..
ну и плюс более простая возможность переноса кода.

В том как раз и дело.... Даже, если взять простенькую программу на С++(известную по моему, даже, чайникам)- то, получается полная чушь:

#подключаем< строки>
функция main()
{
      выводим строку на экран<< "Нажмите пожалуйста любую  
      клавишу для     завершения..."<<перевод строки;
      возвращаем 0;
}

[pu4koff]

Так пожалуй правильнее будет, но оригинал всёже лучше

#включить < строка > // или внедрить, вставить,...

целое главный()
{
      вывод << "Нажмите пожалуйста любую клавишу для завершения..." << конец_строки;
      возврат 0;
}

[Utkin]

Сообщение от JTG

Ну вообще выглядит не так уж нелепо, как в начале темы) Смесь лиспа и паскаля, гг, интересно, что на это скажут truЪ-функциональные программисты?

truЪ-функциональные программисты , на самом деле таких очень мало. Большинство языков такого типа следуют за Лисп, а он на самом деле далеко не чисто функциональный язык, в нем имеются механизмы, позволяющие некоторые командные примочки. Чистую функциональность Лиспу "приклеили" советские преподы (возможно по незнанию). Если читать зарубежные переводы - там нигде не сказано что Лисп чисто функциональный язык программирования.

Так пожалуй правильнее будет, но оригинал всёже лучше

Нет, оригинал от vasek123 звучит гораздо лучше, только еще одна поправочка
выводим строку на экран должна иметь варианты:
вывести строку на экран
отправить строку на экран

и еще парочку тех что сразу приходят на ум. Тогда программист не будет думать как выводить строки.... он их будет просто выводить

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

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

#используем< строки>
Глобальная функция ()
{
      выводим строку на экран<< "Привет Миру и всем остальным МКС! "<<перевод строки;
      Результат функции 0;
}

С по русски...

Согласен с vasek123.
Английские слова более короткие,
и код выглядит более строго как то..
ну и плюс более простая возможность переноса кода.

Izhic - строго от того, что Вы не используете смысла написаного, Вы просто его ЗНАЕТЕ. Грубо говоря, не понимаете что пишите - а это источник ошибок.
Схема работы следующая (но конечно всегда возможны некоторые вариации):
Вы читаете задание (в большинстве случаев на русском), составляете алгоритм (на русском) - вот вам источник логических ошибок, переводите алгоритм на язык программирования - источник логических и синтаксических ошибок.
Именно последний этап порождает очень много ошибок - я не помню типы аргументов функций, плохо представляю работу некоторых методов (потому что их имя не ассоциировано с действиями) и пр. Если избегать перевода, то у Вас изначально будут ассоциации: имя=действие - Вам требуется значительно меньше времени на восприятие (а программы чаще читают чем пишут), потому как часть этого языка Вы всегда практикуете в повседневной жизни, не связаной с программированием.

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

[pu4koff]

Сообщение от Utkin

truЪ-функциональные программисты , на самом деле таких очень мало.

Мне прямо интересно как получится паскаль с лиспом объединить. Почему-то мне кажется, что это невозможно. Если функциональный язык хочется получить, то никаких переменных, всё на константных данных должно быть.

Сообщение от Utkin

Нет, оригинал от vasek123 звучит гораздо лучше, только еще одна поправочка

Ну тогда всё надо писать в стиле описания действий: выполняем функцию ххх, присваиваем значение переменной, выходим из программы,...

Сообщение от Utkin

выводим строку на экран должна иметь варианты:
вывести строку на экран
отправить строку на экран

и еще парочку тех что сразу приходят на ум. Тогда программист не будет думать как выводить строки.... он их будет просто выводить

1) С пробелами в командах лексический анализатор ой как весело будет писать
2) Долго придется продумывать, чтобы не было двузначности толкования таких команд.
3) А мне может понятнее отсылать строку на экран и придется долго вспоминать какие именно слова поддерживает компилятор. Буду сидеть и вспоминать: да что ж за слово то... что-то вроде отослать, но не оно... ну вот на языке вертится, но никак вспомнить не могу...
А кому-то посылать строки нравится или печатать на экране...

Сообщение от Utkin

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

Я бы на это особо не расчитывал. Типы параметров - ограниченное множество и рано или поздно произойдёт пересечение. Придётся всякие пространства имён вводить и получится в итоге непонятная каша)

Сообщение от Utkin

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

А результат функции у меня не ассоциируется с тем, что произойдет выход из функции. В сях по return происходит завершение выполнения подпрограммы. В делфях по result не происходит выхода. Так что тут надо смотреть как именно реализовывать будете.
А перевод строки у меня ассоциируется с языковым переводом. Может компилятор такой умный будет, что строку на англицкий переведет...

Сообщение от Utkin

Izhic - строго от того, что Вы не используете смысла написаного, Вы просто его ЗНАЕТЕ. Грубо говоря, не понимаете что пишите - а это источник ошибок.

Ну почему же. Я, например, понимаю, что student.setFirstName("Иван") изменит имя студента, но для этого мне достаточно только знать синтаксис данного языка программирования и несколько слов из английского языка.

Сообщение от Utkin

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

Вы сможете написать компилятор, который будет понимать русский язык на хорошем уровне?
1) Не помню в русском языке знаков препинания типа << ; и т.д.
2) У каждого человека свой словарный запас и свой набор ассоциаций.
Для меня понятно слово цикл и что это значит. Для человека, увлекающегося астрологией цикл значит впервую очередь что-то другое. Можно заменить на что-то вроде повторить. Мол повторить много раз, но для меня повторить - это значит повторить что-то преддыдущее.
Бухают мужики стоят, выпили по стакану: "эх... хорошо пошла... повторим?", они же не говорят сразу: "давай повторим 2 раза выпивание стакана?".
В любом случае будет переход мыслей от исходной задачи к алгоритму на родном языке и далее уже к преобразования всего этого дела к синтаксису языка программирования.
В случае с англицким синтаксисом у меня нет такой каши, т.к. четкую границу могу провести между студентом, как объектом моделирования в программе и студентом, как модель данных.
Опять же придется во всех классах прописывать разные синонимы для методов. А то кто-то захочет произвести ремонт кузова, а кому-то кузовной ремонт подавай. Иначе так же думать и вспоминать придется, как же там правильно писать...

[pu4koff]

Сообщение от Utkin

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

Ну для этого нормально называть методы надо, ну и словарный запас англицкого языка небольшой собирать. И ежу понятно, что Insert вставляет новый элемент в коллекцию. А типы аргументов и так нужно будет помнить или вы позволите такое: Зачислить студента "Иванов И.И.", зачислить студента "Иванов", "Иван", "Иванович", зачислить студента 15 (по его номеру в списках) и т.д. ? Только чтобы разработчик классов сам об этом не думал, а то ведь только один вариант реализуют, а людям потом вспоминай что именно передавать надо.

Сообщение от Utkin

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

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

Сообщение от Utkin

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

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

[Utkin]

Сообщение от pu4koff

Мне прямо интересно как получится паскаль с лиспом объединить. Почему-то мне кажется, что это невозможно. Если функциональный язык хочется получить, то никаких переменных, всё на константных данных должно быть

.

Ну я не имею ввиду полное следование канонам функционального программирования. Скорей это Паскаль с вкраплениями Лиспа, а не наоборот.

Ну тогда всё надо писать в стиле описания действий: выполняем функцию ххх, присваиваем значение переменной, выходим из программы,...

Все правильно . Только еще разрешить и короткую форму, традиционного типа, так сказать y=f(х) - русский здесь не при чем, это математическая запись.

1) С пробелами в командах лексический анализатор ой как весело будет писать

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

2) Долго придется продумывать, чтобы не было двузначности толкования таких команд.

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

3) А мне может понятнее отсылать строку на экран и придется долго вспоминать какие именно слова поддерживает компилятор. Буду сидеть и вспоминать: да что ж за слово то... что-то вроде отослать, но не оно... ну вот на языке вертится, но никак вспомнить не могу...
А кому-то посылать строки нравится или печатать на экране...

Я уже это писал: включить общеупотребительные команды: и отправить и переслать и печатать пр. Парсер - программа, он проглотит.

Я бы на это особо не расчитывал. Типы параметров - ограниченное множество и рано или поздно произойдёт пересечение. Придётся всякие пространства имён вводить и получится в итоге непонятная каша)

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

А результат функции у меня не ассоциируется с тем, что произойдет выход из функции. В сях по return происходит завершение выполнения подпрограммы. В делфях по result не происходит выхода. Так что тут надо смотреть как именно реализовывать будете.
А перевод строки у меня ассоциируется с языковым переводом. Может компилятор такой умный будет, что строку на англицкий переведет...

Да, я подходил к этому из концепций Паскаля, пусть будет Ваш вариант.

Ну почему же. Я, например, понимаю, что student.setFirstName("Иван") изменит имя студента, но для этого мне достаточно только знать синтаксис данного языка программирования и несколько слов из английского языка.

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

Вы сможете написать компилятор, который будет понимать русский язык на хорошем уровне?

Нет, я слаб в компиляторах, я писал интерпретатор (но это не суть важно, внутренняя структура у них идентична). И еще один нюанс: написать компилятор можно, но сложно, причины также как и для Лиспа. Для него есть и компиляторы, но это не тривиальная задача.

1) Не помню в русском языке знаков препинания типа << ; и т.д.

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

2) У каждого человека свой словарный запас и свой набор ассоциаций.
Для меня понятно слово цикл и что это значит. Для человека, увлекающегося астрологией цикл значит впервую очередь что-то другое. Можно заменить на что-то вроде повторить. Мол повторить много раз, но для меня повторить - это значит повторить что-то преддыдущее.
Бухают мужики стоят, выпили по стакану: "эх... хорошо пошла... повторим?", они же не говорят сразу: "давай повторим 2 раза выпивание стакана?".
В любом случае будет переход мыслей от исходной задачи к алгоритму на родном языке и далее уже к преобразования всего этого дела к синтаксису языка программирования.

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

Далеко не всегда, насчет синонимов - близко к интерфейсам? Я от себя ничего не придумал и далеко не пионер в этой области.
Я рад, что заставил Вас задуматься над такими проблемами .

[Utkin]

Сообщение от pu4koff

Ну для этого нормально называть методы надо, ну и словарный запас англицкого языка небольшой собирать. И ежу понятно, что Insert вставляет новый элемент в коллекцию. А типы аргументов и так нужно будет помнить или вы позволите такое: Зачислить студента "Иванов И.И.", зачислить студента "Иванов", "Иван", "Иванович", зачислить студента 15 (по его номеру в списках) и т.д. ? Только чтобы разработчик классов сам об этом не думал, а то ведь только один вариант реализуют, а людям потом вспоминай что именно передавать надо.

Я уже писал, никто строго не следует этим принципам. Можно встретить программ где это не так очевидно. Это будет даже Ваш собственный код через год или два.

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

Коллекции это куча объектов и в программировании и в жизни .

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

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