Seems like this version hides or deletes your queries with a push to some cloud login. I'll be looking for an alternative if this is the direction Insomnia is headed.
I view Ramda as a redflag in most any code base I see it in. Anecdotally, every large codebase I have worked with that heavily used Ramda is generally held together by one very smart engineer. Once that engineer leaves the company, the code base falls apart because no one else can understand it very well and it takes ages to fix bugs or ship new features. So these days I champion against Ramda simply because I think it just takes to much effort for a typical engineer to understand and it is usually at odds with the rest of the companies code.
Sounds like you've worked with people abusing Ramda. It's not that complicated when used as a utility library rather than some hard FP approach to programming...
I've been using Ramda for years and I'm really struggling to see how any of the code in our projects have been complicated by it vs lodash or any other similar utility library.
But then why use Ramda at all then? There's plenty of non dogmatic libs that don't try to get you to curry your functions and spice your parameters and traumatize your children or whatever. Ramda encourages (in its official docs) unreadable code for the sake of style purity...
Because I prefer the FP style, arg orders, name schemes, documentation, and Ramda is just generally very clean and simple. And you absolutely do not need to use currying when using Ramda. It's entirely optional (just pass 2 arguments...). I tried it a couple times using Currying with Ramda but it mostly makes confusing code so I never did. That was probably 7-8yrs ago and I still use the library daily.
Idk what type of code bases you guys have worked on but I've never had anything close to a situation where it complicated my Codebase or had other devs who were confused by it.
I can imagine someone abusing currying and getting fancy with 10 levels of functions wrapped in another function that gets passed around but honestly that is just bad programming.
Simplicity and clarity is something that is necessary in all programming, FP is not unique, and this library doesn't push you one way or the other, unless you use it for absolutely everything.
> And you absolutely do not need to use currying when using Ramda. It's entirely optional (just pass 2 arguments...)
I think this would be my only argument against Ramda vs something like Lodash, at least in a project with other contributors. Like, I’ll never use the currying because it doesn’t appeal to me. But if another engineer does, and uses it extensively, then we have a situation of “because it was easily available, someone did something that makes the rest of us have to stop and pick apart during review/debugging/whatever”.
I kind of worked in a place similar to this. But I think having someone who understands engineering as opposed to just functional programming is important. The codebase I worked on was quite functional, written in TypeScript with libraries like fp-ts, io-ts. It did take a while to figure out some of the things, but ultimately I think the engineer who was leading really understood not to go full pure Haskell-in-JS since others on the team weren't hardcore FP programmers.
How far can this argument be extended? We can go back to vanilla JS/HTML/jQuery; these are all "easy to understand" things. But then too much spaghetti code builds up and then progress grinds down (much like in the Ramda team situation). You need some abstraction and order to maintain consistent productivity levels over the long-term.
I might also argue that sometimes writing the same dumb basic declarative code 20 different times is still faster and easier to read, debug, and maintain than trying to write one master class to handle every possible edge case.
IMO it's one thing if you're writing an engine or library where you have to ensure extremely high quality and good coverage. Or maybe you just work for an incredibly well run outfit where newcomers are deeply trained in the ins and outs of your codebase and style. But no place I've personally worked with has been like that.
If you're just building a bog standard business app for a small or medium business, I don't think purity of code is typically the primary bottleneck. Likely turnover and poor documentation and lack of on-boarding and sudden frequent pivots will be bigger deals, all of which are significantly complicated by over-abstracted code that can't be modularly changed by a single developer.
People worked with vanilla HTML and JS for decades, maybe using server side includes for some basic DRY. It wasn't pretty, it was hecka tedious, but it also wasn't Inception-level nightmarish like some modern abstractions are. There's an ideal level of abstraction for a given team and codebase, IMO, and it's not always "more abstraction is better" (not that you were arguing that). It's just a process of discovery and design by fire that gets you there, not usually a lone genius that produces a masterpiece in any one particular style.
If you use something like redux toolkit query, it already abstracts that for you using Immer internally. You can just write a simple arrow function or use lodash or underscore or whatever pleases you.
I've also been drinking 2.25l of coke zero every day for 5 years and it has been a game changer for both weight and oral health. Previously i required fillings quite frequently and none over that period. Obv nobody should drink any soda if they don't have to but if replacing consumption of sugary drinks it's extremely effective for health gains. And most of the anti sugar-free soda studies are bro science.
This sounds like a really bad idea. With orange juice it takes less than 30 seconds to differentiate the versions. If this was done with something like Microsoft Word you would probably have to spend the better part of a day teasing out exactly which features you needed or wanted. I think a semi relevant modern example would be how the release of hitman 3 worked out. They had to make a flow chart of how to buy the right copy of the game with the features you wanted.
> They had to make a flow chart of how to buy the right copy of the game with the features you wanted
"They" makes it sound like IO Interactive (developers and publisher of Hitman) made that flow chart for people to use, but in reality it's community made by someone from Reddit.
And to be honest, it doesn't seem that complicated, seems like a joke flow chart to make it more complicated than what it is. These editions seems to exists (for the record, I have neither and first time I hear about them):
- Trilogy Premium Add-ons Bundle
- Trilogy Edition
- Standard Edition
- Deluxe Edition
- A DLC
Trilogy obviously is about the full series (1 to 3), and Deluxe edition contains "Deluxe Pack". Which one you want? Ok, want the DLC too? Ok.
I wouldn't say its inferior by any means. I think the biggest difference is accessibility. When one uses weights, progression is very simple, just increase the weight. With body weight exercises one must switch exercises to increase / change the leverage and make the exercise harder to continue progression. A good example of this is going from a regular push up, to a diamond pushup, then moving toward pseudo planche pushups. The move from regular to diamond is not too bad as you only need to move your hands closer together, but to make progress towards PPPU, you have to learn how to do a planche lean forward a tiny bit more each time you attempt PPPU's eventually moving your hands from under your shoulders to practically under your hips for generating the push motion. So I guess the main point is body weight exercises require more study and coaching generally to see progression than exercises with weights and the progression you do see is less noticeable than simply adding more weight each time you workout, but they are both very good at gaining strength.
Interesting, so the acquisition agreement did not have a non-compete clause or golden handcuffs to Slack? If you don't mind me asking, how come you left Slack?
(I'm not affiliated with either Slack or ScreenHero. But I loved ScreenHero.)
It would be common for an acquisition agreement to shackle the founders with non-competes. It would also be common for those non-compete clauses to have limited durations. (I have seen 2-3 years in documents.)
Slack bought ScreenHero over 4 years ago. The non-competes have likely expired.
Agreed. I'd be happy if they brought their video chat up to the standard Screen Hero set. It was one of the best pieces of software I remember in recent years.
