IMO Matlab is the worst programming language widely used in production.

This perfectly fits my expectations of Matlab:

- i is a mutable, but should be constant

- It has a horrible, non obvious name because mathematicians are used to it. (And they are not used to var names longer than two chars)

- It is in the global scope.

- It's a feature that has a special syntax (sort of).

/edit Apologies for php programmers, maybe php is worse. But I'm not sure.

I was using a very well-known popular computation software direct competitor to ANSYS Multiphysics. I was using it since early version 3 days, through 4.x over a period of 3 years in my phd in the field of fluid-structure interaction (e.g. fish in flow). The computations usually took over several days on many cpus for 1 second of real-life simulation, making testing quite painful. Hence, many studies do not involve testing like in software field.

I was calculating a parameter enhancement where my calculations were showing a great 180% enhancement; this result would make it into very high ranking (15+ IF) paper right away. By then, several people had written numerous papers on this matter using this multiphysics software in well-known journals. But my gut feeling didn't let me. Eventhough my professors were pressing me to publish, I took 6 painful months (toward the end of my phd) to rigorously test the software itself, having nothing to do with my work, since it was closed-source.

After 6 months, I found out that a velocity term used in their stabilization algorithm does not use relative velocity, but absolute velocity, leading to enormous amount of fake diffusion into the model. I had to travel to another city in europe to convince them that there is such bug.

Every single work in my field that used this software till then had been severely invalid. And what the developers did: they fixed the bug in the next sub-release without putting it in the changelog like nothing happened.

I know the feeling, but I think I have a bug that beats even this one...

Once, I was working on the "alias" keyword in MacRuby, and getting it to work with methods defined in Obj-C. Since MacRuby objects are just extensions on Obj-C objects, some methods are defined in Obj-C and require special casing in order to alias them to a different identifier. For example, if you want to alias "Array#length" to a different name, you'd actually be aliasing "-[NSArray length]".

So I do everything I should need to do to make it work: get a handle to the object, the object's class, the method defined for the class, a selector for the new name...but no matter what I tried, every time I aliased the method, and attempted to call the method by the new name, I would always get the same error: "Method not defined".

Finally, I decided to dive deep with gdb and find out exactly what was going on. To my shock and amazement, I came to realize that I was properly aliasing the method but, due to the nature of NSArray's implementation as a class cluster (and the fact that Obj-C doesn't have proper virtual methods like C++), the implementation of "-[NSArray length]" was literally:

    - (NSInteger)length
    {
      [NSException raise:@"Method not defined." format:@"%"];
    }

I had a similarly fun time back in the 90s debugging a VBA script a co-worker had written for an Excel spreadsheet. She was looping through a bunch of time values...

... so she named her variable "time"

... which, when modified, would (naturally) set the system time of the computer.

I'm not sure whether they've fixed that one yet.

>the imaginary constant i in MATLAB was getting overwritten!

The constness of i in Matlab is also imaginary, which is pretty terrible.

Unlike many of the other commenters, I don't see much problem with having "i" mean the imaginary unit. Where MATLAB falls down though is:

1.) not having lexical scoping

2.) not having warnings when a global is overridden in a local scope

these are pretty inexcusable. For anyone looking for a "better MATLAB", Python has NumPy, SciPy and Matplotlib which are pretty much everything.

I made a similar error once working in Adobe Air (if I recall):

    for (x = 0; x < thing.length; x++) { }

To look at it like that, it's blindingly obvious. But it was in the middle of a whole lot of other code, and of course, the for loop ran perfectly fine.

Nice anecdote, but that's a rather uber-sensational title - not in a good way.

Matlab: the language designed so poorly it makes PHP look good.

This is not the worst bug ever. Nice story, however, the title is way over the top.

