The worst programming language ever

[HobGoblyn]

Just watched this on YouTube, apologies if it’s been posted before.

It’s an hour long, but in my opinion well worth a watch

https://youtu.be/2mnYf7L7Amw

[Tagli]

Didn't we already have one? -> Malbolge

[brucehoult]

This guy had both very strange opinions, and a poor command of facts lol.

COBOL is of course very far from being one of the worst programming languages. It's a bit wordy for HelloWorld, but scarcely more so than Java (perhaps he'll get to that). He also says it's from about 40 years ago. Uh .. it's from more than 60 years ago. I had a summer holiday job writing COBOL 40 years ago. These young people, I don't know ....

APL has nothing to do with the lambda calculus. It's an array processing language like R or numpy.

I'm only 5 minutes in ....

[james_s]

C is almost 50 years old and is probably the more popular and widely used programming language in the world. The is something to be said for old languages that are still in use. No need to reinvent the wheel.

[brucehoult]

C is almost 50 years old and is probably the more popular and widely used programming language in the world. The is something to be said for old languages that are still in use. No need to reinvent the wheel.

There's another thread on that topic with ongoing debate...

JavaScript, Python, and Java have a *lot* more people writing code in them than C/C++ do.

[SiliconWizard]

I've just taken a quick look and yeah, a lot of what he said is bogus. But there was one fun slide, on which, IIRC, there were two pages of Python code side by side - both sides looked identical visually, but one was claimed to be buggy. Sorry, but yeah, this is unfortunate fun.

[retiredfeline]

This guy had both very strange opinions, and a poor command of facts lol.

Thanks for saving me an hour. 

Actually I would probably have watched for a couple of minutes and quit. I figure that any YT clip with a title like The Worst <something> Ever is probably clickbait. 

[blacksheeplogic]

COBOL is of course very far from being one of the worst programming languages. It's a bit wordy for HelloWorld

I have done a lot of COBOL in the past and there is nothing wrong with the language. It was used a lot for batch processing and was a pretty efficient language for that. The people commenting about these older languages never worked in that era when systems were as constrained. Most if not all have never written or maintained anything written in the language and probably therefore should not be offering their expert opinion on the language.

[HobGoblyn]

I took the program as a light hearted pi$$ take of  things people find annoying with various programming languages, his goal to create a programming language to include all of them plus adding others.

I didn't dissect the exact truth of every statement he made, i think you're taking it too seriously,  it was a comical (in my opinion) exercise.

I particularly like the bit referencing hitch hikers guide to the Galaxy where he says

"Only lines needing a goto need a number. They have to start with a number that is a multiple of 42..........and I don't care of your code base is 10 millions lines, it must go 42, 84, 126....
And if two people add one on the end and they both check in at the same time, then you will get a compiler error, a compiler error that will say, 'attempted to reassign a constant', which it will also say for 1/2 a dozen other things that I haven't decided yet, because I don't want to make it too easy"

[newbrain]

The take on IBM COBOL is particularly stupid.
It's as if he'd included makefiles, compile and link options as part of C.
The three lines before and the three after the source are job control language, not COBOL.

As for APL, it's a powerful language which was born as mathematical shorthand and only after a long time implemented on computers.
Yes, it's maybe easier to create write-only code than in other languages, but it's possible to write good code.
Yes, it's jarring, as is, say, learning a tongue with a different script from your native one.
OTOH, the syntax is simple. Expressions are evaluated right to left. Functions can be monadic or diadic, and concepts like reduction (/) outer product (°.) and inner product (.) are extremely powerful.
I used to use it many years ago for it's natural handling of linear algebra and mostly loopless programming - I strangely find that something in Python reminds me of that.

For both we are talking languages that date 60 years in the past. I think they both deserve admiration - or someone funnier than that guy.

[Just_another_Dave]

COBOL is of course very far from being one of the worst programming languages. It's a bit wordy for HelloWorld

I have done a lot of COBOL in the past and there is nothing wrong with the language. It was used a lot for batch processing and was a pretty efficient language for that. The people commenting about these older languages never worked in that era when systems were as constrained. Most if not all have never written or maintained anything written in the language and probably therefore should not be offering their expert opinion on the language.

Additionally, cobol development tools have improved a lot since it was released and the language itself has also evolved a lot (nowadays it even supports object oriented programming)

[rstofer]

I played around with COBOL back in '70 so I know it is more than 50 years old.  It came out in 1959, a couple of years after Fortran.

Laugh at the language at your peril.  COBOL programmers are scarce and well paid.  Used your ATM lately?  Chances are the transaction was done in COBOL. Banks are in no hurry to change to something else when they have a language that is perfectly suited to their applications and an extensive code base.

