Ремесло программиста

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Валентина » Описание языка


Описание языка

Сообщений 1 страница 30 из 63

1

Пока не полное и недописанное. Со временем я буду его обновлять.
https://yadi.sk/i/kAcCS1LB3KxxJt

2

utkin написал(а):

Идентификатор_на_национальном_языке=Идентификатор_на_английском

Идентификатор_на_национальном_языке=Идентификатор_на_русском (на худой конец - на арабских цифрах, если вы сообщник ИГИЛ (запрещена в РФ))

И ещё хочу описание RAII (управления временем жизни систем)

3

Идентификатор_на_национальном_языке=Идентификатор_на_русском (на худой конец - на арабских цифрах, если вы сообщник ИГИЛ (запрещена в РФ))

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

И ещё хочу описание RAII (управления временем жизни систем)

Конструкторы явные, деструкторы неявные. Система существует в рамках программного блока. То есть если Вы выходите из функции, все ее переменные будут удалены автоматически и корректно, потому что объекты настоящие, а не ссылки. При создании экземпляра класса создаются все поля без указателей. То есть если грубо говоря, Вы создадите список, то он реально будет содержать объекты, а не являться списком указателей. Соответственно и при копировании объекта копируется объект, а не ссылка на объект, это медленно, но нужно. Например, в Питоне специально есть метод целикового копирования объекта. Такое поведение позволяет строить универсальный деструктор для любого возможного объекта в данной модели вычислений. Если вам нужна манипуляция с ссылками Вы можете строить искусственные индексы сами, но без прямого доступа к памяти (то есть как в массивах), прямое расположение объекта в памяти недоступно для программиста.

4

To, chto ty govorish - eto verno. No nepravilno.

Да. Неправильно, но верно. Я открыт для диалога. Предложите другой вариант. Как Вы видите решение вопроса. Пока эта часть проработана теоретически и все можно исправить (в смысле реализации еще нет и все возможно).

5

utkin написал(а):

Поэтому перевод предполагается гонять туда.

Могут возникнуть проблемы документации. Тогда должна быть полная англоязычная версия/две версии документации.

знающих английский на порядок больше.

Так и англоязычных ЯП на порядок больше.

6

utkin написал(а):

Я открыт для диалога. Предложите другой вариант.

Предлагаю: выкини к Х...ям (это распространённая фамилия в Китае) весь английский,
сделай на русском конфетку для начала.

Отредактировано ВежливыйЛис (2017-07-12 16:18:35)

7

ВежливыйЛис написал(а):

выкини <...> весь английский<...> для начала

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

8

MihalNik написал(а):

сразу не получится

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

а utkin даже на первый этап не согласен. Пусть для начала ник кириллицей напишет...

Отредактировано ВежливыйЛис (2017-07-12 15:46:18)

9

0) Документация по-русски

ВежливыйЛис написал(а):

даже на первый этап не согласен.

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

10

MihalNik написал(а):

Засорили-то всю тему)

зато у меня убедительность +1 :

utkin написал(а):

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

А если не имеет, то зачем вообще весь этот сайт? Java тоже неплохо работает...

Если вам так важна ваша англиская локализация - просто сделаете её как локальную версию потом.

Отредактировано ВежливыйЛис (2017-07-12 16:08:07)

11

utkin написал(а):

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

Однако, остаётся ли возможность поверхностного копирования или надо всегда применять индексы?
Т.е. всегда ли потребуется обёртка - обязательное помещение в общий сборник-массив и обращение по индексу?

12

Могут возникнуть проблемы документации. Тогда должна быть полная англоязычная версия/две версии документации.

Да и я не нашел пока никакого решения.

Да мы это так, разговор поддержать :D
Но с документацией работы больше.

А я серьезно. Если это важный вопрос, значит его нужно рассматривать.

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

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

а utkin даже на первый этап не согласен. Пусть для начала ник кириллицей напишет...

Он у меня давно, по нему определяют, что я это я. Собственно это и есть основная проблема всех иностранных заимствований.

Java тоже неплохо работает...

Джава построена на других принципах.

Однако, остаётся ли возможность поверхностного копирования или надо всегда применять индексы?
Т.е. всегда ли потребуется обёртка - обязательное помещение в общий сборник-массив и обращение по индексу?

