Тенденции языков
От: s22  
Дата: 16.05.15 09:22
Оценка:
Смотрю на новые компилируемые языки вижу следующие вещи:

1. Отказ от исключений
2. Отказ от автоматического разрешения ссылок (только подсчет ссылок+-слабые ссылки)
3. Поддержка функцирнальщины.
4. Отказ от классов/объектов => замена на интерфейсы.

Rust,Swift и т д

а вы какие тенденции заметил и почему так?
(упрощается генерация оптимизированного кода, отсутствие остановки мира)
Re: Тенденции языков
От: hardcase Пират http://nemerle.org
Дата: 16.05.15 11:44
Оценка: +1 :))) :))
Здравствуйте, s22, Вы писали:

s22>а вы какие тенденции заметил и почему так?


Ты случаем не Vogue листаешь?

s22>(упрощается генерация оптимизированного кода, отсутствие остановки мира)


Имхо, подсчет ссылок потому что разрабы вменяемый GC не осилили.
Политика по принципиальному отказу от исключений приводит к необходимости протаскивать чего-то похожего на Maybe через весь код (имеется в виду поддержка со стороны языка, а не как в С). Упрощением компилятора и кодогенерации я бы это не назвал.
/* иЗвиНите зА неРовнЫй поЧерК */
Re: Тенденции языков
От: hi_octane Беларусь  
Дата: 16.05.15 13:51
Оценка: 25 (4) +10 :)))
s22>а вы какие тенденции заметил и почему так?

Заметил тенденцию узости мысли — в прошлом веке появлялись всякие принципиально отличающиеся штуки (lisp, prolog, sql, pascal — у каждого своя идея), а сейчас новые языки — как клонированные. Кстати буду рад если ткнут в что-то крутое, что пропустил.

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

Как выше написал hardcase — вначале все обещают GC, обламываются в реализации и делают подсчёт ссылок (который в общем-то убогий GC, и в котором тоже можно словить вполне заметные проблемы там где не ждёшь). С исключениями та же фигня — сейчас все компиляторы хотят уметь хотя-бы x86, x64, Arm. Нормальная реализация исключений — это трудно, вот и лепят коды ошибок. Дурят голову программистам которые уже освоили C++, и позволяют им повторить путь индустрии 70-х прошлого века (вроде тогда первые статьи пошли о пользе исключений) чем поворачивают их назад в C++.

Из маргинальных языков радует редко упоминаемый тут Nim — компилируемый, статически типизированный, есть какой-то GC с некоторыми настройками, есть исключения, есть макросы но (пока?) без квази-цитат и есть шаблоны (квази-цитаты без макросов?), есть целых 3 перегрузки оператора '.', memory regions, декларируется автоматический решатель/доказатель того что программы работают на непересекающихся данных (имхо это грамотнее чем вводить кучу видов указателей), замыкания, yield, возвращаемые значения lvalue (зачем? пока не разобрался...), и куча других интересностей. Но развивается медленно. Часть синтаксиса как будто содрана с Nemerle — не думаю что до квадратных скобок в Generics можно самому додуматься
Re[2]: Тенденции языков
От: s22  
Дата: 16.05.15 14:13
Оценка: :))) :))
Здравствуйте, hardcase, Вы писали:

H>Ты случаем не Vogue листаешь?

Нет.

s22>>(упрощается генерация оптимизированного кода, отсутствие остановки мира)

H>Имхо, подсчет ссылок потому что разрабы вменяемый GC не осилили.
Apple не осилила?
Mozilla?
Где то читал, что "вменяемый GC" на телефоне требует как минимум 0,05 секунды задержки, что Apple признали не приемлемым, так как пользователь будет ощущать дискомфорт.
Далее как быть в случае с многопоточностью с GC? везде бросать локи? Я не спорю, что может быть ты всегда способен переделать алгоритм на минимум локов, но в Мозиле не уверены ии они пошли другм путем... Компилятор направляет на безлоковость кода.

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

Об этом был пост на gcc, зачастую из за исключений и не формулирования точной точки исключения = необходимости хранить стек в случае оптимизации -O3 разница составляет 2 раза!
Вопрос, инлайнет ли Net код, если в коде есть цепочка исключений и в каких версиях да/нет?
Re[2]: Тенденции языков
От: AlexRK  
Дата: 16.05.15 16:17
Оценка: +4
Здравствуйте, hi_octane, Вы писали:

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


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

_>С исключениями та же фигня — сейчас все компиляторы хотят уметь хотя-бы x86, x64, Arm. Нормальная реализация исключений — это трудно, вот и лепят коды ошибок. Дурят голову программистам которые уже освоили C++, и позволяют им повторить путь индустрии 70-х прошлого века (вроде тогда первые статьи пошли о пользе исключений) чем поворачивают их назад в C++.


Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов.
К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть.
Re[3]: Тенденции языков
От: hi_octane Беларусь  
Дата: 16.05.15 17:24
Оценка:
ARK>Не обязательно городить подсчет ссылок, можно как в Rust — уникальные указатели и контроль за ними. С точки зрения надежности и скорости — самый лучший вариант.
Ну и в итоге преимуществ перед C++ примерно 0, как следствие повторяем очередную итерацию борьбы с C++. Проверено предыдущими поколениями убивцев C++.

