51–60 of 271 posts
Earlier quoted context omitted.
If Unix is your yardstick for simplicity, that just shows how far we've come…
Linux is incredibly simple compared to Windows once you actually your computer as a computer instead of as a really poorly made gaming console.
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…
Don't solve problems you don't have.
Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you go one step ahead, do something outside of quick start, you find yourself helpless. In that sense, the article is on point. Not only the management of the ship is simple, machinery behind the scenes is simple as well. This applies to programming languages, too.…
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…
Sure lisp is a wonderful language, but let's not pretend there's no difference between incidental and accidental complexity.
Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.
I like to “embrace complexity.” Any line of code, especially one that introduces a new concept, like a class or a method, is in “addition” to the root problem we’re trying to solve. The closer the code/data/org-processes/whatever matches the fundamental problems we’re trying to solve, the less complexity we introduce. However, you cannot “remove” complexity! A common mistake I see in software companies is using a sin…
Agreed. It should be almost as simple to create a sub-task (of any task) as it's to comment. Also convert a comment to sub-task. Browsing is another problem...
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.
The author is not arguing for simplicity per se, but about being able to insert a human into a system that is normally automated. The example about the ship's steering system is perfect, actually. The system is not "simple" (if I were on a ship and the steering failed, I would be clueless), but it provides plenty of interjection points where a knowledgeable human can step in and either debug or fix the issue. It's th…
The latter part of the article talks about simplicity but doesn't seem tightly tied to the earlier part.