# Proposing programming language features

This blog hasn’t had enough attention for quite a while. This is not, however, because I have abandoned it, but rather because the original purpose of this blog, that is dumping essays regarding books I read, is still valid. It’s just that the most recent book has taken an order of magnitude more time than I had expected it to take.

Okay, I’m going to write a bigger and better review on the “Structure and Interpretation of Computer Programs”, but the book altogether took so much time, effort and emotions, that even writing the review is going to take a while.

Meanwhile, one of the by-products of my reading happened to be a proposal of a feature to be included into the Scheme Language, that is needed in order to support all the code examples in the book.

(Yes-yes, you’re not misreading it. The book published in 1996 is _still_ not covered by the existing language standard in full. Otoh, it means that there is a chance of achieving things.)

Now that the proposal has an official number, there is going to be a public discussion among the potential Language System providers, and maybe (if it passes the review), we will have this feature officially recognised.

Watching discussions of experts on what they may actually work themselves is a fascinating experience, and a chance to improve own skills too. In this case the discussion is not expected to be too heated, however, but anyway.

https://srfi.schemers.org/srfi-203/ — this is the link to my recent proposal.

It speaks about quite an interesting approach to generating computer images, that builds on top of the classical features present in most drawing languages, such as PostScript, TikZ, MetaPost or SVG. While the expressive power is largely the same, the degree of abstractness is greater, which leaves gives greater code reusability and flexibility.

Scheme is by not means the only language that has a community feature review process.

• Python has Python Enhancement Proposals (PEP)
• Java has Java Community Process (JCP)
• Scheme has Scheme Requests For Implementation

The image in the header is a digital copy of a work of M. Escher, whose works have inspired the original author of the “Picture Language” Peter Henderson. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.1503

# A Review on The Light That Failed by Ivan Krastev and Stephen Holmes

I have read “A Light That Failed”. This review is not a part of the series of reviews on technological books. Nevertheless, in order for a brain to keep moving, some humanitarian reading is advised.

This book was a part of a book club in discussion in Shanghai. Speaking briefly, it discusses the new (2019) tendency in politics in which the western politicians start using the rhetoric that they have not been using so far; the rhetoric that is not unlike the one used by the authoritarian politicians. Surprisingly, the book is known among readers in China, it has a rating on DouBan. The book is not related (at least, directly) to the eponymous novel by Rudyard Kipling. The book is not related (at least, directly) to the eponymous film of 1939, based on the work by Rudyard Kipling.

# A Review of LiShan Chan’s Philosopher’s Madness

I have read the “Philosopher’s Madness” by LiShan Chan. It is a book about mental illness, British Education, academic careers, their successes and failures, Overseas Chinese, Singapore and Dubai, writing and reading.

This review is not a member of the technological book reviews series.

If you are still interested, welcome under the cut.

# A Review for GNU Autotools by John Calcote (1st. ed.)

/ I saw a book titled ≪Die GNU Autotools≫ and I thought “My feelings exactly”. Turns out the book was in German. – Tim Martin./

I have read the GNU Autotools: A Practitioner’s Guide by John Calcote.

This is a small review of mine. This time the review is really small, mainly because there already is a good review, written by Flameeyes  https://flameeyes.blog/2010/08/20/book-review-autotools-by-john-calcote/, and even though ther review was arranged by the original publisher, No Starch Press , it is technically accurate and psychologically unbiased.

What I do have to add are just a few of my own experiences.

## Russian kids are not taught a proper lesson in computer information exchange.

While this statement is a bit radical, most often there is not a single consice introductory lecture which would teach people how to make descent programs, and saying broader, software pakages out of scattered and disperse algorithms, which people are taught to create in high school and in universities.

Most people learn this by either struggling with Microsoft’s documentation, or (even worse) by copying existing Free Software projects, and tweaking the scripts.

## This is a very bad approach.

I know, this is a very emotional statement. But my experience says the following: the less structured is the field you are studying, the more structure needs to be present withing the courses given.

As an example: C, C++, HTML, are reasonably well-structured topics. No matter how you approach the studying, there is only one definitive standard of those, and you have almost no chance of completing your tasks successfully unless you comply with the rules.

As an opposite example, creative writing is not that structured. Your literature teacher may give you good grades, or bad grades, but that would quite often be affected by his personal properties rather than his experiences with the audience you are targeting. In case of the high school class essays this doesn’t matter so much, because your target audience IS your teacher, but it gives you little expertise on how to write for other people.

Therefore, creative writing teaching should require much more elaborate courses than computer programming, exactly to overcome this uncertainty.

## Making software packages is an ill-defined task.

You cannot ever solve it precisely. You can reach some level of closeness to the original goal, but as life evolves, your projects have no choice but to adapt to the changing world. Therefore creating software packages is a badly structured task

## This makes it necessary to have a structured course. Calcote’s book provides such a course.

Indeed, despite being called “A practitioner’s guide.”, it is more of a good theory treatise than a cookbook. And this is good, not bad. Nowadays canned recipies are in abundace, at StackOverflow, for example. But well-narrated explanations are as rare as they have ever been.

## Shall this book be studied at school.

No. Of course not. But it would be a very good idea to let university freshmen read this book as a part of their ‘practice of programming’ introductory classes.

## Statistics

This book is 315 pages long, and required 29 hours 54 minutes of my time, including doing exersises and writing this review. This makes it roughly 10 pages per hour, 6 minutes per page. Those were produced in 11 study sessions, each session 2 to 4 hours, and was accomplished in one week, with more than one session per day on the weekend. The book was printed out on paper, and I was making annotations with a pencil. For practical text writing I was using GNU Emacs 26.2. In the

# Review for SSH Mastery by Michael W Lucas

## Motivation

Why did I decide to read the SSH Mastery?

I have been using SSH for a long time, learning it bit by bit, intuitively. At some point I decided to arrange my knowledge in a more structured shape. So at that time I had a choice, whether to read official SSH documentation, or to look out for some external information, preferably from people who have experience of not just creating the product, but also of using it.

The problem with more prosaic books though is that they often risk just retelling the original documentation verbatim, which is always the safest choice, as all the errors may then be attributed to the software authors. On the other hand, they have a risk of falling into a terribly newbie- oriented, very verbose narration style, which would make them too voluminous for being digested in observable time.

Michael W Lucas’ book skilfully manages to avoid both of those pitfalls. It’s both concise and easily readable. Therefore, it didn’t take me too long time to print it out and dive into.

## Why a book on SSH is even needed?

Indeed, why? What SSH even is? SSH stands for Secure SHell, but it actually has nothing to do with shells or cores. A ‘shell’ is just a name, traditionally used in computing to denote a way to ask a computer to perform exact tasks. That is, 90% of exact tasks are asking a computer to compute something. You know, that mode of your computer, when this huge 1000\$ machine actually works as something it was designed to be 70 years ago: a huge calculator. (By inexact tasks I usually denote tasks which require automated, but not exactly computational tasks, such as calling your friends by a voice chat. )

When you use your calculator, you don’t really need any specific introduction into typing numbers, do you? Well, as I said, a personal computer is a very huge, and a very advanced calculator, so it needs a special advanced program to ask you for your formulae.

