4 ms·

I think this hits the nail on the head but I wanted to add a few examples of what I believe to be this effect in practice: * Roman numerals vs Hindu-Arabic num

I think this hits the nail on the head but I wanted to add a few examples of what I believe to be this effect in practice: * Roman numerals vs Hindu-Arabic numeral system [1] (aka base 10 number system) The Roman numeral system is essentially a 'base-1' number system with other symbols attached to represent larger numbers. There are only a finite number of these larger numbers (V, X, C, etc.) so, in effect, the representation of a number grows linearly with the number itself, compared with base-10 which grows logarithmically. * Logogram [2] vs. Alphabet languages That is, pictographic languages vs. alphabet-like languages. HJK languages have upwards of 3k [3] pictographs to memorize compared with less than 100 characters for English and other alphabet like languages. * "Unix vs. Windows" Maybe a weak comparison, but Unix systems prefer small tools that compose well with each other via pipes using standard text. Unix's focus is on the command line and lends itself to automation. Windows environments focus on single person usability with pictograms, visual aids, etc. Obviously automation can be done in a Windows-like environment (including X) but, as the old adage says, "those who don't understand Unix are condemned to reinvent it, poorly." [4] [1] https://en.wikipedia.org/wiki/Hindu%E2%80%93Arabic_numeral_system https://en.wikipedia.org/wiki/Hindu%E2%80%93Arabic_numeral_s... [2] https://en.wikipedia.org/wiki/Logogram https://en.wikipedia.org/wiki/Logogram [3] https://en.wikipedia.org/wiki/Chinese_characters#Number_of_characters https://en.wikipedia.org/wiki/Chinese_characters#Number_of_c... [4] https://en.wikiquote.org/wiki/Unix https://en.wikiquote.org/wiki/Unix

