Live data from Hacker News

Announcing TypeScript 0.9.1

blogs.msdn.com

101–110 of 116 posts

Re: Announcing TypeScript 0.9.1

#101
post #90

Earlier quoted context omitted.

void* is used in practically every C library that offers a callback facility.

Almost... You have a typed pointer to a function but that's not a void pointer and the "New C Standard" 6.3.2.3 states that you can't cast a function pointer to a void*.

Not for function pointers; for passing data to callbacks that can be any type.

Re: Announcing TypeScript 0.9.1

#102
post #101

Earlier quoted context omitted.

Almost... You have a typed pointer to a function but that's not a void pointer and the "New C Standard" 6.3.2.3 states that you can't cast a function pointer to a void*.

Not for function pointers; for passing data to callbacks that can be any type.

Can you provide an example? Not 100% sure in which context you are talking about.

Re: Announcing TypeScript 0.9.1

#103
post #101

Earlier quoted context omitted.

Not for function pointers; for passing data to callbacks that can be any type.

Can you provide an example? Not 100% sure in which context you are talking about.

As an example, SQLite:

    int sqlite3_exec(
      sqlite3*,                                  /* An open database */
      const char *sql,                           /* SQL to be evaluated */
      int (*callback)(void*,int,char**,char**),  /* Callback function */
      void *,                                    /* 1st argument to callback */
      char **errmsg                              /* Error msg written here */
    );
Here the void * is an argument that is passed in the callback as well so that you can update your own struct with the result, for example. Singe the library cannot know anything about your types, void * is the only option.

Re: Announcing TypeScript 0.9.1

#104
post #24

I sometimes find myself torn between dynamic typing (great for rapid prototyping) and static typing (great for tooling and compile-time error checks). I'm a big fan of TypeScript's approach, which gives you the best of both worlds. Start with fully dynamic code to explore the problem space, then add more static guarantees as you firm up your design. I haven't had occasion to write a big web app recently, but I'm itch…

I think the greatest advantage to static typing is the IDE support. Compile-time error checking is overrated, and in my several years of writing JavaScript, I've never seen a bug in production that could have been prevented with static analysis. That might be because I know the language well, but it's not a feature I need.

"What's true of all bugs? They passed a type checker and they passed the tests!" - Rich Hickey

Re: Announcing TypeScript 0.9.1

#105
post #24

I sometimes find myself torn between dynamic typing (great for rapid prototyping) and static typing (great for tooling and compile-time error checks). I'm a big fan of TypeScript's approach, which gives you the best of both worlds. Start with fully dynamic code to explore the problem space, then add more static guarantees as you firm up your design. I haven't had occasion to write a big web app recently, but I'm itch…

I think the greatest advantage to static typing is the IDE support. Compile-time error checking is overrated, and in my several years of writing JavaScript, I've never seen a bug in production that could have been prevented with static analysis. That might be because I know the language well, but it's not a feature I need. "What's true of all bugs? They passed a type checker and they passed the tests!" - Rich Hickey

Your point is well taken, but I think it has value. Compile-time error checking is useful because it gives you flexibility to make changes in a big program. It's kind of like a big suite of automatic tests that make sure all the parts of your program talk to each other correctly.

Does it catch everything? Can you stop thinking critically? No, but it's still nice to have.

This sort of goes hand in hand with IDE tools (e.g. "change method name" sorts of things), so I don't think we necessarily disagree.

> I've never seen a bug in production that could have been prevented with static analysis.

That seems unlikely to me.

I do application penetration testing for a living, and I'll often use static analysis tools in my work. (Both robust, established tools and ad hoc scripts.) For example, check out Brakeman for Rails apps. These tools find actual bugs in actual production software.

Do they find everything? No, you can't rely on them completely. But they're still nice to have.

Re: Announcing TypeScript 0.9.1

#106
post #103

Earlier quoted context omitted.

Can you provide an example? Not 100% sure in which context you are talking about.

As an example, SQLite: int sqlite3_exec( sqlite3*, /* An open database */ const char *sql, /* SQL to be evaluated */ int (*callback)(void*,int,char**,char**), /* Callback function */ void *, /* 1st argument to callback */ char **errmsg /* Error msg written here */ ); Here the void * is an argument that is passed in the callback as well so that you can update your own struct with the result, for example. Singe the lib…

Thanks for the example. Agree entirely then :)

Re: Announcing TypeScript 0.9.1

#107

Earlier quoted context omitted.

This seems a little disingenuous. I bet Intellij already has great support, but the top link you give there for Sublime Text, emacs and vim doesn't really give anywhere near the level of support you get in Visual Studio. Literally just syntax highlighting! In Visual Studio you get at least error highlighting/completions/code generation/navigation/refactoring. There are definitely attempts to bring the language servic…

> This seems a little disingenuous. I bet Intellij already has great support, but the top link you give there for Sublime Text, emacs and vim doesn't really give anywhere near the level of support you get in Visual Studio. Literally just syntax highlighting! In Visual Studio you get at least error highlighting/completions/code generation/navigation/refactoring. It's a little disingenuous to expect environments that a…

Sorry for the poor choice of word on my part, I admit I was using "disingenuous" incorrectly there. I just thought the description of sublime/emacs/vim having "great" support for TypeScript might give someone the impression that something beyond syntax highlighting was supported.

I don't doubt that it's more work to support more than syntax highlighting, but that doesn't change the fact that the support in those editors is sub-par when compared with lots of other languages. For example I can install SublimeLinter and have basic error reporting for python code, or SublimeJEDI and have code completion and go to definition.

Re: Announcing TypeScript 0.9.1

#108
post #24

I sometimes find myself torn between dynamic typing (great for rapid prototyping) and static typing (great for tooling and compile-time error checks). I'm a big fan of TypeScript's approach, which gives you the best of both worlds. Start with fully dynamic code to explore the problem space, then add more static guarantees as you firm up your design. I haven't had occasion to write a big web app recently, but I'm itch…

I think the greatest advantage to static typing is the IDE support. Compile-time error checking is overrated, and in my several years of writing JavaScript, I've never seen a bug in production that could have been prevented with static analysis. That might be because I know the language well, but it's not a feature I need. "What's true of all bugs? They passed a type checker and they passed the tests!" - Rich Hickey

>...I've never seen a bug in production that could have been prevented with static analysis

That's because they're hidden by the lack of static analysis. They're just waiting for the wrong code path to be taken, then BAM. The whole system crashes.

You need static analysis to find bugs that can be prevented with static analysis. What a strange concept!

Re: Announcing TypeScript 0.9.1

#109
post #70

Earlier quoted context omitted.

Rather than slate me, some constructive discussion would be nice. I'll go from my side: 1. Static type compiler verification saves tonnes of problems. Try managing a 2MLOC dynamically typed solution and you'll get what I mean. 2. Static typed languages are way easier to refactor as more metadata is available to the tooling. 3. Static typed code is easier to test. The type contract is available over the boundary betwe…

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"?

Re: Announcing TypeScript 0.9.1

#110

I haven't heard much about TypeScript since its original announce. Are any big projects using it? Does anybody have some commentary on their experience using it and where they think the project is going?

To anyone wondering, every site that was linked to as response to the parent comment was built with ASP.NET.
Post reply on HN