As to Fortran, it is still widely used in the scientific community mostly because there is a gigantic code base.  It was my first and still is my favorite language for number crunching.  Adding 'objects' was probably a mistake (Fortran 2003).  There's a reason there are wrapper approaches for incorporating Fortran code into Python projects.

[Tomorokoshi]

Prediction: On April 7, 2064 it will still be possible to buy a variant of the IBM Z System that runs COBOL.

[MIS42N]

I didn't watch the video, might do later. My favourite difficult "language" is SUBLEQ. There is only one instruction - SUBLEQ A,B,C - SUBtract A from B and if the result is less than or equal to zero, branch to C. If program and data are allowed to share the same space, certain locations allocated for I/O, a few constants, it is possible to write just about anything. Because there is only one instruction, it is not necessary to specify an action so each instruction is just location, location, location. Maybe a real estate agent designed it.

[PlainName]

I took the program as a light hearted pi$$ take of  things people find annoying with various programming languages, his goal to create a programming language to include all of them plus adding others.

This. Some people take things far too seriously on here!

[Just_another_Dave]

It seems that someone took the time to implement the language designed in the video: https://github.com/BSLang/BS

[brucehoult]

I didn't watch the video, might do later. My favourite difficult "language" is SUBLEQ. There is only one instruction - SUBLEQ A,B,C - SUBtract A from B and if the result is less than or equal to zero, branch to C. If program and data are allowed to share the same space, certain locations allocated for I/O, a few constants, it is possible to write just about anything.

ABSOLUTELY anything. It's Turing-complete.

But very hard to use, and slow.

[SiliconWizard]

Otherwise, you can try Brainfuck. Better yet, you can switch to Whitespace, the syntax of which is entirely made only of whitespaces, which should appeal to Python adepts. (OK we can have a laugh here, right?)

https://en.wikipedia.org/wiki/Brainfuck
https://en.wikipedia.org/wiki/Whitespace_(programming_language)

[SiliconWizard]

It seems that someone took the time to implement the language designed in the video: https://github.com/BSLang/BS

I admit BS is really funny.

[rstofer]

Prediction: On April 7, 2064 it will still be possible to buy a variant of the IBM Z System that runs COBOL.

The same prediction has been made about Fortran

“We don’t know what language engineers will be coding in the year 2100. However, we do know that it will be called FORTRAN.” — C.A.R. Hoare

The earlier version mentioned the year 2000

"I don’t know what the language of the year 2000 will look like, but it will be called Fortran." -- C.A.R. Hoare

In any event, Fortran is alive and well after 64 years.  Let's see how long some of the newer languages last.

[SiliconWizard]

FORTRAN is alive and well, but it has been nowhere near the "language of the year" for a number of decades, though. Hoare was right in seeing it would linger on, but was exxagerating its importance a little bit. Predicting the future is pretty impossible.

[ncot_tech]

Heh I just received a COBOL book through the mail with the intention of reliving the horror of my A-Levels by trying to write something in COBOL again.

I've not watched the video, but there's far worse languages than COBOL. Javascript, for example

[SiliconWizard]

Hum, no. As Bruce showed lately, Javascript is actually a pretty decent language. How and why it's being used may be often questioned, but this is another matter. The language itself is really not bad, and is certainly a modern language.

COBOL is atrocious. As a domain-specific language that has a gigantic code base worldwide and has largely proven to be useful for the domain in question, it's still going strong and will continue in the foreseeable future. But purely as a programming language? Nah. But that's fun anyway - I've read a lot of fun claims about programming languages all over the place, but I think this is the first time I see somone say that JS is far worse than COBOL.

[T3sl4co1l]

The main critique of programming of course is largely not so much the language (not that bad ones are any help, mind), but the environment in which it's placed.  COBOL is bad, but it's particularly notorious because of its crusty, ancient, mainframe-centric development environment (if you can call that "development").  Dev, deployment, scaling whatever, those are the real problems -- from any language.

It should be no surprise we have all these containers and virtual servers and dependency trees today, because we've always had them, and they've always been bad, they're simply continuing to grow with technology and managing them manually is utterly intractable so we write algorithms to do it instead.

In my opinion, JS is a perfectly usable language, but understand that opinion is based on the limited scope I use it in.  It does tend to be rather verbose; I have four examples of projects in the 1-3 kLOC range, some of which I could probably clean up if I had deeper knowledge of it.  Everything else of mine is short calculators (a few kLOC in total, individuals typically being under 100 lines), or just sitting down for a session at the console.  It sure is handy: it has powerful string and array functions at your fingertips, and is basically only ever an F12 away.