jiggawatts 6y ago
Your overall post is very insightful, but the specific example of Windows is would have been always wrong and especially now is spectacularly outdated. Windows for decades has had a concept of "object oriented" composability, first through simple message passing, and later through things like the Component Object Model (COM), DCOM, Object Linking and Embedding (OLE). Among other things, this allows quite high level composability, such as Excel graphs in Word documents. This includes system management APIs such as the Windows Management Instrumentation, which is inherently object oriented and has been available for over a decade through the VB or JS shells, and even CMD/Batch shells using "wmic.exe" Now, UNIX people will argue that this isn't the same as the typical GNU toolset and a shell like bash. They would be right. In Windows, there's a gap between "I can drag and drop an Excel spreadsheet into Word" and "I can use C# to automate COM APIs". It's a big gap. I crossed it, I've seen commercial products that also do various forms of COM automation too, but I can count on one hand people that I have met "in the field" who have ever automated Windows in this manner. In other words, this gap was wide enough that many people -- especially those most familiar with UNIX -- would often claim that there's nothing on the other side. But this just isn't true. These days, everyone uses PowerShell, because it bridges that gap. It wraps all of those OO APIs that have existed for a long time in a unified platform. It can natively call WMI APIs, COM, WS-MAN, .NET, and has wrappers for the legacy DCE/RPC management APIs too. If I can leave you with one takeaway sentence from this is, then it's this one: PowerShell is more UNIX than UNIX. Seriously. In UNIX, if you want to sort the output of "ps"... sss... that's hard. Sure, it has some built-in sorting capabilities, but they're not a "sort" command, this is a random addon it has accumulated over time. It can order its output by some fields, but not others. It can't do complex sorts, such as "sort by A ascending, then by B descending". To do that, you'd have to resort to parsing its text output and feeding that into an external tool. Ugh. Heaven help you if you want to sort the output of several different tools by matching parameters. Some may not have built-in sort capability. Some may. They might have different notions of collations or internationalisation. In PowerShell, no command has built in sort, except for "Sort-Object". There are practically none that do built in grouping, except for "Group-Object". Formatting is external too, with "Format-Table", "Format-List", etc... So in PowerShell, sorting processes by name is simply: ps | sort ProcessName And never some one-character parameter like it is in UNIX, where every command has different characters for the same concept, depending on who wrote it, when, what order they added features, what conflicting letters they came across, etc... UNIX commands are more an accident of history than a cohesive, coherent, composable design. PowerShell was designed. It was designed by one person, in one go, and it is beautiful. The acid test I give UNIX people to see if they really understand how weak the classic bash tools they use is this: Write me a script that takes a CSV file as an input, finds processes being executed by users given their account names and process names from the input file, and then terminates those processes. Export a report of what processes were terminated, with ISO format dates of when the processes were started and how much memory they used into a CSV sorted by memory usage. Oh, there's a user called "bash", and some of the CSV input fields may contain multiple lines and the comma character. (correctly stored in a quoted string, of course!) This kind of thing is trivial in PowerShell. See if you can implement this, correctly in bash, such that you never kill a process that isn't in the input list. Give it a go.
- abetusk 6y ago
  Thanks for this, a very interesting insight into the Windows ecosystem. I won't be able to speak with any authority on Windows systems and I certainly don't want to get into a language/OS war but I would like to point out a few issues that raise red flags for me: * "Powershell is more UNIX than UNIX" Again, I don't have enough knowledge to really speak on PowerShell specifically but I will point out that the shell is one aspect of a Unix system, even if it's one of the bigger ones. The concept of files, filesystem, memory, in addition to the ecosystem of tools, are part of Unix. Obviously Windows has solved these aspects in some way shape or form but, at least from my perspective of the outside looking in, Microsoft has re-invented a lot of the Unix philosophy in order to make a Windows box behave more like a Unix box. * The mess of 'simple' tools vs. a cohesive philosophy in Windows While it's true a lot of the tools in the Unix ecosystem have arbitrary names and non uniform output syntax, the diversity of tools allows for a large range of solutions to a given problem. As you point out, the hodge-podge nature is most likely a historical artifact of the Unix evolution but I would argue this is kind of a natural by-product of systems that are heavily used and improved. I have no doubt that there are some cleaner interfaces in PowerShell but my concern is the reason for the clean interface is because it's a walled garden with Microsoft as the gate keeper. I think this gets into the old conversation about quality of code for FOSS projects vs. commercial projects. It's my belief that, after a certain threshold, having a quantity of software to choose from will lead to better quality software overall compared to software that has less quantity but higher proportion of quality. I think this might be a contentious view but my opinion is that it's better to let many "amateurs" experiment, with the best tools from those experiments filtering to the top, than to rely on a few experts to solve the same problems. Maybe there's a stronger economic argument as it relates to FOSS, I don't know. I will admit that I have a lot of sunk-cost/first-language-bias that makes me stick with Unix. If Microsoft ever open sources their operating system, I might reconsider that position though.
  - AnIdiotOnTheNet 6y ago
    > I have no doubt that there are some cleaner interfaces in PowerShell but my concern is the reason for the clean interface is because it's a walled garden with Microsoft as the gate keeper This is simply not true. Many third-parties have powershell modules to interact with their product. Anyone can write them.

jiggawatts 6y ago

