Русские вычислители

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

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

Вы здесь » Русские вычислители » Русский язык программирования: от слов к делу » Русский язык программирования - с чего начать?

Русский язык программирования - с чего начать?

Страница:   1 2
Ответить

Сообщений 101 страница 153 из 153

101

Юрий написал(а):

Двумя руками «за»! Дело – оно всегда лучше разговоров.

Один не справлюсь. Пока не нашёл единомышленников. Не знаю, где их искать. Иногда думаю, что нашёл, и меня они на самом деле поддерживают, но часто оказывается, что им важнее зарабатывать деньги, и поэтому либо по иной причине у них просто нет времени на такую работу.

Юрий написал(а):

Везде платят по конечному результату. Работает/не работает, сделано/не сделано. Одно время «апплет» с чьей-то лёгкой руки называли «приложеньицем». Но ведь работали «приложеньица», своё дело делали.

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

Юрий написал(а):

«Подготовка» - не одно и то же с «инициализацией».

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

Юрий написал(а):

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

Например, методы подготовки к работе созданных объектов.

Юрий написал(а):

«Слог» и «куча», как замена «байту» и «массиву», - я их взял из того самого словаря.

Я просто забыл вписать туда "ряд".

Юрий написал(а):

А «слово» используется в другом смысле: как несколько байтов, соответствующих разрядности машины.

Это сейчас "слово" используется в таком значении. Я же сказал про советское время, и именно про Ершова. Вот отрывок из его книги "Введение в теоретическое программирование" (1977 г.):

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

Юрий написал(а):

«Функция» - это более узкое определение, чем «подпрограмма». Потому что «процедура» - это тоже подпрограмма. Но процедура, в отличие от функции, не возвращает значение. В математике – своё определение функции, в программировании – своё. Или взять понятие «чистая функция», которая как раз таки близко по сути к математическому смыслу. Не всё так просто.

Это справедливо только для виртовских языков. В том же Си безответная функция называется функцией. Так что по сути в Си и подобных языках функция = подпрограмма.

Думаю, что в Глаголе самое удачное обозначение: задача. Просто есть задачи, возвращающие ответ, а есть, как я их называю, безответные задачи.

0

102

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

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

Это не оправдание. Есть книги, пусть по ним изучают настоящий русский язык.

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

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

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

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

Ну вот Вы здесь уже искажаете смысл.

Нет, не искажаю. Просто использую более подходящие и, главное, русские обозначения.

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

Библиотека представляется как хранилище (информации, а, пардон, данных).

Библиотека представляется как хранилище книг.

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

Что такое задачница?

Сборник самых необходимых задач, который поставляется вместе с языком программирования.

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

О, опять искажение. Задача более емкое определение - это процесс, иногда даже приложение в целом. Вместо функции часто используется слово метод, но он подходит только для императивного описания алгоритмов.

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

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

Класс однозначно лучше, потому что на образы уже итак навешано много смыслов. и в ИТ тоже.

Лучше образ. Класс — это ближе к обществу, к образованию. А вот слово "образ" точнее отражает смысл этой сущности, так как предметы (объекты) создаются по их, как говорится, образу и подобию. "Предмет создаётся по своему образу" — наиболее точно отражает нужный нам смысл, намного лучше, чем то же "объект создаётся по своему классу".

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

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

Это если исходить из того, что английские слова имеют преимущество и что мы должны приспосабливать русский язык в этой области под английский. Это у них heap, а у нас это может называться как-нибудь иначе. Легко, нужно только научиться мыслить русскими словами, и тогда многие названия понятий становятся очевидными.

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

А функция должна передавать результат (и при чем только один). В стремлении найти истину не наломайте больше дров.

Скажите это создателям Си и Си-подобных языков, где функция может ничего и не возвращать. То есть им отступать от истинных значений слов можно, а нам употребить иное, но очень близкое, — нельзя? Двойные стандарты.

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

Не могу представить n-мерный ряд. N-мерный массив запросто. Также не могу представить разреженный ряд. Ряд это заменитель вектора - есть такая структура данных во многом схожа с одномерным массивом.

А я не могу себе представить одномерного массива, русский язык не позволяет (ну, не может быть большое скопление вещества быть необъёмным, и даже неплоским, потому что в таком случае это уже на массив, а жила, нить, волокно, волос, черта, линия, опять же ряд). А вот представить ряд рядов — легко.

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

Плохо, в старой литературе оно сопряжением и было (в радиоэлектронике). Это  новомодное слово.

На самом деле хорошо. Намного лучше, удобнее и, главное, понятнее, чем "интерфейс" (межрожие). В том то и дело, что раньше были именно сопряжения — очень удачное обозначение. Плохо — только если вы англофил.

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

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

Это называется сброс. Вы просто сбрасываете состояние какой-то части вашей программы. А инициализация не может быть выполнена уже после начала работы части программы или устройства, только при перезапуске, так как она может быть только начальной, потому что само слово это означает начальные действия. И вот именно начальная установка значений — это как раз подготовка, просто самая простая. Так что здесь и во многих других вопросах именно вы стараетесь исказить смысл слов, чтобы оправдать их употребление. Недостойный приём.

0

103

  • Автор: Юрий
  • Управляющий
  • Юрий

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

0

104

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

Но как найти, что учить нужно, а что ересь и подлежит сожжению?

Русское слово имеет русский корень. Есть этимологические словари для трудных слов.

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

(ну, допустим продуктового отдела, для полноты картины  )

Любой отдел является продуктовым по определению. Вы имеете ввиду продовольственный отдел?

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

Куда он должен направить свое чадо на обучение, дабы восстановить справедливость? И как он вообще должен узнать о том, что справедливость не восстановлена?

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

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

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

Русский язык правильный. По-хорошему, тот, который был до обрезания. Но такой переход сейчас тем более не представляется возможным. Это даже сложнее, чем внедрить русские слова вместо иностранных. И не правильное отбирают от плевел, а зёрна от них отделяют.

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

В ИТ библиотека давно представляется как хранилище информации. Книги всего лишь носители, материальное воплощение.

В ИТ много дол%#е#изма можно найти. И что теперь? Пусть будет? Например, то, что русский язык в программировании у 99% вызывает лишь смех либо улыбку. Правильно это? Ничего менять не нужно здесь? Не нужно разве бороться за освобождение умов от таких рабских подзападнических, подпиндоснических убеждений?

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

То есть то, что нужно решить, выполнить? Но в библиотеке находятся фрагменты кода и данных, которые уже решены. Как раз для того, чтобы данные вопросы не решать снова и снова.

Нет, там находятся задачи — части программ, которые выполняют какие-то действия.

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

Смысл переучиваться?

Чтобы начать мыслить по-русски. Чтобы было понятно русскому человеку. Чтобы порог вхождения для новичков был как можно ниже. Чтобы обучить детей было легко. Чтобы восстановить русскость. Чтобы в итоге увеличить производительность труда наших программистов. Чтобы восстановить справедливость по отношению к русскому языку.
Переучиться не сложно. Тем более с иностранных слов на русские переучиваться легко. По себе знаю. Главное — не быть англофилом и русофобом и поставить перед собой цель.

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

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

Образ предмета — это не сам предмет, это лишь его образ, который создаёт программист, чтобы впоследствии в ходе работы программы именно по образу и был создан предмет. Так понятнее? А когда речь идёт о предметах программы, которые представляют в ней предметы из яви, то тем более это должно называться образом: это образ настоящего предмета внутри программы.

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

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

А на самом деле это не более, чем передранная с английской словесность. Сущность исходника программы, которая описывает предмет, который должен быть создан по этой сущности, должен называться образом, образцом, образчиком, ещё как-нибудь. Не нужно зацикливаться на этих американизмах: когда их передирали, совсем не задумывались о смыслах. Да и мало ли что там американцы понапридумывали в своём языке: у них там своя семантика, и то, что хорошо подходит для английского языка, совсем не обязательно хорошо подходит для русского.

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

