Programming languages and what’s next

  • Post category:Programming
  • Reading time:3 mins read

My review of programming languages I learned in during my years in IT. BASIC On the Texas Instruments TI99-4a.  Could do everything with it. Especially in combination with PEEK and POKE. Nice for building small games. Impossible to maintain. GOTO is unavoidable. Assembler In various variants. Z80, 6802, PDP 11, System 390. Fast, furious, unreadable, unmaintainable. Algol 68 Loved this language. REF! Have only seen it run on DEC 10. Mainly used in academic environments (in the Netherlands?)? Pascal Well. Structured. Pretty popular in the early 90s.  Again is this widely adopted? COBOL Old. Never programmed extensively in it - just for year 2000. Totally Readable. Funny (rediculous) numbering scheme. Seems to be necessary to use GOTO in some cases which I do not believe. Smalltalk Beautiful language. Should have become the de facto OO programming language but failed for unclear reasons. Probably because it was way ahead of it's time with it's OO base. Java Totally nitty gritty programming language. Productivity based on frameworks, which no one knows which to use. Never understood why this language was so widely adopted - besides it's openness and platform independency. Should never have become the de facto OO programming language but did so because Sun made it open (good move). Far too many framework needed. J(2)EE add more complexity than it resolves. Always upgrade issues. (Proud programmer: We run the application in Java! Fed up IT manager: Which Java?) Rexx Can do everything quickly. But nothing structurally. Ugly code. Readable but ugly. Some very very strong concepts. Php Hodge podgy language of programming concepts and html. Likely high programmer productivity if you maintain a stark discipline of programming standards. Stark danger of creating unmaintainable crap code mix of html and php. Python Nice structured language. Difficult to set up and reuse. Can be productive if nitty gritty setup issues can be overcome. Ruby (on Rails or off-track) Nice, probably the most elegant OO language. Too nitty gritty to my taste still. Like it though. I would start with this language if I had to start today. What is next Visual programming? Clicking building blocks together? In programming we should maybe separate the construction of applications from the coding of functions (or objects, or whatever you call the lower level blocks of code. Programming complex algorithms (efficiently) will probably always remain a craft for specialists. Constructing applications from the pieces should be brought to a higher level. The industry (well - the software selling industry) is looking at microservices but that gives operational issues and becomes too distrubuted. We need a way to build a house from software bricks and doors and windows and roof elements. Probably we need more standards for that.  Another bold statement. AI systems "programming" themselves is nonsense (I have not seen a shred of evidence).  AI systems are stochastical systems.  Programming is imperical. In summary, up to today you can not build software without getting into the nitty gritty very quickly.  It's like building a house but having find your own…

Programming languages for z/OS

  • Post category:DBAOTMProgramming
  • Reading time:6 mins read

In this post I will discuss the programming languages you find on z/OS, and what they are generally used for. COBOL The COBOL programming language was invented 60 years ago to make programs portable across different computers. The language is best usable for business programs (as opposed to scientific programs). COBOL is a language that must be compiled into executables, load modules. IDENTIFICATION DIVISION. PROGRAM-ID. COBPROG. ENVIRONMENT DIVISION. DATA DIVISION. PROCEDURE DIVISION. DISPLAY "HELLO WORLD". STOP RUN. PL/I PL/I was developed in the mid-1960s with the aim to create a programming language that could be used for business as well as scientific applications. Like COBOL, PL/I programs must be compiled into load modules. World: Procedure options(main); Put List( 'Hello world' ); End World; Assembler Assembler is still around. In the past business applications were developed using Assembler. Nowadays you should not do that anymore. But there are still a lot of legacy assembler programs around on the mainframe. In the old days, assembler was often used to implement tricks to achieve things that were not possible with the standard operating system, or other programming languages. This practice has created a problematic legacy of very technical programs in many mainframe application portfolios. The modern stance is that Assembler program should be regarded as severe legacy, because it is no longer maintainable and Assembler program are a risk for operating system and middleware updates. Furthermore, we find Assembler programs in modifications to the z/OS operating system and middleware. z/OS offers a number of points where you can customize the behavior of the operating system. These so-called exit-points oftentimes only have interfaces in Assembler. Like application programs in Assembler, z/OS exits in Assembler are a continuity risk. Not only because nobody knows how to program Assembler anymore, but even more so because these exit points make use of interfaces that IBM may (and wishes to) change at any point in the future. IBM is actively removing Assembler-based exit points and replacing these where needed with configuration parameters. The bottom line is that you should remove all home-grown Assembler programs from your z/OS installation. TEST0001 CSECT STM 14,12,12(13) BALR 12,0 USING *,12 ST 13,SAVE+4 LA 13,SAVE WTO 'HELLO WORLD!' L 13,SAVE+4 LM 14,12,12(13) BR 14 SAVE DS 18F END Java The language invented by a team from Sun in the 1990s with the goal to develop a language that could run on any device. Support for Java on the mainframe was introduced somewhere in the beginning of the 21st century. Java programs do not need to be compiled. They are interpreted by a special layer that must be installed in the runtime environment, called the Java Virtual Machine. The execution is (therefore) far more inefficient than COBOL and PL/I. So inefficient that running it on the mainframe would be very expensive (see section Understanding the cost of software on z/OS, MLC and OTC). To address this IBM invented the concept of zIIP specialty engines (see section Specialty engines), which makes running Java on the…