Why not C# syntax

Topics: Language Specification
Jul 26, 2013 at 12:15 AM
I really like what typescript has to offer. But I really wish that we had chosen C# like syntax for typescript.

Writing variableName : string is painful as it just is not natural for C# or Java coders. Looked at DART from Google and they seemed to have very nice syntax.

Is there anyway we can move to more general purpose programming language style so that people don't have to learn new syntax. I like that it's a superset that can be mixed and matched with Javascript but I believe that can still be accomodated in C# like syntax.

Sorry for the rant. I really like what TypeScript has to offer otherwise.
Coordinator
Jul 29, 2013 at 2:44 PM
The syntax has been discussed on here a few times. The main difference between those other languages and TypeScript is that TypeScript is a superset of JavaScript. Any syntax we pick has to fit in nicely with the current version of JavaScript, and as best we can, fit the future version of JavaScript. Syntax for a lot of TypeScript comes from JavaScript, even its class syntax and module syntax are inspired, or directly use, the syntax currently being designed for the next version of JavaScript.

As a superset, certain deltas on pure JavaScript are going to fit better. Just as an example, if we take this:
var x;
And then add an annotation:
number x;  
var x: number;
In the first case, we had to delete something that came in from JavaScript, so we're not just adding things anymore. In the second case, you can just add the annotation to the JavaScript without deleting anything. With the amount of type inference we do in TypeScript, in many cases you don't even need to do that, so you can leave the JavaScript alone entirely.

The long and short of it is really that TypeScript is a different language, so we tried to pick the best syntax for working with JavaScript.
Apr 14, 2014 at 7:17 PM
Edited Apr 14, 2014 at 7:18 PM
I was just looking around for an answer to the same question and read the answer above. And I have to say... Wow. Is THAT the reason for the 'new' syntax. You dont want to remove 'var'?? This just seems downright silly. Then again, it seems silly to argue with Anders of course.

But it's still nothing short of amazing to me that teaching programmers to write this:
function add(left: number, right: number): number {
return left + right;
}
Instead of just compiling this to javascript:
int add(int left, int right) {
    return left + right;
}
It reuses the syntax of almost any C based language, java programmers get this, c# programmers get this. I mean, it's not like typescript is valid Js. There is still a conversion being done. Why oh why invent something new?
Coordinator
Apr 14, 2014 at 7:45 PM
What do you mean by "new" ? Constructs in a form like name: type have been around since before the web. You can see them in languages like ML (1973), Haskell (1990), Scala (2003), F# (2005), and many others.
Apr 14, 2014 at 9:33 PM
Edited Apr 14, 2014 at 9:35 PM
You're right. The word 'new' is not best here. Perhaps 'mainstream' or 'more generally accepted' seem more appropriate. It daunts me slightly why c#-like syntax seems good enough for the server, the mobile device, embedded, robotics, xbox, anything except the client apparently.
Apr 14, 2014 at 9:45 PM
It comes down to JavaScript !== C#.

The feeling I get from the TypeScript team, and the one I agree with, is that they wanted to make Typed JavaScript, not a C# -> JavaScript Compiler. So they intentionally selected syntax that worked nicely with JavaScript instead of C#. I will agree at times it's confusing to go from writing your types on the left, to writing your types on the right, but as with any other programming language it's just syntactic sugar.

As a developer I do about 50 / 50 split between C# and JavaScript, and I want to push my organization to adopt TypeScript because it offers our C# developers, those that are not used to working with JavaScript the static typed confidence that the code they're writing is correct, that they library they're using has the method they're looking for, etc.
Apr 14, 2014 at 10:18 PM
You can add ActionScript to that list as well. I used to work with Flex Builder (now called Flash builder) for building flash apps, and it uses much the same syntax!
Apr 14, 2014 at 10:28 PM
Note that I wasn't saying C#, but C#-like syntax. I emphasize the difference. Don't even look at the compiler for a moment, just the way C# implements the exact syntactic sugar TypeScript is trying to add. Things like classes, typical OO like things such as inheritance, but also enums, and so on. It's already out there and there's vast amount of c# knowledge and that knowledge is available to companies at a decent price.

I personally did only one, medium sized, project using just TypeScript on the client. I like it enough to use it again because with, frankly, my limited knowledge of building large javascript client-side frameworks, it's the most clear thing to give structure to a project and separate the client logic concerns.

