Comment by adamddev1
1 day ago
Remember when people would argue about how types weren't worth the effort?
I love TypeScript, if nothing else for how it's been able to popularize types.
1 day ago
Remember when people would argue about how types weren't worth the effort?
I love TypeScript, if nothing else for how it's been able to popularize types.
I don't recall anyone disliking types. Lots of people disliked static typing, or more directly static, explicit typing. For instance, I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension.
There are some genuinely untyped languages, or more typically "stringly typed" ones. I hacked around on AREXX as a youth, where all values are strings, even when they look like numbers. Most of the Unix CLI tools like sed could be, uh, said, to be stringly typed. Most of the "discussions" about typing, though, involved Python and similar dynamically typed languages. I don't think I've ever heard someone claim that weakly typed or untyped languages were great for building large project. I've heard plenty of people claiming that Python couldn't be used to build large projects because it was dynamically typed, or "untyped" as they wrongly described it, which was confusing to those of us using it to build large projects.
There's a school of thought that consider the term "types" reflect to the properties that exist in programs even before they are run, as in they are a property of the programs themselves, not their state at runtime. This thinking—which is also what type theory talks about—does consider Python untyped: reading a Python program along with its specification, you are not able to assign types to each expression.
But what Python does have is tagging: when you create an object you tag it, and then whenever you operate on those values, you check the tag and maybe raise an exception or not. This is happening at runtime.
Strongly typed and weakly typed do not seem to have good definitions. A good one I've read is that "strong typing describes the typing you like".
It is great though if people go to the same extent as you to define what they are talking about, as this reduces the chances of misunderstandings. But it should not be taken as fact that the definitions you have chosen are the universally accepted ones.
> Strongly typed and weakly typed do not seem to have good definitions.
Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?
8 replies →
Note that Python supports type annotations in its syntax, but the interpreter will just ignore them as they are meant to be used by external tools such as ruff: https://github.com/astral-sh/ruff
I've had a good experience developing small to medium sized Python programs/scripts using type annotations plus ruff connected to my editor through its LSP (Language Server Protocol). It helps a lot, and I don't like to write Python without it.
You can create types from literal values and use union types, which I feel makes it more pleasant than Go's type system for example.
1 reply →
That's fair, and I don't claim that I have the canonically correct answers. My broader claim is that I don't think I've ever heard someone say ugh, I despise that my bucket of bytes has an associated type! The real discussions weren't against types, but against various type disciplines.
For example, I find it highly annoying to have to sprinkle type annotations all over the place when the compiler isn't smart enough to figure out what I mean, in the absence of ambiguity. Like imagine this C code:
There wasn't a great way until recently (C23, I think?) to say "just make j whatever type it needs to be here and don't pester me with it". Contrast with Rust which is strongly, statically typed but also infers types where it can:
Here, that bit in "foo2" says "cast this str into whatever type you can infer it's suppose to be". Since it's going to be the return value of a function that returns a String, it must be a String, so Rust casts it to a String. Similarly, the first line of main() says f1 is an i8 because it's assigned to something that returns an i8. f2's a String for the same reason. The f3 line is an error because you can't add an i8 and a String, and Rust can figure all that out without having to annotate f1 or f2.
I love Rust's typing because it's helpful and makes strong guarantees about the program's correctness. I'm not "anti-typing" at all. I'm just not a big fan of languages that make you annotate everything everywhere. Back when such arguments were in fashion, a pre-auto C fan might reduce my whole argument to "you don't like typing, newbie!", which would make me roll my eyes and hand them a lollipop.
FWIW, I think TypeScript's pretty great. I never like JS. I tolerated it, and could use it, but didn't enjoy it at all. TS is fun, though.
2 replies →
Puthon is so strongly typed it lets you assign a string to an integer variable, and or compare the two or add a float and an int. Or multiply an array by a number; something which gets overturned if you use numpy. Python's strong typing mostly boils down to some operator rejecting mixed types.
Python doesn't have variables in the C sense. It has pointers to objects (aka "names"), and the "=" is a pointer assignment operator.
So:
i isn't typed. It's a reference to a thing with a type, not a thing with a type itself. It's also pragmatic, in that 99.9% of cases, `1.5 + 2` has a completely obvious meaning. I don't recall ever seeing int+float being the source of a Python bug. Surely someone has, but I haven't.
> Python's strong typing mostly boils down to some operator rejecting mixed types.
Well... yeah. Turns out that plus duck typing is very nearly all most people want out of a type system. I went from Python to Rust and found nearly no difference in how they handle types, except Rust does it at compile time. Judging from the number of people I've seen make the same migration, that seems to be common. And yet no reasonable person makes claims that Rust is weakly typed, even when IMO it's basically Python but enforced at compile time.
1 reply →
Strongly typed is not a well defined term.
But by most people definitions, Python certainly is NOT strongly typed.
My take at a definition... Strongly typed languages make a serious effort to use the type system to prevent whole categories of bugs.
It kinda bites with the "dynamic typing" (a euphemism or marketing-speak for "weak typing") that Python/Ruby/JS implement. Sure some are adding typing now (trying to make big codebases in those languages more manageable), but it's always an optional add-on.
> I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped.
I'm not sure I would go that far, but I would definitely say that I remember many, many moments where a Python codebase hit critical mass and the amount of time I spent documenting and checking types exploded. It wasn't really about static, explicit typing, so much as "once my tools (IDE) are taken into account, how much time am I spending trying to reason about correctness?" Reasoning about types was the main contributor to that with Python before type annotations.
Last I tried, there's still often (not always) fighting with typing, mypy, pyright because of the dynamic nature you mention. I think the complaints about it are sometimes misinterpreted as "disliking types".
haven't seen this flamewar in a while. can't say I missed it. surprised people still argue about it, having written my first Python around 1.5.
for the record - I agree completely.
(glad people are over the unicode thing!)
> I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped.
I'm one of those, but what I mean is that there are no static types you (and the compiler) can reason about.
Moreover there's a difference between types as compiler bookkeeping, as in Fortran or C, and types as propositions about program behavior like in ML, which highly influenced modern type systems, including TypeScript, albeit Ocaml, F# and the Rust type system belong to the ML family.
> Python is strongly typed
Get the f*ck outta here.
> static, explicit typing
the kind of types that helps you reason and read the code. As opposed to the type you mostly don't have to think about anyway, which is complete missing the point.
> I don't recall anyone disliking types. Lots of people disliked static typing
Come on, that was very clearly what he was talking about. No need to be this pedantic.
[dead]
[flagged]
[dead]
> I don't recall anyone disliking types
> where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension.
hmm maybe you don't understand type-checking INSIDE IDE, NOT during runtime?
That is what the parent author means. Static vs dynamic typing is along the dimension of when the type is checked, and strong vs weak typing is a matter of how strongly bound names adhere to types. JS, for instance, is super weak here, you can assign a numerical value to something and in the next line re-assign it to a string, an array, or even a function object.
4 replies →
In 2004 we solved the types for JS with ECMAScript 4 (or ActionScript 2.0).
Unfortunately this was in the middle of browser wars, so no one cared about the standards and all of that work was lost like tears in rain.
Around that time I attended MS conference where they introduced IntelliSense and it was a forming experience for myself. You could do actual programming basically with <space>, <dot>, arrow keys and <enter>.
"x = " and there are only two variables in the scope with the same type so IDE will present them to you in a drop down and you can already think about the next line.
Fast forward to ~2015 when I'm working on Angular project. The whole idea feels like a caricature Chinese whispers of an OOP framework. Each component is divided into three files, all of them have to identify themselves using a magic string, and that string has to be manually entered into each file.
There are couple of type systems, like the one from Facebook, but no one is using them. And everyone claims that OOP and types are the thing of the past.
Part of that corelates to a joke I was making back in 2013, soon after Apple killed Flash and everyone started doing JS everywhere. Major companies where posting job offers for senior javascript devs asking for 5-7 years of experience. But someone who was doing JS for 7 years in 2012 has all his career focused around gluing together jquery plugins.
Anyway, I'm as well glad that we finally did a full circle and finally have some sanity in the industry...
> In 2004 we solved the types for JS with ECMAScript 4 (or ActionScript 2.0).
> Unfortunately this was in the middle of browser wars, so no one cared about the standards and all of that work was lost like tears in rain.
> Around that time I attended MS conference where they introduced IntelliSense and it was a forming experience for myself. You could do actual programming basically with <space>, <dot>, arrow keys and <enter>.
I think you’re off by at least 6-7 years. Visual Studio had autocomplete since at least version 6. And yes it was magical the first time you experienced it.
And by 2004 the browser wars where long over. That was the period when Microsoft left the web languishing on IE6 after destroying all competitors and then promptly disbanding their browser team. Firefox only got its name in 2004 and was released at the end of that year.
God, do you remember that presentation Google gave when they introduced Angular 2.0? I think it was December 2015. It was sooo bad that in my eyes it killed Angular's momentum almost completely. I am surprised that it is still around actually. Can't find it anywhere though. Google must've censored it of the internet :)
I joined a consultancy a few years ago and Angular is the de facto standard at most enterprises we work for; I'm as surprised as you are.
1 reply →
Angular is super used across the industry.
It's more common on consultancy than product companies.
1 reply →
There's been a pendulum swing of sort during my career: static languages like C++/Java, then dynamic ones like Python/Ruby/JavaScript, and now back toward typed languages like TypeScript/Rust/Swift.
My read is that people were never really against types: they were against type systems that got in the way. Older ones often weren't expressive enough, so you ended up writing verbose patterns just to appease the compiler.
That's why dynamic languages gave startups a sizable velocity edge for a while. Modern type systems (with optionals, unions/sum types, inference, etc.) are completely different.
To paraphrase a comment I once read here on Hacker News: I'll take static typing with sum types over dynamic typing, but I'll take dynamic typing over static typing without sum types...
The irony is that I got introduced to the ML type system in 1996, but the industry takes its sweet time to adopt ideas.
It's important to remember that at no point was there a pendulum swing per se, that is, only few actually ported their Java code to Python for example.
The discussions and articles online seemed to infer that, but that's uh. media bias? Hype? Things written about and things you read online are not the full story, is all.
That is a very charitable read. I remember plenty of dumbasses who said: I don't need a type system, cause I know what I am doing and I don't create bugs.
Type systems just used to be bad. Anything that forces you to use a class hierarchy to represent an "OR" type (sum types) is painful to work with. Modern languages like TypeScript / Rust / Swift / Kotlin that have sum types are dramatically much nicer.
Algorithm W is 40 years old and HM has vastly better ergonomics than TS's types.
Why certain approaches didn't catch on until recently, or ever, is an interesting thing to think about but "we didn't know how" is not the story here.
The "or" (and "and") types in TypeScript are set theoretic rather than algebraic, so they don't require wrapping and unwrapping. It seems to me that they are the ones with better ergonomics.
1 reply →
C also has sum types.
No if you're referring to unions and an enum, it isn't sum types.
I have personally had three conversations (2 online, 1 in person) where the other person has said, almost verbatim, “I have never had a typing error in JavaScript”. Two of these people were people whose work I respected, so it could not understand how they could possibly hold that position.
"I have never had a typing error in Javascript" — [Object object]
It isn't wrong exactly. JS is famous for generally just trying to do something semi random instead of giving you a typing error.
That's the difference between "having a typing error" and "having an error due to typing".
well kinda
You can go a long way with just javascript, eslint and prettier if you work solo, but IME work is a low-trust environment which means that either you're a wolf and you do what you want or you have to use C# and enable nullable checks.
Yeah, I think was algebraic + pattern matching that break the ghetto. Suddenly types were far more useful without going crazy like Haskell!
P.D: Before, the exposure of types was from C++/Java, and special C++ is always a horrible exponent of anything except how make a overly complex language.
Once you see what good application of types look like, is far better sell!
> algebraic + pattern matching
Functional programmers keep hyping up ADTs like this but the normie programmer doesn't care about ADTs or immutability. What really brought back static types was Golang & typescript, both have local variable type inference, good IDE support & other tooling, and (at least superficially) lighter weight syntax than Java. Normies don't care about algebraic types, pattern matching, immutability, referencial trasparency, type classes. What matters is libraries and tooling.
Now I'm just waiting for DependentTypeScript :-)
I would chose typescript over js, Python and perhaps ruby. but I would use Scheme over typescript. I would probably use f# or ocaml over Scheme for most projects.
it is not an either or.
And how compiled languages were out of fashion, now everything is getting rewritten into them again, thankfully.
I don't think ... serious people... argued that.
That's a bit hyperbolic so I'm sure I'm wrong, but I have an ace: if you point me at very smart people who argued against types I'm gonna say that they weren't serious. I think it's not possible, if you have the relevant experience of working on both typed and untyped codebases of at least moderate complexity with at least one collaborator, to come away seriously believing that the untyped way is superior (unless you were forced to use a really bad typed language, I guess). And arguing that untyped languages are better without that experience is also not serious, in the sense that anyone can unseriously say anything if they don't care about being well-informed enough to be right.
I worked with people who would consider themselves serious, and are still in the industry and doing fine. A few have certainly gone on to be more prominent and get paid a lot more than I am—not that it's a perfect measure of seriousness.
In the early days they would often say things like "but we have prop types, why use TypeScript", "why not use JSDoc" (this made no sense at the time), or "it's an exercise in needless complexity". It was really tough to sell them on TypeScript for years.
I think there are developers who are very goal-oriented with a narrow perspective on getting from point A to point B, and their understanding of the process isn't particularly holistic, rigorous, or geared towards external or knock-on factors like maintainability, performance, bugs, etc. They deal with it when circumstances force them to, and no sooner. Defining types is a complete waste of time to someone like that.
These people thrive where teams are primarily expected to just ship things, and in my experience they often hate needing to think about things like types, tests, or code quality beyond running a linter.
So, they're serious people in one school of thought. They contribute meaningfully to projects. I think they're a large constituent of the new class of vibe coders who laugh at you if you look at the code. That's fine, they're doing their thing, and there are more than a few ways to get programs into people's hands. That way just isn't the way I like to.
Serious developers can make a serious argument that you can get quality production-level code with other ways besides explicit enforced type systems (eg. that if you have good enough test coverage such explicit type systems are a redundant waste of time).
Obviously "production quality" varies greatly from shop to shop, but I think there's more legitimacy to the idea than you're giving it.
1 reply →
Look at some of the typing present in MS COM back in the IE5/6 days and we can discuss more. I can honestly tell you - I'll take untyped languages any day of the week over that clusterfuck.
Personally - I also think people really underestimate just how much the tooling around types has improved over the last 20 years.
If I'm having to try to look up the difference between iBrowserInterface6 and iBrowserInterface5 and iBrowserInterface4... (and yes - shit like this really did exist: https://learn.microsoft.com/en-us/windows/win32/api/shdeprec...)
And I have no tooling for autocomplete, and the docs are shoddy, and google is just coming on the scene...
People understandable want to throw their computer out the window.
Types are great. Some forms of them were not.
completely agree. but I felt like even then it was clear that types were a good idea and the implementations were not. For instance I started programming on Java 4 or 5 and the types were pretty bad---but still it was obviously the right way to go compared to JS or, god forbid, shell.
10 replies →
Why the past tense? COM is the main Windows API surface since Windows Vista, most Win32 C stuff is frozen in Window XP API surface, with minor improvements.
WinRT for all its pain points, is still COM, only with a different set of base interfaces, and using .NET metadata instead of classical COM type libraries.
This isn't a good example at all. Those interfaces are subtypes.
It's easy to say that now, but it used to be that all mainstream typed languages had absolutely terrible type systems that got in your way as much as they helped
Absolutely, TypeScript is remarkably expressive in my opinion. The inference and option to bail out with `any` is nice for some teams in some cases, too. They did an excellent job of making it accessible.
They're still right here in sibling comments
guess so. I still don't think their position is serious, but, that's just me.
was amusing to come back hours later and find out whether this comment ended up more upvoted or more downvoted, it was oscillating all day...
> I don't think ... serious people... argued that.
Static vs dynamic typing is no less ubiquitous in online forums over the decades than tabs vs spaces and vim vs emacs.
I feel like I see all of these debates far less than I used to? Well I don't see anyone arguing about vim and emacs anymore at all, and spaces have mostly won over tabs, and static typing has mostly won over dynamic, with the holdouts being comparative novices and people who program in less modern environments, like in academia and at smaller companies.
5 replies →
I've been writing code since the 80s, professionally since the mid 90s, in almost every major language, platform and operating system, from 8 bit microcontrollers to large scale web platforms.
So, not sure that counts as "serious" in your estimation, but I would definitely argue that dynamically typed languages are superior for a large class of problems.
Also, just a tip: it's usually better to be less sure of yourself, and seek to understand other's reasoning. It'll get you a lot farther than trying to convince everyone of how right you are.
If you're not sure why an experienced developer would hold an opinion different than yours, why not just ask?
....they did ...and... the camp still exists
well, as I said, I don't take them seriously :p
> Remember when people would argue about how types weren't worth the effort?
> if nothing else for how it's been able to popularize types.
This is such an odd, javascript dev take.
It's maybe a bit of a startup-world, HN-blinkered assessment...but that's where we're talking, isn't it?
Even before JS became the language for everything, there was a good chunk of time - maybe between 2005 and 2015? - when Python and Ruby were dominant in this environment, and this dismissive attitude towards static typechecking was similarly dominant.
Of course in the enterprise space everyone was using Java, and in the systems space or game dev space everyone was using C++. But those worlds get a lot less airtime here.
Plus everyone on HN is a good little pg disciple, and Lisp is dynamically typed. If the One True Language doesn't need static typechecking (though SBCL offers some very helpful heuristics) surely it's not worth it. Right? Right?
> Lisp is dynamically typed.
Ish.
SBCL aggressively infers types wherever possible. It can do dynamic typing with tags of course. You can also write it with 100% static types.
Dynamic typing isn't a defining feature of Lisp style languages (even GC isn't necessary). Some historic Lisps and modern ones are 100% statically typed.
2 replies →
> Lisp is dynamically typed
"Lisp" isn't a single language. Arguably the language people speak about when they say Lisp without qualifier, ANSI CL, allows conforming implementations (e.g. SBCL) to offer gradual typing, not just heuristics.
I'm a Haskell and FP nerd as well. I just meant the argument and the popularity inside the JS/TS world, which is fairly significant. I think the world is a better place because of the widespread adoption of TS over JS.
dhh is still not very fond of it. To each their own.
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
> TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become `any`. No thanks!
That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.
Types are a safeguard, they rule out certain errors. So using them is mostly for maintainability, and especially in large codebases and teams that becomes a thing.
I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
7 replies →
> so little joy to my development experience, and quite frequently considerable grief
Me when my manager asks to complete the JIRA ticket.
I'm a Ruby enthusiast - Sorbet is one of the best things since sliced bread to happen to the ecosystem. matz is pushing hard on static typing as part of the standard Ruby ecosystem as well.
3 replies →
these painpoints seem moot in a world where AI agents are writing all the code.
2 replies →
I mean he's a Ruby developer. He has to delude himself that static typing is a waste of time.
I've seen TS hurt more than help in many cases, because people think types define the world, and then they get malformed JSON (or just a new structure) and their world crumbles.
Yes, it's a skill issue, but oh dear the amount of developers who have that issue.
How does TS make these situations worse? Seems to me that it helps a ton with identifying and fixing these issues. Either you can get away with just replacing the assertions with type guards, or you'll have to refactor some stuff (which is also much easier with types).
At worst, TS can only really be as bad as JS, no?
The illusion of safety.
”Look the type says the data has this shape”, but it doesn’t. This has led to so many cases of ”no data validation” in my experience, how people solve that is usually then with zod, and now you have added a massive runtime dependency instead of local validation.
2 replies →
I still do argue that for JS. I have yet to see it worth the effort other than making things feel comfortable for former OOP devs coming from other languages.
edit: the downvote button HN is not for disagreeing with comments or unpopular opinions. please dont turn hn into reddit.
You need to meet some people who argue that types are positively bad!
people didn't argue against types, people argued against putting lipstick on a pig.