[shevy-java]

> languages without types tend to grow them, like PHP in 7.4 and Python type annotations

Well ... that is a trend that is driven largely by people who love types.

Not everyone shares that opinion. See ruby.

It is very hard to try to argue with people who love types. They will always focus on "types are great, every language must have them". They, in general, do not acknowledge trade-offs when it comes to type systems.

So the claim "tend to grow them" ... it is not completely wrong, but it also does not fully capture an independent want to add them. It comes ALWAYS from people who WANT types. I saw this happen "live" in ruby; I am certain this happened in python too.

> inevitably, people want to push types. even Go. C++ templates are the ultimate example. if it can be computed at compile time, at some point someone wants to, like Rust's ongoing constification.

And many people hate C++ templates. But comparing that language to e. g. ruby is already a losing argument. Languages are different. So are the trade-offs.

> dependent types can get you there. hence perfectable.

So the whole point about claiming a language is "perfectable", means to have types? I don't agree with that definition at all.

> most languages have no facility for this,

How about lisp?

> this lets you design APIs in layers and hide them behind syntax.

The language already failed hard syntax-wise. This is a problem I see in many languages - 99% of the language designers don't think syntax is important. Syntax is not the most important thing in the world, but to neglect it also shows a lack of understanding why syntax ALSO matters. But you can not talk about that really - I am 100% certain alok would disagree. How many people use a language also matters a LOT - you get a lot more momentum when there are tons of people using a language, as opposed to the global 3 or 4 using "lean".

[andai]

You mentioned there are reasons not to type check your program. I would very much like to hear what they are!

Also, I have to point out that of course Ruby has types. And it does type checking. It just does it when the line of code actually runs. (i.e. runtime type errors).

So the discussion here isn't should we check types or not. It's a question of when to do it.

Do you want to know you've made a mistake when you actually make it? Or do you want to find out an unknown amount of time later (e.g. in unfortunate cases, several months later, debugging an issue in prod. Not that I would know anything about that ;)

---

My own thinking on the subject is that it should be configurable.

Rust's level of correctness, for example is probably overkill for a game jam. (As is, arguably, using a low level language in the first place.)

But my thinking here is that correctness should be opt out rather than opt-in. If you have a good reason to make your program wrong by default, then you should be allowed to do that. But it should be a conscious choice! And every source file, at the top of the file, should remind you that you are making that choice: #JAMMODE

And if you intend to actually ship the thing, and charge money for it, in Serious Release Mode the compiler should refuse to build anything that's still in jam mode.

My point here is that some languages make jam mode the only option you have.

[ChadNauseam]

> So the claim "tend to grow them" ... it is not completely wrong, but it also does not fully capture an independent want to add them. It comes ALWAYS from people who WANT types.

Who else would add them, besides people who want them? I'm confused about what you're even claiming here. It sounds like you feel that there's a vocal minority of type enthusiasts who everyone else is just humoring by letting them bolt on their type systems.

[mastermage]

Well Ruby kinda brought forth Crystal which while its own Programming Language is kinda Ruby but with Types.

[ModernMech]

Here's a recent talk about how "concrete syntax matters, actually": https://www.youtube.com/watch?v=kQjrcSMYpaA

Highly recommended!

[yuppiemephisto]

