| ▲ | adamddev1 4 hours 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. |
|
| ▲ | kstrauser 4 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | _flux 2 hours ago | parent | next [-] | | 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. | | |
| ▲ | jt2190 2 hours ago | parent | next [-] | | > 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”? | | |
| ▲ | dtech 2 hours ago | parent [-] | | There's a lot of nuance to that statement. Most languages, including e.g. Java or Typescript, would not be strongly typed according to your definition, because their type system is "unsound": there are known cases where the type system does not protect you and the types are wrong. We generally still call these languages strongly typed. In Typescript this is by design. The most obvious is array variance. Typescript makes them covariant because that's what a lot of sane TS and JS code uses them as, but they should be invariant because you can write to them. Example: const dogs: Dog[] = []
// A sound type system would error here,
// but there's too many useful cases where you want to do this
const animals: Animal[] = dogs
animals.push(new Cat())
animals[0].bark() // runtime TypeError here
| | |
| ▲ | arcfour an hour ago | parent | next [-] | | Okay, so I'm not crazy for thinking that declaring an empty, typed array as `const` and then writing/pushing to it is confusing/feels wrong. I didn't go to college for software engineering or anything so when I ran into that for the first time I assumed there must have been some good academic reason that was simply beyond me as to why it was done that way. It turns out that no, it's just as weird to those that do have the formal background, boy am I feeling vindicated ;) | |
| ▲ | bennettpompi1 2 hours ago | parent | prev | next [-] | | I may be missing something, but your example doesn't typecheck? class Animal { }
class Dog extends Animal{
bark(){return 1}
}
class Cat extends Animal{
bark(){return 1}
}
const dogs: Dog[] = []
const animals: Animal[] = dogs
animals.push(new Cat())
animals[0].bark() <<<<< "Property 'bark' does not exist on type 'Animal'."
| | | |
| ▲ | 28 minutes ago | parent | prev | next [-] | | [deleted] | |
| ▲ | jt2190 2 hours ago | parent | prev [-] | | I would have called this “strictly typed” I think, not “strongly”. Maybe my terminology is off. |
|
| |
| ▲ | kstrauser 2 hours ago | parent | prev [-] | | 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: int main() {
int i = 23;
auto j = i;
printf("i = %d, j = %d\n", i, j);
}
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: fn foo1() -> i8 {
23
}
fn foo2() -> String {
"foo2".into()
}
fn main() {
let f1 = foo1();
let f2 = foo2();
let f3 = f1 + f2;
println!("Hello, world!");
}
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. | | |
| ▲ | delta_p_delta_x an hour ago | parent [-] | | This is called automatic type inference, and it is a big feature of functional programming languages, many of which are very strongly typed. Also, for the record, C++ gained type inference about a decade and a half ago. In C++ one can declare a completely typeless lambda: auto callsAdd = [](auto x, auto y) { return x + y; }
And the programmer need never specify what x and y are, as long as there exists a reachable declaration of operator+ that has two arguments that accepts whatever x and y resolve to, at instantiation time (which is compile time). |
|
| |
| ▲ | tgv 2 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | kstrauser an hour ago | parent [-] | | 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 = 23 # Create an int(23) object and store its address in i
i = "foo" # Create a str("foo") object and store its address in i
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. |
| |
| ▲ | baq an hour ago | parent | prev | next [-] | | 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!) | |
| ▲ | librasteve 11 minutes ago | parent | prev | next [-] | | [flagged] | |
| ▲ | skybrian 2 hours ago | parent | prev | next [-] | | [dead] | |
| ▲ | sysguest 3 hours ago | parent | prev [-] | | > 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? | | |
| ▲ | delta_p_delta_x 3 hours ago | parent [-] | | 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. | | |
| ▲ | MrJohz 3 hours ago | parent [-] | | That's also true of Python, though, which is traditionally considered a strongly typed language. I'm increasingly convinced that "strong/weak" has no useful meaning. Some people regularly use it interchangeably with "static/dynamic", others use it to vaguely refer to how much casting exists in a language, or how easy it is to transmute a value of one type into a value of a different type. There is no academic definition at all. Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior. In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing. |
|
|
|
|
| ▲ | nicoburns 2 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | JoeyJoJoJr an hour ago | parent | prev | next [-] |
| 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. |
|
| ▲ | mamcx 2 hours ago | parent | prev | next [-] |
| 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! |
|
| ▲ | bbg2401 3 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | wk_end 2 hours ago | parent | next [-] | | 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? | | |
| ▲ | dismalaf 2 hours ago | parent | next [-] | | > 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. | |
| ▲ | BoingBoomTschak 2 hours ago | parent | prev [-] | | > 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. |
| |
| ▲ | adamddev1 3 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | ajkjk 4 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | steve_adams_86 4 hours ago | parent | next [-] | | 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. | |
| ▲ | horsawlarway 4 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | ajkjk 4 hours ago | parent | next [-] | | 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. | | |
| ▲ | horsawlarway 3 hours ago | parent | next [-] | | > but still it was obviously the right way to go compared to JS or, god forbid, shell. I just don't think this is true. Frankly - it's hard to argue this at all (even today) given that JS is the dominate language on the planet, and it lacks types... as does python, which had a reputation for decades as THE language to use to teach new folks to code. Or take PHP which dominated server development for a LOOONG time: also lacks types. Ruby on Rails has a wonderful reputation as the "get shit done" framework: no types. Types are good for modern software companies, where code size has ballooned up very high (common to work on a codebase with hundreds of thousands of lines) or teams are large (50+ developers) and terrible if you just want to hammer out something that works as a solo dev. Do I like types today? Sure - the tooling is solid, and I work on large codebases with large teams. Did I like types as a solo dev at 3 person startup? no. | | |
| ▲ | jazzypants an hour ago | parent | next [-] | | It's still useful for things like onboarding the fourth person to your start-up. Good types get you half the way to good documentation. | |
| ▲ | dprkh 3 hours ago | parent | prev | next [-] | | > as does python, which had a reputation for decades as THE language to use to teach new folks to code I am very perplexed by this. I am going through Neetcode's DSA course where he explains what RAM and arrays are, but then he goes on to say something like "but since we are going to use Python, none of this applies." Personally, I learned the most about how software really works from reading The Rust Programming Language. It not only teaches you how to program in Rust, but also how memory works, what a string really is, etc. | |
| ▲ | esafak 40 minutes ago | parent | prev [-] | | Those languages dominated because they were simple. Then they grew, and their users grew up, and realized that worse is better. At a startup you can choose even fancier languages, since nobody is stopping you! |
| |
| ▲ | TedDoesntTalk 3 hours ago | parent | prev [-] | | Java has a lesson of what can go wrong with types, just as parent says. That example is dates and times. So many types… And before Java finally settled on what we have today, we had 3rd-party libraries like jodatime that tried to fix it. I guess it’s in a good state today, but it took a LocalDateTime.MAX to get there. I mean an Instant.MAX. No, I mean an OffsetDateTime.MAX. No, I mean new Date(Long.MAX_VALUE). Oh wait I meant new Timestamp(Long.MAX_VALUE). No, I mean LocalTime.MAX. I’ll stop now, but i could go on. |
| |
| ▲ | nh23423fefe 2 hours ago | parent | prev [-] | | This isn't a good example at all. Those interfaces are subtypes. |
| |
| ▲ | ChadNauseam 4 hours ago | parent | prev | next [-] | | 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 | | |
| ▲ | steve_adams_86 4 hours ago | parent [-] | | 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. |
| |
| ▲ | mrkeen 3 hours ago | parent | prev | next [-] | | They're still right here in sibling comments | |
| ▲ | hombre_fatal 4 hours ago | parent | prev | next [-] | | > 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. | | |
| ▲ | ajkjk 4 hours ago | parent [-] | | 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. | | |
| ▲ | asa400 3 hours ago | parent | next [-] | | Are the banks and trading firms that use e.g. Clojure/Elixir/Erlang/Python "comparative novices" or "less modern", whatever that means? These are some of the most sophisticated shops I've ever seen, doing some serious software engineering. I like static types as much as the next person and have written probably more Rust and Scala than anything else, but this seems maybe a bit of a gross generalization. | |
| ▲ | hombre_fatal 4 hours ago | parent | prev | next [-] | | Yeah, we are definitely past the hey day of these debates, though you can still find them. e.g. Gradual typing was since added to PHP and Python which ended some debate like how linting tools shut down a lot of whitespace debates. | |
| ▲ | alserio 3 hours ago | parent | prev [-] | | Spaces over tabs? Since when? | | |
| ▲ | ajkjk 3 hours ago | parent [-] | | i could be wrong, but it was enforced as the default at several places I worked, and most editors now have the option of the tab key inserting spaces to bridge the gap. (I don't care about the actual debate; just, I thought I had noticed it had mostly gone in this direction) |
|
|
| |
| ▲ | claytongulick an hour ago | parent | prev | next [-] | | 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? | |
| ▲ | samtheprogram 4 hours ago | parent | prev | next [-] | | ....they did ...and... the camp still exists | | | |
| ▲ | 4 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | chem83 4 hours ago | parent | prev | next [-] |
| dhh is still not very fond of it. To each their own. https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701... |
| |
| ▲ | tiffanyh 4 hours ago | parent | next [-] | | > 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. | | |
| ▲ | hvb2 3 hours ago | parent | next [-] | | 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 | | |
| ▲ | egorfine 3 hours ago | parent [-] | | > Types are a safeguard, they rule out certain errors I have migrated to TypeScript just about a year ago and it's my third try to migrate to TS from JS during the last decade and finally a successful one. While TS went a long road since the first versions which were incredibly hostile, my rewrite of a large codebase from js to ts revealed exactly zero type-related bugs. | | |
| ▲ | overfeed 2 hours ago | parent [-] | | eons ago, I migrated a frontend to Typescript and caught a lot of type-related bugs[1]. It was a 5kLoC, fast-moving productized prototype written by a team of 5. I won't ever do dynamic-typed plain Javascript in a team ever again, type-checker is superior to human code-reviews when it comes to catching potential bugs. Then again I prefer codebase stability of clever code or "expressiveness" 1. 20% were type-coercion bugs, 30% were non-boolean values being passed to boolean-named fields (with some overlap with the former). Linters have come a long way, but compile-time type-checking is better in almost every way. |
|
| |
| ▲ | dymk 2 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | matltc 32 minutes ago | parent [-] | | Really? Matt is pushing for it now? Dang. Might try Sorbet out. What IDE/LSP do you use? I was on VSCode/ruby-lsp and disabled sorbet, but after working with Zod, I became quite intrigued with the value of letting the schema do a lot of the guarding. I was under the impression that things like Crystal (statically typed Ruby) were not in vogue, and that the reason no one was moving toward static typing was because Matz did not give his blessing. (Just checked sorbet landing page, looks like it's mainly/only for fn signatures?) |
| |
| ▲ | aaronvg 3 hours ago | parent | prev | next [-] | | these painpoints seem moot in a world where AI agents are writing all the code. | | |
| ▲ | recursive an hour ago | parent | next [-] | | Type declarations can help an LLM in the same way they help people. | |
| ▲ | overfeed 2 hours ago | parent | prev [-] | | That world will never be. Humans will always be writing some code, at least for as long as I live and breathe. |
| |
| ▲ | 3 hours ago | parent | prev [-] | | [deleted] |
| |
| ▲ | IshKebab 19 minutes ago | parent | prev [-] | | I mean he's a Ruby developer. He has to delude himself that static typing is a waste of time. |
|
|
| ▲ | austinthetaco 3 hours ago | parent | prev [-] |
| 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. |
