5 ms·

If "simple" makes you think of "less capabilities" then you are way off the mark. The challenge is to create something with more capability but architeturally

by hsn915 4y ago

If "simple" makes you think of "less capabilities" then you are way off the mark. The challenge is to create something with more capability but architeturally more simple. I don't understand why they brag about supporting "only English". I'm also not sure what it means: does it mean the system does not even support utf-8 strings? Or is it just about the lack of UI translation to other languages? In either case, it's nothing to brag about. You're just removing capabilities for no reason. It's important to understand why simplicity is desireable: it's not desireable for itself, it's desireable because, everything else being equal, a simple system is easier to make reliable and robust. For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language. It's not simple. Errors are not reported until runtime. It's worse than dynamic languages because shell scripts often create permanent changes to the system. If a script fails mid execution, it might very well leave the system in a broken state. Now, obviously when dealing with systems that's always possible even if the program is written in a compiled language with static typing and very good compiler error messages. But there's no need to exacerbate the problem by writing a core utility in a shell script that's several hunderd lines of code.

deleted 4y ago
[deleted]
dundarious 4y ago
It's perfectly reasonable to say "I'll take fewer capabilities in specific areas, if there is far less complexity". Those "missing" capabilities can be hard blockers for you, and that's fine as well. I also don't think much of your argument about shell is particularly strong, as it provides plenty of good facilities for dealing with errors (exiting subshell on first error, `trap`, etc.). The only reason I might expect an implementation in another language to be at least more correct in the ways you describe, is because the barrier to entry of those languages is higher, so the programmers may be more professional (in the good way, not in the meaningless way). Given there's just one developer here, we can skip rules of thumb like that and just assess that person and their modestly sized code.
- hsn915 4y ago
  In many ways, a lot of the complexities in computing are born from the lack of capabilities. C is a simple language. It's so simple it has no concept of modules/packages. So as a hack you can 'include' header files. But this simple hack creates all sorts of complexities. Things would be simpler if the compiler had a concept of modules or packages. Ruby is so simple you don't need a compiler! You just need packages to exist in your system which you can install using the command line. Except now to ship a program you have to ship the entire environment with it, so you create Docker. But things would be simpler if the language had a compiler that can produce a self contained packaging of the program. Supporting only English makes things simple until people from other countires come along and they independently try adding support each for their own language, and you end up with tons of encodings and code pages and all the mess that was there before unicode. Regarding shell, actually the shell language has a quite a high barrier to entry, but only because it's cryptic. That's not my problem though. My problem is even if you add error checking and all that, you don't know if it actually works. There's no compiler that will report errors for you. It's very easy to write incorrect code and get absolutely no feedback about it. There's really nothing to gain from doing this.
  - dundarious 4y ago
    That reads like an argument for static type checking languages and against runtime dynamic languages, and I'm generally in the same camp as you, but obviously it's not impossible to use either to write a good program if it's only 1000 lines (they also state they use shellcheck, which is not nothing). There's absolutely something to gain from their approach. And shell is not particularly cryptic, it's just taught awfully -- the main problem being that lazy tutorials just don't mention how quoting/tokenizing works. Using shellcheck almost always pushes you in the right direction.
