Subj : Re: Windows vs Linux To : tenser From : boraxman Date : Thu Apr 28 2022 23:08:09 te> You keep missing the point. te> te> Sure; that's how escape characters work. But now perhaps te> you can explain how you intend to retrofit an escape te> character into /etc/passwd given 50 years of installed te> base? How do you intend to do this on systems that te> share their authorization database via LDAP or NIS with te> hosts where it is difficult or impossible to update libc? te> What do you do about static binaries? What do you do about te> the many, many tools that were written without care for te> this new thing you want to introduce into an existing file te> format? And how does any of this address the problem of te> adding new fields, or changing existing fields? te> te> Recall that the genesis of this subtopic was your opining te> that delimited text files were somehow superior to CSV, te> which is itself a delimited text format, and your seeming te> objection (unclear; you never really addressed it) to my te> statement that delimited files have limitations. te> te> You seem to fixate on trivial technical details, like te> escape characters etc, while missing the larger technical te> issues. There's a reason the world has mostly moved to te> structured data formats, and it's not because developers te> or lazy or stupid or simply wow'ed by the shiny thing du te> jour. We all understand how escaping works. Experienced te> developers also understand that that is not the only issue te> at play. te> te> I have no idea, but that's not the point. The point is that te> you can use the exact same model you point to with Unix on te> Windows. The Unix philosophy is not singular in the way you te> seem to be asserting it is; it's not even that rich on Unix. te> Both VM/CMS and Windows actually have _more powerful_ primitives te> than Unix/Linux because they bring notions of type safety and te> structure to the pipe primitive. te> te> If you aren't aware of the tools that are available on the te> platforms you are dismissing, and not aware of the limitations te> of the platforms you are lauding, perhaps you examine your te> opinions and refrain from voicing value judgments. te> I'm sorry I brought up ESR's article, because it wasn't the point I wanted to made. /etc/passwd is a little different, but the details don't matter. ESR made a statement that delimited formats are better than CSV, in general I think he is right, but there are nuances. te> What does that have to do with building software? Your te> statement was about software development, which is _radically_ te> different now than it was in 1999. Based on this comment te> alone, it seems likely your experience is limited to using te> machines, and you have very limited development experience. te> te> te> Sounds like you find yourself in a soul-sucking deadening te> environment. I'm genuinely sorry for that; however, you te> continue to draw unwarranted conclusions about things generally te> based on your personal experience, which really does not te> follow. That's called anecdotal evidence, and is a known te> logical fallacy. te> There is a difference between building software, and building solutions. Software is just one part of it. How that software is used together, how it is all strung together to create workflows is what matters in the end. Software developers can't do this, they can't anticipate what Bobs Medical Devices, or Central Victorian Metal Recyclers or Acme Packaging will need to use their software FOR. When software is created by developers to solve a particular problem, it tends to be a monolithic 'suite', often now web based, which attempts to capture all workflows, but is usually inflexible (or modifiable at a cost). I did actually work with an application framework which attempted to partially solve this, by allowing the client the ability to modify screens, create new business logic, but it was all still within the app. Excel and Word are still the same, more or less. The fact the underlying code has change is irrelevant to those of us who aren't developers. How they are developed is irrelevant to the discussion, only the final product, how it interacts with the computing environment it is in, matters. te> This is a strawman. I didn't say, "so what." Though I te> have no idea why you're bringing this up in response to a te> comment about software development, I will say that open te> data formats are de rigor now and have been for quite some te> time. te> te> Also, you seem unaware of a number of points, here. Namely, te> that you could simply programmatically extract the data you te> want from an excel file. There are APIs for this in most te> major programming languages and the formats themselves are te> standardized (ISO/IEC 29500-1:2016). If you run across a te> version of Excel that does not natively save in those standard te> formats, you can likely export to a format that is, or one te> easily groked by a library (even CSV!). te> I do export to CSV, before using in my scripts, and I am aware of the API's. I don't claim it is not possible to create such workflows in Windows, only that Windows wasn't designed around this type of computing model. te> te> In other words, this problem is easily solved, even on te> Windows. If there's a failure of imagination here, I'd te> say it is not even considering these possibilities. te> te> Again, you conflate the _system_ with the _application running te> on that system_, and assert that the former implies the structure te> of the latter. That is the part that does not follow. te> te> You don't seem to want to acknowledge that the system is just a te> tool, and haven't presented any serious evidence for any of your te> assertions beyond anecdote. te> te> Finally, you may find life a bit more pleasant if you took the te> time to look into solutions that are already available on the te> platform you are forced to work on, instead of looking rigidly te> at a different platform as the only solution. te> I can't do much at all with the platform I'm working on because my ability to install new software packages is limited, quite limited. To some degree, the system has shaped the applications, moreso by convention and culture, than by technical necessity. Windows can for example, run a different GUI, but doing so is rather "hacky", not officially supported, and may be undone by a software update. Whereas Unix systems officially support a different GUI. My experience isn't the only thing I'm drawing on, but from conversations with others. Those who work in software development (I have a few friends who do this), have quite a different set up at work, because they are more able to use their tools to their advantage. I would imagine those working in any sort of development are working in environments vastly different to most of us other corporate drones. Most companies have no developers, and rely on people to write monolithic software to fulfill business needs. By the way, I was involved in a software project, with the support of a company, using their framework to create Quality System which moved away from a traditional "page" and "screen" model, where interaction revolved around workflows and tasks. It was the "OS" within an application. --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64) * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101) .