6 ms·

This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. > Haskell, at its core, is simple: it is just a polymor

This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. > Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes. This happens to be just the right combination of features to allow us to write clean, maintainable code that also runs fast. This is an explainabrag which is also wrong: languages without these features can also have "clean, maintainable code" and nothing about this list implies "runs fast." > Memory unsafe languages, such as C, lead to the worst sort of bugs and security vulnerabilities (buffer overflows and memory leaks). Is a memory leak meant to be the "worst sort of bug" or a "security vulnerability?" The implication is that memory-safe languages do not have memory leaks, which is completely false. Haskell is particularly prone to "space leaks" due to its laziness. > Memory safe languages form two groups: the ones that rely on a garbage collector, and Rust. What a profoundly dismissive attitude. Why bring up Cyclone and not, say, Swift? Or is Swift meant to be included in "garbage collected languages?" > Dynamically typed (or, rather, unityped) No these are not the same and this is an absurdly wrong conflation. Dart, Objective-C, TypeScript, and others are dynamically typed languages with static type checking. You can't "or rather" this distinction away. The author rushes past real-world facts to get to the architecture-astronaut rocket ship, solving type-theoretical problems and pretending it's an engineering exercise. Blast off, I guess.

huntie 8y ago
Swift uses reference counting which is generally considered a form of garbage collection. I agree, I felt like the author just wanted to talk about how great Haskell is. It made me think of the "smug lisp weenie" archetype.
- chc4 8y ago
  It does reference counting, but it's not mark-and-sweep stop the world reference counting. It's as garbage collected as shared_ptr<T> and doesn't try to collect cycles. Feels a bit weird to put that under the same bucket as Java.
  - sa1 8y ago
    Would be even weirder to put it in same bucket as Rust, which uses compile-time analysis to solve the problem.
  - hinata 8y ago
    Academically, both reference counting (C++, Swift, some patterns in Rust) and tracing garbage collection (Java, C#) fall under the umbrella of garbage collection.
    - ncmncm 8y ago
      The important distinction, then, is obligate garbage collection. Can I write a substantial program that does, and needs, no garbage collection of any kind? In C++ and Rust, yes, trivially, every day. The distinction matters because without obligate GC, you get the benefit of destructors (or in Rust, the Drop trait), and have the tool for resource management of every kind, usually written "}". Reference counting GC is rarely used in well-designed C++ and Rust programs, simply because there is rarely any need for it. Reliance on shared_ptr or ARC is recognized as a disease of forced Java converts.
      - staticassertion 8y ago
        This isn't true if you've actually seen production Rust code, but the point is irrelevant to the issue of swift being GC'd - it is.
  - pjmlp 8y ago
    Any CS book on garbage collection algorithms worth its place on a good paper bibliography, places reference counting among the possible implementations of garbage collection. What the common dev without compiler background knowledge calls GC is actually named as tracing GC on CS literature.
kreetx 8y ago
I love haskell, but agree that the article is corny as hell (sorry, author!). Having the text read by multiple people before publishing could have made this a lot better (and still can). Dependent types on the other hand are great! Looking forward, good luck!
pzone 8y ago
That "explainabrag" pissed me off too. I feel like that kind of thing is super typical among Haskell bloggers.
- jcelerier 8y ago
  especially when "performant" means "11.5 average FPS when making a breakout game clone with 12 bricks on Android" https://www.youtube.com/watch?v=t5-dFlt7iyc https://www.youtube.com/watch?v=t5-dFlt7iyc ... and being happy that it then can run at 450 fps on a desktop computer with non-negligible manual optimization work https://www.youtube.com/watch?v=PXxwYYNZhU8 https://www.youtube.com/watch?v=PXxwYYNZhU8
  - int_index 8y ago
    Experiments with running Haskell on Android using idealised FRP frameworks such as Yampa are not representative of Haskell performance in general. Haskell allows you to write fast code, it doesn't safeguard you from writing slow code.
- peteretep 8y ago
  At first I thought it was a joke along the lines of "A monad is just a monoid in the category of endofunctors, what's the problem?", but no, it seems to be being said non-ironically.
  - wtetzner 8y ago
    How is this the same thing? - polymorphic lambda calculus: Lambda calculus with generics - lazy evaluation: Well, lazy evaluation. Not sure how else to describe this - algebraic data types: Again, how else to describe this? Put in a full description of what algebraic data types are? - type classes: Haskell has type classes. I really don't see what the problem is. If you're coming in to an article about dependent types, and you don't know what these things are, I think don't think the reasonable response is for the author to explain all of it to the reader. This isn't a beginner's introduction to Haskell.
- 8y ago
sa1 8y ago
It only reads like a troll piece because you are deliberately taking his statements in an adversarial context. It's weird to complain about the tone of other posts, and then go on to write a comment like yours. > This is an explainabrag which is also wrong: languages without these features can also have "clean, maintainable code" and nothing about this list implies "runs fast." I agree with you here. However, I would also agree with the claim that Haskell is simple at its core. It's simple in a mathematical sense, and that doesn't imply that the language is easy to understand or that such simplicity offers all kinds of advantages other languages lack. > The author rushes past real-world facts to get to the architecture-astronaut rocket ship, solving type-theoretical problems and pretending it's an engineering exercise. Blast off, I guess. The author writes a small inaccurate section on the current state of affairs, before writing a very well-explained piece on how to get GHC to be better dependently typed. Dependent types are not something you care about, so its quite obvious why you are only responding to a small preface section of the post, while dismissing the meat of it as "solving type-theoretical problems". I assure you that dependent types, how to get there, are very important to a large number of people. An inaccurate preface doesn't take away from, or affect, this exercise. I wish other readers reading this comment take time to read the bulk of the article, if they are interested in dependent types(or want to learn about it). It is very well written and explained, and it is not a comparative study of mainstream languages with Haskell, in case you get that impression from the other comments here.
a-saleh 8y ago
T.b.h. I skimmed the "Haskell is the best" part and read just through the "Can we get performance of Haskell with the type-features of Agda without sacrificing the ergonomics of either?" and found it informative :)
int_index 8y ago
> This is an explainabrag My goal here was to show that standard Haskell boils down to a small set of features, therefore it's a simple language. Surely, "simple" does not imply "good" (Brainfuck is also simple), so I then assert that the combination of features that Haskell consists is fertile soil for writing maintainable and performant code. > languages without these features can also have "clean, maintainable code" Some people may prefer ML modules to type classes, sure. As to the other features, I have a hard time imagining a clean codebase in a language without some form of polymorphism, first class functions, and algebraic data types. (And lazy evaluation is a great addition to the list). Perhaps there are other sweet spots in the language design space, but I have not seen them yet. > and nothing about this list implies "runs fast." GHC is good at optimising this kind of code. https://stackoverflow.com/a/35038374 https://stackoverflow.com/a/35038374 > Is a memory leak meant to be the "worst sort of bug" or a "security vulnerability?" It's often hard to debug, and it means that the program can't be running for a long period of time. I suppose I should've used a better example, e.g. "use-after-free", to highlight the dangers of manual memory management. > Haskell is particularly prone to "space leaks" due to its laziness. Space leaks are benign compared to memory leaks in that the memory is eventually freed. That said, I'd be happy to have some sort of static analysis to prevent them. > Why bring up Cyclone and not, say, Swift? Or is Swift meant to be included in "garbage collected languages?" Swift relies on automatic reference counting, which is similar to garbage collection in that it isn't done by the programmer and has a runtime performance cost. Remarkably, it seems to be worse on both accounts: the cost of decrementing/incrementing these counters is very real, and handling reference cycles is not automatic (you need to carefully use weak references). Here's an interesting discussion of RC vs GC in context of .NET https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-management/ https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-m... Rust, on the other hand, offers a static analysis with no runtime performance overhead to manage memory safely. > dynamically typed languages with static type checking You're talking about gradually typed languages. Sure, these are not unityped, but they also not purely dynamically typed (you said it yourself – they have static type checking). Perhaps that's just a difference between our uses of the term "dynamically typed" and we don't have a true disagreement here? By the way, Haskell can do that too, we have the `Dynamic` type right in the `base` package. > This read like a troll piece. I'm sorry.
tree_of_item 8y ago
> This is an explainabrag It's not. Maybe it seems that way because you're not familiar with the terms, so it seems like someone trying to name drop all the stuff they know? But if you are familiar with the terms, it's just informative, and serves to situate you in the space of possible language designs. It's a lambda calculus as opposed to a process calculus, polymorphic as opposed to simply typed, lazy as opposed to strict etc.
- kace91 8y ago
  I'd argue that the informative value is pretty much zero: If a programmer is familiar with lambda calculus, lazy languages, and algebraic types, then there's just no way that person isn't also somewhat familiar with haskell. The explanation is gibberish for those who need it, so its only use is to be self congratulatory for those who don't.
  - tree_of_item 8y ago
    Why do you say "self congratulatory" and not "communicative"? You are assuming your conclusion: that it was snobby. But it wasn't. It was just informative, provided, yes, you knew what the words meant. The author is communicating with other people who know about the space of programming languages, and describing Haskell in a particular way to show its surface area.
  - staticassertion 8y ago
    I would assume that some haskell knowledge is assumed, and the author is simply framing the conversation by stating their view of haskell as a set of core features, which they named.
  - empath75 8y ago
    This point of view is alien to me. Why, when you see words you don’t understand, don’t you make an effort to learn what they mean? How on earth did you ever become a coder with this kind of attitude?
    - 8y ago
