Without having looked at the post or scrutinized the language, here's a couple of guesses:
1) looks like C: i.e. verbose, vacuous, loopy.
2) has crappy (i.e. industry-standard) array-handling.
3) fails to incorporate any of the decades of research about how people approach problems versus how programming languages do.

...especially with law firms specializing in personal injury.

...coming soon?

http://en.wikipedia.org/wiki/S...

Not according to the lack of imagination by the posters here I've seen so far.

How much time do you waste with boilerplate crap like this because of nearly clumsy array-handling ideas that date back to the Great Flood?
How bloated is code because of the vacuousness of most common languages that
require
several lines
to do
the simplest
things?

Basing one's choice of language to learn on its current popularity - though this may be economically prudent - retards progress in programming languages almost as much as new languages' emphasis on backwards compatibility and ease of learning for novices.

"Backward compatibility" gives us the backward languages that predominate today. Making things easy for beginners gives us languages mostly only suitable for newbies.

Contrast this novice-oriented, backward-looking orientation with the little-understood idea that a language can be a tool of thought, that it can provide us with useful conceptual building blocks for thinking about computation at a high level.

If you follow the "Risks Digest" - formerly the "Risks in Computing" newslist - now in its 27th year, you'll see that one of the most common themes is the repetition of known bad practices.

"Live and don't learn" could be the official motto of the IT industry.

How does this bullshit excuse apply to someone like me who's only child has graduated from college?

Clearly false:
http://www.npr.org/blogs/money...
and
http://www.debt.org/faqs/ameri...

...courtesy of xkcd: https://xkcd.com/1127/ .

The facts are otherwise. Based on estimates at a talk I was at recently - see the latter part of this (pdf) http://www.orie.cornell.edu/en... - traditional asset management comprises about 20% of trading volume; HFT accounts for over 30% and hedge funds for more than 25%. There may be some HFT done at hedge funds as well, but it's clear that the tail is wagging the dog.

So, you're talking about the Tea Party?

Good suggestion - much like a suggestion to apply a band-aid to a punctured artery.

You can follow these rules - and more - as rigorously as you please but still be undone by any number of simple things someone can do to a spreadsheet quite easily - like adding a row or column that looks like it's included in a calculation, but isn't.

I suffer the same incomprehension, except I've been using other interpreted environments throughout my career, but the idea is the same.

Compiled languages, though sometimes necessary, often substantially increase the difficulty of programming for no benefit whatsoever.

I understand this looks like flamebait, but I'm _only_ basing this on forty years of personal experience, so what the hell do I know? Since an example is worth a lot, here's one: I recently offered to help a colleague who's taking a C++ class and was reminded of all the unnecessary crap it takes to get even a very simple program to run at all. The problem was to build a Fahrenheit to Celsius (and vice-versa) temperature converter. It was friggin' painful - all the crap we had to put together to assemble even a simple, crappy program that is, at best, capable of doing
one
conversion
at
a
time
(and only a hard-coded little subset of them in an initial version).

The result was multiple source files, comprising a couple dozen lines of code, compiling to megabytes of peripheral files (in the debug version) - you know how this goes. In contrast, I write the Fahrenheit-to-Celsius conversion in a short, single line of my favorite interpreted environment (J), and am able to test it on multiple values at a time, instantly - taking seconds instead of hours. Moreover, J is smart enough that it has a built-in inverse construct to allow me to write the inverse function with another few seconds of effort.

I already hear the compiler-lovers muttering darkly about run-times and "large projects" - completely ignoring the first rule of optimization: find the bottleneck. Most code is - and should be - in small pieces that benefit from being tested quickly in small modules. The metric we should care about is "total time to completion" but this is harder to measure and more subjective than "run time", so we continue to focus on this latter measure to the detriment of productivity.

History?

Don't worry - it's a lot like a soul - if you don't have it, you'll never know.