Beltalowda 4y ago
> I don't understand why they brag about supporting "only English". I'm also not sure what it means: does it mean the system does not even support utf-8 strings? Or is it just about the lack of UI translation to other languages? In either case, it's nothing to brag about. You're just removing capabilities for no reason. Good support for different encodings, locales, etc. is actually quite hard, and also imposes some amount of burden on developers of the system, as well as users who don't use these features. Of course, these things are also very useful and if you want/need things like that then that's fair and KISS probably isn't for you. But not every project needs to cater to every need; I think "simple = less capabilities" is fine, although obviously not for everyone but it doesn't need to be. > For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language. It's not simple. Errors are not reported until runtime. It's worse than dynamic languages because shell scripts often create permanent changes to the system. If a script fails mid execution, it might very well leave the system in a broken state. I never used KISS and don't know anything about their package manager, but I did write my own package building tool in shell script, and it builds things to its own chroot and as a last step if everything worked it moves the files over. It's not really atomic, but also not like any error in the script will "leave the system in a broken state". It's great that better package managers exist, and there are a lot of situations where it's good to use them. But for other use cases it's just fine to use a (much) simpler system which isn't entirely perfect (but a lot simpler). Not everything needs to solve all possible problems. My own package builder doesn't do things like dependency tracking either because I don't need it, but obviously this is a very useful thing to have in many scenarios – but not all scenarios. We really need to move away from the view that every project/system should cater to every kind of use case and every kind of user.
- hsn915 4y ago
  I'm not objecting that someone wants to create a toy project that lacks important capabilities. I'm objecting that they are presenting their work as "simple". Simple describes the internal architecture of the system as having fewer parts to achieve a particular goal. What you're doing is not simplyfing the system. You are keeping the system mostly the same, but removing some capabilities (and along with them, removing the parts of the system that were put in place to support these capabilities). The way I see things, these are all different axes. Sort of orthogonal, but not really (they influence each other, but in theory they can be thought of as independent): Easy ------------ Difficult This axes is about the user and what they need to learn to be able to operate the system. If they have to learn many new things and intricate details, it's difficult. If they can operate the system perfectly while only learning fewer things, then it's easy. Obviously there's a degree of relativity. So you can only define this in terms of a target demographics. e.g. "college students who are familiar with smart phones", or "corporate employees who have basic knowledge about computers and can use some office software". Simple --------- Complex This axis describes the internal architecture of the system. The parts its composed of and their interactions. Simple systems have fewer parts and fewer interactions. Complex systems have more parts and more interactions. Reliable -------- Fragile This axis describes the robustness of the system and its sensitivity to changes in the environment. Fragile systems break down when small things change in the environment. Poor --------- Capable This axis is about the features of the system and what it can do. The things that I see in this KISS distro all point in the wrong direction: - Fewer capabilities - Difficult to use - Robsutness is qustionable Is it simpler? It may be simpler than a more capable version of the system, but what's the point? Simplicity is only desireable in so far as it helps make the system more robust.
zajio1am 4y ago
> For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language. Shell is a bad language, but it is a language especially fitting for that purpose. File manipulation and external tool execution is much simpler and concise in it that in most other languages.

by hsn915 4y ago

deleted 4y ago

[deleted]

dundarious 4y ago

It's perfectly reasonable to say "I'll take fewer capabilities in specific areas, if there is far less complexity". Those "missing" capabilities can be hard blockers for you, and that's fine as well. I also don't think much of your argument about shell is particularly strong, as it provides plenty of good facilities for dealing with errors (exiting subshell on first error, `trap`, etc.). The only reason I might expect an implementation in another language to be at least more correct in the ways you describe, is because the barrier to entry of those languages is higher, so the programmers may be more professional (in the good way, not in the meaningless way). Given there's just one developer here, we can skip rules of thumb like that and just assess that person and their modestly sized code.

hsn915 4y ago
In many ways, a lot of the complexities in computing are born from the lack of capabilities. C is a simple language. It's so simple it has no concept of modules/packages. So as a hack you can 'include' header files. But this simple hack creates all sorts of complexities. Things would be simpler if the compiler had a concept of modules or packages. Ruby is so simple you don't need a compiler! You just need packages to exist in your system which you can install using the command line. Except now to ship a program you have to ship the entire environment with it, so you create Docker. But things would be simpler if the language had a compiler that can produce a self contained packaging of the program. Supporting only English makes things simple until people from other countires come along and they independently try adding support each for their own language, and you end up with tons of encodings and code pages and all the mess that was there before unicode. Regarding shell, actually the shell language has a quite a high barrier to entry, but only because it's cryptic. That's not my problem though. My problem is even if you add error checking and all that, you don't know if it actually works. There's no compiler that will report errors for you. It's very easy to write incorrect code and get absolutely no feedback about it. There's really nothing to gain from doing this.
- dundarious 4y ago
  That reads like an argument for static type checking languages and against runtime dynamic languages, and I'm generally in the same camp as you, but obviously it's not impossible to use either to write a good program if it's only 1000 lines (they also state they use shellcheck, which is not nothing). There's absolutely something to gain from their approach. And shell is not particularly cryptic, it's just taught awfully -- the main problem being that lazy tutorials just don't mention how quoting/tokenizing works. Using shellcheck almost always pushes you in the right direction.

