4 ms·

When I first studied compilers, I was amazed that writing a compiler used every other subfield of computer science I'd studied. It's the acid test of language

by ken 7y ago

When I first studied compilers, I was amazed that writing a compiler used every other subfield of computer science I'd studied. It's the acid test of language design. A language that can easily be used to write compilers can do almost anything well. And every non-trivial program I've worked on is 90% of a compiler. (You could describe compilers as just "some business logic in the middle", too, if you were in Architecture Astronaut mode.) You don't think HTTP servers use "pattern matching"? You don't think API endpoints would benefit from "ridiculously easy" testing? This is your bread and butter. This article is showing how to implement if-statements and null-checks in Haskell, and reduce your code size by half. I bet you have some of those in your software. I'm not sure how this could be much more relevant, without reducing its usefulness by being overly specific.

gowld 7y ago
You are conflating computer science (complete writing) with software application development. In the real world, software has a CS "core", plus 95% boring data copying and gluing APIs together, where availability of libs and tools is far more important than theoretical correctness properties and the most general abstraction possible. This is why Haskell looks so nice in blog posts but terrible in a production system. In Haskell, updating fields in a records is still an active area research.
- johnday 7y ago
  > In Haskell, updating fields in a records is still an active area research. In Haskell, everything is still an active area of research. Mutable data already exists in Haskell and has sensible semantics. But the goal of Haskell (so far as I can see, at least) is good, reliable, maintainable code which produces good, reliable, maintainable programs. If this is not what you look for in a programming language then it might not be for you.
- agentultra 7y ago
  I wrote a library for that. Hooray you can version your types and seamlessly upgrade them and the compiler will never let you cross streams by accident. https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs/Data-Migration.html https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs...
- ken 7y ago
  Doesn't the presence of "general abstraction" allow us to write less of the "boring" parts? I thought that's the whole reason for it. Isn't "correctness" a useful property, even for a web service? I think that being able to eliminate entire categories of bugs is terrific, in any situation. Sure, it's always nicer to have good libs/tools than to have to write your own (though that distinction is much less important when your language has great abstraction capabilities). Are there any libs/tools you're missing in Haskell? The way your comment is phrased makes it sound like good old fashioned FUD. I'm not sure what you mean by the last sentence. It seems to still be an active area of research all over the place. Look at Swift/Rust/Go/Java, or Postgres/Mongo/Datomic, or ext4/zfs/btrfs/ntfs. Everybody updates records in very different ways. It's not like all Algol-derived languages have the same data model.

by ken 7y ago

gowld 7y ago

You are conflating computer science (complete writing) with software application development. In the real world, software has a CS "core", plus 95% boring data copying and gluing APIs together, where availability of libs and tools is far more important than theoretical correctness properties and the most general abstraction possible. This is why Haskell looks so nice in blog posts but terrible in a production system. In Haskell, updating fields in a records is still an active area research.

johnday 7y ago
> In Haskell, updating fields in a records is still an active area research. In Haskell, everything is still an active area of research. Mutable data already exists in Haskell and has sensible semantics. But the goal of Haskell (so far as I can see, at least) is good, reliable, maintainable code which produces good, reliable, maintainable programs. If this is not what you look for in a programming language then it might not be for you.
agentultra 7y ago
I wrote a library for that. Hooray you can version your types and seamlessly upgrade them and the compiler will never let you cross streams by accident. https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs/Data-Migration.html https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs...
ken 7y ago
Doesn't the presence of "general abstraction" allow us to write less of the "boring" parts? I thought that's the whole reason for it. Isn't "correctness" a useful property, even for a web service? I think that being able to eliminate entire categories of bugs is terrific, in any situation. Sure, it's always nicer to have good libs/tools than to have to write your own (though that distinction is much less important when your language has great abstraction capabilities). Are there any libs/tools you're missing in Haskell? The way your comment is phrased makes it sound like good old fashioned FUD. I'm not sure what you mean by the last sentence. It seems to still be an active area of research all over the place. Look at Swift/Rust/Go/Java, or Postgres/Mongo/Datomic, or ext4/zfs/btrfs/ntfs. Everybody updates records in very different ways. It's not like all Algol-derived languages have the same data model.