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*.
Announcing TypeScript 0.9.1
101–110 of 116 posts
Re: Announcing TypeScript 0.9.1
#102Earlier 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.
Re: Announcing TypeScript 0.9.1
#103Earlier 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.
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
#104I 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…
"What's true of all bugs? They passed a type checker and they passed the tests!" - Rich Hickey
Re: Announcing TypeScript 0.9.1
#105I 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
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
#106Earlier 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…
Re: Announcing TypeScript 0.9.1
#107Earlier 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…
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
#108I 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
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
#109Earlier 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/~…
Re: Announcing TypeScript 0.9.1
#110I 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?