The "loop and a half"

[bartc]

On 06/10/2017 18:42, Chris Angelico wrote:
> On Sat, Oct 7, 2017 at 4:13 AM, bartc <bc at freeuk.com> wrote:

>> So what's the excuse for an unresponsive text display in 2017?
> 
> Got it. You assume that a system is a coherent computer with its
> peripherals, rather than being a networked collection of computers,
> all of them controlled from your laptop in response to a panicked
> email saying the web site is down. Your terminal exists on your
> laptop. The programs are being run on any of a number of your servers,
> possibly several of them concurrently. How do you handle that?
> 
>>> What text editor do you use there?
>>
>> That depends; are we still in the 1970s?
> 
> Nope. We're in 2017, where the "system" is often a networked
> collection of computers.

Still no excuse. We were talking about the need to use a crude keyboard 
interface to serially create a file of data a line at a time rather than 
using a proper application for it (such as a text editor).

So which bit do you have access to locally? The keyboard presumably. And 
the display has to be local unless you it's either got a 50' screen or 
you use binoculars. Are you saying the bit in the middle is remote and 
that is what is playing up?

This is exactly the situation from the 1970s that I thought we'd long 
left behind! There really is no excuse for not having the minimum amount 
of local processing power available to be able to enter and review a few 
dozen lines of text without needing to involve a temperamental network.

If you're stuck, whip out a tablet computer or smartphone (they should 
still function without connectivity) and use a preloaded text editor. Or 
just compose and then save an email. Even the simplest should be more 
sophisticated than just blindly entering text on a Linux terminal screen.

>> (And since I mainly use my own languages, actually getting hold of 'stdin',
>> 'stdout' and 'stderr' is not trivial. Creating actual named files is much
>> easier.)
> 
> More blub happening right there. You start out by assuming that the
> standard streams are unimportant, therefore you think that providing
> them is pointless. It's self-perpetuating.

They were a creation of either C, Unix, or some combination. Certainly I 
had very little to with any of that for decades. I can't remember that 
it ever stopped me doing anything I needed to do.

My own programs worked like this (showing original '#' symbol I used);

  print     "One"       # to console (also using print #0)
  print #f, "Two"       # to file handle f
  print #s, "Three"     # append to string s
  print #w, "Four"      # to window or control w
  print #b, "Five"      # to image b

What would I want with stderr?!

> It's 2017. You should understand at least a bit about the internet and
> how to use it.

I can use it but can't fix it when it goes wrong.

> I don't know if you're an idiot or a troll. Using TCP/IP networking is
> pretty simple (at least if you're using a real language - your own toy
> languages might have made it unnecessarily hard, for all I know),
> hardly "over-complex" by comparison to RS-232 programming.

So how do you use it from Python - without using an existing Python 
library? Or is it only simple when someone else has made it idiot-proof?

(That reminds me, at some point I have to provide a winsock2.h file for 
my C compiler. I may have to finally learn some of this stuff to test it.)

>> I just don't work that way. The OS is there to launch applications, or to
>> provide a basic API for common services such as a file system. I don't need
>> its complicated shells.
> 
> Blub rears its head again.

How so? I said I have little need for most of what an OS does, in my 
development work, which is perfectly true. Perhaps you haven't noticed 
that many are using sophisticated IDEs now rather than fiddling about 
with command lines. (Mine is not sophisticated, but still better than a 
command line.)

> At what point will you acknowledge that there are things you do not
> understand that are actually useful?

I can understand that people who use Unix and Linux arrange their world 
so that all these things are apparently indispensable.

What you're trying to tell me is that because Unix provides such a 
tightly knit system system of utilities, stdin, stdout, files, pipes and 
very specific ways of using the keyword (which seems to consist of 
avoiding actually using it for entering data as much a possible; just 
using the logical idea of it), then every other text entry system in the 
world, in whichever OS or application, must follow exactly the same 
model. Because the Unix one is so great.

Needless to say, I disagree.


-- 
bartc