Size: a a a

Compiler Development

2020 April 12

ИЧ

Илья Чистяков in Compiler Development
Alexander Tchitchigin
Некоторые люди думают, что они могут руками заоптимизировать лучше, чем компилятор. Справедливости ради, заставить компилятор заоптимизировать код на 100% надо ещё суметь. 😊
иногда приходится использовать AVX инструкции, конечно для этого не нужно писать всё на ассемблере, и вряд ли веб фреймворк на асме будет лучше сишного, меня же интересуют бест-практикс, понятно что без тестов многие пишут
источник

ИЧ

Илья Чистяков in Compiler Development
кстати моя первая прога на асме была rpc сервером)
источник

E

Eugene in Compiler Development
Илья Чистяков
Объясните пожалуйста. Как я понимаю, Haskell не требует юнит-тестов, потому что сам язык обеспечивает гарантии. Код супер-надёжен. Но юнит-тесты всё таки пишут. Например servant. Почему так получается?
> сам язык обеспечивает гарантии

какие гарантии?
источник

МБ

Михаил Бахтерев in Compiler Development
Илья Чистяков
иногда приходится использовать AVX инструкции, конечно для этого не нужно писать всё на ассемблере, и вряд ли веб фреймворк на асме будет лучше сишного, меня же интересуют бест-практикс, понятно что без тестов многие пишут
Лично по моему опыту (Haskell vs. Си в задачах компиляции или в соревнованиях) тестировать приходится примерно на одном и том же уровне. Нет такого, что прямо вау, для кода на Haskell пришлось написать 10 тестов, а для кода на Си 100. Ошибок в Си возникает больше из-за недописанных switch-ей или из-за некорректных доступов в память, но они вылавливаются примерно тем же объёмом тестов.

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

Совсем от тестирования не избавит ни Idris, ни Coq, потому что математическая модель задачи может не соответствовать реальному поведению программируемой системы. Тестировать, всё-равно, приходится.

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

ИЧ

Илья Чистяков in Compiler Development
Eugene
> сам язык обеспечивает гарантии

какие гарантии?
вон те, на вершине
источник

E

Eugene in Compiler Development
Илья Чистяков
вон те, на вершине
не вижу тут гарантий...

если речь про какую-то там формальную верификацию, то она не даёт гарантий
источник

ИЧ

Илья Чистяков in Compiler Development
Михаил Бахтерев
Лично по моему опыту (Haskell vs. Си в задачах компиляции или в соревнованиях) тестировать приходится примерно на одном и том же уровне. Нет такого, что прямо вау, для кода на Haskell пришлось написать 10 тестов, а для кода на Си 100. Ошибок в Си возникает больше из-за недописанных switch-ей или из-за некорректных доступов в память, но они вылавливаются примерно тем же объёмом тестов.

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

Совсем от тестирования не избавит ни Idris, ни Coq, потому что математическая модель задачи может не соответствовать реальному поведению программируемой системы. Тестировать, всё-равно, приходится.

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

МБ

Михаил Бахтерев in Compiler Development
Илья Чистяков
вон те, на вершине
В этом кубе все языки обеспечивают гарантии того, что при редукции (исполнении программы) типы сохраняются. Проблема не в гарантиях, а в выразительности системы типов. То есть, насколько сложные условия можно закодировать
источник

p

polunin.ai in Compiler Development
Eugene
не вижу тут гарантий...

если речь про какую-то там формальную верификацию, то она не даёт гарантий
Она даёт гарантии что описание будет соответствовать реализации. А вот тесты не дают никаких гарантий, да (кроме того, что на определенных входных данных мы получим определенные выходные значения)
источник

ИЧ

Илья Чистяков in Compiler Development
Михаил Бахтерев
В этом кубе все языки обеспечивают гарантии того, что при редукции (исполнении программы) типы сохраняются. Проблема не в гарантиях, а в выразительности системы типов. То есть, насколько сложные условия можно закодировать
но авто-доказательства, это же совсем другой уровень, разве нет?
источник

E

Eugene in Compiler Development
polunin.ai
Она даёт гарантии что описание будет соответствовать реализации. А вот тесты не дают никаких гарантий, да (кроме того, что на определенных входных данных мы получим определенные выходные значения)
но никто не может дать гарантий, что описание соответствует задаче
источник

p

polunin.ai in Compiler Development
Eugene
но никто не может дать гарантий, что описание соответствует задаче
Это уже зависит от того, умеешь ты читать свое ТЗ или нет
источник

E

Eugene in Compiler Development
polunin.ai
Это уже зависит от того, умеешь ты читать свое ТЗ или нет
нет, не зависит, впрочем, тут это уже скорее оффтоп
источник

ИЧ

Илья Чистяков in Compiler Development
polunin.ai
Это уже зависит от того, умеешь ты читать свое ТЗ или нет
на самом деле не всегда очевидны нюансы, например работа со временем всегда очень склонна к ошибкам в логике
источник

p

polunin.ai in Compiler Development
Eugene
но никто не может дать гарантий, что описание соответствует задаче
Никто не может дать гарантий что тест написан правильно, и что тесты покрывают все возможные варианты кода.

То есть разница в том, что формальная верификация покрывает все возможные варианты, а тесты только определенные.
источник

МБ

Михаил Бахтерев in Compiler Development
Илья Чистяков
но авто-доказательства, это же совсем другой уровень, разве нет?
Ну. Сложные теоремы ни один инструмент автоматически доказывать не умеет.
источник

E

Eugene in Compiler Development
polunin.ai
Никто не может дать гарантий что тест написан правильно, и что тесты покрывают все возможные варианты кода.

То есть разница в том, что формальная верификация покрывает все возможные варианты, а тесты только определенные.
>формальная верификация покрывает все возможные варианты

Это миф, к сожалению.

"Она даёт гарантии что описание будет соответствовать реализации."

именно, и нет никаких гарантий, что описание правильное.
источник

ИЧ

Илья Чистяков in Compiler Development
polunin.ai
Никто не может дать гарантий что тест написан правильно, и что тесты покрывают все возможные варианты кода.

То есть разница в том, что формальная верификация покрывает все возможные варианты, а тесты только определенные.
тогда тесты тоже надо протестировать)
источник

p

polunin.ai in Compiler Development
Илья Чистяков
тогда тесты тоже надо протестировать)
И тесты тестов протестировать, да
источник

E

Eugene in Compiler Development
Илья Чистяков
тогда тесты тоже надо протестировать)
всё надо тестировать
источник