actually i think syntax is incredibly important, but i think i'm approaching it from a viewpoint that's even more syntactic than lisp macros, which in practice tend to center around parens syntactically still. racket a notable exception (and good, but not perfectable lang, one of the inspirations for my remark). typed racket is good but is not culturally central enough. but yeah, i do believe types are [inevitable](https://www.youtube.com/watch?v=0AQdSZqGXz4)

https://reservoir.lean-lang.org/@strata-org/Strata isn't done, but its goal is to let one build whole languages that can look like whatever you like. ones for little kids maybe

syntax matters for normal ppl even more than semantics in some ways since semantics can be optimized and refined on the backend, but everyone is (de)limited by their vocabulary

[vouwfietsman]

> do not acknowledge trade-offs when it comes to type systems

Could you elaborate?

[patrickmay]

Here's a good summary of the limited evidence for the benefits of strong type systems: https://danluu.com/empirical-pl/

[vouwfietsman]

> do not acknowledge trade-offs when it comes to type systems

> gives link to "limited evidence of benefits"

I'm not looking for absence of evidence, as absence of evidence does not mean evidence of absence. The original post claims tradeoffs, where are they? What are we trading? Even the most dynamic-language friendly results in your linked post either claim: "look at what we did without types!" or "even though there's no types in ruby, devs think about them all the time", which I mean, come on.

The only real criticism or tradeoffs on types mentioned is a person getting stuck on a single static type check compilation error, but I can easily counter that with "undefined is not a property of null".

From the link:

> if the strongest statement you can make for your position is that there's no empirical evidence against the position, that's not much of a position.

This is how hypotheses work. Maybe the problem is that we have a hard time proving anything about programming languages?

[lelanthran]

> > languages without types tend to grow them, like PHP in 7.4 and Python type annotations

...

> Not everyone shares that opinion. See ruby.

All programming languages that have values (i.e. all of them) have types, because you cannot have a concrete value that doesn't have a type. This includes Ruby.

The only difference is whether the language lets you annotate the source code with the expected type of each value.

This is why you observe that all languages trend towards visible typing: The types are already there and it's only a matter of whether the language lets the programmer see it, or lets a linter enforce it, and everyone likes linters.

> So the claim "tend to grow them" ... it is not completely wrong, but it also does not fully capture an independent want to add them. It comes ALWAYS from people who WANT types.

Maybe you misidentified where the type declaration is coming from? It might not be coming from people who want to see types in the source code, it most probably is coming from people who want a decent linter.

In 2026, programming without type-enforcement is like programming using an LLM; it's quicker, but less safe.

[jerf]

I also add the observation that while the dynamic typing languages are all growing in the direction of the statically-typed languages, no statically-typed language (that I know of) is adding a lot of dynamically-typed features. If anything the static languages trend towards more static typing. Which doesn't mean the optimum is necessarily "100% in the direction of static typing", the costs of more static typing do eventually overwhelm the benefits by almost any standard, but the trend is universal and fairly clear.

I kind of think there's room for a new dynamically-typed language that is designed around being fast to execute and doesn't cost such a huge performance multiple right off the top, and starts from day 1 to be multi-thread capable, but on the whole the trend is clearly in the direction of static typing.

[lelanthran]

> I kind of think there's room for a new dynamically-typed language that is designed around being fast to execute and doesn't cost such a huge performance multiple right off the top, and starts from day 1 to be multi-thread capable, but on the whole the trend is clearly in the direction of static typing.

Other than the "new" qualifier, Lisp supports all of that - SBCL compiles to native code, ecl/gcl compile to C (IIRC), etc.

[SAI_Peregrinus]

Some languages have only a single type, e.g. BrainFuck only has "byte". Shells tend to only have "string" as a fundamental type, and some helpers to do things like split strings on a separator & iterate over the elements or to treat strings as numbers to do arithmetic. Such single-type languages tend to be esoteric and/or difficult to program in, since every sort of data manipulation not supported by that type has to be done at runtime, by the programmer.

[lelanthran]

> Such single-type languages tend to be esoteric and/or difficult to program in, since every sort of data manipulation not supported by that type has to be done at runtime, by the programmer.

It depends; I recall programming in Tcl in the late 90s, and that has only the string and the list as datatypes, but it felt very powerful, like Lisp but without the easy syntax.

[SAI_Peregrinus]

Powerful, yes. Easy to program in, no.

[andersmurphy]

> How about lisp?

I was wondering why lisp (and forth) were omitted from the initial list of languages named in the post.

I guess Scheme is in the list has ok macros.

[rootnod3]

I get adding Scheme, but omitting CL seems like a big oversight