I politely disagree. Both pieces of code have a teaching value, but different.
The iterative code is busy and long, but allows to track exactly how the pretty trivial calculation is happening, down to elementary(-ish) operations.
The comprehension-based code is more declarative; it succinctly shows what is happening, in almost plain English, without the minute details cluttering out the purpose of the code.
For anyone who is not a Python beginner, but is an ML beginner, the shorter version is much more approachable, as it puts the subject matter more front-and-center.
(Imagine that every matrix multiplication would be written using explicit loops, instead of one "multiply" operation. Would it clarify linear algebra for you, or the other way around?)
> For anyone who is not a Python beginner, but is an ML beginner, the shorter version is much more approachable, as it puts the subject matter more front-and-center.
It certainly depends on the audience. Interestingly, I had the opposite conclusion about Python beginners in my head before reaching this line!
I think it's more about the learner's prior background. Lately, I've mostly been helping friends who do a lot of scientific computing get started in ML. For that audience, the "nested loops" presentation is typically much easier to grok.
> (Imagine that every matrix multiplication would be written using explicit loops, instead of one "multiply" operation. Would it clarify linear algebra for you, or the other way around?)
Obviously "every" would be terrible. But there's a real question here if we flip "every" to "first". For a work-a-day mathematician who doesn't write code often, certainly not! For a work-a-day programmer who didn't take or doesn't remember linear algebra, the loopy version is probably worth showing once before moving on.
On a related note: I sometimes find folds easier to understand than loops. Other times find loops easier to understand than folds. I'm not particularly sure why. Probably having both versions stashed away and either exercising judgement based on the learner at hand -- or just showing both -- is the best option.
I sympathize with your position, but in this case the two liner is significantly more readable. I had no problem digesting it. I then looked at the longer version and it was a much higher cognitive load to digest that. I have to look at multiple for loops to realize they're merely counting the words in a corpus. The shorter version lets me see it immediately.
It's probably a matter of audience. For the folks I've been teaching lately, who mostly know some combination of Java/C++/MATLAB, the Pythonic version is probably harder to follow.
Anyways, now I have two ways of saying the same thing, which is always nice to have when teaching.
> Have there been any good studies on programmer productivity?
Yes, but mostly from the companies developing these products:
* The CoPilot productivity study by Peng et al. that is summarized in a Blog post [1] with some additional details in the Arxiv preprint [2]. They find "developers who used GitHub Copilot completed the task significantly faster–55% faster than the developers who didn’t use GitHub Copilot". (Grep for "but speed is important, too" in [1].)
* Amazon's Q1 earnings report [3] includes a paragraph stating that "participants [using] CodeWhisperer completed tasks 57% faster (on average) and were 27% more likely to complete them successfully than those who didn’t use CodeWhisperer.
* I seem to remember seeing something on Replit's blog a while back with a similar number, but can't find it anymore, so maybe I'm mistaken.
These speed numbers are on specific and well-specified programming tasks, which is of course only one part of a developer's job, so there's a lot of opportunity for impactful research in this space. I suspect that the Empirical Software Engineering community will be awash in third-party empirical studies asking all sorts of more specific productivity questions by this time next year.
Absolutely. These are the types of pragmatic, real problems we should be focusing on instead of the "risk of extinction from AI".
(The statement at hand reads "mitigating the risk of extinction from AI should be a global priority alongside other societal-scale risks such as pandemics and nuclear war.")
Einstein's letter to Roosevelt was written before the atomic bomb existed.
There's a point where people see a path, and they gain confidence in their intuition from the fact that other members of their field also see a path.
Einstein's letter said 'almost certain' and 'in the immediate future' but it makes sense to sound the alarm about AI earlier, both given what we know about the rate of progress of general purpose technologies and given that the AI risk, if real, is greater than the risk Einstein envisioned (total extermination as opposed to military defeat to a mass murderer.)
> Einstein's letter to Roosevelt was written before the atomic bomb existed.
Einstein's letter [1] predicts the development of a very specific device and mechanism. AI risks are presented without reference to a specific device or system type.
Einstein's letter predicts the development of this device in the "immediate future". AI risk predictions are rarely presented alongside a timeframe, much less one in the "immediate future".
Einstein's letter explains specifically how the device might be used to cause destruction. AI risk predictions describe how an AI device or system might be used to cause destruction only in the vaguest of terms. (And, not to be flippant, but when specific scenarios which overlap with areas I've worked worked in are described to me, the scenarios sound more like someone describing their latest acid trip or the plot to a particularly cringe-worthy sci-fi flick than a serious scientific or policy analysis.)
Einstein's letter urges the development of a nuclear weapon, not a moratorium, and makes reasonable recommendations about how such an undertaking might be achieved. AI risk recommendations almost never correspond to how one might reasonably approach the type of safety engineering or arms control one would typically apply to armaments capable of causing extinction or mass destruction.
Illah Reza Nourbakhsh's 2015 Foreign Affairs article -- "The Coming Robot Dystopia: All Too Inhuman" -- has an excellent take this topic [1].
All of the examples of AI Risk on safe.ai [2] are reasonable concerns. Companies should be thinking about the functional safety of their AI products. Governments should be continuously evaluating the societal impact of products coming to market.
But most of these are not existential risks. This matters because thinking of these as existential risks entails interventions that are not likely to be effective at preventing the much more probable scenario: thousands of small train wrecks caused by the failure (or intended function!) of otherwise unexceptional software systems.
Let's strong-man the case for AI Existential Risk and consider the most compelling example on safe.ai: autonomous weapons.
Nuclear weapons attached to an automated retaliation system pose an obvious existential risk. Let's not do that. But the "automated retaliation system" in that scenario is a total red herring. It's not the primary source of the threat and it is not a new concern! Existing frameworks for safety and arms control are the right starting point. It's a nuclear weapons existential risk with some AI components glued on, not the other way around.
In terms of new risks enabled by recent advances in AI and robotics, I am much more worried about the combination of already available commodity hardware, open source software, and semi-automatic weapons. All three of which are readily available to every adult (in the US). The amount of harm that can be done by a single disturbed individual is much higher than it has been in the past, and I think it's only a matter of time before the first AI-enabled simultaneous multi-location mass shooting happens in the US. The potential for home-grown domestic terrorism using these technologies is sobering and concerning, particularly in light of recent attacks on substations and the general level of domestic tension.
These two risks -- one existential, the other not -- entail very different policy approaches. In the credible versions of the existential threat, AI isn't really playing a serious role. In the credible versions of the non-existential threat, nothing we might do to address "existential AI risk" seems like it'd be particularly relevant stopping a steady stream of train wrecks. The safe.ai website's focus on automated cyber attacks is odd. This is exactly the sort of odd long-tail scenario you need if you want to focus on existential risk instead of much more probable but non-existential train wrecks.
And that's the strong-arm case. The other examples of AI risk are even more concerning in terms of non-existential risk and have even less credible existential risk scenarios.
So, I don't get it. There are lots of credible threats posed by unscrupulous use of AI systems and by deployment of shoddy AI systems. Why the obsession with wild-eyed "existential risks" instead of boring old safety engineering?
Meta: we teach the "probability * magnitude" framework to children in 6th-11th grades. The model is easy to understand, easy to explain, and easy to apply. But at that level of abstraction, it's a pedagogical toy for introducing children to policy analysis.
The feasibility of automatic verification and ease of specification played incredibly important roles in the historical development of specification languages. This raises an interesting question: what new computational tools are coming on the scene, and what role will those tools play in the next generation of specification/programming languages?
Reading this article, I was struck by how noneterminism was all over the place in ur-specification languages. I think the answer to the question above will turn out to be something about: 1. nondeterminism, and 2. LLMs, RL, and diffusion as a way of resolving/refining nondeterminism.
That aside, I like the taxonomy. Some personal footnotes:
1. I would list Hoare Logic as the ur-language instead of GCL. Dynamic logics are in this family. I had never considered Spin and dynamic logic as being related in this way. That's kind of neat, and I'm glad I read the article.
2. I would probably give type theories a place in the list, even though you have to squint a little bit to make them fit in a list of specification languages.
4. I feel exactly the same way about Petri Nets -- kind of neat, feel powerful, but never quite know what to do with them. Maybe now that we're returning to office I will get a copy of "Petri Net Theory and the Modeling of Systems" for the train ride.
Pithy readable implementations of core ideas have a lot of value. I don't see much value in code golfing besides having fun :)