6 ms·

Static types are the new religion, like OOP was in the 90s. Types solve 2% of programming errors. They lead to coupling for the sake of the compiler, and make

Static types are the new religion, like OOP was in the 90s. Types solve 2% of programming errors. They lead to coupling for the sake of the compiler, and make code harder to change, harder to write, and often needlessly constrain the utility of the code where they're applied. But they do make the IDE code-completion go, so there's that.

iLemming 7y ago
Yeah, sometimes I look at some Typescript or Scala code and feel like I don't even understand what the heck they are trying to build anymore. Very often it feels like they're "elegantly" trying to solve some made-up, bullshit problems for some questionable gain. Feels like bureaucracy for the sake of bureaucracy. Totally like OOP shit that we're still trying to make sense of, like: public abstract class Ellipse2D extends RectangularShape What's the problem? Ellipses are rectangles with some extreme rounded corners. That's exactly how Euclid described them.
- hota_mazi 7y ago
  You're aware that it's possible to write bad code in any language, even Clojure, right?
  - hellofunk 7y ago
    Totally agree, functional programming, and certainly the kind of programming you do with clojure, can get just as messy and far away from your goals as object oriented code. Clear, organized, well-architected code, in any language, is the skill that takes a long time to develop. I do not personally find clojure makes this any easier than in any language.
    - iLemming 7y ago
      > I do not personally find clojure makes this any easier than in any language. Surprisingly, it does for me. After using many different languages, I find myself more productive in Clojure than in any other language I have used before. Every language I used before Clojure left a dent in my mental ability to appreciate what I do. It's not a single favorite PL of mine, but most other programming languages make me feel bored and not interested after a year or so of using them. They have so many inconsistencies and quirks that you slowly succumb to the inevitable - you become a hostage. Your language of choice becomes your mental prison. Your hobby becomes this thing where you dig up yet some another poorly documented inconsistency and brag about it to your colleagues and friends. You become an expert from burning too often and too much. The language becomes your identity because you've seen too many ugly parts of it. You have no idea how many times I had to fight my anxiety and depression and seriously thought about leaving the field for good. Learning Clojure has liberated me; it allowed me to maintain focus and put in use all the good things and patterns I learned over the years. In other languages, sometimes you have to bend over backwards to create something clean. Sometimes you have to build this colossal cathedral that requires enormous scaffolding just to hold its own weight, and you can't even remove the scaffolding, and you call that "an elegant solution."
      - tomp 7y ago
        I'm a Programming Language enthusiast, currently making my own language. I'm really curious what makes Clojure different - it's pretty much the most loved language among its proponents (i.e. people love e.g. Rust and Go as well, but not as much as those who love Clojure, love Clojure). Is there any very Clojure-y code you can point to, that would showcase it? Is it just the libraries - collections, concurrency primitives - that could be replicated in another language? It's can be just homoiconicity, as that's just Lisp, but it could definitely be a big part of it... Do you have any ideas what any other language (e.g. Python, TypeScript, Go, Rust, Julia, Haskell, OCaml) would need to change to make you as productive as Clojure?
        fnordsensei 7y ago
        Since there are many answers already, I won’t elaborate too much. I just want to emphasize one thing: people mention immutable data structures as a default a lot, and sure, they’re great. However, someone might turn around and say, “well, I can pull in a lib with immutable data structures in $lang if I want to.” It needs to be highlighted that the real game changer is an /ecosystem of libraries/ built entirely out of immutable data structures. That’s not something that can be engineered as needed.
        biggidywiggidy 7y ago
        It's not one thing. It's many, many things. Each one, on their own, is good, but not a game changer. It's how they all come together in a consistent, well designed whole. This union is idiomatic. Sure you can do all this stuff in other ways, elsewhere. But there is so much ceremony. Clojure is opinionated in a good way that makes nice things succinct and idiomatic. So you will get many different answers. They are all true. And they all come together. The whole is very much greater than the sum of the parts.
        yonki 7y ago
        I have started programming when I was about 13-14, so it's half of my life now. Honestly, I never wanted to be a programmer. More of a writer/speaker/culture animator. I found Clojure in my first years of learning programming and, from start, it felt, like the only language that was really thought through, before creation. Clojure is the best because its syntax (or lack of thereof) along with data structures, namespaced keywords, specs, and whatnot, allows me to think properly. No other language gives me tools to think so clearly and plainly. I spent lot of time with JavaScript, some Python, some Ruby, a bit of Haskell. None of those really cares about giving you proper tools to think. When I need to use a language different than Clojure it's a burden now because I still think in Clojure. Or: I try to analyze and build a model of my domain without thinking about computers. The best programming language for that is Clojure. Other languages make you think about computers and, for me, that's waisted time
  - didibus 7y ago
    This has been something I've been trying to answer and can't arrive at a conclusion. I can't tell if I happen to have lucked out for the first time ever working with really good engineers, and that's why the Clojure code bases I currently work on are overall better. Or if it has anything to do with Clojure itself. From my prior work experience: Scala, Java, C#, JavaScript, ActionScript 3, C++; the code bases were always kind of crap. Everything was always called "legacy code", even if it was something that we had built just the year before. Similarly, in the open source, or even language core, things were always deprecating one after another, new release introducing breaking changes, and you had to constantly play the upgrade and refactor game to keep things working. That in turn contributed to making our own code bases so called "legacy", as the framework used even a few months back is being deprecated, or libraries you depend on that you can't upgrade to the newest release without breaking everything so you stick to outdated dependencies. None of that happens in Clojure, things are mostly stable for decades.
  - iLemming 7y ago
    Look, I'm not trying to bash on static typing. I like type systems. I love Haskell's, for example. I missed static type checker in every single dynamically typed language, and Clojure is not an exception. That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable. Sometimes, dynamically typed systems make absolute sense, especially in the context of homoiconic language like Clojure, where you have a "true" REPL. An analogy I can think of is wired headphones vs. Bluetooth headphones. Audiophiles would vehemently argue that you cannot deliver quality sound via wireless, and all professionals use wired headphones. But sometimes, wireless headphones are what you need - they grant you some freedom, for a small price - you have to charge them, you have to be close the source all the time, there's interference, etc. But at the end of the day, I rather charge them once in a while and enjoy the music. After using Clojure for some time, now, whenever I need to program in a statically typed language - it feels like I'm a traveler, passing through a series of checkpoints in medieval China or something. Too much ceremony. Perhaps I'm just not smart enough to solve puzzles imposed by a type system over and over again. Maybe the simplicity that Clojure offers allows me to stay dumb and focused on the task at hand, and enjoy the ride.
    - hota_mazi 7y ago
      > That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable. That was never the claim, though. It's possible to write anything in any language, witness the millions of lines of code that are written in PHP or FORTRAN today. The question is trying to determine if there are characteristics of programming languages (such as their type system) that make achieving these goals easier, and which also possess other nice attributes (such as making the code easier to refactor and maintain, easier to navigate or learn by new hires, etc...). In my experience, dynamically typed systems are harder to refactor, harder to understand, require more cognitive load to understand them, and are typically slower than statically typed languages. And because of the absence of type annotations and the 100% reliance on the (hoped) existence of tests, many developers simply decide not to refactor dynamic code for fear of breaking it, which leads to much more pronounced code rot with dynamically typed languages. > Maybe the simplicity that Clojure offers allows me to stay dumb and focused on the task at hand, and enjoy the ride. I'd argue the opposite: dynamically typed languages require you to hold a lot more stuff in your head (the types and what each object is and what they can do) whereas type annotations allow you to focus on more important things.
