5 ms·

Programming language design took a wrong turn with these extremely complicated type systems. They end up hurting developer productivity, and you spend more tim

Programming language design took a wrong turn with these extremely complicated type systems. They end up hurting developer productivity, and you spend more time fiddling with types than solving the problem at hand. We should be focusing on more effective forms of abstraction instead of types.

deleted 3y ago
[deleted]
agumonkey 3y ago
> more effective forms of abstraction instead of types do you have any in mind ? I often think about a blend of functional and OO as 'protocol graphs' but it's a faint idea for now
- peepeepoopoo33 3y ago
  Array programming is an extremely powerful paradigm that is criminally underused outside of data science applications. It also feels like the full power of array programming hasn't been explored yet.
  - mostlylurks 3y ago
    Array programming doesn't really have much effect on how relevant a type system is for a particular language. At most it will let you make operations generic over the rank of the inputs (scalar, array, array of arrays, etc), which is nice, but the scalar values at the bottom of that hierarchy are subject to all the same factors that motivate the type systems present in any other modern language.
    - peepeepoopoo33 3y ago
      My point is that academic PL research has diverged significantly from the kinds of problems people are really facing. That's why we've seen array programming emerge organically to address a direct industry need, and it didn't come from the PL crowd at all.
      - deleted 3y ago
        [deleted]
      - joaogui1 3y ago
        APL started at Harvard (though it developed more in IBM) and even nowadays there's the ARRAY workshop co-located with one of the main PL conferences. The thing is that while array programming is amazing for some specific problems it's not going to help you make sure that you don't have memory errors, race conditions, or wrong states in your program
        peepeepoopoo33 3y ago
        The implementations of array programming in use today are quite different from APL, and they all came from industry. > it's not going to help you make sure that you don't have memory errors, race conditions Not only does array programming abstract away those kinds of errors, it also solves the problems that I care about: code that is faster, more expressive, and easier to read and write. Unwieldy type systems do not help me solve those problems.
        maxbond 3y ago
        I can see how array programming helps with certain memory errors, but I don't think it helps with race conditions. Whereas eg Rust ownership, borrowing, and lifetimes eliminate one class of race conditions (data races) in safe code. Type systems also enable optimizations that do make code faster. Eg monomorphization. Consider that JITs makes untyped code faster by inferring types at runtime. See also this comment https://news.ycombinator.com/item?id=37376010 https://news.ycombinator.com/item?id=37376010 I honestly can't make heads or tails of the idea that type systems don't help make code more expressive? They allow you to express your precise intent in a way that's legible to both humans and the compiler.
        dang 3y ago
        I like (and share) your enthusiasm for array programming! but can you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0&query=community%20identity%20by:dang https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme... Also, can you please stop using trollish usernames? Those aren't allowed either, because they basically troll every thread the account posts to. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=true&page=0&query=by:dang%20trollish%20username https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
- maxbond 3y ago
  This protocol graph idea sounds intriguing. I'd love to hear more about it if you're interested in sharing.
maxbond 3y ago
What languages are you talking about? I find that the weaker the type system the more I feel fiddling with it is a waste, eg Python, but I don't feel that way when I'm working with a strong type system that can not only help eliminate bugs but aid the compiler in analysis and actually deliver a better artefact, eg Rust. LSPs are a sort of middle ground where I derive a lot of the value from, and even weak type systems really help the analysis of the LSP. They make me immensely more productive. I've been writing a lot of TypeScript lately, and I may not have taken the plunge to the frontend if LSPs hadn't made it dramatically easier. So in that case the impact on my productivity is +100%.
- kristopolous 3y ago
  I'm not the parent but at least for me, my #1 complaint is "whiny computer". Especially when dealing with someone else's code, it can be a ceremonial roadblock for moving data around that could easily be processed without issue but artificial constraints in order to service an orthodoxy have been erected to make things needlessly more brittle. In the name of reducing bugs, it in practice can often impose workarounds that increase the chance the confusion and more bugs. This isn't always the case but most of the time things are built in incompetent hands (including my own). Accommodating for this reality is probably the better move. Imposition of absolutist rules doesn't improve the behavior of incompetency, it just makes it more subversive and the defects it creates more insidious
  - maxbond 3y ago
    Hmm interesting. Are these projects that were originally untyped but then gradually typed later? I ask because I've not really encountered that, the most I've had to do is add asserts or ifs to help explain to the typechecker something that I could see as a human. A few times in a gradually typed language I've needed to add an ignore to a line. But it's been rare in my experience. I try not to think of it as whining, I try to think of it as the type checker helpfully pointing out, "hey, you haven't done your due diligence here." I ran into this advice when learning Rust and it made it much more pleasant. In the same way that you might chase a series of failing tests to finish a task, you can chase a series of type warnings. I have them integrated into my editor, so usually the "series" is length 1 because I'm knocking them out as they arise. The projects I've worked with that were previously untyped (Python SaaS backends), I never actually ran the type checker on the entire source code. But if I had a megabyte of type errors that weren't really going to provide value to the business, yeah that would feel like a waste of time. Unless we were having serious quality issues and it was between annotating the entire codebase and rewriting it from scratch, I'd leave well enough alone - it's a tool, not a religion. But the new code I'm checking in, that's getting annotated for sure. I don't really see types as arbitrary absolutist rules. They're the semantics of the language, they're the rules you're following whether you have a typechecker or not. And if you violate them you're gunnuh get bugs and crashes regardless. I too am a flawed human who frequently makes mistakes, and I like having them caught immediately, before I've even checked my code in.
