Смотрю на новые компилируемые языки вижу следующие вещи:
1. Отказ от исключений
2. Отказ от автоматического разрешения ссылок (только подсчет ссылок+-слабые ссылки)
3. Поддержка функцирнальщины.
4. Отказ от классов/объектов => замена на интерфейсы.
Rust,Swift и т д
а вы какие тенденции заметил и почему так?
(упрощается генерация оптимизированного кода, отсутствие остановки мира)
Здравствуйте, s22, Вы писали:
s22>а вы какие тенденции заметил и почему так?
Ты случаем не Vogue листаешь?
s22>(упрощается генерация оптимизированного кода, отсутствие остановки мира)
Имхо, подсчет ссылок потому что разрабы вменяемый GC не осилили.
Политика по принципиальному отказу от исключений приводит к необходимости протаскивать чего-то похожего на Maybe через весь код (имеется в виду поддержка со стороны языка, а не как в С). Упрощением компилятора и кодогенерации я бы это не назвал.
Заметил тенденцию узости мысли — в прошлом веке появлялись всякие принципиально отличающиеся штуки (lisp, prolog, sql, pascal — у каждого своя идея), а сейчас новые языки — как клонированные. Кстати буду рад если ткнут в что-то крутое, что пропустил.
Среди компилируемых языков заметил тенденцию выкатывать яызыки без метапрограммирования (потому что шаблоны зло, а до макросов ещё дорасти надо), и при этом надеяться забороть С++ у которого это самое метапрограммирование фактически есть. Как следствие столкновения с реальностью где писать похожий но чуть разный код всё-таки нужно, авторы начинают боготворить кодогенерацию. Получают предсказуемый эпик фэйл и повторяют через года 2-3 (столько сейчас занимает реализация типового компилятора?) красивый выход ещё раз с чуть другим синтаксисом, названием и фамилиями авторов. Пичалька в общем.
Как выше написал hardcase — вначале все обещают GC, обламываются в реализации и делают подсчёт ссылок (который в общем-то убогий GC, и в котором тоже можно словить вполне заметные проблемы там где не ждёшь). С исключениями та же фигня — сейчас все компиляторы хотят уметь хотя-бы x86, x64, Arm. Нормальная реализация исключений — это трудно, вот и лепят коды ошибок. Дурят голову программистам которые уже освоили C++, и позволяют им повторить путь индустрии 70-х прошлого века (вроде тогда первые статьи пошли о пользе исключений) чем поворачивают их назад в C++.
Из маргинальных языков радует редко упоминаемый тут Nim — компилируемый, статически типизированный, есть какой-то GC с некоторыми настройками, есть исключения, есть макросы но (пока?) без квази-цитат и есть шаблоны (квази-цитаты без макросов?), есть целых 3 перегрузки оператора '.', memory regions, декларируется автоматический решатель/доказатель того что программы работают на непересекающихся данных (имхо это грамотнее чем вводить кучу видов указателей), замыкания, yield, возвращаемые значения lvalue (зачем? пока не разобрался...), и куча других интересностей. Но развивается медленно. Часть синтаксиса как будто содрана с Nemerle — не думаю что до квадратных скобок в Generics можно самому додуматься
Здравствуйте, hardcase, Вы писали:
H>Ты случаем не Vogue листаешь?
Нет.
s22>>(упрощается генерация оптимизированного кода, отсутствие остановки мира) H>Имхо, подсчет ссылок потому что разрабы вменяемый GC не осилили.
Apple не осилила?
Mozilla?
Где то читал, что "вменяемый GC" на телефоне требует как минимум 0,05 секунды задержки, что Apple признали не приемлемым, так как пользователь будет ощущать дискомфорт.
Далее как быть в случае с многопоточностью с GC? везде бросать локи? Я не спорю, что может быть ты всегда способен переделать алгоритм на минимум локов, но в Мозиле не уверены ии они пошли другм путем... Компилятор направляет на безлоковость кода.
H>Политика по принципиальному отказу от исключений приводит к необходимости протаскивать чего-то похожего на Maybe через весь код (имеется в виду поддержка со стороны языка, а не как в С). Упрощением компилятора и кодогенерации я бы это не назвал.
Об этом был пост на gcc, зачастую из за исключений и не формулирования точной точки исключения = необходимости хранить стек в случае оптимизации -O3 разница составляет 2 раза!
Вопрос, инлайнет ли Net код, если в коде есть цепочка исключений и в каких версиях да/нет?
Здравствуйте, hi_octane, Вы писали:
_>Как выше написал hardcase — вначале все обещают GC, обламываются в реализации и делают подсчёт ссылок (который в общем-то убогий GC, и в котором тоже можно словить вполне заметные проблемы там где не ждёшь).
Не обязательно городить подсчет ссылок, можно как в Rust — уникальные указатели и контроль за ними. С точки зрения надежности и скорости — самый лучший вариант.
_>С исключениями та же фигня — сейчас все компиляторы хотят уметь хотя-бы x86, x64, Arm. Нормальная реализация исключений — это трудно, вот и лепят коды ошибок. Дурят голову программистам которые уже освоили C++, и позволяют им повторить путь индустрии 70-х прошлого века (вроде тогда первые статьи пошли о пользе исключений) чем поворачивают их назад в C++.
Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов.
К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть.
ARK>Не обязательно городить подсчет ссылок, можно как в Rust — уникальные указатели и контроль за ними. С точки зрения надежности и скорости — самый лучший вариант.
Ну и в итоге преимуществ перед C++ примерно 0, как следствие повторяем очередную итерацию борьбы с C++. Проверено предыдущими поколениями убивцев C++.
ARK>Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов. ARK>К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть.
Как-то упустил минусы исключений. Можешь перечислить или кинуть ссылку где прочитать?
Здравствуйте, hi_octane, Вы писали:
ARK>>Не обязательно городить подсчет ссылок, можно как в Rust — уникальные указатели и контроль за ними. С точки зрения надежности и скорости — самый лучший вариант. _>Ну и в итоге преимуществ перед C++ примерно 0, как следствие повторяем очередную итерацию борьбы с C++. Проверено предыдущими поколениями убивцев C++.
ARK>>Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов. ARK>>К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть. _>Как-то упустил минусы исключений. Можешь перечислить или кинуть ссылку где прочитать?
Здравствуйте, s22, Вы писали:
s22>Далее как быть в случае с многопоточностью с GC? везде бросать локи?
Если язык ссылочно-прозрачный, то все очень хорошо. Ну, вычислят два или три потока одно значение. Разве от этого что-то изменится?! Чистота как никак
А если серьезно, то даже на Java и C# можно с пользой использовать GC. Вспоминаю свой код на Си++ и Asio. Сколько там всяких заморочек, особенно со std::shared_ptr, тогда так даже на эти двух перечисленных выше не самых сложных и далеко не самых мощных языках мейнстрима было бы все много проще.
Здравствуйте, hi_octane, Вы писали:
ARK>>Не обязательно городить подсчет ссылок, можно как в Rust — уникальные указатели и контроль за ними. С точки зрения надежности и скорости — самый лучший вариант. _>Ну и в итоге преимуществ перед C++ примерно 0, как следствие повторяем очередную итерацию борьбы с C++. Проверено предыдущими поколениями убивцев C++.
Гарантированная корректность операций с памятью — это "0"? Хм.
Убить С++ мешает не его "крутизна", а то, что в него вложено огромное количество ресурсов. В обозримой перспективе смерть С++ абсолютно исключена и разговоры об убийстве С++, ИМХО, не от большого ума. Что не отменяет того факта, что С++ — это говно мамонта, перегруженное фичами и отягощенное наследственными болезнями.
ARK>>Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов. ARK>>К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть. _>Как-то упустил минусы исключений. Можешь перечислить или кинуть ссылку где прочитать?
Могу. Главный минус: исключения оставляют программу в несогласованном состоянии, с разрушенными инвариантами, и формально проконтролировать этот момент нельзя. Теоретически могло бы помочь STM, но у него свой неустранимый минус — не работает с IO.
Здравствуйте, MTD, Вы писали:
ARK>>Могу. Главный минус: исключения оставляют программу в несогласованном состоянии MTD>А необработанный код ошибки в каком состоянии оставляет программу?
В прежнем, очевидно. Правда дальше все равно развалится.
Но в современных ЯП необработанный код пропустить нельзя, компилятор запрещает.
ARK>>с разрушенными инвариантами, и формально проконтролировать этот момент нельзя. MTD>А что насчет С++ с раскруткой стека и деструкторами?
Здравствуйте, AlexRK, Вы писали:
ARK>В прежнем, очевидно. Правда дальше все равно развалится.
Нет, состояние оказывается неопределенным и если развалится, то это прекрасно, а если продолжит работу то это может быть чревато большими проблемами.
ARK>Но в современных ЯП необработанный код пропустить нельзя, компилятор запрещает.
Чмсто для общего развития — в каких? И каким образом? Ну не проверяю я что функия вернула или в "современных" языках по определению функция может вернуть только код ошибки?
ARK>Деструкторы это хорошо, не спорю. Но это, как ни крути, своеобразный костыль над исключениями.
Все костыль, нет ничего идеального, по мне так исключения гораздо лучший костыл, чем коды ошибок.
Здравствуйте, MTD, Вы писали:
ARK>>Но в современных ЯП необработанный код пропустить нельзя, компилятор запрещает. MTD>Чмсто для общего развития — в каких? И каким образом? Ну не проверяю я что функия вернула или в "современных" языках по определению функция может вернуть только код ошибки?
Rust точно, Swift не помню, но тоже, скорее всего.
Вот тут: https://doc.rust-lang.org/std/result/
Компилятор требует обработать возвращаемое значение.
ARK>>Деструкторы это хорошо, не спорю. Но это, как ни крути, своеобразный костыль над исключениями. MTD>Все костыль, нет ничего идеального, по мне так исключения гораздо лучший костыл, чем коды ошибок.
Да у нас вроде как у всех опыт есть, я видел как часто забивают на проверку, в какие спагетти превращается раскрутка стека вручную с освобождением ресурсов.
ARK>С ней в целом согласен — что исключения хороши для "простого" кода, а коды — для требовательного к качеству и скорости.
Здравствуйте, MTD, Вы писали:
MTD>Там просто есть атрибут #[must_use], что таки оставляет простор для ошибок.
Ну, это ошибки другого рода. Грамотно написанное API не позволит _пользователю_ этого API забыть проверку.
В этом отличие от обычных кодов ошибок — заставить пользователя проверить их невозможно.
Понятно, что плохое API написать можно, не вопрос. Но основные баги как раз у конечных юзеров, а не у проектировщиков библиотек.
ARK>>С ней в целом согласен — что исключения хороши для "простого" кода, а коды — для требовательного к качеству и скорости. MTD>А точно не наоборот?
Думаю, что нет. Софт на марсоходе писан на языке без исключений. Игры на современных приставках пишутся без исключений. Статические анализаторы, применяющиеся в авиакосмической промышленности (например: http://www.astree.ens.fr/, http://www.spark-2014.org/), не предусматривают использования исключений. Ядра всех этих линупсов и прочих ОС — тоже без исключений.
Здравствуйте, btn1, Вы писали:
B>Синтаксис на отступах — такое школоло сразу в топку.
Вот мне питоноподобный синтаксис на отступах тоже очень не нравится. Но с другой стороны, в хаскеле и идрисе тоже на отступах, но там ок, нет такого отторжения совсем.
Здравствуйте, MTD, Вы писали:
ARK>>С ней в целом согласен — что исключения хороши для "простого" кода, а коды — для требовательного к качеству и скорости.
MTD>А точно не наоборот?
Про качество не скажу, а вот про скорость недавно один из разработчиков интеловского компилятора рассказывал, что если в функции есть какая-то работа с исключениями, то многие оптимизации для нее сразу выключаются.
Здравствуйте, AlexRK, Вы писали:
ARK>Думаю, что нет. Софт на марсоходе писан на языке без исключений.
На такой софт тратится столько денег, что обычное прикладное ПО никто бы не купил, если бы на его разработку столько же тратили.
ARK>Игры на современных приставках пишутся без исключений. Статические анализаторы, применяющиеся в авиакосмической промышленности (например: http://www.astree.ens.fr/, http://www.spark-2014.org/), не предусматривают использования исключений. Ядра всех этих линупсов и прочих ОС — тоже без исключений.
То что многие проекты были начаты когда поддержка исключений хромала или потому, что главный архитектор фанатик — ничего не доказывает. Достаточно один раз переписать код с кодами возврата на исключения и сравнить результат, чтобы сомнения отпали, как писать проще и безопасней.
