Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fabrice Bellard Releases MicroQuickJS

github.com

Post reply on HN
Print view View original

411–420 of 594 posts

Re: Fabrice Bellard Releases MicroQuickJS

#411

Post by lpribis »

vanviegen wrote: post #403
norir wrote: post #178

Earlier quoted context omitted.

I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…

I do not think your compiler argument in support of TCO is very convincing. Do you really need to write compilers with limitless nesting? Or is nesting, say, 100.000 deep enough, perhaps? Also, you'll usually want to allocate some data structure to create an AST for each level. So that means you'll have some finite limit anyway. And that limit is a lot easier to hit in the real world, as it applies not just to nestin…

TCO is not just for parse trees or AST, but in imperative languages without TCO this is the only place you are "forced" to use recursion. You can transform any loop in you program to recursion if you prefer, which is what the author does.

Re: Fabrice Bellard Releases MicroQuickJS

#412

Post by anthk »

zem wrote: post #183
cosmic_cheese wrote: post #97

Earlier quoted context omitted.

Lots of comments talking about how existing browsers can already do this, but the big benefit that current browsers can't give you is the sheer level of speed and efficiency that a highly restricted "lite web" browser could achieve, especially if the restrictions are made with efficiency in mind. The embedded use case is obvious, but it'd also be excellent for things like documentation — with such a browser you could…

someone should embed it into dillo!

Better not. It already exists former QuickJS and QuickJS-NG, and parsing JS is a no light task by any means. Even Edbrowse https://github.com/cmb/edbrowse can grind down to a halt an n270 netbook becaus of some sites with JS (both with qjs and qjs-ng). So Dillo would be no better.

Also, legacy machines couldn't run it as fast as they could.

Re: Fabrice Bellard Releases MicroQuickJS

#413

Post by anthk »

exasperaited wrote: post #299
AtlasBarfed wrote: post #151

Earlier quoted context omitted.

I think we can do better than a 15x15 text window

WML/WAP got a bad rap I think, largely because of the way it was developed and imposed/introduced. But it was not insane, and it represented a clarity of thought that then went missing for decades. Several things that were in WML are quite reminiscent of interactions designed in web components today.

Gopher today (and even more Gemini) can do almost anything Wap did but without being a dead platform.

Re: Fabrice Bellard Releases MicroQuickJS

#414

Post by znpy »

norir wrote: post #178
antirez wrote: post #111

If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the language ones... (small, fast, ANSI-C). I appreciate certain ideas in Lua, and people love it, but I was never able to like Lua, because it departs from a more Algol-like syntax and semantics without good reasons, for my taste. This creates friction for newcom…

I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…

No offence but it seems that all of the people that are replying to this comment are essentially screaming in the void, if anything among each other.

I scrolled most of this sub thread and gp seem to not be replying to any of the replies they got.

Re: Fabrice Bellard Releases MicroQuickJS

#415

Post by wartywhoa23 »

TheTaytay wrote: post #368
simonw wrote: post #67

Earlier quoted context omitted.

Down to -4. Is this generic LLM-dislike, or a reaction to perceived over-self-promotion, or something else? No matter how much you hate LLM stuff I think it's useful to know that there's a working proof of concept of this library compiled to WASM and working as a Python library. I didn't plan to share this on HN but then MicroQuickJS showed up on the homepage so I figured people might find it useful. (If I hadn't dis…

I was hoping you experimented with this! I am right there with you, hoping for an easier wasm sandbox for LLMs. (Keep posting please. Downvotes due to mentioning LLMs will be perceived as a quaint historic artifact in the not so distant future…)

On the contrary, it's pretty possible that LLMs themselves will be perceied as a quaint historic artefact and join the ranks of mechanical turks, zeppelins, segways, google glasses and blockchains.

Re: Fabrice Bellard Releases MicroQuickJS

#416

Post by StopDisinfo910 »

deafpolygon wrote: post #404
MisterTea wrote: post #68

Earlier quoted context omitted.

Claude is really Bellard sitting in his kitchen, sipping coffee, casually replying to code requests while getting ready for his day.

Is Bellard the “Chuck Norris” of Programming?

He is extremely productive in its specialty: the intersection of programming language and system programming. I don't think that makes him superhuman.

It's more a model of what a really talented person who applies themselves building things they enjoy building can do.

I prefer thinking of it this way: if Bellard can make a small JS engine from scratch by himself, what's really stoping you from knocking down this library you are thinking about.

Re: Fabrice Bellard Releases MicroQuickJS

#417

Post by dualogy »

