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.
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.
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.
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.
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!
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.
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.
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.
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:
classCar{
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.
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.
Home assistant is glorious…
Wouldn’t know, never used it. I tend to stay away from anything written in python as much as I can.
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?
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.
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!
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
niland for optional types you have to explicitly deal with the possibility of a variable beingnil. Boom, null-pointer error are a thing of the past, enforced by the compiler. One less thing to worry about.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!
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.
why?
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.
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.
I’m not saying it can’t be done, only that it’s not a good idea.
what’s is ducktyped
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.