У нас это называется именно как куча. То есть слово куча уже занято и ее нельзя использовать под массив - области использования смежны, возможна путаница.

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

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

Вы не правы. Функция возвращает значение void. Об этом написано в учебниках. Таким образом, в Си-подобных языках только функции (причем "правильные"), в паскалеподобных языках ярко выраженное разделение на функции (с результатом) и процедуры (с побочными эффектами).

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

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

Таким образом, в Си-подобных языках только функции (причем "правильные")

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

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

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

Я здесь написал о своём понимании массива в таком же ключе, в каком и вы описывали ваше понимание ряда.
Снова искажение смысла! Вектор имеет направление, а его начало соотносится с какой-то точкой в пространстве. Короче, понятие вектора здесь вообще не подходит. Только если называть векторами ряды, которые эти самые вектора представляют в программе для расчётов с этими самыми векторами, но это не то же самое, что называть ряды векторами в языке программирования. Это было бы неправильно.

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

Нет, вы меня не поняли, я здесь как раз за сопряжение, а не за интерфейс. Я писал что в статьях до середины 90-х чаще использовалось слово сопряжение и это хорошо. А плохо, что стало интерфейс.

Это хорошо. Хотя бы здесь вы с нами. Жаль, что только здесь. А написали вы так, как будто "плохо" — это сопряжения.

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

Логически это организовано одним фрагментом кода и сброс и подготовка. Так в чем разница? Зачем создавать новые ни к чему не обязывающие сущности, если с их ролью отлично справляются старые?

Дело в том, что сброс нельзя называть инициализацией, потому что это как если бы мы называли стол деревом. Сброс — это сброс. А инициализация — это начальная выставка значений. Так что её вполне можно назвать подготовкой.

0

105

  • Автор: Юрий
  • Управляющий
  • Юрий

http://www.greenmama.ua/forum_img/00/31/36/39.0.leopol0d.jpg

0

106

Создатель написал(а):

Е.В.Геній, а что толку от исходников Глагола? Вот зачем они вам нужны? Менять что-то в Глаголе нет никакого смысла (за исключением добавления некоторых вещей, которые есть в Обероне-2, но которых нет в Глаголе), потому что Глагол — это, по сути, переведённый Оберон. Он полностью повторяет его устройство и преследует единственную цель: быть предельно простым, а значит и предельно надёжным, русским языком программирования. Поэтому он и повторяет Оберон: потому что именно Никлаус Вирт первым создал такой язык. Единственное развитие Глагола может заключаться лишь в написании новых отделов да усовершенствовании преобразователя, в том числе до возможности построения приложений под иные ОС, что позволит перенести на них и сам преобразователь. Никаких крупных изменений в сам язык вносить не нужно, потому что в нём, как и в его прообразе — Обероне, настолько все продумано и вылизано, настолько все части соответствуют друг другу, настолько всё уравновешено, что такие изменения поломают весь язык. Я бы сказал, что Глагол и Оберон — это языки с неизбыточной достаточностью.
Так что, если вам нужны какие-то особые возможности, то лучше делать новый язык.
И кто сказал, что РЯП должен быть один? Кесарю кесарево, как известно. Каждому языку — своё предназначение, свою нишу (свои ниши). Нужны и такие высоконадёжные языки, как Глагол (Оберон), — для разработки высоконадёжных приложений и ОС, и такие, как Си++ или Питон, —для удобной разработки приложений без особо высоких требований к их надёжности. И преобразуемые (компилируемые) языки — для наивысшей производительности, и исполнительные (интерпретируемые) языки — для наивысшей скорости разработки, удобства опять же, и исполнительно-преобразуемые (ИП-языки: с преобразованием исходника в промежкод (байткод) с последующим его исполнением) — для переносимости, многосредности (мультиплатформенности) приложений. И т.д. Всё нужно.
С чего начать? Известно, с чего! С языка общего назначения (ЯОН), то есть с преобразуемого языка. Никуда мы не уедем без оного, потому что именно он станет отправной точной, основой развития русских вычислителей (в широком смысле). И такой язык есть — Глагол. Не нравится? Тогда, как я уже выше сказал, создавайте новый. Глагол — это обероноподобный язык, это переведённый Оберон. Это — данность, явь. В нём всё, включая потроха, заточено под обероноподобность. И пытаться сделать из него Си-подобный или какой-то другой язык... Это как если сидеть и вносить в "язык" ассемблера изменения, пытаясь превратить его в JavaScript. Думаю, вы все хорошо понимаете, что это бессмысленно. А если по-хорошему, то прав Русский: начинать нужно со своего низкояза (ассемблера). Хотя это и не обязательно, но возможность использовать его вместе с ЯОН для увеличения скорости приложений в их узких местах была бы не лишней.

Да я и не устану повторятся - мѣнять я тамъ особо ничего и не собирался, - такъ лишь изучить какъ что устроенно и главное выяснить - нѣтъ ли скрытыхъ минъ либо ловушекъ... Короче я своё слово сказалъ - нѣтъ изходниковъ, либо мнѣнія независимаго авторитетнаго человѣка о подводныхъ булыжникахъ - будемъ считать что ГЛАГОЛЪ какъ языкъ мертвъ! И пользоваться имъ для компиляціи своихъ проектовъ опасно.

И еще совершенству предѣла ни когда нѣтъ - любая программа можетъ быть усовершенствована.

Про вылизанный синтаксисъ - я бы такъ не сказалъ - не соглашусь... многіе понятія выбраны не интуитивно понятными словами, а притянутыми за уши по непонятно какимъ понятіямъ...

Создатель написал(а):
utkin295 написал(а):

Есть устоявшиеся правила и традиции.

Вот скажите мне, какой смысл в том, что за последние два года слова "содержимое" и "содержание" почти везде заменяют на слово "контент"? Сегодня вот увидел на Ютубе: "...контент с участием несовершеннолетних..." По всей видимости, за последние несколько месяцев переделали, потому что раньше там слово "содержание" было. Это ж лютый пи%?ец! Вот что их заставляет так поганить русский язык? Примерно с год назад я случайно заметил, что вместе с очередным обновлением в моей Windows 7 произошла такая замена по всей системе. Смысл? И почему за меня решили, какие мне слова нужны? Это называется навязыванием. Или ещё пример: слово "служба" за последние несколько лет почти везде заменили на слово "сервис": там где раньше была "служба того-то", теперь стал "сервис того-то". В приложении для usb-модема МТС вместо русского слова "соединение" написано "коннект". Примеров много можно найти. И ведь эти поганые англофилы таким образом всем русским людям навязывают эти слова, как бы приучают нас к ним. И это уже очень надоело.

Предлагаю вездѣ переименовать на универсальное слово "пи%?ец" будетъ гораздо понятней...

Ребятъ съ "вынь семь" пора завязывать - послѣдняя "русская" акошка - это "вынь хрюша" и то правильно обновленная!!! Въ семеркѣ, а тѣмъ болѣе въ восьмёркѣ, ядро могутъ въ любой моментъ помѣнять обновленіемъ на мертвое - а что вы хотѣли ихъ среда = ихъ правила!!! А потому Вы все тутъ собравшіеся и это чуящіе, сраться между собой ну ни какъ не должны!!!

Создатель написал(а):
Юрий написал(а):

Но если он не развит как инструмент (как тот же Глагол), то мне нет смысла им пользоваться - руки связаны.

Так его нужно развивать. Про развитие Глагола я уже говорил: сам язык развит почти окончательно, за исключением некоторых вещей. Это как с Обероном, его английским исходником: Никлаус Вирт сделал совершенный с его точки зрения язык и никогда его больше не меняет, только ошибки исправляют. А вот преобразователь и задачницу можно и нужно развивать. Взяли бы да написали оконный отдел, который позволит отвлечься от прямых системных вызовов (WinAPI) или отдел для работы с сетью.

Я начиналъ писать оконный раздѣлъ, а потомъ забросилъ - писать для черной коробки въ которой не вѣсть что, энтузіазмомъ не горю...