The word Secure here implies that using SSH, you can actually ask other computers to be the calculators you ask to compute something for you, and those only need to have the SSH on them, and be connected to a computer network.

So the main task of SSH is establishing connections to other calculators.

Is it so hard? Why would anyone have an extensive manual for a program which performs such a simple task?

There are many answers, but the main one is: not being obvious. The hardest thing to get used to when working with computers is that they are actually one of the least obvious things you find in this world, even less obvious than people.

It doesn’t mean that they are hard. Quite on the opposite, since computers are very dumb, and quite fast, if a good manual is available, few things are actually easier than computers.

But computers are painfully unobvious. Which image among the ones you see on your screen is a real one, and which one is a compressed one? No way to tell. Is the password you are typing on a website stored somewhere or is it not? Are you being attacked by hackers right at this moment, when you are reading this?

The answer to the last question is ‘yes’, even if you are not even remotely aware of the existence of those hackers. And they are also not even remotely aware about your existence, but they don’t even need to. They have robots do all the dirty work for them.

And this is also the place where official manuals fail to increase the obviousness of what is going on, as they are bound to only describing what a program should do, but not what the program should NOT do.

## What is the book about?

SSH is usually used for connecting to a remote computer and giving it some orders using the command line.

One of the reasons for reading the book is learning that SSH can to much more than that. As I already said, it is very good at making any soft of connections between two machines.

A typical example: an SSH can work as a universal (so-called SOCKS5) proxy server between you browser and some computer in a country with a less outrageous censorship law. (Yes, to go around those nasty screens telling you that the government decided to block your access to some website.)

Or, SSH is able to forward just one connection from your computer to another computer. This may be very useful if your company is restricting websites which you are able to visit.

Yes, although this post is NOT about circumventing censorship, for non system administration people it’s not obvious (another picture on “not obvious”) that going around barriers is the very nature of computers.

Or, SSH is able to forward everything leaving your computer through a computer far away. Can be very useful if you company’s system administrator is collecting your bank card numbers for his own pleasure.

SSH can simplify a lot of cryptography for you, and the book is very practical about how to make your life as painless as possible while working with cryptography, and (if you never tried), cryptography is still a very very meticulous task, where every little bit helps.

## Writing style

The SSH Mastery book is good at simply and in a concise manner explaining the (quite complicated) things. To be honest, I was astonished to see how many practical details Michael W Lucas managed to include in his book, and still keep it under 200 pages.

The book is enriched with practical examples from his own working experience, and he, besides being a writer, is one of the world’s best experts on secure operating systems. (He also wrote the Absolute BSD book.)

The book is also written in a swift, light, vocabulary-rich language. (Which is less surprising than it may seem, as Michael W Lucas is also writing fiction books(!).)

One of the best properties of the book is that it gives you the right tools to reach that sweet feeling of almightiness, which is one of the main reasons why people are choosing computers as a career. And this book makes this feeling not limited to just computing (or systems administration) professionals.

## The book collection

Michael W Lucas is writing a series of books actually, under the shared name of ‘IT Mastery’. In this series he elaborates on those tools that systems administrators are learning by trial and error, and users often completely ignore, even though these are those tools which are actually controlling their lives and are used every day. All those have practical examples and accompanying life experience stories.

## Should everyone read this book? Shall it be taught at school?

Well, I am sad to say no. Indeed, most people, most developers, and even most systems administrators can get by without ever consulting any reference material on SSH, and especially a prosaic book.

But saying that, most people can get by without so many things… Maybe it’s sometimes better to think in terms of enriching life, rather than surviving?

## P.S.

Michael W. Lucas has no relation whatsoever to the film director Michael Lucas.

2019-07-04T10:25:13, Shanghai

# How to talk to your child. Общаться с ребёнком. Как? (ENG/РУС)

This blog post contains a short summary and a few independent musings about Yuliya Gippenreyter book’s “How to communicate with your child.”.

## Introduction

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

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

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

В итоге, некоторые принципы, которые она рассказывает, оказались
полезны для выстраивания отношений с коллегами.

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

Гиппенрейтер — МГУшница, 1930 года рождения, заслуженный человек, работает в том же МГУ, делала карьеру в психофизиологии, однако более известна как автор книг по популярной психологии.

I remember, I promised to write a review on GNU Coding Standards, but I’m not made out of steel, and sometimes I do need some less mind-crushing literature for reading.

I selected the book by Gippenreyter, because generally the problem of child-parent communication (although more often a grown-up child) is noticeably painful in Chinese society. Speaking frankly, the it’s ever worse than in Russia. Moreover, I wanted a tool to communicate with my colleagues.

Apart from that, we’re all not that far from being kids ourselves, and I don’t have my own children, therefore I had to apply the skills to communication with adults, and my expectations were exceeded. The methods turned out to be useful in working with colleagues, so useful that I decided to rewrite them in an “adult” way, to better understand myself and to get some feedback.

They say that there is no better way to learn how not to get fooled by advertisement than to read a book on how to do advertisement yourself. I assumed the same logic with respect to talking to those me as to a child.

Especially colleagues, who sometimes do get this feeling that if they start to talk in a patronizing tone, it may help them reach their goals.

Reading this brief summary will not compensate for reading the original book, book, especially because the book has examples and homework (with solutions), but may serve as a cheat sheet.

Gippenreyter is a venerable person, a professor from the Moscow State University, made a career in psychophysiology, but is better known as an author of popular psychology books.

## Acceptance

Надо меньше требовать от коллег. Если у них не получается — значит
это твоя недоработка, а не их ущербность. Надо сказать, что иногда
имеет смысл бросить им вызов словами “да ты просто лентяй”, но чаще
всего даже если дело и в этом, то чаще всего лентяй только потому, что
я не смог его правильно замотивировать. Например, показать, как клёво заниматься программированием. Или как классно можно применять навыки дизассемблирования для написания демок.
Они учились не на Физтехе, и даже не в прогерской системе. Их не
научили учиться, а значит, сейчас надо это делать тебе, потому что не жить же рядом с людьми, которые не умеют этого.

Надо больше заниматься бессодержательными построениями отношений. Люди эти дома, скорее всего, ещё более неустроенные, чем ты, живут далеко от семьи, и страдают от этого больше тебя. Обеспечь им хотя бы ту мелкую социализацию, которой у тебя море, и бесплатно. Расскажи баечку из своего бурного прошлого, расскажи какой-нибудь трюк, сильно упрощающий жизнь, и который давно вошёл у тебя в привычку, и о котором они не задумывались. Ещё очень классно показать им шоткат или какую-нибудь фишку софта, которым вы пользуетесь, просто для того, чтобы качество документов, которые они тебе пришлют, было лучше. Заодно китайский подтянешь.

We need to demand less from our colleagues. If they fail at doing something — it is not their fault, it’s my under-performance. Though sometimes it may make sense to challenge them by saying “you’re just lazy”, but but even if so, he’s usually lazy because it was your obligation to motivate him in one way or another, and you failed. For example by showing how cool it is to do software development. Or how nicely he can use his disassembly skills to write demos.Yeah, remember, your colleagues didn’t study in MIPT/MIT, and they aren’t even professional software developers. They weren’t taught how to learn, therefore now you have to teach them how to do it, because it’s not worth living neat the people who can’t.