Beltalowda 4y ago

> I don't understand why they brag about supporting "only English". I'm also not sure what it means: does it mean the system does not even support utf-8 strings? Or is it just about the lack of UI translation to other languages? In either case, it's nothing to brag about. You're just removing capabilities for no reason. Good support for different encodings, locales, etc. is actually quite hard, and also imposes some amount of burden on developers of the system, as well as users who don't use these features. Of course, these things are also very useful and if you want/need things like that then that's fair and KISS probably isn't for you. But not every project needs to cater to every need; I think "simple = less capabilities" is fine, although obviously not for everyone but it doesn't need to be. > For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language. It's not simple. Errors are not reported until runtime. It's worse than dynamic languages because shell scripts often create permanent changes to the system. If a script fails mid execution, it might very well leave the system in a broken state. I never used KISS and don't know anything about their package manager, but I did write my own package building tool in shell script, and it builds things to its own chroot and as a last step if everything worked it moves the files over. It's not really atomic, but also not like any error in the script will "leave the system in a broken state". It's great that better package managers exist, and there are a lot of situations where it's good to use them. But for other use cases it's just fine to use a (much) simpler system which isn't entirely perfect (but a lot simpler). Not everything needs to solve all possible problems. My own package builder doesn't do things like dependency tracking either because I don't need it, but obviously this is a very useful thing to have in many scenarios – but not all scenarios. We really need to move away from the view that every project/system should cater to every kind of use case and every kind of user.

hsn915 4y ago
I'm not objecting that someone wants to create a toy project that lacks important capabilities. I'm objecting that they are presenting their work as "simple". Simple describes the internal architecture of the system as having fewer parts to achieve a particular goal. What you're doing is not simplyfing the system. You are keeping the system mostly the same, but removing some capabilities (and along with them, removing the parts of the system that were put in place to support these capabilities). The way I see things, these are all different axes. Sort of orthogonal, but not really (they influence each other, but in theory they can be thought of as independent): Easy ------------ Difficult This axes is about the user and what they need to learn to be able to operate the system. If they have to learn many new things and intricate details, it's difficult. If they can operate the system perfectly while only learning fewer things, then it's easy. Obviously there's a degree of relativity. So you can only define this in terms of a target demographics. e.g. "college students who are familiar with smart phones", or "corporate employees who have basic knowledge about computers and can use some office software". Simple --------- Complex This axis describes the internal architecture of the system. The parts its composed of and their interactions. Simple systems have fewer parts and fewer interactions. Complex systems have more parts and more interactions. Reliable -------- Fragile This axis describes the robustness of the system and its sensitivity to changes in the environment. Fragile systems break down when small things change in the environment. Poor --------- Capable This axis is about the features of the system and what it can do. The things that I see in this KISS distro all point in the wrong direction: - Fewer capabilities - Difficult to use - Robsutness is qustionable Is it simpler? It may be simpler than a more capable version of the system, but what's the point? Simplicity is only desireable in so far as it helps make the system more robust.

zajio1am 4y ago

> For example, a package manager written in 1000 lines of posix shell script is not a good thing. Shell script is a bad language. Shell is a bad language, but it is a language especially fitting for that purpose. File manipulation and external tool execution is much simpler and concise in it that in most other languages.