janpaul123

10 ms·

61.
by janpaul123 5y ago
Nectarjs is interesting; I wasn't aware of that. How did it manage to avoid (for example) a garbage collector without making changes to the language?
62.
by janpaul123 5y ago
You didn't see my face when I wrote that ;)
63.
by janpaul123 5y ago
Yeah I meant speed of execution. Sorry for the letdown! But https://github.com/swc-project/swc is a very fast Typescript compiler written in Rust :)
64.
by janpaul123 5y ago
Ah yes; I did see that but forgot to mention it: https://makecode.com/language
65.
by janpaul123 5y ago
Tnx; fixing!
66.
by janpaul123 5y ago
Yep, but it doesn't really solve any of the problems that I mention in the article, unfortunately. The Typescript familiarity part is nice, but it doesn't really work well with existing code; you still have to set up Wasm-JS commu
67.
by janpaul123 5y ago
Yep, but it doesn't really solve any of the problems that I mention in the article, unfortunately.
68.
by janpaul123 5y ago
Yeah I hear you; and even allude to that in some parts of the article, like this part: > Another idea to make Typescript–– a bit less restrictive and more ergonomic, would be to use reference-counting of objects, and then try to optimize
69.
by janpaul123 5y ago
Good points. I agree that choosing the abstractions wisely is key here.
70.
by janpaul123 5y ago
Good feedback; I should add a TL;DR. Basically this is a proposal to create a language that sits somewhere between Typescript and Rust, and which you can incrementally adopt if you already use Typescript.
71.
by janpaul123 5y ago
The overhead of going to JS from Wasm these days is very small, and the DOM is relatively slow. So doing DOM operations from Wasm is not much different than from JS; the vast majority of the time is spent in the actual DOM API calls.
72.
by janpaul123 5y ago
Hah, cool! I agree that for your use case V8 makes more sense :)
73.
by janpaul123 5y ago
I agree; that is what we built the Zaplib framework for. But the reality is that there are tons and tons of existing JS/TS codebases out there, and it'd be nice to have an incremental speedup path for them too.
74.
by janpaul123 5y ago
Hi! Author here. Really curious what you all think. It's a pretty crazy idea but maybe there's something to it! Hacker News is always a special place for ideas like this — you never know what you're gonna get ;) — so I'm
75.
TypeScript as fast as Rust: TypeScript++(zaplib.com)
280 points by janpaul123 5y ago|113 comments
76.
How Simulations Work(anuncommonlab.com)
4 points by janpaul123 6y ago|0 comments
77.
by janpaul123 7y ago
> Their UI looks incredibly sexy Are you talking about the GIFs in that article? I work on that tool, and just in case you're interested, it's open source, so you can play with it yourself: https://webviz.io :)
78.
by janpaul123 9y ago
Also, Dynamicland uses Realtalk, a programming language / operating system / protocol for physical computing that is more general than projectors/cameras/papers.
79.
by janpaul123 9y ago
If you write small programs that interact with other programs, then rearranging them on the floor/table becomes a form of programming (similar to how combining UNIX-style programs in shell scripts is a high-level form of programming).
80.
by janpaul123 9y ago
Yeah, exactly what you said. I work on software for public transit agencies, and Dynamicland immediately made me think of a workshop that Jarrett Walker (humantransit.org) sometimes runs, which involves physical paper and pieces of coloured
81.
by janpaul123 9y ago
Hi! I was asked to repost this (a la https://news.ycombinator.com/item?id=11662380 ), so here goes. I'm JP, and I created this project after visiting Dynamicland a couple of times. I wanted to capture some of the magic
82.
Show HN: Paper Programs – Run JavaScript on pieces of paper(paperprograms.org)
235 points by janpaul123 9y ago|52 comments
83.
Show HN: Paper Programs – run JavaScript on pieces of paper(paperprograms.org)
17 points by janpaul123 9y ago|1 comments
84.
by janpaul123 9y ago
Remix (YC W15) | Design, backend, frontend, full-stack, algorithm engineers, PMs, etc | San Francisco | ONSITE, VISA, FULL-TIME Join us in building a real-life SimCity. Today, cities use pen and paper to make planning decisions that affect
85.
by janpaul123 9y ago
Remix (YC W15) | Backend, frontend, full-stack, algorithm engineers, PM, design, and more | San Francisco | ONSITE, VISA, FULL-TIME Join us in building a real-life SimCity. Today, cities use pen and paper to make planning decisions that aff
86.
by janpaul123 9y ago
Remix (YC W15) | Backend, frontend, full-stack, algorithm engineers, PM, design, and more | San Francisco | ONSITE, VISA, FULL-TIME Join us in building a real-life SimCity. Today, cities use pen and paper to make planning decisions that aff
87.
by janpaul123 9y ago
Remix (YC W15) | Backend, frontend, full-stack, algorithm engineers, and more | San Francisco | ONSITE, VISA Join us in building a real-life SimCity. Today, cities use pen and paper to make planning decisions that affect millions of people&
88.
by janpaul123 9y ago
Remix (YC W15) | Backend, frontend, full-stack, algorithm engineers, and more | San Francisco | ONSITE, VISA Join us in building a real-life SimCity. Today, cities use pen and paper to make planning decisions that affect millions of people&
89.
by janpaul123 9y ago
Remix (YC W15) | Backend, full-stack, algorithm engineers, and more | San Francisco | ONSITE, VISA Join us in building a real-life SimCity. Today, cities use pen and paper to make planning decisions that affect millions of people's liv
90.
by janpaul123 9y ago
Remix (YC W15) | Backend, full-stack, algorithm engineers, and more | San Francisco | ONSITE, VISA Join us in building a real-life SimCity. Today, cities use pen and paper to make planning decisions that affect millions of people's liv

More ›