terminaljunkid 7y ago
> Types solve 2% ....... Vastly understated in my experience. Even trivial python programs contain errors that could be prevented with a trivial type system like Go's And performance. Not being fast enough is a bug. Consuming much more energy is a bug, in my book. Sufficiently expressive type systems are better than dynamic typing. They prevent so many errors, especially in FP-inspired high level data transformation functions. I am saying this as a person who doesn't even like most of FP. (You can infer from my comment history).
- j88439h84 7y ago
  > like Go's or Python's. It even has generics.
- didibus 7y ago
  FYI: Clojure has types for performance, but not for static checking. They're called type hints: https://clojure.org/reference/java_interop#typehints https://clojure.org/reference/java_interop#typehints
hellofunk 7y ago
I don’t know what percentage of errors are caught by static typing, but I do know what percentage of my time has been saved by switching to a statically typed language. I love clojure, but I spent at least an order of magnitude more time tracking down various bugs than I do now, simply because the compiler didn’t catch them for me.
- didibus 7y ago
  I totally respect anyone for just choosing a language that works best for them. They are tools for craftsman, and often are about which one makes you a better programmer. For me, Clojure definitely made me way more productive. My background was in statically typed language mostly prior, though I had done some Python and JavaScript as well. With Clojure I feel I'm between 30% to 300% more productive overall. I think some of this is personal, depends on your style and your own strengths and weaknesses.
