Programming Trends to Follow?

[aggle-rithm]

COBOL programmers are dying off and retiring and there are very few university programs that teach it. There's still a market but it's recovering slowly. Meanwhile I entertain myself by learning JAVA.

In the short-lived Dilbert TV series, Asok mentioned that he knew COBOL. "They still teach that in school?" he was asked.

"Yes, in history class."

 

[CynicalSkeptic]

If those are the upfront requirements...

You actually get upfront requirements? Can I come work for your company?

 

[MortFurd]

OOP greatly reduces cyclomatic complexity. I never use switch statements anymore, and rarely use if statements.

What are you doing that you can get away without making any decisions? Or perhaps I should ask - How are you hiding them?

 

[Paul C. Anagnostopoulos]

Yes, because the execution paths you're not interested in are hidden inside another class, rather than cluttering up the page.

I can do that with a function; don't need OOP.

I thought you were saying that the OO language semantics reduces the number of switch and if statements that you have to code anywhere. Otherwise how can you not be using switch statements and rarely if statements?

Ah, perhaps they are in other classes that you did not write.

~~ Paul

 

[aggle-rithm]

What are you doing that you can get away without making any decisions? Or perhaps I should ask - How are you hiding them?

Check this link:

http://www.antiifcampaign.com/

ETA: On second thought, don't. That's a crap site.

Basically, you replace if's and switch statements with design patterns like chain of responsibility, strategy, or specification.

 

[CynicalSkeptic]

What are you doing that you can get away without making any decisions? Or perhaps I should ask - How are you hiding them?

Method Overloading and Polymorphism?

 

[not daSkeptic]

What are you doing that you can get away without making any decisions? Or perhaps I should ask - How are you hiding them?

This actually isn't that uncommon when dealing with CRUD applications, which are defined by their lack of any significant business logic. When all you're doing is shuttling information back and forth between the user and a database, there isn't a whole lot to be conditional about.

 

[aggle-rithm]

I thought you were saying that the OO language semantics reduces the number of switch and if statements that you have to code anywhere. Otherwise how can you not be using switch statements and rarely if statements?

It doesn't do that inherently, you have to use design patterns.

Such as:

void HandleObject(obj)
{
var lst = GetListOfHandlers();

var handler = lst.Find(h.CanHandleObject(obj));

handler.Handle(obj);
}

"lst" is a list of ICanHandleObject interfaces.

 

[Wudang]

COBOL programmers are dying off and retiring and there are very few university programs that teach it. There's still a market but it's recovering slowly. Meanwhile I entertain myself by learning JAVA.

Well yes, my very large bank uses a lot of COBOL which has to be maintained and reworked to meet fiduciary, legislative and other requirements but we (sadly) do all training in house and is largely geared to produce "coding clerks".
And IBM are still developing COBOL though I believe they didn't act on our feedback that the Linkage Section is bloody ridiculous on MVS.

 

[Paul C. Anagnostopoulos]

It doesn't do that inherently, you have to use design patterns.

Such as:

void HandleObject(obj)
{
var lst = GetListOfHandlers();

var handler = lst.Find(h.CanHandleObject(obj));

handler.Handle(obj);
}

"lst" is a list of ICanHandleObject interfaces.

Right, so the decisions are buried in the Find method, which you did not write. I agree that this can make your code clearer, assuming that the reader understands the behavior of Find. If not, then the reader has to dig through Find.

~~ Paul

 

[aggle-rithm]

Right, so the decisions are buried in the Find method, which you did not write. I agree that this can make your code clearer, assuming that the reader understands the behavior of Find. If not, then the reader has to dig through Find.

~~ Paul

In C#, Find() is an extension method on the standard list class. It takes as a parameter a lambda function that tells Find() what to look for in each item in the list.

The CanHandleObject() function basically replaces the "case" clause in a switch statement. It usually looks something like this:

public bool CanHandleObject(object obj)
{
return this.Status == StatusEnum.New;
}

This is a little bit of functional programming within a procedural language...it's a function that takes a function as a parameter which, in turn, calls another function.

 

[jnelso99]

Right, so the decisions are buried in the Find method, which you did not write.

Why should somebody reinvent the wheel every time a "Find" is needed if an API provides it already?

Hmm...a coworker implemented some function, but I don't want to have to dig through his code since I didn't write it. I better write my own version of that function! Without using any standard API calls, since I didn't write those either! Assembly all the way!

