I do the same with Python, replacing multilevel comprehensions with intermediary steps of generator expressions, which are lazy and therefore do not impact performance and memory usage.
Ultimately it will depend on the functions being chained. If they can work with one part of the result, or a subset of parts, then they might not block, otherwise they will still need to get a complete result and the lazy cannot help.
Sigh. Another git thread, another pile of posts telling me that if I would _just do the work_ to understand the underlying data structure I could finally allow myself to be swept up in the _overwhelming beauty_ of the something something something.
The evidence that the git UI is awful is _overwhelming_. Yes, yes, I’m sure the people that defend it are very very very very smart, and don’t own a TV, and only listen to albums of Halloween sounds from the 1950s and are happy to type the word “shrug“ and go on to tell us how they’ve always found git transparent and easy. The fact is that brilliant people struggle with git every single day, and would almost certainly be better served by something that makes more sense.
GP isn't describing the underlying data structures, they're describing the basic interface of commits, branches, and tags. The 101 stuff you have to learn regardless, for any version control, not just git. Dismissing it like this just sounds like someone who refuses to hold scissors by the handles.
You’re right, of course, and I apologize to GP for conflating what they were saying with what I, to be fair, do often see in these threads.
Like others in these comments, I can use it just fine right up until I can’t. Then it’s back to the mini, many, many posts and questions and tutorials, sprawled across the Internet to try and solve whatever the issue is. JJ has shown that a better chrome can be put over the underlying model, And it’s frustrating to me that we are all collectively, apparently, expected to put up with a tool that generates so much confusion seemingly regardless of brilliance or expertise
There are tools for the UI part. Most people I know only use command line git for doing stuff where GUIs give up (i.e. fixing repos in weird states). Usually, checking out a clean clone and switching to that will do the same without the GUI, just takes a bit longer if you know the command line fixes.
The issues most people seem to have with git are common version control issues. Version control is actually hard, even if it's just "what has changed", once you start going beyond two users editing a file at once. When three people edit a file at the same time, there's going to be complexity when those changes need to be applied back, and that's where you start getting into branching/merging/rebasing.
Just like some people simply cannot get functional programming/object oriented programming/imperative programming to click in their head, others will never truly grasp version control. It's a paradigm of its own. People who know lots of data structures like to trivialise version control into data structures ("it's just a list of ...") but the data structures are the chosen solution, not the problem.
Another complexity issue is that git is actually pretty smart, and will fix most problems automatically in the background. Often, when you need to manually operate on a git repo, you're in a situation where git doesn't know what to do either, and leaves it up to you as the expert to fix whatever is going on. And frankly, most people who use git are nowhere close to experts. The better Git tooling gets at fixing these situations for you, the worse your situation will be once you need to manually correct anything, and the worse your perception might get.
I have no good advice for you on how to work Git better. All I can say is that I'm very productive with Jetbrains' IDE integration, others seem to prefer Visual Studio Code's git integration, and then there's the Tortoise people. Find whatever tool works best for you and hope you'll have a random epiphany one day.
perhaps it is time to take some personal accountability instead of lamenting the complexity in order to avoid the (overwhelming) challenge and learning.
yes, to understand an application, you must also understand the underlying data structures, architectures, models, use cases -- i am not sure what there's to roll eyes at. but there's no requirement that says that understanding has to be deep in order to work on it, or use it.
i think if you treat it like cleaning a large room, by picking out one corner at time and focusing on cleaning that before moving on, you'll find that the room is cleaned in no time, and git isn't anywhere nearly as complicated as it may feel.
there is absolutely no reason to digest a guide this dense for use-cases in every day production settings, bc those usages only make up about 10% of what this guide covers.
yes, learning things can be overwhelming, challenging, full of darkness and terrors, but that's what learning is, until you've learned.
but here is the catch imo: once you've learned, you don't stop learning and the challenges don't go away. you just become better at navigating the darkness, bc you get better at learning and managing feelings of overwhelm and confusion which are by products of complexity -- real or perceived or both.
jump in. it ain't that scary, even if it feels scary. i promise. i've been there, and you can overcome it.
Pretty much, yeah. Just do the work. It's not nearly as hard as whatever it is you're committing into it, I promise. Continuing to mock it via florid metaphor doesn't help anyone at this point.
I'm always kind of aghast at the number of people who not only don't know git, but who cannot or will not learn it over years, or even decades.
Listen, I'm not that smart, and I managed to figure out how to solve even gnarly git issues one summer during an internship... 11 years ago? Ish? Now, I know git well, and not just "the three commands". I would be, honestly, so ashamed if it were a decade on and I still hadn't committed to learning this fundamental tool.
Version control is a hard problem, fundamentally, and a tool for experts will always take more effort to understand. I mean, aren't we supposed to be the software experts? If people can't learn git, I wouldn't trust them with the even harder parts of software development.
But this is a common attitude in industry now, unfortunately: a petulant demand for things to be easier, and for someone else to do the learning. Is it any wonder software today is so bad?
If people can't learn git, I wouldn't trust them with the even harder parts of software development.
This idea breaks under pressure. People have limited concentration and the more you demand for daily routine, the less there’s left for the actual job. This argument only makes sense in a relaxed setting with lots of time and coffee breaks. But all these problems tend to happen at friday evening when you’re expected to get your kids in an hour or something and this damn repo got broken again.
Yes, things should be easier. Cause you get what you get. If you want people who have no issues with git, feel free to enjoy the greatly reduced hiring pool and stop whining about someone not being able to juggle fifty things at once in their mind - focus on your hiring process and where to get the budget for inflated compensation instead.
Is it any wonder software today is so bad?
I remember delphi and vb time, when people - who were unable to understand or use CVS and SVN - made full-blown apps for real sectors, and it worked. Because it was easy. Nowadays all we have is important dudes with pseudo-deep knowledge of git, css, framework-of-the-month and a collection of playbooks, who cannot make a db-enabled hello username message box in less than a day. I don’t think you’re moving in the right direction at all with this. This paradigm is going further and further from good software, actually.
> Nowadays all we have is important dudes with pseudo-deep knowledge of git, css, framework-of-the-month and a collection of playbooks, who cannot make a db-enabled hello username message box in less than a day.
Interestingly that is exactly the opposite of my experience. Git is a practical tool with practical appeal to people who want to do practical things. Egghead gedankentheorists hate it, as evidenced by this very subthread.
In point of fact I find the ability to accomplish workaday tasks with git to be a far better predictor of someone's success as a developer than stuff like being able to recite Rust minutiae. People who like git are people who like getting stuff done.
People, whom I knew since these times and who really like getting stuff done and have done it much, all facepalmed when seen things like git, webdev, etc. Getting stuff done is not performing hundreds of technical operations and thinking “good, I’m so skilled”. It’s actually getting it done. I can almost guarantee that it’s a guy with far better predictor skills who will deliver mvp a month later than everyone else. Been through this countless times.
I don't struggle with git, and I can assure you, I am not brilliant. I do, however, refuse to give up when something seems hard, and I refuse to ask the computer to be easier for me. (Understandably, I started programming computers to make them do what I wanted them to do, not to sit and whine when they didn't.)
Which brilliant people, who have put in an appropriate amount of time into learning any (D)VCS, are struggling with having a day to day working knowledge/familiarity with git? Can you point to some? Brilliant people is of course a definition question. But one of the defining qualities I would ascribe to a brilliant person, is the ability to quickly grasp concepts and ideas and reason about them. That seems to me to be the core quality one needs to use git, since it requires one to have a mental model, whether actually correct (which I think few people have) or just close enough to be useful.
“Do you want to be a Writer, or do you want to write?” I think that almost any question of the form “Do you want to be an Xer, or do you want to X” is useful these days.
100%. As a kid growing up near a golf course I knew lots of kids who wanted to be a pro golfer (me too). Did they want to spend 10 hrs a day at the range hitting ball after ball? Not so much. Lots of people want to be Warren Buffett - do they want to read 10-ks for 10 hrs a day? Not so much.
I keep telling people to think of Rails as a “ruby-like” language. Rails monkey-patches so much and has so much magic that it’s substantially a different thing.
I'm kind of interested in this space -- can anyone point me at an article that goes over why this is harder for python than it seems to be for, e.g., ruby? Is there something inherent about the way code is imported in python that makes it less tractable? Or is it just that the python world has never quite all come together on something that works well enough?
(Note that I can certainly complain about how `bundler` works in ruby, but these discussions in python-land seem to go way beyond my quibbles with the ruby ecosystem)
The big problem is that Python is used in a lot of different contexts and has too many valid ways in which people are able to build, compile, release non-Pythonic extensions in their package. Original way for packaging code was effectively an executable script which made some things easy, but other things much harder. Modern efforts are trying to limit the flexibility of the package definitions without breaking all of this legacy code. I unfairly think of Ruby as only for Ruby on Rails, so only ever dealing with the web domain.
Here is a story about the nightmare it takes to compile the Fortran code that supports much of SciPy (backbone numerical computing library with algorithms for wide swaths of disciplines)
https://news.ycombinator.com/item?id=38196412
It's not. Just that Guido never cared about packaging, so it was left to a ragtag unpaid motley crew to piece together and later learn from industry practices that solidified a decade or two after they started.
Python's import system, as it is, makes some things slightly more complicated due to the need to use virtual environments (copies of the interpreter with separate library paths) as opposed to something like node_modules. This could easily be changed, if the powers-that-be actually cared about packaging. Packaging is handled by a separate group, which likes design by committee, and which enables the creation of separate third party tools instead of standardising on one good tool (uv, rye, and poetry, are all popular tools made by people who are explicitly not members of the packaging group).
Reminder to everyone commenting here: you are not an average student. The hard part of teaching is not coming up with dynamite lessons for kids who are smart and want to learn and are capable of doing so and aren’t hungry. Anyone can do that. Well, almost anyone.
Way back in the olden times, 5 to 10% of people went to school, and it worked really well for them. Now everyone goes to school, and it works really well for about 5% of us.
I promise you, this site is not as special as you think it is.
The majority of people here are incredibly average (like me!), just fortunate to be born at the right time, be exposed to technology at the right time, get a few other lucky breaks, and of course put some work in.
It’s super easy to convince yourself that because you’re successful you must be special. Remember that people tend to ascribe their successes to themselves and their failures to someone else.
You would be average if you actually thought this site doesn't have a selection bias out of the world population. If you think HN averages out to a middle of the pack student, people who spend their free time reading text, you have quite the social bubble around you. There's also like 25 $1b+ founder/ceo's out of 50k.
Believe it or not the world has a lot of people who are above average whose lives don’t revolve around computers. There’s just as many losers here as anywhere.
First part, of course, but since HN is only like 50k that doesn’t say much about HN.
Second part, there can forsure be many “losers” here but it’s quite ignorant to think there’s the same percentage struggling in math classes as the general population. Think about it. If you took 100 HN’ers where do you think they skew on succeeding on math tests or even taking classes like Calculus compared to gen pop? The average person even in the US doesn’t have a Bachelors degree. Do you think that applies to HN? Or that it’s not correlative with educational success?
I said that HN is mostly average students and I haven’t heard anything that changes my mind, regardless of whether you think a lot of people here are good at calculus. How do you think HN readers fared in art/literature/English classes?
Pretty fucking good, actually. That's why we're here writing copious amounts of text, more Bachelor's (a big general education) than average, reading articles, and upvoting ACX posts, someone who was top of the top in English class writing competency.
All that just to typo copious too, sheesh. 15 second long HN comments hardly reflect the writing strength of putting arguments to an essay. Or I guess IRC (Internet Relay Chat) folks are illiterate. So again, maybe you are the average ones if you think it's indicative of HN's success in their English/lit classes.
Even if you believe you have average intelligence, it's without doubt that there are many more students in school with lower motivation. To the point that getting them to write a paragraph is like pulling teeth. The difference between the students in the AP classes when I was in high school and the students in the A or B level classes was night and day in terms of just paying attention or being able to give any answer to a question.
There's only so much you can do to make a subject interesting when the students care so little about their education. It starts at a young age and just compounds. By the time you see them as students in high school, they're already years behind in motivation and education.
A lot of parents really, really like having kids. The ROI on having children is, for them, so self-evident that they don't really think about it. But that's not true for everyone, esp. if you were old enough to be pretty fully-formed by the time you became a father. Kids come at a huge cost. You're exhausted from dealing with them, and in the meantime you're probably not exercising, and you're eating like crap, and, inevitably, just plain getting older.
Step 1 is to reconcile your ideal of who you'll be in the future -- what job, how smart, how influential, etc. -- with the resources actually available to you now. I had to downshift considerably.
Your kids aren't going away, and you're not going to be able to sustain what you're doing now until they get old enough. You need to make a change, and soon, because if you don't you're going to end up wondering how and why you mortgaged your life to your goddamn kids.
I have three boys: 5, 8, and 10. For my first six years of having kids, every time someone told me to "enjoy them while you can" I wanted to punch that person in the throat. I knew they were right, but there are days when that's just not even in the realm of possibility.
There are a lot of parents who are tired, and sick of walking on dropped cereal, and miss being able to pick an actual restaurant that serves actual grown-up food. But there's also a huge societal more to not talk about it, or to aways end with something like, "But it's so worth it," or "It's the hardest job I've ever loved," especially for women. But while it's almost certainly "worth it" for the majority of parents the majority of the time, there are going to be days when it's just NOT.
The cliché is that "The years are short, but the days are long." It's true. In hindsight, the fact that I have a ten-year-old seems insane -- how could it have been ten years? What the hell have I been doing for the last decade? Do I even remember life before kids -- what it was like to just have a wife, to set my own schedule?
At the same time, every night at 6:30pm I find myself asking, "How can it only be 6:30?"
I spent a good number of years just basically resenting the crap out of my boys, which is about as healthy as you might guess. I hated dealing with my kids, hating myself for hating dealing with my kids, and knew I'd hate myself later for not enjoying the young-kid experience while I could. I, my kids, and my wife all suffered.
Now I've got therapy and some drugs and a CPAP, and things are better. Not every day, but most days. Well, many days.
Kids completely take over your life, at least for a while, and it's almost impossible to see the light at the end of the tunnel. Your job -- your JOB -- is to figure out how to enjoy them now so that the sacrifices are worth it to you.
This should be voted higher. It's not "passive-aggressive", as the empathy-deficient thatwebdude says, it's honest, if painfully so. There are plenty of days when a parent cannot in all honesty give the socially-mandated "But it's so worth it" appendix to the litany of perfectly justifiable complaints. It IS hard, exhausting, and does involve a recalibration of your expectations of life and yourself. Thank you for posting this, not many parents would be so honest. (In saying this I am not denying that there are other parents who can in all honesty say they love the whole process.)
No, it was a joint decision. I just figured I'd be more-or-less like my dad, who loves being a dad. It never struck me that it might be something I really struggle with.
Overall, it was the right decision for us. But there are definitely valleys along with the peaks.
reply