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

211–220 of 594 posts

Re: Fabrice Bellard Releases MicroQuickJS

#211

Post by idle_zealot »

krackers wrote: post #180
idle_zealot wrote: post #150

Earlier quoted context omitted.

Does it count as 0-indexing when your 0 is a floating point number?

Actually in JS array indexing is same as property indexing right? So it's actually looking up the string '0', as in arr['0']

Huh. I always thought that JS objects supported string and number keys separately, like lua. Nope!

  [Documents]$ cat test.js
  let testArray = [];
  testArray[0] = "foo";
  testArray["0"] = "bar";
  console.log(testArray[0]);
  console.log(testArray["0"]);
  [Documents]$ jsc test.js
  bar bar
  [Documents]$

Re: Fabrice Bellard Releases MicroQuickJS

#212

Post by andrewshadura »

rwmj wrote: post #168
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…

Out of interest, was Tcl considered? It's the original embeddable language.

Wasn't the original Redis prototype written in Tcl?

Re: Fabrice Bellard Releases MicroQuickJS

#213

Post by hn_throwaway_99 »

lacedeconstruct wrote: post #9
booi wrote: post #4

If there were a software engineering hall of fame, I nominate Fabrice.

rare occasion where he gained a legendary status based purely on his work, I dont think I ever saw even a written interview with the guy

I think this is such an important point. I know all about Bellard's main works. I actually have no idea what he looks like, I've also never seen an interview with him, and I've never read about his specific philosophies when it comes to different software engineering topics. In a world of never-ending bloviations from "influencers" and "thought leaders" it's so awesome to see a real example of true excellence.

Re: Fabrice Bellard Releases MicroQuickJS

#214

Post by procaryote »

cxr wrote: post #133
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…

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…

Lowering the barrier to create your own syntax seems like a bad thing though. C.f. perl.

Re: Fabrice Bellard Releases MicroQuickJS

#215

Post by rao-v »

cxr wrote: post #133
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…

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…

One day Brython (python with braces allowing copy paste code to autoindent) will be well supported by LSPs and world peace will ensure

Re: Fabrice Bellard Releases MicroQuickJS

#216

Post by 1313ed01 »

alcover wrote: post #5

I wish for this new year we reboot the Web with a super light standard and accompanying ecosystem with - A small and efficient JS subset, HTML, CSS - A family of very simple browsers that do just that - A new Web that adheres to the above That would make my year.

Not likely to happen. There is geminiprotocol with gemtext though for those of us that are fine with that level of simplicity.

Work towards an eventual feature freeze and final standardisation of the web would be fantastic though, and a huge benefit to pretty much everyone other than maybe the Chrome developers.

Re: Fabrice Bellard Releases MicroQuickJS

#217

Post by kvemkon »

nine_k wrote: post #206
kvemkon wrote: post #202

Earlier quoted context omitted.

Yes, that's why I've asked about possible rust support of creating such version of normal project. The main issue, I'm unaware of comparably large rust projects without 3rdparty dependencies.

From my daily-use utilities, ripgrep and bat seem to have zero dependencies.

Looking at Cargo.toml, ripgrep seems to have some dependencies and bat has a lot.

Re: Fabrice Bellard Releases MicroQuickJS

#218

Post by uecker »

antirez wrote: post #126
zdragnar wrote: post #120

Earlier quoted context omitted.

I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is. I've had the inverse experience dealing with a many thousand line "core.php" file way back in the day helping debug an expressionengine site (back in the php 5.2ish days) and it was awful . Unless you have an editor which can create short links in a hierarchical tree from semantic comments to let you o…

C has no problems splitting programs in N files, to be honest. The reason FB (and myself, for what it is worth) often write single file large programs (Redis was split after N years of being a single file) is because with enough programming experience you know one very simple thing: complexity is not about how many files you have, but about the internal structure and conceptually separated modules boundaries. At some…

I split to enforce encapsulation by defining interfaces in headers based on incomplete structure types. So it helps me with he conceptually separated module boundaries. Super fast compilation is another benefit.

Re: Fabrice Bellard Releases MicroQuickJS

#219

Post by spacechild1 »

lucketone wrote: post #201
spacechild1 wrote: post #177

Earlier quoted context omitted.

> it feels like it departs from what people know without good reasons. Lua is a pretty old language. In 1993 the world had not really settled on C style syntax. Compared to Perl or Tcl, Lua's syntax seems rather conventional. Some design decisions might be a bit unusual, but overall the language feels very consistent and predictable. JS is a mess in comparison. > because it departs from a more Algol-like syntax Huh?…

I known for very long time that c (and co) inherited the syntax from algol. But only after long time I tried to check what Algol actually looked like. To my surprise, Algol does not look anything like C to me. I would be quite interested in the expanded version of “C has inherited syntax from Algol” Edit: apparently the inheritance from Algol is a formula: lexical scoping + value returning functions (expression based…

The use of curly braces for delimiting blocks of code actually comes from BCPL.

Of course, C also inherited syntax from Algol, but so did most languages.

Re: Fabrice Bellard Releases MicroQuickJS

#220

Post by stellartux »

xonix wrote: post #208
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…

Re: TCO Does the language give any guarantee that TCO was applied? In other words can it give you an error that the recursion is not of tail call form? Because I imagine a probability of writing a recursion and relying on it being TCO-optimized, where it's not. I would prefer if a language had some form of explicit TCO modifier for a function. Is there any language that has this?

Sounds a bit like Clojure's "recur". https://clojuredocs.org/clojure.core/recur
Post reply on HN