|
|
|
|
|
|
by quickthrower2
1642 days ago
|
|
|
I think thats the rub these days. With such an impressive mountain of free and indeed proprietary software, the money is going to be mostly in how you glue it together to solve a problem for a
business. Getting something in a low number of bytes is not rewarded when gigabytes of storage are so cheap. To create something that doesn’t fir this mould has to be more like a “recurse centre” project - a labour of love you have to finance yourself. |
|
|
Sometimes. Sometimes not.
The physical HW, i.e. RAM and HDD storage is cheap but price you pay for accidental complexity is high. E.g. when your non-tail-call recursive calculation eats away all available memory. And you need to persistently store the intermediary results - just a handful of long integers in a dbase. And that dbase must be set up and maintained. That means dealing with access rights, usernames, passwords, replication, backups etc. In every environment: prod, tests, on every development branch (separately!), etc.
In another dimension, read / write operations mean yet more side effects to deal with. And on top of that, dealing with intermediary results means yet more accidental complexity in the source code.
So no, the workaround for "the memory limitation problem" can be in fact the most expensive part of a project. And now imagine, the data grows day by day...