I’ll paraphrase a bit of our Twitter discussion about Jack Rusher’s talk. I can certainly see how he came across as arrogant and generally that’s a huge turn-off for me too. But I think Rusher was mostly playing a character deliberately in order to try to be provocative enough to get people to actually take a step back and question some of their assumptions about programming languages. I think it takes a certain gusto to get programmers out of their ruts and Rusher did a good job of that.
I originally had a 300 word miniessay on exactly what I hated about his talk but decided it was living rent-free in my head and axed it, so this is the less incendiary response :D
FTR I tried a couple of the technologies he was shilling and they all had serious problems, and I looked up his claims about NASA and common lisp and it’s a much worse picture for lisp than he claimed.
I mean okay yeah he’s pretty arrogant…but he also emphasizes that he’s not shilling Common Lisp/Erlang/Clojure/whatever…he’s pointing out that we should take lessons from their better parts and things like interactive environments and richer debugging should be the norm.
FWIW I didn’t find the talk arrogant – I’ll even say it’s interesting and worth watching – but I 100% agree that it’s seriously flawed.
He left out all the reasons that people don’t use such programming environments, thus depriving the audience of a path to address those problems and put the ideas into wider practice. For people who are building production systems, it falls down with a tiny amount of scrutiny, as you allude to.
Though one thing I was thinking during the talk is that the browser itself is one of the few programming environments that does come with rich GUI dev tools, and it’s also arguably the most popular environment !!!
(caveat: I recently learned that iOS Safari dev tools are quite crippled; I think you have to have a Mac to debug there, which is a shame.)
Also thanks for signal boosting the P talk! I remember wanting to look into it a few years ago, but never got around to it … and I missed that there was a Strange Loop talk about it.
I don’t find the talk particularly arrogant, at least anymore so than the average Rust/Haskell evangelist. Dude just seems very passionate and opinionated. I rather suspect people are overly sensitive.
(disclaimer: I’m 30 minutes into a 43 minute talk, perhaps the really obnoxious stuff comes next)
Yeah, I know a number of people who make big claims to be provocative and to get people talking so I’m used to that bluster. Often times with those kinds of people you can corner them and they’ll break from the performative persona and start talking about the real tradeoffs.
I don’t know the speaker though so I can’t say that he is specifically like that. I’ve just seen a pattern with others.
I think so, yes. A big part of the Strange Loop experience for me is “Here’s someone passionate about something crazy you may not have even considered.”
Do they always work out? No, of course not. But I’d rather see a talk from someone opionated, way out there, and 50% wrong, then a talk that is bulletproof but only a tiny incremental step from where I already am. I come to be inspired. I want a random pile of crazy ideas because even the ones that don’t work might lead to a further idea that does.
I bet a lot of what he talks about would not be particularly new to the lobsters crowd, might might be for more orthodox developers. I’m always surprised at how many programmers I encounter out in the world haven’t heard of any of these systems, and who simply accept that the Unix way is just how it has to be.
Yes lobsters being its own echo chamber is also something I’ve also experienced. At least in regards to new technology and completely different programming languages (apart from rust, and even then..).
I feel like answering this question would stray into an extra layer of theoretical speculation. I don’t know this person and I don’t feel qualified to say whether or not a proposed rationale for the tone of their talk would be appropriate for a given context. I only offer up this rationale as an explanation for why I didn’t find it arrogant.
It’s not provocative to use the trope of “everything is complicated because they didn’t have the superior point of view that I have” though. That’s the central point of the talk - that we got to where we are, because everyone along the way was dumb. It’s just a tired argument, and it reeks of hindsight bias.
Now I’m really not an apologist of older technologies either. When it’s time to move on, we move on. The proposed solution to all of these problems though is… spreadsheets, repls, and / or notebooks?. Things that have been around for pretty much equally as long as the “dead languages,” but somehow haven’t saved the entire industry either?
The speaker seems legitimately cool, and fun, and interesting, and smart. No disrespect to them as a person. But the talk itself is isn’t provocative, or interesting, and most importantly provided completely zero fixes for any of the presented problems. And the only reason I’m commenting is hopefully somewhere, people learn from this: instead of 30 minutes of problem statement and 10 minutes of solutions, give a talk with 10 minutes of problem statement and 30 minutes of solutions.
His point is not that “older technologies” are dumb…Lisp is old tech and he probably emphasized that the most out of any of the things he likes. The point is that we shouldn’t settle for the way things are, and that the solutions are at hand. In other words it’s not an argument about intelligence so much as motivation.
It’s not like “spreadsheets, repls, and/or notebooks” have become ubiquitous and found to be a mistake, it’s that they’ve barely been tried. I mean, what language outside of Clojure or CL actually can be said to have an interactive environment that supports REPL interactions that are that rich? I work in Python at $DAYJOB and I would love to have a REPL half as good as Clojure’s there.
It’s not like “spreadsheets, repls, and/or notebooks” have become ubiquitous and found to be a mistake, it’s that they’ve barely been tried. I mean, what language outside of Clojure or CL actually can be said to have an interactive environment that supports REPL interactions that are that rich?
Lisp, Smalltalk, and Ruby all have REPLs that are considered “acceptable” by all of the people that have made this argument before this talk. All of them had their 15 minutes of fame, none more than Ruby. You cannot say that the features being presented here have barely been tried. They have all been tried, and have not led to the magical outcome that is supposed to happen. I mean, you’re referencing Clojure’s REPL. Clojure exists right now. If it’s the savior that it’s supposed to be, why is it barely used? Because the proposed benefits don’t actually matter.
The best things he said in the talk was about static types, where he said he doesn’t like them, but if you do you should use them. Exactly! There’s a free market of tools out there. Usage is completely organic, meaning people use the tools that they want to. That’s why it’s arrogant and patronizing to say that we are using bad tools because the savior tools have “barely been tried.” They have been, they just have different problems, and they do not produce an outcome that is an order of magnitude better than any other tool. You know this is true, because if they did have any meaningful impact on development speed or quality you know that managers would be chomping at the bit to switch to these technologies.
But the opposite seems to be happening in industry. If dynamic types and REPLs are our savior, then why are people who are free to choose their own tools moving more and more to static types and compilers? Could it be that those solve more practical problems for the working programmer than interactive environments do?
They have all been tried, and have not led to the magical outcome that is supposed to happen.
and they do not produce an outcome that is an order of magnitude better than any other tool. You know this is true, because if they did have any meaningful impact on development speed or quality you know that managers would be chomping at the bit to switch to these technologies.
Culture is a powerful inertial force in these matters, and there is definitely a strong mainstream computing culture that is hard to break from. I think this interferes much more with any “free market of tools” than we are normally willing to acknowledge.
Lisp, Smalltalk, and Ruby all have REPLs that are considered “acceptable” by all of the people that have made this argument before this talk.
I’ve heard people make the argument that Ruby is an acceptable Lisp because of its metaprogramming features, but never that its REPL rivaled a Lisp REPL. I’d be curious to learn more about that.
If it’s the savior that it’s supposed to be, why is it barely used? Because the proposed benefits don’t actually matter.
Or it could be because there are other disadvantages to Clojure that preclude widespread adoption, like the steep learning curve and Lisp’s reputation as exotic. (And, I’ll admit, some arrogance.) Perhaps the benefits actually matter, just not enough for people to overcome their (understandable) aversion to (what I maintain are) the few languages where these features are actually central to the workflow.
why are people who are free to choose their own tools moving more and more to static types and compilers? Could it be that those solve more practical problems for the working programmer than interactive environments do?
Sure. Could be. Are you now making the argument that static types and compilers are an order of magnitude more productive?
This isn’t really what I’m saying, only that the features that the talk mentions is the ability to inspect and modify the language environment at runtime, which is most certainly possible in Ruby, and Ruby’s usage has been in steep decline recently.
Are you now making the argument that static types and compilers are an order of magnitude more productive?
Unlike most FMs, where the invariant can be a mathematical expression, you have to write an implementation of the invariant. I feel like as an experienced specifier I’d find that extremely limiting, but if it makes things more approachable for programmers that might be a worthwhile tradeoff.
I’m a huge fan of P (and the direction that P points to for “accessible” FMs in general), and I’ll say that I find this approach more enlightening than limiting. Starting from TLA+ (which is the other FM tool I like best), it’s very natural to think about invariants as statements about global state, rather than about machine-observed (or client-observed) behavior. I initially found P’s approach limiting, but over time I’ve found it more and more useful to think from a client-centric approach which comes rather naturally in P.
I can’t point to TLA+ and P and say which is better, but I will say that I’ve found that there are some people who naturally take to TLA+‘s approach, and some who take to P’s, and the latter group is bigger (in my experience working with these tools on service teams at AWS).
In a way, it’s similar to the different approaches to database isolation levels taken by the classic state approach (Adya, etc), and by client-centric approaches (Crooks et al[1], etc).
“After the talk I asked him why he named it P. He said it was because it was one of the only one-letter languages remaining. He now regrets the name.” Nice understated comedic prose style right here.
My 2 fav out of these were “Building Observability for 99% Developers” and “Formal Modeling and Analysis of Distributed Systems,” and they’re related in a really interesting way. They both made me think that lightweight formal methods is the way to go in the future.
For the Building Observability… talk - the speaker came from a PL theory / formal methods background, and her experience with that is that typical FM stuff (she mostly harped on types and PL theory) misses the mark for practical teams, because most teams don’t even know the full system that they’re working in. I think that last part is 100% true, but I don’t agree that FM is somehow at odds with that reality, especially lightweight formal methods that don’t prove the entire system. So I agree with the problem statement of this talk, I just have a different idea of what the answer is.
This dovetails perfectly to the Formal Modeling… talk, which I think had the best intro to FM of any talk I’ve seen in a while. The speaker highlighted some very real problems with verification, like the verification gap, and thinking of systems as a connection of services vs. a single monolithic entity that you prove top-to-bottom. P just avoids the verification gap, but does tackle the problem of how to check a modular specification, which is cool.
Takeaways from these: lightweight formal methods is the way to go. Be it (partial) design verification, or formally-inspired testing strategies like property-based testing or model-based test case generation, these are the practices with the most likelihood of being adopted by real teams today.
“Formal” can be a dirty word to programmers, but hopefully the lightweight version is more appealing. Using logic and math to think about a problem is much different than proving a codebase line-by-line. The former is great and applicable in a number of different forms.
But I’ve used a lot of different “digital ink” programs and they all have the same problem: handwriting recognition.
I’ve had similar experiences to yours in the past, so I can relate a little bit. (currently, my ReMarkable 2 is doing a shockingly good job of translating my average-messiness handwriting into ASCII) However, I believe that this is an instance of “judging an idea or a theoretical system based on the weaknesses of current implementations”, which I think is a bit flawed (for instance, GC was impractical on consumer hardware when first developed, formal methods were too computationally intensive to apply to software back in the 60’s, steaming video was a no-go when the World Wide Web happened because the bandwidth wasn’t there yet, etc.)
In the specific case of digital ink, handwriting recognition has gotten slowly better over the past few decades, and is pretty good for the median person using OneNote or a ReMarkable. As accuracy improves even further, there will likely be gains made for those with unusually messy handwriting - and the only way to find out is to try!
That’s just for converting handwriting to text: extracting semantics will be a lot harder.
It definitely is. However, in that realm, I can imagine systems that take semi-structured input, just like Photoshop “de-expressifies” (makes less expressive) the digital art realm by constraining artists its tools and workflows, trading some learning curve and freedom in exchange for the tool being feasible at all. I’m not saying that such a system is actually feasible or easy, just that the design-space is worth exploring.
This was a good read, thanks!
In particular, I will be checking out Hedy as I have a seven-year-old who enjoys Scratch but might want a different approach, this looks really interesting.
From the It Will Never Work In Theory mini-conf, the “Refactor commits take longer to approve than feature commits.” talk was interesting but not as broad as I’d hoped. IIRC it was only talking about Java and only the refactoring experience within a single editor. Very nice to see someone talking about refactoring beyond simple find/replace though.
I’ll paraphrase a bit of our Twitter discussion about Jack Rusher’s talk. I can certainly see how he came across as arrogant and generally that’s a huge turn-off for me too. But I think Rusher was mostly playing a character deliberately in order to try to be provocative enough to get people to actually take a step back and question some of their assumptions about programming languages. I think it takes a certain gusto to get programmers out of their ruts and Rusher did a good job of that.
I originally had a 300 word miniessay on exactly what I hated about his talk but decided it was living rent-free in my head and axed it, so this is the less incendiary response :D
FTR I tried a couple of the technologies he was shilling and they all had serious problems, and I looked up his claims about NASA and common lisp and it’s a much worse picture for lisp than he claimed.
I mean okay yeah he’s pretty arrogant…but he also emphasizes that he’s not shilling Common Lisp/Erlang/Clojure/whatever…he’s pointing out that we should take lessons from their better parts and things like interactive environments and richer debugging should be the norm.
The reason to drop common lisp was poor interoperability with the other stuff they were doing right?
Yeah, but also the key benefit he claimed— remote debugging and code reload— is something NASA routinely does with their C and Java code.
For the curious, Lisping at JPL, by Ron Garret: https://flownet.com/gat/jpl-lisp.html
And a (beautifully transcribed) podcast interview with him, by Adam Gordon Bell who is also a user here: https://corecursive.com/lisp-in-space-with-ron-garret/
I haven’t watched the talk, and this is probably the smallest error, but I did notice he got my name wrong while reading it from a screenshot.
FWIW I didn’t find the talk arrogant – I’ll even say it’s interesting and worth watching – but I 100% agree that it’s seriously flawed.
He left out all the reasons that people don’t use such programming environments, thus depriving the audience of a path to address those problems and put the ideas into wider practice. For people who are building production systems, it falls down with a tiny amount of scrutiny, as you allude to.
Though one thing I was thinking during the talk is that the browser itself is one of the few programming environments that does come with rich GUI dev tools, and it’s also arguably the most popular environment !!!
(caveat: I recently learned that iOS Safari dev tools are quite crippled; I think you have to have a Mac to debug there, which is a shame.)
Also thanks for signal boosting the P talk! I remember wanting to look into it a few years ago, but never got around to it … and I missed that there was a Strange Loop talk about it.
I don’t find the talk particularly arrogant, at least anymore so than the average Rust/Haskell evangelist. Dude just seems very passionate and opinionated. I rather suspect people are overly sensitive.
(disclaimer: I’m 30 minutes into a 43 minute talk, perhaps the really obnoxious stuff comes next)
I also enjoyed this talk, and am a little surprised people thought it was arrogant
Yeah, I know a number of people who make big claims to be provocative and to get people talking so I’m used to that bluster. Often times with those kinds of people you can corner them and they’ll break from the performative persona and start talking about the real tradeoffs.
I don’t know the speaker though so I can’t say that he is specifically like that. I’ve just seen a pattern with others.
But is that really a fitting behavior for strange loop talks?
I think so, yes. A big part of the Strange Loop experience for me is “Here’s someone passionate about something crazy you may not have even considered.”
Do they always work out? No, of course not. But I’d rather see a talk from someone opionated, way out there, and 50% wrong, then a talk that is bulletproof but only a tiny incremental step from where I already am. I come to be inspired. I want a random pile of crazy ideas because even the ones that don’t work might lead to a further idea that does.
I agree, those have generally been some of the best talks at Strange Loop. What crazy or interesting ideas were presented here though?
I bet a lot of what he talks about would not be particularly new to the lobsters crowd, might might be for more orthodox developers. I’m always surprised at how many programmers I encounter out in the world haven’t heard of any of these systems, and who simply accept that the Unix way is just how it has to be.
Yes lobsters being its own echo chamber is also something I’ve also experienced. At least in regards to new technology and completely different programming languages (apart from rust, and even then..).
I feel like answering this question would stray into an extra layer of theoretical speculation. I don’t know this person and I don’t feel qualified to say whether or not a proposed rationale for the tone of their talk would be appropriate for a given context. I only offer up this rationale as an explanation for why I didn’t find it arrogant.
It’s not provocative to use the trope of “everything is complicated because they didn’t have the superior point of view that I have” though. That’s the central point of the talk - that we got to where we are, because everyone along the way was dumb. It’s just a tired argument, and it reeks of hindsight bias.
Now I’m really not an apologist of older technologies either. When it’s time to move on, we move on. The proposed solution to all of these problems though is… spreadsheets, repls, and / or notebooks?. Things that have been around for pretty much equally as long as the “dead languages,” but somehow haven’t saved the entire industry either?
The speaker seems legitimately cool, and fun, and interesting, and smart. No disrespect to them as a person. But the talk itself is isn’t provocative, or interesting, and most importantly provided completely zero fixes for any of the presented problems. And the only reason I’m commenting is hopefully somewhere, people learn from this: instead of 30 minutes of problem statement and 10 minutes of solutions, give a talk with 10 minutes of problem statement and 30 minutes of solutions.
His point is not that “older technologies” are dumb…Lisp is old tech and he probably emphasized that the most out of any of the things he likes. The point is that we shouldn’t settle for the way things are, and that the solutions are at hand. In other words it’s not an argument about intelligence so much as motivation.
It’s not like “spreadsheets, repls, and/or notebooks” have become ubiquitous and found to be a mistake, it’s that they’ve barely been tried. I mean, what language outside of Clojure or CL actually can be said to have an interactive environment that supports REPL interactions that are that rich? I work in Python at $DAYJOB and I would love to have a REPL half as good as Clojure’s there.
Lisp, Smalltalk, and Ruby all have REPLs that are considered “acceptable” by all of the people that have made this argument before this talk. All of them had their 15 minutes of fame, none more than Ruby. You cannot say that the features being presented here have barely been tried. They have all been tried, and have not led to the magical outcome that is supposed to happen. I mean, you’re referencing Clojure’s REPL. Clojure exists right now. If it’s the savior that it’s supposed to be, why is it barely used? Because the proposed benefits don’t actually matter.
The best things he said in the talk was about static types, where he said he doesn’t like them, but if you do you should use them. Exactly! There’s a free market of tools out there. Usage is completely organic, meaning people use the tools that they want to. That’s why it’s arrogant and patronizing to say that we are using bad tools because the savior tools have “barely been tried.” They have been, they just have different problems, and they do not produce an outcome that is an order of magnitude better than any other tool. You know this is true, because if they did have any meaningful impact on development speed or quality you know that managers would be chomping at the bit to switch to these technologies.
But the opposite seems to be happening in industry. If dynamic types and REPLs are our savior, then why are people who are free to choose their own tools moving more and more to static types and compilers? Could it be that those solve more practical problems for the working programmer than interactive environments do?
Culture is a powerful inertial force in these matters, and there is definitely a strong mainstream computing culture that is hard to break from. I think this interferes much more with any “free market of tools” than we are normally willing to acknowledge.
Another explanation is that language choice has a very minor effect on how profitable a software business can be.
[Edited bc I fat fingered this on my phone]
I’ve heard people make the argument that Ruby is an acceptable Lisp because of its metaprogramming features, but never that its REPL rivaled a Lisp REPL. I’d be curious to learn more about that.
Or it could be because there are other disadvantages to Clojure that preclude widespread adoption, like the steep learning curve and Lisp’s reputation as exotic. (And, I’ll admit, some arrogance.) Perhaps the benefits actually matter, just not enough for people to overcome their (understandable) aversion to (what I maintain are) the few languages where these features are actually central to the workflow.
Sure. Could be. Are you now making the argument that static types and compilers are an order of magnitude more productive?
This isn’t really what I’m saying, only that the features that the talk mentions is the ability to inspect and modify the language environment at runtime, which is most certainly possible in Ruby, and Ruby’s usage has been in steep decline recently.
No.
I’m a huge fan of P (and the direction that P points to for “accessible” FMs in general), and I’ll say that I find this approach more enlightening than limiting. Starting from TLA+ (which is the other FM tool I like best), it’s very natural to think about invariants as statements about global state, rather than about machine-observed (or client-observed) behavior. I initially found P’s approach limiting, but over time I’ve found it more and more useful to think from a client-centric approach which comes rather naturally in P.
I can’t point to TLA+ and P and say which is better, but I will say that I’ve found that there are some people who naturally take to TLA+‘s approach, and some who take to P’s, and the latter group is bigger (in my experience working with these tools on service teams at AWS).
In a way, it’s similar to the different approaches to database isolation levels taken by the classic state approach (Adya, etc), and by client-centric approaches (Crooks et al[1], etc).
[1] https://www.cs.cornell.edu/lorenzo/papers/Crooks17Seeing.pdf
“After the talk I asked him why he named it P. He said it was because it was one of the only one-letter languages remaining. He now regrets the name.” Nice understated comedic prose style right here.
My 2 fav out of these were “Building Observability for 99% Developers” and “Formal Modeling and Analysis of Distributed Systems,” and they’re related in a really interesting way. They both made me think that lightweight formal methods is the way to go in the future.
For the Building Observability… talk - the speaker came from a PL theory / formal methods background, and her experience with that is that typical FM stuff (she mostly harped on types and PL theory) misses the mark for practical teams, because most teams don’t even know the full system that they’re working in. I think that last part is 100% true, but I don’t agree that FM is somehow at odds with that reality, especially lightweight formal methods that don’t prove the entire system. So I agree with the problem statement of this talk, I just have a different idea of what the answer is.
This dovetails perfectly to the Formal Modeling… talk, which I think had the best intro to FM of any talk I’ve seen in a while. The speaker highlighted some very real problems with verification, like the verification gap, and thinking of systems as a connection of services vs. a single monolithic entity that you prove top-to-bottom. P just avoids the verification gap, but does tackle the problem of how to check a modular specification, which is cool.
Takeaways from these: lightweight formal methods is the way to go. Be it (partial) design verification, or formally-inspired testing strategies like property-based testing or model-based test case generation, these are the practices with the most likelihood of being adopted by real teams today.
“Formal” can be a dirty word to programmers, but hopefully the lightweight version is more appealing. Using logic and math to think about a problem is much different than proving a codebase line-by-line. The former is great and applicable in a number of different forms.
I’ve had similar experiences to yours in the past, so I can relate a little bit. (currently, my ReMarkable 2 is doing a shockingly good job of translating my average-messiness handwriting into ASCII) However, I believe that this is an instance of “judging an idea or a theoretical system based on the weaknesses of current implementations”, which I think is a bit flawed (for instance, GC was impractical on consumer hardware when first developed, formal methods were too computationally intensive to apply to software back in the 60’s, steaming video was a no-go when the World Wide Web happened because the bandwidth wasn’t there yet, etc.)
In the specific case of digital ink, handwriting recognition has gotten slowly better over the past few decades, and is pretty good for the median person using OneNote or a ReMarkable. As accuracy improves even further, there will likely be gains made for those with unusually messy handwriting - and the only way to find out is to try!
It definitely is. However, in that realm, I can imagine systems that take semi-structured input, just like Photoshop “de-expressifies” (makes less expressive) the digital art realm by constraining artists its tools and workflows, trading some learning curve and freedom in exchange for the tool being feasible at all. I’m not saying that such a system is actually feasible or easy, just that the design-space is worth exploring.
I finally finished this… why is 2023 the last strange loop?
Alex didn’t mean to become a conference organizer and wants his life back.
This was a good read, thanks! In particular, I will be checking out Hedy as I have a seven-year-old who enjoys Scratch but might want a different approach, this looks really interesting.
From the It Will Never Work In Theory mini-conf, the “Refactor commits take longer to approve than feature commits.” talk was interesting but not as broad as I’d hoped. IIRC it was only talking about Java and only the refactoring experience within a single editor. Very nice to see someone talking about refactoring beyond simple find/replace though.