Software is a tool. I develop stuff that i know is of interest to companies working with everything from nuclear energy to hydrogen electrolysis and CO2 storage. I honestly believe I can make a positive contribution to the world by releasing that software under a permissive licence such that companies can freely integrate it into their proprietary production code.

I’m also very aware that the exact same software is of interest to the petroleum industry and weapons manufacturers, and that I enable them by releasing it under a permissive licence.

The way I see it, withholding a tool that can help do a lot of good because it can also be used for bad things just doesn’t make much sense. If everybody thinks that way, how can we have positive progress? I don’t think I can think of any more or less fundamental technology that can’t be used for both. The same chemical process that has saved millions from starvation by introducing synthetic fertiliser has taken millions of lives by creating more and better explosives. If you ask those that were bombed, they would probably say they wish it was never invented, while if you ask those that were saved from the brink of starvation they likely praise the heavens for the technology. Today, that same chemical process is a promising candidate for developing zero-emission shipping.

I guess my point is this: For any sufficiently fundamental technology, it is impossible to foresee the uses it may have in the future. Withholding it because it may cause bad stuff is just holding technological development back, lively preventing just as much good as bad. I choose to focus on the positive impact my work can have.

I am very fond of the idea of “stateless” code, which may seem strange coming from a person that likes OOP. When I say “stateless”, I am really referring to the fact that no class method should ever have any side-effect. Either it is an explicit set method, or it shouldn’t affect the output from other methods of the object. Objects should be used as convenient ways of storing/manipulating data in predictable/readable ways.

I’ve seen way too much code where a class has methods which will only work"as expected" if certain other methods have been called first.

Sounds reasonable to me: With what I’ve written I don’t think I’ve ever been in a situation like the one you describe, with an algorithm split over several classes. I feel like a major point of OOP is that I can package the data and the methods that operate on it, in a single encapsulated package.

Whenever I’ve written in C, I’ve just ended up passing a bunch of structs and function pointers around, basically ending up doing “C with classes” all over again…

I would argue that there are very definitely cases where operator overloading can make code more clear: Specifically when you are working with some custom data type for which different mathematical operations are well defined.

This makes sense to me, thanks! I primarily use Python, C++ and some Fortran, so my typical programs / libraries aren’t really “pure” OOP in that sense.

What I write is mostly various mathematical models, so as a rule of thumb, I’ll write a class to represent some model, which holds the model parameters and methods to operate on them. If I write generic functions (root solver, integration algorithm, etc.) those won’t be classes, because why would they be?

It sounds to me like the issue here arises more from an “everything is a nail” type of problem than anything else.

Oh, thanks then! I’ve heard people shred on OOP regularly, saying that it’s full of foot-canons, and while I’ve never understood where they’re coming from, I definitely agree that there are tasks that are best solved with a functional approach.

Can someone please enlighten me on what makes inheritance, polymorphism, an operator overloading so bad? I use the all regularly, and have yet to experience the foot cannons I have heard so much about.

I’ve never thought of myself as a conspiracy theorist, but if jar-jar being planned to be the actual phantom menace, but later being taken out of the role because fans hated him counts as a conspiracy theory: Count me in! I think the arguments are compelling to say the least.

I definitely roll with “badass tiny mf”, “chill little dude”, “tiny gangsta bro” or any other title making fun of my stature. Call me anything involving “king” and I’ll be inclined to convince you that, even though I’m short, you’ll be shorter once you’re confined to a wheelchair

But it might be beer!

Where I live they were systematically nice people that helped keep everybody safe. If they found some drunk/high person that needed help, they would drive them home. When we were teens and had beach parties, a couple of them would typically hang around somewhere out of the way, and only intervene if someone was being an asshole trying to start a fight (and they would tell people to pick up their glass bottles so kids wouldn’t get hurt the next day). If we were otherwise hanging around they might chat to us and ask what was going on around the neighbourhood, and nobody had an issue telling them anything, because we knew they were just there to look after and help people.

Obviously, I can tell that my experience with police growing up is far from what can be expected a lot of other places. I really do wish more places had police like we did.

Hehe, exactly :) the thing with gases is that the line between completely fine (campfire outside) to potentially lethal (liquid nitrogen evaporating in a small, poorly ventilated garage) can be harder to see and judge for an amateur than a lot of other things. Anyone would understand that they should avoid getting acids or toxic chemicals on their skin, and the protective measures are quite simple to carry out. The same is true for most flammable or explosive liquids or solids. So the idea behind my advice was really “If there’s something that’s likely to hurt you because you aren’t properly aware of the danger involved and how to mitigate it, it’s likely to be a gas, so be extra, extra careful around gases, gas producing reactions, and volatile compounds.”

If you have a fume hood that’s good of course, but since the question was about advising amateurs on safety, my advice is restrictive, because gases can be very dangerous in subtle ways.

As an amateur: Do you know how to properly work in a fume hood so that it protects you? Do you know its capacity, and what to do if something unexpected leads to gas development over that capacity? Have you had training in using this stuff, so that you can react properly and quickly if something goes wrong, rather than freezing up?

In short: Because the potential dangers when working with a lot of gases are harder to detect, and harder to mitigate, than when working with other stuff, I’m taking a restrictive approach in my advice.

For you question on pyrophoric gases: They can remain in contact with air for a while (several minutes, depending on concentration) before igniting. Worst case, the room around you can fill with gas from a leak before causing a gas explosion. In principle you can also inhale gas from this leak, such the the explosion also takes place inside you :)

Anther chemist stepping in here: Anything that produces an off-gas of any kind that does anything other than smell bad should be considered potentially lethal. People have died from working with liquid nitrogen or dry ice without proper ventilation. In addition, a gas explosion can be far worse than any other explosion you are likely to pull off by accident, and if you have a leak somewhere you may have no clue how much explosive gas is in the room with you. Some gases will react and form acid when it gets into your airways, essentially acting as an invisible acid that can jump from the table into your face.

In short: Stay away from dangerous gases and stuff that makes them, and consider pretty much all gases as dangerous unless you know for a fact that they aren’t. Other than that, the potential dangers of backyard chemistry can largely be mitigated by using common sense and working with small amounts of chemicals, good luck :)

I was joking, and definitely agree with you. I don’t think I’ve used eval since my first programming course in uni.

Edit: Except for monkey hacks for laughs of course.

For Python I think there’s an actual point though: A lot of Python projects are user friendly wrappers for pre-compiled high-performance code. It makes sense to call something “py<SomeKnownLibrary>” to signal what the library is.

That will give you an extremely clear error when you run the code. Also, any IDE worth its salt should be able to fix that for you.

Even the error message you get from C++ for missing a semicolon is harder to understand and fix than this.

I have to be honest: I dont see the problem of including the entire signature at the top of the doc, and the listing the params below. If I know the class/function, a quick look at the signature is often all I need, so I find it convenient that it’s at the top of the doc. If it’s a class/function I’m not familiar with, I just scroll to the bullet points.

I agree on the bit about whitespace in signatures though. Luckily Python allows me to use as many lines as I want within a parentheses.

I believe eval would like a word with you…

Yes, typing <p> in HTML is like pressing enter in word, but that doesn’t make it a programming language, it makes it a markup language.

A markup language is also what you can use to format comments here: You use a specific syntax to indicate how you want things formatted.

The separation from a programming language is that a programming language can be used to implement logic, like saying: In the following paragraph, a word should be bold if it contains the letter “A”. That cannot be done with a markup language.