ARK>Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов.

ARK>К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть.
Как-то упустил минусы исключений. Можешь перечислить или кинуть ссылку где прочитать?
Re[4]: Тенденции языков
От: s22  
Дата: 16.05.15 17:34
Оценка:
Здравствуйте, hi_octane, Вы писали:

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

_>Ну и в итоге преимуществ перед C++ примерно 0, как следствие повторяем очередную итерацию борьбы с C++. Проверено предыдущими поколениями убивцев C++.

ARK>>Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов.

ARK>>К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть.
_>Как-то упустил минусы исключений. Можешь перечислить или кинуть ссылку где прочитать?

http://stackoverflow.com/questions/1897940/in-what-ways-do-c-exceptions-slow-down-code-when-there-are-no-exceptions-thown
в инете много про это....
часто компиляторы не инлайнят код, если во вложенной функции есть вызов исключения.
Re[3]: Тенденции языков
От: dsorokin Россия  
Дата: 16.05.15 18:10
Оценка: +2
Здравствуйте, s22, Вы писали:

s22>Далее как быть в случае с многопоточностью с GC? везде бросать локи?


Если язык ссылочно-прозрачный, то все очень хорошо. Ну, вычислят два или три потока одно значение. Разве от этого что-то изменится?! Чистота как никак

А если серьезно, то даже на Java и C# можно с пользой использовать GC. Вспоминаю свой код на Си++ и Asio. Сколько там всяких заморочек, особенно со std::shared_ptr, тогда так даже на эти двух перечисленных выше не самых сложных и далеко не самых мощных языках мейнстрима было бы все много проще.
Re[4]: Тенденции языков
От: AlexRK  
Дата: 16.05.15 18:11
Оценка: 4 (1) -3 :)
Здравствуйте, hi_octane, Вы писали:

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

_>Ну и в итоге преимуществ перед C++ примерно 0, как следствие повторяем очередную итерацию борьбы с C++. Проверено предыдущими поколениями убивцев C++.

Гарантированная корректность операций с памятью — это "0"? Хм.

Убить С++ мешает не его "крутизна", а то, что в него вложено огромное количество ресурсов. В обозримой перспективе смерть С++ абсолютно исключена и разговоры об убийстве С++, ИМХО, не от большого ума. Что не отменяет того факта, что С++ — это говно мамонта, перегруженное фичами и отягощенное наследственными болезнями.

ARK>>Исключения — очень спорная вещь. Разговоры о "пользе" исключений — однобокий взгляд. Минусов у исключений не меньше, чем плюсов.

ARK>>К счастью, есть люди, которые это понимают, поэтому Rust и Swift именно такие, какие есть.
_>Как-то упустил минусы исключений. Можешь перечислить или кинуть ссылку где прочитать?

Могу. Главный минус: исключения оставляют программу в несогласованном состоянии, с разрушенными инвариантами, и формально проконтролировать этот момент нельзя. Теоретически могло бы помочь STM, но у него свой неустранимый минус — не работает с IO.

А вот почитать:
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx
http://yosefk.com/blog/error-codes-vs-exceptions-critical-code-vs-typical-code.html
Re[4]: Тенденции языков
От: MTD https://github.com/mtrempoltsev
Дата: 16.05.15 19:13
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>Как-то упустил минусы исключений. Можешь перечислить или кинуть ссылку где прочитать?


Это бла-бла-бла про якобы просадку производительности и про завуалированный goto.
Re[5]: Тенденции языков
От: MTD https://github.com/mtrempoltsev
Дата: 16.05.15 19:16
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Могу. Главный минус: исключения оставляют программу в несогласованном состоянии


А необработанный код ошибки в каком состоянии оставляет программу?

ARK>с разрушенными инвариантами, и формально проконтролировать этот момент нельзя.


А что насчет С++ с раскруткой стека и деструкторами?
Re[6]: Тенденции языков
От: AlexRK  
Дата: 16.05.15 19:22
Оценка: +1 :)))
Здравствуйте, MTD, Вы писали:

ARK>>Могу. Главный минус: исключения оставляют программу в несогласованном состоянии

MTD>А необработанный код ошибки в каком состоянии оставляет программу?

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

ARK>>с разрушенными инвариантами, и формально проконтролировать этот момент нельзя.

MTD>А что насчет С++ с раскруткой стека и деструкторами?

Деструкторы это хорошо, не спорю. Но это, как ни крути, своеобразный костыль над исключениями.
Довольно старая статья Александреску на эту тему: http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758

Solution 3: The Real Approach

"Who said memory's going to exhaust? There's half a gig in this box!"

"Even if memory does exhaust, the paging system will slow the program down to a crawl way before the program crashes."