packetlost 3y ago
[flagged]
systems 3y ago
complexity doesn't go away, you distribute it you either create a complex program, with simple language constructs, or a simple program with complex language constructs if you use only the simplest types, your program will be very complex, if you put all the complexity in types, your type system will be very complex you need to balance things i think OOP is the extreme where all the complexity is in the Object system (or types system) functional programming with complex types, i think give a nicer balance, where some logic goes into the program flow and some goes into types anyway balance is everything, keep things balanced , dont lean too much into any direction
- dietr1ch 3y ago
  Well, intrinsic complexity can be split, but artificial complexity might be added on top of it. Languages and libraries that are well designed and compose better end up being great at taming complexity. Functional languages are made to compose better, but their popularity is a hint that they are not that simple to use effectively.
qudat 3y ago
Similar arguments here: https://bower.sh/typescript-terrible-for-library-developers https://bower.sh/typescript-terrible-for-library-developers As a library developer I spend substantially more time on making the types right than the actual implementation. It can be brutal at times.
- IshKebab 3y ago
  Think of how much time you'd have to spend writing trivial tests instead if you didn't have an automated system to detect basic mistakes like typos and type confusion! I guess you can complain that Typescript forces you to spend time making sure your code meets a minimal bar of correctness...
  - meheleventyone 3y ago
    Library developers in particular should see type complexity as a warning that something isn’t great in the design. This seems largely an issue for libraries migrating to TS which isn’t a surprise.
PartiallyTyped 3y ago
I disagree. These "complicated" type-systems enable fearless refactoring and give you guarantees without cluttering your code with validation checks because, well, there is the guarantee that faulty states are not representable.

deleted 3y ago

[deleted]

agumonkey 3y ago

> more effective forms of abstraction instead of types do you have any in mind ? I often think about a blend of functional and OO as 'protocol graphs' but it's a faint idea for now

peepeepoopoo33 3y ago
Array programming is an extremely powerful paradigm that is criminally underused outside of data science applications. It also feels like the full power of array programming hasn't been explored yet.
- mostlylurks 3y ago
  Array programming doesn't really have much effect on how relevant a type system is for a particular language. At most it will let you make operations generic over the rank of the inputs (scalar, array, array of arrays, etc), which is nice, but the scalar values at the bottom of that hierarchy are subject to all the same factors that motivate the type systems present in any other modern language.
  - peepeepoopoo33 3y ago
    My point is that academic PL research has diverged significantly from the kinds of problems people are really facing. That's why we've seen array programming emerge organically to address a direct industry need, and it didn't come from the PL crowd at all.
    - deleted 3y ago
      [deleted]
    - joaogui1 3y ago
      APL started at Harvard (though it developed more in IBM) and even nowadays there's the ARRAY workshop co-located with one of the main PL conferences. The thing is that while array programming is amazing for some specific problems it's not going to help you make sure that you don't have memory errors, race conditions, or wrong states in your program
      - peepeepoopoo33 3y ago
        The implementations of array programming in use today are quite different from APL, and they all came from industry. > it's not going to help you make sure that you don't have memory errors, race conditions Not only does array programming abstract away those kinds of errors, it also solves the problems that I care about: code that is faster, more expressive, and easier to read and write. Unwieldy type systems do not help me solve those problems.
        maxbond 3y ago
        I can see how array programming helps with certain memory errors, but I don't think it helps with race conditions. Whereas eg Rust ownership, borrowing, and lifetimes eliminate one class of race conditions (data races) in safe code. Type systems also enable optimizations that do make code faster. Eg monomorphization. Consider that JITs makes untyped code faster by inferring types at runtime. See also this comment https://news.ycombinator.com/item?id=37376010 https://news.ycombinator.com/item?id=37376010 I honestly can't make heads or tails of the idea that type systems don't help make code more expressive? They allow you to express your precise intent in a way that's legible to both humans and the compiler.
        dang 3y ago
        I like (and share) your enthusiasm for array programming! but can you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0&query=community%20identity%20by:dang https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme... Also, can you please stop using trollish usernames? Those aren't allowed either, because they basically troll every thread the account posts to. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=true&page=0&query=by:dang%20trollish%20username https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
