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. 😊
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. 😊
Hillel Wayne
This is How Science Happens
I love science. Not the “space is beautiful” faux-science, but the process of doing science. Hours spent calibrating equipment, cross-checking cites of cites of cites, tedious arguments about p-values and prediction intervals, all the stuff that makes science…
https://cforall.uwaterloo.ca/
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.
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
https://www.youtube.com/watch?v=_bJeKUosqoY
Very neat visual illustrations to Langlands program and various connected matters and problems. Also features very short but illuminating overview of Andrew Wiles' proof of Fermat's Last Theorem.
Very neat visual illustrations to Langlands program and various connected matters and problems. Also features very short but illuminating overview of Andrew Wiles' proof of Fermat's Last Theorem.
YouTube
The Biggest Project in Modern Mathematics
In a 1967 letter to the number theorist André Weil, a 30-year-old mathematician named Robert Langlands outlined striking conjectures that predicted a correspondence between two objects from completely different fields of math. The Langlands program was born.…
Предлагаю переименовать YouTube в "Сайт, нарушающий законодательство РФ". Чтобы никто не сомневался и всем сразу было понятно.
https://www.youtube.com/watch?v=G0NUOst-53U
Testing generators and shrinkers (
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
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
YouTube
John Hughes - Keynote: How to specify it! (...) - Lambda Days 2020
Keynote: How to specify it! A guide to writing properties of pure functions
This video was recorded at Lambda Days 2020 http://www.lambdadays.org/lambdadays2020
Get involved in Lambda Days' next conference http://www.lambdadays.org
Learn more about the…
This video was recorded at Lambda Days 2020 http://www.lambdadays.org/lambdadays2020
Get involved in Lambda Days' next conference http://www.lambdadays.org
Learn more about the…
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. 😁
"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
JFYI: in Julia you can't write
you have to write
Such multiple dispatch much intuitive. 🤦♀️
Set(shit) - Set(othershit)
you have to write
setdiff(Set(shit), Set(othershit))
Such multiple dispatch much intuitive. 🤦♀️
😁3
https://www.youtube.com/watch?v=hJQqjELPcOU
Programming Local-first Software Workshop @ ECOOP 22 Berlin
https://docs.google.com/presentation/d/1xqvntURBEwCR-zsS0PP1DD_hdibU8rNJVCevqQeLb0c/edit#slide=id.p
Programming Local-first Software Workshop @ ECOOP 22 Berlin
https://docs.google.com/presentation/d/1xqvntURBEwCR-zsS0PP1DD_hdibU8rNJVCevqQeLb0c/edit#slide=id.p
YouTube
Programming Local-First Software Workshop @ ECOOP 22 Berlin
A recording of the first instance of the Programming Local-First Software Workshop (PLF) as it took place at ECOOP 2022 in Berlin.
PLF is a scientific workshop which is concerned with programming paradigms for Multi-Device Collaborative/Local-First applications.…
PLF is a scientific workshop which is concerned with programming paradigms for Multi-Device Collaborative/Local-First applications.…
👍1
http://tomasp.net/blog/2022/no-code-substrates/
"No-code, no thought?"
Tomas Petricek thinks it's a bit more complicated than that. He introduces the notion of "programming substrates" to discuss different forms and levels of interacting and modifying a system, accommodating the whole spectrum from "just UI" to "codeful" development.
Then he identifies some challenges for no-code systems stemming from "usual" "scripting" tasks and discusses certain "dimensions" for no-code systems design drawing inspirations from historical examples like HyperCard and SmallTalk — as customary — but also examples of early programming languages themselves.
And a host of very curious links as a bonus. 😊
"No-code, no thought?"
Tomas Petricek thinks it's a bit more complicated than that. He introduces the notion of "programming substrates" to discuss different forms and levels of interacting and modifying a system, accommodating the whole spectrum from "just UI" to "codeful" development.
Then he identifies some challenges for no-code systems stemming from "usual" "scripting" tasks and discusses certain "dimensions" for no-code systems design drawing inspirations from historical examples like HyperCard and SmallTalk — as customary — but also examples of early programming languages themselves.
And a host of very curious links as a bonus. 😊
tomasp.net
No-code, no thought? Substrates for simple programming for all
Is it really possible to eliminate programming load? What would real
progress on making programming easier for all mean? In this article, I take a critical look
at no-code programming platforms using the technical dimensions framework and the idea
of a
progress on making programming easier for all mean? In this article, I take a critical look
at no-code programming platforms using the technical dimensions framework and the idea
of a
https://www.meetup.com/category-theory/events/286589723/
Monthly (online) seminars on Category Theory and Categorical Data. Sounds like fun. 😏
Monthly (online) seminars on Category Theory and Categorical Data. Sounds like fun. 😏
Meetup
Login to Meetup | Meetup
Find groups that host online or in person events and meet people in your local community who share your interests.
Что меня втупляет в Julia, так это необходимость руками
collect'ить итераторы. Их нельзя просто взять и передать туда, где ожидается массив. А это значит, что их нельзя передать примерно никуда. 🤦♀️Forwarded from Экспресс 42
Ваши данные есть у киберпреступников?
Напоминаем сайт для проверки: https://haveibeenpwned.com/
Укажите свой номер телефона или адрес почты, и оцените результат.
Если данные есть в базе, то вы узнаете:
🔹откуда, когда была утечка
🔹какие данные скомпрометированы (адреса, пароли, геолокации).
Что делать, если нашли себя в базе?
1. Сменить пароли: на сайте, откуда произошла утечка, и от своей почты.
2. Убедиться, что подключили двухфакторную аутентификацию.
Напоминаем сайт для проверки: https://haveibeenpwned.com/
Укажите свой номер телефона или адрес почты, и оцените результат.
Если данные есть в базе, то вы узнаете:
🔹откуда, когда была утечка
🔹какие данные скомпрометированы (адреса, пароли, геолокации).
Что делать, если нашли себя в базе?
1. Сменить пароли: на сайте, откуда произошла утечка, и от своей почты.
2. Убедиться, что подключили двухфакторную аутентификацию.
Have I Been Pwned
Have I Been Pwned: Check if your email address has been exposed in a data breach
Have I Been Pwned allows you to check whether your email address has been exposed in a data breach.
Оказывается, Julia умеет дампить скомпилированный код в виде бинарника: https://julialang.github.io/PackageCompiler.jl/dev/
Основное предназначение — дампить image для рабочей сессии чтобы после закрытия/открытия не компилировать всё с нуля. Было бы неплохо, если бы они и загруженные в память массивы дампили — вот это было бы ускорение работы. 😏
Как бы то ни было, поверх базовой функциональности есть ещё два применения: PackageCompiler может добавить к дампу нужные куски Julia, и получить либо динамическую библиотеку (для этого нужно определить C-callable функции), либо вообще standalone application.
Можно будет поиграться при случае. 😏
Основное предназначение — дампить image для рабочей сессии чтобы после закрытия/открытия не компилировать всё с нуля. Было бы неплохо, если бы они и загруженные в память массивы дампили — вот это было бы ускорение работы. 😏
Как бы то ни было, поверх базовой функциональности есть ещё два применения: PackageCompiler может добавить к дампу нужные куски Julia, и получить либо динамическую библиотеку (для этого нужно определить C-callable функции), либо вообще standalone application.
Можно будет поиграться при случае. 😏
https://www.youtube.com/watch?v=33YSWaR3kAQ
Another crazy Erdös' conjecture recently proved. Though not yet peer-reviewed. 😊
Another crazy Erdös' conjecture recently proved. Though not yet peer-reviewed. 😊
YouTube
Primes and Primitive Sets (an Erdős Conjecture is cracked) - Numberphile
Extra footage at https://youtu.be/-r2agPNx0gA - Featuring Jared Duker Lichtman. More links & stuff in full description below ↓↓↓
A proof of the Erdős primitive set conjecture: https://arxiv.org/abs/2202.02384
More Prime Number videos: https://bit.ly/PrimePlaylist…
A proof of the Erdős primitive set conjecture: https://arxiv.org/abs/2202.02384
More Prime Number videos: https://bit.ly/PrimePlaylist…
SHAP (SHapley Additive exPlanations) is a game theoretic approach to explain the output of any machine learning model. It connects optimal credit allocation with local explanations using the classic Shapley values from game theory and their related extensions:
https://github.com/slundberg/shap#citations
#machinelearning #explainableai
https://github.com/slundberg/shap#citations
#machinelearning #explainableai
GitHub
GitHub - shap/shap: A game theoretic approach to explain the output of any machine learning model.
A game theoretic approach to explain the output of any machine learning model. - shap/shap