fine, you got me there. Probably, just because it’s written in haskell.
I suppose if there was something I could complain about, it’s use of Shakespearean Templates especially made it hard to get moving quickly in.
But how about this, you have more assurances that you are writing a web application in pure functional code than you would be in any other framework, because of the language it’s written in.
Yesod is notoriously opinionated (and, particularly their template haskelly ORM). If the author wanted to use them with other Haskell web frameworks (and less magic/opinionated database libraries), I doubt the author would have encountered any trouble at all.
“Any other language” is a large set of languages, I am pretty sure there are some more where generating UUIDs requires some coding.
That aside, are you talking about the libraries available, or about the language itself? Generating UUIDs in Haskell is not hard if you don’t need to bend them to the Yesod use case. On the other hand, generating random UUIDs would take some time if you don’t have libraries to deal with pseudorandom sequences and entropy generation, for example.
I’d suggest using content hashes instead of UUIDs. First of all, content hashes are strictly better[1], meaning they can do everything UUIDs can do (and more). Second, they are pure functions and should be no trouble in Haskell.
There are certainly things that are most naturally data modeled such that the value is the identity, and if the value changes you really have a different object. It turns out that most things that one wants a database for are not in this category; you want an identifier that’s stable.
But I’m really not clear what use-case you’re envisioning, so it’s a really confusing statement. Your link talks about message delivery, and I suppose that one could build messaging infrastructure on top of Yesod, but it’s a generic web-and-database framework.
Sorry if I came across as a zealot. In this case, where the author doesn’t care about distributed ID generation and (presumably) wants mutable posts, I would use the hash of an ordinary numeric primary key plus a secret salt. If there were some content he knew wouldn’t change (e.g. post title/URL segment) that would be even better. If nothing else, this could save storage and, of course, works in Haskell.
I just want to point out that using UUIDs takes almost no thought in any other language.
This is the thing that kills Haskell for me. I enjoyed learning the language, and on some level want to like it, but every little thing is an ordeal.
as is everything in haskell. Yesod’s still awesome though. I’m so happy to see a Yesod article for once!
I’m curious, why is Yesod awesome? In particular, what does it do better than all other web frameworks?
fine, you got me there. Probably, just because it’s written in haskell.
I suppose if there was something I could complain about, it’s use of Shakespearean Templates especially made it hard to get moving quickly in.
But how about this, you have more assurances that you are writing a web application in pure functional code than you would be in any other framework, because of the language it’s written in.
Yesod is notoriously opinionated (and, particularly their template haskelly ORM). If the author wanted to use them with other Haskell web frameworks (and less magic/opinionated database libraries), I doubt the author would have encountered any trouble at all.
“Any other language” is a large set of languages, I am pretty sure there are some more where generating UUIDs requires some coding.
That aside, are you talking about the libraries available, or about the language itself? Generating UUIDs in Haskell is not hard if you don’t need to bend them to the Yesod use case. On the other hand, generating random UUIDs would take some time if you don’t have libraries to deal with pseudorandom sequences and entropy generation, for example.
I’d suggest using content hashes instead of UUIDs. First of all, content hashes are strictly better[1], meaning they can do everything UUIDs can do (and more). Second, they are pure functions and should be no trouble in Haskell.
[1] https://bentrask.com/?q=hash://sha256/59fd0cb6d129452290291a75
Better for…? User-visible identifiers? Primary keys?
There are certainly things that are most naturally data modeled such that the value is the identity, and if the value changes you really have a different object. It turns out that most things that one wants a database for are not in this category; you want an identifier that’s stable.
But I’m really not clear what use-case you’re envisioning, so it’s a really confusing statement. Your link talks about message delivery, and I suppose that one could build messaging infrastructure on top of Yesod, but it’s a generic web-and-database framework.
Sorry if I came across as a zealot. In this case, where the author doesn’t care about distributed ID generation and (presumably) wants mutable posts, I would use the hash of an ordinary numeric primary key plus a secret salt. If there were some content he knew wouldn’t change (e.g. post title/URL segment) that would be even better. If nothing else, this could save storage and, of course, works in Haskell.