Записал на слух часть выступления Лесли Лэмпорта (перевод ниже):

"So... Programmer should know about thinking? What everyone should now about thinking? Everyone thinks they think. But when you don't write your thoughts — you're fooling yourself. What a programmer should know about thinking that you should think before you code. Which means you should write before you code. A speck is simply what you write before you coding.

So what code you should specify? [...] Basically any piece of code that someone else might want to use or modify. And that 'somebody else' will likely be you in a month when you forgotten what this piece of code you written does. It could be an entire program or system, a class, a method or just a tricky piece of code inside of a method.

What should you specify about the code? What it does — which means everything anyone needs to know to use it. And perhaps how it does it — if it's complicated, subtle, [you] need to think hard about it to get it right. This is what sometimes called an algorithm, a high-level design.

How should you think about or specify your code? Above the code level — in terms of states and behaviors, or functions for input/output relationships; should do it mathematically as rigorously and formally as is necessary. You should be thinking mathematically even if you're writing mathematics things very informally — perhaps with pseudo-code or Pascal if you're specifying how something does it.

So how do you learn how to write specs? By writing formal specs — even if you never need to write a complete formal spec in your life, learning to write formal specs will really help you learn to write informal specs you need to write.

You learn to write programs by writing them, running them and correcting your errors. You can learn to write formal specs by writing them, running them with a model checker and correcting your errors."

Мой перевод:

"Таким образом... Что должен знать программист о мыслительных процессах? Что все остальные должны знать о мыслительных процессах? Каждый думает, что он думает. Но если вы не записываете ваши мысли — вы обманываете себя. Что должен знать программист по поводу мыслительных процессах — так это то, что вы должны думать перед тем, как писать код. И это означает, что вы должны писать перед тем, как начинать кодирование.

И для какого же кода следует писать спецификации? В целом, для любого куска кода, котороый кто-то другой может захотеть использовать или модифицировать. И этот 'кто-то другой' скорее будет вами через несколько месяцев, когда вы забудете, что этот кусок кода, который вы написали, делает. Это может быть целая программа или система, один класс, метод или просто хитрый кусок кода внутри метода.

Что нужно писать в спецификации по коду? Что он делает — то есть, всё, что нужно знать кому-либо, чтобы использовать его. И возможно также как код делает то, что он делает — если он сложен, неочевиден, и вы должны напряжённо думать для того, чтобы написать его правильно. Это [описание] часто называется алгоритмом, или высокоуровневымы дизайном.

Как вы должны думать о коде или писать спецификацию? На уровне, который выше уровня вашего кода — в терминах состояний и поведений, или функций для взаимодействия ввода/вывода; вы должны делать это математически так строго и формально, насколько это необходимо. Вы должны думать математически, даже если вы пишите математические вещи очень неформально — например, псевдо-кодом или на Паскале, если вы описываете, как что-то работает.

Так как же вы можете научиться писать спецификации? Через написания формальных спецификаций — даже если вам никогда не потребуется писать полностью формальную спецификацию в вашей жизни, обучение написанию формальных спецификаций реально вам поможет научиться писать неформальные спецификации, которые вам надо сделать.

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

#dev #translations

Очень круто:
https://www.youtube.com/watch?v=tPB7Rvk2yzQ

#music

Пробуем на практике по Android в колледже сделать аналог игры 1991-го года "Dangerous Dave in the Haunted Mansion"

#dev #gamedev #нртк

В аудитории достаточно темно

П: Guys, do you need some more light?
С: No...
П: Little vampires...

Соломоновская А.Л.

#НГУ

The Central Social Institution in Prague, Czechoslovakia, 1937 (Score: 150+ in 1 day)

Link: https://readhacker.news/s/5dFSJ
Comments: https://readhacker.news/c/5dFSJ

Обновили фрезер для гравировки печатных плат. На видео -- первые испытания.

Сверление платы.

"...we must be very careful when we give advice to younger people — sometimes they follow it."

— Edsger Wybe Dijkstra

Перевод:
"Мы должны быть очень осторожными, когда даём советы молодому поколению — иногда они могут им следовать."

Цитата из https://www.youtube.com/watch?v=6sIlKP2LzbA

Ещё кусок из выступления Эдсгера Дейкстры:

The competent programmers fully aware of the strictly limited size of his own skull; therefore he approaches task in fully humility. And among other things he avoids clever tricks like the plague.

In the case of well-known confusational programming language I have been told from a various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomena occurs that even has a well-established name: it is called "The One-Liners".

It takes one of two different forms: one programmer places a one-line program on a desk of another and either he proudly tells what it does and asks a question "can you code it in less symbols?" (as if this were of any conceptual relevance) or he just asks "guess what it does?"

Перевод:

Компетентные программисты ясно понимают строго ограниченный объём их черепной коробки; поэтому программист решает задачи с максимальной осторожностью. И, кроме прочего, он избегает хитрых трюков, как чумы.

В случае с широко-известным запутанным языком программирования, мне говорили с разных сторон, что как только сообщество программистов получает доступ к терминалу для него, наблюдается специфичный феномен, который даже имеет широко-известное имя: он называется "однострочники".

Данный феномен принимает две различные формы: в одном случае, программист кладёт на стол другого программиста программу-однострочник и с гордостью объясняет, что данная программа делает; затем он задаёт вопрос "можешь ли ты запрограммировать это меньшим количеством символов?" (как будто это имеет какую-то концептуальную ценность.) В другом случае, программист просто спрашивает "Угадай, что он делает?".

#dev #translations

Music theory for nerds / fuzzy notepad
https://eev.ee/blog/2016/09/15/music-theory-for-nerds/