john-carmack-plan-archive VS language-ext

I had to laugh at this https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...

-----------------------------------------

Yes! Here is the .plan file where Carmack announces its development.

there are a bunch of features in slack beyond the core chat stuff, like:

1. being connected to multiple communities and switching between them instantly

this can be of course simply replaced by connecting to different servers in a tabbed terminal and use the terminal's built-in cmd-1/2/... shortcut, which happens to be the same as in slack.

2. meta data about others, like their timezone or how to pronounce their name is quite important for distributed team work

this can be approximated by a world readable file on the chat server in every user's home, like .plan or motd files (https://github.com/ESWAT/john-carmack-plan-archive)

3. automatic idleness detection

im actually not sure how reliable is this even in slack, but in general, it can be useful, but im not sure how to solve it elegantly, when the chat runs remotely...

maybe we should just spawn a loop at the background, which gathers idleness status from the OS and uploads it when it changes, into world readable files and the remote clients can just check those file whenever they want.

4. extra status indication with automatic expiry, eg when someone is away from the keyboard, coz they are having lunch

we do use this feature often and it's a really helpful regarding when can we expect a response from someone.

again, quite simple to model this as a plain text file and we can even use emojis, to have a very similar effect to setting " lunch" on slack. ppl would need to know what's the emoji selector shortcut though... like cmd-ctrl-space on macos.

5. text search across all channels/rooms

assuming the chat is being logged into files, then a recursive (rip)grep could work to some extent, but then from the search results one might want to get back to the context of the result too.

6. threads

this complicates implementation a lot more, but we found it an obvious improvement over the single threaded IRC model of communication

7. having threads open on the side, so ppl can track 2 streams of comms at once at least

it would require starting the chat app multiple times and do some window management to see them side-by-side

now obviously all this can be done a lot simpler, but those implementations typically always lack somehow. not sure why is that...

see https://cancel.fm/ripcord/ or http://www.altme.com/what.html

the REBOL 3 programming language even had a quite full featured, text-mode chat built in:

I was impressed by his concise daily planfiles.

https://github.com/ESWAT/john-carmack-plan-archive/tree/mast...

Quake and id Software were pioneering things we just take for granted now.

I remember playing QuakeWorld when it came out, on Linux, over a dial up modem. You had ping times of 200-300ms and it was playable. You have to remember at the time Doom and other games were LAN-only. John Carmack used to keep a .plan file with some really cool details behind Quake/QuakeWorld development. Check out Aug 02, 1996 for some detail behind the netcode[1]. You can read the future of gaming being invented right there.

[1] https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...

Perhaps relevant to link to an archive of his .plan files hosted on github: https://github.com/ESWAT/john-carmack-plan-archive/

Instead, you might be interested in looking through John Carmack's .plan archive.

https://github.com/ESWAT/john-carmack-plan-archive/blob/mast... is interesting. It transitions from todo list to a narrative format right after Quake launches :) In subsequent years you see Carmack opine on various high-perf platforms for gamers, and also for Quake level pre-processing (engine licensees had money to spend on productivity)

Chapter 64 onwards of https://www.jagregory.com/abrash-black-book/ is Mike Abrash's detailing of Quake's development.

(tl;dr - Quake was developed on NeXTSTEP + an MS-DOS port of GCC (DJGPP), Quake2 was on Visual Studio + Windows (this was the era of that Carmack giant-monitor photo), there was an in-between period of free updates to the original Quake, like WinQuake, QuakeWorld and glQuake).

You probably noticed that .SetName() returns a Either. You may have come across Unit in libraries like MediatR or Language-Ext. It's a simple construct representing a type with only one possible value. We use it as a placeholder for operations that do not return a value but may return another state. In our example, .SetName() is a Command that does not return a value but may fail. Therefore, the monad Either carries two possible states: Right (without value) or Left (with an Error).

Language-Ext is my personal favourite, but it can be a bit overwhelming for beginners due to its extensive feature set

> but I just want something closer to Scala, but for .Net

That's what I'm working toward with my language-ext library [1]. Obviously more support for expression based programming would be welcome (and higher kinds), but you can do a lot with LINQ and a good integrated library surface.

[1] https://github.com/louthy/language-ext

Definitely a fan of option types, I wonder this library has anything over the C# library language-ext which also has an Option type?

Hey, I am considering adopting the Result pattern in my codebase. Wanted to get some opinions from someone who has experience with it: should I start with language-ext or FunctionalExtensions?

> [1] https://github.com/louthy/language-ext

Cool library. I've had a few of these patterns in my Sasa library for years, but you've taken it to the Haskell extreme! Probably further than most C# developers could stomach. ;-)

You might be interested in checking out the hash array mapped trie from Sasa [1]. It cleverly exploits the CLR's reified generics to unbox the trie at various levels which ends up saving quite a bit of space and indirections, so it performs almost on par with the mutable dictionary.

I had an earlier version that used an outer struct to ensure it's never null, similar to how your collections seem to work, but switched to classes to make it more idiomatic in C#.

I recently started sketching out a Haskell-like generic "Deriving" source generator, contrasted with your domain-specific piecemeal approach, ie. [Record], [Reader], etc. Did you ever try that approach?

[1] https://sourceforge.net/p/sasa/code/ci/default/tree/Sasa.Col...

[2] https://sourceforge.net/p/sasa/code/ci/57417faec5ed442224a0f...

languageext supports linq for its monads and I kinda love it. The challenge is convincing my colleagues. 😅

language-ext supports it and it's pretty dang cool.

I can only recommend c# language extensions library https://github.com/louthy/language-ext