[HN Gopher] Show HN: C is for Camera, a 35mm film camera represe...
___________________________________________________________________
Show HN: C is for Camera, a 35mm film camera represented in Python
objects
Author : DanieleProcida
Score : 84 points
Date : 2021-03-05 13:17 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| DanieleProcida wrote:
| 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.
| ksm1717 wrote:
| I love this. Mapping a real world system/domain to code objects
| is my favorite programming exercise.
| frompdx wrote:
| 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.
| t0mek wrote:
| 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=...
| Apreche wrote:
| Fun little project. As a Python developer who owns that specific
| camera, I approve.
| woodruffw wrote:
| 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).
| tantalor wrote:
| Oh man you're going to LOVE this:
|
| https://play.elevatorsaga.com/
| F00Fbug wrote:
| 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!
| ookdatnog wrote:
| 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....
| craftinator wrote:
| > 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.
| Dylan16807 wrote:
| > 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?
| grenoire wrote:
| That it's badly taught, not necessarily bad in itself.
| Dylan16807 wrote:
| 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.
| brundolf wrote:
| 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).
| m463 wrote:
| This is silly. good silly. (Like those Canon L-lens coffee cups)
| tantalor wrote:
| Is the "ruined" state dependent on the environment luminosity
| multiplied by time? Like, is 0.1 lux (full moon) safe for a few
| seconds?
| DanieleProcida wrote:
| 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).
| Badfood wrote:
| 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
___________________________________________________________________
(page generated 2021-03-05 23:02 UTC)