Still though, indulge me, somewhere the team had the hefty decision of either sticking closer/cleaner to javascript with the way TypeScript works now or making it look more like the C#/Java syntax. And looking at the way they could have made it much more useful to such a large group of people out of the box, I'm just not convinced the former is the best way to go.

As a disclaimer; smarter and more experienced people than me have thought about this problem, but none of the stuff I've read yet could clearly explain to me the decision. Certainly static type checking, the thing you mentioned last, is not dependent on the syntax and can be implemented either way.
Developer
Apr 14, 2014 at 11:21 PM
You seem to be approaching this only from the perspective of writing new code. You're significantly undervaluing the ability to use existing JavaScript code with TypeScript. Your proposal means that moving a JavaScript project into TypeScript would mean modifying every single variable declaration, function argument, etc just to get the code to be syntactically valid. This is an enormous cost to add to try TypeScript and see the value it adds over an existing JavaScript implementation. Using the current syntax allows for this easy migration and has the nice property of looking more like the emitted JavaScript which is highly valuable as well.
Coordinator
Apr 14, 2014 at 11:22 PM
I think there's a broad incorrect perception that the goal of TypeScript was to make JavaScript palatable to C# developers, rather than to make the benefits of static typing available to JavaScript developers.

Some examples of how "types on the left" doesn't work very well with JavaScript:

Declaring a function variable
// TypeScript
var x: (n: string) => number;
var y: (n) => void;
// Proposed
number (string n) x;
void (n) y;
Granted I'm biased, but I like the TypeScript version a lot more. Without delimiting tokens like :, it's hard to tell where the function type ends and the variable name begins. The y declaration is also perilously close to the expression syntax void (n). You really have to be careful here to determine that these are variable declarations, not expression statements.

Adding a type annotation to a function expression
var x = function(string x, y, z) {
    return z;
};
The leftmost item of each part of the parameter list is now either a type name or an identifier. That's confusing.

What about anonymous types? I want to declare a variable of an anonymous type that has a function called 'g' that returns a 'void':
{ void g(); } x = null;
This code is valid JavaScript that means something entirely different, which is very bad. There might be some other way of writing type literals that doesn't have this problem, but I can't think of one. That's a serious problem in a structural typing system.
Apr 14, 2014 at 11:30 PM
Edited Apr 14, 2014 at 11:54 PM
Considering this:
if (true) Function f = int add(int left, int right) {
    return left + right;
} 
IMHO, that just seems equally strange for people coming from a JavaScript world ("if (...) Function ... int ...") - especially since "Function" is ALSO a valid identifier as well, which means "if (true) Function, f = ..." is also valid code [though contrived] - and what if that was a TYPO!!! It would run and also pollute the global scope.