Юрий написал(а):

А что хорошего у слов и словосочетаний «дееход», «словесный разбиратель», «постройный разбиратель», «куча» (это из известного вам словаря) по сравнению со словами «алгоритм», «лексический анализ», «синтаксический анализ», «массив»? Вторые приходится использовать как точно соответствующие моим мыслям. Первые же я не могу сказать, потому что они не выражают мыслей. «Массив» - это вполне упорядоченная структура данных, а вовсе не куча. Не тот смысл. Можно заменить «анализ» «разбором», но чем заменить «функцию»? В том словаре так и нет равнозначной замены. А ведь «функцию» приходится использовать на каждом шагу.

Алъ-Го-Ритмъ - чисто русское основанное на русскомъ корнесловѣ, а вотъ дееход = новоделъ и хоть чего-то тамъ и понятно, но мозгъ реагируетъ на первое гораздо лучше не потому что общепринято, а потому что резонируетъ напрямую, безъ посредниковъ - къ стати "дее" обрѣзокъ отъ "идее" - которое обрѣзокъ отъ "видее" и того - какое изъ двухъ словъ Алъ - высшій, Го - путь, Ритмъ - повтореніе или "вижу ходъ" болѣе правильное не понятно... Словесный разбиратель и лексическій анализъ или постройный разбиратель и синтаксическій анализъ первое понятнѣе второе привычнѣе, а дѣтямъ первое  въ мозгъ ляжетъ лучше... Куча и Массивъ - слово масса технически устоявшееся и ещё не извѣстно его произхожденіе, возможно чисто русское какъ слово "космосъ" къ примѣру...

Юрий написал(а):

«Подготовка» - не одно и то же с «инициализацией». Первое – слишком широкое понятие, второе – узко заточенное. Правильнее было бы назвать «установка начальных значений», но это длинновато. Долго вспоминал, но так и не вспомнил, где бы я использовал «инициализацию» в качестве имени в какой-нибудь программе. Ну разве что где-то в комментариях. Не самое насущное понятие.

Самое интересное есть въ древнерусскомъ такое слово-понятіе Їнить!!! Юрій помнишь Инъ Янъ  :glasses: Їнъ Ѧнъ ?

Отредактировано Е.В.Геній (30.09.2013 12:03:04)

0

107

  • Автор: Юрий
  • Управляющий
  • Юрий

такъ лишь изучить какъ что устроенно

Мне нравится вот этот компилятор: TinyCC: он сам маленький, производит маленький код и быстрее GCC в 9 раз. Открытые исходники, так что при желании можно изучить :)

Алъ-Го-Ритмъ - чисто русское основанное на русскомъ корнесловѣ

Гм... Вы уверены? А как же вот это (из Википедии):

Само слово «алгоритм» происходит от имени хорезмского учёного Абу Абдуллах Мухаммеда ибн Муса аль-Хорезми (алгоритм — аль-Хорезми).

0

108

  • Автор: Юрий
  • Управляющий
  • Юрий

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

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

Мне, чтобы свободно рассуждать о словесности, не хватает образования в этом, поэтому я за это не берусь. Но по компьютерным наукам есть высшее образование; готов с Вами участвовать в обсуждениях - надеюсь, что это принесёт какие-то плоды.

0

109

Въ чёмъ можно превосходить нынѣ? Собственно на этой вѣткѣ многіе перлы уже изложены, мультіязычность была бы къ стати, только потому что угодила бы многимъ, потому кодовая страница понятно что 16 битъ юникодъ, по поводу компилируемость либо переводъ на байткодъ - и то и то, часто требуется кодъ открытый быстромодифицируемый, написалъ - обработалъ текстъ къ примѣру - всё, зачѣмъ компилировать? Троичная логика это особенность которой ни гдѣ точно нѣтъ, хотя уже во многія языки введены разные костыли но полноцѣннаго ни гдѣ нѣтъ - а потребность иногда ощущается.

А вотъ редакторъ IDE такъ называемый надо поднимать не хилый - желательно слить въ одно минимализмъ и максимумъ удобства, мощная справка, легкіе переходы къ опредѣленію процедуръ, функцій или задачъ - собственно не важно какъ назовемъ... Редакторъ формъ и рессурсовъ не знаю гдѣ какъ грамотнѣй чѣмъ въ 1С8 пока ни гдѣ не видѣлъ... Главное единымъ мозговымъ штурмомъ можно къ чему-то прійти...

Къ стати нынѣ всѣ на web технологіи насидаютъ - связь это круто но централизація... Съ ней нужно бороться сами понимаете, что при накрываніи сервера кліенты ложатся автоматомъ - очень удобно къ стати всякимъ паразитамъ - неугоденъ рессурсъ или не прогнулся подъ прослушку - кислородъ перекрыли... Скайпъ былъ когдато спецслужбамъ костью въ горлѣ нынѣ это дырка для слѣжки за юзверями - вродѣ какъ правильному человѣку и скрывать то нечего но осадочекъ остаётся - мало ли президента презикомъ назовешь съ гореча, а завтра тебѣ въ печень будутъ особо рьяные псы режима стучаться, какъ говорится отъ тюрьмы и отъ сумы...

0

110

Почистил ветку. В своей работе предлагаю исходить из общепринятых научных представлений о происхождении слов. Опираться на сектантские источники нет никакого смысла, потому что у них нет ни одного первоисточника. Все обсуждения по русскому языку и словам в нём — в разделе о русском языке. Здесь допускается обсуждать только обозначения понятий, названия технологий, ключевые (служебные) слова, сокращения, и т.д., то есть только то, что прямо связано с языками программирования.

0

111

  • Автор: Infum
  • Участник
  • Infum
Юрий написал(а):

Хотел бы перевести русло наших разговоров от слов к делу. От выпускания пара в свисток к тому, что беспокоит наши умы. А именно к русскому языку программирования. Его нужно создавать. С чего начать?

Путь 1. Взять за основу что-то имеющееся, а потом его развивать. «Взять» 1С нам никто не позволит, исходных кодов нет. «Афина»? Так же, как и 1С, она заточена под определённые задачи; если мы хотим уготовить своему языку узкую нишу, то это не есть хорошо. Глагол, самый продвинутый из пока существующих? Но он основан на идеях 30-летней давности. Ещё многим не понравится его "обероноподобность".

Путь 2. Разрабатываем язык с нуля. Определяемся с парадигмой, синтаксисом, семантикой, способами воплощения, языком, на котором будем писать. Пишем формальное определение языка, пишем документацию (допустим, на wiki). Вероятно, многие тут уже знают, что я подобным начал заниматься на compiler.su . Не навязываю своего видения, своей площадки для обсуждения – предлагайте своё.

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

И второй вопрос: кто готов этим заниматься? Готов ли кто-то поступаться в чём-то своими принципами типа: "если не паскалеподобный синтаксис, то обходитесь без меня; если в языке будут термины иностранного происхождения, то я этим заниматься не буду".

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

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

Любая сложная задача решается поэтапно. С/С++ тоже были созданы не сразу и не с пустого места. Точно так же как и ядро Линукса. Насчёт Линукса, у Торвальдса не было цели создать ОС мирового масштаба, чтобы ей все пользовались. Ему была неудобна ОС, которой он пользовался, он видел как ее можно усовершенствовать, чтобы было удобно использовать для решения Определённого круга задач. Он пользовался платной и закрытой ОС, что ему жутко не нравилось. И волшебным ключиком стало то, что он решил сделать открытую ОС.

По существу. Я готов заниматься, помогать чем смогу. У меня лет 5 назад был опыт написания интерпретатора для своего РЯП. Была консольная оболочка и десяток русских функций, для выполнения рутинных задач. Что-то вроде bash.

