>>Правильно объявлять function или func,Без доказательное утверждение, замена одних символов на других - дело вкуса, и если даже заменяем, то заменяем в одно-однозначном отношении, без противоречий. Форма записи (x) может приводит к неоднозначному отношению. Поэтому, чтобы этого всего избегать нужно придумать синтаксис из конечных предложений типа
new function definition function_name_blabla(Argument X) {}
а не просто func blabla(x) в этом случае имя "неправильно подобранное" имя функции может ввести неоднозначное соответствие к её алгоритму. Поэтому добавил вначале префикс function_name_USER_DEFINED_FUNCTION_NAME. Вызов функции ранее обьявленной также -
call user defined function function_name_blabla(Argument X) и тд.
Но такой подход, как показывает практика "ленивых программистов", символьно избыточен.
>>Если вы хотите фана, то вам конечно без разницы на чём писать.
Да, без разницы, потому-что итог должен быть один, оптимальный конечный машинный код.
>>А если чтобы работало, было читаемо, сопровождаемо и вообще не стыдно было показать, то нужно чтобы намерение было чётко задекларировано.
Чтобы удовлетворить ваши критерии языка - ЯП должен быть фактически схож с естественным человеческим языком, но даже если так и будет, что мы обычными предложениями естественного языка писали алгоритмы, то не было бы на данный момент никаких проблем с машинным переводами. Но, что будет делать ЦП (центральный процессор) когда он встретит предложения антиномии (парадоксы)?
>>Код должен быть самодостаточный и наглядный.
Опять утверждаете, но не то чтобы доказательств нет, пример банальный не приводите.
>>Тогда его можно реально показывать "людям не в теме" и они смогут сказать "вот тут у тебя ошибка в рассчётах".
Людям нужно показывать псевдо код, если мы ищем логические ошибки, а если показывать конкретно код на конкретном ЯП - то это только поможет найти синтаксические ошибки, которые за нас ищет сам ЯП (компилятор и т.д.). В математике тоже самое - есть формула достаточно короткая и под ней её полное доказательное описание на естественном языке, никто не пытается создавать самодостаточные формулы, а если это делать то мы придём к естественному языку.
>>"достаточно один раз выучить"
Выучить что? если есть одно-однозначное отношение между new function definition и func, то почему бы и нет ? Типичная символьная замена.
>>Возьмите тот же SP-Forth, там как бы ничего сложного, "в тему" вникнуть легко - ложим всё на стек, потом выполняем нужные операции. Но вынос мозга на сколь нибудь большом и сложном коде я вам обещаю.
Зачем должен быть вынос мозга если стоит задача разобрать код программы?
И плюс хорошей практикой является документирование кода, не просто коментарии к коду а именно документирование. Как в математике, когда пишется формула - то описываются все входящие в неё символы и какой смысл они носят.
пс:
>>Сиди потом, гадай, fn - это function или filename, или ещё что-то.
не придётся гадать если есть описание этой замене символов. Вы в праве использовать как f, fn, fun, func, function и т.д., но дайте описание по использованию этих символов (сокращений) на естественном языке, ибо ваши замены ясны только лишь ЦП (ЯП), отсюда выводится очевидное, что код программы пишется для машины (хотя утверждают, что код должен писаться "понятным" для человека). Машина не способна понять естественный человеческий язык, хотя человек спокойно разберётся с любым языком предназначенным для машины (даже если он состоит из 0,1).
