91–100 of 271 posts
This feels like it is stating the obvious. However it is easily forgotten. A lot of Software Engineers / Developers in my experience tend to over engineer projects or they are mandated they do so by so their dev leads. It is easy to get caught up into abstracting almost everything away almost for the sake of it while it provides no real benefit.
Earlier quoted context omitted.
A startup is not a container ship going between port A and port B where everything is known. A startup is a new destroyer that has been floated, did not have sea trials and went to war with a crew that might have a couple of people that used to a drive container ship but mostly staffed with kids that thought it was cool to play with a destroyer. Oh, and 3/4 of the systems are still at best have been drawn on a napkin…
Your startup is probably just a variation of CRUD.
That's why it is possible to have a container ship with a crew of 5-6 people pilot the load. Containers aren't sort of identical. They are completely identical and completely standard ( several standard sizes ). They have the weight distributed in a specific way and they are stacked on a ship in a specific way depending on the weight of every container.
The startup equivalent of a container ship in simplicity is a startup sorting a pile containing A4 paper, standard business envelopes and hang folders at a daily rate of 500 items.
Earlier quoted context omitted.
Linux is incredibly simple compared to Windows once you actually your computer as a computer instead of as a really poorly made gaming console.
Try talking Grandma over the phone to help her share her photo directory with Aunt Jeanine, on the same PC. No command line allowed, and you know she can only focus on that type of task for 4, maybe 5 minutes top.
(That's the reason why first the Windows explorer was suddenly sufficent enough and then almost completely disregarded)
A public folder on the same PC is way harder to explain than just telling your photo app to share it with your resident spying company/cloud provider, despite how wasteful the round trip is.
Not that that has anything to do with a discussion about the "unix way" as a special case or even superset of IDEs.
Earlier quoted context omitted.
Linux is incredibly simple compared to Windows once you actually your computer as a computer instead of as a really poorly made gaming console.
Try talking Grandma over the phone to help her share her photo directory with Aunt Jeanine, on the same PC. No command line allowed, and you know she can only focus on that type of task for 4, maybe 5 minutes top.
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.
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.
I think "incidental" (non-essential, secondary, happenstance), and "accidental" (non-intentional, happenstance) are more or less synonyms here, not contrasts. I think there, uh, is basically no significant difference between "incidental complexity" and "accidental complexity".
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…
Humans in the loop are likely to be a source of trouble, and you will need to measure to figure out if they provide any overall benefit other than giving you somebody to blame when that trouble happens. You need to ensure that the "human in the loop" scenario is obviously worse than automation or else humans, always over-confident of their abilities, will put themselves in the loop when it'd be far safer not. A good…
But you example works nicely as well, you should avoid having to work at lowers abstractions, and limit the work there as well. "changing the core to adapt to new features rather than adding to the core"
The author, probably, picked the worst example. Here is a pic: https://iro.nl/app/uploads/2018/12/P-67-onboard-the-BOKA-Van... No, the containership is not a simple system. It's very sophisticated one. It takes massive engineering effort (literally historical effort and knowledge) to build, massive resources for the material and outsourcing, very complex (like the pic) infrastructure in case of repair, satellites to…
Postulating about how things should be by non-experts has become a new e-sport. Then they try to apply it to software or startups as if its a apples to apples comparison.
The author, probably, picked the worst example. Here is a pic: https://iro.nl/app/uploads/2018/12/P-67-onboard-the-BOKA-Van... No, the containership is not a simple system. It's very sophisticated one. It takes massive engineering effort (literally historical effort and knowledge) to build, massive resources for the material and outsourcing, very complex (like the pic) infrastructure in case of repair, satellites to…