Я работаю под Linux. Могу:
1. Конструктивно пинать всех, чтобы процесс двигался. :)
2. Быть сторонником. Все выбрали одно, а я против. Чтобы не делать глупых ошибок и конструктивно разбирать плюсы и минусы.
3. Написать редактор для кода, чтобы подсвечивался синтаксис. Под Линукс или веб. Возможно GTK+ для портирования под Окна.
4. Поступиться не вопрос, если за решением будет сплошные плюсы и минимум минусов.
5. Мне нравятся языки С/С++ и Python (Пайтон).
6. С чего начать? Я в своей теме описал подробно с чего начать. За сохранение культурных ценностей.
Кратко. Нужно заниматься самим языком, чтобы было легко выражать мысли на нём и приятный был синтаксис. Когда будет достигнут баланс, что все устраивает в коде, уже заниматься созданием компилятора/интерпретатора. До этого момента можно смело забить про все, что связано с реализацией компилятора.

0

112

  • Автор: Infum
  • Участник
  • Infum
utkin написал(а):

Кстати, некоторые его версии поддерживают alias - переприсвоение имени команды. Вы могли бы составить словарик русских команд для линукса.

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

Возможно имеет смысл разработать свой командный процессор на Си с русским синтаксисом.

Отредактировано Infum (11.07.2014 12:01:02)

0

113

  • Автор: Infum
  • Участник
  • Infum

Ознакомился с вопросом про аналоги Bash по-русски. Ранее уже были попытки перевода команд, о проектах почти ничего не слышно. Мертвяки.

Встретил интересную тему на одном форуме, где студент просит помощи в создании русского командного процессора с русскими командами.
Факт интересен тем, что данную задачу ему поставил преподаватель. То есть есть преподаватели, которые подводят молодые, светлые головы, чтобы те делали попытки создания РЯП и оболочек. :)

0

114

  • Автор: Infum
  • Участник
  • Infum

utkin, по поводу перевода. Перевести и сделать можно всё, если сильно захотеть. Но зачем и для чего? Какой смысл от очередного перевода очередного языка?

0

115

  • Автор: Юрий
  • Управляющий
  • Юрий

Факт интересен тем, что данную задачу ему поставил преподаватель. То есть есть преподаватели, которые подводят молодые, светлые головы, чтобы те делали попытки создания РЯП и оболочек.

Увы, но тех преподавателей, кто задаёт вопросы по поводу русификации "А на хрена это надо", больше. Знаю, потому что сталкивался.

0

116

Юрий, как у вас дела с русским ассемблером продвигаются?

0

117

  • Автор: Юрий
  • Управляющий
  • Юрий

Я вам тут ответил.

0

118

  • Автор: Юрий
  • Управляющий
  • Юрий

Написал об идеях по более активному использованию памяти в стеке, не прибегая к динамическому распределению памяти в «куче». Желаете познакомиться – милости прошу. Если есть возражения, пожелания, свои собственные идеи, просто замечания (в том числе ошибки, описки и прочие очепятки). Разбил на несколько статей:

Почему динамическое распределение памяти – это плохо
Как обеспечить возврат функциями объектов переменной длины?
Типы переменного размера (dynamically sized types, DST) в языке Rust
Размещение объектов в стеке, традиционный подход
Размещение объектов переменной длины с использованием множества стеков
Размещение объектов переменной длины с использованием двух стеков
Реализация двухстековой модели размещения данных
Размещение объектов переменной длины с использованием одного стека
Можно ли забыть о «куче», если объекты переменной длины хранить в стеке
Безопасность и размещение объектов переменной длины в стеке
Массивы, структуры, типы, классы переменной длины
О хранении данных в стеке – вместо заключения

0

119

  • Автор: Юрий
  • Управляющий
  • Юрий

Теперь работает.

0

120

  • Автор: Infum
  • Участник
  • Infum

Листал противную ленту Фейсбука. Остановился на посте одного уважаемого преподавателя по "железу". Не хотел читать текст, так как там было про C#. Но что-то заставило. :)

Цитирую.

C# неисчерпаем. Встретил в нём забавные типы данных, которые называются
Nullable types.

Что особенно понравилось -- имена переменных можно писать кириллицей.

К сожалению с именами методов и классов это не проходит. Что до русских имён переменных, то программа становится гораздо более самодокументированной. Длина слов на английском в среднем всего на два символа короче. Так что не вопрос. У меня был опыт разработки приложений на Турбо-Прологе и там это замечательно работало.

Второй собеседник.

пожалуй главное ну или минимально-достаточное требование для программной системы - это чтобы ее можно было развивать. Код, комментарии и документация на национальных языках это в с учетом данного требования и реалий современной индустрии разработки ПО скорее анти-паттерн. Есть некоторая культура разработки хороших продуктов, она предполагает, что вы код и апи комментарии пишете на английском как фолбек локали (многие в т.ч. включающие национальные символы кодировки устроенны так что латиница всегда прочитается даже на самом странном устройстве и в необычных обстоятельствах), а все национально-специфичное держите в т.н. ресурсах, в .net/с# кстати приличная инфраструктура для локализации;)

Отредактировано Infum (05.08.2014 23:13:53)

0

121

  • Автор: Infum
  • Участник
  • Infum

Убийственное затишье. Кто-нибудь что-нибудь делает? =)

Отредактировано Infum (21.08.2014 11:39:50)

0

122

  • Автор: Юрий
  • Управляющий
  • Юрий

У меня как раз-то всё наоборот: чем больше я тут пишу, тем меньше делаю. А чем больше делаю, тем меньше пишу :) Вы сами-то намерены что-то делать? Хотите, я Вам предложу фронт работ? У меня нашлось бы для Вас предложение :)

0

123

  • Автор: Infum
  • Участник
  • Infum

Юрий, с удовольствием. Готов попробовать свои силы. С моей стороны затишье, так как я готовлюсь к учебному сезону.
1. Пишу новую программу для кружка робототехники.
2. Буду учителем информатики на полной ставке с этого года.
3. Пишу материалы и уроки по основам электроники, программирования.
4. Планирую запустить онлайн курс по основам электроники.

Буду выкладывать на своем сайте: http://informatikum.ru

Скайп: informatikumru
Почта: инфо @ informatikum.ru

Делал набросок структуры РЯП для программирования роботов. С коллегой хотим сделать набор для создания робо платформы и чтобы ее можно было на РЯП программировать.

0

124

  • Автор: Infum
  • Участник
  • Infum

Сейчас очень хочу решить задачу, чтобы простую программу на РЯП, можно было скомпилировать и зашить в микроконтроллер. Например, помигать светодиодом. Вы могли бы помочь, направить, показать что нужно поэтапно делать и изучить. Если вы в Москве живете, можно было бы встречу организовать. Или по скайпу.

0

125

  • Автор: Yaisis
  • Участник
Юрий написал(а):

Путь 1. Взять за основу что-то имеющееся, а потом его развивать. «Взять» 1С нам никто не позволит, исходных кодов нет. «Афина»? Так же, как и 1С, она заточена под определённые задачи; если мы хотим уготовить своему языку узкую нишу, то это не есть хорошо. Глагол, самый продвинутый из пока существующих? Но он основан на идеях 30-летней давности. Ещё многим не понравится его "обероноподобность".

Можно взять за основу иностранный язык, предлагаю D, он поддерживает кучу парадигм программирования и он является компилируемым системным языком. Так же предлагаю делать всё на базе LLVM, для данного языка - это компилятор LDC, исходники есть в сети, они написаны на С/С++. Можно найти в коде все ключевые слова и перевести их на русский и уже должен получится русский язык программирования.

Юрий написал(а):

Путь 2. Разрабатываем язык с нуля. Определяемся с парадигмой, синтаксисом, семантикой, способами воплощения, языком, на котором будем писать. Пишем формальное определение языка, пишем документацию (допустим, на wiki). Вероятно, многие тут уже знают, что я подобным начал заниматься на compiler.su . Не навязываю своего видения, своей площадки для обсуждения – предлагайте своё.

