I only did haskell in a pre-req for a compilers series I took. It is a purely functional language with a shitload of recursion involved. Recursion can get you into trouble. It’s more of an educational language in my opinion.
Python doesn’t baby you with the duck typing and you can probably write a bunch of really disgusting code. However the IDE I’ve been using (used to be a purely vim + terminal guy, but for this video game I’m making, the IDE is way way better) can catch a lot of the dumb mistakes for you. Python abstracts away a lot of stuff that tends to get developers in trouble like memory management.
Theyre kind of like apples and oranges though. Python is really great at what it does.i really like its design philosophy and ease of use. For a devops person having a language in your toolkit that can do basically anything is always highly desired. Between bash, golang, and python I don’t think there are many problems I cannot solve.
All the IDEs I’ve seen have had some way to let you use VIM keyboard shortcuts.
I have never stuck with an IDE because they all run so damn slow on my cheap computers. I guess because I don’t play games my cheap computers are never an issue otherwise. I don’t think I ever have problems with anything other than IDEs.
Pycharm seems pretty light weight - it runs on my 2015 macbook air just fine. I really like it, and I believe it does support vim shortcuts. I’m not using them however because I don’t mind the normal shortcuts, like ctrl + Q or whatever to expand a library’s method/variable to a description. That’s mainly why I’m using it so I don’t need to have 4 different windows open to reference API docs.
I tried Pycharm and fell out of using it. It was just a little more hassle and I haven’t done anything in Python that required more than a couple files. Unfortunately. I’ve just done scripts for parsing and editing text/CSV files and the backend for database queries. I guess it might be different if I had a large project.
In your company’s style, is there actually any difference between a class “inheriting” from a superclass vs having an instance of the superclass as a field? Either way, it seems like the only way the child can interact with the parent’s state is by calling the parent’s public methods.
I’ve been thinking about this for a while, and I think the answer is that Go interfaces and C++ abstract classes are basically the same, but not because Go likes inheritance, but rather because:
To put it more academically, both class inheritance and Go interfaces are about subtyping. Class inheritance, however, is normally about nominal subtyping (Child is an instance of Parent) , whereas an interface is structural/behavioral subtyping (Child has properties with the same type as Parent). Obviously sometimes you want nominal subtyping (you wouldn’t want a function that expects a USDAmount argument to accept any object with major_units and minor_units fields), but if you want behavioral subtyping, then inheriting from a base class that you know to have the desired properties is kind of a hack. You’re requiring that the value be a nominal subtype of the base class, not because you care about the identity of the base class, but rather because you know that the rules of inheritance will require any concrete instance of the base class to implement the desired behaviors. It’s basically a way to mimic behavioral subtyping via nominal subtyping.
Based on my extremely rudimentary understanding, it seems more correct to say that interfaces are a simplified version of C++ concepts?
According to DDoSecrets’ Best, the hacker says that they pulled out Gab’s data via a SQL injection vulnerability in the site—a common web bug in which a text field on a site doesn’t differentiate between a user’s input and commands in the site’s code, allowing a hacker to reach in and meddle with its backend SQL database.
To be clear, I wasn’t saying it’s a hack in a judgy sense, just that requiring an object to inherit from a base class when you really care about whether the object implements certain behaviors is a workaround for having better support for inheritance than structural typing. If the language has support for directly parameterizing over behavior, it’s not evidence that the language secretly yearns for inheritance, because using inheritance for that role was only ever a workaround.
the idiotic dev that still does not understand how to use git (no joke she had 2 git questions for me this morning, one of which was bc she was trying to switch branches with uncommitted work and kept getting an error…derrr no shit ugh)
This shit genuinely blows my mind. It’ll even tell you in the git error you need to use git stash.
Got a gig. It’s finishing/fixing some .NET project. At first it’s just looking at how feasible it is, so it could be a very short project. Pretty short regardless. But it’s for a software company that will have more projects.
