Microsoft architect writes about project to add new extensions to C#

A team at Microsoft has been working for the past four years on a project that aims to bring some new “systems programming” extensions to the C# language. This week, the leader of that effort, Joe Duffy, quietly revealed the first details of this effort on his blog site.

Duffy writes that the ultimate goal is to "eventually open source this thing" but that there is still some work to do before that happens. That will include having the code work with the upcoming "Roslyn" compiler which is expected to be completed in the near future.

So why create a new programming extension to C# in the first place? Duffy explains his thoughts via a graph which he says shows how some coding languages tend to have better performance while others have more safety and productivity features. He states:

Our top-level goal was to explore whether you really have to choose between these quadrants. In other words, is there a sweet spot somewhere in the top-right? After multiple years’ of work, including applying this to an enormous codebase, I believe the answer is “Yes!”

The highly technical post then goes over the primary features in this new C# extension project, including async programming at scale, a new modern error profile and more. Duffy says that he is "eager" to get some feedback on their project and concludes the post by saying, "Ultimately, I eagerly await the day when we can share real code."

Source: Joe Duffy's Blog via Microsoft News | Image via Joe Duffy

Report a problem with article
Previous Story

Samsung offers a future with lots of touchscreeen displays in concept video

Next Story

Microsoft offers free 30-day subscription to New York Times on Windows devices

71 Comments

Commenting is disabled on this article.

It worries me that they're building this as a superset of C#. C# is a language with already a long history, too many features and some glaring redundancies and design mistakes (for instance having both anonymous methods and lambdas, inconsistent type inference, etc.) A new language should strive to be as small and cohesive as possible, and C# is far from that. C# also gets many defaults wrong, most importantly that everything is by default mutable and nullable. C# also has only half-assed support for functional programming, with no tail recursion, pattern matching or partial function application.

I could go on but while the goal of building a better systems programming language than C++ is laudable and, I would say, necessary, basing it on C# seems like a terrible choice. We'll likely end up with a huge, incoherent language where half of it must be avoided, much like C++. I'd much rather see a derivative of Haskell or F#.

Edited by Andre S., Dec 31 2013, 7:02am :

I'd be more annoyed by problems that led to ambiguities in the language and liberties in the wrong places, and I'm much more annoyed at C++ than C# when it comes to that. Both issues tend to lead to code harder to debug. I don't really have a problem with e.g. both lambda function and anonymous methods since I don't think these collide. They're more like two different ways of expressing the same thing to me, not different, incompatible ways to solve the same problems.

But sure, you have a point in that one can seen as redundant when the other exists, and maybe C# could have a "Strict" compilation mode where e.g. anonymous methods are no longer supported, since lambdas can be seen as succeeding those. This could also make it easier to develop third party C# compilers if you limited them to "Strict C# 4.0" or whatever.

I like the way this story was presented on other sites.

They started by stating Duffy was originally on the midori team which was then absorbed into the unified OS group.

The language he is talking about isn't C# at all, but M#.

The goal is to compile existing C# into M# according to the blog comments.
Duffy is extremely active on his comment thread so if anyone really understands this and wants to engage, that is the place to do it.

There are all sorts of things wrong with the simplistic little chart that is claimed to be a justification for this, the biggest single error being the idea that you cannot put safety and productivity as one axis.

arayb said,
......

I thought the same until I read the blog post.
And then I read the other two he referenced. I now realize I know nothing about programming. I shall sit sheltered in my C# world and let these experts extend my reach and efficiencies.

That "X" mark is where the D programming language is already at: http://dlang.org/

You can seamlessly reference C code from it, it has garbage collection, syntax sugar, and ridiculously much more than that. It also has a standards library that should be pretty mature by now.

It doesn't help much if you want to write using the .NET libraries though. Just saying that the problem of a high level object-oriented language with none of the baggage of C++ and yet compiling for C performance has already been solved. It is usable, and designed to be usable as, a systems programming language. Facebook is using it in production code since October this year.

I love c#. I think its brilliant, simply the easiest yet most elegant code syntax out there. (I use to be java guy but c# has the same syntax with more feature such as lambda, generics and all other features such as dynamic variables and anonymous types and funcs)

There's a bunch of negativity here, and I just don't get it: I think this is great -- in a very real sense, who cares if it doesn't work out? The fact that this sort of thing is being done at all is excellent: the last thing anyone should want for the primary language of their choice (and mine just happens to be C#) should be that it becomes stagnant and static. Why are so many programmers so pessimistic about everything?

My worry is the idea that we need 'something else' to fill the upper-right quadrant. If the premise is that C# is not an efficient enough language, then improve the framework. Look at what developers actually do (read and write to the database, call web services, etc.), and provide methods in existing objects to do it better (or optimize the existing methods). This lets the framework do its job of abstracting the low-level interaction away so developers can solve business problems.