Это тоже надо продумывать, если что-то в пункте 1 не устраивает, то можно поменять. Не обязательно делать с нуля, можно взять, что-то за основу, убрать от туда то, что не нравиться и добавить то, что нравится.
Можно и с нуля придумать, но делать лучше на базе LLVM, чтобы не тратить время на разработку оптимизатора и на поддержку разных архитектур.

Юрий написал(а):

И второй вопрос: кто готов этим заниматься? Готов ли кто-то поступаться в чём-то своими принципами типа: "если не паскалеподобный синтаксис, то обходитесь без меня; если в языке будут термины иностранного происхождения, то я этим заниматься не буду".

Тут вы правильно, что создали wiki, не надо ждать, что тот, кому нравится Паскаль будет разрабатывать вместе с вами язык аналогичный С/С++, а надо искать единомышленников, с которыми будут совпадать взгляды, решать вместе с ними проблемы о способах реализации разных пунктов языка и приходить к согласию.

Юрий написал(а):

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

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

Отредактировано Yaisis (07.10.2014 03:39:31)

0

126

  • Автор: Yaisis
  • Участник
Infum написал(а):

Перевести и сделать можно всё, если сильно захотеть. Но зачем и для чего? Какой смысл от очередного перевода очередного языка?

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

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

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

Язык D делал всего один человек, который до этого занимался написанием компиляторов для C/C++, позже к нему присоединились ещё несколько человек, они развивают данный язык абсолютно бесплатно и хотят так развивать его и дальше потому, что они не хотят, чтобы их стимулом стали деньги.
1C-же именно ради денег занимается своей платформой, конечно она могла бы создать системный язык программирования общего назначения, но зачем ей это ? Итак достаточно языков разных и все они бесплатные, на этом особо не заработаешь, а вот сделать удобный конструктор для предприятий и зарабатывать на этом - это выгодно, поэтому она этим и занимается. Поэтому они это не делают не "Потому, что это требует огромного количества ресурсов, включая денежных.", а потому что на этом не заработать.

Поэтому я думаю, что нишу не надо выбирать, русский язык программирования должен быть системным языком программирования общего назначения, чтобы на нём можно было написать абсолютно всё, как на С/С++ и D.
Иначе зачем нужен такой язык, когда полно аналогичных уже насоздавали ?

"Мне нравятся языки С/С++ и Python (Пайтон)."
Уверен, что вам и D понравиться.
Представьте язык программирования по мощности, как С/С++ но по простоте, гибкости и скорости написания кода, как Python. Так вот D похож на данный язык.

Отредактировано Yaisis (07.10.2014 03:40:51)

0

127

  • Автор: Yaisis
  • Участник
Сергей написал(а):

А что, если на вход некоего приложения — назовём его преобразователем — будут подаваться последовательности условных знаков или даже чисел, которые будут описывать логику работы преобразуемой программы, а такой преобразователь будет давать на выходе двоичный код? Также будет приложение, которое будет разбирать исходник и строить такую условную запись программы (рабочее название — промежкод), назовём его разборщиком. Тогда любой мог бы прикрутить к этому преобразователю любой язык, написав свой разборщик. Также к такому разборщику можно было бы прикрутить исполнитель, который этот промежкод исполнял бы напрямую (с сохранением промежуточника (файла с промежкодом) для увеличения скорости работы при последующих запусках или без такового). То есть мы могли бы создать некий набор снастей, сочетая которые можно решить любую задачу, связанную с программированием. Что скажете?

Всё это реализовано в LLVM и нет смысла тратить на разработку этого всего с нуля время, достаточно использовать LLVM.
LLVM состоит из трёх компонентов:
1) Компилятор в байткод, который выполняет простое преобразования кода с понятного языка программирования в промежуточный байткод LLVM - вот эту часть и надо написать для собственного языка.
2) Оптимизатор - выполняет архитектурно-независимую оптимизацию созданого байткода. Оптимизация не привязана ни к языку, ни к архитектурам процессоров. Оптимизация состоит из набора фаз, которыми можно управлять, которые можно включать или нет в процесс оптимизации. любая мельчайшая единица оптимизации вынесена в отдельную фазу. Можно создавать свои фазы оптимизации. Например удаление мёртвого кода - это одна фаза оптимизации; вынес условий за циклы - другая и т.д. Оптимизатор оптимизирует промежуточный байткод и даёт на выходе соптимизированный байткод. Любой байткод LLVM можно преобразовать в ассемблер LLVM и обратно.
3) Генераторы кода - пишутся под разные платформы, описываются в файлах специального формата. Генератор кода преобразует байткод в машинный код архитектуры, под которую написан и выполняет архитектурно-зависимую оптимизацию. Все стадии оптимизации также описываются в отдельных фазах.

В результате, если для языка использовать LLVM, то получаем мощный оптимизатор, как у C/C++, поддержку огромного количества архитектур. Возможность создавать или нативный код, или запускать его в режиме JIT. Возможно компилировать код сразу, а потом распространять его в скомпилированном виде или распространять его в виде байткода, а потом уже на устройстве выполнять или в режиме интерпретатора, или в режиме JIT или компилировать непосредственно под устройсто с использованием полной оптимизации для данного устройства, что делает код более эффективным, чем распространяемый заранее скомпилированный код, который не учитывает всех особенностей устройства, на котором работает. Например, если скомпилировать код под i686, то данный код будет работать на Core i7, но он не будет использовать инструкции AVX в своей работе, т.к. в i686 таких инструкций ещё не было и поэтому компилятор их не использовал.

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

Отредактировано Yaisis (07.10.2014 04:20:02)

0

128

  • Автор: Yaisis
  • Участник
Юрий написал(а):

Давай те посмотрим правде в глаза, 1С занимает такую нишу только по причине «дешёвого решения надуманных государством проблем». В других странах бухучёт намного проще и ведётся чуть не в Экселе (для подачи налоговой отчётности). Нет возможности с русским ЯП занять место 1С.

Не соглашусь. 1С популярен потому, что это конструктор, в котором легко и быстро можно создать то, что на С/С++ создавать долго. Exсel тоже в этом смысле неудобный.
Бухгалтерия и государство тут не причём.
Допустим надо создать учётную систему - на 1С она реализуется очень быстро.
А потом понадобилось создать сложный отчёт с группировками - на 1С это реализуется быстро и просто. Я не знаю, где ещё можно так просто создавать отчёты ?
А таких отчётов может понадобиться создать много и постоянно добавлять всё новые и новые.
Да там в 1С ещё куча всего, что в ней делается быстрее, чем в любом обычном языке программирования.

Юрий написал(а):

...В других странах...

В других странах есть свои системы - например SAP, ABAP и т.д.

0

129

  • Автор: Юрий
  • Управляющий
  • Юрий

Путин однажды спросил одного отечественного предпринимателя, почему он не перевозит свой комбайновый завод из Канады в Россию. Тот ответил ему через статью в Инете. Одной из причин он назвал существование трёх видов учета: бухгалтерского, налогового и управленческого вместо одного за рубежом. Там одного SAP достаточно, чтобы удовлетворять и собственные потребности в учёте, и фискальные потребности государства. У нас же многие зарубежные производители КИС делают экспорт данных в 1С, чтобы соответствовать фискальной политике государства.

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

0

130

  • Автор: Юрий
  • Управляющий
  • Юрий

если для языка использовать LLVM

У меня вопрос: насколько хорошо Вы знаете LLVM? Что-то я не встречал внятной документации на русском. На английском её полно, но читаешь её значительно медленнее. И вообще, разница в объеме документации по ИТ между русскоязычным и англоязычным сегментами Инета так велика, что надо прекращать лениться и работать над беглым чтением английских текстов.

Опять же встаёт вопрос: а есть такая кроссплатформенный GUI, который бы транслировался в байт-код LLVM? Что-то я не нашёл ответов на такой вопрос. А пока (в моём представлении) ситуация такова: есть кросплатформенный ассемблер LLVM, который сам по себе, и есть кроссплатформенные GUI типа Qt, GTK+, VxWidgets, которые тоже сами по себе.

