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

Emacs-ng: Emacs with Deno runtime and TypeScript

github.com

Post reply on HN
Print view View original

51–60 of 154 posts

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#51

Post by dleslie »

JasonFruit wrote: post #18

The Emacs community, like the Lisp community with which it overlaps, is very conservative, in the sense that it doesn't throw things away quickly or make huge changes lightly. For that reason, I'd be very surprised if this took off — even though it sounds like it would be mostly backwards-compatible. I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more la…

And let's not overlook that it doesn't make elisp any faster. This isn't going to have a performance improvement for those who use elisp regularly for productive reasons.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#52

Post by dleslie »

cle wrote: post #45
janoc wrote: post #26

Earlier quoted context omitted.

Well, basically this is someone trying to implement VSCode in Emacs ... Ain't gonna get far once the main developer loses interest in the project. Emacs users use Emacs because they want Lisp and don't care about web rendering and javascript runtimes ... Oh yeah and Rust is thrown in too for good measure. Good 90% of Emacs code is in the extensions which are in Lisp and nobody is going to rewrite them to Javascript e…

This doesn't require rewriting extensions, it is backwards compatible.

It does not improve elisp performance, however. So it's pointless for those who use and rely on elisp.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#53

Post by dleslie »

eddieh wrote: post #44
vitus wrote: post #9

Earlier quoted context omitted.

EDIT: as pointed out, this is run with Guile 2.2, which is pre-JIT. Results to be posted later in this thread... Okay. $ cat fib.scm (define (fibonacci n) (if ( Node also uses V8. $ time node fib.js node fib.js 1.29s user 0.01s system 100% cpu 1.296 total But okay, you wanted deno. $ time deno run fib.js deno run fib.js 1.41s user 0.02s system 99% cpu 1.423 total Meanwhile, using `emacs --script fib.elc` to evaluate…

This got me curious about other Scheme implementations. Chicken compiles to C $ csc fib.scm $ time ./fib real 0m8.461s user 0m8.383s sys 0m0.061s Racket has a modern JIT $ cat fib.rkt #lang racket (define (fibonacci n) (if ( For reference $ sysctl -a | grep .brand_string machdep.cpu.brand_string: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz

Chicken's default is fairly unoptimized; try higher optimization levels.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#54

Post by dleslie »

bitwize wrote: post #4

I personally look forward to the day when every program I run embeds JavaScript and an HTML engine in it. Then we will be living in an age of true modernity in software development. Systemd-ng, anyone?

You're not thinking modern enough; what we need is uboot-ng!

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#55

Post by bitwize »

JasonFruit wrote: post #18

The Emacs community, like the Lisp community with which it overlaps, is very conservative, in the sense that it doesn't throw things away quickly or make huge changes lightly. For that reason, I'd be very surprised if this took off — even though it sounds like it would be mostly backwards-compatible. I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more la…

> I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more layers of abstraction to understand and maintain, and splitting the extensions between Emacs Lisp and JavaScript. I'm also not convinced that a significant part of the community really wants this.

I'm reminded of when an old C hand tells me that Rust will never replace C because it's too complex, brittle, and frustrating for the kinds of applications C programmers use C for. I always tell them: Rust isn't aimed at you -- it's aimed at your replacement.

The Emacs-ng team doesn't have to convince the Emacs community -- they only have to convince their replacements. Much of computing in the very near future will be built on two languages: Rust and JavaScript. By basing Emacs-ng on those two languages, they just opened Emacs up to extension and hacking by a huge community who have no interest in touching Emacs's ancient, doddering Lisp nor its C underpinnings (C being, inherently, unsafe at any speed to work in). So ugly as it is, from a social standpoint it's absolutely the right approach and may well overtake GNU Emacs in terms of ecosystem size and vibrancy by the late 2020s.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#58

Post by eddieh »

dleslie wrote: post #53
eddieh wrote: post #44

Earlier quoted context omitted.

This got me curious about other Scheme implementations. Chicken compiles to C $ csc fib.scm $ time ./fib real 0m8.461s user 0m8.383s sys 0m0.061s Racket has a modern JIT $ cat fib.rkt #lang racket (define (fibonacci n) (if ( For reference $ sysctl -a | grep .brand_string machdep.cpu.brand_string: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz

Chicken's default is fairly unoptimized; try higher optimization levels.

Oh dang...you're right

    $ csc -optimize-level 5 fib.scm 
    $ time ./fib

    real 0m5.506s
    user 0m5.489s
    sys  0m0.010s
I could get a few fractions of a second better playing with the stack size (4 MB was the best, 8 MB or above would segfault)

    $ csc -optimize-level 5 -stack-size 4m fib.scm 
    $ time ./fib

    real 0m5.295s
    user 0m5.277s
    sys  0m0.011s
Everything else was negligible or extremely varied.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#59

Post by eddieh »

taeric wrote: post #50
eddieh wrote: post #44

Earlier quoted context omitted.

This got me curious about other Scheme implementations. Chicken compiles to C $ csc fib.scm $ time ./fib real 0m8.461s user 0m8.383s sys 0m0.061s Racket has a modern JIT $ cat fib.rkt #lang racket (define (fibonacci n) (if ( For reference $ sysctl -a | grep .brand_string machdep.cpu.brand_string: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz

This got me interested in other lisps, as well. Looks like sbcl gives (time (fib 40)) to be about 1.7 seconds on my machine. (Ryzen 5 3600x.) For lulz, I clocked a dumb loop version. (defun fib (n) (loop repeat n for a = 1 then b for b = 1 then c for c = (+ a b) finally (return a))) And... well, serves as an amusing reminder that tree recursion has its downsides. :D Edit: I confess the speed of the loop got me curiou…

Try BigInt in JS https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#60

Post by bitwize »

skissane wrote: post #31
toomim wrote: post #29

I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". It has weird keyboard shortcuts. Every third command also copies to the clipboard as a side-effect, which means you constantly oblitera…

> But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". Using "buffer" as a name for text being edited is hardly worthy of the title weird , vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. The…

> Using "buffer" as a name for text being edited is hardly worthy of the title weird, vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. Their contents may differ, and one may exist without the other.

It doesn't matter. When people talk of editing documents in Word, they speak of opening a file, not a buffer. That's the metaphor people are used to. It may not make sense, but saying "well, ackshually, files refer to the copies on disk while buffers refer to the copies in memory" just confuses people more. Have we learned nothing since Macintosh 1984? Actually, we haven't; we've gone backwards. The spatial Finder was based on very deep psychological notions of how humans relate to the world: through spatial orientation and object manipulation. Meaning that there is only one place on the screen where a given file appears, and it appears at the same place every time unless the user moves it. In short, it works like an actual desktop with real physical pieces of paper. And Apple brushed it aside in favor of NeXT's Unixoid "file manager".

> Likewise, calling the subdivisions of the screen "windows" is something which vim does too, and likely other editors also. For a text mode editor, it makes perfect sense. When you then port such an editor to a GUI, you end up with "windows" which are subdivisions of the GUI "window" – vim has that too, not just emacs.

Again, it doesn't matter. The ordinary user's concept of a "window" maps directly to a GUI window, so if you expect your program to be used in a graphical environment without confusing the shit out of people, you need to adopt that environment's terms and concepts.

Meet. Your. Users. Where. They. Are.

Post reply on HN