Fork me on GitHub
#off-topic
<
2023-10-02
>
pesterhazy09:10:45

When I want to back out some changes from a branch (basically, revert a file or folder back to its original state before I messed with it on the branch), I use this alias:

unchange = "!f() { git checkout $(git merge-base master head) -- \"$@\" ; } ; f"
E.g. when I do git unchange foo.clj, this makes sure it disappears from the github diff Is there an easier way to do that?

p-himik09:10:41

I'm probably missing something - why is plain git checkout foo.clj not enough?

pesterhazy09:10:15

My use case is changes that are already committed to a branch. I want to remove them from the branch My understanding is that plain git checkout works only uncommitted changes

pesterhazy09:10:42

(And I just tried it and it didn't do what I wanted)

p-himik10:10:10

Ah, gotcha, I misunderstood the premise. Your approach makes sense. And while I don't know for absolute certain that there's no easier way to do it, FWIW I doubt that there is.

p-himik10:10:41

The only thing I'm not sure about at all is whether the function is really needed. Why not just !git checkout ...?

pesterhazy12:10:31

Somehow that didn't accept any extra arguments, not sure why. In other words I don't understand how git aliases work

p-himik13:10:49

Hmm, seems like having $(...) in there necessitates either an function or sh -c, TIL. Regardless of how I tried creating an alias and escaping that part, it always results in Git complaining that either $(...) is not a valid revision or that there are four arguments to checkout.

vemv14:10:21

Your unchange function seems reasonable to me (I'm saying this as someone with a pretty scary collection of Git helpers)

pesterhazy14:10:43

tell me about it!

telekid14:10:19

I remember reading a recent blog post a few weeks ago that made a compelling argument against the need for DI frameworks in Clojure, but now I can't find it. Does this ring a bell for anyone?

Frank Henard14:10:08

DI frameworks... are you speaking of things like integrant, component, mount, etc?

mauricio.szabo14:10:10

I can give my 2 seconds inspiration: if your external IO stuff is too small (like, 2 to 4 services) you probably will complicate the loading of the app for no particular reason. I like the idea of Integrant/Component/Mount that you can make one service a dependency of the other - I just don't see the need for that in most cases. Usually, "load everything and start the server" works well enough...

1
telekid14:10:54

> Maybe this? That was the one!

emccue14:10:08

i think the manual stuff i outline here works more or less still

Ben Sless14:10:11

I think the interesting/annoying problem isn't solved cleanly by any framework which is separation of pure code from effects. DI isn't a value, it's a tool to be able to reason about your system, debug and test it. reloaded is a bonus, sure, but not the main course imo. Haven't found a good solution yet

2
👍 1
telekid15:10:05

> separation of pure code from effects Much as I love clojure, I don't expect this to ever be solved here. Too many of the language's other values (JVM interop, dynamic typing) are working against it

Ben Sless16:10:42

It's a "terms and conditions may apply" sort of aspiration. It either ends up looking like a state machine, dataflow graph or side effecting components taking data, passing it through pure functions, doing side effects, processing them through pure functions, then passing them on to other components

pesterhazy09:10:05

@U3JH98J4R just wanted to say thanks for writing that blog post. This is truly a great introduction to DI. What I like most about it is that it starts from problem statements rather than launching into tools right away

pesterhazy09:10:52

In terms of interesting work on DI in Clojure, I think DIME is worth looking into as well https://speakerdeck.com/kumarshantanu/clojure-2016

🙏 1
telekid11:10:51

Yeah @U3JH98J4R that post is great

jpmonettas16:10:10

Damn reddit AI bots

Ben Sless16:10:23

spam it with replies to eat up their API limits

💸 2
henrik16:10:55

Dear name, thank you for sharing this very funny image in the #C03RZGPG3 channel at Clojurians Slack. Haha! I too share the sentiment that reddit AI bots. We’d love to have your wit and intelligence over at Leonard’s Developer Honey Pot.

13
6
👏 2
1
p-himik21:10:01

I struggle to fathom the endurance of Swift developers. I'm exposed to it every now and then via one of my clients, and holy hell is it a nightmare. It's just C++ from a slightly different perspective, which is still evolving along with its whole ecosystem. You can't just get the first item of a collection - you have to know exactly what the type of that collection is. You can't know the type without a working IDE because most of the things are defined in extensions god knows where, extensions that you don't even have to import. You can't have a working IDE because there's no other real choice than Xcode and Xcode isn't working all that well (on a fresh install, just now - one crash, one hang, one "dependency not found", and after a cleanup of some cache that "you need to clean up every time you have a problem, which is all the time", that one error turned into three).

Martynas Maciulevičius21:10:59

> extensions that you don't even have to import Sounds like Scala's implicits. But the thing with implicits is that you have to import them. But you don't know where they are if you're writing fresh code :thinking_face: > the endurance of Swift developers Are you paid enough? I think pay increase increases endurance quite a bit up to some extent. > extensions that you don't even have to import Maybe it's a language for whoever has 10y background of C++ and just know by heart where everything is located? If not then this means that the location is opaque and then your issue belongs in this discussion: https://reddit.com/r/Clojure/comments/16qso0q/inspired_by_seancorfield_comment_i_did_several/k1yy731/?context=3

p-himik21:10:16

They used a UI table implementation that was incredibly buggy. I don't know how it's possible, but that table impl got released by Apple. I don't recall all the specifics but the new table implementation, less buggy, requires the latest version of macOS. So now everyone on a slightly older version is screwed. Using a newer macOS necessitates a newer Xcode. A newer Xcode changes the format of the project file, which results in the need for every single developer to switch to the newer version, along with updating their whole macOS. All just to be able to read the code. > Are you paid enough? I think pay increase increases endurance quite a bit up to some extent. Well enough to not even consider a job at FAANG. But I also don't really have to deal with Swift, fortunately. I'd probably make my rate at least 3x on good days and 5x on bad days to consider properly writing Swift. It's a health hazard at this point.

Max21:10:38

The worst part is afaik swift is the only language that handles Unicode strings correctly by default. Also it can’t be worse than objective-c. I’d imagine mobile devs are so deep in the Stockholm syndrome at this point that it doesn’t even register

Max21:10:26

Also Swift devs are probably just as excited about swift as frontend devs are about js/ts. On the backend we are truly blessed with an abundance of choices, if swift/js/kotlin is all you’ve ever known then you don’t know what you’re missing

p-himik22:10:54

The funny thing about strings in Swift is that you can't just deal with strings. If you have lots of string manipulations, you have to use stuff like .utf8 or .utf16 or .withUTF8 or some other crap. Stuff that is still being changed, but libraries rely on for efficiency and then get broken on a new version of Swift. It's not something rare, it's something that seems to be everywhere in the Swift's ecosystem.

Max22:10:59

Sure, perhaps they got it right by accident, but broken clocks etc etc

p-himik22:10:01

> On the backend we are truly blessed with an abundance of choices Oh, that particular client is now in process of writing a Swift-based alternative for the service I've written in Clojure. :) Fun stuff.

facepalm 5
Max22:10:57

People write backend js too 🤪

laughcry 2
seancorfield22:10:02

Xcode alone is a hell not worth 2x my salary! At work, we build Android and iOS native apps, using React Native, because that seemed to be the least painful way to expand our React.js frontend into the app markets. Android can be painful but overall it isn't too awful. But iOS means Xcode and it is absolutely awful about randomly rewriting parts of your project files and if, like us, you build multiple apps from a single codebase, it will randomly change things so you end up building the same app repeatedly, even when you are trying to build different apps. Our frontend folks have nightmares every time they need to build and deploy updated versions of our (ever-expanding) suite of iOS apps...

p-himik22:10:39

Ah yes, there's a monorepo that houses a few apps, services, and libraries. :)

mauricio.szabo22:10:52

@U01EB0V3H39 if I'm not mistaken, Elixir handles it quite well too... well, unless you need to interface with Erlang

mauricio.szabo22:10:28

I was working with a react-native (non-expo) project in one previous job. Honestly, the whole ecosystem is trash - Apple changes things a lot and not only code - sometimes they changed their contract/terms and suddenly you can't compile your code anymore until somebody that have a lot of permissions just accept the new terms... Android have Gradle... which is a personal hell in itself. Project stops building, for no reason, and only on a specific developer's machine (or worse - it only builds on that specific developer's machine). Then, you run clean, cleanAll, do some voo-doo magic, promise to never add a new library again and to behave yourself, and when you're done and decide to pair with someone, the stupid thing simply... works...

Max23:10:47

@U3Y18N0UC I didn’t know about elixir’s Unicode handling, it does indeed look correct. Thank goodness someone does it right other than swift

Max01:10:14

Yeah, I think people can get used to anything. I hear some people even still use emacs! trollface

hifumi12303:10:56

I actually enjoyed writing Objective-C. Swift not so much since it reminds me of everything I dislike about C++ and Java-style OOP 🙂 And Swift’s ABI was a huge moving target until very recently with Swift 5. It’s also somehow worse than C# at being “cross platform” despite Apple marketing it as cross platform on their own website!

👍 1
lassemaatta10:10:40

eugene, you would have loved working with symbian /s. I think there were at least a couple of dozen different string classes (and conversion functions between the types) depending on whether the chars were 8-bit vs 16 bit, whether the string buffer is in the stack or in the heap, whether the string object itself contains the string data or just a pointer elsewhere, whether the string is mutable etc.

p-himik11:10:49

Oh, it's not that different in Swift if you need to work with the raw data at any point. :D There are 8 types of pointers, and then there strings with different views into their data, there are arrays, and there's Data class. (The latter is fun by itself - there are methods to get its contents as an array in a shuffled or sorted manner, but you can't just get an array in the original order, or at lest https://www.cocoaphile.com/posts/turning-data-into-arrays-in-swift/). What adds to the insult is the fact that Swift is still changing - there's plenty of code to go around written for 1.x, 2, 3, 4 - code that might or might not work (probably the latter). All those classes and approaches are probably needed for one reason or the other but boy am I glad to not have to deal with that nonsense.