Идея LLVM красива и лично мне нравится. Но Clang пока не работает на самой популярной платформе – Windows.

0

131

  • Автор: Юрий
  • Управляющий
  • Юрий

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

Ну сделал я русификацию C/C++, но я бы не стал назвать это «своим языком».

Поэтому я думаю, что нишу не надо выбирать, русский язык программирования должен быть системным языком программирования общего назначения, чтобы на нём можно было написать абсолютно всё, как на С/С++ и D.


Согласен. Если сделать РЯП низкого уровня (или системного программирования – кому как нравится), то на его базе можно делать другие РЯП, более высокого уровня. Если же делать РЯП высокого уровня, то он будет написать уже на чём-то не нашем.

Уверен, что вам и D понравиться.

А я уверен, что Вам ещё Rust понравится :) Тоже неплохой язык :) Если Вам нравится D, то Rust не может не понравиться. Единственное, что не очень пока понятно – заточенность на параллельные вычисления.

Юрий написал(а):
...если в языке будут термины иностранного происхождения...

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

Понимаете, не иностранные термины, а термины иностранного происхождения. Т.е. речь идёт не о том, чтобы избавиться от «function», «hash table» или «stack», а о том, чтобы избежать употребления «функция», «хэш-таблица» или «стек». Заменив последние «задачей», «решёткой с мешаниной» и «подвалом», т.е. словами с исключительно русскими корнями.

0

132

  • Автор: Yaisis
  • Участник
Юрий написал(а):

У меня вопрос: насколько хорошо Вы знаете LLVM? Что-то я не встречал внятной документации на русском. На английском её полно, но читаешь её значительно медленнее. И вообще, разница в объеме документации по ИТ между русскоязычным и англоязычным сегментами Инета так велика, что надо прекращать лениться и работать над беглым чтением английских текстов.

Опять же встаёт вопрос: а есть такая кроссплатформенный GUI, который бы транслировался в байт-код LLVM? Что-то я не нашёл ответов на такой вопрос. А пока (в моём представлении) ситуация такова: есть кросплатформенный ассемблер LLVM, который сам по себе, и есть кроссплатформенные GUI типа Qt, GTK+, VxWidgets, которые тоже сами по себе.

Идея LLVM красива и лично мне нравится. Но Clang пока не работает на самой популярной платформе – Windows.

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

Про GUI думаю, что надо clang`ом его компилировать в объектные файлы или в библиотеки, которые потом подключать к своему проекту. Если для какой-то известной платформы, то наверно можно и готовые подключить, а если делать кроссплатформенные с распространением в байткоде, то и компилировать надо в байткод - это мои догадки.
В результате при наличие исходников можно скомпилировать любую программу/библиотеку в баткод LLVM. Единственное в последний раз я читал, что были проблемы с компиляцией ядра Линукс, не знаю устранили их или нет, но в Дебиан 8, насколько я знаю, все пакеты(и ядро наверно) можно будет без проблем компилировать clang`ом.

LLVM вроде есть под виндовс, т.к. под данную ОС есть компилятор LDC, правда только 32-разрядный.
В интернете находится clang под Windows и как его самому собрать под данную ОС, например http://habrahabr.ru/post/167281/ (но я не читал данную статью)

0

133

  • Автор: Yaisis
  • Участник
Юрий написал(а):

Ну сделал я русификацию C/C++, но я бы не стал назвать это «своим языком».

Согласен - это чужой язык, который тем не менее может стать русским.

Юрий написал(а):

А я уверен, что Вам ещё Rust понравится  Тоже неплохой язык  Если Вам нравится D, то Rust не может не понравиться. Единственное, что не очень пока понятно – заточенность на параллельные вычисления.

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

Юрий написал(а):

Понимаете, не иностранные термины, а термины иностранного происхождения. Т.е. речь идёт не о том, чтобы избавиться от «function», «hash table» или «stack», а о том, чтобы избежать употребления «функция», «хэш-таблица» или «стек». Заменив последние «задачей», «решёткой с мешаниной» и «подвалом», т.е. словами с исключительно русскими корнями.

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

Отредактировано Yaisis (07.10.2014 16:05:25)

0

134

  • Автор: Юрий
  • Управляющий
  • Юрий

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

Словари русского языка сильно отстают от жизни. Многие термины укоренились в языке явочным порядком, не взирая на наличие аналогичных слов в русском. Ну а всякого рода институты русского языка только констатируют факты задним числом. Надо играть на опережение, придумывая замены терминам до того, как они (термины) стали распространёнными. Увы, государственной политики в этом не наблюдается.

Поэтому мне видится так: пользуемся тем, что есть. Главное – сделать РЯП, а его словарный запас можно будет уточнять уже по ходу дела.

0

135

  • Автор: Yaisis
  • Участник
Юрий написал(а):

А как это сделать на Си? Как узнать количество процессоров в системе и загрузить конкретный процессор конкретной задачей? Вот в чём вопрос.

