1.83K subscribers
3.3K photos
132 videos
15 files
3.58K links
Блог со звёздочкой.

Много репостов, немножко программирования.

Небольшое прикольное комьюнити: @decltype_chat_ptr_t
Автор: @insert_reference_here
Download Telegram
Только что ко мне в БК подошёл чел и предложил мне тысячу рублей, если я установлю TikTok 😐
#prog #article

В последние годы в употребление вошло словосочетание software engineer. Само это словосочетание подразумевает, что работа разработчиков программного обеспечения сравнима с деятельностью инженеров из более традиционных областей индустрии. Много копий было сломано на тему того, можно ли разработчиков и впрямь называть инженерами. К сожалению, эти умствования были малополезны, поскольку все из них были написаны разработчиками без опыта работы в традиционном инженерном деле. Как следствие, их авторы исходили не из реальных представлений о работе инженеров, а из своих стереотипов, которые имели к практике весьма опосредованное отношение.

Hillel Wayne избрал более надёжный подход: признав, что он не в состоянии самостоятельно рассуждать на эту тему, он провёл на эту тему интервью с полутора десятком людей, которые сейчас работают разработчиками, но были ранее инженерами (в их число с неожиданностью для автора вошёл Nick Coghlan, который сейчас больше известен, как один из разработчиков CPython, но до этого работал инженером системной интеграции в Boeing). Этих людей автор в дальнейшем называет "crossovers". Информацию их интервью с этими людьми автор в итоге суммировал в трёх эссе. Если вы спешите, то вот заключение из последнего из них:

To summarize my ultimate conclusions:

First of all, We software engineers are “really” engineers. All the differences people give between software and “real” engineering don’t accurately reflect what “real” engineering looks like. And the biggest difference, licensure, is a political construct, not a technical one. At the same time, there is a difference between the different ways people make software, and it makes sense to think of software developers and software engineers as distinct concepts. But even then, it’s very easy for a software developer to become a software engineer and vice versa.

Second, we are not special. There are some aspects of software engineering that are unique to software, such as the speed of iteration, loose constraints, and the consistency of our material. But software engineering has far more in common with the other forms of engineering than it has differences. The same ideas that engineers use to advance their craft are equally useful in our own domain.

Finally, there is a lot we can both teach and learn. Engineering processes are more sophisticated than ours in ways that we can extract lessons from. Traditional engineers have a stronger sense of professionalism and responsibility than we tend to. In contrast, our culture is much more open and our communities much stronger than what exists in trad engineering. And our developments in version control have the potential to revolutionize traditional engineering.

Тем не менее, сами эссе, разумеется, раскрывают тему более развёрнуто, так что всячески рекомендую их к прочтению:

Are We Really Engineers?
We Are Not Special
What engineering can teach (and learn from) us
This media is not supported in your browser
VIEW IN TELEGRAM
#rust

Почему-то не выкладывал. Коллега сделал давно
@mersinvald спасибище 🙏
#prog #article

Статья, показывающая, как можно при помощи инструмента спецификации ловить баги в многопоточном коде. Конкретно используется подход model checking.
Forwarded from Backtracking (Дима Веснин)
про игры как модель мира: в амазоновской MMO New World дефляция, которая противоположность инфляции, стала настолько серьёзной проблемой, что основным способом торговли в игре стал бартер

This type of regression becomes a severe disincentive to players: what’s the point of leveling a profession if you can’t make any money from it? What’s the point of farming for items if they’re not worth any money, and you can’t afford to repair them?

https://blog.playerauctions.com/mmorpg/currency-crisis-in-new-world/
#prog #scala
Для меня это стало серьёзным доводом в пользу того, чтобы тайпклассы были в самом языке, а не прикручены сбоку в виде имплиситов
Forwarded from Lil Functor
Длинный блогпост с подробным объяснением тайп констрейнтов в скале. От паттернов использования до собственной реализации.

Как работают эти магические <:<, =:=, и почему недостаточно обычных тайп баундов. Для меня при изучении скалы это долгое время был один из самых непонятных вопросов.

https://blog.bruchez.name/posts/generalized-type-constraints-in-scala/
Я плохой?
Почему у std::function есть конструкторы для "пустого" объекта?
Forwarded from вафля'
антон
#prog

Интервью от 2004 года с Julian Seward, создателем Valgrind. Не смотря на возраст материала, читать интересно.

Некоторые интересные моменты:

* В отличие от приличного количества инструментов из мира UNIX, Valgrind был создан в 21 веке (первая версия вышла в 2002 году)

* "One of the major parts of GHC I worked on was the back-end x86 and SPARC code generators, and the register allocator. From this I learnt a lot about the x86 instruction set and code generation techniques, and the idea of making a memory-checking tool for Linux came back into view."

* Вопреки расхожему мнению, название Valgrind — не сокращение от "value grinder" или чего-то похожего, как можно было бы подумать, а взято из скандинавской мифологии (передаю привет Антону)

* "Valgrind is only useful because C and C++ are such crappy programming languages."

* "Valgrind is loaded with assertion checks and internal sanity checkers which periodically inspect critical data structures. These are permanently enabled. I don't care if 5 percent or even 10 percent of the total run-time is spent in these checks—automated debugging is the way to go. As a result, Valgrind almost never segfaults—instead it emits some kind of a useful error message before dying. That's something I'm rather proud of."
#prog #article #soc

В основе библиотек для PBT (property-based testing) лежит фреймворк для нахождения и минификации набора аргументов, на котором выполняется некоторый предикат. Этот фреймворк можно применять для совсем разных целей, например, для того, чтобы найти набор предпочтений избирателей, на которых разные методики выборов дадут разные показатели (да, это всё ещё блог hypothesis).

И да, альтернативы обычному большинству голосов есть. В этой статье с интерактивными визуализациями от Nicky Case рассказывается о пяти различных альтернативах и о их разных свойствах. Абсолютно лучшей среди них нету, но все они выгодно отличаются от простого большинства отсутствием эффекта спойлера (когда введение в списки голосований непопулярного кандидата, который, тем не менее, оттягивает на себя голоса, позволяет сменить исход выборов между двумя наиболее популярными кандидатами).

(Есть также русскоязычная адаптация (с сохранением и переводом интерактивных элементов), но это именно что адаптация, так что не могу безусловно рекомендовать)
Извините, но чуток #wafflecontext. Надеюсь, вы следите за новостями
Подписчики, дорогие мои, в довольно скором времени будет Rustcon. Мне туда хочется попасть (🧇), но идти просто слушателем не хочется а ещё меня жаба душит отдавать за билет 14 тысяч. Поэтому у меня есть хитрый план: взять один из своих авторских постов в Блог*е и переработать его в доклад. Так что у меня к вам вопрос: какой пост(ы), на ваш взгляд, заслуживает конвертации в доклад для конфы?