In contrast, I can't imagine how much of a pain a production web or backend service might be -- in JS or otherwise.  Typical served JS is generated, minified and obfuscated, partly to optimize storage size and execution speed, partly for... less transparent reasons.  There are transpilers between many languages, any of which might be used for actual development, over JS; and there are zillions of libraries (implemented in JS again, or integrated into the browser natively, or as webasm or various other trendy things), wherein you incur all the usual dependency-hell problems.  Add to that, proprietary (private) libraries, various web APIs, etc., and you've got plenty of potential for a real mess.

Tim

[brucehoult]

Hum, no. As Bruce showed lately, Javascript is actually a pretty decent language. How and why it's being used may be often questioned, but this is another matter. The language itself is really not bad, and is certainly a modern language.

I think the correct way to put it is that Apple, Mozilla, and Google have spent probably hundreds of millions of dollars optimising the heck out of their respective Javascript implementations because web browser performance is super-important, and javascript performance is now such a huge part of it. Despite the lack of type declarations, they manages to figure out (in well-wrtten code) that a particular variable can only ever be a floating point number, or only ever an integer and they compile fast versions of the code with that assumption, and the occasional check to make sure the integer hasn't overflowed -- in which case it branches to a slower (but still compiled) version of the code.

There are a ton of awful mistakes in the design of Javascript:

- if you accidentally write, say "for (i=0; i<10; ++i){...}" and you haven't declared i elsewhere in the function, then it's a GLOBAL in the web page document

- ok, so you can write "for (var i=0; i<10; ++i){...}" and i will only be visible inside the {...}, right? Wrong. It's available everywhere in the function. If you had another "var i" in an enclosing scope in the function then IT'S THE SAME VARIABLE

-  ok, finally, at last, they invented "let". So "for (let i=0; i<10; ++i){...}" works how you'd expect.

JavaScript lets you mix types in expressions, doesn't warn you, and doesn't give you what you expect:

var i = 1;  // ok, it's 1
i = i + "";  // now it's "1"
console.log (i+1); // "11"
console.log(i-1); // 0

var j = "1";
j++; // j is 2
var k = "1";
k += 1; // k is "11"

All these statements evaluate to true

0 == ""
0 == "0"
0 == " \t\r\n "
"0" == false
null == undefined

""  != "0"
false != "false"
false != undefined
false != null

There's a lot more. It's an absolute minefield.

But it runs fast now.

And you write tests, right? Lots of tests.

[MIS42N]

COBOL was right for the times. The compilers produced small efficient programs that could produce payrolls for 25,000 employees on a computer with 64kbyte and an instruction time of 2us. Because of the verbosity, it wasn't difficult to maintain. Not quite self documenting like Grace Hopper wanted, but close. The PIC(ture) reservation of memory is better tuned for portability than most languages because it described what the programmer really wanted rather than what the machine provided. I want to store up to a million dollars as credit or debit, in a computationally efficient manner, PIC S999999.99 COMP. And let the compiler figure out how to deal with that in whatever architecture it ran on.

Many people criticise COBOL for being slow to write, due to the verbosity. I haven't written a COBOL program for over 30 years, but in the day I could churn out between 200 lines a day to 100 lines an hour. Like any language the effort is in translating the ideas into actions and it doesn't really matter in what language that action is expressed. For one employer I wrote programs that were COBOL, FORTRAN and Assembler composites to take advantage of the computational features of FORTRAN, the ease of laying out a report in COBOL, and Assembler routines to compress and decompress records being written to and read from magnetic tape.

Today such efficiencies are no longer prized. Throw more memory and a bigger processor at the task. The C language changed a lot, now the choice for more efficient programs. And if efficiency is subordinate to productivity , choose the language appropriate to the task at hand. The worst programming language is the one that gives the most grief trying to translate ideas to actions. It may be possible to compute satellite orbits using COBOL, or write invoices using FORTRAN. Who would want to.

[Just_another_Dave]

The main critique of programming of course is largely not so much the language (not that bad ones are any help, mind), but the environment in which it's placed.  COBOL is bad, but it's particularly notorious because of its crusty, ancient, mainframe-centric development environment (if you can call that "development").  Dev, deployment, scaling whatever, those are the real problems -- from any language.

Thankfully, COBOL development tools have improved a lot outside the IBM world. Nowadays it isn’t uncommon to develop COBOL programs using a version eclipse (or other modern IDE). Sometimes, they even test programs in normal windows machines before uploading them to the mainframe (there are compilers for both windows and Linux). And just in case you need to program a front end for the backend that runs in the mainframe, some companies offer tools for developing mobile phone apps in cobol, as well as visual cobol (like Visual Basic but using cobol)

[SiliconWizard]

The main critique of programming of course is largely not so much the language (not that bad ones are any help, mind), but the environment in which it's placed.  COBOL is bad, but it's particularly notorious because of its crusty, ancient, mainframe-centric development environment (if you can call that "development").  Dev, deployment, scaling whatever, those are the real problems -- from any language.

