Live data from Hacker News

Announcing TypeScript 0.9.1

blogs.msdn.com

111–116 of 116 posts

Re: Announcing TypeScript 0.9.1

#111

Earlier quoted context omitted.

C has very simple types and allows for untyped operations very easily. Say you cast some ptr of type void* to Foo*: at least in Python you would get a dynamic type error if the cast was incorrect; in C you are lucky if your program immediately crashes. C has some static type safety, and virtually no run-time type safety. Java on the other hand, has a lot of static type safety, is completely memory safe (barring bugs…

That's what we have valgrind, test cases and decent software engineers for. Java don't forget suffers as do other languages from lots of nasty things related to types including invalid casts, null reference exceptions etc. When these go phut in production, you're usually in the same situation.

Java is not a good example of a statically typed language. Null pointer exceptions just don't happen in idiomatic Scala. For example, let's say I have 3 functions a,b and c, each with signature Int => Option[Int]. Any one of these can return Some[Int] or None.

Options, like all collections, can be chained together as such:

   for {
      x 
this expression is of type Option[Int], and will never throw a null pointer exception. (Futures can be chained together with identical syntax)

Re: Announcing TypeScript 0.9.1

#112
post #70

Earlier quoted context omitted.

Your heart is in the right place, but you're stuck with a bad example still. C is hardly a good representative for an statically typed language. Read Luca Cardelli's "Typeful Programming"[1] to get an overview of what typed programming is all about, and see for yourself how brain-dead C and C++ are in comparison. After that go to Benjamin Pierce's canon, "Types and Programming Languages". [1] http://www.daimi.au.dk/~…

So what would you consider to be the "good representatives for an statically typed language"?

A language with a statically enforced type system? Anything in the ML family for starters, but more popularly, Java, C#, the Pascal family, etc.

Re: Announcing TypeScript 0.9.1

#113

Earlier quoted context omitted.

That's what we have valgrind, test cases and decent software engineers for. Java don't forget suffers as do other languages from lots of nasty things related to types including invalid casts, null reference exceptions etc. When these go phut in production, you're usually in the same situation.

Java is not a good example of a statically typed language. Null pointer exceptions just don't happen in idiomatic Scala. For example, let's say I have 3 functions a,b and c, each with signature Int => Option[Int]. Any one of these can return Some[Int] or None. Options, like all collections, can be chained together as such: for { x this expression is of type Option[Int], and will never throw a null pointer exception.…

> Null pointer exceptions just don't happen in idiomatic Scala.

But match exceptions do.

Anyways, if I had to choose between unsound static type checking and sound dynamic type checking, I would definitely choose the latter.

Re: Announcing TypeScript 0.9.1

#114

Earlier quoted context omitted.

5 is not entirely correct. 6 is not true, serialisation in dynamic languages is correctly done with type definitions. 7 is not true at all, mainstream statically typed languages (like C) much more commonly overflow silently. Look at Python, there's no way to lose precision through arithmetic, as types get promoted on overflow correctly. In general, C's type system is so weak as to be both useless and a hindrance.

5 is true for the cases where it results in static compiled output which is equivalent of say C's output. 6 you're adding metadata with type definitions. Enough metadata is present in entirely statically typed languages to not do this. 7. How do you know if 1.000000000000000000001 is decimal or float? It's weak in some places but strong in others. Knowing when to use each case effectively is the art.

6. It's still necessary (or at least a good idea) to write serialisation models for most statically typed languages as well. the difference is minor

7. It's a float, unless you made it a Decimal explicitly. Arguably that's the wrong default, but almost no languages default to arbitrary precision/size everything.

No, C's type system is totally unsound. It fails to catch very bad errors (pointer-related issues, null-related issues, etc.) and is perfectly happy to implicitly cast left and right. It's little more than a hindrance.

Re: Announcing TypeScript 0.9.1

#116

Earlier quoted context omitted.

Java is not a good example of a statically typed language. Null pointer exceptions just don't happen in idiomatic Scala. For example, let's say I have 3 functions a,b and c, each with signature Int => Option[Int]. Any one of these can return Some[Int] or None. Options, like all collections, can be chained together as such: for { x this expression is of type Option[Int], and will never throw a null pointer exception.…

> Null pointer exceptions just don't happen in idiomatic Scala. But match exceptions do. Anyways, if I had to choose between unsound static type checking and sound dynamic type checking, I would definitely choose the latter.

> But match exceptions do.

I'd call that non-sense.

Post reply on HN