21 8y ago
> This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. You're not the only one: https://old.reddit.com/r/programmingcirclejerk/comments/a76b89/haskell_at_its_core_is_simple_it_is_just_a/ https://old.reddit.com/r/programmingcirclejerk/comments/a76b...
lmm 8y ago
If you want to engage productively, remember that people tend to say things they think are true, so look for a way to read it that makes sense rather than going out of your way to find a way to read it that makes it false. (I guess nitpicking the phrasing for a "middlebrow dismissal" is the best way to get upvotes here nowadays). > nothing about this list implies "runs fast." It doesn't imply it, but it enables it; read "allow" that way. > Is a memory leak meant to be the "worst sort of bug" or a "security vulnerability?" Maybe the one that makes sense rather than the one that doesn't make sense. > The implication is that memory-safe languages do not have memory leaks, which is completely false. There's no such implication, only that memory-unsafety leads to memory leaks, which is true. > Or is Swift meant to be included in "garbage collected languages?" Yes it is. > No these are not the same and this is an absurdly wrong conflation. They are the same; traditional dynamic typing is exactly unityping. That it's possible to combine dynamic typing with other things just means that alternatives are possible, not that dynamic typing is something different.
- jlokier 8y ago
  > > The implication is that memory-safe languages do not have memory leaks, which is completely false. > There's no such implication, only that memory-unsafety leads to memory leaks, which is true. If we're going to read in the spirit of "looking for a way to read things that make sense rather than going out of your way to find a way to read it that makes it false"... Then it depends which sort of implication. https://en.wikipedia.org/wiki/Implicature https://en.wikipedia.org/wiki/Implicature
  - newen 8y ago
    Not really. p therefore q implies not p therefore not q is a very basic logical fallacy. Making a statement does not imply it's inverse.
