AlexTCH
309 subscribers
76 photos
4 videos
2 files
904 links
Что-то про программирование, что-то про Computer Science и Data Science, и немного кофе. Ну и всякая чушь вместо Твиттера. :)
Download Telegram
A reaction to the paper linked in the previous post: https://blog.cr.yp.to/20201206-msword.html

I'd say the reaction mostly points out obvious glaring problems with the original study, but maybe they are not that obvious in the end as long as the paper was peer-reviewed and published?

I'd recommend skipping the first part of the post, everything before the explicit reference to the paper as it discusses simple stuff about list numbering and editing and reference management which MS Word and Word-like systems can do for many years.

Also the post references several other reactions to the study but I didn't follow the links.
Где-то в прошлом году я постил ссылку на https://dcic-world.org/ и отчаянно рекомендовал эту книгу как для самостоятельного изучения, так и в качестве основы для преподавания. И всё ещё рекомендую!

Напомню, что это основательно переосмысленное и переработанное продолжение http://htdp.org/ которая была и во многом остаётся революционной в части методического подхода к преподаванию программирования. Обе книги отличаются исключительной систематичностью: материал подаётся в выверенном порядке, без забегания вперёд или использования неизвестных понятий. Более того, изложение заранее учитывает типичные проблемы студентов и либо явно их предупреждает, либо даёт инструменты самопроверки и самопомощи. В том числе, этот подход поддерживается и специально разработанными языками программирования и IDE, используемыми в этих учебниках.

И тем не менее, Data-Centric Introduction ухитряется пойти ещё дальше, решить ещё больше затруднений, возникающих у студентов, показать больше связей информатики (Computer Science) с "реальной жизнью" (и не только программистов, но и бухгалтеров, маркетологов, учёных всех мастей и т.д.), объяснить ещё больше алгоритмов и дать больше систематических способов построения собственных и ещё больше облегчить переход со специальных языков на общеупотребительные (Python главным образом).

А теперь к инфоповоду для моих повторных излияний. Обе книги в ближайшее время выходят на русском языке в издательстве "ДМК Пресс" и уже доступны для заказа:
https://dmkpress.com/catalog/computer/programming/978-5-93700-137-5/

https://dmkpress.com/catalog/computer/programming/978-5-93700-926-3/
👍3🔥1
AlexTCH
https://www.hytradboi.com/ Super cool online one-day conference around Databases topics organized by pretty well-known Jamie Brandon. Look at the speakers, there are familiar names too.
Remember this conference with unpronounceable acronym? Turns put they've released all the recordings quite some time ago. Just click on a talk's title in the schedule.
https://www3.nd.edu/~dthain/compilerbook/
"Introduction to Compilers and Language Design" by Douglas Thain

A free introductory book (PDF is available for direct download) on writing compilers. It spends 3 out of 12 chapters on scanning and parsing which is kinda questionable but at least touches all major topics. As an in introduction should be pretty decent.
Я считаю, нужно ещё законодательно закрепить чтобы имена Семи Вечных тоже обязательно писались с заглавной буквы: Судьба, Смерть, Сон, Страсть, Страдание, Сумасшествие, Сокрушение.
😁3💩1
https://deathbykeystroke.com/articles/20220517-business-processes-as-types-lets-explore.html

Go-программисты открывают для себя монаду Either и "Railway-oriented programming".
👍1😁1
Придумал Emacs-rehab. С VS Code на завтрак, IntelliJ IDEA на обед и вечерними профилактическими клизмами Vim.
"Тятя-тятя, наши сети" принесли феерическое: http://rsdn.org//forum/philosophy/8285289 — "Почему программисты прошлого были умнее".

Давайте сразу начну с punchline: "почему раньше X были умнее" — это "уловка-22", если раньше были умные, а теперь тупые, то автор автоматически получается тоже из нас, из тупых. А дальше, если он пишет что-то тупое, то это, конечно, только подтверждает его тезис. И автор, конечно же, подтверждает.

> Как известно более старые книги по математике времён СССР лучше более поздних того же СССР и России.

Как говорится, citation needed: кому известно, на основе каких исследований, по каким критериям?

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

После чего автор кодом на языке Lua иллюстрирует тезисы относительно превосходства структурного программирования над процедурным. В рамках обсуждения программирования 1940-1960х годов. 👏