It’s also worth to do more and more small-talk. Building weak relationships. At home these people are probably even more unkempt than you are, and suffer from it more than you. Provide them with some tiny socialisation which you have lots of and for free. Tell them a story from your tumultuous past, tell some life-simplifying trick, which your practice every day automatically, and which they are unaware of. It’s really nice to teach people how to use hotkeys/shortcuts, just to make the quality of the email they send to you better. You can also improve your Chinese this way.

## It really pays off to teach your colleagues

Для людей, активно практикующих extreme programming, или хотя бы
code-review, в этом нет ничего странного, но вообще говоря, большинство людей крайне удивляется, когда им предлагают поработать
вместе надо документом. Чаще всего последний раз они это делали в
старшей школе, и с тех пор фидбэк по работе к ним приходил
исключительно в виде “сдал-не сдал”. К сожалению, сдал-не сдал
работает только для человека, который уже настолько увлечён работой, что его уже бессмысленно оценивать. Поэтому лучшее, что можно сделать при оценке работы подчинённого или коллеги — это выдать ему оценку тех сил, что он, по твоему мнению, вложил в работу. (Оценивать работу как таковую бессмысленно в высшей степени.) А лучше всё-таки просто пытаться работать вместе, пока коллега не начнёт делать так, как ты считаешь правильным. Это будет лучше и быстрее, чем тебе кажется, потому что с вероятностью 99% с ним больше никто возиться не будет, так что волей-неволей начнёт тебя копировать.Соответственно, хвали — за старание. Ругай — за неверие в
собственные силы. Остальные оценки бесполезны, хотя можно иногда
попытаться постимулировать премией.

Зачем учить, ещё раз.

• Свалить на него свою работу.
• Научить учиться без учителя и избавиться от обязанности учить в дальнейшем.
• Заработать авторитет (особенно если научить “магическим” трюкам, вроде хоткеев, которые дёшево и сердито делают работу с компами и не только удобнее) и заручиться поддержкой в будущем.

Нужно ли учить коллегу-мудака? Да, нужно, и ещё больше, чем коллегу
хорошего, но желательно какой-нибудь технологии которая нужнее
где-нибудь там, чем здесь. Тогда неровен час, что уволится, да ещё и тебя хорошей памятью вспоминать будет.

В обучении коллег ест одна загвоздка. Часто надоедает смотреть “что
так медленно”, и думаешь “лучше сам сделаю”. Не надо так делать, так ничего не выучит. Но и бросать на него работу вида “бери и делай”, не стоит. Он-то сделает, но результат потом можно будет в лучше случае применить один раз.

For people who practice “Extreme Programming” or at least regular code-review, there is nothing new about that, but generally many people become incredibly surprised when offered to work together at a paper. Most probably, the last time they did it in high school, and since then the only feedback they ever had was in the form of ‘pass-fail’. Unfortunately, pass-fail only has any meaning for people who already like their work enough to not need to be evaluated. Therefore, the only thing you can really do when assessing your colleague’s work is to assess the amount of effort he has put into the job. (Assessing the work itself if meaningless to the utmost degree.) And generally it’s just better to just try to work on the same task together until the colleague starts doing what you see ad being correct. It will be better and cleaner, and even much faster than you may thing, because with high probability no-one but you will ever care about him, so he will be copying you inevitably.Therefore — praise him for his effort. Disapprove — for not believing in himself. The rest of the marks are pointless, although sometimes a bonus may also help.

So why would you teach your colleagures once again:

• Dump your job on him.
• Teach him to learn without a teacher and get rid of the necessity to teach him more.
• Earn credibility. Especially if you can teach him some magical tricks, such as hotkeys, which cheaply make working with computes and such faster, and earn some guarantees of his support in the future.

Do you really need to teach a jerk colleague? Yes, and even more than a good one. And it better be the technology useful somewhere far from your immediate sphere of interest. This increases the chances of him resigning and leaving for a better position.

Teaching colleagues has one caveat. It’s often so annoying to see him working so slowly that you start thinking “I’d better be doing this myself”. Don’t do it. He won’t learn anything like this. But dumping all your job on him and saying “just do it” is also not very productive. He may ever successfully do it, but the result will be disposable at best, and most probably ever unusable.

## What to do if the colleague is not cooperative?

Достаточно часто можно просто забить. Если и так хватает работы, то
невозможно объять необъятное. (Отдельная ссылка на самого себя — не больше 7 трудовых связей может поддерживать человек в один момент времени. Уж всех людей свыше этих семи можно с чистой совестью не пытаться научить.)Что делать, если забить нет возможности?

Во-первых, для начала попытаться понять, не пытаешься ли ты учить его не ради благих целей, а ради распространения собственной любимой доктрины (даже если она какой-нибудь интересный трюк из компьютерной грамотности). Если второе — посиди, подумай, обожди. Может, и не надо.

Если надо.

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

Во-вторых, можно пытаться действовать через ваших
заказчиков, даже если они внутренние. Кто больше ништяков может
сделать, без кого дело не движется — тот ценный человек. Упрямый
коллега почувствет, что заказчики от него уходят — вполне может
всё-таки в итоге освоить дело.

Давить через босса — не рекомендую, за исключением ситуаций, когда
это делается через презентацию “для всей команды”. Если босс даёт не личное поручение “выучить Х”, а командное — это всегда воспринимается легче.

Ну, и иногда можно бросить человеку вызов вида “что же ты Х, а не
можешь У”. На достаточно гордых людях это прокатывает иногда. Но трюк тоже опасный, потому что гордые люди не любят ощущение, что они проиграли.

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

Инструмент 1: внешние инструменты, вроде того, что в межличностной
психологии называется “пассивная агрессия”, в рабочей практике
незаменимы. Напоминалки, чеклисты, маленькие жёлтые стикеры, диаграммы на стенах, катающиеся доски, и просто повторения упрощённых бизнес-процессов вслух — создают чувство общего контекста и разгружают память. Найди все, что существуют в твоей компании, и используй их все. Лучше всего — напиши батч, который по одному средству, удобному тебе, активирует их все.

Инструмент 2: не всегда обязательно приходится вдалбывать человеку навык Х силой. Часто, когда вы делите работу, можно дать ему выбор. То, что человек выбрал сам, будет и осваивать, и делать с большим удовольствием. Ну и, соответственно, иногда можно давать фейковый выбор. Скажем, сделали вы часть работы, выпустили бета-версию продукта. Попробуйте оставшиеся части дать на выбор. С вероятностью 90% человек выберет то, что уже делал. Но уже будет иметь ощущение “это моё”.

Often you can just ignore him.

Especially if there is enough work, and you cannot cover The Unbounded.
(One more shameless reference to myself: a standard person cannot maintain more than 7 relevant personal connections at a moment. You shouldn’t criticise yourself for not being able to teach more of them.)

What can you do if you can’t just ignore them?

First, try to reflect once again if you’re really trying to teach him for the sake of something good, or just because you want to disseminate some favourite doctrine of yours (even if it IS some interesting computer literacy trick). If the second is the case, hang on for a bit, make a deep breath and reflect on it a little bit. Maybe it’s not worth it.