feanaro 7y ago
My experience is the opposite. Types make code much easier to refactor, in fact almost effortlessly so and with a certain confidence the code won't be hopelessly broken afterwards. They also make code easier to reason about since the coupling that exists because of types is the result of an explicit and thoughtful decision on the part of the author. You don't as often get into situations where the code appears to work based on superficial similarity of data, only to find out there is some deep difference which prevents it from ever working. It's also the truth that the more expressive the type system is, the less coupling you are required to do. For instance, if the language supports type classes (traits), you can codify the fact that a part of the system requires not data of a particular type, but of any type supporting some set of operations. This is the very thing you imply is lost when coming from dynamic types, only this time it's tool-backed and not merely accidental.
- doglooksgood 7y ago
  I think what the most import for refactoring, is about runtime. When you get a totally unfamiliar code base, only if you can run it over and over, or at least run the tests over and over, then you can talk about the refactoring. If you can't, the refactoring is almost impossible, not matter how strong the type system is. For an argument which require type of string, the behavior could be unexpected if you just give it a string.
Axnyff 7y ago
https://news.ycombinator.com/item?id=19131272 https://news.ycombinator.com/item?id=19131272 . It don't know where your 2% number is coming from, but in Airbnb's experience it was much more. It feel like it would also be more, imo, but I guess it depe nds. Typescript can be annoying but usually it helps a lot with refactoring. It's also pretty great for detecting unused props with react. I don't use IDEs so my defense of typescript is only based on its type checking merits
exdsq 7y ago
Can you reference "Types solve 2% of programming errors"? I've read numerous research papers and blogs on this topic and have never seen anything as low as 2%. Edit: Googled and nope, can't find anything.
- didibus 7y ago
  Here are some which look at GitHub for various languages and count the defect rates by analysing commit messages: https://dev.to/danlebrero/the-broken-promise-of-static-typing https://dev.to/danlebrero/the-broken-promise-of-static-typin... https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html https://www.i-programmer.info/news/98-languages/11184-which-... https://nextjournal.com/PRL-PRG/toplas-analysis https://nextjournal.com/PRL-PRG/toplas-analysis One thing to note is that the absolute difference in terms of bugs from the worst language to the best is still minimal. So language choice doesn't seem to make or break software. Another thing to note is that while overall static languages faired better in terms of having lower defects, Clojure did best of all. I knew of another one but can't find it again. Then there are a few where they had beginner programmers implement trivial programs in different programming language and checked how many errors/time it took them. But I consider those all pretty bad since the experiments are so reductionist. So I won't list them. They aren't conclusive either. Some end up saying static and dynamic are same, some say dynamic is more productive at equal defect, and some say static had less defects at equal productivity.
- slowmovintarget 7y ago
  https://games.greggman.com/game/dynamic-typing-static-typing/ https://games.greggman.com/game/dynamic-typing-static-typing...