Your overall post is very insightful, but the specific example of Windows is would have been always wrong and especially now is spectacularly outdated. Windows for decades has had a concept of "object oriented" composability, first through simple message passing, and later through things like the Component Object Model (COM), DCOM, Object Linking and Embedding (OLE). Among other things, this allows quite high level composability, such as Excel graphs in Word documents. This includes system management APIs such as the Windows Management Instrumentation, which is inherently object oriented and has been available for over a decade through the VB or JS shells, and even CMD/Batch shells using "wmic.exe" Now, UNIX people will argue that this isn't the same as the typical GNU toolset and a shell like bash. They would be right. In Windows, there's a gap between "I can drag and drop an Excel spreadsheet into Word" and "I can use C# to automate COM APIs". It's a big gap. I crossed it, I've seen commercial products that also do various forms of COM automation too, but I can count on one hand people that I have met "in the field" who have ever automated Windows in this manner. In other words, this gap was wide enough that many people -- especially those most familiar with UNIX -- would often claim that there's nothing on the other side. But this just isn't true. These days, everyone uses PowerShell, because it bridges that gap. It wraps all of those OO APIs that have existed for a long time in a unified platform. It can natively call WMI APIs, COM, WS-MAN, .NET, and has wrappers for the legacy DCE/RPC management APIs too. If I can leave you with one takeaway sentence from this is, then it's this one: PowerShell is more UNIX than UNIX. Seriously. In UNIX, if you want to sort the output of "ps"... sss... that's hard. Sure, it has some built-in sorting capabilities, but they're not a "sort" command, this is a random addon it has accumulated over time. It can order its output by some fields, but not others. It can't do complex sorts, such as "sort by A ascending, then by B descending". To do that, you'd have to resort to parsing its text output and feeding that into an external tool. Ugh. Heaven help you if you want to sort the output of several different tools by matching parameters. Some may not have built-in sort capability. Some may. They might have different notions of collations or internationalisation. In PowerShell, no command has built in sort, except for "Sort-Object". There are practically none that do built in grouping, except for "Group-Object". Formatting is external too, with "Format-Table", "Format-List", etc... So in PowerShell, sorting processes by name is simply: ps | sort ProcessName And never some one-character parameter like it is in UNIX, where every command has different characters for the same concept, depending on who wrote it, when, what order they added features, what conflicting letters they came across, etc... UNIX commands are more an accident of history than a cohesive, coherent, composable design. PowerShell was designed. It was designed by one person, in one go, and it is beautiful. The acid test I give UNIX people to see if they really understand how weak the classic bash tools they use is this: Write me a script that takes a CSV file as an input, finds processes being executed by users given their account names and process names from the input file, and then terminates those processes. Export a report of what processes were terminated, with ISO format dates of when the processes were started and how much memory they used into a CSV sorted by memory usage. Oh, there's a user called "bash", and some of the CSV input fields may contain multiple lines and the comma character. (correctly stored in a quoted string, of course!) This kind of thing is trivial in PowerShell. See if you can implement this, correctly in bash, such that you never kill a process that isn't in the input list. Give it a go.

abetusk 6y ago
Thanks for this, a very interesting insight into the Windows ecosystem. I won't be able to speak with any authority on Windows systems and I certainly don't want to get into a language/OS war but I would like to point out a few issues that raise red flags for me: * "Powershell is more UNIX than UNIX" Again, I don't have enough knowledge to really speak on PowerShell specifically but I will point out that the shell is one aspect of a Unix system, even if it's one of the bigger ones. The concept of files, filesystem, memory, in addition to the ecosystem of tools, are part of Unix. Obviously Windows has solved these aspects in some way shape or form but, at least from my perspective of the outside looking in, Microsoft has re-invented a lot of the Unix philosophy in order to make a Windows box behave more like a Unix box. * The mess of 'simple' tools vs. a cohesive philosophy in Windows While it's true a lot of the tools in the Unix ecosystem have arbitrary names and non uniform output syntax, the diversity of tools allows for a large range of solutions to a given problem. As you point out, the hodge-podge nature is most likely a historical artifact of the Unix evolution but I would argue this is kind of a natural by-product of systems that are heavily used and improved. I have no doubt that there are some cleaner interfaces in PowerShell but my concern is the reason for the clean interface is because it's a walled garden with Microsoft as the gate keeper. I think this gets into the old conversation about quality of code for FOSS projects vs. commercial projects. It's my belief that, after a certain threshold, having a quantity of software to choose from will lead to better quality software overall compared to software that has less quantity but higher proportion of quality. I think this might be a contentious view but my opinion is that it's better to let many "amateurs" experiment, with the best tools from those experiments filtering to the top, than to rely on a few experts to solve the same problems. Maybe there's a stronger economic argument as it relates to FOSS, I don't know. I will admit that I have a lot of sunk-cost/first-language-bias that makes me stick with Unix. If Microsoft ever open sources their operating system, I might reconsider that position though.
- AnIdiotOnTheNet 6y ago
  > I have no doubt that there are some cleaner interfaces in PowerShell but my concern is the reason for the clean interface is because it's a walled garden with Microsoft as the gate keeper This is simply not true. Many third-parties have powershell modules to interact with their product. Anyone can write them.