Hacker News Reader

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.

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.

> > 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

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.

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.

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.

Would be even weirder to put it in same bucket as Rust, which uses compile-time analysis to solve the problem.

Academically, both reference counting (C++, Swift, some patterns in Rust) and tracing garbage collection (Java, C#) fall under the umbrella of garbage collection.

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.

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.

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.

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 :)

> 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

> 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-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.

> I have a hard time imagining a clean codebase in a language without some form of polymorphism, first class functions, and algebraic data types

You don't have any definition of 'clean', so maybe you mean something precise or maybe you don't, but I have seen clean codebases in all kinds of languages - C, C++, Go, Java. The language doesn't dictate whether your code is clean or not, the programmer does.

Bad programmers will write bad code in any language, but in some languages even the best programmers will struggle to write good code. E.g. I've found even the best C tends to look quite cluttered, because the lack of first-class functions forces the programmer to thread state through "by hand", and the lack of polymorphism means the programmer can't clearly separate the what from the how but has to interleave the two. (Indeed I would say bad C can sometimes look superficially cleaner: things like using global variables for state remove some of the clutter, but ultimately the cure is worse than the disease)

> the cost of decrementing/incrementing these counters is very real

Only true if you use pervasive reference counting, with atomic updates. Swift essentially does this, but other languages don't.

One of the reasons why it makes sense to single out tracing GC (as opposed to RC) is that it's essentially a package deal; your whole program needs to be structured to use memory as essentially an in-RAM database, where every single object or reference can be traced after the fact at some arbitrary time in the future. (There are reasons to do this in some cases, even in 'low-level' languages which are not ordinarily garbage collected - see e.g. the use of "entity component systems" in such languages - but it's obviously not a generally-appropriate solution in any real sense!). RC is self-contained, and it need not even be locally inefficient.

> You're talking about gradually typed languages.

Interestingly, gradual typing does seem to end up with a "worst of both worlds"-type situation - the dynamic tag checks and conversions that have to be inserted at every boundary between statically- and dynamically-typed parts of the program introduce pervasive inefficiency, which is only resolved when static typing is used essentially throughout.

The term for languages like Swift, Java, and Haskell is "obligate GC". The cost of obligate GC is only superficially just the poor memory locality, interruptions, and bad citizenship -- worse is that the power of destructors is denied you, and with it the power to automate managing every other kind of resource.

> worse is that the power of destructors is denied you, and with it the power to automate managing every other kind of resource.

These are orthogonal concerns. Plenty of languages without GC do not have good support for ARM (e.g. C), and a GCed language can still have good support for ARM (e.g. monadic regions in Haskell). C++ is really the only language that conflates the two, and IME its RAII style is overrated in practice (there are a lot of rules you have to follow to avoid leaking, and for many of them you get very little warning if you break it).

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!

>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

> 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_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-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?

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

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

...

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

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.

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.

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.

You’re not the intended audience for this. For people with an academic cs background, it’s perfectly readable.

I dunno. It can just be that the intended audience is expected to know these terms already. It'd be weird to call any Nature paper an explainbrag simply because it uses field-specific terminology.

Personally, when little things like that piss me off, I find it more helpful to introspect "why do I have such a strong emational reaction to this little thing?" than to go about laying moral judgement. I find this approach is especially good at promoting effective communication in places where it's easy to misinterpret intenions, like text.

> 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.

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.

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.

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.

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?

I do understand them, I'm into functional programming and I've toyed with haskell in the past. I'm just aware that such a definition makes it sound more daunting than it really is, mostly because of that "just".

It's kinda like the running joke of "a monad is a monoid in the category of endofunctors, what's so hard about it?", but said in a non-sarcastical manner.