Creator of pixeldrain here. Italy has been doing this for a very long time. They never notified me of any such material being present on my site. I have a lot of measures in place to prevent the spread of CSAM. I have sent dozens of mails to Polizia Postale and even tried calling them a few times, but they never respond. My mails go unanswered and they just hang up the phone.
If the above poster never replies, I would assume that they're referring to (from a quick google) the fact that the EFF opposes laws that would put liabilities for blockchain software on the software author[1], and provides other similar defenses, similar to how the ACLU occasionally defends the free speech of white supremacists[2], to ensure equal protection under the law and avoid setting a bad legal precedent.
I'm trying to use it for Kubernetes since it can both work like helm (paramerizing functions) and kustomize (using the merge // operator). Moreover it has (safe) imports which make defining constants quite easy.
The syntax in the examples looks a bit more verbose and less readable than yaml but I think building sensible abstractions on top of it will alleviate the pain (abstractions here are innocuous since you can 'normalize' the code and they disappear)
I'm not too happy with the default formatting though. I think if the formatter indented nested values similar to yaml that would look better to the human eye.
> Moreover it has (safe) imports which make defining constants quite easy.
I read about dhall’s imports, and I don’t think I like it. If I add a text configuration mechanism to software, I do not want it accessing the network by default, full stop. To me, a “safe” configuration language means that parsing terminates, does not have side effects, does not touch the network, and that parsing the same file twice gives the same output unless I explicitly change an input. Pulling a prelude off of github does misses several of these requirements.
(Having your config file fail to parse if your network is down is bad, bad news if that config is needed to bring your network up. It’s also bad news if a parsing failure due to a transient network issue leaves your system in a state where it won’t quickly recover if the network comes back.)
You can still do that, though. In Dhall you may import things remotely as you develop and then tell Dhall to pre-fetch the result, you can commit that and it will not access anything.
You may also just download any imports yourself and source them locally.
Additionally Dhall supports import fallbacks, for example you may try first a remote import, and if it fails it will look for another place, which I’ve could be remote or local. This is a good strategy for developing locally and then committing imports for production use.
You can also, of course, host the files in your local network.
I get your point, but you don't need to run imports over the network (local imports are fine).
Also, if you were to import over the network, by running `dhall freeze` a semantic hash of the content is computed so you are 100% sure that what you are importing is not going to change. Moreover, files that have a hash value will be cached by dhall.
If you don't want to bother with copying over Prelude and you don't trust the cache, you can also normalize the code before pushing it to the network. This will flatten all your imports and reduce your file to normal form.
Not to start a flame war, but imho this is my definition of a "terrible book". Of the everything and the kitchen sink variety. By contrast, I very much enjoyed LYAH, not least for its self-effacing humor. Hutton was too dry for me. There's a less well-known "Thinking Functionally with Haskell" book by Richard Bird that is concise and targets the mathematically inclined crowd.
It is something that is marketed very well. From the sample content, It didn't look interesting to me at all.
LYAH may not be the greatest Haskell tutorial. But it makes an easy read. That means, you are not afraid to go back to it again and again, Which is the crucial aspect of learning anything sufficiently complex or new or both..
I agree re: marketing -- something I had easily fell for. One of the authors has moved onto writing another Haskell book (a "work of art" apparently), but this time my interest, for an intermediate level book, is elsewhere: https://intermediatehaskell.com/ (which would be more informative--thus pedagogically sound--than a work of art).
Lesson learned: don't fall for the marketing of art.
I personally favor thin books that present what really matters after having digested it first. Not that there's no place for thick books on my shelves (CLRS among others). I find HaskellWiki/Hoogle better serve the use case that the Haskell Book seems to target.
I can't recommend this book highly enough. Very practical, and the way the chapters are organized really feels right. The excercises and examples really help drive the concepts home.
In my opinion, Learn You A Haskell is a poor resource to learn the language and for some readers seems to be actually counterproductive (I have two friends who got through LYAH and then tried actually using Haskell, realized they have no idea how to actually use the language, and give up on Haskell altogether :( If only they'd used The Haskell Book...)
I read more than half of this book, and sadly I did not enjoy it at all. Read it only if you enjoy long-winded verbose explanations. Hutton's or Bird's is concise yet explanatory.
It was valuable to me as pretty much the only Haskell resource I read that addressed more complex concepts without hitting a point where they needed to resort to mathematics.
I've never had to resort to mathematics (like category theory) when learning to use Haskell in real-world projects. And I don't think Hutton's or Bird's rely on mathematics for teaching Haskell.
Well, if you are reading the chapter, it's because you want to understand it. Since everything in this book is verbose, you can't just skip the verbose parts.
Half the examples contain jokes or cutesy animal sounds (onomatopoeia). I like jokes, but it is distracting me. Especially when I don't understand the cultural reference.
My biggest gripe with the book is that the examples can feel quite contrived. Its probably super hard to make a book featuring all concepts without having contrived examples. But I remember reading a chapter and some arbitrary abstraction is introduced. Problem is, based on that example, I don't realize when the abstraction is useful.
It might be impossible to write a Haskell book that is neither terse not unnecessarily verbose.
Since you can get some chapters for free, I'd recommend you just download them and see if you like the style.
It seems that it's development is stagnating, no visible updates for a long time, though I'm eagerly waiting for the release of it's final printed edition.
The book is functionally complete. We're not waiting on any new chapters or anything. If you want a printed edition I wouldn't wait. The digital version is very good though.
Also from a user's perspective, I'd prefer everything that doesn't need to be a native app to be a pwa. They are much more lightweight and more limited in permissions. Probably those apps don't need to be submitted to the store either, except for discoverability (users are now used to search for apps on the store)