So, you're saying that Javascript is more productive than C#?

And that Java is faster than C#?

And I suppose VB goes in the lower left box???

Regardless, I think your placement of languages in relationship to safety, productivity (how do safety and productivity get combined anyways???) and C++ are arbitrary at best.

Dart boards are round, not square.

The chart suggests it is safe *and* productive. It's safe because it's comparatively quite limited. As far as productivity goes, I'm not sure I agree with the chart, though. Yes, it's fairly quick to cobble something together, but those same language limitations that make it relatively safe securitywise also to me, anyway, decrease its productivity when compared to a more fully-featured language like C# or Java.

Exactly.
Productivity of JavaScript is limited by it being safe - especially when you try to create a web application. Additionally it is just nasty syntax wise, from C# world, JavaScript can be described as a language with only dynamic anonymous types and lack of genuine interfaces and classes and easy to use built in libraries (jQuery is not part of JS by default for example) as well as different behavior based on the compiler/browser.

How many colors can you paint a pig? Seriously!

I truly resent C# riding the coattails of "C" language for a couple of reasons.

"C" was created to write efficient code that rivaled Assembly language in speed and efficiency.

"C Dull" is a bastardization of this concept by basically stepping all over structured programming with "bling terminology" and poor programming techniques.

What good is optimization to a "language" (and I use that term loosely) that relies primarily on objects so heavily that even the simplest statements absorb incredible CPU effort.
Is C sharp a "programming language" or a scripting language??? seriously there is a difference.

For that matter C++ is really again not much better in that C++ is a framework in top of "C", that actually requires incredible amounts of code in some cases to create "hello world"!!

Can't anyone come up with an original name for a "new language" .....rather than latch on and corrupt a venerable language like "C"?

Too many people write very obsequious code that is both difficult to read and questionable to maintain.

Sorry if this sounds harsh, but frankly besides writing web forms and such, C# to me is useless as a language. Much more akin to VISUAL BASIC than a true programming language.

Windows Scripting Host does at least as much as C Dull, and it is free and easily maintained.

I tried to give C Dull a chance, really I did. I can code in it and everything! HAH trouble is it is so platform specific that frankly it does me little good.

It is yet another "hey look I am a programmer" language that the Microsoft Fanboys latch onto with vigor and you can't pry it from their cold hands.

Problem I can see now is that unless somebody ports C Dull to Android pretty quick, C Dull is soon to become C Dodo (as in extinct non flying bird)!

Again, sorry if this ruffles feathers or sounds harsh. Just the way I see it.

Jim

C# is primarily a business language and android has zero traction in the backend enterprise and even less traction in the desktop space. C++ was log ago dismissed due to higher development costs and lower productivity except in scenarios where the expense is worth the extra performance. This is why Java and C# took off in the enterprise. Just look for jobs on C#/Java development and you'll see if anything they are becoming more numerous, completely contradicting your theory.

however there is a real opportunity here for c# to bring the performance of c++ without the cost.

Again you're using cute little RSS client development for android to predict the overall versatility of a language which is ridiculous. JavaScript would do there, or any other language. Since most mobile apps avoid c++ like they avoid the plague, unless it's for gaming or other perf critical tasks it really doesn't matter what some mobile app uses as the backends systems don't care, and shouldn't care if they are properly designed.

you have to separate yourself from this fantasy world where the way phone apps are written is the same way business back-ends are written. C# has so much flexibility and the .NET framework is so popular that it will never go away.

and for the record C# is also free and WSH is like having your teeth drilled. Yes any Turing complete language can do what another Turing complete language can. It doesn't mean productivity wise both are the same. We all know at the end of the day, nobody is going to make a meaningful app using WSH.

And remember C# is platform agnostic, it even runs on Linux and using tech like xamarin's you can even target android and iOS natively. So your notion that it is platform specific out of the box is absolutely misguided. You can choose to make it so, but you can do the same with Java, and you don't see people stop coding in java.

ultimately you seem to lack an understanding of C# which means your opinion is as you call it, the way you see it, which is in fact, pretty biased, uniformed and ignorant.

Edited by neonspark, Dec 30 2013, 1:48pm :

Extra points for trolling originality, jwnoord--I'm impressed.

