So you want to be a computer programmer when you grow up?

[Sanx]

or Finsbury Park mosque?

*snicker* Anyway, isn't it hard to find a plane you can fly with one eye and one hand?

As for coding: whilst C++ can be an elegant language, I've never failed to understand why they couldn't include a string variable type. You've got half a million different types for numbers, but nothing that can handle text without having to declare arrays and all the shit that goes along with that.

Give me VB any day.

[jrandom]

As for coding: whilst C++ can be an elegant language, I've never failed to understand why they couldn't include a string variable type.

(I assume 'never failed to understand...' was an unintentional double negative?)

C++ does. It's called std::string, and it's part of the library described by the language standard. It's as good as a basic type.

C doesn't, because the design philosophy of C was to abstract fundamental computer operations without hiding algorithmic complexity.

Almost any operation on a string requires processing time in the order of the length of the string rather than the constant time required for numeric operations, so forcing C programmers to be explicit about their handling of strings in memory was a conscious performance-driven decision.

Good old C, eh? All the power of assembly language combined with all the ease of use of assembly language.

Give me VB any day.

Try using Visual Basic to code a software driver for a CompactFlash socket that some bastard of an electronic engineer has hung off the data bus of a Mitubishi M16C processor.

Sometimes you really do need a language that simply and elegantly gives access to the basic operations that a CPU can perform, and nothing more.

[Tank]

pfffft you talk tough - but everyone knows real men program using LOGO.

http://en.wikipedia.org/wiki/Logo_(p...ming_language)

[Ixion]

*snicker* Anyway, isn't it hard to find a plane you can fly with one eye and one hand?

As for coding: whilst C++ can be an elegant language, I've never failed to understand why they couldn't include a string variable type. You've got half a million different types for numbers, but nothing that can handle text without having to declare arrays and all the shit that goes along with that.

Give me VB any day.

C++ does . C doesn't because there is no such datatype as a "string". It's just an array of char types (and char is really just a small int). Those languages such as VB Java and C++ that pretend to have a string type really just define a very large array of chars.

That's why C (and Cobol! ) are good. What you see is exactly what you get.

[Ixion]

pfffft you talk tough - but everyone knows real men program using LOGO.

http://en.wikipedia.org/wiki/Logo_(programming_language)

Arrghh. LISP (Lotsa Irritating Silly Parentheses). Fetch garlic crosses and cold iron. And yes, I have programmed in LISP. I still wake up sometimes screaming at the memory.

[Tank]

Arrghh. LISP (Lotsa Irritating Silly Parentheses). Fetch garlic crosses and cold iron. And yes, I have programmed in LISP. I still wake up sometimes screaming at the memory.

I used to think KB was where all the cool kids hung out - Now I find its full of middle aged nerds like me. How terribly disappointing .


(p/t of course)

[forkoil]

C++ does . C doesn't because there is no such datatype as a "string". It's just an array of char types (and char is really just a small int). Those languages such as VB Java and C++ that pretend to have a string type really just define a very large array of chars.

That's why C (and Cobol! ) are good. What you see is exactly what you get.

I doubt that std::string does that, more likely it just adds "new" bits as required. oh and lets not overlook the irritating little terminating zero shall we with char type. And std::string is v v fast even compared with C char pointer handling.
"Old" cobol was just a file processing language, optimised for reading and writing files. Hardly low level, and not anything like C, maybe they changed it? Just remember those packed decimal fields!! aaarrgghh.

Note to myself, avoid turning this into an "I've been everywhere man" thread.

[jrandom]

I doubt that std::string does that, more likely it just adds "new" bits as required. oh and lets not overlook the irritating little terminating zero shall we with char type. And std::string is v v fast even compared with C char pointer handling.

std::string has to store its data as a contiguous null-terminated array to support its c_str() member function.

What string operations do you think are faster with std::string? I can't think of any.

Edit: Oh, right, sorry, you weren't saying it was faster, just that it wasn't slower.

[Ixion]

