But flexibility is the problem with XMPP in the first place. None of the clients and servers have compatible feature sets.
55 karma · joined July 2, 2014
We are a VERY significant minority of the population, and our institutions are not working for us. We should organize and do something about it instead instead of letting people try to medicate away our differences.
Maybe a more healthy meme could be: "Buy high-quality things, but never buy new". If you believe a product is durable, you should be comfortable with buying it used. If you end up not needing the thing anymore, you should be able to sell it again without any waste or loss of value.
Serious question: If people want to post blasphemy, what's preventing them from doing so? [...] I honestly don’t understand why mainstream social media websites should be allowing that sort of thing.
Stack (and stackage) is the best nicest, most-reliable build-system of any language.
Nah, I haven't used cabal-install in years now. Because of hpack, you don't even need to write .cabal files.
The only time I touch cabal is when I need to write Setup.hs files, which is, mercifully, quite rare.
"Looks like we need to let the scholars know - there are 18,300 uses of the non-word "performant" in scholarly papers" <- If that's not sarcasm, something is wrong. Performant is a word!
No typeclasses (and associated goodness), GADTs, HKTs, Monadic IO, first class functions, generic deriving, higher rank types, existential type, etc. These are bread-and-butter features in day-to-day Haskell work. Rust's type system isn't powerful enough to build the vast majority of the tools that Haskell programmers use every day.
I don't mean this as a criticism; The Rust design seems solid. But different priorities lead to different trade-offs, and the end result is a very different type system.
It's not a bad thing, but Rust has very little in common with Haskell/Ocaml; aside from stealing a couple of good ideas.
> Whenever I work in Rust, I find myself having a good time mucking around with the abstractions.
Good abstractions, the kind you use in Haskell and (presumably) Rust are simple, non-leaky, and exist to enable simple, correct code.
It's true that abstractions, even good abstractions, take time to learn. However, once you've digested them, you'll see them everywhere, and you can continue to use them for the rest of your life. Functors, for example, are a foundational abstraction. They are extremely simple, extremely powerful, and will relevant forever.
Sincerely, a Haskell developer.
If 1.5 is anywhere near as tasty as 1.3, then I strongly recommend that you give it another try. You might be able to buy some from Craigslist or something? I don't know if that's still a thing.
Personally, 2 hours works well for me but 90 minutes does not.
I don't remember all of the issues, but there are a ton of small things that make the editor unusable to me. I used it for a couple of weeks, and I spent some time working on these issues, but never had PR-worthy code. Here's what I can remember off the top of my head:
- Startup time is very slow because of the way configuration works. In my local copy, I made a version without runtime configuration, and that solved this problem. This conflicts pretty badly with the whole architecture, so I didn't make a PR.
- :n :N don't work. Opening multiple files from the command line doesn't work.
- :cq doesn't work. I fixed this, but my fix was a hack, so I didn't make a PR.
- Operating on regions with '{' and '}' is off by one line in some directions.
- You can't replace regions with shell commands. For example, using '!}sort' to sort a paragraph.
print(arr[i])
print (arr `V.unsafeIndex` i)Also, your bug reports are really solid.
fold [[_ 4 _] 3 _] → f 4 (f 3 #)
fold2 f # [[_ 4 _] 3 _] → f (f # (f 4 #)) (f 3 #)
foldl f # [[_ 4 _] 3 _] → f (f # 4) 3
foldr f # [[_ 4 _] 3 _] → f 3 (f 4 #)
fold [[_ 4 _] 3 _]
f (go [_ 4 _]) (f 3 (go []))
f 4 (f 3 (go []))
f 4 (f 3 #)
fold2 [[_ 4 _] 3 _]
fold3 f # [[_ 4 _] 3 _]
f (go [_ 4 _]) (f 3 (go _))
f (f (go _) (f 4 (go _))) (f 3 (go _))
f (f # (f 4 # )) (f 3 # )
f (f # (f 4 # )) (f 3 # )
f (f # (f 4 #)) (f 3 #)
foldl f # [[_ 4 _] 3 _]
go # [[_ 4 _] 3 _]
go (f (go # [_ 4 _]) 3) _
f (go # [_ 4 _]) 3
f (go (f (go # _) 4) _) 3
f (go (f # 4) _) 3
f (f # 4) 3
foldr f # [[_ 4 _] 3 _]
go # [[_ 4 _] 3 _]
go (f 3 (go # [_ 4 _])) _
f 3 (go # [_ 4 _])
f 3 (go (f 4 (go # _)) _)
f 3 (f 4 (go # _))
f 3 (f 4 #)The Monoid operation mappend is guaranteed to be associative, so the order is irrelevant. Data structures can fold in whatever way is most efficient for their structure.
It's true that lists and arrays are implemented as right folds, however the fold implementation for sets is neither:
From Data.Set:
fold = go
where go Tip = mempty
go (Bin 1 k _ _) = k
go (Bin _ k l r) = go l `mappend` (k `mappend` go r)
-- Here, I reorganized the code of `fold` to have the same shape as
-- `foldl/foldr` so that you can see the difference in structure more
-- clearly.
fold2 = fold3 mappend mzero
fold3 f z = go z
where
go z' Tip = z'
go z' (Bin _ x l r) = f (go f z' l) (f x (go f z' r))
foldl f z = go z
where
go z' Tip = z'
go z' (Bin _ x l r) = go (f (go z' l) x) r
foldr f z = go z
where
go z' Tip = z'
go z' (Bin _ x l r) = go (f x (go z' r)) l1: fold :: (Foldable t,Monoid m) => t m -> m
Basically, the idea is that Yi is actually a Haskell library, and your "config file" is really a Haskell program that uses this library to build an editor.
This is similar to how many suckless tools are written. If you want to configure them, edit the source: It's designed to be approachable and easy to modify.
This style of configuration is extremely nice IMHO. It gives you complete control over everything in one of the cleanest, most expressive languages around. It also means that you don't need to maintain a separate configuration language, and people that use your software are already taking steps towards becoming contributors.
This approach means that Yi has to depend on the entire Haskell toolchain :(