That's an interesting question. By and large the finance industry is in the money bussiness, and a consumer of technology by necessity, not desire. The leadership of fiance companies rises the ranks from the financial side of the business, and looks at tech the same way the average person looks at their car engine or electrical power. Details like computers not being good at base ten mathematics don't reach the awareness of the decision makers. On rare occasions the finance industry has pushed the technology industry into developing specific products specifically in the area of online transaction processing and fault tolerance. But that's when a senior manager wants to create a certain feature and is told by the tech team that an off the shelf or homebrew solution won't work.
Something else to consider is that the senior management of financial firms tends to be old. When they we're lower level management their divisions weren't nearly as technology dependent as they are today, so there's also that disconnect as well.
I spent most of my career working for technology companies, but got sick of the boom and bust cycles where I would end up looking for a new job when my employer's product fell out of fashion. So I chose my current job for the stability knowing that the mindset was radically different from a technology company.
Moves into the staid, fuddy duddy world of finance to get a bit of stability (A very good idea by the sound of it) and then finds the finance guys are getting all hipster, adopting the churn of the FAD based engineering methodology, and forcing him to use JS and node.
Who would have seen that coming?
It will work out OK Martin, next year they will have you working with Go or Erlang or perhaps Haskell
...So how come the finance industry has not created for itself a language that deals with the number type they like to use? ...
They did. It is called COmmon Business Orientated Language short COBOL.
Since Grace Hopper developed it, it was made for financial transactions and reporting over the results of them transactions. Same source runs on Big Iron or a RasPi. There are a couple of commercial compilers out there and even a GNU version named GNU COBOL (former Open Cobol).
The language is still running strong. The last major revision was COBOL 92 a new revision is on the horizon, already ECMA approved and now in the process of being ANSI certified. One of the big players on the COBOL front besides IBM is Micro Focus. They recently acquired Novell Networks and together with them Suse Linux.
It is just so that you do not find much in the Internet about COBOL. Most financial Company's do not like there sources published. NDA's are quite common for any programmer there. COBOL programs are usually quite large applications with millions of lines of code. In opposite to say C or C# it is a very verbose language. You need to type a lot in COBOL. On the other hand it is almost self commenting - sometimes it is readable as plain English text, even for non programmer. Very helpful if you have - say - some accountant sitting next to you explaining to you the tricky difference between two transactions. Usually they are able to read the part of the source you show to them and understand it.
identification division.
program-id. freeze.
data division.
working-storage section.
01 hell pic 9.
88 hell-freezes-over value 1.
procedure division.
perform jumps thru flaming-hoops until hell-freezes-over.
stop run.
jumps.
flaming-hoops.
divide 1 by 0 giving hell.
Yeah, I thought of COBOL as soon as I hit send on that post.
The first computer used in business applications was the Leo made by J.Lyons and Co. in England in 1951. The Leo was subsequently available from the English Electric Company, then ICL which eventually merged with Fujitsu.
Anyway, I bet that used proper decimal arithmetic in hardware. As did later mainframes. I wonder where it all went wrong?
COBOL programmers seem to live in some parallel universe totally detached from the computing world we live in. I hear there is a lot of COBOL code somewhere so I presume there were/are a lot of COBOL programmers. But one never sees any around. One never sees any of that code. One never sees COBOLers chatting on tech forums. Spooky.
After three decades of hanging around the computer business in all kinds of places I met and talked to a COBOL programmer face to face for the fist time recently. She's a neighbour, nearly retired, works for the social security department. We did not talk about computers or programming.
You are the only forumista anywhere who openly talks about having worked in COBOL.
I strongly suspect that parallel universe of COBOL is alive and healthy.
Why so? The wealth one has is the wealth they keep track of. Accounting is a big deal and a very big business. The kind of computation that is done is geared toward specific objects of responsiblity for the data and the ability to audit the accuracy. IBM still thrives after all the decades of the personal computer revolution by providing services to large businesses and whole nations in bean counting for taxation and economic forecast.
Where might these programmers be lurking. In the big global CPA firms, in IBM, SUN Microsystems, Orale, and so on. And in military data centers that track procurment and such.
Every line of COBOL is likely associated with a lot of legal agreements.
One is either in that circle or not, and the specialized nature of it really has little relevance to public discussion.
I saw a similar thing during my time selling and using SGI computers.
There was SGI consumer, and we all saw that happen. There was SGI effects, and that is the Jurassic Park thing. People in the industry saw and ran lots of stuff nobody else did.
Then there was and still likely is SGI federal. The NSA, NASA, FBI, and others needed trusted, secure super computing and visualization.
All of that is private. There won't be any published discussion at all. Likely ever.
One would need clearance to participate.
COBOL exists in circles like effects and federal. Either the stuff is proprietary or requires one have credentials.
People who go into that field sort of stay and work in a bubble quite different from what most of us are familiar with.
Languages that were big in military and avionics, respectively, circles at the time.
Try finding much info or discussion of those on the net today.
I'm not allowed to talk about any of that even decades later but I know some of those systems are still in use.
I now assume COBOL is the same. There are old systems written in it that are still used and maintained.
But, 90% of the code in use today is actually a mess of Java, C++, Erlang, Javascript, and whatever other Smile the following generations have piled on top.
Every generation leaves it's mark as a "sedimentary" layer, frozen in time under the weight of all the new stuff that covers it over.
I used to code COBOL by day to pay the bills, while coding in Pascal, C and ASM on Apple ][ & Mac OS systems for fun & learning. So, it gave me a good start! One thing about a lot of COBOL code (other than batch processing code) is that in a similar way to web-based coding, there are so many other languages & protocols that you needed to learn. Your COBOL code just becomes your base, while you wrote a lot of SQL (or DL1 & DB2, back in the day), CICS (a customer interface protocol on IBM MV390 systems) or other interface code to display your data on a screen. Kind of like Java, JavaScript, Perl or Python, there's tons of other languages & protocols that you spend your time writing in order to get data to your users. It's hard to say anyone is "just" a COBOL coder or JavaScript coder, or C coder, etc.
Most COBOL code is written for internal corporate use, so it's not something that a lot of people talk about in general computing forums and outside of their work environment. I know it's done but could you see a bunch of folks on a forum discussing inventory management schemes or postulating on performance optimizations on their weekly-run batch accounts payable program, etc... you get the picture... At one time, I did that around the watercolor at work, but I spent more time on BBS's at night discussing how to get a non-Apple floppy drive to work with my Apple IIe :-)
Here's an example of the kind of stuff that just makes me view JavaScript as a sloppy mess:
if (null == undefined)
{
console.log("yes null == undefined, except when it doesn't.");
}
if (16 == [16])
{
console.log("scalar 16 is equal to an array of 16.");
}
if (-1 < Number.MIN_VALUE)
{
console.log("-1 < Number.MIN_VALUE, so why isn't -1 Number.MIN_VALUE?");
}
// I dare you to try this one:
console.log((![]+[])[+[]]+(![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]);
This aggressive type promotion is beyond dynamic typing into chaos typing.
...But, 90% of the code in use today is actually a mess of Java, C++, Erlang, Javascript, and whatever other Smile the following generations have piled on top...
You really underestimate the verbosity of COBOL. Them listings are long. Actual (in LOC) the current estimate is about 70% of all written code is still in COBOL. We are talking about millions of man hours. 50+ years of coding from a lot of people. JavaScript? Not so.
As usual @potatothead is right in his assessment. And @dgately is right in that there is always infrastructure around COBOL to take care of too. But overall it is the most portable language I know of.
And since GNU COBOL (former Open Cobol) transpiles COBOL to C or C++ using GCC, Clang or Visual Studio there is even the possibility to use Emscripten to transpile it to JavaScript.
Agreed. That code is a sloppy mess. It's typical of the issues with JS that all JS detractors love to point out. We all know these "features" of the language and it turns out that that in practice they are very rarely a problem. When I drop it into my Sublime editor it lights up like a Christmas tree as the jslint plugin points out all the problems with it. That code would never even be saved from my editor never mind get anywhere near being run around here.
So what have we got:
"if (null == undefined)", jslint points out that this is better written as "if (null === undefined)". No problem. (But why would you need to write that anyway?)
"if (16 == [16])", well that's just got a big red "Unexpected [" all over it.
"if (-1 < Number.MIN_VALUE)", that's just dumb. MIN_VALUE is defined as "the smallest positive numeric value representable in JavaScript." So of course -1 is less than that. Doh!
Did I say once that people don't bother to learn JS? This is a classic case. Seems people get "forced" into using JS, then assume it's simple and just like C or C++ or Java or whatever they like, then don't bother to actually learn the language they are using.
"console.log((![]+[])[+[]]+(...."
Ah, the magic of jsfuck http://www.jsfuck.com/ Good fun and all but all a fire with red in the editor here.
What you have there is indeed a sloppy mess. But:
1) Nobody writes code like that (except when wanting to poke fun at JS)
2) If you do write code like that the linter shouts at you immediately pointing out what an idiot you are.
3) If you are dumb enough to not use jslint or ignore it's advice then your code is going to immediately fail in your tests.
4) If you don't have any tests well, you are doomed. You need those tests no matter which language you are using so there is no extra burden there.
So basically these things are not a problem in practice.
Now, if you want to get really mean and bash on JS you should pick on some of it's more interesting structural flaws. For example the wonderful chaos that can ensue whenever "this" is involved.
In closing don't forget:
a) Always use jslint
b) Always put "use strict"; at the top of your code.
c) If you must use "classes" try to do it without using "prototype" and "this". Makes life much simpler, allows for private properties and avoids any "this" problems when passing methods around (No need for "bind"). At the cost of a little performance loss and RAM usage perhaps.
Now that I understand that COBOL programmers earn $10,000 USD more per year, I find it extremely interesting.
But would any major corporation really want their accounting system to easily operate in a browser? Bookkeeping technology is very conservative.
A nice little COBOL program? General Ledger, payroll journal, accounts payable journal, accounts receivable journal, inventory management, purchase orders, bank account, billing accounts receivables, depreciation history, and so on.
I just found out recently that GnuCobol supports besides VS and GCC also Clang without problem. So Emscripten should work also.
But in opposite to you I haven't touched Linux since 199x. Sad as it is. And the guys working on GnuCobol use mostly Linux. Since I have VS installed anyways on my Windows system I did not bother to install Mingw or GCC or whatever but just run GnuCobol with Microsofts C/C++ compiler.
GnuCobol does not really care. I am quite impressed by this now free and not just open compiler. A commercial one cost you about $4.000 to open end.
Just playing around with it, but really impressed.
Will look for or write some small program to test with emscripten, if you are willing to install GnuCobol and do the compiling on Linux. I am not able to figure out how to do that in windows at all.
As far as I understand you should be able to do something like atpget opencobol on Linux since some years to install. Now maybe GnuCobol.
Heater, I threw those in there because the response to aggressive type promotion is: you should be using jslint, using a better editor, not writing code like that, or your unit tests will catch it anyway. Because that's the response to everything wrong with the language! Those add-ons wouldn't be needed if the core language was better in the first place.
@msrobots:
Yes, you're right. On my Debian Wheezy (not bleeding edge like Sid) I have
$ apt-cache search cobol
exuberant-ctags - build tag file indexes of source code definitions
libcob1 - COBOL compiler - runtime library
libcob1-dev - COBOL compiler - development files
open-cobol - COBOL compiler
sloccount - programs for counting physical source lines of code (SLOC)
src2tex - A converter from source program files to TeX format files
universalindentgui - GUI frontend for several code beautifiers
Those 'non-cobol' lines are for tools that support Cobol for what they do.
$ apt-cache show open-cobol
[..]
Description-en: COBOL compiler
OpenCOBOL implements substantial part of the COBOL 85 and COBOL 2002
standards, as well as many extensions of the existent compilers. OpenCOBOL
translates COBOL into C and compiles the translated code using GCC.
Homepage: http://www.opencobol.org/
JS does indeed have some spectacularly bad features. Sadly many of those features were slated for fixing when it was time to first standardize JS but Microsoft barged in and demanded they get written into the standard rather than have to fix their JS engine (Which had very accurately copied all those miss-features from the Netscape engine)
I'm not sure that the aggressive type promotion is such a big deal though. As I keep saying, you will have tests for your code anyway and those errors will show up there. No worries.
No, the grievous miss-features of JS are to be found else where. And that is what JS lint is mostly about. As you are now working in node I'll leave it as an exercise for you to discover those miss-features and report back here:)
Anyway as to the standard responses you mentioned:
1) Over their in C++ land, a statically type language that you so much enjoy, the clang team is building all kind of "linters" with LLVM to catch all the miss-features of that language. Thread Sanitizer. Memory Sanitizer etc. Indeed Java itself has a need for linting, see Lint4j. So jslint is hardly a gripe.
2) No better or special editor is required.
3) "not writing code like that" - Isn't a good idea not to write crappy code in any language?
4) "your unit tests will catch it anyway" - Once again, you have to test your code anyway to catch the vast ocean of logical errors you can make over and above type errors. Those tests will also catch all your type errors. Ergo we don't need static type checking.
Unless you are in the "It compiles, ship it" school of engineering
If you could knock up a simple "interesting" program in COBOL that would be great. Perhaps the famous recursive Fibonacci sequence generator bench mark.
@tor
Great stuff.
Let's start the COBOL revolution, should be a great hit with all the retro loving hipsters!
Remember up thread when I said we were writing about a third more tests to cover the loosy goosey nature of JavaScript? You took issue with my claim, but here you're saying write more tests to make up for it. You can't have it both ways.
The problem with the "your unit tests will catch it mantra" is that I've never seen a project with 100% code coverage. We fail the build when we fall below 90%, and we struggle with error paths. In a large system that last 10% is still a large amount of code and I'd rather have a language with some type discipline.
What about errors in the test themselves? That happens too because you mock dependencies in the tests and can flub it. Now that 90% figure isn't quite as solid as you think.
I did not say write more tests. I said "you have to test your code anyway to catch the vast ocean of logical errors you can make over and above type errors. Those tests will also catch all your type errors."
Edit: Reading myself again I see that the "over and above" part might be a bit ambiguous.
It's a simple idea:
1) There is a huge number of ways your program can be wrong.
2) A few of those ways will be type mismatches and arity problems.
3) Most will be logic problems
4) If you test for 3) well enough you have automatically tested for 2)
5) You will be testing for 3) well enough because you take your code seriously.
6) Ergo no extra tests for type checking and arity are required. If you have those problems you will have failed at 5) already.
I've never seen a project with 100% code coverage
I have. Used to be a daily occurrence. People who build planes are fussy like that.
90% hey, not very good, but I sympathize Java programs are a ***** to test
Of course 100% coverage does not just mean stepping on every line in your source code just once.
if ((x > 10) && (x <= 20)) {bla bla}
already requires tests for x = 10, x = 11, x = 19, x = 20, probably x = 0, negative x, maximum possible values of x etc etc. So that's already 4 tests minimum, more like 8.
I might guess you don't actually do that and your test coverage is more like 20% than 90%.
Anyway, having done all the required functional testing like that its seems unlikely any type errors are getting through.
I have. Used to be a daily occurrence. People who build planes are fussy like that.
90% hey, not very good, but I sympathize Java programs are a ***** to test
You're being ridiculous. Most of the software industry can't support that level of testing. Maybe it should, but you won't be given the time or the budget. 90% is actually considered a high level of coverage. Here's a few links:
Of course 100% coverage does not just mean stepping on every line in your source code just once.
if ((x > 10) && (x <= 20)) {bla bla}
already requires tests for x = 10, x = 11, x = 19, x = 20, probably x = 0, negative x, maximum possible values of x etc etc. So that's already 4 tests minimum, more like 8.
I might guess you don't actually do that and your test coverage is more like 20% than 90%.
Now you're being insulting. Of course you have multiple tests that pass through the same block of code. The 90% figure is the high watermark of all coverage.
6) Ergo no extra tests for type checking and arity are required. If you have those problems you will have failed at 5) already.
That' what you don't seem to understand. Your actual code needs to check for arity and type, now you need to test to make sure that arity and type checking works, so you need more tests.
Loopy's $10,000 annual premium isn't enough incentive to make me want to code in COBOL again. Just to go on the record.
I'll just sit back with my popcorn now and watch the jousting continue.
@mindrobots,
I am with you there. But actually I had some fun doing it a short while ago again after 10+ years C#. COBOL is some cool language. Just think about CopyBooks, #include is lame against CopyBooks and replacing in a one liner.
And compared to the 80ies and 90ies where I fulltime did COBOL we have way bigger screens now. Folding editors. Large COBOL sources are quite easy to handle now. It still was some time travel programming COBOL again. Like riding bicycle you never forget.
As I suspected, there has never been an interesting program written in COBOL
Snobbish... aren't we? Accounting is what rich successful people learn before their ABCs. Computers are indeed 'business machines'.
Since the Propeller has video, keyboard, and bar code scanner capablities -- it might just make an excellent front-end device for COBOL as a cash register.
Only one problem, it's not the recursive fibo algorithm. We need that to make any benchmark comparisons with the usual recursive fibo in C or whatever languages. There is a recursive fibo example in C in the link I posted earlier.
I was wondering if COBOL even supports recursion. Sure enough it does. At least the Microfocus COBOL does. Here is an example I found on their web site for calculating factorials.
1 working-storage section.
2 01 n pic x(4) comp-x.
3 01 factorial pic x(4) comp-x.
4 01 m pic x(4) comp-x.
5
6 local-storage section.
7
8 procedure division.
9 accept n
10 move 1 to factorial
11 call "factorl" using n
12 display "factorial of " n " is " factorial
13 stop run.
14
15 entry "factorl" using m.
16 if m < 1
17 move 1 to factorial
18 else
19 if m > 1
20 multiply m by factorial
21 subtract 1 from m
22 call "factorl" using m
23 end-if
24 end-if
25
26 exit program.
I'll leave the recursive fibo in your skilful hands.
@Loopy,
Snobbish... aren't we?
So I have often been told. Never understood why though.
Accounting is what rich successful people learn before their ABCs
Which may well explain why I'm so damn poor.
The people with money I know were more into economics or law than bookkeeping. They have accountants for the drudge work.
Comments
Something else to consider is that the senior management of financial firms tends to be old. When they we're lower level management their divisions weren't nearly as technology dependent as they are today, so there's also that disconnect as well.
I spent most of my career working for technology companies, but got sick of the boom and bust cycles where I would end up looking for a new job when my employer's product fell out of fashion. So I chose my current job for the stability knowing that the mindset was radically different from a technology company.
I think finance won't move due to a lot of legacy code. Once it works, it works and errors actualize as money. Their money and our money.
So they add, glob on, but seldom replace.
Moves into the staid, fuddy duddy world of finance to get a bit of stability (A very good idea by the sound of it) and then finds the finance guys are getting all hipster, adopting the churn of the FAD based engineering methodology, and forcing him to use JS and node.
Who would have seen that coming?
It will work out OK Martin, next year they will have you working with Go or Erlang or perhaps Haskell
Just for completeness I added a link to the modern day Erlang promotional video by gar1t here:
http://forums.parallax.com/showthread.php/152201-The-Official-JavaScript-Religious-War-Thread.?p=1225811&viewfull=1#post1225811
"Node.js, your code will look like a pile of tangled slinkies."
"Just because I carry my Mac in a messager bag, and have great taste in nose rings, doesn't mean I use Ruby"
They did. It is called COmmon Business Orientated Language short COBOL.
Since Grace Hopper developed it, it was made for financial transactions and reporting over the results of them transactions. Same source runs on Big Iron or a RasPi. There are a couple of commercial compilers out there and even a GNU version named GNU COBOL (former Open Cobol).
The language is still running strong. The last major revision was COBOL 92 a new revision is on the horizon, already ECMA approved and now in the process of being ANSI certified. One of the big players on the COBOL front besides IBM is Micro Focus. They recently acquired Novell Networks and together with them Suse Linux.
It is just so that you do not find much in the Internet about COBOL. Most financial Company's do not like there sources published. NDA's are quite common for any programmer there. COBOL programs are usually quite large applications with millions of lines of code. In opposite to say C or C# it is a very verbose language. You need to type a lot in COBOL. On the other hand it is almost self commenting - sometimes it is readable as plain English text, even for non programmer. Very helpful if you have - say - some accountant sitting next to you explaining to you the tricky difference between two transactions. Usually they are able to read the part of the source you show to them and understand it.
Enjoy!
Mike
Yeah, I thought of COBOL as soon as I hit send on that post.
The first computer used in business applications was the Leo made by J.Lyons and Co. in England in 1951. The Leo was subsequently available from the English Electric Company, then ICL which eventually merged with Fujitsu.
Anyway, I bet that used proper decimal arithmetic in hardware. As did later mainframes. I wonder where it all went wrong?
COBOL programmers seem to live in some parallel universe totally detached from the computing world we live in. I hear there is a lot of COBOL code somewhere so I presume there were/are a lot of COBOL programmers. But one never sees any around. One never sees any of that code. One never sees COBOLers chatting on tech forums. Spooky.
After three decades of hanging around the computer business in all kinds of places I met and talked to a COBOL programmer face to face for the fist time recently. She's a neighbour, nearly retired, works for the social security department. We did not talk about computers or programming.
You are the only forumista anywhere who openly talks about having worked in COBOL.
Why so? The wealth one has is the wealth they keep track of. Accounting is a big deal and a very big business. The kind of computation that is done is geared toward specific objects of responsiblity for the data and the ability to audit the accuracy. IBM still thrives after all the decades of the personal computer revolution by providing services to large businesses and whole nations in bean counting for taxation and economic forecast.
Where might these programmers be lurking. In the big global CPA firms, in IBM, SUN Microsystems, Orale, and so on. And in military data centers that track procurment and such.
http://www.computerworld.com/article/2537042/it-careers/confessions-of-a-cobol-programmer.html
http://readwrite.com/2014/09/17/cobol-programming-language-hot-or-not
One is either in that circle or not, and the specialized nature of it really has little relevance to public discussion.
I saw a similar thing during my time selling and using SGI computers.
There was SGI consumer, and we all saw that happen. There was SGI effects, and that is the Jurassic Park thing. People in the industry saw and ran lots of stuff nobody else did.
Then there was and still likely is SGI federal. The NSA, NASA, FBI, and others needed trusted, secure super computing and visualization.
All of that is private. There won't be any published discussion at all. Likely ever.
One would need clearance to participate.
COBOL exists in circles like effects and federal. Either the stuff is proprietary or requires one have credentials.
People who go into that field sort of stay and work in a bubble quite different from what most of us are familiar with.
I used to do a lot of work in Coral 66 and Lucol.
Languages that were big in military and avionics, respectively, circles at the time.
Try finding much info or discussion of those on the net today.
I'm not allowed to talk about any of that even decades later but I know some of those systems are still in use.
I now assume COBOL is the same. There are old systems written in it that are still used and maintained.
But, 90% of the code in use today is actually a mess of Java, C++, Erlang, Javascript, and whatever other Smile the following generations have piled on top.
Every generation leaves it's mark as a "sedimentary" layer, frozen in time under the weight of all the new stuff that covers it over.
Most COBOL code is written for internal corporate use, so it's not something that a lot of people talk about in general computing forums and outside of their work environment. I know it's done but could you see a bunch of folks on a forum discussing inventory management schemes or postulating on performance optimizations on their weekly-run batch accounts payable program, etc... you get the picture... At one time, I did that around the watercolor at work, but I spent more time on BBS's at night discussing how to get a non-Apple floppy drive to work with my Apple IIe :-)
dgately
if (null == undefined) { console.log("yes null == undefined, except when it doesn't."); } if (16 == [16]) { console.log("scalar 16 is equal to an array of 16."); } if (-1 < Number.MIN_VALUE) { console.log("-1 < Number.MIN_VALUE, so why isn't -1 Number.MIN_VALUE?"); } // I dare you to try this one: console.log((![]+[])[+[]]+(![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]);This aggressive type promotion is beyond dynamic typing into chaos typing.
You really underestimate the verbosity of COBOL. Them listings are long. Actual (in LOC) the current estimate is about 70% of all written code is still in COBOL. We are talking about millions of man hours. 50+ years of coding from a lot of people. JavaScript? Not so.
As usual @potatothead is right in his assessment. And @dgately is right in that there is always infrastructure around COBOL to take care of too. But overall it is the most portable language I know of.
And since GNU COBOL (former Open Cobol) transpiles COBOL to C or C++ using GCC, Clang or Visual Studio there is even the possibility to use Emscripten to transpile it to JavaScript.
Bummer! Cobol in a Browser...
Mike
Agreed. That code is a sloppy mess. It's typical of the issues with JS that all JS detractors love to point out. We all know these "features" of the language and it turns out that that in practice they are very rarely a problem. When I drop it into my Sublime editor it lights up like a Christmas tree as the jslint plugin points out all the problems with it. That code would never even be saved from my editor never mind get anywhere near being run around here.
So what have we got:
"if (null == undefined)", jslint points out that this is better written as "if (null === undefined)". No problem. (But why would you need to write that anyway?)
"if (16 == [16])", well that's just got a big red "Unexpected [" all over it.
"if (-1 < Number.MIN_VALUE)", that's just dumb. MIN_VALUE is defined as "the smallest positive numeric value representable in JavaScript." So of course -1 is less than that. Doh!
Did I say once that people don't bother to learn JS? This is a classic case. Seems people get "forced" into using JS, then assume it's simple and just like C or C++ or Java or whatever they like, then don't bother to actually learn the language they are using.
"console.log((![]+[])[+[]]+(...."
Ah, the magic of jsfuck http://www.jsfuck.com/ Good fun and all but all a fire with red in the editor here.
What you have there is indeed a sloppy mess. But:
1) Nobody writes code like that (except when wanting to poke fun at JS)
2) If you do write code like that the linter shouts at you immediately pointing out what an idiot you are.
3) If you are dumb enough to not use jslint or ignore it's advice then your code is going to immediately fail in your tests.
4) If you don't have any tests well, you are doomed. You need those tests no matter which language you are using so there is no extra burden there.
So basically these things are not a problem in practice.
Now, if you want to get really mean and bash on JS you should pick on some of it's more interesting structural flaws. For example the wonderful chaos that can ensue whenever "this" is involved.
In closing don't forget:
a) Always use jslint
b) Always put "use strict"; at the top of your code.
c) If you must use "classes" try to do it without using "prototype" and "this". Makes life much simpler, allows for private properties and avoids any "this" problems when passing methods around (No need for "bind"). At the cost of a little performance loss and RAM usage perhaps.
Do you have an interesting little COBOL program that might be fun to compile to JS and run on a web page?
(Is there such a thing as an interesting COBOL program?
But would any major corporation really want their accounting system to easily operate in a browser? Bookkeeping technology is very conservative.
A nice little COBOL program? General Ledger, payroll journal, accounts payable journal, accounts receivable journal, inventory management, purchase orders, bank account, billing accounts receivables, depreciation history, and so on.
I suppose you could do a petty cash journal.
As I suspected, there has never been an interesting program written in COBOL
I just found out recently that GnuCobol supports besides VS and GCC also Clang without problem. So Emscripten should work also.
But in opposite to you I haven't touched Linux since 199x. Sad as it is. And the guys working on GnuCobol use mostly Linux. Since I have VS installed anyways on my Windows system I did not bother to install Mingw or GCC or whatever but just run GnuCobol with Microsofts C/C++ compiler.
GnuCobol does not really care. I am quite impressed by this now free and not just open compiler. A commercial one cost you about $4.000 to open end.
Just playing around with it, but really impressed.
Will look for or write some small program to test with emscripten, if you are willing to install GnuCobol and do the compiling on Linux. I am not able to figure out how to do that in windows at all.
As far as I understand you should be able to do something like atpget opencobol on Linux since some years to install. Now maybe GnuCobol.
link: http://sourceforge.net/projects/open-cobol/
Cobol transpiled to C, transpiled to JavaScript in a browser. Sort of funny.
Enjoy!
Mike
Flowmatic http://archive.computerhistory.org/resources/text/Remington_Rand/Univac.Flowmatic.1957.102646140.pdf
Enjoy!
Mike
Yes, you're right. On my Debian Wheezy (not bleeding edge like Sid) I have Those 'non-cobol' lines are for tools that support Cobol for what they do.
JS does indeed have some spectacularly bad features. Sadly many of those features were slated for fixing when it was time to first standardize JS but Microsoft barged in and demanded they get written into the standard rather than have to fix their JS engine (Which had very accurately copied all those miss-features from the Netscape engine)
I'm not sure that the aggressive type promotion is such a big deal though. As I keep saying, you will have tests for your code anyway and those errors will show up there. No worries.
No, the grievous miss-features of JS are to be found else where. And that is what JS lint is mostly about. As you are now working in node I'll leave it as an exercise for you to discover those miss-features and report back here:)
Anyway as to the standard responses you mentioned:
1) Over their in C++ land, a statically type language that you so much enjoy, the clang team is building all kind of "linters" with LLVM to catch all the miss-features of that language. Thread Sanitizer. Memory Sanitizer etc. Indeed Java itself has a need for linting, see Lint4j. So jslint is hardly a gripe.
2) No better or special editor is required.
3) "not writing code like that" - Isn't a good idea not to write crappy code in any language?
4) "your unit tests will catch it anyway" - Once again, you have to test your code anyway to catch the vast ocean of logical errors you can make over and above type errors. Those tests will also catch all your type errors. Ergo we don't need static type checking.
Unless you are in the "It compiles, ship it" school of engineering
If you could knock up a simple "interesting" program in COBOL that would be great. Perhaps the famous recursive Fibonacci sequence generator bench mark.
@tor
Great stuff.
Let's start the COBOL revolution, should be a great hit with all the retro loving hipsters!
I'll just sit back with my popcorn now and watch the jousting continue.
The problem with the "your unit tests will catch it mantra" is that I've never seen a project with 100% code coverage. We fail the build when we fall below 90%, and we struggle with error paths. In a large system that last 10% is still a large amount of code and I'd rather have a language with some type discipline.
What about errors in the test themselves? That happens too because you mock dependencies in the tests and can flub it. Now that 90% figure isn't quite as solid as you think.
I did not say write more tests. I said "you have to test your code anyway to catch the vast ocean of logical errors you can make over and above type errors. Those tests will also catch all your type errors."
Edit: Reading myself again I see that the "over and above" part might be a bit ambiguous.
It's a simple idea:
1) There is a huge number of ways your program can be wrong.
2) A few of those ways will be type mismatches and arity problems.
3) Most will be logic problems
4) If you test for 3) well enough you have automatically tested for 2)
5) You will be testing for 3) well enough because you take your code seriously.
6) Ergo no extra tests for type checking and arity are required. If you have those problems you will have failed at 5) already. I have. Used to be a daily occurrence. People who build planes are fussy like that.
90% hey, not very good, but I sympathize Java programs are a ***** to test
Of course 100% coverage does not just mean stepping on every line in your source code just once.
if ((x > 10) && (x <= 20)) {bla bla}
already requires tests for x = 10, x = 11, x = 19, x = 20, probably x = 0, negative x, maximum possible values of x etc etc. So that's already 4 tests minimum, more like 8.
I might guess you don't actually do that and your test coverage is more like 20% than 90%.
Anyway, having done all the required functional testing like that its seems unlikely any type errors are getting through.
You're being ridiculous. Most of the software industry can't support that level of testing. Maybe it should, but you won't be given the time or the budget. 90% is actually considered a high level of coverage. Here's a few links:
http://www.bullseye.com/minimum.html
http://martinfowler.com/bliki/TestCoverage.html
Now you're being insulting. Of course you have multiple tests that pass through the same block of code. The 90% figure is the high watermark of all coverage.
That' what you don't seem to understand. Your actual code needs to check for arity and type, now you need to test to make sure that arity and type checking works, so you need more tests.
Here you go:
small tutorial http://www.dreamincode.net/forums/topic/230271-cobol-the-fibonacci-sequence/
Enjoy!
Mike
@mindrobots,
I am with you there. But actually I had some fun doing it a short while ago again after 10+ years C#. COBOL is some cool language. Just think about CopyBooks, #include is lame against CopyBooks and replacing in a one liner.
And compared to the 80ies and 90ies where I fulltime did COBOL we have way bigger screens now. Folding editors. Large COBOL sources are quite easy to handle now. It still was some time travel programming COBOL again. Like riding bicycle you never forget.
Fulltime again? COBOL as main language? Not sure.
Mike
Snobbish... aren't we? Accounting is what rich successful people learn before their ABCs. Computers are indeed 'business machines'.
Since the Propeller has video, keyboard, and bar code scanner capablities -- it might just make an excellent front-end device for COBOL as a cash register.
Nice looking COBOL program.
Only one problem, it's not the recursive fibo algorithm. We need that to make any benchmark comparisons with the usual recursive fibo in C or whatever languages. There is a recursive fibo example in C in the link I posted earlier.
I was wondering if COBOL even supports recursion. Sure enough it does. At least the Microfocus COBOL does. Here is an example I found on their web site for calculating factorials. I'll leave the recursive fibo in your skilful hands.
@Loopy, So I have often been told. Never understood why though. Which may well explain why I'm so damn poor.
The people with money I know were more into economics or law than bookkeeping. They have accountants for the drudge work.