A long running project wanted a little flexibility in their compile script so added conditionals; then variables, statements,... No documentation except the awful sources. No tests except "it used to work". If tempted to write your own language, then fine - just don't let it escape into the real world without the docs, tests, support,...

I used to work for a while in a company where the main product was written in ColdFusion. It was the worst programming nightmare you can imagine. Html syntax for control structures such as loops and ifs.

I would say Prolog. I had to do a homework 15-16 years ago and absolutely nothing was available on the Web and the book was totally wrong translated. So I passed about 5 hours to make that program accept some user input.

i hate PHP - every similar command comes with different order of parameters, and for methods where you should use paramters there was a new method

PS: i only know the early versions of PHP but still i refuse to use it again

Having started my career as a JavaScript developer, I start to see your point after learning TypeScript. Types make everything so readable and understandable!

I wouldn't say I've had a horrible programming language because I have not really encountered difficulties. But from others, it's JavaScript.

Nowadays, I work with PHP, and I hate it not as a language, but as an environment, because it behaves differently depending on settings in PHP.ini. So frustrating!

I think there are a lot of languages that have some burden but I never hated a language. Some of them are harder, some of the more beautiful but in the end every language has its benefits and use cases. We should be more thankful that someone invented these languages and take decades to make a language better and better.

After some years, I would say that JavaScript as a working language is not too bad. You have to be very diligent to work with JavaScript and TypeScript or you will have very quickly a lot of Anti-Patterns.

I think the least preferable working language is for me personally SAP ABAP with Web Dynpro or more specific all proprietary languages that are only invented for a pretty small circle of developers. Oracle does that also a lot like Server Script or their CRM System.

This: codeproject.com/articles/1012650/distributed-sema…

Worst thing I've ever had to work with... I mean just look at this test:

/// <summary>
/// Verify that a semantic type is received on a "remote" semantic processor.
/// </summary>
[Test]
public void DistributedComputation()
{
  SemanticProcessor spOut = new SemanticProcessor();
  SemanticProcessor spIn = new SemanticProcessor();

  received = "";
  OutboundDistributedComputingReceptor dcrOut = new OutboundDistributedComputingReceptor(4002);
  InboundDistributedComputingReceptor dcrIn = new InboundDistributedComputingReceptor(4002, spIn);

  // Create an "emitter" in which a semantic type emitted on the TestMembrane permeates
  // into the inner DistributedProcessMembrane for our test type.
  spOut.AddChild<TestMembrane, DistributedProcessMembrane>();
  spOut.OutboundPermeableTo<TestMembrane, TestDistributedSemanticType>();
  spOut.InboundPermeableTo<DistributedProcessMembrane, TestDistributedSemanticType>();

  // The stateful DCR out lives in the distributed process membrane.
  spOut.Register<DistributedProcessMembrane>(dcrOut);

  // Create a "receiver" in which a semantic type is received on the inner DistributedProcessMembrane
  // and the test type permeates out to a "handler" receptor.
  spIn.AddChild<TestMembrane, DistributedProcessMembrane>();
  spIn.OutboundPermeableTo<DistributedProcessMembrane, TestDistributedSemanticType>();
  spIn.InboundPermeableTo<TestMembrane, TestDistributedSemanticType>();

  // The stateful DCR in lives in the distributed process membrane.
  spIn.Register<DistributedProcessMembrane>(dcrIn);
  // The responding receptor lives in the TestMembrane
  spIn.Register<TestMembrane, TestReceptor>();

  // Put a semantic type instance on the outbound side.
  spOut.ProcessInstance<TestMembrane, TestDistributedSemanticType>((t) =>
  {
    t.Message = "Hello World";
  });

  // Wait a bit for threads to do their thing and Http posts to do their things.
  // !*!*!*!* Sometimes this wait must be longer -- the unit test engine can really slow things down.
  // !*!*!*!* This is particularly true when running the test in the debugger!
  // !*!*!*!* If this delay isn't long enough for the server's message to be processed, you will get
  // !*!*!*!* errors related to accessing objects on an unloaded AppDomain.
  // !*!*!*!* In real life this woudn't happen -- this is an artifact of unit testing a complex
  // !*!*!*!* multi-threaded process.
  //Thread.Sleep(500);

  // Because we know it works, we could actually do this, which is particularly useful when we're
  // debugging and single stepping through code -- we do not want the test in this AppDomain
  // to exit prematurely!
  while (String.IsNullOrEmpty(received))
  {
    Thread.Sleep(0);
  }

  Assert.That(received == "Hello World", "Expected to receive 'Hello World'");
}

Besides that, also I really didn't like Amazon Athena's strange SQL behavior. It uses some database named Presto. Why can't they just use a normal SQL database? I remember having to run queries and certain functions and operators that existed in MySQL and Microsoft SQL and PostgreSQL was absent. It was extremely frustrating. In general, I'm not a big fan of "SQL-Like" languages where they kinda sorta try to implement SQL but not fully... I found JIRA JQL to bad a pain at first but it's one of the better SQL-Like languages... But still, when you know that the backend is just using SQL anyway, it makes you want to just be able to use full SQL.

I just had a discussion with a colleague about a JavaScript file that we're both working on. There's this 'that' variable/object that was suddenly being used in the functions without having it being initially declared. Not being well versed in JavaScript I was assuming that must be a built-in Java object that is equivalent to 'this'. But then it takes different function arguments. It didn't seem right. If it was an anonymous function, shouldn't it also be declared as such somewhere in the script?

Anyway, we traced the 'that' assignment on a different JavaScript file that was declared earlier before the JavaScript file that we were working on. And even worse, that assignment was declared in one of the functions there, not at the top as global variable!

"This is sloppy coding!" I said. Just because the variable that you declared using 'var' can be used beyond the function that you declared at, that doesn't mean you have to use it as global variable! Using 'let' is still much better. It prevents unwanted behavior when treating variables as though they are available everywhere!

So, that's my gripe with JavaScript so far. Sloppy coding can happen in any programming language but JavaScript made it too easy to do it.

Wow, I love JS, because I can get things done fast, however for stable code, I usually go for TypeScript (which transpiles to JS).

The worst language I ever had to work with was ABAP. It feels like a DB query language overloaded with everything one needs for GUI and logic in the worst way possible. It's old and clunky, and I hate it. Luckily, I don't have to do anything in it anymore.