Hacker News Reader

I understand your frustration. This is the 3rd editor I've got excited about by looking at screenshots (see also Atom and Brackets). Then was disappointed when I realised they render using a browser.

=Slow. Not slow enough to be unuseable. But slow enough to drive you crazy after working with it for a day. And perhaps 30% reduction in laptop battery life, because of increased power requirements.

I moved to Sublime Text. Millions of us did. It provided both fantastic usability and rocket-fast speed. That's the baseline. Any new editor needs to at least have BOTH those features!

>This is a bit of a personal rant, but we're living in an age with multi-gigaflop CPUs and multi-terraflop GPUs, and we have somehow regressed to a point where scrolling is laggy again? IMO this is absurd, as an industry trend in general. For this reason, I generally dislike the trend to write everything (including local apps) in HTML/CSS/JS. These technologies really weren't designed to support this sort of complex dynamic UI. While it's quite impressive what's possible despite this, the stress of forcibly warping HTML/CSS/JS to accomplish some of these UI feats shows through as horrible inefficiency.

I doubt the issue is simply the use of web technologies...the fact is the more powerful our computers become the more demand is placed on them. Your web browser is just one more thing running on your computer, there are a bunch of other things influencing overall performance. You could replace the entire web stack of technologies and you would probably end up in the same place performance-wise.

I envision a future where we have even faster computers but then maybe your OS would have integrated a bunch of AI that'll bring performance to a crawl :)

I can barely push my pc above 10% usage and yet I enjoy from time to time laggy interfaces and locks. Worst offender right now - Eclipse after being out of focus for more than 10-12 hours.

I've noticed that too on OSX - it's not just Eclipse, any memory heavy app such as xcode causes the same. I don't get this happening in Eclipse on either my Windows or Linux installs. I think it's just very aggressive paging to disk or something similar.

It is on SSD ... and I have 32 Gigs of ram. And some of the intelij products I use have no problems - and they are java based. Windows 8.1.

But anyway on current PCs any kinds of unresponsive UI-s are inexcusable.

Ah.. weird I have no idea then. I've got an Eclipse running on Win7 SSD that has been open for over a month using 3GB of ram out of 16GB. It's very very snappy. I do have an Eclipse running on a macbook pro SSD 16GB and that one has about a 2-3 sec freeze when swapping back to Eclipse after backgrounding it for awhile, so I thought that was your issue. Maybe Win 8.1 works more similarly to OSX than Win 7?

Something in OSX paging is broken. See http://workstuff.tumblr.com/post/20464780085/something-is-de... for details. Apple refuses to fix this for years. This rendered my old Core2Duo/2GB RAM/spinning disk MBP useless even for web browsing. This sort of system rot is one of the reasons I'm running Arch on my Haswell MBP/16GB.

No doubt, as computational supply increases, so does the demand. Normally, this is a sign of health/progress; it only becomes a problem when demand shoots so far past the supply that we actually regress important user experience metrics (e.g. interaction latency or battery life experienced by the user). So why does this happen?

"HTML5" has rightfully exploded in popularity. In fact, these days it's hard to justify NOT building your front on this stack. But much like any explosion of a popular technology, the developer community will tend to push the limits of what it can reasonably do. This exploration is a good thing, but it can be frustrating until people settle into best practices of what applications do and do not suit a given tech stack.

I doubt the issue is simply the use of web technologies...the fact is the more powerful our computers become the more demand is placed on them.

