22 ms·

COBOL can be a real pleasure to use. For instance, it allows programmers to quickly create user interfaces by declaratively describing them, in a so called SCR

• adzm 7y ago
  I was blown away by some reporting systems in COBOL that were surprisingly understandable and simple.
• apfsx 7y ago
  Do you have a video that shows an example of this text entry system? I'm interested in seeing this.
  • triska 7y ago
    Sometimes I see it on terminals for instance when checking into a hotel, opening an account in a bank, booking a flight, interacting with the tax administration etc. One important point that makes them so efficient to use is that everything can be accessed using only the keyboard. For my personal use, I have simulated such forms using Emacs, and especially its Widget Library: https://www.gnu.org/software/emacs/manual/html_mono/widget.html https://www.gnu.org/software/emacs/manual/html_mono/widget.h... This is a bit similar to what you get with a SCREEN SECTION in COBOL.
    • userbinator 7y ago
      Anyone who has used the BIOS setup function of a PC before the EFI bloat took over will find that interface familiar, it's certainly easy to use and quite efficient. Here's an example screenshot: http://www.buildeasypc.com/wp-content/uploads/2011/11/step12_bios_setup_h.jpg http://www.buildeasypc.com/wp-content/uploads/2011/11/step12...
    • epc 7y ago
      Could also be ISPF dialogs (https://en.wikipedia.org/wiki/ISPF https://en.wikipedia.org/wiki/ISPF, https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconc_whatisispf.htm https://www.ibm.com/support/knowledgecenter/zosbasics/com.ib...).
  • Zenst 7y ago
    In the early 80's we had terminals (Newberry being one brand iirc)that would talk to the mainframe and in this instance a Honeywell Bull DPS8 range and these terminals had block mode, so could just type out using the cursor keys to navigate and key in all your code or feild attributes as you would for a transactional screen layout input interface. Then having effectly edited and dealt with localy, could hit send into the edit buffer and covered much WYSWYG form of input and layout for screens. So many ways of doing screen editing and text entry in the real early pre PC days would of been down to the terminals and local cursor, send whole screen block mode form of editing. Unlike character mode (very early systems way of pooling terminals) in which it had to handshake each and every keystroke in effect. Though even some of these terminals could be configured to allow full screen editing mode and sent via character mode batch polling. Terminals were not cheap back then either and when the PC came out, terminal emulation software was one of the big sellers in some markets who would spend lots on the early PC's and more on this software as cheaper than the dedicated terminal offerings.
• wglb 7y ago
  The only way I found COBOL palatable was to spend the better part of a year programming in RPG III first.
• tantalor 7y ago
  > quickly create user interfaces by declaratively describing them > everything can be accessed using only the keyboard Sounds like plain old html forms.
  • triska 7y ago
    Yes, at least in some respects, HTML forms could have been that way, but in practice, they are not: For one thing, and this is important, with every browser I tried, I get periodically interrupted by messages that the browser displays and that are not part of the form. Just recently, I was again asked for security updates by the browser. Sometimes when opening a form it gets prefilled by the browser, sometimes not, and sometimes only some of the fields. Some other times I get asked whether the browser should translate the form. Sometimes it asks me whether some fields should be prefilled. Sometimes when submitting a form the browser asks me whether I would like to store the form contents for later use. Sometimes the browser asks me at unpredictable times whether I would now like to restart it. An important prerequisite for getting a lot of work done is for the system to behave completely consistently and predictably, and not to interfere with unrelated messages, questions, alarms etc. This is also very important for training new users, writing teaching material etc. Another important point, and that is very critical as well, is latency: Just recently, I typed text into my browser, and it stalled. Only after a few moments, the text I entered appeared. I never had such issues with COBOL applications. Today, we can barely even imagine applications that are usable in this sense, because we have gradually accepted deterioration in user interfaces that would have been completely unacceptable, even unthinkable, just a few decades ago.
    • tomlagier 7y ago
      The trade-off, of course, is access. Now, computers are cheap and available everywhere. In the COBOL era, what percentage of a family's income would it take to purchase such a machine? How wide-spread were these machines in non-English speaking areas? How easily could a program from one of the machines be used on a machine built by a different vendor? Were said programs resilient to malicious actors? As always, there are sacrifices, but in general I think we have made rational trade-offs in this realm.
• downerending 7y ago
  I've not used this, but it reminds me some of the UI of early Lotus 1-2-3 (in text, no GUI). It was amazingly intuitive and easy to navigate, even without a mouse. Modern web apps, each unique and confusing, with no reliable way to move focus around and with bizarre text entry "improvements", would have made the Admiral weep.
  • zozbot234 7y ago
    > Modern web apps, each unique and confusing, with no reliable way to move focus around If accessibility is set up correctly, you can still move focus with TAB and activate widgets/buttons with SPACE or ENTER. No different from any terminal app. If client-side JS is being used, the web page could even display additional forms in response to a keyboard shortcut, with no network-introduced latency.
    • betenoire 7y ago
      Accessibility is only part of it. You should know where your keys are going to take you, and tabs often become unpredictable and confusing
    • downerending 7y ago
      Per sibling, even at best, this just isn't in the same league. And I'm doubtful about "best". And even if it works, why should I need to enable special accessibility features to access a UI mode that isn't utter sh_t?
    • badsectoracula 7y ago
      > move focus with TAB and activate widgets/buttons with SPACE or ENTER. No different from any terminal app No different from a terminal app that pretends to be a GUI app :-P. At the minimum many terminal/DOS apps used arrow keys to move between fields and often just pressing enter in a field (often after it was validated), it'd move to the next relevant field. Shortcut keys to move around and/or perform context sensitive functions (e.g. search for product IDs in a field where you are supposed to enter a product ID) would also be available at any time. I remember my father making a program for his job (for his own use) ~20 years ago in Delphi and he was manually wiring all the events to move around with the Enter key, like his previous program (written in DOS and Turbo Pascal) did and was annoyed that he had to do this manually. TBH i do not believe it is impossible to do this nowadays on the web, but just like it wasn't done in the majority of GUI desktop apps that followed the DOS days, i also do not believe it is/will be done in the web apps that is done nowadays. The reasons for this vary, but i think a large part of it is that people simply haven't experienced using the other methods to even think about them.
• scythe 7y ago
  >For instance, it allows programmers to quickly create user interfaces by declaratively describing them, in a so called SCREEN SECTION. >The resulting interfaces are very efficient for text entry, and allow users to quickly get a lot of work done. The interaction is so much more efficient than what we are used to with current technologies that it can barely be described or thought about in today's terms. It's not common anymore, but Unix clones still have dialog(1): https://www.freebsd.org/cgi/man.cgi?query=dialog https://www.freebsd.org/cgi/man.cgi?query=dialog
• wgyn 7y ago
  That is a great video! It also reminds me of Dan Wang's essay on How Technology Grows: https://danwang.co/how-technology-grows/ https://danwang.co/how-technology-grows/. It introduced me to the Ise Grand Shrine, which is a wooden temple that's rebuilt and torn down periodically so that the knowledge of how to maintain it doesn't get lost.
• gumby 7y ago
  > For instance, it allows programmers to quickly create user interfaces by declaratively describing them, in a so called SCREEN SECTION. By the way if it seems odd to have I/O like this in your language:* this reflects the architecture of mainframes; because the CPU was so important, I/O was managed by external devices (typically themselves a cabinet of electronics, at a time when the CPU took up two or three cabinets itself). You'd write essentially a small program describing what IO you wanted and then let the IO channel controller be busy dealing with minutiae like dealing with the tape drive motor or input from terminals. So the language would set up data to be slapped to a terminal (this would have been a decade or more after COBOL was written, once terminals with screens were available), which the channel controller would send to the appropriate terminal. It would then deal with input and once all was ready, tell the CPU that it had a bunch of input ready. Terminals like the 3270 were even half duplex so would process the input and then send it off as a block, to make the channel controllers more efficient! In the ARPAnet of the 1970s, the ITS PDP-10s and -20s took this further with a protocol called SUPDUP (super duper) which allowed this kind of processing to be done on a remote machine when logging in over the net (as we would do today with ssh). So you could log into a remote machine and run EMACS, and while you were editing a remote file with a remote editor all the screen updating would be done by your local computer! Even the CADR lisp machines supported this protocol! * At the time not doing IO through the language itself was considered oddball. I seem to recall a line in the original K&R where they described C's I/O and made an aside, '("What, I have to call a function to do I/O?")'
  • zitterbewegung 7y ago
    What you are describing sounds like the inverse of TRAMP in modern GNU emacs.
    • rbanffy 7y ago
      Or an HTML form.
      • gumby 7y ago
        SUPDUP was far more dynamic than an HTML form (read RFCs 734 and 749). html forms are more like the half duplex terminals of the 70s/80s.
• dzonga 7y ago
  thanks for the Jonathan blow talk. very informative and good to reflect on. e.g in software younger dev's don't generally accept the advice of the older gen. hence we keep reinventing tech instead of iterating. examples been serveless vs php deployment. k8's, react etc
• acdha 7y ago
  This had some neat benefits: in the 90s I worked for a COBOL vendor (Acucorp) who had a bytecoded portable runtime which allowed you to run a binary on systems ranging from 16-bit DOS to Windows NT, most Unix variants, VMS, etc. (our QA matrix had ~600 platforms & versions). The display section meant it could adjust to the platform: on DOS and other consoles, you had text controls but on X11, Win16/32, OS/2, and Mac it had native GUI widgets, with native validation UI. It wasn’t beautiful out of the box but it was familiar, consistent, and accessible. The same was true of the standard indexed storage: a different runtime could use a SQL database for storage without recompiling the program, which was key to some gradual migrations to Java. A similar feature allowed remapping invoke calls to run on a remote server. At one point we produced a NPAPI plugin version: install it in Netscape and your client ran the UI while the data access and RPC calls happened on a server. All I can say is that it seemed like a good idea at the time.
• Pmop 7y ago
  Kinda but not entirely off-topic. Low-tech magazine is all about solar power these days but previous issues brought back to light technologies we once used, and probably would be still useful these days; plus, you get to save power, lower carbon footprint, and so on. https://www.lowtechmagazine.com/ https://www.lowtechmagazine.com/
• tynpeddler 7y ago
  At one of my previous jobs, I was responsible for designing and building a webapp to replace a high speed data entry system that had been written in cobol that was used to input large legal documents (several thousand lines of data in some cases). We had two objectives, data entry had to be as fast or faster than the old system and the training time on the new system had to be faster. We blew both objectives out of the water. Training time went from 3-6 months to about 2 weeks. We had a variety of modern UI concepts like modals, drop downs and well behaved tables that dramatically simplified the work flow. We also had a full suite of user defined hotkeys, as well as a smart templating system that allowed users to redefine the screen layout on a per use case basis (the screen would be reconfigured based on what customer the user was entering data for example). For performance, cobol typically requires a server round trip every time the screen changes. We simply cached the data client side and could paginate so quickly that it actually caused a usage problem because users were not mentally registering the page change. The initial screen load took slightly longer compared to the cobol system, but the cobol system required 40 screens for its workflow whereas our system could do everything on a single screen. I guess my point is that modern systems are capable of much better performance and user ergonomics than cobol systems. We have a lot more flexibility in how UI's are presented that let us design really intuitive workflows. The flexibility also lets us tune our data flow patterns to maximize performance. But most modern development processes do not have this kind of maniacal focus. Systems don't perform because most product owners don't really care that much at the end of the day. Once you care enough, anything's possible.
  • fareesh 7y ago
    How long did it take? What frameworks/libraries did you use?
    • tynpeddler 7y ago
      We used Angular 1. Took about 2 years, but it was just me for about half that time and we were all learning js and the web ecosystem. The new system had been prototyped a few years earlier using java swing. That really helped nail down the design requirements.
• dylan604 7y ago
  >Regarding the underlying theme of legacy systems, here is an interesting presentation by Jonathan Blow, citing various examples of earlier civilizations losing access to technologies they once had This is why printed physical books are still an important thing in the age of eReaders and the like. Also, the Library of Congress archives audio on vinyl. The ancient analog formats will still be able to be understood in 100 years. Today's latest tech won't be though. I was just provided a CD-R/DVD-R(didn't look that close) of x-rays of my cat. I honestly have no way of reading that data as none of my devices have a x-ROM drive.
  • xigency 7y ago
    That’s funny. I have a Blu-ray Drive only so I can make physical backups of some important things to store.
  • badsectoracula 7y ago
    Eh, not really a problem. Your CD-R issue is pretty much the same as you not having a cylinder phonograph player - a device that is already 100 years old. Sure, if you do not have such a player you cannot play the cylinder, but the audio stored in those players isn't lost, players exist for those who want to listen to the cylinders and given enough money, new ones can be made. Similarly, you may not have a CD-R or DVD-R reader, but it takes about 5 euros to buy one and access your CD. In 100 years it might cost more, but i'm willing to bet that CD-R and DVD-R readers will still be available in much greater numbers than cylinder phonograph players are. Making new ones, for really important data, will certainly be more expensive than making a new cylinder player but it wont be impossible - if the data is important enough and for some reason all the millions of CD-R players in existence nowadays has vanished, a new one will be made. And analog formats aren't that great either - most of them tend to wear over time, so they have their own drawbacks.
    • tbyehl 7y ago
      Mr Wizard taught me how to improvise a record player [1]. I doubt our great-grandchildren will be able to improvise a CD reader. [1] https://www.youtube.com/watch?v=HJa6Ik6xmiU https://www.youtube.com/watch?v=HJa6Ik6xmiU
• hacker_9 7y ago
  Have you used imgui? Easily fastest way to create a GUI since dawn of computing, Cobol screen section really has nothing on it.
  • analognoise 7y ago
    Compared to Tkinter (or even straight Tk)? If you want something naive that I think blows both out of the water: FreePascal/Lazarus.
• okareaman 7y ago
  Everything Old is New Again
• thereyougo 7y ago
  Wow, I was sure that COBOL is not being used any more since the new programming languages are just better in any aspect. What's the reason that COBOL faded over the years?
  • goatinaboat 7y ago
    the new programming languages are just better in any aspect. Well, you should question your assumption that the new languages are better. They aren’t, they are just more fashionable. You can see this in every aspect of life, not just programming. Previous generations liked high-quality products that would last. Modern day people like cheap objects that soon break and are thrown away and replaced with something equally cheap and flimsy. There’s a reason that COBOL (and FORTRAN) code is still running 50 years later, and that last year’s JavaScript already needs to be rewritten.
    • onei 7y ago
      It depends how you quantify better. If you mean easier to hire developers in, provides higher levels of abstraction, etc. then modern programming languages are generally better. If you value stability and cost, as those who own these COBOL do, then you don't care about what it's running on and what you have is good enough until it suddenly isn't. 50 years is a long time to find bugs and modern applications don't have anything close to that level of hardening.
      • goatinaboat 7y ago
        you mean easier to hire developers in, provides higher levels of abstraction, etc. then modern programming languages are generally better That’s a subtle distinction, in JavaScript a high level of abstraction means hiding the details of the DOM and how the interface works, whereas in COBOL or FORTRAN what you’re really abstracting is the problem domain itself. Availability of programmers is part driven by the market but largely by programmers themselves who try to avoid mature and established technologies and chase the hottest new trend. So it’s true what you say, but it doesn’t happen because it has to but because people want it to.
• m463 7y ago
  little known fact - COBOL is very efficent - in terms of errors. I recall it won an award for the most error messages from the fewest number of lines of code. I think a program with a period in column 6 run through the IBM Cobol compiler would generate either 200 or 600 lines of error messages.
• icedchai 7y ago
  If only it were so easy to do that with modern web technologies. Instead, you write dozens (if not hundreds) of lines of HTML/CSS/JS just to do a simple form post. And it feels like it's gotten worse over the years.