In JS the above may also be written as "if (...) var f = function add(): int { ... };" To me, that format in TS is more natural for adding types on JavaScript conventions. After all, I WANT to program in JavaScript, not C, (and students can learn much of JS using TS as well) so the conventions should resemble JS as much as possible. All JS developers need is TYPE CHECKS, not a new language to learn (TS should not force JS developers to learn C/C#). Also, as I said, many people from the past have a lot of ActionScript experience mixed with JS, so there may actually be much less of a learning curve for most people.

What about:
int a = 0, b = 0, c = 0;
bool d = true, e = true, f = false;
vs
var a = 0, b = 0, c = 0, d = true, e = true, f = false;
For that matter, consider people who have JavaScript libraries with 1000s of lines of code - do you really want to enforce a new convention and force people to scour over their code to reformat "var a ..." to "<sometype> a..."? In TS I could just dump in my existing JavaScript code, and voilà! Like magic, "a, b, c, d, e, f" have types (without doing anything). I can keep all my "var" code as is, and just enforce types where needed.

I'm going to take a guess that # of JS developers > C# developers, so why would any one want to choose C/C# to base the convention on?
Apr 14, 2014 at 11:35 PM
(oh, you guys just posted before me! LOL)
Apr 15, 2014 at 6:54 AM
Ok, thx all for taking the time to elaborate on the topic a bit more. It's definitely clearer to me now how using c#-like syntax would result in a bigger mess. If you wanted to support all the Js code structures, you would end up with something not looking like c# anyway.

The migration path is a good point to. I very much agree it's a really good place to start to just be able to rename your .css files to .less and your .js files to .ts and slowly add start adding the value typescript offers instead of turn-key per file. I see now there is no reasonable way to make c# like syntax a superset of js.
Apr 18, 2014 at 4:02 PM
Edited Apr 18, 2014 at 4:18 PM
Well, this TypeScript is not as successful as it should have been. The idea of writing C# and get it translated into Javascript is genuinely cool. Think about the C# eco system that we have today (AutoMapper, T4, TFS Build, Static Code Analysis). All of these are going to be missed simply because TypeScript is not following C# language spec.

PEOPLE HATE TO LEARN A NEW LANGUAGE. And companies do not want to pay for the adventure into another language that may not be easy for hiring new resources. Python is an example.


Typescript inventors could follow the dream of being able to copy and paste any javascript snippet to get going. They hope that would be a good sale for people who already know about Javascript. But that's not a good business strategy.

Why?
People who are fluent in Javascript don't want to change to another language. They have little urge to do so.
People who are not fluent in Javascript but fluent in a static type language always want to be competitive with their fellows who write Javascript.

Instead of Typescript being a miracle to help C# developers to build front end code. It does the opposite way of convincing people who write front end code to think as back end developers.


Looks like somebody has started Script# to address the issue from the other end.

https://github.com/nikhilk/scriptsharp
Apr 19, 2014 at 2:42 PM
Believe2014 wrote:
Well, this TypeScript is not as successful as it should have been. The idea of writing C# and get it translated into Javascript is genuinely cool. Think about the C# eco system that we have today (AutoMapper, T4, TFS Build, Static Code Analysis). All of these are going to be missed simply because TypeScript is not following C# language spec.
What measure are you using to gauge the success of TypeScript? 4600+ commits in Definitely Typed by almost 400 different users, that seems pretty successful.
PEOPLE HATE TO LEARN A NEW LANGUAGE. And companies do not want to pay for the adventure into another language that may not be easy for hiring new resources. Python is an example.

Typescript inventors could follow the dream of being able to copy and paste any javascript snippet to get going. They hope that would be a good sale for people who already know about Javascript. But that's not a good business strategy.
TypeScript is JavaScript. You can choose to use ECMAScript 6 things like classes and modules or not. Still ECMAScript 6 is also just the next version of JavaScript. It's an additional iteration much like how C# is version'd. JavaScript isn't going away, if you don't want to learn JavaScript, I really urge you to give TypeScript a real shot, instead of bringing a bunch of C# assumptions along with you. The ability to interface directly with native and populate JavaScript libraries like JQuery, Angular, Knockout with minimal work, is a huge boost in productivity.
Why?
People who are fluent in Javascript don't want to change to another language. They have little urge to do so.
When you look at larger teams, as a JavaScript Developer, I have an urge to because static typing allows errors to be highlighted faster. This helps myself, as well as helps my team in the event I'm working with developers of less experience or developers without JavaScript familiarity are working on the code. I do C#, and JavaScript, I want other developers to have the same flexibility, but most of the stereo-typical C# developers I've worked with are uncomfortable with JavaScript because they don't have the safety net that static compilation gives you and the tooling that comes with it like Intellisense, Refactoring, etc. Static Compilation and Tooling are the reasons why TypeScript was developed.
People who are not fluent in Javascript but fluent in a static type language always want to be competitive with their fellows who write Javascript.

Instead of Typescript being a miracle to help C# developers to build front end code. It does the opposite way of convincing people who write front end code to think as back end developers.


Looks like somebody has started Script# to address the issue from the other end.

https://github.com/nikhilk/scriptsharp
Script# is promising on the surface, but the Developer has left Microsoft so without an active maintainer I would be worried about buying into a technology that is steadily falling behind. TypeScript has a vibrant community that has produced hundreds of interfaces for all the popular and obscure JavaScript libraries, and they are actively working on making sure everything is up to date, identical to the library it represents.
Apr 19, 2014 at 3:22 PM
Edited Apr 19, 2014 at 3:25 PM
DavidDriscoll wrote:
Believe2014 wrote:
Well, this TypeScript is not as successful as it should have been. The idea of writing C# and get it translated into Javascript is genuinely cool. Think about the C# eco system that we have today (AutoMapper, T4, TFS Build, Static Code Analysis). All of these are going to be missed simply because TypeScript is not following C# language spec.
What measure are you using to gauge the success of TypeScript? 4600+ commits in Definitely Typed by almost 400 different users, that seems pretty successful.
You have proof of how TypeScript is successful. But you don't have any proof about how it should have been much more successful. If you want, we can sit together to make an anonymous survey and post it around the community to get their opinions.

Also, the market is operating 2 ways: pull and push. Either each developer pulls (try to sell) modern technologies to their managers for using in production; or the managers could push the developers to evaluate and choose a technique or tool that have the most advantages to their company. If you think about the bigger team (Dev + DevOps + QC + Managers), not just developers, you can see that a good language is just the first step. Tooling, Automation, Reporting are all as important as the language itself. To this extent, I can't enforce JsLint, automate unit tests, collect code metrics (complexity, coupling, cohesion). When you are on a few people team, this does not matter. But when you are on a larger team, especially with outsourcing or contractors on board, the code metric reports are everything you have to track, communicate, lead and make decisions.

I know that you can automate TypeScript on the server side to generate Javascript and run JsLint against the generated code. This does help. But all of the extra efforts on converting current Javascript to TypeScript, configuring automated translation, configure TFS Build to enforce Gated Checkin Build,... could have been a much easier sell if the statement "TypeScript is C#" holds true rather than "TypeScript is Javascript".

First comes the language, then come the tools. It's very reasonable to think of it that way. TypeScript is comparable to Dart language. Both are cool but hard to sell.

KnockoutJS is developed by Steve Anderson, not Microsoft. And now Script# seems to be the same story. While there could be many reasons behind the way Microsoft choose what to build to fit the long term strategy of the company. I just wish the similar effort (marketing, contributing, distributing) could be done for all good projects.
Apr 21, 2014 at 10:24 AM
@Believe2014,

You make a compelling case for why it would be difficult to force adoption of TypeScript within a large organisation. As you say
_
If you think about the bigger team (Dev + DevOps + QC + Managers), not just developers, you can see that a good language is just the first step. Tooling, Automation, Reporting are all as important as the language itself.
This is a very valid point.

However, I don't see how this problem can be solved by making the TypeScript syntax more C#-like. The output of TypeScript is JavaScript. The tooling, automation etc build for C# is not likely to simply work off that output.
Apr 21, 2014 at 12:19 PM
Edited Apr 21, 2014 at 12:20 PM
I sort of did a 180 based on the recent discussion in this thread. Somewhat ironically I am now convinced the TypeScript syntax is the cleanest way to tackle the 'javascript huge application problem'. I thought allot about the things said here, but also I watched a few convincing videos which helped me cross that line, so to speak.

For example, the old Crockford video he gave at google left me with a feeling that javascript 'is just too weird' to fit into the programming paradigm we know today where we separate the concerns in our business logic based on classically implemented OO principles.
https://www.youtube.com/watch?v=hQVTIJBZook

Also, Sean Hess made an interesting video about using TypeScript (he loves TS) together with Angular. Based on that video I came to the conclusion that Ts being a close-syntax superset of Js in not just a nice feature, but an absolute must-have for giving broad adoption a chance.
https://www.youtube.com/watch?v=u6TeBM_SC8w

Also, the syntactically closeness, if you will, of TypeScript to EC6 is worth it's weight in gold in a few years.
Apr 22, 2014 at 2:00 PM
I can see that Microsoft create C# as the next evolution of C++. TypeScript may be the same evolution step of vbScript, an adoption of Javascript by Microsoft. While Microsoft may have all the resources and investments to invent and promote a new language, and get head to head in the race with other big names (Dart language from Google), we don't have to wait.

I did not look very deeply into Script#. But I have my own way of translating C# to Javascript: Use Roslyn to parse a C# project, then use T4 to translate the C# DOM into Javascript.

If you are interested, please let me know.

Believe.
Apr 22, 2014 at 2:19 PM
Use Roslyn to parse a C# project, then use T4 to translate the C# DOM into Javascript.
Wait what? You actually have this done or in beta??

I'm pretty sure I won't be using it but I'm also pretty sure I want to see what you've done with it.

Put it on Git plz.
Apr 22, 2014 at 4:27 PM
No, I have not done it. But I know how to do it. I am asking to see if anyone is interested in that direction.
Apr 22, 2014 at 4:30 PM
GerbenRampaart wrote:
Ok, thx all for taking the time to elaborate on the topic a bit more. It's definitely clearer to me now how using c#-like syntax would result in a bigger mess. If you wanted to support all the Js code structures, you would end up with something not looking like c# anyway.

The migration path is a good point to. I very much agree it's a really good place to start to just be able to rename your .css files to .less and your .js files to .ts and slowly add start adding the value typescript offers instead of turn-key per file. I see now there is no reasonable way to make c# like syntax a superset of js.
I think this is a good strategy for existing code. But for building a new app, I want to help all C# guys to kick start a new empty project in C# with Unit Tests and existing Continuous Integration infrastructure.
Apr 22, 2014 at 4:47 PM
Of course, that approach would require implementing at least a sizeable chunk of the BCL into JS, implementing the whole of the DOM in C# for coding against, and finding a way to cope with the inherent differences between fully statically typed code (overloads etc) and a dynamic language.

Apr 22, 2014 at 4:57 PM
markrendle wrote:
Of course, that approach would require implementing at least a sizeable chunk of the BCL into JS, implementing the whole of the DOM in C# for coding against, and finding a way to cope with the inherent differences between fully statically typed code (overloads etc) and a dynamic language.
I agree. I need resources. It's not impossible. Developers could also find a few limitations in beginning as it is reasonable to not support the whole Entity Framework in it.
But, I enforce a policy in my team to keep their code files under 200 lines including comments. If you could meet that constraint, porting C# to any other languages should be easier than it may sound.
Apr 22, 2014 at 4:58 PM
Edited Apr 22, 2014 at 4:59 PM
Imagine all of the C# design patterns come to live in Javascript, that's a big win.
Apr 22, 2014 at 5:03 PM
The only thing that I don't like that much is the fact of I have to use T4, which is not the first choice of C# developers. Poor design support (intellisense, syntax coloring) and bad debugging experience are pretty hard to sell.
Apr 22, 2014 at 5:06 PM
As I've heard Anders say several times, "people have tried to replace JavaScript before, but it's not broken enough." As limited as it may be, JavaScript works, and there are billions of lines of it in the wild and hundreds of JavaScript libraries available. C# in the browser means you automatically lose first class access to all of those libraries and isolate yourself into your own little community.

C# is a great language, but if you look at TypeScript's current feature set and all the feature requests for it, it could easily reach or surpass C# in terms of ease of development eventually.
Apr 22, 2014 at 5:12 PM
Edited Apr 22, 2014 at 5:13 PM
MgSam wrote:
there are billions of lines of it in the wild and hundreds of JavaScript libraries available.
Dart has the concept of Interop to call native Javascript functions. I could use that idea, too.
C# in the browser means you automatically lose first class access to all of those libraries and isolate yourself into your own little community.
No C# in the browser. C# in the console and T4, that generates Javascript in the browser.
C# is a great language, but if you look at TypeScript's current feature set and all the feature requests for it, it could easily reach or surpass C# in terms of ease of development eventually.
No doubt about the power of TypeScript. It's just another language that people have to learn.
Apr 22, 2014 at 5:14 PM
Edited Apr 22, 2014 at 5:14 PM
GerbenRampaart wrote:
I sort of did a 180 based on the recent discussion in this thread.
What is this 180?
Apr 22, 2014 at 6:25 PM
I turned 180 degrees in opinion. As in, I've completely changed my mind.
Apr 22, 2014 at 7:52 PM
No doubt about the power of TypeScript. It's just another language that people have to learn.
Funny thing: Coming from the C++/Assembly world, I said the same thing about C# many years ago. ;) (I was eventually sold on the memory management part - I hate writing my own GCs - and also on how close it was to C++ in many ways [and you could still use unsafe pointers if ever needed for low level stuff]]). Sometimes being very much like a superset of another language (perhaps similar to moving from C to C++) is all that is needed; to add some enhancements, and nothing more.
Apr 23, 2014 at 9:54 AM
We've just ported a C# code-base to TypeScript, achieving a 60% reduction in terms of LOC. Wasn't all that difficult to bid goodbye to the lovely 'System.InvalidCastException'.

TypeScript is not the next evolution of vbscript: it feels more like the next evolution of JavaScript and C# combined.
Apr 23, 2014 at 1:26 PM
Someone needs to make a sticky post containing all of the rebuttals to this tiring, ill-thought out and short-sighted request. The often indignant and demanding tone of the question is what really makes me crazy.
Apr 23, 2014 at 7:10 PM
Someone needs to make a sticky post containing all of the rebuttals to this tiring, ill-thought out and short-sighted request.
I agree with the premise of what you're saying, but you're exaggerating. Basically you say that the idea for scriptsharp is tiring, ill-thought and short-sighted instead of pointing out in a more nuanced way why that has proven not to be a success.
The often indignant and demanding tone of the question is what really makes me crazy.
The irony of that comment is so thick you can cut it with a knife.

But to keep it on-topic; good points were raised here, but in the end, and I am not hero-worshiping here, Anders Hejlsberg has enough credit by now that if it would have worked better with C# syntax, he would've designed it like that.
Apr 23, 2014 at 7:49 PM
My personal preference is a sticky post that says "This is a forum: please do not ask any questions"
Coordinator
Apr 24, 2014 at 4:18 PM
Edited Apr 24, 2014 at 4:19 PM
I think wanting C# syntax is perfectly valid, that's why Script# exists and why you are seeing people want to compile from C# to JS in other toolchains. C# is a great language with a lot of features that help you get real work done. Users who want to keep working in C# and target JS can do just that, which I think is great.

TypeScript has a different focus. It answers a different question. "What if we started from JavaScript" and then we grew a language that gave JavaScript some of the pieces that programmers would need for tooling, early error detection, as well as class/modules/lambdas. We knew ES6 was going to have those, so we aligned as much as we could there and will keep working to align in the future.

Just a different approach. I like where TypeScript landed. It gives you the ability to use the lightweight JavaScript syntax, and, if you want, sprinkle in a few types to help catch errors and save you time where you might otherwise have written a unit test. You can also go OOP to the max, and build out a full class hierarchy. A lot of what you learn you can translate into ES6 when that comes out, which is an added bonus.

All about choice and the trade-offs that make sense for your team/project.
Apr 24, 2014 at 5:14 PM
I like where TypeScript is too. I think "type first" is familiar from C, but yeah, it's a mess when declaring function types. (For a laugh, take a look at fuckingblocksyntax.com and look at what I have to deal with when I'm declaring block types in Objective C (blocks are Objective C's anonymous functions).)
Apr 24, 2014 at 5:47 PM
Edited Apr 24, 2014 at 5:55 PM
In regards to Script#, I've tried it for awhile and it quickly became tiring. First, I kept wanting to do C# specific stuff, to which the compiler quickly kept reminding me how much of a C#-JS noob I was (I'm not new to C# by a long shot; I had to think about what only works in "JavaScript" while in C# [this is counter intuitive]). Second, I quickly realized there wasn't a large enough following (at the time), so I would end up writing definitions for all the JS libraries I wanted to use (not fun; with TS we have Definitely Typed). Thirdly, having to toggle back and forth from C# and JavaScript to see what the heck is actually being produced when hooking it up to my pages was a pain (TypeScript is not as abstract - and in fact, as stated above, is closer to ES6 syntax [extra bonus points]). Finally, all members of my utility C# files (shared by other non-JS projects) had upper case letters (this is more of my own doing really). This was later corrected by using attributes - but I'd have to scatter those everywhere all the time to keep to JS naming conventions when creating a library API for JS users (so my hopes to use the shared C# files with other projects where quickly crushed - it just doesn't work that way). The preverbal nail(s) in the coffin for me where: 1. I couldn't replace class methods on the fly dynamically, or other fancy dynamic JS stuff (that C# hates), and 2. I had to create a separate project JUST for the C#-JS files (and understandably so). With TS, I can simply pop in a .ts file and watch the magic. Perhaps things have changed with Script# lately, but for me at least, TS and the many existing definition files gave me all I needed to quickly build somewhat type-safe large scale frameworks, with intellisense for the DOM and most common libraries (and then some), while staying true to the coming ES6 semantics.

JavaScript is like freestyle painting, and TypeScript is like adding in the guide lines and numbering - use it if you want to. ;) C# is like art using stencils. :P ;)