Thankfully, COBOL development tools have improved a lot outside the IBM world. Nowadays it isn’t uncommon to develop COBOL programs using a version eclipse (or other modern IDE). Sometimes, they even test programs in normal windows machines before uploading them to the mainframe (there are compilers for both windows and Linux). And just in case you need to program a front end for the backend that runs in the mainframe, some companies offer tools for developing mobile phone apps in cobol, as well as visual cobol (like Visual Basic but using cobol)

Yes, I've seen modern IDEs, tools and libraries for COBOL.
The thing is - if we consider COBOL as a general-purpose language, it would be horrible. But it's not meant to be one.

While domain-specific languages were rather common back then, these days, they tend to be frowned upon in general regardless of their merit. We tend to favor general-purpose languages whatever the application, for a number of reasons, including of course the ease of finding developers and replacing them.

[Just_another_Dave]

The main critique of programming of course is largely not so much the language (not that bad ones are any help, mind), but the environment in which it's placed.  COBOL is bad, but it's particularly notorious because of its crusty, ancient, mainframe-centric development environment (if you can call that "development").  Dev, deployment, scaling whatever, those are the real problems -- from any language.

Thankfully, COBOL development tools have improved a lot outside the IBM world. Nowadays it isn’t uncommon to develop COBOL programs using a version eclipse (or other modern IDE). Sometimes, they even test programs in normal windows machines before uploading them to the mainframe (there are compilers for both windows and Linux). And just in case you need to program a front end for the backend that runs in the mainframe, some companies offer tools for developing mobile phone apps in cobol, as well as visual cobol (like Visual Basic but using cobol)

Yes, I've seen modern IDEs, tools and libraries for COBOL.
The thing is - if we consider COBOL as a general-purpose language, it would be horrible. But it's not meant to be one.

While domain-specific languages were rather common back then, these days, they tend to be frowned upon in general regardless of their merit. We tend to favor general-purpose languages whatever the application, for a number of reasons, including of course the ease of finding developers and replacing them.

Successful languages tend to end up finding their own niche. The idea of having a general purpose language that can be used for anything seems great while you’re learning your own language, but after learning several languages I realized that each type of application has its own needs and having a standard library that helps you with them saves a lot of time. However, most new languages try to innovate in their sintaxis or supporting any type of programming paradigm instead of providing better tools for a certain niche, which seems to make them a solution looking for a problem to solve instead of something worth your time (until third party libraries make it useful for a particular domain)

I wouldn’t use cobol for developing a simulator, but neither I would use C++ for programming a website

[mikerj]

JavaScript, Python, and Java have a *lot* more people writing code in them than C/C++ do.

Overall sure, because that encompasses a huge amount of web/desktop programming.  Look at microcontroller development and the situation is reversed.

[NorthGuy]

Perl was widely used. It wouldn't survive a second in Today's world

[Saskia]

actually I kinda liked make (the original one) and using awk and sed plus variables in the target declaration. It made for very compact and fast code. Which was what I was paid for. It took my successor about 2 years to replace my 64 lines of code.

[SiliconWizard]

Make is still widely used, and although I personally don't use the latter, I believe awk and sed too.
Even many of the more modern build tools (such as CMake) generate makefiles, and make does the real job.

[brucehoult]

Perl was widely used. It wouldn't survive a second in Today's world

I use Perl every day. It's a superset of both sed and awk, and runs faster. It's perfect for 1-100 line scripts where Python looks like COBOL in comparison.

[brucehoult]

Make is still widely used, and although I personally don't use the latter, I believe awk and sed too.
Even many of the more modern build tools (such as CMake) generate makefiles, and make does the real job.

"make" does two very different jobs:

1) describe the dependencies between files, and the actions to update them, in a concise, powerful, understandable, and maintainable way.

2) execute the dependency graph as quickly as possible using the available resources

Make does a pretty good job of 2), though ninja is better.

Make does a lousy job of 1) by modern standards. There are many better options now. And, yes, those better options often use make or ninja as the execution engine.

[Saskia]

Mind you, it has been in the late 90s that I wrote that program. It replaced a pretty shitty shell script that took about an hour to run with a small script setting a couple of variables and calling make with the corresponding target. In those target definitions sed and awk took values from the calling shell script to define the targets on the fly by modifying the definitions during runtime and adapting file names and path names during execution. Execution time dropped by about 95 percent. I was happy, but the code would have one the obfuscated contest back then.
Oh well. The job that came after that one led me to a 3 letter company where I did software support for those folks in Poughkeepsie and Austin. Like debugging crash dumps of their power based ?IX machines and HA / parallel nodes.
Enjoyed it back then. Should not have left. Oh well.