Worst programming language ever?

Mike Krailo

Well-known member
Local time
Today, 14:42
Joined
Mar 28, 2020
Messages
1,341
This was sparked by the following presentation given by Mark Rendle:

First up is IBM Cobol's Hello World code:
Code:
//COBUCLG JOB CLASS-A, MSGCLASSZA,
//HELOWRLD EXEC COBUCLG,PARM.COB='MAP,LIST,LET'
//COB.SYSIN DD *
001 IDENTIFICATION DIVISION.
002 PROGRAM-ID. 'HELLO'.
003 ENVIRONMENT DIVISION.
004 CONFIGURATION SECTION.
005 SOURCE-COMPUTER.  IBM-360.
006 OBJECT-COMPUTER. IBM-360.
0065 SPECIAL-NAMES.
0066    CONSOLE IS CNSL.
007 DATA DIVISION.
908 WORKING-STORAGE SECTION.
009 77 HELLO-CONST PIC X(12) VALUE
075 PROCEDURE DIVISION.
090 OOO-DISPLAY.
100     DISPLAY HELLO-CONST UPON CNSL.
110     STOP RUN.
//LKED.SYSLIB   DD DSNAME=SYS1.COBLIB,DISP=SHR
//              DD DSNAME=SYS1.LINKLIB,DISP=SHR
//GO.SYSPRINT   DD SYSOUT=A
//

In contrast APL (A Programming Language)
Code:
'Hello, World!'

And Conway's game of life in APL:
1651148988722.png

That's just totally unreadable and how would you even type it in? You had to have an APL keyboard of course.
1651149144951.png

Moving on to INTERCAL, which was designed to simply poke fun at other programming languages.
1651149371922.png

Notice the lines with PLEASE in them, if you didn't have enough of that word in your code, it would not compile due to programmer being too impolite. It's like a form of slavery to the compiler. To make matters worse, instead of GoTo statements you had to use Come From instead. The compiler was designed to drive up your CPU usage to 100% if you didn't add that last line "PLEASE GIVE UP" at the end.

Mark puts Visual Basic 3.0 on the list because at the time there was no object oriented coding in that version and the Data Access Layer was non-existent until VB4 came out.

The rest of the video shows Mark attempting to piece together an even worse programming language than INTERCAL. He called it BS. Have a look at it comment back here.

1651150797269.png
 
Probably should add LISP to that mix. The programmers of the day gave it the nickname "LISP - Lots of Insipid, Silly Parentheses" - because practically everything had to be enclosed parenthetically. Sometimes with multiple layers.
 
I recently ran across a very similar article (which actually may refer to this article), but then "lost" it so I couldn't post it.
 
At the risk of going too far afield, this reminds me of the days back in grad school, when we were forced to read insufferable text books for many course. A few of us came up with the notion that many of them were written solely to intimidate new students, and not to impart any real knowledge. The guiding principle of Academic Writing is that "I'm smarter than you and I'm proving it by writing something you can't understand."
 
Ah, but no, George. The guiding principle was "If I don't publish something else original then I had better publish a book that I can use in one of my courses and force students to buy it. I may not be smarter than you - but I can still give you a bad grade if you don't buy my book."

One of my (now deceased) committee professors did exactly that - and I even managed to contribute a chapter without realizing he was going to do what he did until it came out. Cheap-ass bastard didn't even give me a free copy.
 
They left out TCL and Universe SQL.

In Universe SQL it could be:
You pull the trigger WHERE your foot is in the target and blow a hole in both feet with one shot.

I'll explain since this is so obscure. Universe supports multilvalued attributes. Referring to a multivalued attribute with WHERE returns True if any of the multivalues in the attribute match the test. The key word for returning the specific multivalues that match the test is WHEN.

While I am here, see if you can get your head around this. The table name (more accurately, the VOCabulary entry for the data file) can include dots and underscores without requiring delimiters.

However the dot is also the delimiter between the file and attribute just as it is for the table and column in TSQL. It is not unusual for both the file and attribute names to include a dot or two. The parser somehow works it out but I have no idea what happens if there are ambiguities.

The underscore is also the delimiter between them when referring to a multivalue. (It is essential when referring to the multivalue attribute for updates.)
 
The guiding principle of Academic Writing is that "I'm smarter than you and I'm proving it by writing something you can't understand."
And I thought that I was the only one with that opinion. Some experts recommend giving precedence to articles on .edu websites. Not I. They are not written to inform, especially not for the novice. I think the idea behind the recommendation is that they are more likely to be factually correct. I won't argue with that but being able to follow the math of relational algebra is way beyond what anyone but someone who wants to actually design the software that manages relational databases needs to understand. My eyes glaze over when I look at the expressions but I'm pretty sure I understand what I need to to actually design correct relationships.
 
Pat, I'm guilty of that advice, but it is based on their INTRO TO NORMALIZATION articles rather than their "Strict Mathematical Theory of Interrogatory Logic" (which is one of the contributors to the proof that SQL actually works from a math standpoint). I'm simultaneous sad and not so sad that Hurricane Katrina took my book on Interrogatory Logic. I didn't bother to buy the companion volume on Assertory Logic as that was just the formal proofs for syllogisms. When you get to proving logical proofs with logic, it starts to get a bit... incestuous.
 

Users who are viewing this thread

Back
Top Bottom