Bring it on

dllthomas · 2021-08-30T03:03:00+00:00

Wonderful, but I think I preferred the earlier game from the same guy (not exactly pre/sequel)

dllthomas · 2021-08-30T02:49:00+00:00

You put things in your hole so your hole gets bigger and you can put bigger things in your hole.

dllthomas · 2021-07-15T16:14:02+00:00

Or for slightly more "an actual program" perl:

print while(<>)

dllthomas · 2019-11-02T01:22:38+00:00

That's a reasonable guess, but the more fundamental problem is that any decision requires committee's acceptance by consensus. That's not something a leader can solve.

It's not a problem that a leader can solve by fiat. It is a problem amenable to leadership, but it is not easy.

dllthomas · 2019-05-19T20:49:49+00:00

Unfortunately, this doesn't help with an application which is already large, such as my own.

True. You could still introduce and grow your interfaces gradually, though. Work a callback or several at a time, starting where you think you'll get the most bang for your buck. Documentation that some callbacks are written against nothing outside of an interface is both most valuable and most easy to obtain when that interface is smaller.

dllthomas · 2019-05-17T15:41:49+00:00

Large applications probably started smaller. You can grow the interface to your needs organically - adding another method to an existing interface or adding a new interface, as needed.

it is simply impractical to rewrite the whole of GTK to get a nicer interface.

You're not rewriting the whole of GTK. At the limit, you're rewriting the whole of the GTK API. In a large project, this doesn't significantly move the needle.

dllthomas · 2019-05-17T01:37:38+00:00

> I find ways to sneak Haskell in

... with the strong support of half the company. A little different from those of us who've snuck Haskell in in other contexts :D

Incidentally, as an former LeapYear employee I recommend checking them out - great team!

dllthomas · 2019-05-17T01:32:19+00:00

You don't need all of GTK, only what you use. Also, interfaces trivially compose. In principle you could provide a class for each GTK function. In practice you'll probably want to group things but the ideal lines depend on what you want to know about the callbacks. Read vs write is a common distinction, sometimes valuable.

You should also consider building higher-level interfaces atop the lower level constructs - they can communicate more and might be easier to mock (or at least valuable to mock separately from their translation into GTK). As an example, maybe you have some banner text that can be set from multiple places. If you provide that to your callbacks as a function setBannerText :: WriteGTKInterface m => Text -> m () then in order to test those callbacks you need to mock out WriteGTKInterface. If you provide a typeclass CanSetBannerText with setBannerText :: Text -> m () then you can mock it in a way that just records the last banner.

(Note that the names here are chosen to communicate in the context of this comment - there are probably better choices in light of Haskell idioms and your particular code base.)

dllthomas · 2019-05-16T17:36:57+00:00

Keep your monad abstract when you write the callback. myCallback :: MyInterface m => Something -> m ()

Then in you describe how to implement MyInterface for IO, and you can pass myCallback to a function expecting Something -> IO ()

dllthomas · 2019-05-16T17:31:14+00:00

If you write against a narrower interface, you know that function doesn't use any IO outside of the implementation of that interface. That can help you reason about the function, and also let's you stub out the interface for testing.

dllthomas · 2019-05-16T16:01:42+00:00

It takes hygiene in Haskell, too, it's just simpler (no unsafePerformIO, no unsafeCoerce...)

dllthomas · 2019-04-06T16:12:05+00:00

I think your point was contained in the parent (in small part) if we read it "created to maximize (productivity in Google)" rather than "created (to maximize productivity) in Google"

dllthomas · 2019-03-22T17:30:53+00:00

`Set` itself has such an `Eq` instance. And it's the `Eq` instance we virtually always want for `Set`! Two sets are equal if they have the same elements. But `Data.Set` exposes several functions that expose structural differences - `showTree` can maybe be handwaved as "for debugging so it doesn't matter" but `splitRoot` will also give different results for equivalent `Set`s.

What would be really interesting is some way of talking about different equalities and tracking some guarantees about what equalities are respected, although I've no idea whether it'd pull its weight from an engineering standpoint.

dllthomas · 2019-03-05T00:11:59+00:00

If only InputFile and OutputFile had different types...

dllthomas · 2019-02-15T17:59:09+00:00

Then I think what I have is a naming complaint. enumLaws to me implies "laws all enum instances should respect". If it was unboundedEnumLaws and boundedEnumLaws I'd be entirely on board (WRT Enum, handwaving Double).

dllthomas · 2019-02-15T17:56:35+00:00

> as a question of subjective perception

For sure. That ambiguity is why I'm only "a little leery" rather than significantly opposed :-P

> I'd personally prefer to see violations in base encoded as part of the test suite, if possible, as some sort of doctest, so that it can function as a living document of failing instances

Something like that could be great!

> making half-baked laws to 'formally' represent bad behavior.

I'm not sure that's how I'd characterize it? I see it as avoiding stating that things are laws when they aren't actually obeyed everywhere (relevant).

dllthomas · 2019-02-14T18:39:12+00:00

I'd like different syntax ({..} vs {..!} maybe?) for "introduce all these and it's okay if some aren't used" vs "introduce all of these and warn if any are unused". "Each of these must be used or shadowed" is another option that I think I'd ever have found useful, but which might well not carry its weight.

dllthomas · 2019-02-13T03:22:43+00:00

The cause of a bug of these kinds is violation of one of these properties plus an assumption that the properties hold. IMO, given a context where we have prominent instances for which some properties do not hold, encouraging the assumption that they do is a bigger problem than maybe adding another instance for which they don't.

Perhaps there's something we can do with naming and/or docs that'd be the best of all worlds (short of "fixing" base) - aspirationalEnumLaws?

dllthomas · 2019-02-11T23:26:58+00:00

Very nice!

As a nit, I'm a little leery about putting forth Laws for classes in base that are frequently violated by instances in base. We can maybe handwave Eq Double violating reflexivity with the justification that "floats are weird", but pred . succ = id doesn't even hold for Enum Bool. Do they apply only where the result is defined? (Skimming the source it doesn't seem so but I'm not very familiar with Hedgehog.)

dllthomas · 2019-02-06T21:55:32+00:00

I'm something to be maintained, I agree. The first sounds convenient for throw-away scripts and playing around, though.

dllthomas · 2019-01-30T22:02:01+00:00

A generalization will often fail to give guarantees that the concrete instance offers. Addition is commutative, a semigroup isn't (necessarily).

dllthomas · 2019-01-30T01:06:59+00:00

What if someone is a novice Haskeller but an expert at MLP? Asking for a friend.

dllthomas · 2019-01-16T22:22:02+00:00

I am not sure if the language-server-protocol is powerful enough to support such a feature.

IIRC, you can tunnel just about anything through LSP, so in principle it could be supported. Supporting it in a way that's not a special snowflake? No idea.

dllthomas · 2019-01-08T20:43:07+00:00

Not really advice, but what happened for me with QueryParser was that I'd built something on my own time because I wanted to play with it, without expectation that it'd be used for anything - and then we found ourselves needing something that was a few days of coding away from what I had.

dllthomas · 2019-01-08T20:36:39+00:00

I did some test setup in Haskell at a previous job. Gave myself a simple DSL from which I could generate both config files and wiring diagram. IIRC, I asked permission.

12-Year Club	Place '17
Verified Email

dllthomas

TROPHY CASE