Comments 61
По поводу оптимизации… странно требовать оптимизации от языка, занимающего промежуточное место между Си и Ассемблером. Ведь по сути это тот же Ассемблер, только чуть более структурированный, и по идее в таком языке должна быть не оптимизация, а однозначные и задокументированные правила преобразования высокоуровневых констуркций в код.
Мне кажется, что это довольно фатальный недостаток, причем его исправление поломает старые программы
>Мне кажется, что это довольно фатальный недостаток, причем его исправление поломает старые программы
Вы что, серьезно? Оценивать язык программирования не по семантике, выразительности и наличию концепций и средств, а по синтаксису алгебраических выражений? Тогда Lisp с его полным отсутствием приоритетов операций наверное очень плохой язык. И Smalltalk с его полным аналогом приведенного https://ideone.com/TsBHuS — тоже. Ну да, это же мертвые языки, которые не содержат никаких интересных и революционных концепций, а весь мейнстрим пишет на настоящих нормальных языках, в которых арифметика на бинарных инфиксных операциях с понятным еще с первого класса приоритетом…
Также и с приоритетами. Так сложилось, что человечество использует инфиксную запись с приоритетами. Для компилятора нет никаких проблем реализовать построение AST с приоритетами. Тогда зачем ломать мозги миллионам программистов на ровном месте?
Вот только лисп сюда приплетать не надо. Он необычный/непривычный (если с него не начинать, конечно) — это да. Но давайте представим, что мы его совсем не знаем и смотрим на код:
(+ 1 2 (- 3 4) 5)
Да, будет непривычно/непонятно. Но как только мы понимаем префиксную нотацию, то всё становится прозрачно. Про приоритеты задумываться не надо и самое главное — нет конфликта с уже имеющимися знаниями и привычками. А вот если мы видим код 2+2*2
, то весь наш опыт будет протестовать против результата, который выдаст С--.
И да, Smalltalk меня этим тоже напрягает. Но в нём за отсутствием приоритетов стоит идея того, что все операции — это посылка сообщений. А вот в C-- оно зачем?
типа (- 1) (- 1 2) и (- 1 2 3) вам сразу и интуитивно понятно как будут вычисляться
"Совсем сразу" — нет. После того как понял базовый принцип — вполне. Тут главное, что оно предыдущему опыту никак не противоречит.
Я понимаю зачем оно так в Смолтоке
Я тоже, именно поэтому претензий и не выдвигаю. Не знаю откуда столько агрессии.
смутно догадываюсь, почему оно так в С--
Ну так озвучьте. Потом можем порассуждать приносит ли это какие-то преимущества или нет.
Но если это главный недостаток языка, а других недостатков нет — то он просто идеален тогда.
Это вообще к чему? Где я о качестве языка высказывался?
От обилия близких индивидов на харбе (впрочем, как и везде), которые пишут глупости.
> Ну так озвучьте. Потом можем порассуждать приносит ли это какие-то преимущества или нет.
Думаю, это было как минимум удобнее разработчику компилятора, но ценой неудобства пользователей. Можно ли написать какой-нибудь препроцессор для перевода из стандартной нотации? Конечно, об этом ниже писали уже. В Лиспе тоже можно макросы инфиксных бинарных операций написать.
> Это вообще к чему? Где я о качестве языка высказывался?
К тому, что вы поддерживаете критиков языка из-за одного момента реализации его синтаксиса. Я С-- не знаю и использовать вряд ли буду, но в Смолтоке тот же самый синтаксис арифметики. Это то же самое, как если кто-то вам (как Rust-аману) будет говорить, что Rust плохой потому что там синтаксис плохой или скобочки не те.
Думаю, это было как минимум удобнее разработчику компилятора, но ценой неудобства пользователей.
Отличный подход, ничего не скажешь.
Это то же самое, как если кто-то вам (как Rust-аману) будет говорить, что Rust плохой потому что там синтаксис плохой или скобочки не те
Регулярно говорят, но на людей я не бросаюсь. (:
И да, в расте есть куча моментов которые мне не особо нравятся. Как из-за (не)привычности, так и "более объективных". И к аргументированной критике отношусь совершенно спокойно, даже с интересном: любопытно же узнать, что разным людям в глаза бросается. Довольно занятно как раст воспринимается людьми в зависимости от их "любимого языка". И в общем-то это довольно важно, если мы хотим новый язык продвинуть: каждая "необычность" должна быть чем-то обоснована, иначе будет сложнее отвоёвывать целевую аудиторию.
Повторюсь касательно Смолтока: я понимаю почему так сделано и понимаю, но там оно хотя бы "логично" в рамках языка. И собственно, является продолжением его особенностей.
Для всего языка парсер написал, а такая примитивная вещь, как арифметические выражения, стала последней соломиной? :)
(- 1) = 1 не противоречит?
length (1, 2) = 1 не противоречит?
Во многих интересных языках можно найти что-то «противоречащее предыдущему опыту». Но можно обогащать свой опыт, а можно «не пущать» и «Катерина, доколе» (С)
(- 1) = 1 не противоречит?
Тут противоречит разве что минус работающий по разному в зависимости от того есть пробел или нет. С другой стороны, о том, что разделителем является пробел и о том как выглядит вызов функций мы, скорее всего, узнаем из любого букваря ещё до того как до арифметики дойдём.
Во многих интересных языках можно найти что-то «противоречащее предыдущему опыту».
Разумеется. Но я с самого начала говорил, что ценность "оригинальности" имеют не сами по себе, а вместе с новыми возможностями. Или вы с этим не согласны? А то ведь можно "обогащать свой опыт" вещами типа brainfuck или ещё лучше — whitespace.
Это все равно, что вам завтра скажут, что -2 * -2 = -(2 * 2) = 4 (а почему бы и нет? это настолько же тупо, насколько 2 + 2 * 2 = 8)или 0 > 1
Я имел ввиду -2 * -2 = -(2 * 2) = — 4
Тогда как 2 + 2 * 2 = 2 + (2 * 2) или (2 + 2) * 2 — это не фундаментальное различие математических теорий, а тривиальное различие алгебраической нотации в рамках одной и той же математической теории. Приоритет операции умножения над операцией сложения, которому учат в школе — не фундаментальный закон мироздания, а соглашение о записи, нужное только и исключительно лишь для экономии скобочек при записи.
"Приоритет операции умножения над операцией сложения, которому учат в школе — не фундаментальный закон мироздания, а соглашение о записи, нужное только и исключительно лишь для экономии скобочек при записи."
Что то я это не совсем понял — а как же тогда мы можем строить мосты, туннели и коллайдеры — ведь их строят по предварительным расчётам, и, часто в единственном уникальном экземпляре — не то что табуреты.
При этом шаблоны гнутся и трещат, например, при изучении комплексных чисел (еще в пятом классе мы познали, что извлекать квадратный корень из отрицательного числа нельзя!), при изучении пределов (мы же уже познали, что делить на ноль нельзя!), при изучении теории вероятностей (что это, вообще, за число, которое может три, а может пять, а может ноль??). И это таки тоже большая проблема?
При этом существуют другие формы записи алгебраических выражения — всякие префиксные и постфиксные нотации, например, прямая и обратная польская нотация, и даже — о боже! — языки, на них основанные. И это тоже большая проблема? Запретить, всё запретить, тому ли нас во втором классе учила Марьванна, доколе же, Катерина, будешь испытывать ты наше терпение…
При этом существуют другие формы записи алгебраических выражения — всякие префиксные и постфиксные нотации
Так они, как правило, применяются ради чего-то, а не просто так. Скажем, префиксная нотация лиспа помогает парсить однозначно и упрощает работу с кодом как со списками. То есть, новшества хороши когда дают какие-то преимущества. А оригинальность ради оригинальности только оттолкнёт людей.
Феноминально, что язык ещё жив. Я в своё время писал на нём всякие мандельбротики, визуализаторы игры жизнь, архиваторы, и прочую мелочь. Тогда это казалось востребованным, ибо компилятор С не был так умён. Сегодня же, не вижу смысла уползать ниже Rust/C без лишней необходимости.
Вопрос безо всякого подтекста — а в чем именно компилятор Си не был так умен?
Это превратит код в lisp и убьет вообще какую-либо совместимость с С-like.
А разве нельзя просто сделать конвертер для старых файлов и перегонять их в новые — уже с приоритетами операций?
Очень просто — при конвертации конвертер в файл вставляет скобки в выражения и закомментированную спецпометку, на манер хеш суммы от времени конвертации с замечанием "Не удалять!!!" и пояснением — что за пометка и зачем она.
При конвертации проверяется наличие скобок, спецпометки и если не того ни другого нет, значит это старый файл, выражение конвертируется слева направо (ибо таковы правила языка — (2+2)*2).
Вообще, же не вижу особой проблемы здесь — вместо "лестницы приоритетов" в языке простое и запоминающееся правило — "слева-направо", но если уж хочется — можно поправить компилятор, чтобы он выдавал предупреждения специального вида о необходимости расставить скобочки — тогда и старое работать будет и в новом скобки ставить станут — ну или же, компилятор будет ориентироваться на спецметку, (которая автоматически появится в новых файлах после его доработки и старые без метки будет трактовать как "слева-направо" а новые — по приоритетам.
А вот куда важнее научить компилятор 64-битному коду — 32-битный уже уходит в прошлое (может, от LLVM-Clang кодогенератор взять для него?..) и научить компилироваться в Posix-системах (когда последний раз его смотрел, он был только под Виндой) — эти системы — это "естественная среда обитания" компиляторов, ему там будет хорошо — как белке в родном лесу.
Я может быть сейчас от незнания сморожу, но можно ли писать под эту ОС на Rust?
Мне кажется, что аналогичная статья про Rust (если можно конечно), была бы очень интересна (благодаря хайпу), и возможно я (и даже куча других людей) бы даже попробовал свои силы в написании каких нибудь программ под эту ОС.
Ну а если нет — тогда ждём....
Сообщество Rust вполне возможно дало бы импульс развитию этой ОС.
Ну это какие-то очень размытые требования — очень сильно зависит от решаемых задач, да и требования к "адекватности" у каждого свои :). Тут в общем виде не скажешь. Для меня и моих задач адекватные библиотеки и документация для ОС "первого уровня" наличествуют)
Хелп есть по языку и стандартной библиотеке, а они (как и с большинством языков) стараются быть независимы от платформы. Документация к сторонним библиотекам, очевидно, зависит от авторов библиотек и бывает разного качества.
В любом случае, готов спорить, что для раста библиотек куда больше чем для С--.
В определённых условиях — вполне. И уж точно из вас получится лучший транспорт чем из Хокинга.
Но я не совсем понимаю к чему вы клоните. К тому, что нет смысла выбирать из (условно) двух инвалидов при наличии более подходящих вариантов? Возможно, вот только всё, опять же, зависит от условий. Как по мне, то выбирать С-- и писать на нём что либо тоже нет никакого смысла. Но кому-то стало интересно и в результате появилось некоторое количество программ и если они популярны, то какая разница на чём написаны?
Если же вернуться ближе к расту, то (на мой взгляд) рядом преимуществ он обладает, причём даже в сравнении с С и С++, а не только С--. И программы на нём вполне пишут, в том числе и коммерческие. Насколько он нужен в контексте KolibriOS — это уже другой вопрос.
А так вроди Си должен нормально подойти, надо почитать что умеет ОС. С первого взгляда, без malloc(), free() (и прочая работа с динамической памятью) и FILE Си очень даже подходит.
Не пойму я нафига это всё? Для каждой архитектуры писать свой ассемблерный код? А как потом заинлайненую ассемблерную функцию компилятор будет оптимизировать? Даже если и нужно по каким-то причинам писать ассемблерный код — есть же inline assembler.
Бред.
Если этот пример неправильно работает, замените
DefineAndDrawWindow(215,100,350,300,0x34,0xFFFFFF,"Window header");
на
DefineAndDrawWindow(215,100,350,300,0x34,0xFFFFFF,"Window header", 0);
C--. Первое знакомство