maxbond 3y ago
This protocol graph idea sounds intriguing. I'd love to hear more about it if you're interested in sharing.

maxbond 3y ago

What languages are you talking about? I find that the weaker the type system the more I feel fiddling with it is a waste, eg Python, but I don't feel that way when I'm working with a strong type system that can not only help eliminate bugs but aid the compiler in analysis and actually deliver a better artefact, eg Rust. LSPs are a sort of middle ground where I derive a lot of the value from, and even weak type systems really help the analysis of the LSP. They make me immensely more productive. I've been writing a lot of TypeScript lately, and I may not have taken the plunge to the frontend if LSPs hadn't made it dramatically easier. So in that case the impact on my productivity is +100%.

kristopolous 3y ago
I'm not the parent but at least for me, my #1 complaint is "whiny computer". Especially when dealing with someone else's code, it can be a ceremonial roadblock for moving data around that could easily be processed without issue but artificial constraints in order to service an orthodoxy have been erected to make things needlessly more brittle. In the name of reducing bugs, it in practice can often impose workarounds that increase the chance the confusion and more bugs. This isn't always the case but most of the time things are built in incompetent hands (including my own). Accommodating for this reality is probably the better move. Imposition of absolutist rules doesn't improve the behavior of incompetency, it just makes it more subversive and the defects it creates more insidious
- maxbond 3y ago
  Hmm interesting. Are these projects that were originally untyped but then gradually typed later? I ask because I've not really encountered that, the most I've had to do is add asserts or ifs to help explain to the typechecker something that I could see as a human. A few times in a gradually typed language I've needed to add an ignore to a line. But it's been rare in my experience. I try not to think of it as whining, I try to think of it as the type checker helpfully pointing out, "hey, you haven't done your due diligence here." I ran into this advice when learning Rust and it made it much more pleasant. In the same way that you might chase a series of failing tests to finish a task, you can chase a series of type warnings. I have them integrated into my editor, so usually the "series" is length 1 because I'm knocking them out as they arise. The projects I've worked with that were previously untyped (Python SaaS backends), I never actually ran the type checker on the entire source code. But if I had a megabyte of type errors that weren't really going to provide value to the business, yeah that would feel like a waste of time. Unless we were having serious quality issues and it was between annotating the entire codebase and rewriting it from scratch, I'd leave well enough alone - it's a tool, not a religion. But the new code I'm checking in, that's getting annotated for sure. I don't really see types as arbitrary absolutist rules. They're the semantics of the language, they're the rules you're following whether you have a typechecker or not. And if you violate them you're gunnuh get bugs and crashes regardless. I too am a flawed human who frequently makes mistakes, and I like having them caught immediately, before I've even checked my code in.

packetlost 3y ago

[flagged]

systems 3y ago

complexity doesn't go away, you distribute it you either create a complex program, with simple language constructs, or a simple program with complex language constructs if you use only the simplest types, your program will be very complex, if you put all the complexity in types, your type system will be very complex you need to balance things i think OOP is the extreme where all the complexity is in the Object system (or types system) functional programming with complex types, i think give a nicer balance, where some logic goes into the program flow and some goes into types anyway balance is everything, keep things balanced , dont lean too much into any direction

dietr1ch 3y ago
Well, intrinsic complexity can be split, but artificial complexity might be added on top of it. Languages and libraries that are well designed and compose better end up being great at taming complexity. Functional languages are made to compose better, but their popularity is a hint that they are not that simple to use effectively.

qudat 3y ago

Similar arguments here: https://bower.sh/typescript-terrible-for-library-developers https://bower.sh/typescript-terrible-for-library-developers As a library developer I spend substantially more time on making the types right than the actual implementation. It can be brutal at times.

IshKebab 3y ago
Think of how much time you'd have to spend writing trivial tests instead if you didn't have an automated system to detect basic mistakes like typos and type confusion! I guess you can complain that Typescript forces you to spend time making sure your code meets a minimal bar of correctness...
- meheleventyone 3y ago
  Library developers in particular should see type complexity as a warning that something isn’t great in the design. This seems largely an issue for libraries migrating to TS which isn’t a surprise.

PartiallyTyped 3y ago

I disagree. These "complicated" type-systems enable fearless refactoring and give you guarantees without cluttering your code with validation checks because, well, there is the guarantee that faulty states are not representable.