Live data from Hacker News

The history of C# and TypeScript with Anders Hejlsberg [video]

youtube.com

11–20 of 162 posts

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#11

We need Anders to make one final language. A MINIMAL memory safe language. The less it has the better. Rust without the crazy town complexity. The distilled wisdom from C# and Delphi and TypeScript. A programming language that has less instead of more.

I want something that will bring productivity of Delphi to Web. May be I am old now, but I could have built applications in a weekend in Access or Visual Basic that will take weeks now in latest web stack.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#12

I don't know that many languages but, having been writing lots of typescript in the last 3 years there are so many things I love about it. It infers types. If I do const data = [ { name: 'bob', age: 35, state: 'CA' }, { name: 'jill', age: 37, state: 'MA' }, { name: 'sam', age: 23, state: 'NY' }, ]; Typescript knows data is an array of { name: string, age: number, state: string }. I don't have to tell it. Further, if…

What you are describing is structural types. It is indeed a mystery that these are so under used, especially as they are a cornerstone of type theory. Structural types are so useful that they creep into most languages in some way. Even in Java, the Kingdom of the Nouns, where the rulers refused to merge a pair class, functions essentially take tuple arguments and these tuples don't have to be named and defined. You can't return a tuple though, so there is an unfortunate asymmetry. In Haskell and OCaml, we like to describe functions in a structural way, so com.google.android.Predicate would be just "a -> Bool". You wouldn't have to convert your com.google.guava.Predicate. But even these languages lack structural records and variants and suffer for it.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#13

We need Anders to make one final language. A MINIMAL memory safe language. The less it has the better. Rust without the crazy town complexity. The distilled wisdom from C# and Delphi and TypeScript. A programming language that has less instead of more.

What would you take out of C# etc?

(not OP) I would take out mostly historic stuff, that is in there for backwards compat, that has been superseeded. But this could be achieved using linters.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#14
post #10

I don't know that many languages but, having been writing lots of typescript in the last 3 years there are so many things I love about it. It infers types. If I do const data = [ { name: 'bob', age: 35, state: 'CA' }, { name: 'jill', age: 37, state: 'MA' }, { name: 'sam', age: 23, state: 'NY' }, ]; Typescript knows data is an array of { name: string, age: number, state: string }. I don't have to tell it. Further, if…

Lots of languages can infer types. And your last example with the colors is just a dictionary.

Most languages have poor support for structural types though. If you try and join two records together (like a SQL join), what will your favourite language infer then?

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#15
post #10

I don't know that many languages but, having been writing lots of typescript in the last 3 years there are so many things I love about it. It infers types. If I do const data = [ { name: 'bob', age: 35, state: 'CA' }, { name: 'jill', age: 37, state: 'MA' }, { name: 'sam', age: 23, state: 'NY' }, ]; Typescript knows data is an array of { name: string, age: number, state: string }. I don't have to tell it. Further, if…

Lots of languages can infer types. And your last example with the colors is just a dictionary.

dictionaries generally aren't guaranteed to contain an entry for every possible value of the key type. while you could implement the colors example with a dictionary, ideally you'd want the type system to assure that given a Color, there will be a string associated with it

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#16
post #10

I don't know that many languages but, having been writing lots of typescript in the last 3 years there are so many things I love about it. It infers types. If I do const data = [ { name: 'bob', age: 35, state: 'CA' }, { name: 'jill', age: 37, state: 'MA' }, { name: 'sam', age: 23, state: 'NY' }, ]; Typescript knows data is an array of { name: string, age: number, state: string }. I don't have to tell it. Further, if…

Lots of languages can infer types. And your last example with the colors is just a dictionary.

It's not a dictionary (type-wise). "as const" is the magic ingredient.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#17
If you feel that TypeScript, or hell even JavaScript, is becoming more alike C#, it's actually deliberately done by Microsoft in benefiting their ecosystem. In this interview they mentioned they had internal demands to convert/transpile C# into JavaScript or TypeScript. So by making these target languages more like C#, it directly benefits their need. But I don't think this should be the driving force in designing ECMAScript. When they are pushing a language feature, they have an unspoken internal goal, and every choice they make is to make JS/TS look more like C#, and they are more likely to dismiss proposals that preventing them from deliverying that goal. There's likely a bit of conflict of interest there.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#18

I don't know that many languages but, having been writing lots of typescript in the last 3 years there are so many things I love about it. It infers types. If I do const data = [ { name: 'bob', age: 35, state: 'CA' }, { name: 'jill', age: 37, state: 'MA' }, { name: 'sam', age: 23, state: 'NY' }, ]; Typescript knows data is an array of { name: string, age: number, state: string }. I don't have to tell it. Further, if…

Inferred types are really great, but I feel they do not scale. Inside a method/function? Generally fine, but the signature, including the return type, had better be explicit.

Also, I think there was some performance issue with too much inference? Could be wrong, could also be fixed.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#19
post #15
post #10

Earlier quoted context omitted.

Lots of languages can infer types. And your last example with the colors is just a dictionary.

dictionaries generally aren't guaranteed to contain an entry for every possible value of the key type. while you could implement the colors example with a dictionary, ideally you'd want the type system to assure that given a Color, there will be a string associated with it

Sounds like enums with extra steps.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#20
post #17

If you feel that TypeScript, or hell even JavaScript, is becoming more alike C#, it's actually deliberately done by Microsoft in benefiting their ecosystem. In this interview they mentioned they had internal demands to convert/transpile C# into JavaScript or TypeScript. So by making these target languages more like C#, it directly benefits their need. But I don't think this should be the driving force in designing EC…

It sounds like conspiracy theory that they design TS/JS to convert from C# easier, huh.

The truth is that C# is probably the best designed mainstream language out there.

C# was known as a language with lowest amount of WTF per LoC

Post reply on HN