Xray – An experimental next-generation Electron-based text editor • Hacker News Board

Re: Xray – An experimental next-generation Electron-based text editor

#191

Post by saurik » Tue, Mar 06, 2018, 12:25 PM UTC

com2kid wrote: post #104

paulryanrogers wrote: post #81

Earlier quoted context omitted.

My rose-tinted glasses are cracked, so I don't want to go back. Software was a lot less capable back then. And APIs were often incredibly obtuse, bespoke, or both.

> Software was a lot less capable back then. Some was. WinAmp came out in 1997, 2.x was released in 1998. Real time streaming media. Visual Studio 6 came out in 1998, had most of Intellisense up and running. The refactoring stuff wasn't there yet, but it could do remote debugging. The Windows APIs were obtuse, but incredibly well documented. It'd take a long time before a lot of things we take for granted got commodi…

> It wouldn't have been hard to write a Slack competitor then. It wouldn't have had streaming video, and the client would have been native, but you could have gotten 80% of the functionality in there, and watched as people still complained it was just a fancy wrapper around IRC.

In 1998, I was using the Internet Explorer COM embeddable COM object to build an IRC client where all of the text rendering was handled by the HTML renderer ¯\_(ツ)_/¯. (The reason why is the same as the reason I'd do the same thing today: because fancy text layout in a native app has always sucked and still sucks :/.)

Re: Xray – An experimental next-generation Electron-based text editor

#192

Post by KozmoNau7 » Tue, Mar 06, 2018, 12:33 PM UTC

paulryanrogers wrote: post #81

zero_iq wrote: post #46

Earlier quoted context omitted.

I always think back to when I had a 120MB hard disk in the early 90s. It contained multiple editors, raytracers, games, music editors + music, images, paint programs, multiple programming languages and development kits, a multi-tasking operating system... and room to spare. 90s me would be absolutely floored by a text editor needing 438MB RAM. Wait, what am I saying? 2018 me is pretty flabbergasted by it, but perhaps…

My rose-tinted glasses are cracked, so I don't want to go back. Software was a lot less capable back then. And APIs were often incredibly obtuse, bespoke, or both.

Sometimes the lack of capability was a good thing, meaning less distractions and more focus on the core functionality.

The simplicity of Win3.11 and Win95 was great, and that isn't just rose tinted glasses speaking.

Re: Xray – An experimental next-generation Electron-based text editor

#193

Post by sushibowl » Tue, Mar 06, 2018, 12:34 PM UTC

pjmlp wrote: post #181

gr__or wrote: post #180

Earlier quoted context omitted.

To be charitable, I'm gonna interpret this as hyperbole. If you meant this as its written, it'd be an immensly ignorant statement. Almost by definition, there CAN always be a faster implementation in C++ but there are also more ways to shoot yourself in the foot (or as they saying with C++ goes, shoot your leg off).

A programming language where this compiles and maps to alert(1) , has nothing to say against C++. [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(!…

Spoken like someone who has never seen obfuscated/underhanded code contests. C++ can do fuckery that rivals higher level languages just because of the limitless hardware access and undefined behavior the language has.

Re: Xray – An experimental next-generation Electron-based text editor

#194

Post by KozmoNau7 » Tue, Mar 06, 2018, 12:40 PM UTC

TeMPOraL wrote: post #136

com2kid wrote: post #104

Earlier quoted context omitted.

> Software was a lot less capable back then. Some was. WinAmp came out in 1997, 2.x was released in 1998. Real time streaming media. Visual Studio 6 came out in 1998, had most of Intellisense up and running. The refactoring stuff wasn't there yet, but it could do remote debugging. The Windows APIs were obtuse, but incredibly well documented. It'd take a long time before a lot of things we take for granted got commodi…

> WinAmp came out in 1997, 2.x was released in 1998. Real time streaming media. Related to GP's "Software was a lot less capable back then." - somehow, WinAmp 2.x seems to be peak capability of music players; I don't recall any player made later that would be comparable in features for playing local music (with maybe the exception of Foobar2000). My rose-tinted glasses have some scratches on them, but I still maintai…

WinAMP 2.x was nothing short of a miracle, it was a revolution in audio players. I wasn't a huge fan of the skin-based interface, and the playlist did some odd things once in a while, but on the whole, it was a damn good piece of software.

These days I'm using Foobar2000 and Quod Libet, and have looked at other "music library" type apps, but I'm considering just going with a simple player such as DeaDBeeF, and handle everything else through the file manager, since I've taken the time to properly plan the folder layout. I don't need ratings or playback statistics or all kinds of other things. I need a simple playlist to add music to, with basic playback controls. If I need to add tracks, I'll drag and drop from the file manager.

Basically, I don't need in-between applications between simple WinAMP 2.x style and the all-singing all-dancing streaming services such as Spotify, that do a much superior job with ratings and especially smart playlists.

Re: Xray – An experimental next-generation Electron-based text editor

#195

Post by alphaalpha101 » Tue, Mar 06, 2018, 12:50 PM UTC

com2kid wrote: post #104

paulryanrogers wrote: post #81

Earlier quoted context omitted.

My rose-tinted glasses are cracked, so I don't want to go back. Software was a lot less capable back then. And APIs were often incredibly obtuse, bespoke, or both.

> Software was a lot less capable back then. Some was. WinAmp came out in 1997, 2.x was released in 1998. Real time streaming media. Visual Studio 6 came out in 1998, had most of Intellisense up and running. The refactoring stuff wasn't there yet, but it could do remote debugging. The Windows APIs were obtuse, but incredibly well documented. It'd take a long time before a lot of things we take for granted got commodi…

>Web forums sucked though. Slashdot figured out the right idea, the entire conversation loaded at once, one big page, it took the rest of the web a lot time to catch up.

Web forums were so much better than what we have today. I miss being active on multiple phpBB2 forums. Different communities, different norms. None of this everything-is-a-subreddit shit.

Re: Xray – An experimental next-generation Electron-based text editor

#196

Post by pjmlp » Tue, Mar 06, 2018, 12:53 PM UTC

sushibowl wrote: post #193

pjmlp wrote: post #181

Earlier quoted context omitted.

A programming language where this compiles and maps to alert(1) , has nothing to say against C++. [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(!…

Spoken like someone who has never seen obfuscated/underhanded code contests. C++ can do fuckery that rivals higher level languages just because of the limitless hardware access and undefined behavior the language has.

JavaScript WTF win hands down over C++.

Re: Xray – An experimental next-generation Electron-based text editor

#197

Post by flavio81 » Tue, Mar 06, 2018, 1:20 PM UTC

petre wrote: post #112

nine_k wrote: post #96

Earlier quoted context omitted.

The v8 engine behind Atom is an incredibly efficient compiler, a just-in-time compiler. Without it, all current JS interfaces would be comically slow. The problem with JS is that its execution model is built around highly dynamic features that are hard to compile efficiently. It also lacks a nice type system, though Typescript helps a lot. The problem with Atom performance, I suspect , is mostly with its using a web…

Most of them are slower. Luajit is the only dynamic language runtime that's faster than V8, at least at prime number crunching. I haven't tested elisp but the others (Perl, Ruby etc.) are an order of magnitude slower.

>Luajit is the only dynamic language runtime that's faster than V8,

Also Common Lisp (much faster than V8), Forth, and probably some Scheme implementations.

Re: Xray – An experimental next-generation Electron-based text editor

#198

Post by flavio81 » Tue, Mar 06, 2018, 1:26 PM UTC

switchbak wrote: post #10

toomanybeersies wrote: post #5

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles. You'd lose type safety compared to Rust, but they don't have that with JS now anyway. I don't think the majority of the memory consumption is from JS though, moreso the embedded browser+DOM approach. Edit: Blaming electron for bloat more than JS.

>If it weren't for the oddness of the language, Lua would be a perfect fit. Near-C speeds, super flexible, no recompiles.

True.

But there are also other dynamic languages that can go as fast as LuaJIT and of course faster than V8: Common Lisp and some Scheme implementations.

Both are very elegant languages, moreso than Lua (which is very peculiar.)

However, for the goals of an editor, my choice would be Free Pascal with Lazarus. It is already complete for cross-platform UI deployment. And compiled code is really fast.

Re: Xray – An experimental next-generation Electron-based text editor

#199

Post by gdgegeg » Tue, Mar 06, 2018, 1:39 PM UTC

ahtu123 wrote: post #17

toomanybeersies wrote: post #5

I've always felt like the inevitable conclusion of Atom and other electron based apps is the reversion to using low level compiled languages. I'm starting to get tired of how much of a resource hog Atom is.

I'm always amazed when I see the size of the Atom executable on my computer(438MB). It's the size of a game! It's also pretty much the worst performing text editor (in runtime for most operations) and a memory hog. I really don't get the hype.

It's true that it's the size of a game (I think Deus Ex was about that big?) but in-keeping with the shifting numbers lets take a popular Call of Duty game from last year.

Steam's minimum storage guideline says 70GB(!).

Not say Atom can't be more efficient, but I think this is often our field's "I remember when a cola was 10 cents".

Re: Xray – An experimental next-generation Electron-based text editor

#200

Post by JPKab » Tue, Mar 06, 2018, 1:52 PM UTC

rattray wrote: post #122

nine_k wrote: post #96

Earlier quoted context omitted.

The v8 engine behind Atom is an incredibly efficient compiler, a just-in-time compiler. Without it, all current JS interfaces would be comically slow. The problem with JS is that its execution model is built around highly dynamic features that are hard to compile efficiently. It also lacks a nice type system, though Typescript helps a lot. The problem with Atom performance, I suspect , is mostly with its using a web…

Hmm, VSCode uses a web browser (and I think also the DOM) to display/edit text, and I find it to be perfectly snappy (Atom was unusably slow on my work codebase).

GitHub doesn't do desktop software. Msft does. I'm assuming that is a big reason why they have a big performance boost.