Язык программирования 1 теперь работает на Эльбрусе

Для какого параметра?

Вот это: «Вот этот код можно сделать гораздо более понятным и выразительным без единого комментария. Просто нужно назвать функцию соответственно тому что она делает. Каждую строчку также сделать функцией также имеющей соответствующее имя. И внезапно понять вычисление сможет любой школьник.».

Как будет выглядеть код в правильном виде?

Как-то так

const float precalculatedApproxConstant = 0x5f3759df;

float square(float x) {
   return x*x;
}

float firstApproximation(float x) {
  int i = *(int*)&x;
  i = precalcualtedApproxConstant - (i >> 1);
  return *(float*)&i;
}

float secondApproximationNeuton(float firstApproximantion, float x) {
  return firstApproximation*(1.5f-(0.5f*x*square(firstApproximation)));
}

float invertedSquareRoot(float x) {
  return secondApproximationNeuton(firstApproximation(x), x);
}

Я полагаю конвертирование типов и умножение на 2 можно отдельно не расписывать, т.к. это идиомы Си.

Это очевидный кусок кода

float firstApproximation(float x) {
  int i = *(int*)&x;
  i = precalcualtedApproxConstant - (i >> 1);
  return *(float*)&i;
}

?

А что тут непонятно? Ну используется некая формула из справочника для приблизительного вычисления обратного корня. Или в коде нужно объяснять весь «матан»? Для этого есть учебники.

Хм, а чем КуМИР не нравиться?

Исключительно крайней ограниченностью. Там же даже структур нет.

Ну используется некая формула из справочника для приблизительного вычисления обратного корня. Или в коде нужно объяснять весь «матан»? Для этого есть учебники.

Для этого в комментариях пишут ссылку на учебник. Потому что иначе потом программу переносят на другой ЯП или ЦПУ, где нет 32-битного float, а есть только 64-битные целые и вещественные и понимают, что новую константу посчитать неоткуда.

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

Для этого в комментариях пишут ссылку на учебник

А может и не в комментариях. Это к написанию и пониманию кода напрямую не относится.

желательно указать на наличие UB

Это можно явно обозначить в названии функции, если хочется. Вот кстати в растишке все стебутся над unsafe, а между тем это отличное языковое средство для явного обозначения такого кода. В сишечке (и вообще любом языке с UB и т.п.) тоже неплохо было бы иметь такое. За неимением специального средства можно использовать общее.

А может и не в комментариях. Это к написанию и пониманию кода напрямую не относится.

К пониманию относится напрямую. Читаешь такое в какой-нибудь геометрической библиотеке и первая реакция будет «что за фигня?», а вторая «оно разве вообще работает?». А если оно работало, а потом на новой версии линукса вдруг перестало, так ещё и неясно чем этот магический код заменять. Потому что из

float firstApproximation(float x) {
  int i = *(int*)&x;
  i = precalcualtedApproxConstant - (i >> 1);
  return *(float*)&i;
}

вообще не видно, что должно вернуться. Некое «первое приближение от приближённой константы»…

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

unsafe и UB — разные вещи. unsafe - это то, что программист сам проверил (в Си аналогом будет чтение элемента массива без проверки выхода за границы), а UB - это значит, что будет работать на конкретной версии компилятора, ОС и ЦП (и возможно не всегда).

вообще не видно, что должно вернуться

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

Читаешь такое в какой-нибудь геометрической библиотеке и первая реакция будет «что за фигня?»

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

unsafe и UB — разные вещи

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

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

Вот для этого и нужны комментарии. Чтобы можно было указать название используемого метода, если он широко известен или ссылку на статью, если мало известен. А не «угадай каким методом здесь решается система дифуров».

Чтобы такой «грязный» код требовалось помечать явно.

Как бы есть #pragma warning(disable …)

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

Ну и отдельно про сабж: брать и смешивать семантику Racket и синтаксис Haskel, на мой взгляд, плохая идея. Это поднимает порог входа до того, что надо приемлемо знать оба этих языка (не самых простых) и вдобавок помнить, что авторы добавили от себя. Кто будет на этом будет писать?

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

В общем, предельно странная поделка.

