Show HN: C is for Camera, a 35mm film camera represented in Python objects | Hacker News Reader

Show HN: C is for Camera, a 35mm film camera represented in Python objects

github.com

103 pointsDanieleProcida22 comments

Open articleView on HN

This reminds me the tweet [1]:

manager: we need to design an admin system for a veterinary centre

dev: ok, this is it, remember your training

class Dog extends Animal {}

[1] https://twitter.com/iamdevloper/status/727854065426804738?s=...

Neat project. I love seeing models of complex, real-world systems.

One that I've always wanted to try is modeling an elevator bank: there's a surprising amount of complexity in the different states that an elevator can be in, as well as relevance to basic CS concepts (hierarchy, priority, capacity, &c).

Oh man you're going to LOVE this:

https://play.elevatorsaga.com/

That is fantastically fun. What a neat little project!

Fun little project. As a Python developer who owns that specific camera, I approve.

Neat project! The QL17 was my first rangefinder as well as one of my first cameras. I sold mine to someone in the Netherlands who insisted on paying cash. I had my doubts but a week later I received an envelope containing crisp new US currency in the amount we agreed upon in the mail, so I sent him the camera. Wish I would have kept it but I have too many cameras anyway.

A great extension to this would be the dedicated flash for the QL17.

Is the "ruined" state dependent on the environment luminosity multiplied by time? Like, is 0.1 lux (full moon) safe for a few seconds?

So far, it's only dependent upon luminosity - as long as it's not 0, it's considered ruined. And in reality, the unexposed frames wouldn't be ruined either (that's easy enough to model).

This is a great exercise -- well done!

What I try to convey to my students:

* We write programs to solve problems.

* The program is a model of the real-world problem.

* The better our model is, the easier it is to solve the problem.

* Objects are excellent ways to model real-world "things" and manipulate them in our programs.

I see online there's a movement that says OOP is "bad" but honestly in cases like this it makes perfect sense to me!

> I see online there's a movement that says OOP is "bad" but honestly in cases like this it makes perfect sense to me!

TLDR; bad code practices make bad code.

I think that this is confined to people who have a functional programming fetish, and those that worked at companies that drank the "OOP cool-aid" back in the late 90's early 2000's and built their codebase into massive, sprawling, strictly hierarchical monstrosities... I may have worked for one of these, and hated OOP with a passion till I realized that anything taken to an absurd degree is absurd.

If we all just orient our models in relationships that make sense for what they do, OOP is fine.

> massive, sprawling, strictly hierarchical monstrosities

> till I realized that anything taken to an absurd degree is absurd

Whenever I see OOP taught, the expectation is that every non-primative is an object in a massive hierarchy. If the default is an absurd degree, what does that say?

That it's badly taught, not necessarily bad in itself.

It makes a difference for categorizing and talking about OOP though.

If the default level is good, and some people take it to absurd counterproductive levels, you need to give a bit of a warning.

If the default level is absurd and counterproductive, but using a fraction that much is good, you need to approach the conversation in an entirely different way and "OOP is bad" is kind of correct and important to address.

Again, your argument boils down to "doing bad stuff is bad", which I completely agree with.

"Do it the right way!" is not very helpful advice, though.

We want to be able to say that one type of OOP is good and another is bad with relatively specific examples. We should have different terms for those types.

You did the equivalent of replying to someone talking about nutritional tactics with "tl;dr eat healthy". Yeah, figuring out healthy is why we're here, looking at these different techniques and sub-techniques and figuring out at what point they become counterproductive.

> Whenever I see OOP taught, the expectation is that every non-primative is an object in a massive hierarchy.

I actually had a great professor who'd worked at Microsoft during the dark ages, and taught OOP with very sensible "this can get way out of control if you drink the cool-aid" warnings.

I also had a different professor that preached FP to an absurd degree, literally refusing to accept work that had a "too much OOP" flavor to it. Bad teaching and practices exist anywhere, hence my TLDR at the top.

My objection to this view is that, a "thing" is not the same thing as the data that represents it, and what data you use to represent the thing is dependent on what you intend to do with it. I think object-oriented programmers are more prone than others to wrongly equate their model with the thing they are modelling; the paradigm almost encourages that.

I found this talk by Rich Hickey very persuasive: https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi....

Real-world code very rarely models real-world physical objects like this. This project is novel specifically because of that fact. And as soon as you step outside of modeling physical objects, OOP's benefits start to fall apart and you find yourself contorting abstract ideas into "objects" by way of concepts like Services, Strategies, Providers, Controllers, Adapters, etc (a whole lot of -ers, for the most part, which really drives home the fact that many of these objects only exist to "do" something, not to represent something).

I started exploring a graphical user interface too, using Anvil - https://camera.anvil.app. It only has two controls so far, but it's simply a matter of adding form elements and output for the existing objects.

I love this. Mapping a real world system/domain to code objects is my favorite programming exercise.

This is silly. good silly. (Like those Canon L-lens coffee cups)

Xrays.Dew.temperature extremes. Misloaded film. Dust or mould on lens. Physical damage. Shutter mechanism life is limited and they need to be pre emptively replaced. External flash sync. Problems between flash sync and shutter speed. Light meter false readings due to dirty light meter lenses.

All of these are real. I'm a professional photographer and I own this camera in my historical collection.

What's my point? Fuck OOP

Reply on news.ycombinator.com