**edited - removed number I couldn't duplicate**

Only as good as the dictionary used.  So it seems like the OSPD3 does not have all of the exceptions to the rule. 

Regarding maple builtin words I think when creating the ospd3 word list it also counts in the builtin words.  Not words just from OSPD3. 

Maple should update to OSPD5.  but regarding words like beruit and budweiser, it must be a word list that is internal to builtin as well. 

@nm rosettacode updates from Maple users are old and almost non-existant.  I made mention years ago to update at least one section there, but it really hasn't been updated past Maple 5.

@SYLee Try pointplot3d instead

I agree, crtl-jt is short enough.  Just have to get used to it, unless nm uses some third party program (free or otherwise) where you can program a set of hotkeys to perform the crtl-j crtl-t.

@Carl Love Yes indeed.  I'm pretty sure the answer was here in 2010.  It must have dissappeared.  Thanks for updating the question. 

This is the earliest release ever!  A welcome surprise. I was expecting Mid April, late March at the earliest.

@epostma Good explanation, thanks for that.

Interesting little trick at the end. 

**edit add** Oh I see, the $ just expands out the list as I had mentioned earlier.  I just quickly looked at it and thought it was some programming slight of hand with the StandardDeviation command.

@Carl Love Thanks for that bit of programming insight.

@Carl Love Yes of course the weights would change the deviation.  But I think that points to where the underlying issue lies as to why Maple won't calculate the Standard deviation when increasing the weighting, indeed it should change but doesn't.  Does that mean it's a bug?  Not sure but the issue comes up only when using weights.

One could instead create a proc that would circumvent the issue when StandardDeviation command is called, yes?

@Markiyan Hirnyk 

Interestingly

with(Statistics): L := [3, 2]: W := <700, 130000>: StandardDeviation(L, weights = W);

                   HFloat(0.7071067811865475)

So regardless of the weight values we get the same value 0.707106...

The different graphics drivers must react to maple 17 differently.

Markiyan Hirnyk said it works for him.  Be interesting to know if the line was solid black or grey or multi level greyscaled. 

In Classic M17.00 the line is a single grey color for me.
For the standard GUI the line color is scaled from black to white. 

It would be interesting to know if the scaled color for the line is standard across all users or if it's supposed to be one color .. all grey as in the M17 classic or scaled color M17 standard or all black as displayed in M12.  

Interestingly forcing a linestyle caused the line to appear then plot options color=black should also work but it is unclear if this was tried and failed or not.

@dholtzman Did you try Alejandro Jakubi's method?  What happened with that result?

You could also add color=black to see if anything happens there.

@dholtzman Works here as well however the line is not a solid color.

Try rotating the plot, maybe you're looking at it straight on hence seeing only a dot or not at all.  Add orientation=[45,45,45] in the display command to be sure. 

The line created for me is gray scaled (black at [0,0,0] to white at [1,1,1])

In M12 the line is completely black.  Not sure why the color is scaled in M17.00 though.

I believe one needs the NAG C library to follow the examples given in the help pages.

Alternatively there is a way without the NAG C library I am sure a few people are already working on. 

A silly mistake by all new Maple users.  Maple can absolutely answer.  I won't reiterate Kitonums answer below.  ...

re M12 limited?  not really.  As a matter of fact, even the newest software is limited.