staticassertion 8y ago
>This is an explainabrag which is also wrong It only feels like "explainabrag"ing to some, I would imagine. The terms are all really standard, and listing out features by their names hardly feels braggy. It's a clear, concise way of stating features of a language. Coming from other languages with those features I think the information was conveyed well - but for others it would just look like jargon. To me, the author was setting up the post - framing the conversation by explaining their view of Haskell as a set of core features. Then they moved on to discuss another feature - dependent types. This makes a lot of sense in the context of dependent types - I think this HN post really nicely conveys why: https://news.ycombinator.com/item?id=18705128 https://news.ycombinator.com/item?id=18705128 > What a profoundly dismissive attitude. Why bring up Cyclone and not, say, Swift? Or is Swift meant to be included in "garbage collected languages?" It's like, pretty mostly true. There are other languages that are memory safe without GC but I don't know of any that are mainstream/ even in use, or that allow free'ing of memory. Yes Swift is GC'd, just not tracing GC'd. https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting https://en.wikipedia.org/wiki/Garbage_collection_(computer_s... > No these are not the same and this is an absurdly wrong conflation. Dart, Objective-C, TypeScript, and others are dynamically typed languages with static type checking. You can't "or rather" this distinction away. I don't think so. "Dynamically typed with static type checking" makes no sense. The languages listed are statically typed. They may coincidentally compile to code that checks the type at runtime as well, or code that has or lacks implicit casts, or otherwise carries type information around with the data, or whatever, but the types are statically defined. Also, dynamic types are often considered to be unityped - every value inhabits one giant union of all possible types. https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan... Here is a source demonstrating that this view is not unique. You are free to disagree (some do), but it's hardly an "absurdly wrong conflation". I think your post was pretty unnecessarily critical. You didn't like the post, ok. But maybe you should have challenged that gut reaction - that "rubbed me the wrong way" feeling, because I think your post has considerably more inaccuracies than the article and is unequivocally more hostile. If you'd challenged that feeling maybe you would have learned something?