DannyB2 7y ago
Static types turn certain runtime errors into compile time errors. When I learned Pascal in 1982 it became quite obvious what a huge benefit this was. That said, I still like some dynamic languages for certain things.

iLemming 7y ago

Yeah, sometimes I look at some Typescript or Scala code and feel like I don't even understand what the heck they are trying to build anymore. Very often it feels like they're "elegantly" trying to solve some made-up, bullshit problems for some questionable gain. Feels like bureaucracy for the sake of bureaucracy. Totally like OOP shit that we're still trying to make sense of, like: public abstract class Ellipse2D extends RectangularShape What's the problem? Ellipses are rectangles with some extreme rounded corners. That's exactly how Euclid described them.

hota_mazi 7y ago
You're aware that it's possible to write bad code in any language, even Clojure, right?
- hellofunk 7y ago
  Totally agree, functional programming, and certainly the kind of programming you do with clojure, can get just as messy and far away from your goals as object oriented code. Clear, organized, well-architected code, in any language, is the skill that takes a long time to develop. I do not personally find clojure makes this any easier than in any language.
  - iLemming 7y ago
    > I do not personally find clojure makes this any easier than in any language. Surprisingly, it does for me. After using many different languages, I find myself more productive in Clojure than in any other language I have used before. Every language I used before Clojure left a dent in my mental ability to appreciate what I do. It's not a single favorite PL of mine, but most other programming languages make me feel bored and not interested after a year or so of using them. They have so many inconsistencies and quirks that you slowly succumb to the inevitable - you become a hostage. Your language of choice becomes your mental prison. Your hobby becomes this thing where you dig up yet some another poorly documented inconsistency and brag about it to your colleagues and friends. You become an expert from burning too often and too much. The language becomes your identity because you've seen too many ugly parts of it. You have no idea how many times I had to fight my anxiety and depression and seriously thought about leaving the field for good. Learning Clojure has liberated me; it allowed me to maintain focus and put in use all the good things and patterns I learned over the years. In other languages, sometimes you have to bend over backwards to create something clean. Sometimes you have to build this colossal cathedral that requires enormous scaffolding just to hold its own weight, and you can't even remove the scaffolding, and you call that "an elegant solution."
    - tomp 7y ago
      I'm a Programming Language enthusiast, currently making my own language. I'm really curious what makes Clojure different - it's pretty much the most loved language among its proponents (i.e. people love e.g. Rust and Go as well, but not as much as those who love Clojure, love Clojure). Is there any very Clojure-y code you can point to, that would showcase it? Is it just the libraries - collections, concurrency primitives - that could be replicated in another language? It's can be just homoiconicity, as that's just Lisp, but it could definitely be a big part of it... Do you have any ideas what any other language (e.g. Python, TypeScript, Go, Rust, Julia, Haskell, OCaml) would need to change to make you as productive as Clojure?
      - fnordsensei 7y ago
        Since there are many answers already, I won’t elaborate too much. I just want to emphasize one thing: people mention immutable data structures as a default a lot, and sure, they’re great. However, someone might turn around and say, “well, I can pull in a lib with immutable data structures in $lang if I want to.” It needs to be highlighted that the real game changer is an /ecosystem of libraries/ built entirely out of immutable data structures. That’s not something that can be engineered as needed.
      - biggidywiggidy 7y ago
        It's not one thing. It's many, many things. Each one, on their own, is good, but not a game changer. It's how they all come together in a consistent, well designed whole. This union is idiomatic. Sure you can do all this stuff in other ways, elsewhere. But there is so much ceremony. Clojure is opinionated in a good way that makes nice things succinct and idiomatic. So you will get many different answers. They are all true. And they all come together. The whole is very much greater than the sum of the parts.
      - yonki 7y ago
        I have started programming when I was about 13-14, so it's half of my life now. Honestly, I never wanted to be a programmer. More of a writer/speaker/culture animator. I found Clojure in my first years of learning programming and, from start, it felt, like the only language that was really thought through, before creation. Clojure is the best because its syntax (or lack of thereof) along with data structures, namespaced keywords, specs, and whatnot, allows me to think properly. No other language gives me tools to think so clearly and plainly. I spent lot of time with JavaScript, some Python, some Ruby, a bit of Haskell. None of those really cares about giving you proper tools to think. When I need to use a language different than Clojure it's a burden now because I still think in Clojure. Or: I try to analyze and build a model of my domain without thinking about computers. The best programming language for that is Clojure. Other languages make you think about computers and, for me, that's waisted time