Нет. Это просто как пример был. Речь там о другом шла, изначально как таковых индексов вообще нет, это если нужно имитировать ссылку на посторонний объект.
Переменные есть деревья. Сразу из коробки по умолчанию. То есть Вы содержимое одной переменной можете засунуть в содержимое другой. Не просто скопировать значение, а именно добавить как ветвь. Основа работы это ориентация на работу с ветвями деревьев. То есть зачем Вам вообще ссылки? Вот допустим Вы делаете структуру - список контактов. Тогда сама переменная будет являться списком, а ее ветви это контакты. Не ссылки, а сами контакты. Контакты тоже имеют ветви - ФИО там, телефоны, адреса. Вам нужно - Вы просто берете контакт и работаете с ним.
Деревья по умолчанию будут иметь ряд необходимых операций. Например, удаление ветви. Тогда в нашей модели эта операция автоматически дает нам возможность удалять контакт с минимальными усилиями со стороны программиста. В сложных моделях система может хранить смешанные данные - контакты физлица, контакты юрлица и т.д. Удаление будет однотипным, несмотря на то, что данные будут иметь разную природу (для программиста разумеется). Построение на деревьях кортежей (коллекций, контейнеров и как их там еще называют) сразу дает возможность хранения разных типов данных (для программиста, с точки зрения интерпретатора это все равно ветви дерева, а значит подход к ним одинаковый). Шаблоны, дженерики просто не нужны. При этом сразу возможно быстрое построение всех основных функций, таких как вставка, удаление, поиск, фильтрация (например, получить контакты только юр. лиц), так как это будут встроенные функции по работе с ветвями дерева.

13

utkin написал(а):

Если это важный вопрос, значит его нужно рассматривать.

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

А если основной вариант будет русским - то это будет удобно в первую очередь нам.

14

utkin написал(а):

То есть зачем Вам вообще ссылки?

Очевидно затем, что нужно знать из двух мест об одном общем третьем со всеми его изменениями.
Ну то есть реализация такой логической структуры. Будут ли это индексы или пути к ветви дерева как значения, но не две разные копии?

15

Очевидно затем, что нужно знать из двух мест об одном общем третьем со всеми его изменениями.
Ну то есть реализация такой логической структуры. Будут ли это индексы или пути к ветви дерева как значения, но не две разные копии?

Да обращение к ветвям дерева возможно указанием сцепленного ключа (он будет задаваться прямо в тексте программы как например обращение к полям класса и возможно использовать обычные текстовые строки). Типа "Контакты.Уткин". Я писал о недоступности ссылок, хранящих конкретный адрес ячейки памяти.
Поверх уже можно накатывать более сложные структуры, например АТД - список. Навскидку - поименовать ветви дерева числами нужного интервала. Можно еще более высокоуровневый список - поименовать ветви дерева определенным словарем (главное чтобы соблюдалось отношение порядка между индексами (типа возможность упорядочить по алфавиту или иным способом).

16

utkin
Думаю мысли по терминологии  можно взять из книге:
(Классика computer science) Андерс Хейлсберг, М. Торгерсен, С. Вилтамут, П. Голд-Язык программирования C реш.-Питер (2011)

17

Если вам так важна ваша англиская локализация - просто сделаете её как локальную версию потом.

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

18

utkin написал(а):

Фишка в том, что вообще синтаксис языка есть локальная версия!

Да я понял, понял, не настолько тупой. Сделайте внутреннее представление русским, потом локализуете его на русский и на английский. Китайцы с английской локализации поймут, что означают внутренние русские термины и сделают себе китайскую локализацию.

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

Снаружи наш диалог выглядит так:
У: я хочу написать на английском!
Л: лучше на русском!
У: я так не думаю!
Л: все вы, глобалисты-рептилоиды, такие.
У: ну может ты и прав
через день.
У: Лис, и всё-таки я возражаю против твоей идеи, у меня есть ещё такая идея.
Л: #$%(*%
...

Отредактировано ВежливыйЛис (2017-07-16 18:31:20)

19

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

20

utkin
Я с Лисом согласен.  Во-общем надо 2 версии русская и английская.  Вот только пока что я не вижу ноухау, многое у вас с Питона слизано. Следовательно в англоязычной среде  у вас уже есть конкурент.  Так что на английскую можно и забить пока что-то выдающиеся не появится.

21

Вот только пока что я не вижу ноухау, многое у вас с Питона слизано.

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

22

utkin
Например вот это один в один:

6. Основные управляющие структуры
Основные управляющие структуры языка:
1. Циклы:
а) Цикл-счетчик
б) Цикл с предусловием
в) Цикл перебора подсистем
2. Блок обработки исключений
3. Условный оператор
а) Простое условие с одной ветвью
б) Условие с истинной и ложной ветвями

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