I doubt that std::string does that, more likely it just adds "new" bits as required. oh and lets not overlook the irritating little terminating zero shall we with char type. And std::string is v v fast even compared with C char pointer handling.
"Old" cobol was just a file processing language, optimised for reading and writing files. Hardly low level, and not anything like C, maybe they changed it? Just remember those packed decimal fields!! aaarrgghh.

Note to myself, avoid turning this into an "I've been everywhere man" thread.

Cobol is still evolving. It is far more than a file processing language. Cobol still contributes more lines of code to business applications than any other language.

Modern Cobol also runs under the .NET Framework, BTW.

[jrandom]

Cobol still contributes more lines of code to business applications than any other language.

I call bullshit.

What information are you basing that assertion on?

[forkoil]

Cobol is still evolving. It is far more than a file processing language. Cobol still contributes more lines of code to business applications than any other language.

Modern Cobol also runs under the .NET Framework, BTW.

lines of source or generated

[Ixion]

I call bullshit.

What information are you basing that assertion on?

Gartner Group research. But don't ask me to find it now. Note also, the careful restriction to "business application". There are unthinkable amounts of Cobol code still running in the big US bank and insurance worlds.

Just think back to how much demand there was for Cobol programmers leading up to Y2K. Headhunters wouldn't have been paying megabucks an hour to lure oild programmers out of retirement unless there was a shit load of code to be inspected.

EDIT : 75% of the world's business data processed by Cobol according to Gartner - ref here

[jrandom]

Gartner Group research. But don't ask me to find it now. Note also, the careful restriction to "business application".

I did, but, personally, I'd consider any non-OS software used to facilitate operations in a corporate environment to be a 'business application'.

That includes Word, Excel, Oracle, SAP, SolidWorks, SPICE, PhotoShop, and every horrible little line of Java or Visual Basic that's ever been written to glue a front end to a CRM database.

There are unthinkable amounts of Cobol code still running in the big US bank and insurance worlds.

Define 'unthinkable'.

I would be quite surprised if any bank is running COBOL software with a total source linecount that exceeds that of Microsoft Office (which is probably in the order of 50 million lines or thereabouts).

75% of the world's business data processed by Cobol...

Oh, I can believe that, but that has nothing to do with your earlier statement relating to the size of the software involved.

[Ixion]

I did, but, personally, I'd consider any non-OS software used to facilitate operations in a corporate environment to be a 'business application'.

That includes Word, Excel, Oracle, SAP, SolidWorks, SPICE, PhotoShop, and every horrible little line of Java or Visual Basic that's ever been written to glue a front end to a CRM database.

I would disagree with that definition. That would make anything at all a "business application". Photoshop is most certainly not a business application, for instance. Nor is email. A business application is one which handles or processes business transactions, and is designed for that purpose. Yes , you could write an accounting package in Excel (or even Word, I've seen it done). That doesn't make ewither of them a business application.

A good rule of thumb, if it doesn't use a 'proper' database (not MS Access or such like crap) it *probably* isn't a business application. databases rule, DBAs are the true gods!

Define 'unthinkable'.

I would be quite surprised if any bank is running COBOL software with a total source linecount that exceeds that of Microsoft Office (which is probably in the order of 50 million lines or thereabouts).

180 to 200 billion lines of Cobol code according to the same source. WAY more than Word, even if you count word as a business application .

I can say from experience that any banking application in Cobol will indeed run to millions of lines of code. And there is only one Word code base. Whereas Cobol is mostly bespoke or heavily customised code, so every bank has a different codebase (f'instance - not just banks of course)

[jrandom]

180 to 200 billion lines of Cobol code according to the same source. WAY more than Word, even if you count word as a business application .

I can say from experience that any banking application in Cobol will indeed run to millions of lines of code. And there is only one Word code base. Whereas Cobol is mostly bespoke or heavily customised code, so every bank has a different codebase (f'instance - not just banks of course)

My bullshit detector wavers and falters; you paint a truly horrible and disturbingly believable picture.

I shall now shut up, lest it be indisputably proven true, and I begin to wake in the night to demonic visions of:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO-WORLD.
PROCEDURE DIVISION.
MAIN.
DISPLAY 'Hello, world.'.
STOP RUN.

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense".
- Edsger Dijkstra