AlexTCH
313 subscribers
76 photos
4 videos
2 files
906 links
Что-то про программирование, что-то про Computer Science и Data Science, и немного кофе. Ну и всякая чушь вместо Твиттера. :)
Download Telegram
Придумал 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. 😊
https://cforall.uwaterloo.ca/
C∀ (C-for-all) is an open-source project extending ISO C with modern safety and productivity features, while still ensuring backwards compatibility with C and its programmers. C∀ is designed to have an orthogonal feature-set based closely on the C programming paradigm (non-object-oriented) and these features can be added incrementally to an existing C code-base allowing programmers to learn C∀ on an as-needed basis. In many ways, C∀ is to C as Scala is to Java, providing a vehicle for new typing and control-flow capabilities on top of a highly popular programming language allowing immediate dissemination.

Since 2017 it seems. And Huawei again.
Though their "logo"! 😁

There's a link to Github repo but they might drop a new massive release in a couple of weeks.
👎2🤔1
Предлагаю переименовать YouTube в "Сайт, нарушающий законодательство РФ". Чтобы никто не сомневался и всем сразу было понятно.
https://www.youtube.com/watch?v=G0NUOst-53U

Testing generators and shrinkers (Arbitrary instances) themselves is a very practical idea (advice №1).
Using commuting diagrams to inspire properties is a very deep idea (advice №3).
Model-based testing as another instance of a commuting diagram is a very neat idea (advice №5).

#propertybased #testing #talk #haskell
Покуда жив был Чехов, всякая шваль не смела называться контент криэйтером!
https://algebradriven.design/
"Algebra-Driven Design", a recent book by Sandy Maguire in a tradition of Richard Bird's "Pearls of Functional Algorithm Design" and to some extent "How to Design Programs".

Though the author explicitly references "prior art" going back to 1970s including pretty much mandatory quotes from Dijkstra, Landin's classic "The Next 700 Programming Language" and Backus' Turing Award lecture. 😊

The style is bold and fun to read. Just for a teaser.

> Our discussion on abstraction is merely foreplay to set the stage for this book’s main contribution: that code is the wrong abstraction for doing programming.

> If you take away nothing else from this book, it should be that code is a uniquely terrible tool for thought.

> A core theme of Algebra-Driven Design is the insistence on working at the proper level of abstraction and on creating new levels if the available ones aren’t sufficient. This book isn’t here to harp on about how source code shouldn’t be represented — or, for that matter, experienced — in bytes. No, the argument presented is that__ programs themselves are the wrong level of abstraction__, and what we can do about that.

You can taste a sample yourself: http://samples.leanpub.com/algebra-driven-design-sample.pdf 😊

And if you think Sandy teaches worthless crap that can never work sure think you can take a bunch of quotes out of context and mock him however you please, but I challenge you to buy the book, study it through and through, and write your own piece point out exactly where Sandy gets it all wrong. 😁
🤔3👍1
Not an asshole, but "culturally challenged person"!
😁4