- didibus 7y ago
  This has been something I've been trying to answer and can't arrive at a conclusion. I can't tell if I happen to have lucked out for the first time ever working with really good engineers, and that's why the Clojure code bases I currently work on are overall better. Or if it has anything to do with Clojure itself. From my prior work experience: Scala, Java, C#, JavaScript, ActionScript 3, C++; the code bases were always kind of crap. Everything was always called "legacy code", even if it was something that we had built just the year before. Similarly, in the open source, or even language core, things were always deprecating one after another, new release introducing breaking changes, and you had to constantly play the upgrade and refactor game to keep things working. That in turn contributed to making our own code bases so called "legacy", as the framework used even a few months back is being deprecated, or libraries you depend on that you can't upgrade to the newest release without breaking everything so you stick to outdated dependencies. None of that happens in Clojure, things are mostly stable for decades.
- iLemming 7y ago
  Look, I'm not trying to bash on static typing. I like type systems. I love Haskell's, for example. I missed static type checker in every single dynamically typed language, and Clojure is not an exception. That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable. Sometimes, dynamically typed systems make absolute sense, especially in the context of homoiconic language like Clojure, where you have a "true" REPL. An analogy I can think of is wired headphones vs. Bluetooth headphones. Audiophiles would vehemently argue that you cannot deliver quality sound via wireless, and all professionals use wired headphones. But sometimes, wireless headphones are what you need - they grant you some freedom, for a small price - you have to charge them, you have to be close the source all the time, there's interference, etc. But at the end of the day, I rather charge them once in a while and enjoy the music. After using Clojure for some time, now, whenever I need to program in a statically typed language - it feels like I'm a traveler, passing through a series of checkpoints in medieval China or something. Too much ceremony. Perhaps I'm just not smart enough to solve puzzles imposed by a type system over and over again. Maybe the simplicity that Clojure offers allows me to stay dumb and focused on the task at hand, and enjoy the ride.
  - hota_mazi 7y ago
    > That being said, there's no conclusive evidence that dynamically typed systems can't be robust and scalable. That was never the claim, though. It's possible to write anything in any language, witness the millions of lines of code that are written in PHP or FORTRAN today. The question is trying to determine if there are characteristics of programming languages (such as their type system) that make achieving these goals easier, and which also possess other nice attributes (such as making the code easier to refactor and maintain, easier to navigate or learn by new hires, etc...). In my experience, dynamically typed systems are harder to refactor, harder to understand, require more cognitive load to understand them, and are typically slower than statically typed languages. And because of the absence of type annotations and the 100% reliance on the (hoped) existence of tests, many developers simply decide not to refactor dynamic code for fear of breaking it, which leads to much more pronounced code rot with dynamically typed languages. > Maybe the simplicity that Clojure offers allows me to stay dumb and focused on the task at hand, and enjoy the ride. I'd argue the opposite: dynamically typed languages require you to hold a lot more stuff in your head (the types and what each object is and what they can do) whereas type annotations allow you to focus on more important things.

terminaljunkid 7y ago

> Types solve 2% ....... Vastly understated in my experience. Even trivial python programs contain errors that could be prevented with a trivial type system like Go's And performance. Not being fast enough is a bug. Consuming much more energy is a bug, in my book. Sufficiently expressive type systems are better than dynamic typing. They prevent so many errors, especially in FP-inspired high level data transformation functions. I am saying this as a person who doesn't even like most of FP. (You can infer from my comment history).

