xuejie's comments

I totally agree that it's not the best tech always wins, that's why I'm pointing it out, I really wish that 5 years from now, we can rely on something that makes sense to be there, not just because something has a low cost of adoption.

While I do agree WASM makes a lot of sense for the Web, I personally am having doubts regarding treating WASM as a general abstractions for native code as used in the post. For this case, it might suit the job better to have a bytecode that resembles more of underlying machine architecture, rather than a still highly abstracted model like WASM. Please don't get me wrong, I do agree WASM is already one step ahead of, say, JavaScript, but we can do better than that.

The problem with WASM here, is that it really is a bloated model like JVM in its early days, huge amount of work is needed to make it closer to native speed, which is contradictory to the original slogan. What's more, people are still planning to add tons of new features to it: https://webassembly.org/docs/future-features/. Before you tell me those are opt-in features, the question I want to raise is: for an abstraction of general platform, you would definitely want to have a widely accepted standard so people know what features will be expected, one example is that people know SSE will be available for 64-bit x86 code.

With all those opt-in features, I doubt if we can have a proper layer that adapts well to different implementations with different supported features. We might end up with the situation like Rust, where you can claim a secondary compiler could exist, but in practice people are all using the same compiler/implementation.

Any chance you can elaborate the reasons for staying away from Intel syntax?

This is indeed amazing! But I was wondering if it's possible to compile the whole TeXmacs into WebAssembly and have it in the browser. That will be a totally different world.

This is really depending on your view, but the moment you step outside of lists and use arrays, you are keeping modern CPU architecture in mind. And all of a sudden all those wonder car/cdr/cons concepts as well as things built upon it no longer holds, which, again depending on the view, actually harms the abstractions in Lisp, and we are actually back at the same page with all the other programming languages.

Also, when you are promoting something, it might not a good idea to compare against Python when it comes to speed, but when talking maintainability, only C is talking as a target here.

Although I do agree data flow programming can be useful sometimes, it has been pointed out that data oriented design is not about data flow: https://sites.google.com/site/macton/home/onwhydodisntamodel...

And taking from the other side of the view, even when you consider high performance data flow programming, there're great people pointing out going functional might not be a very good idea: https://www.freelists.org/post/luajit/Ramblings-on-languages...

> about 20x+ faster than Python, too; speed in the same order of magnitude than C.

I think this is exactly into parent thread's point: yes the performance can be great but you need to tail the code for the hardware, which is niche and the beautiful abstraction might never hold anymore

Nightly Rust already has basic RISC-V support, but the problem is Rust's libc binding is not yet ported to RISC-V. Without libc, Rust's std will not be usable, that's the main blocker here. While the theory is you don't require std to compile a Rust program, most, if not all, Rust programs leverage std in some extent.

I'm confused here, Quill has a a very nice OT solution built-in to solve collaborative issue: https://github.com/quilljs/delta

Why not leverage that solution than just saying OT is incorrect and roll out a rudimentary solution? CRDT is not something easier, OT and CRDT are just 2 different beasts with different trade-offs.

I'm not sure AAA games have more depth and complexity. Usually, modern AAA games are just optimized for more polygons, yes there are minor outliers but I do believe business card games can have a fight in terms of complexity with a significant number of AAA games.

Thanks for the explanation! One follow-up question is: how can we still call ignition an interpreter with this flow where TurboFan is still used to generate machine code? Doesn't that defunct the idea of an interpreter in v8, which is to be used in platforms w/o write access to executable memory, such as iOS or PS4?

Agreed, and I'm not saying duktape doesn't have a use case, I'm merely saying having a standalone ignition interpreter might enable different use cases.

Definitely agree duktape is a decent attempt at low memory situation, but one additional point is that duktape is very slow compared to modern JavaScript engines.

Hence I wonder if we can split ignition off v8 to create a standalone fast JavaScript interpreter at the cost of (possibly) more memory consumptions than duktape, that could prove to be useful in many scenarios.

This is exactly what I thought as well. Julia is born for this use case.

Interestingly, the platform design of ProseMirror is one of the key reason which drives me to Quill in one of my side projects. Don't get me wrong, if your goals mostly align with ProseMirror, it's a perfect tool, but if you want to deviate with ProseMirror in some aspects, the coupling design between different ProseMirror packages is actually a headache. On the other hand, Quill feels more like a simple library targeting exactly one use case.

In addition, I feel that Quill's delta format [1] is much more elegant and easier to work with than ProseMirror's changeset [2], especially if your architecture uses a different language that's not JS.

[1]: https://quilljs.com/docs/delta/ [2]: https://github.com/ProseMirror/prosemirror-changeset

I believe this is CodeMirror [1], not monaco.

[1] https://codemirror.net/

I'm in a similar situation: I used to use a 2016 macbook pro with touchbar, but couldn't tolerate more with it, so I switched to a 13' macbook air(while I can still buy this device) earlier this year. I couldn't be more happier.

One thing I disagree with the author, is that I don't think this is downgrade, I consider this is an upgrade, cuz there's more in a computer than just the spec.

Tho I'm not sure what I will use in 3 years, there might not be trustworthy macbook air anymore then.

Just curious: other than established convention, is there anything that Sly/Slime provide that are still missing in Language Server Protocol(https://langserver.org/)? Would it benefit more to move to a lsp-based solution so we can make Common Lisp more modern-editor friendly?

I wish Microsoft could make a new edx course in their series covering TLA+. Those lectures are gonna be more helpful with exercises one can get his/her hands dirty.

Curious if we're gonna have a complete redesigned virtual machine without considering C-like conventions, how do you think we should do that?

I've heard about alternative CPU architectures in the Lisp machine days that never gone popular, and just wonder if there're such things in the modern era.