> Как показала практика не все парадигмы одинаково полезны. Некоторые приводят к размазыванию алгоритмов по огромному количеству файлов.

Ссылок на исследования снова нет. Видимо, автор это берёт из собственной практики.

> Вроде бы код открыт и даже свободен, читай и используй, но нет, не получается.

Может, потому что в 60х-80х было крайне мало открытого кода? Не было не то что Github, но даже Sourceforge? Да нет, просто читать не получается.

Пропустим несколько параграфов в том же стиле и перейдём к кульминации:

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

Во-первых, оказывается, быть пользователем в 2022 — это плохо. Позорно. Можно даже не понимать, что у тебя в образовании имеются некие проблемы.

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

> да и не для всех это действительно проблемы

Аминь.
https://distill.pub/2017/research-debt/
A sorta position paper from (early years) of Distill.
It called for one-sentence summaries so here you go:
Humanity suffers greatly from poor presentation of scientific ideas and underwhelming educational materials, thus Distill is aimed to improve this situation by incentivising scientist to produce carefully prepared exposition articles through a publishing venue, tools and monetary support.
Still I encourage everybody to at least skim through the paper for a great list of very interesting links if nothing else.

What I personally find questionable in the paper itself are the mountaineering metaphor that suggests a scholar needs to learn all of the science or at least of an area (climb all the peaks), and overly simplistic "cost model" of "interpretive labour". I think these simplifications don't do justice to neither the problem nor the scientists wrestling with it. But the awareness of research debt is necessary of course.
🔥2
https://hopin.com/events/unison-forall/registration
Join us for a full day of talks and discussion about Unison, a friendly programming language from the future. This conference is 100% online and absolutely free.

June 24 2022, 9 AM - 5 PM EDT (13:00 - 21:00 UTC)

It's astonishing Unison language is still alive, they've made a startup out if it and now having a conference. Apart from sheer fun of it some talks look pretty interesting and useful (regardless Unison).
🔥1
https://github.com/yatima-inc/yatima-lang-alpha

Another "pure functional programming language implemented in Rust with... content addressing, first-class types, linear, affine and erased types, type-safe dependent metaprogramming". Although this one shows some promise. And some interesting people among contributors.
https://makeabetter.computer/

Microgrants ($100–$500) for microprojects to make computing and computers marginally better.
https://haskle.net/

Guess a function from Haskell Prelude by obscured type signature (Wordle-like though I never played Wordle).
https://www.nature.com/articles/d41586-022-01516-2

Who are Research Software Engineers and what they do.
100% тактический, 100% из "Сплава".
https://www.hillelwayne.com/post/this-is-how-science-happens/

A big and important story about Empirical Software Engineering. Pretty much a must-read for both Software Engineers and Software Researchers empirical or not.

I mean the post itself is really good: a pleasure to read and underlines many deep issues. But the most important thing is the story behind it, a 5 years (sic!) inquiry into a particular research question.

Apart from conference presentations and Twitter and Facebook threads the story is captured in 4 papers (5 if you count the first report). All of them are must-read for hands-on exposition to software repository mining, data preparation, analysis and validation. Actually all of the authors did excellent and very thorough job, the papers are fascinating and teach a lot of important subtle concerns. And yet all of them had pretty big oversights.

The case in point is pretty heated and opinionated, and even senior researchers couldn't refrain from some personal attacks. So the most important conclusion we can draw is we should constantly remind ourselves to be humble and polite towards all other human beings.

The next conclusion is "software repository mining is hard and tricky". Despite Big Data promise to settle all the questions with indisputable statistics given enough data, as soon as we have more data than any reasonably sized team can manually validate in any reasonable time we start getting all crazy sorts of absurd correlations due to corrupted data, missing data, misclassification and so on and so forth (as many Data Scientists know first-hand for many-many years).

And even setting data quality issues aside "statistics is hard" still. In the face of enormous number of data points and very small effect sizes, not possibly being able to directly control for confounders and using proxy features, doing multiple hypothesis testing at once... One have to know what their doing, what their methods assume and what exactly they tell through and through to make remotely plausible statistical inferences and conclusions.

Explaining that in a clear and direct way to unsophisticated audience is a whole separate thing...

It's a cliché that Computer Science is a very young field. Then Empirical Software Engineering is a new-born. But I hope for the very bright and fruitful future. 😊