01:15 <ill_logic> It seems like Meteor is supposed to be there to simplify client-server communication but it just ends up being a mindfuck.

01:26 <ill_logic> Then again so is FP until you get it.

01:26 <ill_logic> But it seems like Meteor is sold as something simpler upfront.

01:27 <JacobWeisz[m]> I remember starting the tutorial and thinking it felt magical.

01:27 <JacobWeisz[m]> But I've learned most magical things are held together by the horrors of the deep.

01:30 <xet7> New Wekan v4.03 at experimental if someone dares to test

01:30 <xet7> horror included

01:30 <xet7> ;)

01:30 <xet7> with new Clearblue theme, etc

01:31 <xet7> and mobile fixes

01:32 <xet7> Also some bug https://github.com/wekan/wekan/issues/3094

01:41 <isd> The reactive stuff is pretty useful, as is the 'Methods' thing. It's nice to be able to just define a function on the client and call it from the server, and being able to just write client-side code in terms of a database query and have it auto-update is also very useful.

01:42 <isd> But, that is more or less where my appreciation for meteor ends.

01:43 <isd> ...and for the 'methods' thing, I'd rather be using capnproto over a websocket anyway... if only we had an implementation that ran in the browser.

01:44 <isd> s/define a function on the client and call it from the server/define a function on the server and call it from the client/

01:46 <isd> Also the size of our transitive dependency tree bothers me.

01:56 <isd> ill_logic: I think part of the trouble you're hidding is also probably just the pedagogy of the tutorials. They don't really explain how anything works.

01:56 <isd> I kinda felt them lacking too.

01:57 <isd> It's a bit easier to wrap your head around once you've actually been given the how.

01:58 <isd> hitting

02:00 <isd> I think that kind of instructional material drives system folks nuts in particular; we want to actually form a mental model of how the system operates, and instead we just see magic...

02:03 <isd> The other piece of it for me is I just don't like big expansive web frameworks. E.g. in the Python world I've always favored Flask over Django, I can't bring myself to use Yesod in the Haskell world (usually I use scotty)...

02:03 <isd> And meteor is one of those plus magic.

02:33 <ill_logic> I could appreciate if it was all on some conceptual plane where concepts of client and server are totally hidden.

02:34 <ill_logic> Haskell does that sort of thing to you in other ways.

02:46 <isd> Honestly I think the hardest thing about haskell is just that so much of the pedagogy is completely wrongheaded.

02:47 <isd> This was written like a year after I started learning the language: https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

02:47 <isd> I wish it had been written sooner.

03:24 <ill_logic> I dunno man. It's not as though learning how exactly the bind function works is a great idea either. That's on the concrete level.

03:25 <ill_logic> Specific examples do help though.

03:25 <ill_logic> You show a few useful examples of monads, and then you start to at least get a feel for what they are in general.

03:26 <ill_logic> I do agree in general that one loses the progression after one knows something.

03:27 <ill_logic> For me, I could learn more of how Meteor works. Instead I'm just gonna dive in and poke at this Sandstorm thing until I start to get it.

05:51 <isd> Yeah, I think the thing that will really make it click is actually hacking on stuff. When I realized I "got" monads was not when I stumbled on some metaphor that worked for me, but when I caught myself reaching for generic monad operations while using Haskell in anger.

21:24 <isd> Rust makes building "singletons"/global variables really obnoxious. Normally this wouldn't be a bad thing, but with the LD_PRELOAD thing the singleton design of libc/the unix syscall interface kinda forces my hand...

23:06 <ill_logic> Oh hey speaking of Haskell... I'm updating an old project of mine and I want to take advantage of Stack's snapshots. (and now they have LTS which is extra cool).

23:07 <ill_logic> But for some reason it seems there's a whole suite I have to install, that manages ghc installations, etc. Can I just get the snapshot tool that sets cabal constraints?

23:07 <ill_logic> It seems I've done this years ago but I forgot how.

23:08 <ill_logic> It doesn't even look like it does anything with cabal. Maybe it changed.

23:18 <isd> I don't really use stack.

23:19 <isd> Afaik the only real advantages it offers over cabal these days are: (1) managing different version of GHC, and (2) supposedly a more intuitive UI

23:20 <isd> It also used to have some advantages re: build reproducibility and isolation, but with v2-build cabal is just as good, and it seems a bit smarter about not duplicating work.

23:20 <isd> (2) is obviously subjective. But by the time stack was a thing I'd already learned the cabal UI anyway, so...

23:22 <ill_logic> Okay great. Very interesting. So do I just want to prepend all cabal commands with `v2-`?

23:23 <ill_logic> And it'll do the same package stabilization as stack?

23:23 <ill_logic> Built into its dependency management?

23:25 <isd> I think if you have stack pointed at a particular snapshot it will ignore newer versions that get uploaded to hacakge. Whereas if you do cabal update then the solver may decide to use newer versions. If you want to pin all your versions you can do cabal v2-freeze

23:26 <ill_logic> Right, I can pin them, but that's assuming I know what versions I want.

23:27 <ill_logic> That's what stack snapshots do. I thought you were saying that cabal somehow can give me similar stability.

23:27 <ill_logic> (Without using stack)

23:28 <isd> I mean I tend not to bother with actually freezing in the first place. I just make sure to put version bounds in my cabal file, and as long as upstream follows pvp I should be good.

23:28 <isd> The solver will respect those bounds.

23:29 <isd> I may not remember exactly what stack's snapshots are.

23:29 <isd> This is just the grouping of LTS packages, yes?

23:30 <isd> I mean I think if you want the curated set of core packages with no breaking changes without having to think about it too hard then stack will probably make that easier.

23:34 <ill_logic> Sure, but I'd have to think about how to remake my package for stack.

23:34 <ill_logic> I'd rather deal with a few annoying dependency issues.

23:35 <ill_logic> In other news - wait cabal v2 uses Nix?!

23:35 <isd> No, but it's internals are inspired by it.

23:35 <ill_logic> okay cool. just as well. so that's why there's no sandbox. cool.

23:35 <isd> yep.

23:36 <ill_logic> Perhaps if it takes the same form, it might be easier for hack-nix to use?

23:37 <ill_logic> haha oh.

23:37 <ill_logic> Maybe it's no longer going.

23:39 <isd> Why have I been so productive on Tuesdays recently?

23:40 <JacobWeisz[m]> I love the contribution graph. It's just fun.

23:40 <JacobWeisz[m]> I miss when it told you your streak.

23:40 <isd> I don't. That wasn't healthy.

23:41 <JacobWeisz[m]> I think anything can be used unhealthily. But I would say I benefited a lot from trying to keep a streak going here and there.

23:47 <isd> I suspect on the whole its a good thing it went away; programmers are already too prone to overworking themselves.

23:48 <isd> Taking a day off now and then is a good thing.