Ну и отдельно про сабж: брать и смешивать семантику Racket и синтаксис Haskel, на мой взгляд, плохая идея. Это поднимает порог входа до того, что надо приемлемо знать оба этих языка (не самых простых) и вдобавок помнить, что авторы добавили от себя. Кто будет на этом будет писать?

Если знать Racket, то для этого языка достаточно прочитать 3 страницы документации.

Если же изучать с нуля, то он проще для изучения, чем Racket.

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

Для гуглежа russian-lang. Можешь предложить свой вариант.

Как бы есть #pragma warning(disable …)

Костыль же.

угадай каким методом здесь решается система дифуров

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

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

нужны комментарии

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

Название совершенно негуглябельное. Хуже чем у го.

уверен, что она имеет известный специалистам референс

Ага. 0x5f3759df. Назовёшь firstApproximationMagic0x5f3759df ?

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

Кстати, ссылка на пункт ТЗ в комментарии тоже частая практика.

Комментарии это канал взаимодействия людей работающих над проектом.

Вот! Код для машины, а для людей комментарии и документация. Часть кода самодокументируема (имя переменной или функции уже комментарий), но не весь (так как в имя функции пару абзацев вставить нельзя, а в комментарий можно).

Может предложишь свой вариант?

https://yandex.ru/search/?text=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9+%D1%8F%D0%B7%D1%8B%D0%BA+%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F+1&lr=973 у меня находит.

Нашёл прекрасное. Посмотри, как люди мучаются, только чтобы английский не учить: https://marketplace.visualstudio.com/items?itemName=intellsmi.comment-translate

Назовёшь firstApproximationMagic0x5f3759df

Нет, назову как она называется. Ты же не пишешь magicSquare3.1415.

ссылка на пункт ТЗ в комментарии тоже частая практика

Самая частая практика это не писать никаких комментариев.

комментарии и документация

Это одно и тоже. Масло масляное.

предложишь свой вариант

АДИН-АДИН!!!111

Потом книжку напишешь «Язык Адина!»

Это одно и тоже. Масло масляное.

Вот нет. Комментарии в коде, а документация в виде отдельного документа или набора документов.

https://github.com/belonesox/python-udaff-encoding

Адина

עדינה ?

Ну вот видишь какое глубокое название? Пользуйся. Завирусится только в путь.

Для гуглежа russian-lang

По запросу russian-lang гуглится, внезапно, русский язык.

Убедили. Переименую в «Адина».

И да, удобно когда класс определяется словом «класс»

Это очень удобно тем, кто предыдущие 12 лет считал «класс» комнатой, набитой 25ю шумными пеньками, которых так же называли классом.

Так что class даже лучше, чем класс, поскольку однозначно указывает на class, а не на класс или класс.

Когда я изучал, а потом преподавал математику и физику, я всегда радовался, что пишу на кириллице, а не латинице или греческом. Поскольку z – это однозначно аппликата, а не zombies.

Это очень удобно тем, кто предыдущие 12 лет считал «класс» комнатой, набитой 25ю шумными пеньками, которых так же называли классом.

У них ещё биология была. Где они все были отнесены к классу млекопитающих.

Поскольку z – это однозначно аппликата, а не zombies.

Однобуквенные переменные в программировании уже редки. А getElementsByTagName легче понимать на родном языке.

В целом, проще грохнуть базовые станции и прочую инфраструктуру.

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

Бухгалтерия и склад — нишевые продукты, даже если вся страна получает зряплату при помощи 1C, что, конечно же, является явным преувеличением.

Хых. А что, комментарии в коде бывают исключительно на английском?

ЗЫ выше уже рассказывал о том, как некоторое время читал код, написанный китайскими коллегами. Ну, в целом, всё понятно, особенно, если пару-тройку десятков иероглифов выучить :-)

«Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует». Бьерн Страуструп

Китайский-то ладно. Вот польский код читать - это жесть.