huntie 8y ago

Swift uses reference counting which is generally considered a form of garbage collection. I agree, I felt like the author just wanted to talk about how great Haskell is. It made me think of the "smug lisp weenie" archetype.

chc4 8y ago
It does reference counting, but it's not mark-and-sweep stop the world reference counting. It's as garbage collected as shared_ptr<T> and doesn't try to collect cycles. Feels a bit weird to put that under the same bucket as Java.
- sa1 8y ago
  Would be even weirder to put it in same bucket as Rust, which uses compile-time analysis to solve the problem.
- hinata 8y ago
  Academically, both reference counting (C++, Swift, some patterns in Rust) and tracing garbage collection (Java, C#) fall under the umbrella of garbage collection.
  - ncmncm 8y ago
    The important distinction, then, is obligate garbage collection. Can I write a substantial program that does, and needs, no garbage collection of any kind? In C++ and Rust, yes, trivially, every day. The distinction matters because without obligate GC, you get the benefit of destructors (or in Rust, the Drop trait), and have the tool for resource management of every kind, usually written "}". Reference counting GC is rarely used in well-designed C++ and Rust programs, simply because there is rarely any need for it. Reliance on shared_ptr or ARC is recognized as a disease of forced Java converts.
    - staticassertion 8y ago
      This isn't true if you've actually seen production Rust code, but the point is irrelevant to the issue of swift being GC'd - it is.
- pjmlp 8y ago
  Any CS book on garbage collection algorithms worth its place on a good paper bibliography, places reference counting among the possible implementations of garbage collection. What the common dev without compiler background knowledge calls GC is actually named as tracing GC on CS literature.

kreetx 8y ago

I love haskell, but agree that the article is corny as hell (sorry, author!). Having the text read by multiple people before publishing could have made this a lot better (and still can). Dependent types on the other hand are great! Looking forward, good luck!

pzone 8y ago

That "explainabrag" pissed me off too. I feel like that kind of thing is super typical among Haskell bloggers.

jcelerier 8y ago
especially when "performant" means "11.5 average FPS when making a breakout game clone with 12 bricks on Android" https://www.youtube.com/watch?v=t5-dFlt7iyc https://www.youtube.com/watch?v=t5-dFlt7iyc ... and being happy that it then can run at 450 fps on a desktop computer with non-negligible manual optimization work https://www.youtube.com/watch?v=PXxwYYNZhU8 https://www.youtube.com/watch?v=PXxwYYNZhU8
- int_index 8y ago
  Experiments with running Haskell on Android using idealised FRP frameworks such as Yampa are not representative of Haskell performance in general. Haskell allows you to write fast code, it doesn't safeguard you from writing slow code.
peteretep 8y ago
At first I thought it was a joke along the lines of "A monad is just a monoid in the category of endofunctors, what's the problem?", but no, it seems to be being said non-ironically.
- wtetzner 8y ago
  How is this the same thing? - polymorphic lambda calculus: Lambda calculus with generics - lazy evaluation: Well, lazy evaluation. Not sure how else to describe this - algebraic data types: Again, how else to describe this? Put in a full description of what algebraic data types are? - type classes: Haskell has type classes. I really don't see what the problem is. If you're coming in to an article about dependent types, and you don't know what these things are, I think don't think the reasonable response is for the author to explain all of it to the reader. This isn't a beginner's introduction to Haskell.
8y ago

sa1 8y ago

It only reads like a troll piece because you are deliberately taking his statements in an adversarial context. It's weird to complain about the tone of other posts, and then go on to write a comment like yours. > This is an explainabrag which is also wrong: languages without these features can also have "clean, maintainable code" and nothing about this list implies "runs fast." I agree with you here. However, I would also agree with the claim that Haskell is simple at its core. It's simple in a mathematical sense, and that doesn't imply that the language is easy to understand or that such simplicity offers all kinds of advantages other languages lack. > The author rushes past real-world facts to get to the architecture-astronaut rocket ship, solving type-theoretical problems and pretending it's an engineering exercise. Blast off, I guess. The author writes a small inaccurate section on the current state of affairs, before writing a very well-explained piece on how to get GHC to be better dependently typed. Dependent types are not something you care about, so its quite obvious why you are only responding to a small preface section of the post, while dismissing the meat of it as "solving type-theoretical problems". I assure you that dependent types, how to get there, are very important to a large number of people. An inaccurate preface doesn't take away from, or affect, this exercise. I wish other readers reading this comment take time to read the bulk of the article, if they are interested in dependent types(or want to learn about it). It is very well written and explained, and it is not a comparative study of mainstream languages with Haskell, in case you get that impression from the other comments here.

a-saleh 8y ago

T.b.h. I skimmed the "Haskell is the best" part and read just through the "Can we get performance of Haskell with the type-features of Agda without sacrificing the ergonomics of either?" and found it informative :)

