6 ms·

But is that just to accommodate the newer, more mainstream stuff, or because it's actually technically better?

by anyfoo 6y ago

skissane 6y ago
I think it is mainly about making it easier to port code from more mainstream platforms (AIX/Unix/Linux), which reduces engineering costs. Porting open source code is a low cost way to get new functionality and features, and makes the environment seem more familiar and modern to newcomers who are familiar with Linux – and commercial Unixes such as AIX are pretty close to Linux. When detractors call it a "legacy" platform, their sales team can now respond "it's not legacy, it runs node.js!" But one thing I think it demonstrates is a problem with non-mainstream operating system architectures. Even if a non-mainstream operating system architecture is technically superior, sooner or later you want to port software to it from a mainstream operating system, which means you need a compatibility layer implementing a more mainstream operating system architecture. And before you know it most of the code is running in the compatibility layer, because that's where all the new applications are coming from and there is no way you can keep up with that pace yourself. And then you have to ask what is the point of the innovative non-mainstream architecture if so much of the software you run doesn't actually use it. So eventually it leads you to moving off the non-mainstream architecture and on to a more mainstream one. Is IBM i technically superior? It is a weird mixture of (a) advanced concepts like single-level store, an object-oriented operating system and bytecode virtual machine (b) legacy crud like EBCDIC, RPG, block mode terminals, 10 character limit on object names and a single-level filesystem (c) a severe lack of extensibility and openness in which a lot of OS concepts (e.g object types) are closed up so only IBM engineering can extend them (or possibly ISVs who pay big $$$$ for NDA manuals) (d) the completely different worlds of POSIX/AIX/Java grafted on the side, and increasingly taking over the rest. I grant that (a) could be said to be technically superior, but (b) and (c) clearly are not.
- anyfoo 6y ago
  But that's entirely my point, yeah. I don't know if a single-level store address space is better, but if the reason for its decline on IBM i is merely that mainstream software doesn't mesh well with it, I feel like it doesn't tell me much about the paradigm itself. By the way, I'd argue about whether all of b) is technically inferior or not. Object name limits certainly are, but I got to really know data entry with block mode terminals long, long after its hey day (I've certainly come across it back then, but I was rarely a user). I feel that it can be enormously efficient for data entry and maintenance tasks. Many a person who had to move from intensive use of a block mode data entry terminal to performing the same tasks with a web app got quite annoyed at the clumsiness of it all. The web was not created for "business apps" but for hypertext document retrieval, the other uses got bolted on and it still very much shows. It's sad, because proper terminal emulation well used to be a ubiquitous feature of the Internet, before browsers took over almost entirely.
  - skissane 6y ago
    > but I got to really know data entry with block mode terminals long, long after its hey day (I've certainly come across it back then, but I was rarely a user) I don't think block mode terminals are necessarily inferior. I see some big problems with 5250 though. The biggest is EBCDIC. Another big problem is character-at-a-time interfaces let you build things like text editors (vim and emacs), spreadsheets (like Lotus 123), etc. Sure you can build a text editor for a block mode terminal (SEU on IBM i, XEDIT on z/VM, ISPF EDIT on z/OS) but there are just certain features and interaction styles that vim and emacs support that block mode terminals can't do as nicely (example: interactive search). Lotus 123 was actually ported to 3270 (to run under MVS and VM/CMS), I've never used it (I would love it if someone could find a copy so I could!) but from what I've heard it was pretty clunky compared to the MS-DOS / PC version. Sometimes I think that block mode terminals could have exposed some kind of byte code to enable running some interactivity in the client. Actually real 3270s and 5250s generally had some kind of CPU in them (like an 8080) so I can't see why they couldn't have done that. And of course terminal emulators could do that. Then you could have these more flexible interaction styles that character mode terminals support even in a block mode terminal.
    - anyfoo 6y ago
      > I don't think block mode terminals are necessarily inferior. I see some big problems with 5250 though. The biggest is EBCDIC. Oh yeah I agree, the actual implementation details in this case are icky. > Another big problem is character-at-a-time interfaces let you build things like text editors (vim and emacs), spreadsheets (like Lotus 123) That's true, but at the same time block mode allows for highly standardized and always latency free data entry and manipulation. I wonder if this is just a case for different technologies for different use cases. > Sometimes I think that block mode terminals could have exposed some kind of byte code to enable running some interactivity in the client. Hmm, it helps to preserve the zero latency aspect (if done correctly), but at the same time opens up the door for shoddy implementation and non-standard UX. And then I'm sure people would come up with all sorts of "UI libraries" for terminals that they think are very clever, but just make everything fragmented and clumsy again, just like I often wish that a web site was just a plain old HTML page with maybe a standard web form, instead of whatever crazy js-backed UI the web framework du jour came up with...

But is that just to accommodate the newer, more mainstream stuff, or because it's actually technically better?

by anyfoo 6y ago

But is that just to accommodate the newer, more mainstream stuff, or because it's actually technically better?

I think it is mainly about making it easier to port code from more mainstream platforms (AIX/Unix/Linux), which reduces engineering costs. Porting open source code is a low cost way to get new functionality and features, and makes the environment seem more familiar and modern to newcomers who are familiar with Linux – and commercial Unixes such as AIX are pretty close to Linux. When detractors call it a "legacy" platform, their sales team can now respond "it's not legacy, it runs node.js!" But one thing I think it demonstrates is a problem with non-mainstream operating system architectures. Even if a non-mainstream operating system architecture is technically superior, sooner or later you want to port software to it from a mainstream operating system, which means you need a compatibility layer implementing a more mainstream operating system architecture. And before you know it most of the code is running in the compatibility layer, because that's where all the new applications are coming from and there is no way you can keep up with that pace yourself. And then you have to ask what is the point of the innovative non-mainstream architecture if so much of the software you run doesn't actually use it. So eventually it leads you to moving off the non-mainstream architecture and on to a more mainstream one. Is IBM i technically superior? It is a weird mixture of (a) advanced concepts like single-level store, an object-oriented operating system and bytecode virtual machine (b) legacy crud like EBCDIC, RPG, block mode terminals, 10 character limit on object names and a single-level filesystem (c) a severe lack of extensibility and openness in which a lot of OS concepts (e.g object types) are closed up so only IBM engineering can extend them (or possibly ISVs who pay big $$$$ for NDA manuals) (d) the completely different worlds of POSIX/AIX/Java grafted on the side, and increasingly taking over the rest. I grant that (a) could be said to be technically superior, but (b) and (c) clearly are not.

anyfoo 6y ago
But that's entirely my point, yeah. I don't know if a single-level store address space is better, but if the reason for its decline on IBM i is merely that mainstream software doesn't mesh well with it, I feel like it doesn't tell me much about the paradigm itself. By the way, I'd argue about whether all of b) is technically inferior or not. Object name limits certainly are, but I got to really know data entry with block mode terminals long, long after its hey day (I've certainly come across it back then, but I was rarely a user). I feel that it can be enormously efficient for data entry and maintenance tasks. Many a person who had to move from intensive use of a block mode data entry terminal to performing the same tasks with a web app got quite annoyed at the clumsiness of it all. The web was not created for "business apps" but for hypertext document retrieval, the other uses got bolted on and it still very much shows. It's sad, because proper terminal emulation well used to be a ubiquitous feature of the Internet, before browsers took over almost entirely.
- skissane 6y ago
  > but I got to really know data entry with block mode terminals long, long after its hey day (I've certainly come across it back then, but I was rarely a user) I don't think block mode terminals are necessarily inferior. I see some big problems with 5250 though. The biggest is EBCDIC. Another big problem is character-at-a-time interfaces let you build things like text editors (vim and emacs), spreadsheets (like Lotus 123), etc. Sure you can build a text editor for a block mode terminal (SEU on IBM i, XEDIT on z/VM, ISPF EDIT on z/OS) but there are just certain features and interaction styles that vim and emacs support that block mode terminals can't do as nicely (example: interactive search). Lotus 123 was actually ported to 3270 (to run under MVS and VM/CMS), I've never used it (I would love it if someone could find a copy so I could!) but from what I've heard it was pretty clunky compared to the MS-DOS / PC version. Sometimes I think that block mode terminals could have exposed some kind of byte code to enable running some interactivity in the client. Actually real 3270s and 5250s generally had some kind of CPU in them (like an 8080) so I can't see why they couldn't have done that. And of course terminal emulators could do that. Then you could have these more flexible interaction styles that character mode terminals support even in a block mode terminal.
  - anyfoo 6y ago
    > I don't think block mode terminals are necessarily inferior. I see some big problems with 5250 though. The biggest is EBCDIC. Oh yeah I agree, the actual implementation details in this case are icky. > Another big problem is character-at-a-time interfaces let you build things like text editors (vim and emacs), spreadsheets (like Lotus 123) That's true, but at the same time block mode allows for highly standardized and always latency free data entry and manipulation. I wonder if this is just a case for different technologies for different use cases. > Sometimes I think that block mode terminals could have exposed some kind of byte code to enable running some interactivity in the client. Hmm, it helps to preserve the zero latency aspect (if done correctly), but at the same time opens up the door for shoddy implementation and non-standard UX. And then I'm sure people would come up with all sorts of "UI libraries" for terminals that they think are very clever, but just make everything fragmented and clumsy again, just like I often wish that a web site was just a plain old HTML page with maybe a standard web form, instead of whatever crazy js-backed UI the web framework du jour came up with...