Simple Systems Have Less Downtime • Hacker News Board

Re: Simple Systems Have Less Downtime

#31

Post by collyw » Tue, Mar 03, 2020, 9:48 AM UTC

z3t4 wrote: post #30

Sometimes the complexity is there for a reason. But if you can just start over, those reasons was not that important!? So don't hang on to functionality because it would be nice to have, you will have to pay the price for those features over and over.

Sometimes, but a lot of devs fetishise complex stuff. I disagree wit a lot of my tech leads decisions because he always wants to do the "most correct" way, whereas I want to keep things as simple as possible with the aim of keeping our code maintainable. For example, he wants to a add a graph database to the tech stack, while I realise that its one more thing to manage and potentially break and mongodb (that we already have) will be probably be good enough.

Re: Simple Systems Have Less Downtime

#32

Post by collyw » Tue, Mar 03, 2020, 9:49 AM UTC

speedgoose wrote: post #19

It's important to find a compromise. The simplest system at my work would be something like a php/mysql backend hosted on a old fashion shared server using ftp. Good luck attracting good developers with that. We use something over engineered but we have fun. The customers don't care but we do.

That's all good if your company is making money.

Re: Simple Systems Have Less Downtime

#33

Post by unnouinceput » Tue, Mar 03, 2020, 9:58 AM UTC

Very good article. Please also preach this article to those who praise Kubernetes right and left (remember, Kubernetes it's the new blockchain hype; and just like blockchain you don't really need it unless you're a cryptocurrency; which 99% of companies who use Kubernetes aren't).

Re: Simple Systems Have Less Downtime

#34

Post by pjmlp » Tue, Mar 03, 2020, 9:58 AM UTC

hyperion2010 wrote: post #25

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…

Forgetting Smalltalk here?

Mesa/Cedar, Oberon System were also like that by the way.

Java and .NET also share a bit of it, after all Java is half-way to Lisp (as per Guy Steele), and .NET follows up on it.

Re: Simple Systems Have Less Downtime

#35

Post by cal97g » Tue, Mar 03, 2020, 9:59 AM UTC

hyperion2010 wrote: post #25

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…

What about Erlang, it provides tools for real time debugging iirc.

Re: Simple Systems Have Less Downtime

#36

Post by Taek » Tue, Mar 03, 2020, 10:00 AM UTC

It's similar to optimization in that it follows a U-curve. Up to a point, simpler things have more performance, and simpler things have less downtime.

But after a certain point, it's no longer enough to make it simpler. You have to get a lot more involved again, and this time the complexity has to be intelligently focused around the end goal (be it performance or uptime).

Re: Simple Systems Have Less Downtime

#37

Post by CalRobert » Tue, Mar 03, 2020, 10:01 AM UTC

carlmr wrote: post #3

>For example, an analytics dashboard built with a no-code analytics tool like Looker is likely to have more qualified people to fix it than one built with a patchwork of custom scripts and APIs. Nobody should have to pull data scientists or product developers away from their work to fix a bar chart. I don't have experience with Looker, but the unseen complexity of no-code tools often leads to very complex systems wit…

Looker isn't no-code. A lot of people consider Looker a slightly more robust Tableau, but the visualization aspect is almost inconsequential. It's the data modeling part, the "this is exactly what structure my data takes and we define that in code", that matters. Otherwise what you get is "Here's my Tableau workbook with an unholy pile of hand-written untested SQL as custom data sources"

Incidentally I'm all ears if there's a good open-source LookML style project out there.

Re: Simple Systems Have Less Downtime

#38

Post by AmericanChopper » Tue, Mar 03, 2020, 10:12 AM UTC

hyperion2010 wrote: post #25

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…

> The only language that I have worked with that realizes that in the real world simple is _always_ a lie

This feels like an excuse to me. I’ve worked on a lot of rather simple web apps that all more or less do the same stuff. A few of them have managed to have delightfully simple codebases, most of them haven’t. There’s no reason that couldn’t be true for all of them. You usually end up having at least some complexity. But small complexity trade offs don’t necessarily require you to undermine the simplicity of the entire system.

Re: Simple Systems Have Less Downtime

#39

Post by viraptor » Tue, Mar 03, 2020, 10:14 AM UTC

hyperion2010 wrote: post #25

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?

Re: Simple Systems Have Less Downtime

#40

Post by praptak » Tue, Mar 03, 2020, 10:18 AM UTC

hyperion2010 wrote: post #25

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…

I disagree about Python. First, you can code a "manhole" in your code which lets you evaluate arbitrary string as Python code at runtime, basically a shell available via a socket.

Second, you don't even need that. Gdb with some tooling (see pyrasite) lets you attach to an arbitrary Python process and evaluate Python code in its context.