> Windows 10: Can Microsoft Get It Right This Time?

Outlook not so good

How about "STEEM" (with an extra E for English)?

Or to be more culture neutral - "STELM" (with L for Language)?

You're being pedantic. (And I'm about to follow suit.) Paradigm *isn't* a fancy buzzword - it is a word with a clear definition that has been in use since the 15th century. It's fame as a buzzword comes from imprecise overuse during the last decade or so. The word itself is fine.

Here's another definition, this time from Merriam-Webster: "a theory or a group of ideas about how something should be done, made, or thought about". That seems to fit the discussion pretty well when referring to different ways to approach the decidely non-trivial task of defining at a fundamental and conceptual level how a programming language works.

You mention "style". I don't think it's really equivalent to paradigm, though it could apply to variations of a paradigm. Style involves the details in how you implement a paradigm - it's not a paradigm itself. Merriam-Webster supports this assertion: "a particular form or design of something" and "a particular way in which something is done, created, or performed" (emphasis mine).

But I grow tired of this nitpicky exercise. You may have the last word if you wish (preferably with concrete examples of why you believe you are correct rather than vague generalizations and unfounded assertions regarding awkwardness and clarity). I've said my piece and I'm done with this. Good day.

Actually I looked it up and based on the definition of the word ("a distinct concept or thought pattern"), its use in the given context seemed appropriate, so I kept it in. "Style" seems to imply something more arbitrary, while "model" is a way of describing reality using simplified concepts (or a plastic thing I used to build as a boy, or something I found appealing as a teenager). Paradigm seems right.

Thanks. I was going to mention that there was a dedicated person (Steve Klabnik is his name, BTW - http://www.steveklabnik.com/) who was doing a great job and has just been momentarily overwhelmed. I decided it sounded too much like an excuse that "drinkypoo" wouldn't find convincing, given that "drinkypoo" (*snicker*) clearly has high standards of professionalism. So I decided to mention the API docs instead, which have been most helpful when sorting out code breakage due a change in the nightly version of the compiler. Actually, much of the time, the extremely clear error messages emitted by the compiler have been enough to make the correct changes to fix errors, which is almost better than good documentation. The latter is more useful in understanding why the code was incorrect, even if the compiler message is often enough to correct the problem.

I wouldn't bet on that horse staying in the lead forever (well, horses plural). Those of us with long enough memories remember when this wasn't true. Here's a thought experiment: How did they get dominant in the first place, since at one time they were new and different? Things change and improve over time, and that's a good thing. Besides, Python and JS developers aren't necessarily the target audience, though there may be some overlap between them and potential Rust developers. For some reason "The Blind Men and the Elephant" comes to mind, and the term "tunnel vision" as well. :-)

That's a rather uninformed statement to make, given that you're referring to a rather short time period when the rate of change caused the docs to lag behind. That will be corrected soon, I'm sure. Besides, the API docs, which are generated from the code, *are* correct and have been kept up to date all along despite the rapid rate of change. So documentation exists and is correct. The GP was likely referring to the higher level docs, such as guides and tutorials, which aren't produced by "the devs".

But hey, at least you got your *zing* in, though you forgot the rimshot at the end.

I agree with you in principle, except for the "it competes ... really well" part. That's an unfounded assertion since it hasn't actually competed in the real world yet. Because, you know, not being finished yet. The true challenges are still in the future. It seems to have successfully passed the early "get people interested" stage, which is nice, but there are a bunch more hurdles to be surmounted before I would call it even a marginal success. Let's wait and see.

That remains to be seen. I've heard the same thing said about email, the internet, Linux, Java, the iPhone, tablets and many other things over the years. The truth is that in a viable and vibrant marketplace of ideas, many things fail but some survive, and predicting which is hard. Give it a chance to fail or succeed on its own rather than condemning it in the womb, and be glad you live in a time where people have the enthusiasm and energy to try new things. Your attitude leads to stagnation.

Or maybe an informed one. Go and Rust -- objects without class

Besides, Rust isn't an "OO" language. It's a multi-paradigm language that supports pure-functional, concurrent-actor, imperative-procedural, and object-oriented styles. After 40+ years, a growing opinion seems to be that pure OOP isn't without its problems, and other approaches may fit development goals better. I'm not sure multi-paradigm languages are the answer (there seems to be a huge potential to be confusing, IMHO), but OOP isn't the evolutionary pinnacle of language design that the last few decades of hype would have us believe. I'm willing to give this approach a chance (and I'm always up for learning something new).

Critcisim of the OOP paradigm

(Aside: Not quite sure why, but the use of the term "paradigm" multiple times makes me feel slightly icky for some reason. Probably due to it's misuse in business jargon.)

Don't forget the fourth letter of the latin alphabet (also used as the first letter in three elements on the periodic table though can't rate it's own, the Roman numeral 500, a poor grade in education and tons of other things. And apparently something the girls be wantin'.)

Thanks for noticing. That was deliberate. My attempt to hold back the rising tide of unclear and uninformative titles and summaries on /. Too bad it wasn't successful.

Or perhaps we're both the victims of *whoosh* and the folks above were just having some fun. :-)