Я использовал для этого QT. Например:
QThread::idealThreadCount(); - возвращает количество потоков в системе, т.е. например, если есть 4-ядерный процессор, то вернёт 4. А если 4-ядерный процессор с hyper-treading`ом, то вернёт 8, из них 4 виртуальных ядра.
Потом я использовал процедуру QtConcurrent::run(proc, ...); в которой "proc" - это указатель на процедуру, а "..." - это список параметров для этой процедуры. Я запускал эту процедуру в цикле столько раз, сколько потоков имеется и таким образом загружал все потоки процессора, индикатор загрузки процессора у меня выводил полную загрузку.

И последняя процедура - это QThreadPool::globalInstance()->waitForDone(); - она ждёт завершения всех запущенных потоков, чтобы программа не выполнялась дальше, пока они не завершаться.

В QT есть ещё полезные функции, но для моей задачи луше подходили именно эти 3.
И кстати QT - это не GUI, а это фреймворк, в котором есть и GUI в том числе, а кроме GUI там ещё много всего.

Я использовал QT и OpenCL, ещё можно использовать OpenMP, ещё есть OpenACC и т.д.
С помощью OpenCL можно загрузить, как процессор, так и видеокарту, а можно и то и то одновременно. Можно одновременно загрузить все вычислительные устройства в системе, поддерживающие OpenCL.

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

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

Отредактировано Yaisis (07.10.2014 18:58:34)

0

136

  • Автор: Юрий
  • Управляющий
  • Юрий

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

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

Ну не всегда больше – это лучше, чем меньше :) Поддержка многозадачности – она не бесплатная, есть накладные расходы. В системах, где приоритет – энергосбережение, а не вычислительная мощь, накладных расходов лучше избегать.

0

137

  • Автор: robur
  • Участник
Yaisis написал(а):

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

8-) Раз пошла такая пьянка...  Не надо справочник, справочник потом .. учебник за 5-6 классы раздел грамматика из которой следует что   ...Должны быть   ...Имена, (имя существительное)  которое обозначают примет, в данном случае предметы программы.. Класс, объект к примеру, и  отвечающие на вопрос, Кто? Что?.  Должны быть к этим именам и прилагательные.. то бишь (ц) ...обозначающие признак признаки предмета)) отвечающий исчерпывающий на вопрос какой? какое?  ...чей?. и.т.д  ...по человечий в общем свойства предмета. Должны быть и глаголы  - (ц) обозначающие действия предметов - Методы по научному. Должны быть наречия - обозначающие признак действия и отвечающие на вопросы как? куда? когда?, то бишь указатели  на глаголы (методы). Местоимения  указатели на имена и прилагательные... ну и так далее)).   Короче, хвала тому "Сишнику" кто пыхтел над созданием этого языка ООП  ..то есть русского языка)) в прочем он старался не только над ним.

Отредактировано robur (07.10.2014 21:16:07)

0

138

  • Автор: Yaisis
  • Участник
Юрий написал(а):

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

С вами я согласен, просто я имел ввиду совсем другое. Под "лучше" я имел ввиду то, как выжать из процессора максимум производительности. А так конечно всё зависит от задачи и от условий.

0

139

  • Автор: Yaisis
  • Участник
robur написал(а):

Раз пошла такая пьянка...  Не надо справочник, справочник потом .. учебник за 5-6 классы раздел грамматика из которой следует что   ...Должны быть   ...Имена, (имя существительное)  которое обозначают примет, в данном случае предметы программы.. Класс, объект к примеру, и  отвечающие на вопрос, Кто? Что?.  Должны быть к этим именам и прилагательные.. то бишь (ц) ...обозначающие признак признаки предмета)) отвечающий исчерпывающий на вопрос какой? какое?  ...чей?. и.т.д  ...по человечий в общем свойства предмета. Должны быть и глаголы  - (ц) обозначающие действия предметов - Методы по научному. Должны быть наречия - обозначающие признак действия и отвечающие на вопросы как? куда? когда?, то бишь указатели  на глаголы (методы). Местоимения  указатели на имена и прилагательные... ну и так далее)).   Короче, хвала тому "Сишнику" кто пыхтел над созданием этого языка ООП  ..то есть русского языка)) в прочем он старался не только над ним.

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

Отредактировано Yaisis (08.10.2014 02:17:04)

0

140

  • Автор: robur
  • Участник
Yaisis написал(а):

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

Да нет, вопрос в этом )), ООП это высшая стадия Процедурных. Все ООП вылезли так сказать естественным образом из своих родителей )). Как и все естественные родились от своих менее развитых предков а те из общего "ассемблера" в виде мычания и размахивания руками древних сапиенсов. Кроме этого ничего не мешает например в С++ писать в процедурном стиле С если есть такая охота он сохранил этот наследственный признак. Что касается например "функциональных" или "логических" так любой включая процедурный основан на функциях (математическое) и логике абсолютно, просто разница в записи функций и у ООП например  С++ очень бережное отношение к памяти от сюда и его особенность в типизации "в ручную", а у функциональных она большей частью просто вынесена вниз.. и функции записываются более откровенно. В общем те же яйца только в профиль.))) 

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

А вот об конкретных словах я не думал, т.к. это можно обдумать уже на ходу в процессе создания.

А вот это вы зря... снизу в верх.. это сфера все же ограничена в плане того что "неизвестных  земель" в компе нет и "земли Санникова" вы в нём не откроете. Пока не выпустят скажем квантовые процессоры, тогда может быть)) и проявятся какие ни будь новые свойства. Нужно начинать с верху и вниз.. решите пару практических задач на своём псевдокоде пользуясь правилами грамматики русского языка..   и "откомпилируйте" их структуру как следует, и Вы неизбежно придёте к тому что называют ООП.

Отредактировано robur (08.10.2014 14:28:51)

0

141

  • Автор: Yaisis
  • Участник
robur написал(а):

Да нет, вопрос в этом )), ООП это высшая стадия Процедурных. Все ООП вылезли так сказать естественным образом из своих родителей )). Как и все естественные родились от своих менее развитых предков а те из общего "ассемблера" в виде мычания и размахивания руками древних сапиенсов. Кроме этого ничего не мешает например в С++ писать в процедурном стиле С если есть такая охота он сохранил этот наследственный признак. Что касается например "функциональных" или "логических" так любой включая процедурный основан на функциях (математическое) и логике абсолютно, просто разница в записи функций и у ООП например  С++ очень бережное отношение к памяти от сюда и его особенность в типизации "в ручную", а у функциональных она большей частью просто вынесена вниз.. и функции записываются более откровенно. В общем те же яйца только в профиль.)))

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

ООП тут не причём, ну и допустим вы создали удобный язык, круто продумали ООП, но не реализовали в нём метапрограммирование - всё, мне он уже не интересен, т.к. метапрограммирование мне нравится. И так же он может оттолкнуть от себя ещё кучу разработчиков.
Или допустим вы в языке реализовали шаблоны, как в С/С++, которые вызывают только путаницу, а посмотрите, как красиво реализованы шаблоны и обобщённое программирование в D.
Или например в вашем языке надо писать лишние слова, без которых можно обойтись, то лично меня тоже такой не устроит.
Например в D можно создать переменную типа int так:
   int a;

А в вашем к примеру будет так:
  Создать переменную a;

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

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

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

А вот это вы зря... снизу в верх.. это сфера все же ограничена в плане того что "неизвестных  земель" в компе нет и "земли Санникова" вы в нём не откроете. Пока не выпустят скажем квантовые процессоры, тогда может быть)) и проявятся какие ни будь новые свойства. Нужно начинать с верху и вниз.. решите пару практических задач на своём псевдокоде пользуясь правилами грамматики русского языка..   и "откомпилируйте" их структуру как следует, и Вы неизбежно придёте к тому что называют ООП.

Тут я вас не понял, я говорил о том, как называть ключевые слова и мне не понятно причём тут ООП ?

Ну и если я неизбежно к чему-то приду, то также я могу прийти и к метапрограммированию, и к обобщённому программированию, и т.д.

Отредактировано Yaisis (09.10.2014 19:04:53)

0

142

  • Автор: robur
  • Участник
Yaisis написал(а):

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

Он ведь должен быть прежде понятен, практичным, тем должен быть и интересен. Письмена Мая то же интересны но для  гурманов...

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

круто продумали ООП, но не реализовали в нём метапрограммирование

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

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

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

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

Отредактировано robur (10.10.2014 18:15:16)

0

143

  • Автор: robur
  • Участник

:idea:   )) Если посмотреть в грамматику русского в частности в синтаксис, виды предложений по цели высказывания, то становится понятно что для программирования главными будут законы  построения побудительных предложении, то бишь "строк" и их подвид вопросительно-побудительные, в смысле   если... то... )). Повествовательные это у нас комментарии..  А вопросительными  ...мм.. как правило задаются пользователи программ которые пишут программисты ))) Ну или программа к пользователю.. в диалоге. "Сроки" в русском языке то есть единицы общения, учительницы по русскому их называют предложения, как выясняется могут состоят из двух главных подлежащего и сказуемого или одного из этих двух элементов, учительницы по русскому их называют членами, и второстепенных членов  ..ть-фу элементов. Таких как определение, приложение, дополнение, обстоятельства виды которых целая куча. Первым идут как правило подлежащее вторым сказуемое такой порядок называют прямым, но существует и законные нарушения этого правила называются инверсией что в нашем случае побудительного предложения самое то.. )) Первым идет сказуемое глагол который должен быть в повелительном наклонение а затем подлежащие как говорится кто? ..что? в случае побудительного. Хотя понятно что порядок прямого построения то же лишним не будет..)) В общем в русском языке не один ЯП закопан  :yep:

0

144

  • Автор: Юрий
  • Управляющий
  • Юрий

Я использовал следующий вариант - в языке имелась специальная переменная Контекст. И когда программист писал в программе: Переменная Х существует? Результат вопроса всегда помещался в эту переменную. Условие допускало не указывать в сравнительнйо форме Контекст явно. Например:
Переменная Х существует?
Если да тогда a=a+Х
Я не знаю насколько это правильно и корректно, но веду к тому, что данную вещь реализовать можно. Позже правда возникли вопросы следующего плана - у программиста может возникнуть желание использовать Контекст в условии далеко от заданного вопроса, что может приводить к путанице...

В так называемых конкатенативных языках программирования (типа Форт, Постскрипт, Фактор) принято по умолчанию сохранять результат хрен знает куда (точнее – в стек), а потом по умолчанию его извлекать. Фортеры считают, что так удобно. Другие считают, что из текста не ясно, что там за кулисами делалось, значит это плохой стиль программирования. Можно переписать безо всякого ущерба:

Код:
Если Переменная Х существует тогда a=a+Х

А у Вас переменная Контекст - это просто скалярная переменная? Две и более контекстных переменных не поместятся туда? И какого типа она?

0

145

  • Автор: Юрий
  • Управляющий
  • Юрий

Усложню свой вопрос.

Код:
Переменная Х существует?
Переменная Y существует?
Если да тогда	// на вершине стека – ответ последний вопрос
    a=a+Y
Если да тогда	// на вершине стека – ответ на предпоследний вопрос
    a=a+Х

Так можно?

0

146

Трудно удерживаться чтобы не писать не прочитав. Но подозрения оправдывались - часто хотелось написать то что кто-то уже написал дальше по ветке.

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

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

Насчет ассемблера. Не знаю просто и можно ли это использовать для существующих процессоров, но когда я мастерил свои процессоры, я придумал себе до нельзя простой ассемблер. В нем каждая строка это слово программы. Все команды и имена регистров прописывались в конфигурационном файле в форме "имя = значение", с нужным сдвигом уже. Далее команда писалась простым перечислением имен и чисел через пробел или запятую и все это просто складывалось по OR. В результате я мог написать команду как хотел, а также получались команды, в которых по выбору указывалась нужная специфика - условная, безусловная, есть-нет код функции АЛУ и флаги для проверки и т.п. Единственное что более сложное к этому добавлялось это вычисление выражений, адресных смещений, и задание адресных сегментов для данных и комманд.

Далее еще насчет языка, который придумывать. Стоит ли выбрать адресацию в массивах и в указателях в файле с 1 до N или с 0 до N-1 ? Просто если с 1, то тогда индекс 0 можно возвращать из функций если "не найдено", "вне границ" и т.п., тоесть насчет той пресловутой троичной логики. Тоесть не отрицательное число, которое съедало бы пол-диапазона, а 0, тоесть лишь один вариант значения. Но конечно это годится для индексов и адресов, но не для числовых значений.

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

(если А = Б (операция, операция) иначе (операция, операция) исключение (операция, операция))
или
(если А = Б (операция, если Ж = Щ операция) иначе операция)

А еще для цикла можно было бы сделать так:

((инициализация)
....
цикл <условие> //или: пока <условие>
....
(операция в конце))

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

Идея со стеком мне понравилась. Хоть она и не позволяет беспорядочно удалять, но ее можно использовать совместно с кучей. Еще возможно можно сделать два стека в одной области - заполняющихся навстречу друг другу. Если программно такое оформить сложно, то аппаратно такой задел можно сделать.

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

Отредактировано Алексей Яковлев (28.05.2015 04:52:06)

0

147

Если воплощать многоязыковость, то название языка последующего кода можно ставить в начале кода на самом этом языке, причем обязательно, без "по умолчанию". Словесный разборщик распознает язык даже по уникоду просто. Поэтому можно даже просто писать типа "Salut!" или "Cool beans" или "И было так..."

0

148

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

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

Ж += А < Б ? 30 : 40;

можно написать

Ж += (если А < Б то 30 иначе 40)

Здесь "то" просто напрашивается, хотя в других местах оно чувствуется как не нужным. Поэтому можно наверно допустить вставлять такие вставки, как уже предлагали, которые ничего не значат для компилятора/преобразователя, но улучшают читаемость и понимаемость кода.

Пример более сложного использования рператоров в выражении:

Ж += (Х = 40, (если А < Б (Д = запросить_число(), Д /= 10, Д *= 10) иначе Х)) // прибавление десяток

Мысль 2. Если заключать операторы в скобки, то не только можно определять внутри временные переменные, как в многих языках, но и дать возможность использовать команду "exit/выход", по которой будет переход за правую скобку, как если бы из одно-проходного цикла.

Отредактировано Алексей Яковлев (28.05.2015 06:53:21)

0

149

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

0

150

Да, я про язык Юрия говорил. Про его вариант. Ну тут никуда не денешься, когда программист по своему нраву выбирает каким языком воспользоваться. Можно еще варианты для операций в выражениях:

((кл = 0, ОбщийДоход = 0) цикл кл < КоличКлиентов
ОбщийДоход += ((д = 0, Сумма = 0) цикл д < Клиент[кл].КоличОпераций Сумма += Клиент[кл].Доход[д] (д++))
(кл++))

или:
((кл = 0, ОбщийДоход = 0) пока кл < КоличКлиентов
ОбщийДоход += ((д = 0, Сумма = 0) пока д < Клиент[кл].КоличОпераций Сумма += Клиент[кл].Доход[д] (д++))
(кл++))

Но тогда придется оговаривать что "последняя операция" в цикле не является значением выражения в скобках цикла.
В противном случае можно так:

ОбщаяСумма += ((д = 0, Сумма = 0; д++) цикл д < КоличОпераций Сумма += Доход[д])

Тоесть "последняя операция" стоит рядом с "инициализацией" и отделена точкой с запятой, а последння операция в скобках даёт им результат. Но это мысли вслух просто естественно.
А так вообще, если операции использовать в выражениях, то оно получится опять же так же трудночитаемым как в таких же спрессованных кодах в С.

А вот отступы мне жуть как не нравятся. Ошибся на один пробел и привет, особенно если код длинный. Мне нравится четкая определенность. Я могу поступиться "началом" и "концом", но вообще четким ограничением поступиться не могу. Отступы ограничивают, но они не дают охрану.

Отредактировано Алексей Яковлев (28.05.2015 16:44:45)

0

151

Алексей Яковлев написал(а):

А вот отступы мне жуть как не нравятся. Ошибся на один пробел и привет, особенно если код длинный.

Ошибка будет ещё до запуска построения приложения или запуска приложения на исполнение, если в одной строке в отступе пробелов меньше, чем в другой.
И зачем там пробелы? Лучше использовать знаки отступа. Настроил их на нужную длину — и очень удобно получается.

Ваши примеры почему-то тяжело читаются. Не нравятся мне все эти круглые скобки.

Мне кажется, что вы и Юрий не туда идёте.
Нужно стремиться, наоборот, к простоте и ясности: чтобы бросил взгляд на указания, на их построения — и сразу понятно всё.
А у вас приходится всматриваться пристально: где там одна скобка, где там две и т.д.
В общем, моё личное мнение: не выстрелит такой язык.

Слово «цикл» — просто уродство какое-то. Корня русского в нём нет, поэтому как-то неестественно воспринимается.
Лучше повтор или повторять. Но не в вашем случае.

Я смотрю на эти примеры и понимаю, что люди, которые их пишут, работают очень много с языками Си и Си++. Я прав?
Уже давно многие умные люди предостерегали: Си ломает мышление, приучает к беспорядку, такие языки вредны.
Но никто не слушает, как правило. Вот и итог.

0

152

Сергей написал(а):

Ошибка будет ещё до запуска построения приложения или запуска приложения на исполнение, если в одной строке в отступе пробелов меньше, чем в другой.
И зачем там пробелы? Лучше использовать знаки отступа. Настроил их на нужную длину — и очень удобно получается.

Нет. Без ошибок, которые компилятор/преобразователь заметит. Например отступ назад можно по ошибке не туда отодвинуть. А скобка, круглая или фигурная, от такого защитит. Знак отступа это в редакторе специальном? А если в простейшем текстовом редакторе писать?

Сергей написал(а):

Ваши примеры почему-то тяжело читаются.

Я так и сказал - трудночитаемо получается.

Сергей написал(а):

Я смотрю на эти примеры и понимаю, что люди, которые их пишут, работают очень много с языками Си и Си++. Я прав?
Уже давно многие умные люди предостерегали: Си ломает мышление, приучает к беспорядку, такие языки вредны.
Но никто не слушает, как правило. Вот и итог.

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

0

153

Алексей Яковлев написал(а):

Нет. Без ошибок, которые компилятор/преобразователь заметит. Например отступ назад можно по ошибке не туда отодвинуть. А скобка, круглая или фигурная, от такого защитит.

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

Алексей Яковлев написал(а):

А если в простейшем текстовом редакторе писать?

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

0

Ответить
Страница:   1 2

Быстрый ответ

Напишите ваше сообщение и нажмите «Отправить»


Вы здесь » Русские вычислители » Русский язык программирования: от слов к делу » Русский язык программирования - с чего начать?