# Constraints that make developers faster — retained record

> Retained news record from news:blog-stack-overflow.

Canonical: https://highsignal.app/data/records/9b665a3cba3ae9de

[← sources](https://highsignal.app/data)


source: [news](https://highsignal.app/data/news) (news:blog-stack-overflow)  published 2026-10-02 07:40 ingested 2026-10-24 10:01

[original source ↗](https://stackoverflow.blog/2026/10/02/constraints-that-make-developers-faster/)

## extract

Skip Labs develops a programming language designed for reactive programming alongside specialized constraint-based tooling for AI agents.
Connect with Julien Verlaguet on LinkedIn.
Congrats to Populist badge winner s0nix for winning the badge on their answer to Git through Visual Studio Code is unusably slow.
TRANSCRIPT
[intro music]
Ryan Donovan
Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I am your host, Ryan Donovan, and today we are talking about creating tooling to constrain the programmer and programs to make sure they're not making mistakes, whether that is through a language or through an agent harness. My guest for that is Julien Verlaguet, who is the CEO over at Skip Labs. So welcome to the show, Julien.
Julien Verlaguet
Thank you. Thanks for having me.
RD
Before we get into the tooling topic, can you tell us a little bit about how you got into software and technology?
JV
TLDR, I got really into it because my parents bought a computer when I was a kid. And back in those days, I wanted to play video games really bad. And the only way to play video games was to copy the source code of some games that was at the end of some book to learn BASIC.
And that's how I ended up debugging BASIC back in those days, because none of those programs was ever working, at least not from the get go. So that was early on. Then at university, I got very quickly involved into programming languages and type theory and proofs and all this kind of field. And I think it's a French thing. There's a lot of French people interested in type systems somehow. And so I studied programming languages in Paris. And then throughout the rest of my career, I was always involved in anything regarding dev tools, correctness, programming languages, etc., etc.
RD
In your involvement in programming language, you've created a programming language or two.
JV
I created several, but I think the only ones that are worth mentioning are Hack and Skip. So there was one called LinearML, which was more experimental, but it was a bit, think of it as Rust for ML. So it was Rust before Rust existed. This was not a major implementation. The mainstream languages would be Hack and Skip. So Hack was created before TypeScript, but I guess the best way to describe it these days would be to say it's TypeScript for PHP. And Skip is a programming language designed for reactive programming. So it's domain-specific language, if you will. It's not a general programming language.
RD
These programming languages are essentially tooling for creating software, right? How did you think about designing them to prevent mistakes?
JV
Things have changed now with AI, obviously. But back then, the balance had to be found between what a human being would tolerate and what the tooling could bring to the developer. Because I mean, we could go all the way, right? Going all the way would be, you have a dependent type system, Agda, Coq, or this kind of stuff. And then you can write whatever you want in your type and be as specific as you want and enforce that. The problem is people are not doing that because the cost of doing that for a human being is just way too high. And so I think back then, the question was not so much about what can we enforce statically. We knew already back then that we could enforce pretty much whatever we wanted statically. The question was more, what do we want to enforce statically that will be bearable for a human being in that context? And the context is going to matter a lot. So for example, when I started my career, I was working on safety critical embedded software. So the kind of software that runs on a plane or nuclear plants or this kind of stuff. So the kind of software where when something goes wrong, people are going to die, right? And in that kind of context, developers are willing to put up with a lot of hurdles. You can give them tooling that is very constraining and they're going to jump through the hoops and make it work until it's correct. In other contexts, such as web development, eh – not so much. What they're willing to put up with is they will typically take anything that makes them gain time. So if you give them a tool that prevents mistakes that they were going to have to debug anyway, then they'll do that. So go back to your original question. I think for Hack and for any system of the sort. So Hack back then, the trade-off was we have a bunch of PHP developers at Facebook. They are shipping a ton of code. They start to slow down now because the code base is becoming large enough that maintaining a large code base written in dynamic language comes with a set of challenges. The biggest one especially is if you don't have good unit test coverage. The biggest one is you basically cannot refactor anything anymore. Because whenever you touch a method name, for example, something as simple as that, you really don't know what's going to be affected by this change. And so you don't take your chances and you don't touch anything. So because we wanted to get out of this vicious circle where we were, we decided to create a type system, which is very similar to what TypeScript did. They built a type system on top of JavaScript to be able to build tooling and help. But in that context, for JavaScript and PHP, the right amount of tooling and the right amount of constraint that you want is something that will help you move faster. So find methods faster and whatnot, help you refactor, but definitely not much beyond that. You don't want to constrain too much the developer, even if it helps with correctness, because in that kind of crowd, they're not going to like it.
RD
Yeah, I feel like strongly typed languages and systems have gotten a lot more popular in the last or so years. TypeScript, I think Rust is strongly typed.
JV
So TypeScript is not strongly typed, but yeah, it's gradually typed. Well, it's optionally typed, actually, it's not even gradually typed. So basically, it's a best efforts approach. So it's really, the type system really cannot be trusted. When it gives you an error, it has a good chance that there is an error. And sometimes it's incorrect, too. You should see it as a best effort kind of type system.
RD
So getting something that is strongly typed, you have to define the type at the beginning. Is that what strongly typed means?
JV
Basically, there is a difference between dynamically typed, statically typed, and then strongly typed and weakly typed. And those two dimensions are completely different. So you can be dynamically typed and strongly typed. So that's, for example, Python, or you can also be statically typed and weakly typed. So that's, for example, C. So the definition of strong is when the types cannot be changed, cannot be changed, whether it's dynamically or statically.
So, for example, in PHP or in JavaScript, whenever you have an object, let's say you were supposed to have a string, and the function that you're trying to call, manipulate it with expects an int, there will be a conversion that's going to happen. So we're going to take your type and we're going to try to make it fit, right? I like to say, basically, the way I like to think about these things is, ask yourself, are apples always incompatible with oranges? And if the answer is yes, they're always incompatible, then you're dealing with a strongly typed system. When you are in a system where you will convert objects sometimes, when that's the case, this is a weakly typed system. And then whether that conversion happens statically or dynamically is irrelevant. So I can have a system like C. So, for example, C has a lot of conversions, especially around integers, right? So I can take an int and pass it to another size int, and it's going to do something behind my back. That is weakly typed, right? And then the same is true. So with static versus dynamic, I think people are more familiar with those. But then whether it's static versus dynamic, and whether it's weak versus strong, it's always a spectrum. So there's never a language that is fully static. Even if you take a language like Haskell, that is supposed to be fully statically typed, fully strongly typed, there will be ways to cheat. So, for example, there will be unsafe I.O. in Haskell. Or if you are in OCaml, which is another one that is meant to be very, very extreme on all those dimensions, there's something called object.magic that lets you convert objects, and all that stuff is unsafe, obviously. You are told not to use these things. But what I'm trying to say here is that it's always a spectrum. You never have a language that is fully strong or fully weak. Even in C, you cannot, I mean, C might not be the worst. I think PHP or Perl are probably the languages that are the most, the weakest. Even in those languages, there are some limits. At some point, you will get an exception, and it will tell you, no, this is not going to work, right? So, it's a spectrum.
RD
It seems like there is a lot of different languages that hit different points on the spectrum. Do these sort of correspond to different use cases or scales or other situations?
JV
Yeah, it's definitely use cases. I don't know about scale. Maybe, I don't think scale is the problem. I think it's mostly use cases, context.
RD
It does sound like the hack came about because Facebook started scaling with PHP, and they're like, hey, this is out of control.
JV
Ah, I see, I see, I see. So, you're talking about the scale of the code base. You're not talking about the scale of the program. Yes, so definitely. The scale of code bases plays a huge role in your choice of programming language. And what is very unfortunate is what was a good choice when you start may not be one, you know, two, three, five years down the road. And so, it's very, very difficult because a lot of languages have been very successful because they were very good for people who wanted to get something off the ground very quickly. And then, years later, you are stuck with those technologies for years and years and years, and you have a hard time evolving your system. I mean, Python is a very good example of that, where you start in Python, it's extremely fast, it's very compelling, everything works well, you get something working very, very, very quickly. And then, years down the road, you have a huge Python code base, and then you start feeling really the pain of pretty much everything, like refactoring is a nightmare, the performance is a nightmare, the tooling doesn't really scale, nothing scales, it's painful. So, Python is a good example of a language that gets you in one of those traps where you start with it because it's super fast and super compelling. And then, five years or ten years down the road, everybody will curse you for choosing Python to start the project.
RD
Yeah, I mean, I've seen a lot of refactors where people are replacing their Python scripts with Go or something else.
JV
Python is super powerful when you want to get something running very, very quickly. But I would always ask myself the question, is this thing likely to grow? Is there a non-zero chance that this thing is going to grow? And if there is, then I would probably think twice before using Python.
RD
Obviously, we are in an era of software development that is no longer as close to the code. People are using agents to spin up entire code bases very quickly. How are you thinking about this sort of constraint-based tooling for agents?
JV
So, for agents, things are a little bit different because you're not optimizing for the same thing. So, what's good with agents is that they don't complain, right? So, you can make it as constrained as you want and nobody is going to complain. However, you have different dimensions to care about. So, one of them is going to be token use. So, you can make a lot of rules, but if those rules feel alien to the agents, what's likely to happen is that they're going to get it wrong repeatedly and they'll have to iterate on their code to get it right eventually.
And that is going to cost you tokens. The second dimension is familiarity in the sense that a lot of those models are trained on datasets. And the larger those datasets, the more the programming principles are going to be enshrined in the model. And if you try to deviate from that, it's going to cost you a lot. So, for example, we worked a bunch on TypeScript and we wrote tools for TypeScript to help agents write better code for TypeScript. And it could be tempting to say, hey, you know what? Let's just write a super strict version of TypeScript that doesn't use at all the same idioms, but at least we know is completely safe. If you do that, it's not going to work well. You really have to stick to idiomatic TypeScript. And if you don't, then it's going to cost you. So, I would say the trade-off with humans was don't spend too much time for humans and don't frustrate the humans too much because they're going to give up on your tools. For models, it's more token use and how much this is going to cost you in terms of token usage.
RD
Right. The token usage, to sort of like put it specifically, is because of the multi-step with the iteration, that's going to be a lot of costing extra tokens and a lot of context going in. So, how do you hit that sweet spot of constraining an agent, making it safe, but also doing it on a budget?
JV
So, I think you have to take it like an experimental science, right? So, first, we have to be specific about how much compute power you have because if you're training your own model, things are very, very different. Then you can shape how the model thinks about something.
So, we're going to put that aside and we're going to assume that you're not training your own model. So, if you're not training your own model, it feels very much like an experimental science. You basically set up a bunch of tasks and then you let a bunch of agents to code those tasks and those tasks and that's going to give you a baseline. And then you make changes to your tooling in general and you're going to measure how those changes affect the performance of the agent. Obviously, if you want to do things rigorously, you need to use more than one model and all of that costs. And so, since it costs a lot of money because you have to burn a lot of token, a smart way to go about it is to first run experiments on smaller scales, things, small examples.
So, let's say a few percentage of your code base. Let's say you have an idea to improve a tool, you write this idea and before running the full test suite to benchmark this idea, you first run it on a few examples where you think it's going to make a difference. If it does make a difference, then you make it part of the next batch where we will rerun all the tests and see if the performance improves. But it's very much like experimental science.
RD
So, you're talking with a lot of experiments and feedback and sort of iterating and building. I think we've heard in the last year or so a lot about loops. First I heard of it was the Ralph loop, but there's a lot of iterating, you know, inner loops, outer loops, various ways to do that. How do you think about building this sort of feedback loop system with an agent? Are you automating that?
JV
We have our own harness, which defines its own loops. And the way we like to think about it is that I can walk you through the different steps. So, the big innovation of our loop is that we have it all centered around reactive programming. And so, reactive programming is a style of programming where state is managed for you. So, a little bit like when you have an Excel spreadsheet, for example, and you make a change, you don't go and maintain the change in the spreadsheets by hand. You know, the system is doing it for you. So, imagine a programming language that works this way. This is exactly what Skip is. So, our loop, the way it works is you have a first phase where you take a diff. So, the LLM has produced a change, right? And wants to commit that change. So, step one, we're going to run through a bunch of tooling that is going to validate this diff. One of them is going to be type checking. Once the type checking is okay and states, yes, this program is correct, then after that, we can run a reachability analysis. And the reachability analysis will tell us which part of the program is affected by this change. And especially it can tell you which unit tests are affected by this change. So, once you know that, then you can run the unit test and you can iterate on the unit test until the unit test pass. And then once the unit test pass, you do the same with integration tests and all the other layers of testing. Once you reach all of that, now you have a diff and you know you want to integrate it into a running program. The running program itself is incremental. So, you can take this change and make it part of the program and just update the pieces that need to be updated. But basically, long story short, the loop itself is not where the secret sauce is. The secret sauce is, it's a very normal, traditional loop, the kind of thing you would expect from an agent. Where the secret sauce is that because all of our tooling is incremental every step of the way, whenever a change occurs, we can take those changes in very, very quickly. And it's starting to pay off, but it's going to pay off more and more in the future. Because right now, the bottleneck is still the models. Because one, the model are pretty slow. And two, the code bases that they tend to work on are still small enough that the LLM tends to be the bottleneck. But I think that's going to change. In the next couple of years, the models are going to get faster, much, much, much, much faster. The hardware and everything, and then it's going to be compressed. It's going to be both at the hardware level and at the software level. And the code bases that the models evolve in are going to get bigger and bigger and bigger, just because models can produce so much code that it's inevitable.
RD
Do you think that models were able to understand and retain an understanding of a large code base? Sort of a context rot question, right?
JV
Yeah, I think we'll have to do things differently. I don't think growing the window is just going to be the solution for longer term. I think we'll have to find better solutions, whether it's at the level of the model or at the level of the tooling. That is still unclear. I think probably a bit of both. Yeah, I'm more interested in the tooling aspect, but I wouldn't be surprised if the models evolve. Because I mean, if you think about it, the models have been thought for text, right? And for natural language understanding. And we're only scratching the surface of what we could do to make a transformer better adapted for code. And specifically, and I'm not just talking about the embeddings, I'm really talking about everything before and after in terms of compression and whatnot, what we could do to make it better suited for code. Just to be clear, this is not at all my field. I have a level of understanding of this stuff that is very shallow. So don't come and question me on that. I just wouldn't be surprised if there was some major advancement there.
RD
I think it's Vercel has a language that is specifically for agents to develop code that is not intended for humans at all. Is that a necessary thing? Is that a step in an interesting direction?
JV
I think so. If I had to put my money on it, I would say it's a little bit early right now. I think we're going to get to that at some point. But sometimes it's good to be early because you get to occupy the space before everybody else. But I would say right now, you should work on TypeScript or Python. And I think TypeScript is likely to win because there's a JIT and the ecosystem is not as fragmented as Python. Python just has too many versions. Python is notoriously hard to optimize because it depends on a lot of C libraries that uses the internals of the interpreter. And so I think it's going to be either Python or TypeScript. But if I had to bet between those two, I think it's going to be TypeScript. And the reason why I think models are going to write a lot of TypeScript for the foreseeable future is that they are, as of today, they still rely on large datasets. And the internet is full of annotated TypeScript. And that's not going to change anytime soon. So since that's the language where they have the best, highest quality data, more likely that's what the agents are going to be good at. And once they get to a level where their understanding of programming is generic enough that it transposes to another language, then it will be time, I think, to think about what a language design specifically for an AI looks like.
RD
It is a sort of next level leap where it has a general understanding of programming because, like you said, they are designed to understand text and statistically predict text. This seems like it's a whole other model.
JV
Well, I mean, I must admit that I've been really impressed with how far LLMs have come. And I've underestimated them repeatedly. So I'm not going to make that mistake once again. Because it is true that at the end of the day, it's just predicting what the next token is the most likely. And seeing what they're capable of doing just with that methodology is very, very impressive. So maybe we won't need anything specific to programming languages. You'll just give more data to the model and the model will be able to learn that and make all the connections inside its own weights. That's possible. And I don't think it's likely. And I don't think it's likely just in terms of costs. Because if we were to get one of those super intelligence that can program in any language, yada, yada, yada, chances are high we would need many, many, many more weights. And in terms of costs, I think it's likely that we'll go for something more cost efficient.
RD
Definitely does seem like there is a big cost effective sector in the model world growing that models have gotten so good that it's like, well, I don't need the frontier model for this specific thing that I'm doing, right?
JV
I mean, you don't need it at any cost. That's the thing, right? Now, I mean, before, I'd say one year ago, the frontier models were far enough from what you really wanted, that you always wanted the best. And the cost was low enough that you were never asking yourself the question, right? You would just use whatever frontier model. But now that the frontier models have gotten so big and so expensive to operate, now it becomes a real trade-off, right? Do you want to use something that costs a ton of money for a simple refactoring that you may not actually validate at the end? Well, maybe not. Maybe some older models or some open weight models running on a cheap infrastructure is what you want.
RD
It depends coming into the model selection.
JV
Yeah, it's interesting times for tooling. So this is why I'm very interested. I think it's the beginning of a very interesting time for people like myself who like to build tools because the world before was a bit boring where you just throw more data at the model and the model just gets better. For somebody who likes to build tools, that's not a super compelling story, right? But now with more models and more trade-offs then the tooling and the scaffolding around the model now becomes more important and that's my area. That's where I like to have fun.
RD
Yeah, with the conversation on harnesses and skills and connectors and all that sort of thing, that is absolutely getting to the tooling world, right? So what do you think is the piece of the sort of agentic tooling puzzle that is either missing or overlooked right now?
JV
I mean, it's not completely overlooked. I think composability is not where it should be. So I've read the latest DeepSeq paper on that and they clearly understand that this is a big subject. So it's not overlooked, but it's not where it should be because in a world where agents produce a lot of code, we will need composability. You will have a lot of agents that are producing a lot of new capabilities and we need to be able to plug them in and unplug them cleanly. And except for the DeepSeq folks, I don't see very many people having solutions for that. So I think there's a lot to be said there.
RD
In terms of like a harness that is componentized, kind of plug and play, I think it was the DeepSeq one that I heard that was entirely plug and play where every piece of it could be replaced. Is that right?
JV
Yeah, I think it's called Cordis and they released a white paper not too long ago and I haven't finished the paper, but I've read good chunks of it and they have spent a lot of time thinking about composability and they thought of it formally as well. So they have formal mechanisms to understand how effects work and how co-effects work. So an effect is when the program does something, right? And the co-effect is when the program needs something and how these two things affect composability of the plugin system is really what they looked into, which I think is very important. That's one of the things that if you look at other systems without naming, but everybody knows them, it's clear that the other coding agents don't think too hard about these problems.
RD
It has been an interesting pathway where originally the LLM was the product and people are like, well, we're going to have the agent harness. And so the harness plus the LLM is the product. And now it's like, well, no, maybe this piece of the harness is the product, right?
JV
Yeah, it's classical infrastructure building. It's always like that, right? Like you always start with some very, very, very core and simple API, which back then was you give some text, you get some text back and then come back a few years later and you have a framework, you have a gazillion APIs, you have configuration files, you have experts who can help you tune the configuration file and you have a whole ecosystem. That's always how infrastructure works.
[transition music]
RD
It's that time of the show again where we shout out somebody who came on the Stack Overflow, drop some knowledge, share some curiosity and earn themselves a badge. Today, we're shouting out the winner of a Populous badge. Somebody who dropped an answer that was so good, it outscored the accepted answer. So congrats to Sonix for answering get through Visual Studio is unusably slow. If you're curious about that, we'll have the answer for you in the show notes. I'm Ryan Donovan. I edit the blog, host the podcast here at Stack Overflow. If you have comments, topics to cover, questions, concerns, et cetera, you can email me at podcast at stackoverflow.com. And if you want to connect with me directly, you can find me on LinkedIn.
JV
Awesome. Well, thanks for having me. I'm Julien Verdegret. I'm CEO of SkipLabs. And if you need to find me, you can find me on LinkedIn.
RD
Where can they check out your work at SkipLabs?
JV
On skipper-ai.dev or also on skiplabs.io for the JavaScript framework that we developed.
RD
All right. Thanks for listening, everyone. And we'll talk to you next time.
[outro music]

## retained text (truncated)



```
Skip Labs develops a programming language designed for reactive programming alongside specialized constraint-based tooling for AI agents.
Connect with Julien Verlaguet on LinkedIn.
Congrats to Populist badge winner s0nix for winning the badge on their answer to Git through Visual Studio Code is unusably slow.
TRANSCRIPT
[intro music]
Ryan Donovan
Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I am your host, Ryan Donovan, and today we are talking about creating tooling to constrain the programmer and programs to make sure they're not making mistakes, whether that is through a language or through an agent harness. My guest for that is Julien Verlaguet, who is the CEO over at Skip Labs. So welcome to the show, Julien.
Julien Verlaguet
Thank you. Thanks for having me.
RD
Before we get into the tooling topic, can you tell us a little bit about how you got into software and technology?
JV
TLDR, I got really into it because my parents bought a computer when I was a kid. And back in those days, I wanted to play video games really bad. And the only way to play video games was to copy the source code of some games that was at the end of some book to learn BASIC.
And that's how I ended up debugging BASIC back in those days, because none of those programs was ever working, at least not from the get go. So that was early on. Then at university, I got very quickly involved into programming languages and type theory and proofs and all this kind of field. And I think it's a French thing. There's a lot of French people interested in type systems somehow. And so I studied programming languages in Paris. And then throughout the rest of my career, I was always involved in anything regarding dev tools, correctness, programming languages, etc., etc.
RD
In your involvement in programming language, you've created a programming language or two.
JV
I created several, but I think the only ones that are worth mentioning are Hack and Skip. So there was one called LinearML, which was more experimental, but it was a bit, think of it as Rust for ML. So it was Rust before Rust existed. This was not a major implementation. The mainstream languages would be Hack and Skip. So Hack was created before TypeScript, but I guess the best way to describe it these days would be to say it's TypeScript for PHP. And Skip is a programming language designed for reactive programming. So it's domain-specific language, if you will. It's not a general programming language.
RD
These programming languages are essentially tooling for creating software, right? How did you think about designing them to prevent mistakes?
JV
Things have changed now with AI, obviously. But back then, the balance had to be found between what a human being would tolerate and what the tooling could bring to the developer. Because I mean, we could go all the way, right? Going all the way would be, you have a dependent type system, Agda, Coq, or this kind of stuff. And then you can write whatever you want in your type and be as specific as you want and enforce that. The problem is people are not doing that because the cost of doing that for a human being is just way too high. And so I think back then, the question was not so much about what can we enforce statically. We knew already back then that we could enforce pretty much whatever we wanted statically. The question was more, what do we want to enforce statically that will be bearable for a human being in that context? And the context is going to matter a lot. So for example, when I started my career, I was working on safety critical embedded software. So the kind of software that runs on a plane or nuclear plants or this kind of stuff. So the kind of software where when something goes wrong, people are going to die, right? And in that kind of context, developers are willing to put up with a lot of hurdles. You can give them tooling that is very constraining and they're going to jump through the hoops and make it work until it's correct. In other contexts, such as web development, eh – not so much. What they're willing to put up with is they will typically take anything that makes them gain time. So if you give them a tool that prevents mistakes that they were going to have to debug anyway, then they'll do that. So go back to your original question. I think for Hack and for any system of the sort. So Hack back then, the trade-off was we have a bunch of PHP developers at Facebook. They are shipping a ton of code. They start to slow down now because the code base is becoming large enough that maintaining a large code base written in dynamic language comes with a set of challenges. The biggest one especially is if you don't have good unit test coverage. The biggest one is you basically cannot refactor anything anymore. Because whenever you touch a method name, for example, something as simple as that, you really don't know what's going to be affected by this change. And so you don't take your chances and you don't touch anything. So because we wanted to get out of this vicious circle where we were, we decided to create a type system, which is very similar to what TypeScript did. They built a type system on top of JavaScript to be able to build tooling and help. But in that context, for JavaScript and PHP, the right amount of tooling and the right amount of constraint that you want is something that will help you move faster. So find methods faster and whatnot, help you refactor, but definitely not much beyond that. You don't want to constrain too much the developer, even if it helps with correctness, because in that kind of crowd, they're not going to like it.
RD
Yeah, I feel like strongly typed languages and systems have gotten a lot more popular in the last or so years. TypeScript, I think Rust is strongly typed.
JV
So TypeScript is not strongly typed, but yeah, it's gradually typed. Well, it's optionally typed, actually, it's not even gradually typed. So basically, it's a best efforts approach. So it's really, the type system really cannot be trusted. When it gives you an error, it has a good chance that there is an error. And sometimes it's incorrect, too. You should see it as a best effort kind of type system.
RD
So getting something that is strongly typed, you have to define the type at the beginning. Is that what strongly typed means?
JV
Basically, there is a difference between dynamically typed, statically typed, and then strongly typed and weakly typed. And those two dimensions are completely different. So you can be dynamically typed and strongly typed. So that's, for example, Python, or you can also be statically typed and weakly typed. So that's, for example, C. So the definition of strong is when the types cannot be changed, cannot be changed, whether it's dynamically or statically.
So, for example, in PHP or in JavaScript, whenever you have an object, let's say you were supposed to have a string, and the function that you're trying to call, manipulate it with expects an int, there will be a conversion that's going to happen. So we're going to take your type and we're going to try to make it fit, right? I like to say, basically, the way I like to think about these things is, ask yourself, are apples always incompatible with oranges? And if the answer is yes, they're always incompatible, then you're dealing with a strongly typed system. When you are in a system where you will convert objects sometimes, when that's the case, this is a weakly typed system. And then whether that conversion happens statically or dynamically is irrelevant. So I can have a system like C. So, for example, C has a lot of conversions, especially around integers, right? So I can take an int and pass it to another size int, and it's going to do something behind my back. That is weakly typed, right? And then the same is true. So with static versus dynamic, I think people are more familiar with those. But then whether it's static versus dynamic, and whether it's weak versus strong, it's always a spectrum. So there's never a language that is fully static. Even if you take a language like Haskell, that is supposed to be fully statically typed, fully strongly typed, there will be ways to cheat. So, for example, there will be unsafe I.O. in Haskell. Or if you are in OCaml, which is another one that is meant to be very, very extreme on all those dimensions, there's something called object.magic that lets you convert objects, and all that stuff is unsafe, obviously. You are told not to use these things. But what I'm trying to say here is that it's always a spectrum. You never have a language that is fully strong or fully weak. Even in C, you cannot, I mean, C might not be the worst. I think PHP or Perl are probably the languages that are the most, the weakest. Even in those languages, there are some limits. At some point, you will get an exception, and it will tell you, no, this is not going to work, right? So, it's a spectrum.
RD
It seems like there is a lot of different languages that hit different points on the spectrum. Do these sort of correspond to different use cases or scales or other situations?
JV
Yeah, it's definitely use cases. I don't know about scale. Maybe, I don't think scale is the problem. I think it's mostly use cases, context.
RD
It does sound like the hack came about because Facebook started scaling with PHP, and they're like, hey, this is out of control.
JV
Ah, I see, I see, I see. So, you're talking about the scale of the code base. You're not talking about the scale of the program. Yes, so definitely. The scale of code bases plays a huge role in your choice of programming language. And what is very unfortunate is what was a good choice when you start may not be one, you know, two, three, five years down the road. And so, it's very, very difficult because a lot of languages have been very successful because they were very good for people who wanted to get something off the ground very quickly. And then, years later, you are stuck with those technologies for years and years and years, and you have a hard time evolving your system. I mean, Python is a very good example of that, where you start in Python, it's extremely fast, it's very compelling, everything works well, you get something working very, very, very quickly. And then, years down the road, you have a huge Python code base, and then you start feeling really the pain of pretty much everything, like refactoring is a nightmare, the performance is a nightmare, the tooling doesn't really scale, nothing scales, it's painful. So, Python is a good example of a language that gets you in one of those traps where you start with it because it's super fast and super compelling. And then, five years or ten years down the road, everybody will curse you for choosing Python to start the project.
RD
Yeah, I mean, I've seen a lot of refactors where people are replacing their Python scripts with Go or something else.
JV
Python is super powerful when you want to get something running very, very quickly. But I would always ask myself the question, is this thing likely to grow? Is there a non-zero chance that this thing is going to grow? And if there is, then I would probably think twice before using Python.
RD
Obviously, we are in an era of software development that is no longer as close to the code. People are using agents to spin up entire code bases very quickly. How are you thinking about this sort of constraint-based tooling for agents?
JV
So, for agents, things are a little bit different because you're not optimizing for the same thing. So, what's good with agents is that they don't complain, right? So, you can make it as constrained as you want and nobody is going to complain. However, you have different dimensions to care about. So, one of them is going to be token use. So, you can make a lot of rules, but if those rules feel alien to the agents, what's likely to happen is that they're going t
```



document fetched 2026-10-24 10:03 · canonical https://stackoverflow.blog/2026/10/02/constraints-that-make-developers-faster