К примеру в питоне всё является объектом, даже функции источник http://ru.diveintopython.net/odbchelper_objects.html
На самом деле эта ещё идея взята из Smalltalk.
У вас это названо не объектом а системой. Вот то что у вас базовый тип строковой вас отличает от этих двух языков. У них базовый тип числовой.

23

К примеру в питоне всё является объектом, даже функции источник http://ru.diveintopython.net/odbchelper_objects.html

Так и в Руби все является объектом (включая числа). Так что Питон не прослеживается :). Это более общая закономерность. Называется глубина ООП.

У вас это названо не объектом а системой.

Есть незначительное отличие, направленное на свободное манипулирование подсистемами.

24

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

Не будет ли это приводить к накоплению мусора?

25

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

Бинго!
К самой Вселенной обратиться будет нельзя. А вот по цепочке пройти вниз до объекта можно. В скандинавской мифологии это называется Иггдрасиль - такое вот дерево на котором живут все-все-все (боги, люди, демоны и т.д.). Если хочется курить без травы - https://ru.wikipedia.org/wiki/Мировое_древо
Для казахов есть Байтерек  :crazyfun:
Возвращаясь к ЯП: TObject в паскаль тоже самое по сути. Когда там пишут х=class подразумевается x=class(TObject).

Не будет ли это приводить к накоплению мусора?

Смотрите. Любая вновь созданная подсистема живет только в рамках программного блока. Допустим есть какая-нибудь функция:
функция f(x)
   
     новая подсистема Y
конец функции

Все после выхода из f(x) Y и все ее подсистемы будут автоматически собраны и удалены. Тоже самое для подсистем внутри условий, циклов и т.д. То есть деструктор не нужен, информации вполне достаточно, чтобы рекурсивно удалить все подсистемы, начиная с листьев.

26

Павиа написал(а):

1. Циклы:
а) Цикл-счетчик
б) Цикл с предусловием
в) Цикл перебора подсистем
2. Блок обработки исключений
3. Условный оператор
а) Простое условие с одной ветвью
б) Условие с истинной и ложной ветвями

Из этого 1 и 3 явно удалить не возможно, а неявное исполнение только всё усложнит.
Оно же есть в 100500 языках и там различия в мелких подробностях вроде не/нужности then в условном операторе,
поэтому нельзя сказать насколько будет оно как в Python или нет. Зависит от подробностей исполнения.
А если русский язык, то даже значительнее от подбора слов.

27

Зависит от подробностей исполнения.

Там классика, я счас дописываю определения. Пару дней и выложу новый вариант.

28

utkin написал(а):

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

У вас есть операция "поменять уже существующую систему, добавив в неё подсистему".

Тут одно из двух - либо подсистема принудительно извлекается при удалении,
либо сохраняется и не удаляется.

Если первое - будет неудобно.
Если второе - это будет ручное управление кучей (то есть "вселенной").

Отредактировано ВежливыйЛис (2017-07-17 14:59:36)

29

Тут одно из двух - либо подсистема принудительно извлекается при удалении,
либо сохраняется и не удаляется.

Я не понял Вашу мысль. Расшифруйте. Кого куда надо извлекать? Она удаляется и усе. Вы передаете параметры в функцию и получаете результат из функции и все на этом. Не пойму я чего, Вы хотели сказать там.

Если второе - это будет ручное управление кучей (то есть "вселенной").

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

30

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


Вы здесь » Ремесло программиста » Валентина » Описание языка