Why aren't physical units in programming languages yet?

Can you name a programming language or tool that lets you write expressions like:

mylength = 3 feet + 2 meter + 1 inch

The web mentions ATLAS, but that language is long dead. I can't think of any recent language that offers this obvious feature in the simple syntax above. The Wolfram Language has made provisions for it, but it is ugly with lots of additional punctuation:

In[8]:=h = First[y[t] /. DSolve[{ y''[t] == -\[Gamma] y'[t] - g, 
       y[0] == Quantity[0, "Meters"], 
       y'[0] == Quantity[10, "Meters"/"Seconds"]}, y, 
      t]] /. {\[Gamma] -> Quantity[1/10, 1/"Seconds"], 
    g -> Quantity[9.8, "Meters"/"Seconds"^2]};

Adding units to programming languages was proposed in 1978 by Van Snyder of JPL. The Ada language committee considered it, but didn't get around to it. FORTRAN has had it on their "to-do" list for decades. What is it about this very simple feature, that confounds all the language developers? On the surface it looks very simple. We are asking for the computer to know some basic information about physical units, and automatically convert things for us. It sure would come in handy when you are doing gnarly calculations, and expect units of energy at the end, but due to some subtle mistake you have the wrong units which means your results are completely wrong. Money is a unit, and currency conversions are also in the "would be very useful to have" category.

In 1999 JPL crashed their Mars Climate Observer spacecraft due to a units mistake. That was a 327 million dollar project ruined by a simple meters--feet unit mistake. If only they had listened to Mr. Snyder and implemented units into their programming languages. Every day of the week, thousands of Excel users are making small and large units mistakes. Occasionally a massive error is exposed by the press. For an interesting read, see the WSJ blog about a $100 million mistake:

http://blogs.wsj.com/moneybeat/2014/10/16/spreadsheet-mistake-costs-tibco-shareholders-100-million/

In 2007, the Fortran committee issued a report N1696, where Page v in the introduction stated the following:

        "The most common errors in scientific and engineering software,
        that a language and its processor might be expected to
        ameliorate, are mismatched, missing or excess actual arguments
        in procedure references, followed by out-of-bounds array
        references, and then incorrect use of physical units of measure.
        Explicit interfaces largely solve the first problem and help to
        avoid the second problem, but do nothing directly for the
        third."

Why has it been so tough to add units features to a programming language? Joe Armstrong, in his 2014 Strange Loop Conference talk, put it very succinctly: you only get one chance to do a language right. Once you have lots of users cranking out code, you will have a riot by your users if you break their hundreds of thousands of lines of code by making a major syntax change.

Make no mistake about it, adding units to a programming language is a major decision that has implications in the most crucial area. There is a lot of talk about functional programming nowadays, but at the end of the day, all of our computers, from mainframes to cellphones, are Von Neumann type computers, and do their work by loading values into a CPU, calculating a number, and then storing that number. This crucial action is performed in all languages by the arithmetic expression statement, and when you add units to expressions, you are changing the most fundamental part of any computer language. Just now Cambridge University has tweaked their FORTRAN pre-processor to add physical type annotations. A brilliant job of retrofitting a valuable feature, but also testimony to the glacial speed at which committees work. 

Unit-based arithmetic is one of the pillars of my Beads language. It promises to eliminate an entire category of common programming mistakes. In the end, programming is a creative human activity, like writing a novel, except that instead of tickling the minds of human readers, the programmer gives work to a machine whose sole purpose is to make human lives more convenient and enjoyable. The only thing stopping computers from massively improving the quality of life, is that it is so difficult to build reliable software. I have heard 100 startup pitches at meetings in Silicon Valley, where the sole purpose of their first $400k was to fund some piece of programming. They can't even begin to run their company until their software and websites are built; and they take too long and cost too much.