It's probably not simply the use of web technologies, but I'm quite sure it makes a difference. There's a lot of buzz about how slow Github's Atom is compared to Sublime Text, for instance. And BBEdit -- an old Mac text editor which often gets ignored these days as an unfashionable relic -- just loaded up a 24M, 181,000-line MySQL dump and is having no perceptible speed issues either scrolling the file or letting me insert new text on its first screen, even with syntax coloring enabled. The same was also true of Vim and Emacs (despite Emacs kvetching about the file's size when it loaded it).

It's my suspicion that the age of these warhorses may help them here rather than hurt them: serious editors twenty years ago required serious optimization work. While I do most of my programming in Sublime Text, there are certain times BBEdit is just the fastest tool for the job. If I was starting a new text editor, which I wouldn't, I'd be much more concerned about editing speed than it appears the developers of the current batch are.

> It's my suspicion that the age of these warhorses may help them here rather than hurt them:

Of course it does. Back in the day one couldn't take a megabyte file and say, "I'll just load it all into memory." When I worked in Visual Studio, it annoyed me to no end that VS had trouble loading large text files when ancient FoxPro (another MSFT dev product whose origins are from the 80s) would load them just fine. FoxPro didn't try to cram the whole thing in memory, just the parts it needed. I'm guessing vim and Emacs work in a similar manner. Don't use VS anymore, so I don't know if they ever fixed that or not. Particularly annoying is that it ever needed to be fixed, rather than being designed correctly (for which there was plenty of prior art) from the start.

>didn't try to cram the whole thing in memory, just the parts it needed. I'm guessing vim and Emacs work in a similar manner.

Yes, but with the caveat that it's line based (1 dimensional) not 2 dimensional so a VERY long line can still choke vim and Emacs.

--- long time primary Emacs, secondary vim user

> it's line based (1 dimensional) not 2 dimensional so a VERY long line can still choke vim and Emacs.

Have an upvote because (to quote Johnny Carson) I did not know that.

Certainly true. (I'm old enough to remember TRS-80 word processors, only one or two of which were able to handle files larger than memory. SuperScripsit's ability to handle files as large as your floppy disk -- all, what was it, 180K of it? -- seemed amazing!)

Re: FoxPro vs. VS, it's probably quite unfair to suggest that it's in part because FoxPro didn't start its life at Microsoft, but I admit it was the first thing that came to mind...

Modern applications have a host of demands placed upon them today that older ones did not. Whether it's complex theming capability, accessibility support, or special font/unicode support, things aren't so simple.

I say this as a long-time vim/emacs user... (yes, I've learned and use both although I primarily use vim).

So while I'll readily agree that I doubt they work as much at optimisation, they're also being asked to do significantly more.

I think you're right, but Vim and Emacs and BBEdit all seem to have managed this without unduly choking. I'm not sure where the "fault" actually is in these specific cases -- if I had to place a bet it might be on the syntax scoping algorithms, as nearly every post-TextMate editor seems to re-implement TextMate's language files. (I don't know if Zed does.)

Let's not pretend emacs/vim are perfect; there are certainly situations where they slow down. I certainly have files where the syntax highlighting isn't so speedy or where it's temporarily broken.

I'm just trying to point out that attempting to compare applications from a certain period in computer history to modern applications is doomed to fail.

While I certainly believe optimisation work would help some modern editors, it would be silly to attempt to blame that all on optimisation work instead of recognising that the world is different now.

> I doubt the issue is simply the use of web technologies...the fact is the more powerful our computers become the more demand is placed on them. Your web browser is just one more thing running on your computer, there are a bunch of other things influencing overall performance. You could replace the entire web stack of technologies and you would probably end up in the same place performance-wise.

Running a profiler would seem to suggest otherwise.

>These technologies really weren't designed to support this sort of complex dynamic UI

I used to think of this when I saw UI developed in C++ (instead of pure assembler. Jesus, they would just multiply with a scan width instead of shifting!). I thought it when I switched to Windows (they're running everything through a giant abstraction layer here! That will never perform!). And yes, I find myself thinking this again now that the final bits of software seem to be moving into the browser. But this time, I'm going to assume that I'm probably wrong :-)

Bottom line: What is the end user experience?

I don't care how many abstraction layers, VMs, and scripting languages you do or don't use. I care that my UI doesn't lag or have choppy scroll animations, and that the battery doesn't drain 2x faster than expected.

Yeah, eventually these problems will likely disappear with more powerful hardware. But we're not the yet, and a good engineer realizes hardware limitations and designs software appropriately to achieve a great user experience.

"software is getting slower more rapidly than hardware becomes faster"[1]

I was showing a junior some plpgsql yesterday and he asked me what languages use BEGIN, END etc. So I pointed him to Pascal and ended up myself on wikipedia where I (re)found the above quote.

One of the points people normally make for HTML/JS/CSS is that the browser is sandboxed and there is already a well defined standard on how to serve dynamic content to a browser, across ALL platforms.

This might change with all platforms moving to a package manager or walled garden, and we then might start to see some "native" code again. But even the new platforms op-in for web tech like Metro etc.

But meh I'm rambling again so I will leave who ever will read this comment with a link to vsftpd[2] security section because I liked the idea of sandboxing a application with chroot and with that you can start to build a "Secure" native app.

[1]: https://en.wikipedia.org/wiki/Wirth%27s_law [2]: https://security.appspot.com/vsftpd.html#security

JavaScript is a slightly different situation. The degree of "sufficiently smart compiler" required to get C to run at assembly speed/power is nearly trivial (strength reducing multiply to shift? really not hard). On the other hand, the degree of "sufficiently smart compiler" required to map JS's type system and execution model to the machine is much higher and in some cases is impossible, which is why we have to use lots of JIT tricks (which takes power and time) just to get a mature, native-optimized JS program to run at half native speed at who-knows-what power.

Thank you for your constructive comments. I can work with this :)

fwiw the search is called fuzzy matching

also, gl on the project

And here's an explanation with some code examples: http://www.quora.com/Algorithms/How-is-the-fuzzy-search-algo...

Another interesting algorithm for fuzzy searching is this one: http://www.catalysoft.com/articles/StrikeAMatch.html

It essentially compares the number of matching two letter pairs in strings.

I used it in a C# app that did a fuzzy instant search as the user typed more letters in. On a dataset of about six thousand names it performed really well, but it was a pretty simple app. I also used a javascript version on the same list to see how it performed on an X120e netbook, and again, it was instantaneous.

No idea how the performance would compare to the methods for common substring. I like the pairs matching because I can screw up letter positioning and accidentally type a letter or two that doesn't exist in the string, but still get back strongly matching results and usually find what I want. I used it because we had a huge issue at work with people brutalizing names they entered into our employee database.

Here's an implementation I wrote in javascript: https://gist.github.com/doorhammer/3016ecaac5313a87804b

I never used it in production, and it's not optimized really at all, but it shows how straight forward a typical version can be.

I took a quick look. What he described is essentially a specific case of n-grams (n=2, bigrams).

http://en.wikipedia.org/wiki/N-gram

Thanks for the information. So it looks like it's a specific application of an algorithm to vectors of bigrams? The most relevant part of the wikipedia page (I think): http://en.wikipedia.org/wiki/N-gram#n-grams_for_approximate_...

It also appears that the algorithm I linked is actually the Sørensen–Dice index. They have the exact same formula on the wiki page: http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coef...

Appreciate the heads up. Gave me much better terms to search for. Going to add them to the notes of my gist. I'm on vacation now, so I'll have to do more reading on it over the next few days

Also made a public gist for whoever is interested:

https://gist.github.com/doorhammer/9957864

On a related note, Komodo Edit/IDE has a great feature in their fuzzy matcher.

In ST3 for example, a space is basically treated like the regex /.*/

This means that if you type something you can only the filter results on the RHS of your input do far.

Consider: Models/player.js Controllers/player.js Views/player.js

If I type "play" then I need to hit home to filter further.

In Komodo, space is treated as a logical AND, which you can use to more effectively search the above.

I've not tried Zed yet, but if it can handle this case then that's a plus point from me.

Visual Assist does the Komodo thing in its file name and symbol selectors. It's excellent. I've never used any other search mechanism that's quite so good for very quickly narrowing down large lists to a handful of items.

(emacs users may be familiar with iswitchb, which can be operated in a similar manner. Entering space-separated strings in Visual Assist is equivalent to entering those same strings in iswitchb and then pressing C-SPC after each one to perform each search on the result of the previous one. This is marginally more fiddly, but the key part is being able to narrow the list down with one substring, and then add more substrings to further refine things.)

I've added a similar Visual Assist-/Komodo-style UI for finding things to a couple of programs I've worked on, basically copying exactly what Visual Assist does. The response is always positive.

it makes me somewhere between depressed and angry whenever i type into an entry widget that cannot keep up with my keystrokes. i really don't know why this is not a drop-everything-and-fix-this bug, but the computing world seems to have accepted it as one of those things that happens.

I think this is because developers tend to have fairly fast computers, and simply don't realize that their program is slow on old hardware.

But does this happen with Zed? For me it works well even on old pentium4 desktop.

wasn't talking about zed specifically, just about text entry software in general. the worst offenders seem to be IDEs and web-based forms that want to do per-character callbacks.