Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by Fnord666 on Thursday April 16 2020, @03:41AM   Printer-friendly
from the this-dept.-intentionally-left-blank dept.

IBM age discrimination lawsuit suddenly ends, suggests Big Blue was willing to pay to avoid discovery process:

The judge overseeing Jonathan Langley's age discrimination lawsuit against IBM has dismissed the case, which was scheduled to go to trial later this year.

The court order [PDF] closing the case, signed on Wednesday by Judge David Ezra in the Texan Western District Court, cites a stipulation of dismissal by Langley and IBM. That suggests the two parties have agreed to settle confidentially out of court.

The Register asked IBM to confirm that the case has been settled. We've not heard back. Langley's attorneys could not be reached for comment.

In 2018, Langley sued IBM, claiming age discrimination. He was laid off at the age of 60 after 24 years at the biz. The lawsuit was filed several months after a report from ProPublica and Mother Jones claimed that IBM had embarked on a company-wide campaign to dismiss older workers, a project said to be called Operation Baccarat.

In January, Andrew Austin, the federal magistrate judge overseeing the pre-trial phase of the litigation recommended that case be allowed to go to trial. Then in February, IBM's motion to dismiss the case was rejected. Last week, Judge Ezra set the trial date for Monday, October 19, 2020.

But with the dismissal of the case, there will be no trial.

Numerous other lawsuits are pending; by some estimates 13,000 people were let go under similar circumstances.

[Disclaimer: I was an employee of IBM back in the last century. --martyb]


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Thursday April 16 2020, @12:39PM (2 children)

    by Anonymous Coward on Thursday April 16 2020, @12:39PM (#983545)

    Had to learn it as part of my CS degree in the late 90s. Never quite understood all the hate it got, it wasn't a horrible language just very rigid.

  • (Score: 0) by Anonymous Coward on Thursday April 16 2020, @03:47PM

    by Anonymous Coward on Thursday April 16 2020, @03:47PM (#983633)
    The main problem with COBOL is that it is much too verbose, so much so that it's even been quipped that it is the only language where the source code is generally longer than than the compiled machine code. They thought that by making the syntax English-like they could give non-programmers the ability to program, only to find out that logic involved in writing correct programs isn't an artefact of syntax, and they only succeeded in obfuscating this logic by making the syntax like English's.
  • (Score: 1, Informative) by Anonymous Coward on Thursday April 16 2020, @07:42PM

    by Anonymous Coward on Thursday April 16 2020, @07:42PM (#983756)

    Its partly because of what the AC said. It can be awfully verbose and equally laconic, depending on the programmer. The real problems is that, as I mentioned above, the data structure comes first and the code last. Many coders, especially the young or otherwise undiciplined ones, like to throw crap on the wall without thinking of everything else first. Not that that way of thinking can't be correct in the right situation or language, but it goes strongly against the COBOL paradigm. On top of that, like I also said, even if you get the COBOL part down, that is only 1/3 of the problems you will have in the "real world." Without equal or better understanding the rest of the environment, you still might not get the output you expect from the system your code runs on. So you commonly end up with someone who invests the time in learning to think of structures first and the COBOL syntax/semantics and then they get frustrated because that still isn't enough for an actual COBOL job because COBOL "programmer jobs" are usually more than just "coders" or "programmers" or dealing with COBOL. So they, naturally, conclude that the problem isn't them, but inherent in the language, the people hiring them, or the system, depending on exactly where they start having problems.