3 ms·

Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myse

by laumars 10y ago

Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags. What's more, many developers (myself included) aren't afraid of jumping into someone elses code and modifying it to behave how we want. Let's also remember that a great deal of software you don't even think about also runs this way; they'll have config flags to add and remove features at compile time (run Gentoo or FreeBSD ports for a few weeks and you'll see what I mean). So having hardcoded options isnt that ridiculous nor uncommon on Linux. However mainstream desktop distros do a good job at hiding that from their users by picking sane defaults for them.

Jaruzel 10y ago
> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags. Cool... Now I know that it's not just me that does this then. :)
tokenizerrr 10y ago
> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags. Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.
- laumars 10y ago
  > Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs. If you're building an MVP then the first and foremost concern is getting a proof of concept product running. However to answer your question I don't really see how editing list of constants in an AOT compiled language is any worse than having to do the same in any of the hundreds of popular web solutions written in languages like PHP where they often embed config as source code variables. It's the same issues with hard coded settings in source code but the difference is how your continuous integration pipeline / code deployment scripts are configured. So it's quite an easy problem to solve once you look at the deployment automation. Obviously the end goal would be to have readable configuration files for different environments. But pragmatically real world code often ends up being rushed and hacked to meet deadlines rather than nurtured, following industry best practices at every point throughout it's development cycle (assuming your company even has a documented development cycle. Many don't!)

by laumars 10y ago

Jaruzel 10y ago

> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags. Cool... Now I know that it's not just me that does this then. :)

tokenizerrr 10y ago

> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags. Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.

laumars 10y ago
> Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs. If you're building an MVP then the first and foremost concern is getting a proof of concept product running. However to answer your question I don't really see how editing list of constants in an AOT compiled language is any worse than having to do the same in any of the hundreds of popular web solutions written in languages like PHP where they often embed config as source code variables. It's the same issues with hard coded settings in source code but the difference is how your continuous integration pipeline / code deployment scripts are configured. So it's quite an easy problem to solve once you look at the deployment automation. Obviously the end goal would be to have readable configuration files for different environments. But pragmatically real world code often ends up being rushed and hacked to meet deadlines rather than nurtured, following industry best practices at every point throughout it's development cycle (assuming your company even has a documented development cycle. Many don't!)