I thought I was reading the rantings of a mad C purist (there's so few of them left), but then the WSH reference really threw me in for a loop. It's like a coding rant rick-roll.

It's hard to beat C#/.Net for developer productivity. After coding in C and C++ for years, C# is nothing but a *pleasure* to use. jwnoord, come on over and joins us in reality some time. Pull that stick out of your ass and give C# a chance.

Seriously now, how many projects require 'efficient code' these days. They require RELIABLE code that can be developed QUICKLY for a variety of types of applications. That's what C# does. As far as naming a language Cxxx, it is appropriate because it is built on the foundation of C.

>> Too many people write very obsequious code that is both difficult to read and questionable to maintain.

Good C# code is probably among the easiest languages to read and maintain.


>> but frankly besides writing web forms and such

Writing web forms and such is called 'Programming'. It is what developers do. The fact that one can write a WinForm application, and, if done properly, can build a new front end and deploy the exact same application to the web is what makes C# a tremendously valuable language

If you want to code in traditional C, go grab yourself a card punch, a VT 100 terminal, and have at it. The rest of us will be in the 21st century solving real business problems.

There is no reason c# can't compile to native code without the byzantine cpp syntax and offer the same perf. It amazes me we're still putting up with c++ nonsense in 2014.

There are cases when unmanaged code will necessarily be more efficient than managed code (although those cases are relatively few and far between). It would be nice if .NET did a better job integrating unmanaged code where it is needed.

As long as C# is not able to even offer the basic reasons for C++'s performance advantages (read: templates) it will never replace it for systems/high performance programming…
And as the current way C# is programmed is inherently bound to a GC, good luck with writing performance-critical code…

A lot of talking and no code samples, typical .net, a lot of talking and a little of improvements.

C# was a great language, JavaScript today can do much better.

john.smith_2084 said,
A lot of talking and no code samples, typical .net, a lot of talking and a little of improvements.

C# was a great language, JavaScript today can do much better.

hahaha. Doesn't even have classes and must resort to various unintuitive syntactical nonsense to even remotely approach oop

john.smith_2084 said,
A lot of talking and no code samples, typical .net, a lot of talking and a little of improvements.

C# was a great language, JavaScript today can do much better.


And that everyone, was the troll post of the year. Had to end it on a good one I guess!

sathenzar said,

And that everyone, was the troll post of the year. Had to end it on a good one I guess!

Damn! I thought for sure I'd get troll post of the year and then boom! John Smith

john.smith_2084 said,
A lot of talking and no code samples, typical .net, a lot of talking and a little of improvements.

C# was a great language, JavaScript today can do much better.

Wow. Enjoy that golden hammer.

john.smith_2084 said,
A lot of talking and no code samples, typical .net, a lot of talking and a little of improvements.

C# was a great language, JavaScript today can do much better.


The current state of JavaScript or ECMAScript 6 or 7?
If you only at least meant the latter, but you don't.

neonspark said,
hahaha. Doesn't even have classes and must resort to various unintuitive syntactical nonsense to even remotely approach oop

Err, JavaScript does have classes.

Brandon Live said,

Err, JavaScript does have classes.


No it doesn't. JavaScript/EcmaScript is a prototype based language, by definition it therefor has no classes. Even if you emulate classes based on prototypes and conventions that doesn't change that fact!

Brandon Live said,

Err, JavaScript does have classes.


You're probably thinking of functions and the prototype-based object-orientation, where you can even get constructors. Don't confuse this with class-based OO which has encapsulation, inheritance, interfaces, abstract classes, and other important concepts.

BUT! JavaScript *will* get basic class support. Microsoft sort of offers an early "preview" of this with TypeScript, where they made this into an own language so that they could stabilize and get some proposed features out early along with other useful ones. (personally I prefer the Dart language as it's so beautifully "whole" and coherent even to run server-based software, yet compilable to all browsers, but hey... The TypeScript advantage is that it's easier to get into and start using.)

The forthcoming version of "JavaScript" which corresponds to ECMAScript 6 codename "Harmony" will introduce significant new syntax and features for proper classes, "for ... of" support (iterators), collections, and more. I'd say the most exciting revision to JavaScript in a while!

Browsers are today on the road to ES 6 support: http://kangax.github.io/es5-compat-table/es6/

Edited by Northgrove, Dec 31 2013, 2:37pm :

Northgrove said,

You're probably thinking of functions and the prototype-based object-orientation, where you can even get constructors. Don't confuse this with class-based OO which has encapsulation, inheritance, interfaces, abstract classes, and other important concepts.

You're imposing a very specific definition of "classes" then. Classes in C# are quite different from classes in C++, which are different still from those in Java.

JavaScript doesn't (today) have a built-in concept it calls a "class" unless you use libraries which add them. And yes, they're limited in certain capacities such as lacking private members to enforce encapsulation. But JavaScript developers can and (many) do make us of encapsulation via classes, generally be prefixing private members with underscores. Obviously this isn't enforced by the language, but it's pretty easy to get right.

With libraries like WinJS and others you get things like inheritance (i.e. WinJS.Class.derive). There are no language-defined interfaces, but for those to be useful you need opt-in strict typing anyway.

Yes, ECMAScript 6 will bring more strict typing capabilities, which in turn enables more C++-like class functionality. But I also think it's inaccurate to say that JavaScript lacks classes entirely. It is very easy to do OOP with JavaScript.

Brandon Live said,

You're imposing a very specific definition of "classes" then.

Nope, he is just using the official definition of "object-oriented class-based programming languages".
The way you interpret classes, every language that allows you to define types has classes (e.g. C as you can always use the same hack that GNOME uses to emulate classes)…

MFH said,

Nope, he is just using the official definition of "object-oriented class-based programming languages".
The way you interpret classes, every language that allows you to define types has classes (e.g. C as you can always use the same hack that GNOME uses to emulate classes)…

Whose "official" definition is that?

So you're saying WinJS.Class.define does not define a class?

Classes are more than just custom types. There are several common characteristics of classes, but languages vary in which specific subset they support. JavaScript already supports what I consider to be the "core" set: Instantiation via constructor pattern, static and instance members, basic inheritance. Yes, more extensive support is coming, but for most practical purposes, JavaScript has classes.

Brandon Live said,

Whose "official" definition is that?

You mean apart from the guys who defined it by coming up with the original idea for classes [aka. Ole-Johan Dahl and Kristen Nygaard (inventors of Simula) or Alan Kay, Dan Ingalls and Adele Goldberg (inventors of Smalltalk - if you're one of those daring who prefer Smalltalk instead of Simula)] - the base model which has later been applied to every other class-based programming language in existence?

Brandon Live said,

but for most practical purposes, JavaScript has classes.

No, it does not! JS is prototype-based, whilst modern framework hide that via conventions, that doesn't change the fact the language itself is NOT class-based.

Edited by MFH, Jan 2 2014, 7:29pm :

MFH said,

You mean apart from the guys who defined it by coming up with the original idea for classes [aka. Ole-Johan Dahl and Kristen Nygaard (inventors of Simula) or Alan Kay, Dan Ingalls and Adele Goldberg (inventors of Smalltalk - if you're one of those daring who prefer Smalltalk instead of Simula)] - the base model which has later been applied to every other class-based programming language in existence?

So... link?

The Wikipedia definition certainly applies. http://en.wikipedia.org/wiki/Class_programming

"A class is an extensible template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions, methods)."

No, it does not! JS is prototype-based, whilst modern framework hide that via conventions, that doesn't change the fact the language itself is NOT class-based.

I never said it was "class-based." I said for practical purposes it offers the functionality most people describe as "classes." Because it does.

Brandon Live said,

A class is an extensible template for creating objects

You just found out yourself the reason of why JS is not class-based: in JS not classes are used as templates for objects. Instead prototype-based languages (like JS) uses existing objects - called prototypes - as templates…

class-based OO: new class() => object
prototype-based OO: object.clone() => object

BTW: It's funny that you can't accept that fact as even the Brendan Eich calls JS prototype-based…

You're making a pedantic distinction, and even that is still wrong.

First, your example is wrong / misleading. The syntax for instantiating an object is:

C++: auto aFoo = new Foo(); // Pointer to a new Foo
JS: var aFoo = new Foo(); // Reference to a new Foo

Now, I wasn't making an argument about the technical implementation. I was talking about the usage and functionality provided to a developer using the language. Yes, JavaScript is prototype based. But that's utterly irrelevant.

At any rate, it seems you've become confused and argued yourself into a corner. C++ classes are not implemented as templates for any definition of the word. Period. In C++, a class definition is basically just a specification of the layout of an object's memory (i.e. a set of field offsets, just like a C struct). There is no template (unless you use the separate C++ feature by that name). You just have the specification of the memory layout via offsets and a bunch of functions, all of which are actually static under the hood, with an implicit "this" parameter passed to instance methods and the constructor. Every time you reference any C++ object, that same class specification is used to map member references to offsets from the instance's base address. When you instantiate one, all you get is a chunk of uninitialized memory (or zeroed out memory, depending on your allocator). It's up to your constructor function to put anything useful there.

A template implies there's a master instance which is set up in an initial state and is then copied to make usable instances. Why, that sounds a lot like your misinterpretation of a prototype!

In reality, the implementation in modern JavaScript engines is more like C++ classes than you'd probably think. When you new up a Foo, it isn't making a copy of Foo.prototype. It's making a brand new empty object, setting its prototype property to the class definition (aka the function/object used to instantiate it), and then passing that to the constructor. If you reference a member, such as an instance method, which doesn't exist on the object - it walks up the prototype hierarchy to try and find it. This is analogous to walking the class hierarchy in C++.

But as I said, the implementation is irrelevant, as is the specific naming and syntax. The point is, you can do the same thing in both.

// Define a class
class Car {
int numWheels;
String make;
Car(make)
{
this.wheels = 4;
this.make = make;
}
};

// Instantiate an object of that class
auto pinto = new Car("Ford");

Or...

// Define a class
var Car = function (make) {
this.make = make;
this.numWheels = 4;
};

// Instantiate an object of that class
var pinto = new Car("Ford");

Prototypes in JS are mainly used to achieve the C++ model of having a single implementation of an instance method shared by all instance of the class. In fact the only real difference is that JavaScript is a dynamic language, so the class definition is mutable (via the prototype) at runtime. How you think that this invalidates a JavaScript class's "classness" is evading me.

Edited by Brandon Live, Jan 4 2014, 11:09pm :

Brandon Live said,
C++ classes are not implemented as templates for any definition of the word.

Yes, they are! Every instance of a class is created based on the "class-template" (not to be confused with actual C++ class templates…)!

Brandon Live said,

You just have the specification of the memory layout via offsets and a bunch of functions, all of which are actually static under the hood, with an implicit "this" parameter passed to instance methods and the constructor,

That's exactly what the definition is talking about when I talks about "templates". And don't try to teach me anything about C++, you will fail miserably at that task…

Brandon Live said,

A template implies there's a master instance which is set up in an initial state and is then copied to make usable instances. Why, that sounds a lot like your misinterpretation of a prototype!

LOL, that's the exact definition of a prototype. And no a "template" does not imply that there is a master instance. A template defines they way an object is created and layed out… A prototype on the other hand is an instance that specifies how a the initial state of a clone is to be set.
Or in other words:
class == blue print for objects that is used during construction
prototype == initial instance that's cloned to create new objects

Brandon Live said,

How you think that this invalidates a JavaScript class's "classness" is evading me.

That's because you apparently simply fail to get the difference between a class-based and a prototype-based programming language. Just because JS allows you to hide the prototype-based-ness to a certain extend does not change the fact that it's prototype based!
I could write you an abstraction layer on top of C++ that would simulate message passing ala Smalltalk, that still wouldn't change the fact that C++ is not message-passing-based, but function-call-based…

MFH said,

Yes, they are! Every instance of a class is created based on the "class-template" (not to be confused with actual C++ class templates…)!

This is simply false. There is no such concept in C++ (either at the language level, the compiler implementation, or at runtime). When you call the new operator on a class type ("Foo"), this is all that happens:
1) A block of memory sized to the type is allocated from the free store (i.e. large enough to hold all of its fields and any necessary padding, and optionally a vtable pointer).
2) The type's constructor, if applicable, is called (and not just for proper classes, i.e. structs have them too). It is implicitly passed a pointer to the newly allocated memory ("this") which is of type Foo*.
3) The constructor initializes the memory.
4) A Foo* pointer to the initialized memory is returned.

There is no step involving a template of any kind. All you need to instantiate a C++ class is the size and constructor. The class definition maps the layout of the memory from the base address of the object, so the compiler can turn foo.bar into foo+0x20. But once compiled, the class definition isn't used.


That's exactly what the definition is talking about when I talks about "templates". And don't try to teach me anything about C++, you will fail miserably at that task…

Given the way this conversation is going, and my experience, it seems clear you are mistaken.


LOL, that's the exact definition of a prototype. And no a "template" does not imply that there is a master instance. A template defines they way an object is created and layed out… A prototype on the other hand is an instance that specifies how a the initial state of a clone is to be set.
Or in other words:
class == blue print for objects that is used during construction
prototype == initial instance that's cloned to create new objects

Please look up the definition of the word "template." I'll wait.

Oh right, a template is a master or mold used to produce copies. Hence why C++ has a feature called templates which lets you author a master class definition which it can turn into many specialized copies.

As for prototypes, that is simply not how JavaScript uses that word. Prototypes are never copied to create new instances of a class/type/whatever in JavaScript.


That's because you apparently simply fail to get the difference between a class-based and a prototype-based programming language. Just because JS allows you to hide the prototype-based-ness to a certain extend does not change the fact that it's prototype based!
I could write you an abstraction layer on top of C++ that would simulate message passing ala Smalltalk, that still wouldn't change the fact that C++ is not message-passing-based, but function-call-based…

I fail to understand why you insist on this false dichotomy. Prototypes and classes are not mutually exclusive concepts. In fact, they're largely orthogonal. The example I gave you above does not "hide" any prototype stuff. It doesn't use any. Nowhere in any steps of that example is a prototype used. Calling "new" does not copy any objects. Zero. Zilch. When you create an object of a class type, its __proto__ property is set with a reference to the prototype property of the function that created it. That's it.

Calling "new" just calls the constructor function with a new object. It's only when you get into inheritance that prototypes come into play, and even then there's no copying involved. It's just a chain of references to the constructor of each object in the chain. You can think of the prototype hierarchy as JavaScript's version of a base class hierarchy and a vtable rolled into one.

I'm not sure which aspect you're stuck on. Is it that in JavaScript classes are themselves objects (/functions)? This is more a result of it being a dynamic language than anything else. Python works much the same way. Would you argue it lacks classes too?

Maybe you're just arguing this straw man that "JavaScript is not class-based." A nebulous term, but more importantly, a claim I've never disputed. What I said is that JavaScript has classes. If you're a C++ developer, you'll figure them out just as easily (or not) as you would classes in Python. Yes, inheritance is prototype-based. You still haven't made a meaningful point.

I guess the bigger question is why you care to keep stubbornly argue the issue. Especially when you seem, no offense, ignorant of how either language in question works.

Edited by Brandon Live, Jan 5 2014, 4:57am :

Actually, I think you are the one being stubborn. MFH is correct, you are incorrect. JavaScript simulates classes, but they are not classes.

This is not about semantics, there is a clear definition for what a class is, and JavaScript doesn't meet it.

By definition, a class is a description of an object, never an instance of an object.
In JavaScript, the things you call classes are instances of function objects, therefore it doesn't meet the definition.

The blueprint analogy from FMH is spot on.

Brandon Live said,

There is no step involving a template of any kind.

For crying out loud, THE CLASS IS THE TEMPLATE ON HOW TO INSTANCIATE NEW OBJECTS OF IT'S TYPE!

Brandon Live said,

But once compiled, the class definition isn't used.

Yes it is! It's no longer present as class definition as it's been transformed into the actual calls to constructors - why are you not able to get it?

Brandon Live said,

Given the way this conversation is going, and my experience, it seems clear you are mistaken.

More like: You're simply wrong and don't even notice it. Which is a shame but a common problem in IT…

Brandon Live said,

As for prototypes, that is simply not how JavaScript uses that word.

Doesn't matter how they use the word, it's simply the way it works in JS…

Brandon Live said,

I fail to understand why you insist on this false dichotomy.

'false'? Now you're stretching it. I'm not the one here that calls standard conventions 'false' or 'wrong'…

Brandon Live said,

Prototypes and classes are not mutually exclusive concepts.

Yes they are on a fundamental level, as they describe two contrary concepts of how new objects are created.

Brandon Live said,

When you create an object of a class type, its __proto__ property is set with a reference to the prototype property of the function that created it.

Which means it's class is a runtime entity, aka a prototype => QED.
As there are now classes in JS you just showed yourself that it's purely based on conventions…


Brandon Live said,

A nebulous term,

This one honestly takes the cake…

Brandon Live said,

What I said is that JavaScript has classes.

No wait, this one takes it as JS clearly doesn't…

Brandon Live said,

Especially when you seem, no offense, ignorant of how either language in question works.

I'm not the one here who is ignorant on how this stuff is implemented in a specific language…
Saying that JS has classes is like saying that C is object-oriented. And yes C can be used as OO language - based on conventions (see Vala => GObject) - but that doesn't change the fact that C is not an OO language…

kde said,
The blueprint analogy from FMH is spot on.

It's MFH, but thanks for your support

kde said,
Actually, I think you are the one being stubborn. MFH is correct, you are incorrect. JavaScript simulates classes, but they are not classes.

I'm not being stubborn, I'm trying to educate. JavaScript has a functional equivalent of classes, it just doesn't use that name. Python decided to use that name even though its classes share as much with JavaScript as they do with C++. I'm saying the name doesn't matter. The core functionality is there.


This is not about semantics, there is a clear definition for what a class is, and JavaScript doesn't meet it.

JavaScript absolutely meets the definition as it is on Wikipedia. There is no clear definition because the term "class" is used in a variety of ways by a variety of languages. The general programming concept of a class is quite simple, which I quoted above. What JavaScript has meets that definition perfectly.


By definition, a class is a description of an object, never an instance of an object.
In JavaScript, the things you call classes are instances of function objects, therefore it doesn't meet the definition.

JavaScript classes are not, nor do they include, instances of themselves.

Python classes are objects of type "type." So Python classes aren't classes either?

No, the reason C++ classes aren't objects is primarily that it's a compiled, statically typed language. So it had no need for them to be (also that it grew from a non-OO language is surely a factor).

Python and JavaScript are both dynamic languages with objects as first-class concepts. Classes are objects in these languages primarily so they can be inspected and mutated at runtime.

The blueprint analogy from FMH is spot on.

A C++ class definition does include a blueprint. So do Python class definitions. Basically they're a blueprint plus a constructor. In C++ the blueprint defines the layout and "interface" (programming concept, not C++ term) of the class. In Python it's just the latter, which is a necessity for a strongly-typed language. The main difference between the two is that Python's definition is mutable, because it's a dynamic language.

JavaScript is a loosely-typed dynamic language, so its version of classes (today, in ECMA 5) do not require a description of the interface in their definition. Instead, JavaScript objects largely rely on duck typing.

The other rest of the class definition (that part that's not a blueprint) is made up of the constructor, methods, and inheritance information. While the implementation details of these differ, they're all part of C++ classes, Python classes, and JavaScript classes-if-not-in-name.

MFH said,

For crying out loud, THE CLASS IS THE TEMPLATE ON HOW TO INSTANCIATE NEW OBJECTS OF IT'S TYPE!

That's simply not how C++ works. If you want to define "template" to mean "the information needed to create instances of a type" then this applies equally to JavaScript, making your argument moot.


Yes it is! It's no longer present as class definition as it's been transformed into the actual calls to constructors - why are you not able to get it?

This is getting silly. Now you're repeating what I said but asking me why I don't get it. Although you're being far less precise. Calls to instantiate objects are compiled as calls to the constructor (after memory is allocated). But different parts of the class definition are used elsewhere. It all evaporates at compile time though, which was my point.


More like: You're simply wrong and don't even notice it. Which is a shame but a common problem in IT…

I'm not in "IT." Until last Spring I was one of the top Senior SDEs and junior architects on Windows (a C/C++ based operating system you may have heard of). I don't make arguments from authority but you brought it up.

Doesn't matter how they use the word, it's simply the way it works in JS…

But it's not. You said new objects are clones of other objects. This is completely and utterly false. You have repeatedly demonstrated that you have no knowledge of how JavaScript works*. This is why the case you're pleading makes no sense.

* = see https://developer.mozilla.org/...Reference%2FOperators%2Fnew


'false'? Now you're stretching it. I'm not the one here that calls standard conventions 'false' or 'wrong'…

It is a false dichotomy. Period. There are languages which contain (by name!) prototypes and classes. ECMAScript 6, the next version of JavaScript, will be this way.

Yes they are on a fundamental level, as they describe two contrary concepts of how new objects are created.

No no no. They. Do. Not. Prototypes have nothing. Zero. Zilch to do with creating objects. They have to do with how objects inherit from their creators.

ECMAScript 6 classes still have prototypes. They're just like today's JavaScript "classes" with the addition of strong typing (i.e. a required, though mutable in this case, interface definition).


Which means it's class is a runtime entity, aka a prototype => QED.
As there are now classes in JS you just showed yourself that it's purely based on conventions…

Nothing you said here makes any sense. Classes are runtime entities in many languages (C#, Java, Python, etc). Those languages don't use prototypes. Nothing about having a runtime representation makes something be or not be a class.

Anyway, I'm done here. I've well-proven my point, that JavaScript has a functional equivalent of classes.

Brandon Live said,

Until last Spring I was one of the top Senior SDEs and junior architects on Windows (a C/C++ based operating system you may have heard of).

Ok, that just scares the **** out of me! If people that - supposedly - worked at MS are unable to understand the difference between class-based and prototype-based OO, then there is something horribly wrong at their selection process…

Brandon Live said,

Anyway, I'm done here. I've well-proven my point, that JavaScript has a functional equivalent of classes.

For the last time: has functional equivalent of classes != has classes. I'm done here too - I can only hope that some day you will read a book on programming languages and start to understand why it does make a difference…

MFH said,

Ok, that just scares the **** out of me! If people that - supposedly - worked at MS are unable to understand the difference between class-based and prototype-based OO, then there is something horribly wrong at their selection process…

I fully understand class-based and prototype-based OOP. You, on the other hand, do not understand that JavaScript largely supports both (and in ECMA 6 has more extensive support for the former). Further, there are many variations of both concepts, and practical applications rarely fit squarely into any particular definition.


For the last time: has functional equivalent of classes != has classes. I'm done here too - I can only hope that some day you will read a book on programming languages and start to understand why it does make a difference…

What I have said repeatedly is that JavaScript offers the functional equivalent of classes, just not by name (unless you use a library like WinJS). There are absolutely differences, and I have never argued otherwise. As I said, Python classes are just as different from C++ classes as they are from JavaScript's equivalent. They all still serve the same function with the same core capabilities (and basic usage patterns).

Arguing with you is a waste of time as you've demonstrated no interest in learning or acknowledging your mistakes. You refuse to answer any of my questions (such as whether you think Python has classes) or attempt to explain any of the contradictory statements you've made. You've yet to acknowledge that everything you've said about object creation (i.e. that new Foo() is equivalent to some mythical Object.clone() function).

I can ignore the ad hominem arguments and pervasive arrogance. But I'm not going to argue with someone who is just going to repeat that they're right without addressing any of my points.

Torolol said,
what the? Javascript is high on safety? explain !

There're no pointers, there is a garbage collector, there's even no multithreading. If you want to crash a browser from the JavaScript - it's a dead end, you can't (well, as soon as there's no bug in browser, but that would not be the JavaScript fault).

Vladislav Nagorny said,

There're no pointers, there is a garbage collector, there's even no multithreading. If you want to crash a browser from the JavaScript - it's a dead end, you can't (well, as soon as there's no bug in browser, but that would not be the JavaScript fault).

Exactly. I took "safety" in this context as meaning type safety, which does not imply secure code...

Vladislav Nagorny said,

There're no pointers, there is a garbage collector, there's even no multithreading. If you want to crash a browser from the JavaScript - it's a dead end, you can't (well, as soon as there's no bug in browser, but that would not be the JavaScript fault).

Actually there is multi-threading... It's limited in that you currently can't share memory between threads (only pass messages), but that does make it high on "safety."

trojan_market said,
javascript really shouldn't even be here but technically its safe because it cannot do much with your system because its browser context code

Why would it not be there? JavaScript doesn't just run in a browser. You can write apps (especially on platforms with support for native JS apps like Windows), or servers (i.e. with node.js). It has its advantages and disadvantages like any language, but I don't see any reason to leave it off the list.

> "Ultimately, I eagerly await the day when we can share real code."

As soon as I read that, I was reminded of how MS's better debugging/code analysis tools are only bundled with VS Ultimate.

If they want to share something and want feedback in return, it needs to be part of the set of tools most of us can afford.

Mind you, language features apply equally to all editions of VS, but I think it's fair to say my point stands...?

_dandy_ said,
> "Ultimately, I eagerly await the day when we can share real code."

As soon as I read that, I was reminded of how MS's better debugging/code analysis tools are only bundled with VS Ultimate.

If they want to share something and want feedback in return, it needs to be part of the set of tools most of us can afford.

Mind you, language features apply equally to all editions of VS, but I think it's fair to say my point stands...?

what about VS ultimate do you need? for most debugging purposes, their standard debugger is so good it makes xcode and android studio blush in shame.

neonspark said,
what about VS ultimate do you need? for most debugging purposes, their standard debugger is so good it makes xcode and android studio blush in shame.

For one, I remember watching some Channel 9 video a good while back of some of the more advanced profiling tools that are included with Ultimate only, that looked pretty sweet.

It's not necessarily that I have a specific need--it's one of those things you get by just fine without, but then would start using a lot if you had access to it, to the point where it changes the way you program.

neonspark said,

what about VS ultimate do you need? for most debugging purposes, their standard debugger is so good it makes xcode and android studio blush in shame.

Pfft it's nothing compared to what Ultimate has. Even John Carmack has said how good they are in Ultimate and you cant get higher praise than that.

unkle stu said,
I think C++ 11 is higher up than is given credit.. especially against the Windows Runtime where everything is ref new'd

Err, what? "ref new" is syntactic sugar over new/make + addref (or at worst, CoCreate/ActivateInstance, depending on the class). The compiled result is identical.

Also, that's C++/CX, not C++ 11.

unkle stu said,
I think C++ 11 is higher up than is given credit.. especially against the Windows Runtime where everything is ref new'd

I think the greater point they are trying to make is that there is no reason why we have to put up with c++ legacy syntax to achieve its benefits. Honestly I'm surprised it took them this long. I can't remember the number of times over the past decade I hadn't wished c# would break out of the .net runtime and just compile to native.

I'm ok giving up the GC given VS debugging tools and extensions make memory profiling extremely easy.

unkle stu said,
I was referring to smart pointers being baked in.. there's also std::shared_ptr etc

What does that have to do with performance? Smart pointers are template-based and thus expanded at compile time, and are easily inlined.

unkle stu said,
Nothing; I was talking about the other axis Safety/Productivity

Oh I guess I misread your post as suggesting that ref new made it a "higher level" / lower performance language. My mistake.

There's ways around that (Delimon.Win32.IO plus others) but yea.. that needs addressing already.. long overdue. Not that I've got anything against new features mind you.. I like that they keep building on it with new toys.