I use GPT in the sense of “I need to solve X problem, are there established algorithms for this?” which usually gives me a good starting point for actual searching.
Most recent use-case was judging the similarity of two strings: I had never heard of “Levenschtein distance” before, but once I had that keyword it was easy to work from there.
Also: cmake and bash boilerplate
Fair enough, git clean does exist. However, if the button saying “discard all changes” is really a button that runs git clean, that’s just a plain terrible design choice. git clean is “delete all untracked files”, which is specifically not discarding changes, because there can be no changes to discard on an untracked file. Even talking about “changes” to an untracked file in VC context makes little sense, because the VC system doesn’t know anything about any changes to the file, only whether it exists or not.
That’s not even mentioning the fact that the option to “git clean” shows up as one of the easily accessible options in relation to a staging process. Especially if you’re coming from the git CLI, you’re likely to associate “discard changes” with “git restore”.
Got will not delete untracked files though, which is what happened here. If you want to discard changes to a file with git, you first have to commit the file to the index at some point, which means there’s only ever so much damage an erroneous “git restore” or “git reset” can do. Specifically, neither of them will delete all the files in an existing project where VC has just been added.
If you have set up your staging area for a commit you may want to discard (unstage) changes from the staging area, as opposed to discarding changes in the working directory.
Of course, the difference between the two is obvious if you’re using git CLI, but I can easily see someone using a GUI (and that maybe isn’t too familiar with git) misunderstanding “discard” as “unstage”.
Either way, what happened here indicates that all the files were somehow added to the VC, without having been committed first, or something like that, because git will not let you discard a file that is untracked, because that wouldn’t make any sense. The fact that the GUI let this person delete a bunch of files without first committing them to the index is what makes this a terrible design choice, and also what makes the use of the word “discard” misleading.
I use gitkraken for two primary purposes:
Having a visual representation of my project history.
resolving merge conflicts
Of these, the first is really the only thing I really want a GUI for. I’ll just have it open on my side-screen if I’m managing some more or less messy branch structure or quickly want an overview of what has been done on which branches, where common ancestors are, etc. All the actual doing of things is done from the CLI, because it’s just better for that.
Watch me: My void* doesn’t give a shit about your const!
I have to be honest in that, while I think duck typing should be embraced, I have a hard time seeing how people are actually able to deal with large-scale pure Python projects, just because of the dynamic typing. To me, it makes reading code so much more difficult when I can’t just look at a function and immediately see the types involved.
Because of this, I also have a small hangup with examples in some C++ libraries that use auto. Like sure, I’m happy to use auto when writing code, but when reading an example I would very much like to immediately be able to know what the return type of a function is. In general, I think the use of auto should be restricted to cases where it increases readability, and not used as a lazy way out of writing out the types, which I think is one of the benefits of C++ vs. Python in large projects.
The amount of people I’ve been helping out that have copied some code from somewhere and say “it doesn’t work”, and who are dumbfounded when I ask them to read the surrounding text aloud for me…
Along the same line: When something crashes, and all I have to do is tell people to read the error message aloud, and ask them what that means. It’s like so many people expect to be spoon-fed solutions, to the point where they don’t even stop to think about the problem if something doesn’t immediately work.
While I do agree with most of what is said here, I have a hangup on one of the points: Thinking that “docstrings and variable names” are a trustworthy way to indicate types. Python is not a statically typed language - never will be. You can have as much type hinting as you want, but you will never have a guarantee that some variable holds the type you think it does, short of checking the type at runtime. Also, code logic can change over time, and there is no guarantee that comments, docstrings and variable names will always be up to date.
By all means, having good docstrings, variable names, and type hinting is important, but none of them should be treated as some kind of silver bullet that gets you around the fact that I can access __globals__ at any time and change any variable to whatever I want if I’m so inclined.
This doesn’t have to be a bad thing though. I use both Python and C++ daily, and think that the proper way to use Python is to fully embrace duck typing. However that also means my code should be written in such a way that it will work as long as whatever input to it conforms loosely to whatever type I’m expecting to receive.
Well if you need something to work with Fortran…
The whitespace doesn’t bother me at all, but holy hell! Any time I’m trying to understand a Python program/library that’s anything above a couple thousand lines of code, I instantly feel a burning hate for dynamic typing.
I love Python for scripting- in large part because of dynamic typing. IMO it’s just not a language made for building large infrastructures.
Sorry, but I honestly don’t get it. I I were to point out the crown jewel of open source, it’s gcc. gcc is the backbone and survival condition for so much modern industry that it’s not even remotely funny.
Take away gcc, and the world will likely burn for a substantial amount of time until people start making in-house or proprietary alternatives.
Don’t do that in Norway either - just bad luck if the holidays happen to land on a weekend. On the other hand, we have five weeks of paid vacation, and holidays are not counted into those, I’m not sure how that’s done in other countries?
I feel like it has something to do with the fact that there’s less content, so when you post something, it’s actually going to be seen by people.
I didn’t post or comment anything the last couple years on Reddit, largely because it increasingly felt like shouting into the void.
I am/was in the same boat as you: For a long time, I just didn’t care that I was giving away a bunch of information in return for convenience, and didn’t get why people cared so much.
I don’t really know what triggered it, but at some point I became painfully aware that the only goal these companies have is to squeeze every possible penny out of selling me. I started noticing that the stuff they ask you to confirm is 95% stuff they want because they can sell it, or use it to get you hooked to their service, and 5% (at best) stuff they need to make the service good for you.
This triggered a change in my perspective: Now it pretty much makes me sick to my stomach to think about all the companies that are drooling over me, trying to make a buck by getting me to click something I’m not actually interested in, or don’t actually need.
These people have a vested interest in manipulating me, and by giving them my data, I’m giving them the tools to do it. I don’t want to be manipulated or sold as a product: That’s what made me start caring about protecting my data.
This will sound dumb, but I’m saying it sincerely.
I’ve had similar issues (without getting into details), but what worked for me was getting outside a couple times a week. By that I mean bringing a tent or hammock + tarp and sleeping outside a couple nights a week on workdays.
To be specific: I sleep outside Monday-Tuesday and Wednesday-Thursday. On those days I also make my dinner at my campsite. What I’ve found is that my brain goes into a much more “primal” state of “monke outside in cold, monke get shit done”, and that it propagates into my day and week.
The barrier to this is of course actually going outside, but I’ve been able to get to a place where I have a “deal with myself” about those two nights a week. I always have my pack ready, so it’s just about grabbing it and heading out- I think that’s key.
I’m not saying this is a solution for everyone, but it’s done wonders for me. As of now, I get restless and feel bad if I’m in a situation where I can’t get outside at least once a week. It brings me a peace of mind and will to get stuff done that nothing else can.
That’s what major versions are for - breaking changes. Regardless, you should probably be able to fix this with some regex hackery. Something along the lines of
new_file_content = re.sub(r'(?<=\bprint)(\s+)(?!\()', '(', old_file_content)
new_file_content = re.sub(r'(print\(.*?)(\n|$)', r'\1)', new_file_content)
should do the trick.
For someone starting out, I would say that a major advantage of Python over any compiled language is that you can just create a file and start writing/running code. With C++ (which I’m also a heavy user of) you need to get over the hurdle of setting up a build system, which is simple enough when you know it, but can quickly be a high bar for an absolute beginner. That’s before you start looking at things like including/linking other libraries, which in Python is done with a simple import, but where you have to set up your build system properly to get things working in C++.
Honestly, I’m still kind of confused that the beginner course at my old university still insists on giving out a pre-written makefile and vscode config files for everyone instead of spending the first week just showing people how to actually write and compile hello world using cmake. I remember my major hurdle when leaving that course was that I knew how to write basic C++, I just had no idea how to compile and link it when I could no longer use the makefile that we were explicitly told to never touch…
Yes, it’s a field. Specifically, a field containing human-readable information about what is going on in adjacent fields, much like a comment. I see no issue with putting such information in a json file.
As for “you don’t comment by putting information in variables”: In Python, your objects have the __doc__ attribute, which is specifically used for this purpose.
It makes sense when you think about it too: It’s a language model, so it should be expected to do a decent job as a glorified dictionary