class Obrazek {
    public:
        void narysujLinie(void);
        void narysujKwadrat(void);
        void narysujElipse(void);
        void narysujWypelnionyKwadrat(void);
        void narysujWypelnionaElipse(void);
        int aktualnaWersja(void);
        int aktualnieZapamietanych(void);
        void zapamietajZmiany(void);
    private:
        int wysokosc, szerokosc;
        int wersja, zapamietane;
        bool rysowanie;

Так в том-то и дело. Что если задача поставлена на одном языке, а объекты в коде названы на другом, то где-то в цепочке (задача - документация - комментарии - код) будет разный язык в соседних звеньях. И, как следствие, потеря информации при переводе.

Если задание написано по-английски, то проблемы не возникает. Но в РФ это встречается очень редко.

Вроде всё понятно. Даже лучше, чем английский.

Польская жесть страшнее этого:

吾有一術。名之曰「埃氏篩」。欲行是術。必先得一數。曰「甲」。乃行是術曰。
	吾有一列。名之曰「掩」。為是「甲」遍。充「掩」以陽也。
	除「甲」以二。名之曰「甲半」。

	有數二。名之曰「戊」。恆為是。若「戊」等於「甲半」者乃止也。
		有數二。名之曰「戌」。恆為是。若「戌」等於「甲半」者乃止也。

			乘「戊」以「戌」。名之曰「合」
			若「合」不大於「甲」者。
				昔之「掩」之「合」者。今陰是矣。
			若非乃止也。
		加一以「戌」。昔之「戌」者。今其是矣云云。
	加一以「戊」。昔之「戊」者。今其是矣云云。

	吾有一列。名之曰「諸素」。
	昔之「戊」者。今二是矣。恆為是。若「戊」等於「掩」之長者乃止也。
		夫「掩」之「戊」。名之曰「素耶」。
		若「素耶」者充「諸素」以「戊」也。
	加一以「戊」。昔之「戊」者。今其是矣云云。
	乃得「諸素」。
是謂「埃氏篩」之術也。

施「埃氏篩」於一百。書之。

?

А мне просто очень смешно становится в процессе: «инт высокошть, серокость» :)

Да, тут я прочитать ничего не могу, поэтому нормально.

А мне просто очень смешно становится в процессе: «инт высокошть, серокость» :)

Так и русскоязычные ЯП по той же причине отвергаются. Синдром утёнка.

После гуглопереводчика там прямо поэма.

Я тут скорее попадаю в такую вот uncanny valley, только не «зловещую», а наоборот. Достаточно похоже на русский, чтобы понимать. И достаточно непохоже, чтобы не принимать.

Да. С русскоязычными ЯП та же проблема.

А = Новый Структура;
Для каждого Строка Из МассивЗначений Цикл ...

Достаточно похоже на русский, чтобы понимать. И достаточно непохоже, чтобы не принимать.

А вот этот китайский код - нормальный литературный китайский. Но звучит примерно так:

У меня есть техника. Она зовётся "Решето Эратосфена". 
Желание этой техники. Надо сначала получить первое число.
Назови "Раковиной". Движение этой техники гласит.

   У меня есть ряд. Он зовётся "Сокрытое". Считай "Раковина" раз. Наполни "Сокрытое" истиной.

   Раздели "Раковину" на два. Назови "Половина раковины".

   Есть число два. Назови "Копьё". Считай вечно. Лишь когда "Копьё" сравняется с "Половиной раковины" остановись.
   ...

Однобуквенные переменные в программировании уже редки. А getElementsByTagName легче понимать на родном языке.

Так это не ЯП на родном языке, а удобные для понимания идентификаторы от программиста. Разные вещи.

Хочу напомнить, что уже был ЯП на русском: Ершова или просто «Алгоритмический язык». Так вот в нём, чтобы отличить операторы ЯП, их ПОДЧЁРКИВАЛИ. Т.е. делать операторы ЯП на родном языке так себе идея. Как и делать ЯП близким к естественному. Вспомните тот же Cobol.

Слушай, ну вот полистал сейчас примеры на языке «Рапира». Отторжения никакого не вызывает, всё хорошо.

http://ershov.iis.nsk.su/ru/node/772584

Как и делать ЯП близким к естественному. Вспомните тот же Cobol.

Для языка, выпущенного в 1959 году, он очень живуч.

Т.е. делать операторы ЯП на родном языке так себе идея.

Иначе получается что-то вроде:

for(int Номер = 0; Номер < Сотрудники.length(); Номер++)
{
   cout << Сотрудники[Номер].Имя << endl;
}

Тема кириллизации не раскрыта. Нужно добавить систему записи чисел кириллицей. 😎