I agree that this can make your code clearer, assuming that the reader understands the behavior of Find. If not, then the reader has to dig through Find.

~~ Paul

OH MY GOD! You mean the reader may have to <gasp> LOOK AT THE DOCUMENTATION? The HORROR!

 

[aggle-rithm]

Why should somebody reinvent the wheel every time a "Find" is needed if an API provides it already?

Hmm...a coworker implemented some function, but I don't want to have to dig through his code since I didn't write it. I better write my own version of that function! Without using any standard API calls, since I didn't write those either! Assembly all the way!



OH MY GOD! You mean the reader may have to <gasp> LOOK AT THE DOCUMENTATION? The HORROR!

I read an article recently by someone who dislikes C# for, among other reasons, turning algorithms into methods. "Find()" being an example.

It's a big time-saver to use Microsoft's implementation of Find() (or "Where()" or "OrderBy()"), but it takes away your choice of which specific algorithm to use.

Personally...I don't think it's a problem. If micro-optimizing performance is that important, I'll code in C++ instead.

 

[whitefork]

Well yes, my very large bank uses a lot of COBOL which has to be maintained and reworked to meet fiduciary, legislative and other requirements but we (sadly) do all training in house and is largely geared to produce "coding clerks".
And IBM are still developing COBOL though I believe they didn't act on our feedback that the Linkage Section is bloody ridiculous on MVS.

I believe they still support SERVICE RELOAD but it's treated as a comment. ALTER remains as well as far as I know but I haven't seen it used in maybe 30 years.

 

[Paul C. Anagnostopoulos]

Why should somebody reinvent the wheel every time a "Find" is needed if an API provides it already?

I don't think anyone should reinvent the wheel. We were talking about whether the code was easier to follow or not.

Hmm...a coworker implemented some function, but I don't want to have to dig through his code since I didn't write it. I better write my own version of that function! Without using any standard API calls, since I didn't write those either! Assembly all the way!

Well, that's pretty much my opinion, but I'm not proposing it for anyone else. Your coworker probably wrote a broken version of the function. The standard API calls are whacky. Go assembler!

OH MY GOD! You mean the reader may have to <gasp> LOOK AT THE DOCUMENTATION? The HORROR!

The question was about cyclomatic complexity, not reuse. I'm all for reuse, in spite of my previous statement.

~~ Paul

 

[W.D.Clinger]

OOP greatly reduces cyclomatic complexity. I never use switch statements anymore, and rarely use if statements.

And yet the complexity of those conditions must be realized somewhere. Is it more perspicuous to have them buried in the underlying structure of the language?

The goal of reducing cyclic complexity is to make the source code easier to understand...perhaps at the expense of performance.

Right, but if the complexity is simply buried in the semantics of the language, rather than programmed explicitly, have we gained anything?

Yes, because the execution paths you're not interested in are hidden inside another class, rather than cluttering up the page.

I can do that with a function; don't need OOP.

I thought you were saying that the OO language semantics reduces the number of switch and if statements that you have to code anywhere. Otherwise how can you not be using switch statements and rarely if statements?

Ah, perhaps they are in other classes that you did not write.

Basically, you replace if's and switch statements with design patterns like chain of responsibility, strategy, or specification.

Method Overloading and Polymorphism?

Yes.

Dynamic method dispatch writes the switch and/or if statements for you when you're trying to implement:

• inclusion polymorphism
• ad hoc polymorphism
• extensible-sum-of-extensible-product types

If those things account for a large fraction of your code, then dynamic method dispatch can be worthwhile.

(Most current implementations of OO languages implement dynamic method dispatch badly, but that's another topic.)

 

[a_unique_person]

Business rules can be very complex. The problem that OO has not solved is persistence.

 

[hodgy]

As I understand it, "The Cloud" is putting your data on other people's computers, so that you don't have to worry about it.
For some reason, this worries me.

When done properly, putting your data and / or applications on the Cloud can be much less worrisome and have significant advantages versus an on-premise approach. There can be major economies and capabilities afforded by scale.

Consider that when using something like Salesforce a one-man-band business benefits from the same redundancy, scalability, disaster recovery, security etc... as that provided to large corporations.

 

[TjW]

And wonderfully, when it breaks, you're not responsible. No worries!

 

[not daSkeptic]

The problem that OO has not solved is persistence.

How so?