317
submitted 11 months ago* (last edited 11 months ago) by FireTower@lemmy.world to c/asklemmy@lemmy.world

you are viewing a single comment's thread
view the rest of the comments
[-] CurbsTickle@lemmy.world 7 points 11 months ago

Yes and yes, regularly serviced. And synced smoke alarms, wired with battery backup.

I've even got sprinklers.

[-] BorgDrone@lemmy.one 6 points 11 months ago

And synced smoke alarms

Same. Also, they are both smoke and heat alarms so they also trigger for smokeless fires. They are also linked into my home automation system, if triggered every light in the house will turn on to maximum brightness. It will also send an alert to my phone.

[-] CurbsTickle@lemmy.world 3 points 11 months ago

Home assistant is glorious.....

[-] BorgDrone@lemmy.one 0 points 11 months ago

Wouldn’t know, never used it. I tend to stay away from anything written in python as much as I can.

[-] CurbsTickle@lemmy.world 4 points 11 months ago

Considering what I've seen written in various languages from C to html, I don't judge by a language being used.

What are you using?

[-] BorgDrone@lemmy.one 3 points 11 months ago

Some languages are much more difficult to write reliable and stable code in, especially for larger codebases. Python is one of those. I’m not saying it can’t be done, but that’s despite the language being used, not thanks to it.

My home runs on OpenHAB, which is written in Java and built on top of OSGi.

When I set up my home automation (which was years ago) I looked into the technical aspects of the different options and OpenHAB had by far the most solid architecture.

[-] CurbsTickle@lemmy.world 4 points 11 months ago

Got it. I've got a friend running openhab, decent solution though it couldn't meet my needs.

To my experience, writing reliable code is more about the coding strategy than anything else, the language used doesn't even make the list. And I've developed with pascal back in the day.

Glad you've got a solution that works for you!

[-] BorgDrone@lemmy.one 2 points 11 months ago

To my experience, writing reliable code is more about the coding strategy than anything else, the language used doesn't even make the list. And I've developed with pascal back in the day.

Language makes a lot of difference in my experience. For example: a good type system can eliminate entire classes of mistakes. In Swift for example there are optional types, Non-optional types can never be nil and for optional types you have to explicitly deal with the possibility of a variable being nil. Boom, null-pointer error are a thing of the past, enforced by the compiler. One less thing to worry about.

[-] CurbsTickle@lemmy.world 2 points 11 months ago

And to me, that's more easily addressed with standardizing the approach. But I'm also logic before code, so more often than not I'm designing regardless of language.

Just different strategies towards the same outcome!

[-] BorgDrone@lemmy.one 1 points 11 months ago

That's not how it works. Programming is done by humans, and humans make mistakes. No amount of 'standardising the approach' (whatever the hell that means) or design is going to prevent humans from making mistakes.

We keep finding security problems related to memory management: buffer overflows, double frees, etc. You think all that code is written by amateurs who don't know what they're doing? No, it's written by professionals who know exactly how to prevent these things. But they are human, and they do make mistakes.

You can either bury your head in the sand and ignore this reality, or you can do something about it. A good way is to use a language that doesn't allow you to make these kinds of mistakes in the first place. That means a memory-safe language. That means one with strict static typing. This not only prevents bugs, it also frees up the programmer's mental bandwidth. If you don't have to think about accidental complexity you can put your energy into the actual problem you're trying to solve.

[-] bigMouthCommie@kolektiva.social 1 points 11 months ago
[-] BorgDrone@lemmy.one 1 points 11 months ago

It’s very difficult to write and maintain any significant amount of code in a ducktyped language. I don’t trust python code to be reliable or stable. It’s a nice toy language for academic projects but in no way suitable for production use. I certainly won’t have it controlling the things in my home that should just work, like the lights.

[-] ieatpillowtags@lemm.ee 2 points 11 months ago* (last edited 11 months ago)