int_index 8y ago

> This is an explainabrag My goal here was to show that standard Haskell boils down to a small set of features, therefore it's a simple language. Surely, "simple" does not imply "good" (Brainfuck is also simple), so I then assert that the combination of features that Haskell consists is fertile soil for writing maintainable and performant code. > languages without these features can also have "clean, maintainable code" Some people may prefer ML modules to type classes, sure. As to the other features, I have a hard time imagining a clean codebase in a language without some form of polymorphism, first class functions, and algebraic data types. (And lazy evaluation is a great addition to the list). Perhaps there are other sweet spots in the language design space, but I have not seen them yet. > and nothing about this list implies "runs fast." GHC is good at optimising this kind of code. https://stackoverflow.com/a/35038374 https://stackoverflow.com/a/35038374 > Is a memory leak meant to be the "worst sort of bug" or a "security vulnerability?" It's often hard to debug, and it means that the program can't be running for a long period of time. I suppose I should've used a better example, e.g. "use-after-free", to highlight the dangers of manual memory management. > Haskell is particularly prone to "space leaks" due to its laziness. Space leaks are benign compared to memory leaks in that the memory is eventually freed. That said, I'd be happy to have some sort of static analysis to prevent them. > Why bring up Cyclone and not, say, Swift? Or is Swift meant to be included in "garbage collected languages?" Swift relies on automatic reference counting, which is similar to garbage collection in that it isn't done by the programmer and has a runtime performance cost. Remarkably, it seems to be worse on both accounts: the cost of decrementing/incrementing these counters is very real, and handling reference cycles is not automatic (you need to carefully use weak references). Here's an interesting discussion of RC vs GC in context of .NET https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-management/ https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-m... Rust, on the other hand, offers a static analysis with no runtime performance overhead to manage memory safely. > dynamically typed languages with static type checking You're talking about gradually typed languages. Sure, these are not unityped, but they also not purely dynamically typed (you said it yourself – they have static type checking). Perhaps that's just a difference between our uses of the term "dynamically typed" and we don't have a true disagreement here? By the way, Haskell can do that too, we have the `Dynamic` type right in the `base` package. > This read like a troll piece. I'm sorry.

tree_of_item 8y ago

> This is an explainabrag It's not. Maybe it seems that way because you're not familiar with the terms, so it seems like someone trying to name drop all the stuff they know? But if you are familiar with the terms, it's just informative, and serves to situate you in the space of possible language designs. It's a lambda calculus as opposed to a process calculus, polymorphic as opposed to simply typed, lazy as opposed to strict etc.

kace91 8y ago
I'd argue that the informative value is pretty much zero: If a programmer is familiar with lambda calculus, lazy languages, and algebraic types, then there's just no way that person isn't also somewhat familiar with haskell. The explanation is gibberish for those who need it, so its only use is to be self congratulatory for those who don't.
- tree_of_item 8y ago
  Why do you say "self congratulatory" and not "communicative"? You are assuming your conclusion: that it was snobby. But it wasn't. It was just informative, provided, yes, you knew what the words meant. The author is communicating with other people who know about the space of programming languages, and describing Haskell in a particular way to show its surface area.
