Typically, C and C superset (e.g. C++ and Objective-C) applications either:
Use a few well-understood (e.g. GTK+, ncurses, zlib, et al.) dependencies. The requirements range from requiring (#include <dependency>) and linking to CMake magic.
Use monolithic frameworks (e.g. Boost, Cocoa, Unreal Engine, et al.). They mask most of the complexity from the programmer.
In the Haxe community I’ve seen a few efforts to generate strictly typed extern/proxy definitions from loosely typed Javascript modules [1] or from typescript definitions [2].
I guess this tool fits a different niche - rather than trying to add type information to a dynamically typed library, you write your library in something with strong type info (Typescript, Haxe) and then can compile down to JS, or share type information with other languages. An interesting approach, though it would be good if it was more automated, having to write your description manually is something I might not always bother with. (At least for Haxe you could generate this automatically at build time, using macros).
(Side note: I think this is the first time I’ve clicked on a link from a site like this and the example code has been in Haxe. Then I realized it was Prezi - those guys are using Haxe at a scale not many other companies are so it doesn’t surprise me to see them tackling difficult issues like this.)
i’m excited about the fact that spaghetti could help statically-typed js core libraries take off, and be seamlessly adopted by languages and frameworks that use more dynamic types.
This is a tough problem.
JavaScript is very much like C nowadays (correct me if im wrong, my CS history knowledge is lacking)
How did C programmers solve this problem? (With mixing modules from compile-to-c languages)
We didn’t. It’s very similar to JavaScript.
Typically, C and C superset (e.g. C++ and Objective-C) applications either:
Use a few well-understood (e.g. GTK+, ncurses, zlib, et al.) dependencies. The requirements range from requiring (
#include <dependency>) and linking to CMake magic.Use monolithic frameworks (e.g. Boost, Cocoa, Unreal Engine, et al.). They mask most of the complexity from the programmer.
In the Haxe community I’ve seen a few efforts to generate strictly typed extern/proxy definitions from loosely typed Javascript modules [1] or from typescript definitions [2].
I guess this tool fits a different niche - rather than trying to add type information to a dynamically typed library, you write your library in something with strong type info (Typescript, Haxe) and then can compile down to JS, or share type information with other languages. An interesting approach, though it would be good if it was more automated, having to write your description manually is something I might not always bother with. (At least for Haxe you could generate this automatically at build time, using macros).
(Side note: I think this is the first time I’ve clicked on a link from a site like this and the example code has been in Haxe. Then I realized it was Prezi - those guys are using Haxe at a scale not many other companies are so it doesn’t surprise me to see them tackling difficult issues like this.)
[1] https://github.com/jdonaldson/jsdoc3-hxtern [2] https://github.com/Simn/ts2hx
they’ve also hired the developer of elm, and are continuing to support it as an open source project: http://engineering.prezi.com/blog/2013/05/21/elm-at-prezi/
i’m excited about the fact that spaghetti could help statically-typed js core libraries take off, and be seamlessly adopted by languages and frameworks that use more dynamic types.