I actually enjoy this part, where I’ve written some intricate code of sorts and get to spend some time writing a memo that explains how it works.
I usually don’t even end up reading them, because the process of writing a good memo will make me remember it.
Not running any LLMs, but I do a lot of mathematical modelling, and my 32 GB RAM, M1 Pro MacBook is compiling code and crunching numbers like an absolute champ! After about a year, most of my colleagues ditched their old laptops for a MacBook themselves after just noticing that my machine out-performed theirs every day, and that it saved me a bunch of time day-to-day.
Of course, be a bit careful when buying one: Apple cranks up the price like hell if you start specing out the machine a lot. Especially for RAM.
Don’t worry, referring to yourself in third person gives enough of an impression that what you answer probably matter all that much.
I wholeheartedly agree: In my job, I develop mathematical models which are implemented in Fortran/C/C++, but all the models have a Python interface. In practice, we use Python as a “front end”. That is: when running the models to generate plots or tables, or whatever, that is done through Python, because plotting and file handling is quick and easy in Python.
I also do quite a bit of prototyping in Python, where I quickly want to throw something together to check if the general concept works.
We had one model that was actually implemented in Python, and it took less than a year before it was re-implemented in C++, because nobody other than the original dev could really use it or maintain it. It became painfully clear how much of a burden python can be once you have a code base over a certain size.
I have next to no experience with TypeScript, but want to make a case in defence of Python: Python does not pretend to have any kind of type safety, and more or less actively encourages duck typing.
Now, you can like or dislike duck typing, but for the kind of quick and dirty scripting or proof of concept prototyping that I think Python excels at, duck typing can help you get the job done much more efficiently.
In my opinion, it’s much more frustrating to work with a language that pretends to be type safe while not being so.
Because of this, I regularly turn off the type checking on my python linter, because it’s throwing warnings about “invalid types”, due to incomplete or outdated docs, when I know for a fact that the function in question works with whatever type I’m giving it. There is really no such thing as an “invalid type” in Python, because it’s a language that does not intend to be type-safe.
For anything mathematical, the fact that Fortran has integrated support for doing math on arrays is absolutely fantastic
Looking at the general quality of YouTube videos, and the expected demographic of people that would select this option, this looks like a recipe for creating the most conspiracy-theory-oriented AI ever created.
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”.
Yeah, I guess I’ve got to leave it like that now…
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.
set -e