- staticassertion 8y ago
  I would assume that some haskell knowledge is assumed, and the author is simply framing the conversation by stating their view of haskell as a set of core features, which they named.
- empath75 8y ago
  This point of view is alien to me. Why, when you see words you don’t understand, don’t you make an effort to learn what they mean? How on earth did you ever become a coder with this kind of attitude?
  - 8y ago

21 8y ago

> This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. You're not the only one: https://old.reddit.com/r/programmingcirclejerk/comments/a76b89/haskell_at_its_core_is_simple_it_is_just_a/ https://old.reddit.com/r/programmingcirclejerk/comments/a76b...

lmm 8y ago

If you want to engage productively, remember that people tend to say things they think are true, so look for a way to read it that makes sense rather than going out of your way to find a way to read it that makes it false. (I guess nitpicking the phrasing for a "middlebrow dismissal" is the best way to get upvotes here nowadays). > nothing about this list implies "runs fast." It doesn't imply it, but it enables it; read "allow" that way. > Is a memory leak meant to be the "worst sort of bug" or a "security vulnerability?" Maybe the one that makes sense rather than the one that doesn't make sense. > The implication is that memory-safe languages do not have memory leaks, which is completely false. There's no such implication, only that memory-unsafety leads to memory leaks, which is true. > Or is Swift meant to be included in "garbage collected languages?" Yes it is. > No these are not the same and this is an absurdly wrong conflation. They are the same; traditional dynamic typing is exactly unityping. That it's possible to combine dynamic typing with other things just means that alternatives are possible, not that dynamic typing is something different.

jlokier 8y ago
> > The implication is that memory-safe languages do not have memory leaks, which is completely false. > There's no such implication, only that memory-unsafety leads to memory leaks, which is true. If we're going to read in the spirit of "looking for a way to read things that make sense rather than going out of your way to find a way to read it that makes it false"... Then it depends which sort of implication. https://en.wikipedia.org/wiki/Implicature https://en.wikipedia.org/wiki/Implicature
- newen 8y ago
  Not really. p therefore q implies not p therefore not q is a very basic logical fallacy. Making a statement does not imply it's inverse.

staticassertion 8y ago

>This is an explainabrag which is also wrong It only feels like "explainabrag"ing to some, I would imagine. The terms are all really standard, and listing out features by their names hardly feels braggy. It's a clear, concise way of stating features of a language. Coming from other languages with those features I think the information was conveyed well - but for others it would just look like jargon. To me, the author was setting up the post - framing the conversation by explaining their view of Haskell as a set of core features. Then they moved on to discuss another feature - dependent types. This makes a lot of sense in the context of dependent types - I think this HN post really nicely conveys why: https://news.ycombinator.com/item?id=18705128 https://news.ycombinator.com/item?id=18705128 > What a profoundly dismissive attitude. Why bring up Cyclone and not, say, Swift? Or is Swift meant to be included in "garbage collected languages?" It's like, pretty mostly true. There are other languages that are memory safe without GC but I don't know of any that are mainstream/ even in use, or that allow free'ing of memory. Yes Swift is GC'd, just not tracing GC'd. https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting https://en.wikipedia.org/wiki/Garbage_collection_(computer_s... > No these are not the same and this is an absurdly wrong conflation. Dart, Objective-C, TypeScript, and others are dynamically typed languages with static type checking. You can't "or rather" this distinction away. I don't think so. "Dynamically typed with static type checking" makes no sense. The languages listed are statically typed. They may coincidentally compile to code that checks the type at runtime as well, or code that has or lacks implicit casts, or otherwise carries type information around with the data, or whatever, but the types are statically defined. Also, dynamic types are often considered to be unityped - every value inhabits one giant union of all possible types. https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan... Here is a source demonstrating that this view is not unique. You are free to disagree (some do), but it's hardly an "absurdly wrong conflation". I think your post was pretty unnecessarily critical. You didn't like the post, ok. But maybe you should have challenged that gut reaction - that "rubbed me the wrong way" feeling, because I think your post has considerably more inaccuracies than the article and is unequivocally more hostile. If you'd challenged that feeling maybe you would have learned something?