If you decide that it IS worth it.

Firstly you can try to do it through the colleagues who are closer to him than you are. There is a good chance that if his friends learns to do X, then the more resistant colleague may want it too… or he will solve the problem in some more efficient way. (This would be even better, because it’s a chance for you to learn something from them.)

Secondly, you can try to influence him through customers, even if they are internal customers. Who can do more nice things, without whom the business is not running, that person is a worthy, respected guy. If the more resistant colleague starts feeling that the customers are leaving him — there is a good chance he would be able to learn too.

Putting the pressure on him through his boss… I don’t recommend it. Except when it is done on team meetings. If a boss gives a team order ‘learn X’, rather than a personal one — it is always easier.

Sometimes you can challenge your colleague. “You are an X, and still don’t know how to do Y. Shame on you!”. Sometimes it works on haughty people. Although the trick is a bit dangerous, as proud people don’t like the feeling of losing.

Lectures and trainings are useful for establishing a common vocabulary, and for memorising shared diagrams. As an information transfer media at an adult job, the don’t work. Although having a common vocabulary is also valuable, and getting noticed by co-workers is also valuable.

Tool 1: external instruments of a passive-aggressive kind are indispensable in daily work. Reminders, check-lists, tiny little stickers, diagrams on walls, rolling boards, and just repeating established business processes aloud — the together create a feeling of a shared context and relieve your memory. Find all that are used in your company (yes, make a list!) and use them all. Or, if you can, write a batch script that is triggered by your favourite tool and activates them all. Works for software tools, obviously.

Tool 2: not every time you have to force someone to learn X. Often you are deciding how to split the work to be done. The thing that the person has chosen himself he would enjoy learning more. Therefore sometimes your can give him a fake choice. Say, you’ve done a part of work, released a beta version of a product. Now try to make a vote on how the rest of the work should be split. With probability 90% a person will choose something he has already familiar with. But will get this feeling of ownership.

## Working with emotions

Не то чтобы я сам был большой специалист по работе с эмоциями, однако, есть несколько простых правил, упрощающих жизнь.Меня тут могут обвинить в манипулятивности, и трудно будет это
отрицать. Однако, в своё оправдание могу сказать, что тот, кто не
манипулирует сам, будет манипулируем другими. Ну и, что манипуляция, кроме как быть направленной на человека, может быть ещё направленной на себя самого.

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

В эмоциях, самая опасная вещь — это не негативность, а их
нераспознанность.

Не так плохо, когда человек искренне недоволен чем-то, чем когда он
чувствует, что его эмоции никем не поняты и игнорируются.

Взрослого человека в этот момент тянет сказать: “Ага! Значит сейчас мы будем угадывать эмоции коллеги и пытаться их скомпенсировать хитрым трюком!”. В целом, если у тебя скилл манипуляции уровня бог, то это может и прокатить, однако есть приличный шанс обмануть самого себя и получить не только коллег, которые не верят ни единому твоему слову, но и проблемы с психикой. Поэтому предлагается более простой метод. Если тебе кажется, что ты угадал эмоцию коллеги — дождись, пока он произнесёт ещё два предложения (вдруг ты всё понял неправильно), и выскажи свою догадку. Если ты ошибся, коллега тебя поправит. Достаточно трудно угадывать эмоции людей, которые их скрывают. Но ещё труднее пытаться подделывать эмоцию вслух.

Рекомендация подождать два предложения не на пустом месте написана. Не надо превращать рабочую коммуникацию в игру “угадай эмоцию”. Но накал дискуссии таким образом можно снизить.

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

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

It’s not that I am a great expert on working with emotions, but there are a few rules that simplify life.And I may be accused of manipulation here, and will find it hard to refute the accusations. As an excuse, I can meekly say that whose who don’t manipulate get manipulated. And that a manipulation is still just a tool. And that apart from being targeted at someone, it can be targeted at oneself.

In other words, you can use manipulation to mislead someone and confuse, in order to make some personal benefit out of it, but you can also use the same tool to clarify the communication and improve the working process. And I don’t endorse the first application as honest collaborators are always more efficient than misled. So I’d try to broaden the picture a bit.

In emotions, the most dangerous property is being unencrypted.

It’s not as bad if a person is genuinely unhappy with something than when he feels that his emotions are not even spotted, and therefore — ignored.

An experienced adult reader may immediately feel the urge to say “I get what you mean. Now we will be guessing colleagues’ emotions and try to compensate them with our clever tricks”. In general, if you manipulation skill is Godlike, this may actually work, although a much higher chance is that you may actually fool yourself instead, and not just find out that your colleagues don’t believe a single word of yours any more, but that you are in need af a psychological help yourself. That’s why a more trivial method is proposed. When you feel that you have guessed your colleague’s emotion, wait until he pronouncec two more sentences (in case you are wrong), and voice your guess. If you are wrong, he will correct you. It’s a bit hard to guess people’s emotions when they are hiding them. But it’s even harder to hide your emotions aloud.

The recommendation to wait for two more sentences is not here for nothing. It’s not worth turning your work communication into a “Guess Emotion” game. But it IS possible to lower the tone of the debate his way.

The best way it usually to express the emotion using his own words, but be careful not to turn into an Emacs psychotherapist.

And you also should inform your colleagues about your emotions. As we become adult, it becomes increasingly tempting to keep silent and to pretend everything is good in order to maintain peace. But usually that’s a bad practice. You can’t restrain yourself all the time, and when the emotion erupts the consequences may be gross. Therefore a better approach is to often but not too strongly express your own emotions aloud. There are not people with zero empathy. Your colleagues will eventually become more cooperative.

## Standard (and often misused) interaction methods

По-моему, эта глава плохо работает на работе, в отличие от
остальных. Она слишком эмоциональна, коллеги всё-таки уже не
настолько дети, а часть приёмов всё-таки не приходит в голову
применять в работе со взрослыми.

1. Команда (делай Х)Пошёл ты в жопу, начальник.
2. Угроза (если не сделаешь, оштрафуем)Не оштрафуете, я и так за МРОТ (ЖРАТ) работаю.
3. Пропаганда (Мы самые трудолюбивые и талантливые)Не знаю, как вы, а я нет.
4. Советы (Тебе стоит)Если не стоит, то и не стоит.
5. Призывы к логике. (Если делать Х, можно такое)А можно такое не делать!
6. Ругань (ты дурак)Сам ты дурак.
7. Лесть. (Ты молодец)Я молодец, и что?Здесь лучше сказать “ты хорошо сделал Х”, а ещё лучше “я считаю, что ты хорошо сделал Х”.
8. Высмеивание. (Ты инженер, а не умеешь Х)Ты сам много чего не умеешь.
9. Интересоваться личной жизнь человека.Если не хобби или отпуск. Ну, тут комментарии не нужны.
10. Допросы. (Тебе сказали, ты не сделал. Почему?)Не сделал и не сделал, пошёл ты в жопу, начальник.
11. Фейковое сочувствие. (Да, плохо быть тобой.)Лучше бы делал чего.
12. Уход от разговора. (У меня нет времени.)Нету — найди. Запланируй на через неделю.
In my opinion, this chapter (from the original book) is not so efficient at work, in contrast to the other ones. It’s too emotional, and the colleagues are not that childish, and we are generally more considerate to other adults than to children.

