Собственно, один из бывших сотрудников BioWare, работавших над игрой, основал консалтинговую компанию, помогающую бороться с переработками. К сожалению, эта компания, по всей видимости, больше не работает: последний пост в блоге был 3 года назад :(

(напоминаю, у блога есть чат @decltype_chat_ptr_t, где вы можете всё это обсудить)

#prog #haskell #cpp #article
Товарищ мёртвопищ опять вызывает бурления широких народных хабромасс.
Haskell быстрее C++!
Python медленнее PHP!
Одна и та же оптимизация приводит к противоположным результатам в GCC и Clang!

...Реализация на других языках программирования (включая Rust) тоже имеется, так что есть шанс сравнить производительность.
https://habr.com/ru/post/483864/

Когда-то я написал на Rust программу, которая переводила числа в строку прописью (т. е. 123 -> "сто двадцать три"). Написал и решил написать статью о том, как написать подобную программу.

Это было год назад.

Статья всё ещё не готова.

#prog
Идея не нова, но убедительную реализацию сделать сложно

художник @harryh___h экспериментирует с рендером, который выглядит так, будто листья нарисованы от руки. сделано в Unity

#prog #article
Отличная статья, показывающая новый способ тестирования, вскрывающий ошибки...
А заодно хорошо показывающая, насколько мы далеки от написания по-настоящему корректно работающего софта

Вот эта статья вынесла мозги (друзьям и мне). Да, все же ловить сегфолты в Постгресе неприкольно, хотя хорошо, что скоро будет пофикшено.

The core idea of this approach is to automatically generate queries for which we ensure that they fetch a specific, randomly selected row, called the pivot row. If the DBMS fails to fetch the pivot row, the likely cause is a bug in the DBMS. We tested our approach on three widely-used and mature DBMS, namely SQLite, MySQL, and PostgreSQL. In total, we reported 123 bugs in these DBMS, 99 of which have been fixed or verified, demonstrating that the approach is highly effective and general.

https://arxiv.org/abs/2001.04174

#prog #rust #моё
В конце этой заметки я сказал, что планирую расширить код до поддержки impl BorrowMut<VecDeque<T>>. Теперь я понимаю, что это несколько неосмотрительно: код в unsafe полагается на то, что адрес, по которому лежат данные, не меняется. В случае impl BorrowMut такой гарантии уже нет. Для доказательства того, что подобный вариант является unsound, предположим, что MutPair уже реализовал подобный функционал (это изменение я, с вашего позволения, опущу, потому что это чисто механическое изменение кода) и рассмотрим следующий тип:

#[derive(Default)]
struct DeqWrapper<T> {
inner: VecDeque<T>,
}

Для него можно написать следующие реализации Borrow и BorrowMut:

impl<T> Borrow<VecDeque<T>> for DeqWrapper<T> {
fn borrow(&self) -> &VecDeque<T> {
&self.inner
}
}

impl<T> BorrowMut<VecDeque<T>> for DeqWrapper<T> {
fn borrow_mut(&mut self) -> &mut VecDeque<T> {
self.inner.clear();
&mut self.inner
}
}

Да, это отвратительно, да, так никто (я надеюсь) не пишет. Но принципиально нас ничего от этого не ограждает. Хочу отметить, что код выше не содержит unsafe.

Теперь попытаемся использовать данный тип:

let wrapper = DeqWrapper::<i32>::default();
wrapper.inner.push_back(0);
wrapper.inner.push_back(1);
let mut mut_pair = MutPair::new(wrapper).unwrap(); // (1)
let _ = mut_pair.get(); // (2)

Что тут происходит? В (1) мы делаем внутри MutPair::new проверку длины дека. Так как при этом мы используем .borrow(), DeqWrapper даёт ссылку на поле inner, длина которого как раз достаточна, поэтому MutPair возвращает Ok и .unwrap() не паникует. В (2) мы вызываем .borrow_mut(), из дека удаляется данные, MutPair::get использует get_mut, предполагая, что данные есть, и — вуаля! — мы получаем ссылку на неинициализированные данные! Что является UB в Rust.

Хочу особо отметить, что мы получили UB, не написав (как пользователь) unsafe-код и не вызвав unsafe-код напрямую, поэтому наш код unsound.

В чём же проблема? Наш код слепо доверял реализации BorrowMut, чего делать не стоит (unsafe не должен доверять safe).

Каковы решения? Лично я вижу такие:
1) Объявить методы MutPair как unsafe. В принципе, вариант, но это немного лишает смысла эту абстракцию.
2) Оставить код как есть. Вполне рабочий вариант, но не исключено, что для кого-то это окажется недостаточно гибким.
3) Обобщить код относительно sealed-трейта и включить в него только доверенные реализации (для VecDeque<T> и &mut VecDeque<T>). Тоже рабочий вариант (если я таки буду публиковать этот код на crates.io, то, вероятно, так и поступил бы), но это выглядит несколько избыточным решением + страдает эргономика: пользователю теперь надо импортировать нужный трейт, который он(а) не может реализовать.
99) Требовать от типов реализовать трейт, который не только даёт мутабельную ссылку на VecDeque, но и требует доказательство вменяемости такой реализации. К сожалению, этот вариант сильно превосходит текущие возможности Rust и навряд ли когда-то будет осуществлён.

#prog #video
Как писать тесты (если быть более точным — тесты для property-based тестирования).
Лично для меня поразила идея metamorphic testing — простая и вместе с тем плодотворная.
https://youtu.be/zvRAyq5wj38

Напоминаю: DRM — это рак
habr.com/ru/company/dcmiran/blog/484718/
habr.com/ru/post/208390/
habr.com/ru/post/171849/
habr.com/ru/post/364775/

В копилку когнитивных искажений: ru.wikipedia.org/wiki/Парадокс_Абилина
Кажется, нужен новый тег... #psy?

#prog #article

As closing thoughts: this blog post is not intended to start a flame war, nor is it intended to be an assault on dynamically typed programming. There are many patterns in dynamically-typed languages that are genuinely difficult to translate into a statically-typed context, and I think discussions of those patterns can be productive. The purpose of this blog post is to clarify why one particular discussion is not productive, so please: stop making these arguments. There are much more productive conversations to have about typing than this.

https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/