There is plenty of production code written and maintained in Python outside of academia, as well as Perl, PHP and others. You’re presenting an opinion as fact.

[-] BorgDrone@lemmy.one 1 points 11 months ago

I’m not saying it can’t be done, only that it’s not a good idea.

[-] bigMouthCommie@kolektiva.social 0 points 11 months ago
[-] BorgDrone@lemmy.one 3 points 11 months ago

In most programming languages data has a type. You can think of it as the ‘shape’ of the data. For example: you have an ‘integer’ type which can contain whole numbers, a ‘floating point’ type which can contain fractional numbers, a ‘string’ type which can contain text, etc.

These simple types are called ‘primitive’ types, they are built into the language itself.

Usually, you can also define your own types, which are made up of the primitive types, for example: you can have a ‘car’ type:

class Car { 
    float maximumSpeed;
    int numberOfPassengers;
    String brand;
    String model;
}

Meaning any piece of data of type ‘Car’ has a maximum speed, number of passengers, brand an model.

Now languages like Java have so called static typing. You declare something to be a car, and the compiler knows that a car has these properties. This is used in a lot of places. Variables have types, parameters passed to a function have types. The return values of functions have types, etc. Static typing means you always know exactly what type of data you are dealing with.

Ducktyping is the exact opposite. The term comes from ‘if it walks like a duck and quacks like a duck, it’s probably a duck’. In a ducktyped language you don’t declare what type something is, you just use the data as if you know what type it is, and if it’s the correct type, it works. If it’s not, things might break.

In a statically typed language it is impossible to use the wrong type, this is enforced by the compiler. In a ducktyped language this is impossible, as the types are not declared. So if a function expects a ‘Car’ as a parameter, and you pass in a ‘Horse’ instead, in Java you would get an error when trying to compile this code. In Python it would just run it. This may be fine. A horse may also have a maximumSpeed and if you try to read that it would work. But when you try to access something a Horse doesn’t have, like the ‘brand’ property, things go tits up.

The main problem with this is that you only see this if you happen to run that specific bit of code in that specific situation. It may never happen during testing. Worse, if you change anything in ‘Car’ you don’t necessarily catch all the problems this causes. Say you rename ‘numberOfPassengers’ to ‘passengerCount’, in Java any code that still tried to access ‘numberOfPassengers’ would fail to compile, you’d immediately get an error. In Python you wouldn’t spot this problem at all until it’s too late.

The advantage of ducktyping is that it’s less verbose, you can whip something together quickly without having to think too much about the types. For a small simple program this is perfect, but the larger your codebase gets the harder it becomes to manage this. You can’t oversee the whole codebase anymore, mistakes happen and the compiler won’t catch them.

You can mitigate it a little, for example by writing lots of automated tests, but you really shouldn’t have to. A static type system prevents a lot of dumb mistakes from being made.

this post was submitted on 08 Jan 2024
317 points (97.9% liked)

Ask Lemmy

27241 readers
1994 users here now

A Fediverse community for open-ended, thought provoking questions


Rules: (interactive)


1) Be nice and; have funDoxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them


2) All posts must end with a '?'This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?


3) No spamPlease do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.


4) NSFW is okay, within reasonJust remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either !asklemmyafterdark@lemmy.world or !asklemmynsfw@lemmynsfw.com. NSFW comments should be restricted to posts tagged [NSFW].


5) This is not a support community.
It is not a place for 'how do I?', type questions. If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email info@lemmy.world. For other questions check our partnered communities list, or use the search function.


6) No US Politics.
Please don't post about current US Politics. If you need to do this, try !politicaldiscussion@lemmy.world or !askusa@discuss.online


Reminder: The terms of service apply here too.

Partnered Communities:

Tech Support

No Stupid Questions

You Should Know

Reddit

Jokes

Ask Ouija


Logo design credit goes to: tubbadu


founded 2 years ago
MODERATORS