This project is read-only.

[closed] ascii vomit

Topics: Language Specification
Oct 2, 2012 at 7:34 PM

Please tell me the point of putting a colon between the type and the identifier? And what is the thinking behind the order? Look at the function declaration and then look at the function signature, its inconsistent. Consider the following code in which you would like to take argument defaults, it starts to look especially bad...

This looks bad...

const decode(foo:string="foobar", bar:number=10) { ... }

This looks better...

const decode(string foo="value", number bar=10) { ... }

and this is ok...

const decode(string foo="value", const number bar=10) { ... }


Oct 2, 2012 at 7:43 PM

Agreed. Consistency in identifier declarations is important.

Oct 2, 2012 at 7:52 PM

I agree, but I believe this is mainly to account for parameters that require specific function signatures. For example you can do something like this:

function foo(bar: (string) => bool){


To Specify that a function should take a parameter that is itself a function which accepts a string, and returns a boolean. Trying to accomplish this without having some sort of alias (a generic Action<T>, Func<T> definitions) may have been difficult.

Oct 2, 2012 at 8:01 PM
Edited Oct 2, 2012 at 8:15 PM

The complex case should never dictate the simple case. And here, the complex case in unnecessary and possibly should not be allowed for the sake of sanity! :) Consider the simplicity and sanity of this sudo code...

string f(string s) {

  return s;


void foo(function f) {

 console.log(f('hello, world'));


Oct 2, 2012 at 8:02 PM

Note that when you assign a default parameter value you do not need to provide a type annotation as it is inferred from the default value. The reasoning behind the pascal-style type annotations is that it was a more straight forward addition on top of JS syntax. It is also easier when types are optional as they are in TypeScript.

Oct 2, 2012 at 8:08 PM
Edited Oct 2, 2012 at 8:14 PM

I think pascal-style type annotations are very alien in an already javascript-heavy aesthetic. What makes it more strait-forward? Your straight-forwardness assertion is simply a straw-man. I also dont understand who its easier for, the parser/lexer or the coder?


Edit: I'm cool with inferred types, but the main argument still stands. If you can't find an argument *for* using the colon or the specified order, it will continue to seem awkward and wrong in some way.

Oct 2, 2012 at 9:17 PM


// valid TS:

function foo( a = "test": string) { 
  return a; 

... That's not to say that I like it. Just that it's not an issue with ES6 default params


Oct 3, 2012 at 9:20 AM


function (a = "test")
the parameter type is inferred to a string. An additionally type annotation is not needed.

Oct 3, 2012 at 12:43 PM

@teyde, im just going to assume you are a bot or you have not read the entire conversation.

@all There really is still no reasonable answer to this question. I'm guessing this is the direction that will this community will take.

Oct 3, 2012 at 5:32 PM

@hij1nx, this was answered in the thread "Why the backwards colon parameter typing?".

Also note that mathematicians use the so called "ascii vomit". And most of the more advanced statically typed programming languages use : or ::. 

Bjarne Stroustrup, the creator of C++ stated this: "I consider the C declaration syntax an experiment that failed".

Personally I vastly prefer the "ascii vomit" to the C style, there's a world of beauty in the notation f: X->Y, used by mathematics and many programming languages.


Oct 3, 2012 at 5:46 PM
Edited Oct 3, 2012 at 5:47 PM


By attempting to point out the obvious fact that mathematicians use operators, you have pretty much lost all self-respect as a programmer. Any good PL researcher/implementer understands that cognitive load is an important consideration for adoption. I think by more advanced you mean more complex, not better.

Bjarne Stroustrup (the creator of C++) also said "You don't improve a language by simply adding every feature that someone considers a good idea." Funny, considering how Bjarne is possibly the one person who could write a program that used every C++ feature.

Do you have a github account? I'd love to read some of your code.

Oct 3, 2012 at 6:39 PM

I was pointing out the fact that mathematicans, who also care about cognitive load, use the notation you consider vomit. It seems to me that most PL researchers also prefer and use the mathematical notation.

BTW: My code has quite a lot of "ascii vomit" in it (and "unnecessary complex" types like string->bool) so I think it's best you don't read my code, it could make you really sick. ;)

Oct 3, 2012 at 6:46 PM

no github? you are more than likely a software manager or a troll. #gtfo.

Oct 3, 2012 at 7:09 PM

I have a github account and have probably written hundreds of thousands of lines more code than you. But now I'll follow your friendly advice.

Oct 3, 2012 at 7:39 PM
Edited Oct 3, 2012 at 7:46 PM

Cool story, bro. I found your github account here:


Oct 15, 2012 at 3:58 PM

I hope that I can help to explain why the types were implemented as they are.

In a language where types are mandatory, it makes sense to use:

string name = "hij1nx";

But in a language where the type is optional, it makes more sense to add it after the name of the variable, parameter, function...

var name: string = "hij1nx";
Placing the type after the name makes it explicit that the type is optional.

Oct 17, 2012 at 9:40 PM
your answer says "x makes sense", and "x makes it explicit"; but consider the following statements which are easier to read, just as effective and ultimately less complex...

string name = "hij1nx"; // (an explicit type)

var name = "hij1nx"; // (a variable type)