j88439h84 7y ago
> like Go's or Python's. It even has generics.
didibus 7y ago
FYI: Clojure has types for performance, but not for static checking. They're called type hints: https://clojure.org/reference/java_interop#typehints https://clojure.org/reference/java_interop#typehints

hellofunk 7y ago

I don’t know what percentage of errors are caught by static typing, but I do know what percentage of my time has been saved by switching to a statically typed language. I love clojure, but I spent at least an order of magnitude more time tracking down various bugs than I do now, simply because the compiler didn’t catch them for me.

didibus 7y ago
I totally respect anyone for just choosing a language that works best for them. They are tools for craftsman, and often are about which one makes you a better programmer. For me, Clojure definitely made me way more productive. My background was in statically typed language mostly prior, though I had done some Python and JavaScript as well. With Clojure I feel I'm between 30% to 300% more productive overall. I think some of this is personal, depends on your style and your own strengths and weaknesses.

feanaro 7y ago

My experience is the opposite. Types make code much easier to refactor, in fact almost effortlessly so and with a certain confidence the code won't be hopelessly broken afterwards. They also make code easier to reason about since the coupling that exists because of types is the result of an explicit and thoughtful decision on the part of the author. You don't as often get into situations where the code appears to work based on superficial similarity of data, only to find out there is some deep difference which prevents it from ever working. It's also the truth that the more expressive the type system is, the less coupling you are required to do. For instance, if the language supports type classes (traits), you can codify the fact that a part of the system requires not data of a particular type, but of any type supporting some set of operations. This is the very thing you imply is lost when coming from dynamic types, only this time it's tool-backed and not merely accidental.

doglooksgood 7y ago
I think what the most import for refactoring, is about runtime. When you get a totally unfamiliar code base, only if you can run it over and over, or at least run the tests over and over, then you can talk about the refactoring. If you can't, the refactoring is almost impossible, not matter how strong the type system is. For an argument which require type of string, the behavior could be unexpected if you just give it a string.

Axnyff 7y ago

https://news.ycombinator.com/item?id=19131272 https://news.ycombinator.com/item?id=19131272 . It don't know where your 2% number is coming from, but in Airbnb's experience it was much more. It feel like it would also be more, imo, but I guess it depe nds. Typescript can be annoying but usually it helps a lot with refactoring. It's also pretty great for detecting unused props with react. I don't use IDEs so my defense of typescript is only based on its type checking merits

exdsq 7y ago

Can you reference "Types solve 2% of programming errors"? I've read numerous research papers and blogs on this topic and have never seen anything as low as 2%. Edit: Googled and nope, can't find anything.

didibus 7y ago
Here are some which look at GitHub for various languages and count the defect rates by analysing commit messages: https://dev.to/danlebrero/the-broken-promise-of-static-typing https://dev.to/danlebrero/the-broken-promise-of-static-typin... https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html https://www.i-programmer.info/news/98-languages/11184-which-... https://nextjournal.com/PRL-PRG/toplas-analysis https://nextjournal.com/PRL-PRG/toplas-analysis One thing to note is that the absolute difference in terms of bugs from the worst language to the best is still minimal. So language choice doesn't seem to make or break software. Another thing to note is that while overall static languages faired better in terms of having lower defects, Clojure did best of all. I knew of another one but can't find it again. Then there are a few where they had beginner programmers implement trivial programs in different programming language and checked how many errors/time it took them. But I consider those all pretty bad since the experiments are so reductionist. So I won't list them. They aren't conclusive either. Some end up saying static and dynamic are same, some say dynamic is more productive at equal defect, and some say static had less defects at equal productivity.
slowmovintarget 7y ago
https://games.greggman.com/game/dynamic-typing-static-typing/ https://games.greggman.com/game/dynamic-typing-static-typing...

DannyB2 7y ago

Static types turn certain runtime errors into compile time errors. When I learned Pascal in 1982 it became quite obvious what a huge benefit this was. That said, I still like some dynamic languages for certain things.