Notices by someodd (someodd@fosstodon.org)

This gnome extension is a must for intelligent-pinyin/gnome users: https://extensions.gnome.org/extension/2820/ibus-tweaker/

It let me make the font size larger for the popup.

SEEKING PEOPLE INTERESTED IN #gopher

Want to try drag-and-drop gopherhole hosting (sftp)? It'll get automatically build/fancy-ified by my bore gopherhole builder.

Reply below!

I'm my opinion, the best way to talk about functional programming isn't to contrast it with OOP, and say "it's when you don't have objects." After all, I believe functional programming is a concept long before OOP, in which back in those days it might've been contrasted with procedural and imperative code. But not even that, in my opinion.

It's not even to talk about composition nor first order functions.

Perhaps the thing to talk about is maybe the Alonzo-Church paradigms and im/mutability.

Just rewrote my Mustache templating library. More updates incoming now that it's easier to understand.

It was a bad combination before of the Mustache library I'm using being confusing for me to use and me trying to be too clever (like avoiding repeating myself).

https://github.com/someodd/bore/commit/58855566d17cfd3a8cf77b9fc6a1c52ed7e5cfa2

I've gotten good enough at Haskell to realize there's a problem in paradigms.

There's really two types of useful programming languages and approaches.

1. Correctness. That's Haskell. The downside of correctness is that in Haskell this often means you have to exactly what to expect at all times and know about every possible edge case. This isn't in the sense of "logical edgecase broke my code," no this is about code flexibility.

(thread continued...)

An example of this philosophy divide is just think about non-exported functions in Haskell. The author made them private because he knows how the code works and why you shouldn't access them, that's very nice and correct--unless... someone out there really does have a weird case! Humans are bad at setting these boundaries!

Or how about the ability to support some YAML keys that are user-defined? Now your magical json-to-datatype generic is moot.

(end)

2. Hackability. Hackable paradigms are the most flexible, they allow you to do anything, to whatever, however you want. It makes it easy to tweak and tinker with any component, because there are no real expectations on exactness or validity laid out before you. For this same reason it's harder to maintain, easier to break, more prone to bugs, but it's much easier to extend and quickly work with.

(continued...)

Thinking about that brilliant quote, IDK who said it, that if you're writing tests that break every little change you make, you're doing it wrong. That you really just care about testing properties of the entrypoints and API. I'd add for everything else if you really want you can use doctests.

Why #Haskell ? Thread.

It's such a different way of thinking fundamentally due to the alfonzo/turing split and this has lead to unique features that slowly bleed into the general language ecosystem. One of my favorite features of Haskell is exactness and correctness. The type system lends itself to not just catching the kind of errors that would be normally runtime errors in some other languages, but it it also lends itself to things like formal verification and proof assistants like...

But also, I think Haskell was maybe one of the first places you saw property testing, and I think it's kind of the norm in this ecosystem. Just look at a unique way of thinking testing *properties* rather than just "dumb" unit tests are:

https://github.com/someodd/bore/blob/master/test/Spec.hs

What's happening here is a kind of statistical verification of *properties* that should prove true about the actual entrypoint/main functions that *do the thing*...

... #LiquidHaskell (restriction types, SMT solver) and the Isabelle proof assistant.

For example, look at the kind of assurances we can make about data at the type-level. This means the SMT solver can assure that certain logical constraints on types are provably true.

My code to verify a file ranking algo I made:

https://github.com/someodd/bore/blob/master/src/Bore/SpacecookieClone/Search/Verified.hs

In this code above is I actually "verify" important properties of the important thing: file ranking works as expected.

It's explicitly NOT "if I give x input I get y output" style unit test. The "statistical verification" comes from the fact that you can programmatically generate inputs and verify the outputs, and thus generate >1,000 test "cases" from just one actual property test.

And this is because, I think, you're dealing with more abstract logic, which Haskell really lends itself to.

My #GitHub account is rather lonely.

I do lots of neat #haskell projects!

Looking for followers, stars, collaborators!

https://github.com/someodd

type families in Haskell are a cool concept, but I've never made my own.

Please reply to this toot if you use #XMPP!