"The database folks said AddFriend cannot possibly fail. They're using XYZ and TZN!"

"It's not worth the trouble. We'll think of it at a later review."

Re[7]: Тенденции языков
От: MTD https://github.com/mtrempoltsev
Дата: 16.05.15 19:29
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>В прежнем, очевидно. Правда дальше все равно развалится.


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

ARK>Но в современных ЯП необработанный код пропустить нельзя, компилятор запрещает.


Чмсто для общего развития — в каких? И каким образом? Ну не проверяю я что функия вернула или в "современных" языках по определению функция может вернуть только код ошибки?

ARK>Деструкторы это хорошо, не спорю. Но это, как ни крути, своеобразный костыль над исключениями.


Все костыль, нет ничего идеального, по мне так исключения гораздо лучший костыл, чем коды ошибок.
Re[8]: Тенденции языков
От: AlexRK  
Дата: 16.05.15 19:43
Оценка:
Здравствуйте, MTD, Вы писали:

ARK>>Но в современных ЯП необработанный код пропустить нельзя, компилятор запрещает.

MTD>Чмсто для общего развития — в каких? И каким образом? Ну не проверяю я что функия вернула или в "современных" языках по определению функция может вернуть только код ошибки?

Rust точно, Swift не помню, но тоже, скорее всего.
Вот тут: https://doc.rust-lang.org/std/result/
Компилятор требует обработать возвращаемое значение.

ARK>>Деструкторы это хорошо, не спорю. Но это, как ни крути, своеобразный костыль над исключениями.

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

Я тут выше статью приводил: http://yosefk.com/blog/error-codes-vs-exceptions-critical-code-vs-typical-code.html
С ней в целом согласен — что исключения хороши для "простого" кода, а коды — для требовательного к качеству и скорости.
Re[9]: Тенденции языков
От: MTD https://github.com/mtrempoltsev
Дата: 16.05.15 19:58
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

ARK>Rust точно


Там просто есть атрибут #[must_use], что таки оставляет простор для ошибок.

ARK>Я тут выше статью приводил: http://yosefk.com/blog/error-codes-vs-exceptions-critical-code-vs-typical-code.html


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

ARK>С ней в целом согласен — что исключения хороши для "простого" кода, а коды — для требовательного к качеству и скорости.


А точно не наоборот?
Re[10]: Тенденции языков
От: AlexRK  
Дата: 16.05.15 20:19
Оценка: +2
Здравствуйте, MTD, Вы писали:

MTD>Там просто есть атрибут #[must_use], что таки оставляет простор для ошибок.


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

ARK>>С ней в целом согласен — что исключения хороши для "простого" кода, а коды — для требовательного к качеству и скорости.

MTD>А точно не наоборот?

Думаю, что нет. Софт на марсоходе писан на языке без исключений. Игры на современных приставках пишутся без исключений. Статические анализаторы, применяющиеся в авиакосмической промышленности (например: http://www.astree.ens.fr/, http://www.spark-2014.org/), не предусматривают использования исключений. Ядра всех этих линупсов и прочих ОС — тоже без исключений.
Re[2]: Тенденции языков
От: btn1  
Дата: 16.05.15 21:39
Оценка: +1 -3
Здравствуйте, hi_octane, Вы писали:

_>Из маргинальных языков радует редко упоминаемый тут Nim


Синтаксис на отступах — такое школоло сразу в топку.
Re[3]: Тенденции языков
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 17.05.15 04:12
Оценка:
Здравствуйте, btn1, Вы писали:

B>Синтаксис на отступах — такое школоло сразу в топку.


Вот мне питоноподобный синтаксис на отступах тоже очень не нравится. Но с другой стороны, в хаскеле и идрисе тоже на отступах, но там ок, нет такого отторжения совсем.
Re[10]: Тенденции языков
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 17.05.15 04:16
Оценка:
Здравствуйте, MTD, Вы писали:

ARK>>С ней в целом согласен — что исключения хороши для "простого" кода, а коды — для требовательного к качеству и скорости.


MTD>А точно не наоборот?


Про качество не скажу, а вот про скорость недавно один из разработчиков интеловского компилятора рассказывал, что если в функции есть какая-то работа с исключениями, то многие оптимизации для нее сразу выключаются.
Re[11]: Тенденции языков
От: MTD https://github.com/mtrempoltsev
Дата: 17.05.15 06:22
Оценка: +1 -2
Здравствуйте, AlexRK, Вы писали:

ARK>Думаю, что нет. Софт на марсоходе писан на языке без исключений.


На такой софт тратится столько денег, что обычное прикладное ПО никто бы не купил, если бы на его разработку столько же тратили.

ARK>Игры на современных приставках пишутся без исключений. Статические анализаторы, применяющиеся в авиакосмической промышленности (например: http://www.astree.ens.fr/, http://www.spark-2014.org/), не предусматривают использования исключений. Ядра всех этих линупсов и прочих ОС — тоже без исключений.


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