1. A command. (Do X)Cos fuck ya, “boss”.
2. A threat. (If you don’t do X, we’ll fine you.)No you won’t, because I’m already working for food.
3. Propaganda (We in this company are the most hard-working and talented.Maybe you are, I am not.
4. Advices (You should)Don’t tell me what to do, and I won’t tell you where to go.
5. Logic. (If you do X, you can Y)You don’t even image how good is my life without Y.
6. Swearing (you’re an idiot)You’re the idiot yourself.
7. Flattery. (You’re great)Yeah, I know. Now what.It’s better to say “you did X well” or even better “I think that you did X well”
8. Making jokes. (You’re an engineer and not know how X)You can’t do a lot of stuff yourself.
9. Being curious about someone’s personal life.Unless it’s a hobby or a holiday. Well, no comments.
10. Interrogation. (You were told, you didn’t do. Why?)I didn’t because I didn’t. Fuck you, “boss”.
12. Avoiding a conversation. (I don’t have time.)If you don’t, find it. Plan for next week.

## Own emotions

Как уже писал, собственные эмоции надо декларировать. Это помогает их потихоньку выпускать, не проявляя совсем уж демонстративно.Как ни странно, люди намного больше любят личные конструкции, чем
безличные, поэтому “эта работа отлично сделана” — хуже, чем “я
считаю, что эта работа отлично сделана”. Рептильный мозг человека
довольно прямолинеен, если слышит “ты хороший”” — думает “я хороший всегда”, слышит “хорошая работа” — думает “хороша для всех вариантов использования”.

С другой стороны, можно и нужно обезличивать конструкции, когда они
склоняют к мысли, что коллега плох. “Работа не очень” — лучше “ты
плохо сделал работу”, потому что есть шанс воспитать в человеке
неверие в собственные силы, а этого делать не надо.

As I said, own emotions must be declared. It helps slowly emitting them bit by bit, without falling into an outright hysteria.”Peculiarly, people much prefer personal constructions to impersonal. That is “this work is well done” is worse than “I think that this work is well done”. Reptilian brain of a homo sapiens is quite straightforward, and if it hears “you’re good” it thinks “I’m always good”, and if it hears “the work is good”, it thinks that the work is done.

On the other hand, making impersonal statements is the right thing to do if a personal one would imply that the colleague is bad by himself, not that just the work is bad. “The work is not really good” is better than “you did the work badly”, because it decreases the chance of instilling a disbelief in himself in that employee.

## Conflicts

Про решение конфликтов написано много материалов, но метод, который
даётся в книге Гиппенрейтер довольно прост.Очевидно, что ни ты, ни коллега не не можете быть правы
всегда. Скажем, сегодня мне рассказали один интересный, хотя и
тривиальный трюк с Фурье-интерполяцией, которого я не знал, хотя он
фольклорен. И рассказал коллега, от которого я этого совсем не ждал.

Даже если тебе кажется, что твой опыт в некотором деле бесконечно
велик, всё равно у тебя всего одна жизнь. А жизнь всё-таки длинна и
разнообразна, волей-неволей узнаешь много разного.

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

В целом, если возникла спорная ситуация, метод разрешения простой:

1. Проанализировать
2. Собрать предложения
3. Выбрать
4. Воплотить
5. Проверить

Более сложные протоколы наверняка существуют, и если компания богатая, то могут даже иногда применяться. Например, иногда можно выбора не делать, реализовать оба решения и выбрать лучшее. (На самом деле, это классный вариант, он очень мягко учит, и тебя, и коллегу. Но дорогой.)

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

А вот когда решение совсем плохое, провалится оно довольно быстро, а научиться на нём всё равно можно многом.

Способ временами трудоёмкий, даже когда применяется один раз, однако в частности способствуте ещё и развитию риторики и навыков убеждения.

There is a lot of literature written on the subject of conflict resolution, but the method give in the book is relatively simple.Obviously neither you nor your colleague are always right. Say, today I was taught a useful, although trivial trick with Fourier interpolation that I had been unaware of, although it is well-known. And it was explained to me by a colleague who I expected the least to do so.

So even if you feel that your experience in some area is infinitely high, you still only live once. And life is long and variable, so inevitably different people learn many different things.

So the most general advice is to always doubt everything, first and foremost yourself. Doubt the suggestions of your colleagues too, but first listen to them carefully, because even if they say stupid things, you will be considered an attentive listener, and it’s a respected trait. What’s more interesting — they can and probably will tell you some trick which may be found useful in other situations.

In general, if a debatable situation arises, the easiest ever solution protocol is the following:

1. Analyse
2. Gather solution candidates
3. Choose
4. Implement
5. Verify

More complicated protocols surely exist and if the company is rich may be even applied somewhere. For example sometimes you can avoid making the choice at once, implement both proposed solutions and choose the better one. (Frankly, this option is the best one, it teaches both you and your colleague, and in a very soft way. But it’s expensive.)

So from this follows that sometimes it’s worth being interested in a choice of a decision much worse than yours. Because if the decision is just a little worse, it’s easier for it to win the selection, but the drawbacks may only be discovered yeas later,when it’s already too late to change.

On the other hand, when the decision is really bad, it will fail quite fast, and should provide a lot of learning opportunity.

Sometimes this method is laborious, even if applied once, but it also helps developing debating skills.

## Regulation

Что такое регламент? Бессмысленная бюрократия, или что-то полезное?Я ненавидел регламенты, пока не поиграл в политику. В обществе людей, каждый из которых хочет мнить себя наполеоном, регламент сразу проявляет свою жизненную необходимость.

Я внедрял на работе Jira. Внедрял с болью и негодованием. Внедрил. Теперь без Джиры народ работы не мыслит. Одно из самых замечательных свойств Джиры — практическая честность. Всё на виду. Недостаток — если ты не админ — трудно делать свои воркфлоу, и не получается делать воркфлоу для единственной задачи. Однако, стоит привыкнуть писать воркфлоу, как в какой-то момент понимаешь, что можно обходиться и без Джиры.

Полезность регламента вообще можно сопоставить полезности
графиков. Есть правило, что тем лучше график, чем больше в нём
отношение энтропии к площади чернил. С регламентом всё почти так
же. Чем больше рекомендаций на единицу чернил — тем полезнее
регламент.

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

Вообще, чем больше доверяешь коллеге, тем проще будет регламент. А в какой-то момент можно позволить ему и самому писать его для
себя. Главное, чтобы он это делал.

What is regulation? Is it just worthless bureaucracy or something worthier?I had hated regulation until I took part in a bit of political activities. In a society of people, each of whom deems himself Napoleon, regulation immediately reveals its usefulness.

I implemented business processes with Jira at work. It was painful and induced hatred. Finished. Now people don’t even imaging working without Jira. One of the best properties of Jira is a practical honesty. Everything is visible. The drawback is that if you are not an admin, it’s harder to create new flows and you can’t make individual flows for different tasks. But when you get used to writing work-flows, you will suddenly have in your head how to get by without Jira.

The usefulness of regulation can be compared to the usefulness of graphs. The greater is the information divided by ink ratio, the better the graph. The regulation is almost similar. The more recommendation per unit of ink, the more useful the regulation.

Moreover, a well written regulation allows casting boss’ spells without having his level of responsibility. Make a well designed paper, get it authorised by your boss, and suddenly you have a spell of an unexpected might.

In general, the more you trust your colleagues, the simpler the regulation will be. At some point you can even find him writing his own regulation. He’d better do.

## Conclusion

Не везде в этом тексте можно заменить “коллега” на “ребёнок”, чтобы
получился содержательный текст. Однако, это получилось сделать в
намного большей степени, чем даже я сначала ожидал.Если бы я хотел сформулировать главную мысль этой книги в одном
абзаце, нескольких предложениях, то написал бы примерно следующее.

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

А вы что думаете на тему проекции методов общения с детьми на коллег?
Хочу услышать ваше мнение.

2019-05-08T01:05:29, Шанхай

Not everywhere in this text you can substitute colleague for a child to get a consistent text. But I managed to do it to a far greater degree than I had expected.If I had to formulate the essence of this book in just a few sentence, I would write roughly the following:

The communication protocol at work must be well defined, easy and clear. Emotions should not be avoided, but rather incorporated in the protocol, as a method of assessment. It’s better to measure than to mitigate. Listen to everyone, but push your agenda. And let the most worthy win, helping him is an honour if you lose.

What do you think about the work-child communication?
I’d like to hear your opinions.

2019-05-26T09:47:55, Shanghai

My telegram: http://t.me/unobvious

# GNU Emacs Manual 26.1

I have read the GNU Emacs manual. Before you turn away and switch to a
less propaganda-oriented topic, let me pledge that I’ll try to stick to only
speaking about the book itself, and its influence on me, rather than the
software it describes. This may sound a bit counter-intuitive, but I am
aiming at the audience slightly broader than purely operating systems
enthusiasts or even professional programmers. And as such, the book as a representation of a way of thinking would be more valuable than the actual
software itself.

# A Mathematical Theory of Systems Engineering: The Elements by A. Wayne Wymore

The review on the book by Albert Wayne Wymore
‘A Mathematical Theory of Systems Engineering — The Elements’

This review must be prefaced with a quotation from the last chapter of the book, which is sort of really indicative of what you should expect from it if start reading.

“(Alan) Turing’s work is very important; there is no question about that. He illuminated many fundamental questions. In a sense, however, it is unfortunate that he chose to write in terms of ‘computability’ especially in view of development, subsequent to Turing’s work, of modern computers. As a theory of ‘computability’, Turing’s work is quite important, as a theory of ‘computations’, it is worthless.

“Wow!”, you would think. “This man has the audacity to defy Turing himself! He must be offering something really outstanding instead!”
Well, not really. What is then that he is offering instead?

To start reviewing a book about systems engineering, one would have to first, at least try to specify what systems engineering is. But even such a simple, supposedly, term would have to be met with caution. Well, obviously, it’s connected with the engineering of systems.

But if you open the definition of a system in the book, you’ll see the following:

A system is a set Z = {S, P, F, M, T, \sigma}, where
S is a set not empty,
P is a set not empty,
F is an admissible (ignore this word at the moment) set of input functions with values in P,
M is a set of functions each defined on S with values in S,
T is a subset of R containing 0,
\sigma is a function defined on FxT with values in M such that \sigma is onto and
(1) the identity mapping \omega \in M and for every f \in F, \sigma(f,0) = \omega;
(2) if f \in F, s, t, and s+t \in T, then \sigma(f -> s, t)\sigma(f,s) = \sigma(f, s+t);
(3) if f and g \in F, s \in T, and f(t) = g(t) for all t \in R(s), then \sigma(f,s) = \sigma(g,s)



Wow. Looks really cryptic, doesn’t it?

Factually, if you open almost any other book on the subject, you’ll most probably see a completely different definition, likely dealing with loosely defined terms, such as ‘components’, ‘interfaces’, ‘actors’ and similar things from project management jargon.

For example, this is the definition of a system from the INCOSE’s Systems Engineer’s Handbook.

“… an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements. (INCOSE)”

“Well”, you may tell me, “perhaps this Dr. Wymore is meaning something completely different?” Are they even speaking about the same field of knowledge?

Let’s check:

‘A. Wayne Wymore founded the first academic department of Systems Engineering in the world at the University of Arizona in 1960. He pioneered Mathematical-based Systems Engineering and later led Model-based Systems Engineering. He was an early and ardent supporter of the fomenting of INCOSE. He has led self-evaluation of Systems Engineering education, and continues to be one of the most prominent theoreticians of the Systems Engineering community. In addition to his teaching, writing, and consulting, he has participated in pro bono projects to bring a Systems Engineering approach to social service organisations.

INCOSE (2003) “INCOSE’s Pioneer Award” text; cited in: Wayne Wymore biography at incose.org, last updated: 19 Nov 2007.’

Wow, that’s impressive. So Dr. Wymore actually founded the whole Systems Engineering way of thinking. How come the definitions are so different?

The answer can be found, interestingly, in the auto-biography of Dr. Wymore, written by himself (http://sysengr.engr.arizona.edu/wymore/WWAutobiography.htm):

“Now (1987) I had a chance to finish the book on which I had been working for 11 years, since the publication of Systems Engineering Methodology for Interdisciplinary Teams in 1976. This was to be the book that I write for myself, for pleasure, with little regard for the existence of a market. It would be mathematically as rigorous as I was able to make it and it was intended to include every aspect of system science that would be necessary for successful systems engineering.  The rigor doubtless would be tedious for the present day systems engineer.  It might take a generation or two, perhaps more, before the profession would see fit to train systems engineers at a sufficiently high level of mathematical sophistication to qualify themselves to take on the design of a really vast and complex system such as the national health care system.”

Please, note the *the rigor doubtless would be tedious for the present day systems engineer*.

Has those two generations passed already? Or perhaps just one? 1987-2017 = 30 yeas.

So, basically, Wymore had seen the power of mathematics in describing all possibly thinkable systems, back then, in 1967. But even today, in 2019, we still don’t have sufficient enough computing systems to implement all the prerequisites for a self-supporting, computable Systems Engineering ecosystem.

Well, I have said ‘Systems Engineering’ so many times, and still hasn’t properly explained what it is.

The problem, it IS a bit hard to explain what it is. The informal definition of ‘assembling systems from pieces’ leaves more questions than answers anything.

Actually, Dr. Wymore actually had the same feeling, so he decided to give the same subject a more fundamental, mathematical base.

So, from a mathematical point of view, systems engineering is sort of a mathematics, and a skill of solving equations in a special functional space, which Wymore calls an ‘admissible input functions’ space. Without getting into too much detail, it is a somehow queer space of functions, which can have quite a lot of discontinuities, and are not obliged to be in any sense smooth, but are required to be sort of scale and shift independent, representing time and space isotropy.

Wymore claims that almost all imaginable systems (hardware or software, or even human organisations) can be represented as formulae on top of the ‘admissible functions’. And he builds a relatively comprehensive theory, describing how to relate various mathematical descriptions of systems requirements (input, output, state) with his definition of what is a system.

Interestingly, the most ‘meaty’ thing, that is how to actually describe a system mathematically, is given very little attention in the book. Because that is, supposedly, heavily dependent on the nature of the system built. But if the system IS already described, Wymore’s theory is ready to give some insight on how to predict the system’s behaviour, and how to use the power of mathematics to partition the system into parts. (Which IS, in some sense, the main thing expected from a systems engineer in practice.)

Remember, this book comes from 1967. There is, however, the second book in the series, written in 1993 (*model-based* systems engineering), which puts more emphasis exactly on those two missing aspects of the theory. On modelling and on simulating. (I haven’t yet read it, but it’s on my plans.)

You would ask me: how does it actually work in practice? Is Wymore’s mathematics actually used somewhere?

The answer is a bit disappointing. I haven’t seen any applications of the theory, and more modern books on systems engineering seem to be full of marketing bullshit, not of consistent mathematics.

Why? Well, so far, the world is still ruled by people more focused on intuitive thinking, rather than mathematical thinking. And I don’t see much of it changing in the foreseeable future. And Wymore’s theory seems to be in the worst possible location for a mathematical theory. It requires the users to be BOTH mathematics-savvy, AND having good intuition in those places where no good mathematical theory exists.

But how is Systems Engineering working nowadays then? Well ,the actual answer is ‘difficultly’. In the situation when you can’t force people to not just know mathematics, but even learn programming, you’re left with an only option of ‘programming people’ by writing documents. And to some extent, the systems engineering of now, is a science of writing instructions for people, and drawing diagrams (rather than writing code), because generally, unprepared people are easier at understanding graphics, not text.

I guess, you’re starting to feel where I’m going to. I am going to SysML.

SysML (and UML) is an attempt to make programming ‘imprecise’. That is, actually, a software program is always a model of behaviour of some system. But too often we cannot formulate the system precisely enough to actually write a robot to satisfy the system specification.

Nevertheless, we often can at least sketch the system’s definition in UML/SysML. (And frankly, it was a very bad idea to make the canonical representation of the language graphical, not text-based, but thanks to PlantUML, the situation is now much-much less cumbersome for people like me, who like precision.) Who knows, maybe at some point we will actually have better tools for the interaction between graphics and logic (code). Maybe the second tome (1993) will give me more insight into how this works. Especially since Wymore seems to be providing a more computer-friendly language called T3SD, a domain-specific textual language for describing systems. Maybe it will serve as a good bridge between the mathematical and the visual parts of systems design.

So, getting back to the Mathematical Theory of Systems Engineering: The Elements.

This book is definitely a must-read for a systems engineer. If you don’t understand the mathematics behind what you are doing, you’re not doing it right in any respect.

Is it well written? Well, in almost every aspect — yes. I feel some influence of the social nature of the systems engineering job — the book has a rich vocabulary, and with an exception of several rather confounding theorems, is clearly and consistently written.

Is this book of immediate practical applicability? I wouldn’t be so sure about this, but maybe the second book will change my mind.

Is this book enough as a first introduction into the subject? Still, no. Systems engineering in practice is much more than just mathematics behind the system specifications. Some practical information on how to do *informal* descriptions of systems is seriusly needed.

And, I guess, for every subject I’m reading about, I should be asking myself a little bit weird question: “should such thing be taught in middle school?”.
And in some sense, I would rather answer “yes” than “no” to such a question.
I still remember studying physics at school, and I do remember than one of the biggest complaints I had about it was that physics was presented to us as just a set of disconnected, scattered facts, each of them having a different structure.
Having then not interconnected was already bad enough, but it was the inconsistency of internal structures than was really driving me crazy. (I still don’t know physics, even though I am working (!) as physicist now.)

And in some sense, the MTOSE book is making a small step towards providing a unified base under various physical models and phenomena, and also can be seen as providing links to the other modellable subjects, such as biological phenomena, for example.

Should you read the book? I don’t know. I guess, we need a simpler book on systems engineering for ordinary people, which would still keep at least a trace of mathematical rigour. But this one… perhaps not, unless you are a working engineer or a mathematician. Then — yes. And of course, if you are a systems engineer, it is must.

# INCOSE Systems Engineering Handbook short review.

(This is an old post that I have forgotten to re-post here. Original date: 30 June 2018)

In two words: unless you work in a company of more than 10000 people, you don’t need it.

In more words:
Some time ago I became increasingly suspicious of books and films without authors. For some reason, ‘collectively’ or ‘in the name of an organization’ written books tend to be not as useful as those which have some author’s name on the front page.

And this book was a relatively nice example. Well, it has ‘some’ authors mentioned in a fineprint piece of technical text on the second page, and by a sheer coincidence the book turned out to be better than completely authorless books tend to be on average.

Nevertheless, the book completely lacks the general picture of the field. The beginning, which is expected to give a broad overview, before plunging into the details in the latter chapters, is in fact full of citations of ‘revered people’s work’, but short of actual definitions or explanations of what’s going on.

The rest of the book is filled with ‘process descriptions’, which are presented in a relatively obscure marketingese, which, if purified, happen to be job descriptions templates. Pretty useful for bosses willing to write instructions for their subjects, but not as useful for people who actually understand what their employees should do. (That is, they rule less than 1000 people.)

The last part even suggests to semi-automate the process of writing instructions to people using the ‘sysml’ diagram notations (which, is not properly supported anywhere, since all CASE development systems were designed with octopi in mind), which is so cumbersome that to be justified unless your company has less than 1000 people.

The book is pockmarked with references to how useful NASA, JPL and various other well-known guys find the suggested model, but let’s be honest, what the reference _actually_ tells is is that if you are smaller than NASA, don’t even think about adopting such a huge bureaucratic model of an organization.

Conclusion: unless you REALLY know what you’re doing, stay away from UML, SysML or huge bureaucratic organizations which care more about insuring you against legal consequences than actually doing something new and technologically breaking through.

The voting is open on the contents of the second (out of eight) beta-version of the Revised^7 Report on Algorithmic Language Scheme (R7RS-large, Tangerine Edition), as well as the ‘straw poll’ on the contents of the third beta-version (Orange Edition).

Scheme, one of the branches of the Lisp family of languages, is a modern algorithmic programming language known for its proclivity to functional programming paradigm, although not limited to it.

The Lisp family is the second oldest (after FORTRAN) family of languages, invented by Jong McCarthy as in instrument of Artificial Intelligence development. One of the active developers of the specially designel Lisp-machines was Richard Stallman, the founder of the Free Software Foundation. As a byproduct, the main instrument in Scheme development is Emacs (Geiser, Scheme-Complete, company-mode). It is expected that at some point Scheme will replace Emacs Lisp as an internal language of Emacs. (At the moment one may have a look at EdWin.)

Scheme is Lisp, aimed at the ease of portability, functional approach and incorporation of the best software languages theory.

Scheme is developed in two processes. Individual language extensions are formulated according to a standartized process called Scheme Request For Implementation (SRFI). On the other hand, when there are enough changes pending, the new versions of the ‘Revised Report’ are published.

The latest finalized report is Revised^7 Report on Algorithmic Language Scheme (small language), whereas the latest experimental report is R7RS-large Red Edition. It is expected that before R7RS-large is finalized, there will be 7 or 8 intermediate beta editions, and currently the second (Tangerine) and the third (Orange) editions are being reviewed.

Interested professionals are expected to study the proposed discussion material and vote in the election, after presenting themselves briefly in the scheme-reports-wg2@googlegroups.com mailing list.

The topics considered for voting are:

• String library
• Maps
• Regular expressions
• Generators/Accumulators
• Integer Division
• Bitwise operations
• Fixpoint numbers
• Floating point numbers
• Bytevectors
• Homogeneous numeric vectors
• Formatting
• Bignums
• Ratios
• Inexact numbers
• Exact numbers

The questions considered for the third beta version:

• Random numbers
• Prime numbers
• Integer sets
• Descriptive statistics
• Ranges
• Bitvectors
• Bytestrings
• Enumerations
• Combinatorics

Below you can see the original voting announcement email.

Apologies to those who receive multiple copies of this posting.

There are two ballots to vote on this time, the Tangerine Edition ballot,
which decides what goes into R7RS-large, and the Orange Edition straw poll,
which helps to decide what will go on the ballot for the future Orange
Edition.  Voting on both is open until the end of January.  Please vote!

Links to the ballots, which are Google Forms, will be sent to
scheme-reports-wg2 ONLY.  However, you can also reach the forms at
at <
(Tangerine) and <
(Orange).  You don't need a Google account.  Let me know if anything goes
wrong.

Here are the detailed instructions for the Tangerine Edition ballot:

This is a ballot to decide which SRFIs are to be included in the Tangerine
(data structures and numerics) Edition of R7RS-large.  This is the second
of about 8 editions, so only certain topics are being voted on now.   If
you are seeing this ballot, you are a member of Working Group 2 provided
you actually vote.  However, if you have not voted on a Scheme ballot or
ratification before, please send an email to
explanation of your interest in Scheme.

Choose "No vote" if you wish to abstain, which means that your vote on this
question will not be counted.  Note that if one person votes for
alternative A, and two people for alternative B, and everyone else
abstains, alternative B wins.  That is because we are going by a majority
of the legal votes cast for each ballot question.  If no alternative
achieves a majority, the question will be reballoted at a later date.

Otherwise, choose "None" if you wish not to include a library of the type
described in R7RS-large, or choose one of the SRFIs or R6RS according to
the choices given.  You can also choose "Other" for a write-in vote.

There are also some yes/no questions on the ballot, for which the answers
are "No vote", "No", and "Yes".

If you want to revote, just vote again using the same name.  Only the last
vote is counted.  The ballot closes at the last moment of Friday, February
1, 2019, in any time zone, which is equivalent to noon February 2 UTC.

All ballots will be made public.  If you object to using Google Forms (you
do not need a Google account), post your ballot in an email to
scheme-re...@groups.google.com.  As an absolute fallback, send an
email to co...@ccil.org and I will post your vote for you.  Ballots posted
to other fora will be used if I see them, but are not formally supported.

And here are the instructions for the Orange Edition straw poll:

Please vote on the proposals you think should be considered for
R7RS-large.  This vote is not binding, but provides guidance to the editor
about which pre-SRFI proposals should be converted into SRFIs and which
should not.  Ones that are already SRFIs or which have simple or existing
implementations are excluded.

There are four options in all cases:  "No vote", "No", "Yes", and
"Volunteer"; the last means that you are volunteering to write the
implementation.

--
John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org
weirdo:    When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.

--0000000000005cc1d3057b80739c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Apologies to those who receive multiple cop=
ies of this posting.There are two ballots to vote=
on this time, the Tangerine Edition ballot, which decides what goes into R=
7RS-large, and the Orange Edition straw poll, which helps to decide what wi=
ll go on the ballot for the future Orange Edition.=C2=A0 Voting on both is =
open until the end of January.=C2=A0 Please vote!=
Links to the ballots, which are Google Forms, will be sent to scheme-report=
s-wg2 ONLY.=C2=A0 However, you can also reach the forms atat <=
0YWDaWKBs-J9CCTA> (Tangerine) and <https://docs.go=
ogle.com/forms/d/1qn1Ut7tR5bzXyWOrxpbLu5O7rJJ5_m2HhAeG8YqfgGI/> (Ora=
nge).=C2=A0 You don't need a Google account.=C2=A0 Let me know if anyth=
ing goes wrong.Here are the detailed instructions=
for the Tangerine Edition ballot:=C2=A0This is a=
ballot to decide which SRFIs are to be included in the Tangerine (data str=
uctures and numerics) Edition of R7RS-large.=C2=A0 This is the second=C2=A0=
of about 8 editions, so only certain topics are being voted on now.=C2=A0 =
=C2=A0If you are seeing this ballot, you are a member of Working Group 2 pr=
ovided you actually vote.=C2=A0 However, if you have not voted on a Scheme =
ballot or ratification before, please send an email to scheme-re...@groups.google.com giving you=
r name and a short explanation of your interest in Scheme.Choose "No vote" if you wish to abstain, which means tha=
t your vote on this question will not be counted.=C2=A0 Note that if one pe=
rson votes for alternative A, and two people for alternative B, and everyon=
e else abstains, alternative B wins.=C2=A0 That is because we are going by =
a majority of the legal votes cast for each ballot question.=C2=A0 If no al=
ternative achieves a majority, the question will be reballoted at a later d=
ate.Otherwise, choose "None" if you wis=
h not to include a library of the type described in R7RS-large, or choose o=
ne of the SRFIs or R6RS according to the choices given.=C2=A0 You can also =
choose "Other" for a write-in vote.Ther=
e are also some yes/no questions on the ballot, for which the answers are &=
quot;No vote", "No", and "Yes".=
If you want to revote, just vote again using the same name.=C2=
=A0 Only the last vote is counted.=C2=A0 The ballot closes at the last mome=
nt of Friday, February 1, 2019, in any time zone, which is equivalent to no=
on February 2 UTC.All ballots will be made public=
.=C2=A0 If you object to using Google Forms (you do not need a Google accou=
nt), post your ballot in an email to scheme-re...@groups.google.com.=C2=A0 As an absolute fallba=
ck, send an email to co...@ccil.org a=
nd I will post your vote for you.=C2=A0 Ballots posted to other fora will b=
e used if I see them, but are not formally supported.<=
div>And here are the instructions for the Orange Edition straw poll:</div><=
div><br></div>Please vote on the proposals you think should be co=
nsidered for R7RS-large.=C2=A0 This vote is not binding, but provides guida=
nce to the editor about which pre-SRFI proposals should be converted into S=
RFIs and which should not.=C2=A0 Ones that are already SRFIs or which have =
simple or existing implementations are excluded.T=
here are four options in all cases:=C2=A0 "No vote", "No&quo=
t;, "Yes", and "Volunteer"; the last means that you are=
volunteering to write the implementation.-=
-=C2=A0John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://vrici.lojban.org/~cowan=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 co...@ccil.orgweirdo:=C2=A0 =C2=A0 When is R7RS coming out?Riastr=
adh: As soon as the top is a beautiful golden brown and if youst=
ick a toothpick in it, the toothpick comes out dry.