Where our roots reside and the high quality of life in our area. Once we began a family, this became all the more important and added in the desire for stability for our children. It was these choices, combined with living well outside an hour of Boulder and Denver, that pushed me to focus on a remote-centric career.
I think a lot about moving closer to technology hubs and there is definitely a desire to generally work day-to-day with excellent engineers in close quarters. However, each time I do rocking chair thinking, I come back to the same conclusion; our lives are more rich with family and friends and the lifestyle we are able to gain via the lesser cost of living. Though, I admit it has a large potential cost on career. I'd love to be slinging Haskell day-to-day, in SF, etc for the rest of my life on a professional level.
I made a minimal bash CLI for transfer.sh, since I regularly interact with it. Nothing you couldn't do by hand, but it makes it easier to do some operations. Uploading directories, encryption/decryption, piping, etc.
I did something similar where you could send GitHubers encrypted messages only they could decrypt via their SSH public key that GitHub makes available: https://github.com/rockymadden/github-crypt
I've considered adding Github public key support to EnvKey[1]. Currently, when inviting a user, you need to send a token out of band in order to not trust our servers during the invite process. Using the Github public key could potentially eliminate this step.
My only concern is that these might have a tendency to get out of date or not be managed securely, in which case it could be more trouble than it's worth.
That's a cool idea. It would be neat to have some way of sending that to the githubber builtin to the tool. Maybe send an email to the githubber if they have an email published or maybe just post it to a gist that then you can send them the link to?
I love that idea! I think you could use the anonymous gist API. Have the tool output to stdout/pbcopy the gist URL that was created upon encrypt and similarly have it accept a gist URL to decrypt. Nothing to send on either side beyond the URL.
For those looking for monadic Promises, I’d suggest taking a look at Fluture (https://github.com/fluture-js/Fluture). It’s a wonderful library and with do-notation, ability to work with callbacks, nodebacks, and Promises, I haven’t looked back. It also has adheres to Fantasy Land, Static Land, and has defintions for santuary-def.
But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff.
I hope I'm wrong, and I really am interested to learn more about it, but I can see from the OP's linked thread that I'm not alone feeling this way. It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are. After decades of coding, I'm just getting more alergic to complexity, and this feels like complexity.
What are some good online resources that might help me change my mind and see the light?
> At a glance it just feels super complex, academic
Agreed, because unfortunately, it is. (I might substitute "complex" with "hard" -- the ideas are actually very simple; understanding the big picture of how they fit together is hard)
> It's not at all clear why I should be thinking about my JavaScript algebraically at all times, or what the practical advantages are.
The main goal is to be able to write more and more code as pure functions -- this is hopefully an accepted best practice: functions with minimal inputs and no tangle of global state/context are far easier to reason about, test, and with proper data design, reuse.
But you quickly run into an issue: how can I write pure, stateless functions when dealing with inherently stateful surroundings (IO, DOM, database, etc.). That's what all this category theory jargon is about.
"Once you understand monads, you immediately become incapable of explaining them to anyone else” Lady Monadgreen’s curse ~ Gilad Bracha"
If you'd like to go down a rabbit hole of category theory look up the phrase "A monad is just a monoid in the category of endofunctors, what's the problem?" - a fun quote that a lot of monad explanatory tutorials will quip. Not that it will help - because anyone writing a monad explanation already suffers from the first quote: they're incapable of explaining them.
I had read 30 or 35 different monads-for-Javascript tutorials/guides/explanations before I finally thought I grokked it. None of them have helped and I'm still not sure my understanding of them is correct.
Because the point is mostly lost on the unrelated analogies most tutorial writers use. A monad is a mathematical construct. Trying to explain them in terms of what makes sense to you, because your analogy results from your understanding, isn't likely to be more helpful than outright accepting what they represent, mathematically speaking, then putting that to use in your code.
I tried my best to write a series of posts [0] demonstrating functional programming concepts using practical examples. I've found that Javascript is actually a decent language for learning about currying and monads, etc, because it affords you the ability to pick up a little bit at a time. You can learn one little trick and use it to improve your existing code before picking up another.
The nice thing about Monads is that once you learn the interface then encountering another is no big deal: you already know the API and how to use it. And it turns out this pattern is quite common.
While I agree, I've also found that it can be a danger. I thought I was all about the functional programming until I used languages that 'required' it. It was only then that I realized I'd been using non-functional escape hatches all over the place.
The thing is the general problem with software development right now:
What we know is "intuitive and simple". What we don't know is "off-putting and academic".
Terminology is incredibly important in computer science. If you make something that's kind of like a promise, but not "quite" a promise, and call it a promise, a lot of problems wil arise when people use your code or try to debug it. Monads are pretty simple (they're a heck of a lot simpler than promises). The terminology manners because they're all about interop. If you make something like a monad, but it's not quite a monad, you essentially lose all the benefits (that's the problem with promises).
Fantasy-land is a specification. It's meant for implementers, not for users. The important part is that people who build libraries that should work with other libraries also conforming to the spec, work well with each other. Take a look at some of the very simple constructs you might be used to, and how they are specified on the TC39's github. I'm quite familiar with the spec and I have trouble reading it, but I'm not the target audience. For the users, there are simpler resources.
As for the terminology, inheritance, polymorphism, overloading are all words that a lot of people are familiar with. I'd say the terminology is way worse, and the concepts are often a lot more complex, but people are used to them because it's what they're taught. Java put in monad-like constructs in their Optionals, and it's a lot friendlier...except when trying to compare 2 libraries doing the same thing using 2 different 'friendly' terminology, it's hell. It's not about being academic or elitist, it's about being precise. Something I can google for without having to sort through 16 pages of unrelated crap.
Google for monads, you'll get a lot of relevent material. Google for "optionals", and now you have to precise which language you're talking about, and in some cases potentially which library.
If you want a friendlier intro, look up "Functional programming in javascript" by luis atencio. It's fantastic.
At the end of the day, you don't need to know what dynamic method dispatch is to use it. Only the implementers need to :) This is the same thing.
Finally, yeah, some stuff look like "enterprise java". And there's a reason "enterprise java" existed: not all problems are easy. Some companies have hard problems to solve. Maybe it wasn't the best way to solve those problems, but a vanilla Rails REST api probably is worse. That doesn't mean everyone needs those solutions, but its nice that they exist. In this case, most people wouldn't have felt much difference if promises had been monads. But for the people who need monads, they're worse off by the current state of things.
First, going straight to "How do I understand Monads?" is not a good idea. I remeber when this article showed up on the web, and I remember wishing it had been written before I started learning Haskell:
If you want to understand monads, start hacking and watch for patterns.
> But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff.
Yeah, and here's my take on why it looks like that:
First, the terminology is all borrowed from mathematics, hence the academic tone. People can debate on the merits of this; I think it makes more sense when you're making tools for folks who are already familiar with the usual notation, but e.g. if you're not dealing with people who are already accustomed to the way physisicts talk about things, "p" is probably not the best variable name for momentum, traditional as it may be.
The authors of that document seem to have gone even farther in that direction than the Haskell folks -- Setoid? really? It's just fing equals! even Haskell calls it Eq. At least they kept Ord.
Also, the design looks to be basically transliterated from Haskell. There's been no attempt to adapt it to either javascript's strengths or its weaknesses. For example:
Conceptually a monoid is a special case of a category, but it's fiddly to abstract out the commonalities in Haskell because of the way the type system works. In javascript you could basically collapse the two, with id == empty and concat == compose. You might still want a blurb in there somewhere about the differences; not every category is a valid monoid, but there's no reason to have a whole separate hierarchy with different method names.
* The whole TypeRep thing they talk about is a complication that is unnecessary in Haskell; having methods that aren't attached to an extant value is just a non-issue, because the compiler can figure out which one you mean based on the types.
The libraries were designed around Haskell, and they lose something in translation. One of the things that kept in that thread was why not build some experience using these patterns before writing a spec? I tend to agree.
The other thing is that it is a big pile of abstractions. Even when working in Haskell, though I am more or less familiar with all of the type classes on that chart, I've only really had call to use 9 of them. Including Eq(Setoid) and Ord. The abstractions can definitely get to be a bit much.
There is some real use for this stuff; here's one I find kindof shiny:
...but I would say these abstractions are as applicable to day to day programming as the rest of computer science -- no more and no less.
I'm with you on the complexity allergy thing. Lately I've been doing some stuff in elm[1], and the simplicity has been a wonderful breath of fresh air coming from Haskell. I might recommend it if you're curious about functional programming. Some of the same ideas are sprinkled throughout the libraries; every time you see a function called "andThen," there's a monad lurking there, but because elm doesn't have type classes, you won't find anything called Monad. The flip side is you end up writing more boilerplate than you would in a language that can abstract these things away.
I think a lot about moving closer to technology hubs and there is definitely a desire to generally work day-to-day with excellent engineers in close quarters. However, each time I do rocking chair thinking, I come back to the same conclusion; our lives are more rich with family and friends and the lifestyle we are able to gain via the lesser cost of living. Though, I admit it has a large potential cost on career. I'd love to be slinging Haskell day-to-day, in SF, etc for the rest of my life on a professional level.