Earlier quoted context omitted.
I had been thinking that WebAssembly or CLR could be the target for TypeScript and that would allow to bring her own base class libraries etc. But if you look closely again, the beaut & wide adoption of TS is because it has no "runtime" or no extra libraries or APIs to learn. Its the JS. This also makes it easy to iterate quickly on Type System and bring new features. Having its own runtime means, that wouldn't be ea…
Interesting referencing a programming language as a feminine article like that... Not saying it's wrong, just unusual to me.
Show HN: A SQL database implemented purely in TypeScript type annotations
181–190 of 196 posts
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#182 void main()
{
import std.algorithm, std.conv, std.stdio;
"Starting program".writeln;
// Sort a constant declaration at Compile-Time
enum a = [ 3, 1, 2, 4, 0 ];
static immutable b = sort(a);
// Print the result _during_ compilation
pragma(msg, text("Finished compilation: ", b));
}
It can also reflect at compile time on user-defined annotations, which can store arbitrary metadata on any symbol, to generate arbitrary code at compile time. They serve a similar role to procedural macros from Rust, but they're easier to use than the earlier. Thanks to mixin templates, you can inject arbitrary symbols, making D's UDAs just as flexible as Python's decorators.Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#183Earlier quoted context omitted.
Types do not need to have a one-to-one correspondence with runtime data structures and indeed in many type systems often do not. In the limit, a type does not need to have any runtime representation at all (this is more than just generic erasure or phantom type parameters, you can have an entire type signature that has absolutely no runtime representation of any of its parts). There is not really a fundamental differ…
A predicate is a computer program that accepts an input and returns "yes/no." A type system could be an arbitrary predicate which returns "well typed/not well typed" when given a term. But obviously there must be some difference between types and predicates, such as extensionality -- the type of an expression can be decided by examining the code alone.
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#184Earlier quoted context omitted.
generating types from a swagger spec? Graphql? Or any kind of schema? Look up fsharp type providers.
As far as I understand (and I might be wrong so please correct me), this can't be used to generate anything. Of course all the technologies you've listed are useful and brilliant but this isn't what I'm seeing. It's more of an experiment of thoughts to generate types that are defined by the result of the SQL query, bending a compiler to a new strange behaviour that happens to be SQL like.
If you think this is useless because it doesn't generate any code then I'm assuming you're not familiar with typescript because type level libraries isn't supposed to do do that anyway. There are already libraries that generate open api client and graphql client but they generate type definition via an extra build step which libraries like this can eliminate.
And this typescript feature was made to parse strings so no this is not "bending the compiler"
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#185That's pretty neat. What I really want is this: function fn(query:string){ const stuff = // do some stuff with `query` variable return createType(stuff); } type MyType = FromJS ; This way we could compute types on the fly with JavaScript instead of creating monstrous types in TypeScript types system.
wouldn't that be neat... However, there are Java frameworks that basically generate a type system from your database so whatever columns you query ends up being static types that can be determined at compile time. https://www.jooq.org/ Java is really quite cool. I wonder if we'll ever get a typescript version of jOOQ
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#186JavaScript is such a cool language, and I really love it, especially the FP subcommunity, but the AI community for Python is way bigger, I wish there were more options for neural nets, differentiable programming, and data frame type things in JS. The interoperability with WASM is hugely valuable, and so is the ability to easily publish results on the web. It feels like it’s way easier to make an AI system in python,…
Write the core AI code in Python because that's what's practical to do. Write the app code in JS because that's what's practical to do. Sell the product to customers that want to use it and probably don't care what's underneath.
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#187Earlier quoted context omitted.
Interesting referencing a programming language as a feminine article like that... Not saying it's wrong, just unusual to me.
People downvoting an observation on a curious use of language? If it's because of some perceived political motive, then that's really sad. I really did just wonder why anyone would anthropomorphize a programming language, by ascribing a gendered pronoun to it.
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#188Earlier quoted context omitted.
Thinking about this more. I think this project has some promising practical uses when combined with code generation from the typescript ast (which is what my project does). Since the type system can parse the SQL strings, then it becomes possible to include those strings as a source for the ast. Then the code generator can use the typescript parser to parse all the types and the sql. From that it can generate all the…
my thoughts as well. compile-time checked arbitrary sql would defeat the purpose of so many abominable ORMs. make it work with DDL instead of sample data and you've really got something nice!
Re: Show HN: A SQL database implemented purely in TypeScript type annotations
#189This shows how complex TypeSript has become. It may be fun to write complicated Type annotations such as this, but imagine having to read and maintain the code!