nine_k wrote: post #149
cxr wrote: post #133

Earlier quoted context omitted.

It wouldn't fix the issue of semantics, but "language skins"[1][2] are an underexplored area of programming language development. People go through all this effort to separate parsing and lexing, but never exploit the ability to just plug in a different lexer that allows for e.g. "{" and "}" tokens instead of "then" and "end", or vice versa. 1. https://hn.algolia.com/?type=comment&prefix=true&query=cxr%2... > 2. http…

Not "never exploit"; Reason and BuckleScript are examples of different "language skins" for OCaml. The problem with "skins" is that they create variety where people strive for uniformity to lower the cognitive load. OTOH transparent switching between skins (about as easy as changing the tab sizes) would alleviate that.

> transparent switching between skins (about as easy as changing the tab sizes)

One of my pet "not today but some day" project ideas. In my case, I wanted to give Python/Gdscript syntax to any & all the curly languages (a potential boon to all users of non-Anglo keyboard layouts), one by one, via VSCode extension that implements a virtual filesystem over the real one which translates back & forth the syntaxes during the load/edit/save cycle. Then the whole live LSP background running for the underlying real source files and resurfacing that in the same extension with line-number matchings etc.

Anyone, please steal this idea and run with it, I'm too short on time for it for now =)

Re: Fabrice Bellard Releases MicroQuickJS

#418

Post by cryptonector »

userbinator wrote: post #185
rasz wrote: post #175

Earlier quoted context omitted.

Funny how people know Fabrice for all the software stuff but none of the hardware antics: played with implementing analog modem DSP in software in 1999 (linmodem is ~50-80% there, sadly never finished) probably leading to played with implementing SDR (again DSP) using VGA output to transmit DVB-T/NTSC/PAL in 2005 probably leading to Amarisoft SDR 5G base station, commercial product started in 2012 - his current job h…

I was going to mention the last one, and his ASN.1 compiler which is likely related to his telco work: https://bellard.org/ffasn1/

As a maintainer of an ASN.1 compiler, I think his ASN.1 compiler must be quite awesome (it's not open source), and it's brilliant of him to make it proprietary. I bet he makes good money from it.

Re: Fabrice Bellard Releases MicroQuickJS

#419

Post by rwmj »

rapind wrote: post #263
brabel wrote: post #157

Earlier quoted context omitted.

> it feels like it departs from what people know without good reasons. Lua was first released in 1993. I think that it's pretty conventional for the time, though yeah it did not follow Algol syntax but Pascal's and Ada's (which were more popular in Brazil at the time than C, which is why that is the case)! Ruby, which appeared just 2 years later, departs a lot more, arguably without good reasons either? Perl, which i…

> Ruby, which appeared just 2 years later, departs a lot more, arguably without good reasons either? I doubt we ever would have heard about Ruby without it's syntax decisions. From my understanding it's entire raison d'être was readability.

It's essentially Perl for people who don't like punctuation marks.

Re: Fabrice Bellard Releases MicroQuickJS

#420

Post by mananaysiempre »

teo_zero wrote: post #325
mananaysiempre wrote: post #318

Earlier quoted context omitted.

You’re wrong in the way in which many people are wrong when they hear about a thing called “tail-call optimization ”, which is why some people have been trying to get away from the term in favour of “proper tail calls” or something similar, at least as far as R5RS[1]: > A Scheme implementation is properly tail-recursive if it supports an unbounded number of active tail calls. The issue here is that, in every language…

Thank you for the precise answer. I still think that the language property (or requirement, or behavior as seen by within the language itself) that we're talking about in this case is "unbounded nested calls" and that the language specs doesn't (shouldn't) assume that such property will be satisfied in a specific way, e.g. switching the call to a branch, as TCO usually means.

Unbounded nested calls as long as those calls are in tail position, which is a thing that needs to be defined—trivially, as `return EXPR(EXPR...)`, in Lua; while Scheme, being based around expressions, needs a more careful definition, see link above.

Otherwise yes. For instance, Scheme implementations that translate the Scheme program into portable C code (not just into bytecode interpreted by C code) cannot assume that the C compiler will translate C-level tail calls into jumps and thus take special measures to make them work correctly, from trampolines to the very confusingly named “Cheney on the M.T.A.”[1], and people will, colloquially, say those implementations do TCO too. Whether that’s correct usage... I don’t think really matters here, other than to demonstrate why the term “TCO” as encountered in the wild is a confusing one.

[1] https://www.plover.com/misc/hbaker-archive/CheneyMTA.html

Post reply on HN