The only language that I have worked with that realizes that in the real world simple is _always_ a lie, is common lisp. It is the only language that has actually embraced the fact that its designers/committee were not geniuses and provided the tools for dealing with the complexity of the system. When unix tools fail, hope that you are on a system where it is possible to get the symbols and/or the source code, and ev…
> when python code really fails, e.g. in a context with threading, you might as well burn the whole thing to the ground This sounds weird. Why burn the whole thing to the ground? You've got frames from all threads available. Why would it take days to resolve the issue? Why do you think it's easier to resolve it in common lisp?
Simple Systems Have Less Downtime
41–50 of 271 posts
Re: Simple Systems Have Less Downtime
#42The only language that I have worked with that realizes that in the real world simple is _always_ a lie, is common lisp. It is the only language that has actually embraced the fact that its designers/committee were not geniuses and provided the tools for dealing with the complexity of the system. When unix tools fail, hope that you are on a system where it is possible to get the symbols and/or the source code, and ev…
Re: Simple Systems Have Less Downtime
#43- Thomas Paine, Common Sense, 1776
Re: Simple Systems Have Less Downtime
#44Every new programming style epiphany is an ad hoc, intuitively-specified, hazy restatement of the Unix Way.
If Unix is your yardstick for simplicity, that just shows how far we've come…
And it is 2020, I guess nowadays everybody understand how unix-like system works and how simple they are.
Re: Simple Systems Have Less Downtime
#45Every new programming style epiphany is an ad hoc, intuitively-specified, hazy restatement of the Unix Way.
If Unix is your yardstick for simplicity, that just shows how far we've come…
Re: Simple Systems Have Less Downtime
#46Re: Simple Systems Have Less Downtime
#47Your system should be testable, debuggable and it should allow a human to step in and take control if needed. An open system is generally better than a closed one.
Re: Simple Systems Have Less Downtime
#48Re: Simple Systems Have Less Downtime
#49"Choose tools that are simple to operate over those that promise the most features."
Doing this very much depends on your requirements, doesn't it? What good is a simple-to-operate tool if it doesn't do what you need it to do? Sure, maybe you can simplify your requirements; then again, maybe not.
The example of troubleshooting a whitepaper form very much depends on the design of the system. Maybe there's a reason for having multiple forms. If they all shared common architecture and the problem lies in what they share, it's not necessarily more difficult to troubleshoot many as opposed to just one.
Moving from Marketo to HubSpot is good and well - for now. What about years from now? How did they end up with such complexity with the Marketo solution? Both solutions and requirements evolve. Down the line, you could end up with the same difficulties with HubSpot. I think it depends in part on how the organisation handles change.
Lastly, I agree with the sentiment of Mateusz Górski, who commented on the page: is there any hard proof beyond anecdote to back up the article? If you expand the article's concept of a system to beyond just software, all you need is a hardware fault in a third-party hosting company with lousy support for your simple piece of software to be down for weeks.
Re: Simple Systems Have Less Downtime
#50What are alternatives to commonly used complex systems, like Docker/Kubernetes, Active Directory, Remote Access or just shared folder structures? How to keep the functionality of centralized management while making it simple? Would be happy to hear your thoughts on this.