Kind of along the same lines in the sense of being my biggest facepalm moment; many years ago in my first professional programming gig we had full SA access to our sql server. We regularly did troubleshooting via direct SQL statements (a practice I've since shied away from). One particular day, we were troubleshooting a problem in our monthly billing process. I went to delete a few rows and foolishly forgot to include a limiting statement on the WHERE clause, which resulted in most of the data being blown away.

Thankfully, we were able to restore that table from a backup and rerun everything to rebuild the table's state to a correct place ... but suffice to say the experience taught me many things about attention to detail, and how debugging in production should happen.

Good times!

As a mechE, I was brought up on Matlab. We were taught to use ii, jj, kk... as our index variable names. Many years later, I still prefer them to i, j, and k.

That is a pretty awful MATLAB perk, using 'i' as the sqrt(-1) (and indexing the arrays from 1...).

It makes polyglot programmers make a lot of silly mistakes. It would have been SO easy to call the imaginary constant just 'I' instead of 'i'...

Just want to say thanks to all the Hyperbole Police in this thread pointing out this isn't actually the worst bug ever.

it's the most frequent error you can do when writing 'a-little-bit-more' complex scripts using MATLAB. it's sad to say but MATLAB takes too much care of backward code compatibility and they didn't fix this! all matlab's newcomers do that error. :)

On my first programming job (2004), I was adding shopping cart functionality to a proprietary CMS written in PHP. For some reason I couldn't get a simple item listing to work. I had spent several hours debugging it before I found the problem.

The CMS had a database query result class with a method named something like "numberOfRecords". It returned the number of records minus one...

I told my boss about this, and his answer was "Yeah I know, but we don't want to fix it because a lot of code depend on that bug."

Thats not so much a "nice bug" but rather a big fat warning sign for anyone trying to use MATLAB.

I'm baffled by the fact that the single most common name for an integer variable has a special meaning (though it's not a reserved word). I'm pretty sure this is a bug in MatLab, not in OP's code.

But still I was wondering: isn't that code horribly un-idiomatic for an array based programming language?

Oh the joys of side-effects. Wouldn't you love to have a programming language that doesn't have them?

If that is the worst bug ever, I would die a happy programmer. Btw, why would anyone use the 3*i form when there is the much clearer 3i form?

Don't trust it too much: http://cm.bell-labs.com/who/ken/trust.html

Fun, but there are worse things than scope shadowing bugs. At least this one is deterministic and can be zeroed in with a few trace prints.

Python (before version 3) leaks variables from list comprehension, while it seems natural to assume that the comprehension has its own scope. Makes for some funny bugs:

  i = ...
  ... # lots of code 
  [ do_stuff(i) for i in range(n) ]
  ...
  # whoops, our outside i has now been modified

That is not what I call "worst" bug. It is a pretty cool bug. Screw Matlab for hiding this from you.

Maybe change the title.

If you call this the worst bug ever (t = [-infty, +infty]), then what's this?

https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi...

For some reason, I've found more bugs like this in MATLAB than in any other domain. Ever.

I spent a few hours debugging an OpenGL program I was working on only to realize that I forgot to account for normalized coordinates. All I had to do was individually multiply x and y by the canvas size.

Always start with the small, obvious stuff first!

Colleague had a long long debugging session doing MDA based code generation, turns out JET (java/ibm/eclipse) template engine had a stupid arithmetic bug, the kind you'll only investigate after everything in the stack has been checked.

Thanks for posting this -- I just went and fixed just such a loop in my own code.

Why did he get the correct results when the script was run stand-alone?

I don't know what I would do without list comprehensions. I can hardly imagine using iteration loops and counters anymore, and this is one among many reasons why.

undefined

Oh, the things a little syntax highlighting can prevent...

Further evidence that j is the one true imaginary unit.

Title is still sensationalist.

"those where"

</grammar nazi>

Who upvoted this?

Nice article but there's a lesson here.

First I'll come with an old bug of mine (early nineties). The bug was very hard to reproduce because it was very very occasional (but terrible in consequences). I simply couldn't find it. I knew I was probably smashing some memory somewhere (I was not that experienced in C) but couldn't find where.

So what did I do after weeks of hunting the bug? I moved my design away to an entirely deterministic one and started recording all the inputs the program received and then I could replay them. At one point, logically, the bug happened. And so was it "recorded". Because my program was now deterministic, I could simply feed it the inputs (and the time at which they happened) and, surely enough, the bug was there.

And then finding the cause of the bug was of course trivial.

What's the lesson?

Well, first obviously bugs that you cannot easily reproduce because you cannot "reproduce the state" are typically kinda hard to track down.

The less "state" in your program, the easier it is to reason about your program and the easier it is to reproduce the state.

The lesson?

Functional programming rocks.