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

How I fixed a bug in Atom

davidvgalbraith.com

Post reply on HN
Print view View original

121–130 of 189 posts

Re: How I fixed a bug in Atom

#121

Post by pilif »

ngoldbaum wrote: post #118
pilif wrote: post #110

In general, when you are working on a problem and you think "let me use a regex for that" and then you come up with ^\s*[^\s()}]+(? [^()]*\((?:\g |[^()]*)\)[^()]*)*[^()]*\)[,]?$ to solve your problem, then you have IMHO come across a problem which you should not be solving using regular expressions. Case in point is counting and balancing parentheses which is very easily done using a single loop over the string in qu…

The issue seems to be that Atom uses regular expressions as part of the internal API it uses to separate Atom core from add-on modules.

Maybe the API needs to be changed to allow the module to return a function. After all, JS has first-class functions, so this would make total sense.

Re: How I fixed a bug in Atom

#122

Post by GFK_of_xmaspast »

kcbanner wrote: post #94

I am still unsure why anyone uses Atom when it consumes so many resources. The emacs instance I have had open for some time now is using 92Mb. Atom instances have been reported in the hundreds of megabytes [1]. Of course, this is because it is actually a web application running in an entire browser, renderer and helper processes included. I understand the need for people to be able to "easily" hack on it (easily in q…

Time was, emacs was the huge bloated editor that would catch flack for using so many resources ("Eight[y] Megabytes And Constantly Swapping)

Re: How I fixed a bug in Atom

#123

Post by GFK_of_xmaspast »

Tyr42 wrote: post #117

Grrr, that's not a Regular expression at all. I think you'd be better off looping over the string and counting the number of ( and )s in a loop, guaranteed linear time. I wish people would stop abusing regular expressions.

A regex is far more useful than a regular expression, and I'm ok with the terms getting conflated.

Re: How I fixed a bug in Atom

#124

Post by mbrock »

hvis wrote: post #120
mbrock wrote: post #86

Earlier quoted context omitted.

The issue tracker for js2-mode illustrates that such a parsing approach is no guarantee of real-world accuracy either. https://github.com/mooz/js2-mode/issues The goal just shifts from having a semi-accurate regexp tokenizer, to having the language mode's complex parser match the complex parser of the language it targets—which will pretty much never happen, unless the language is exquisitely simple, like maybe restri…

js2-mode supports ES6 fairly accurately. But of course, that's not enough, people keep asking for new things: JavaScript mixed with HTML, Facebook Flow support, JSX, new ES7 (still unstable) syntax extensions, and so on. It would be easier with a more stable language. I.e. not JavaScript, which is still going through growing pains. Even so, "25 Open, 204 Closed" seems pretty good to me.

fundamental-mode hasn't failed me even once, is what I mean. :) I'm not criticizing js2-mode, it's just that I have personally given up hope for accurate language modes in general, and realized that they are a lot of effort and IMO relatively little use.

Re: How I fixed a bug in Atom

#125

Post by GFK_of_xmaspast »

fenollp wrote: post #77

> Having very little to go on, I began the search by searching the whole codebase for the word “newline”. Is this really how people troubleshoot JS issues? In 2016?

I don't know javascript beyond the most basic aspects, what would you have suggested here.

Re: How I fixed a bug in Atom

#126

Post by BinaryIdiot »

Lazare wrote: post #45
viraptor wrote: post #17

Earlier quoted context omitted.

Same here. Also, I don't use Atom, but looking at the expression I'm pretty sure it fails to account for strings with parentheses. The way the matching is done, it looks like it will happily count: func("some call :)") as extra closing paren. (regex101 agrees)

Sometimes I feel like the difference between a junior, intermediate, and senior developers is that the junior hasn't yet figured out how to use regexps, the intermediate dev has, and the senior dev has figured out not to. I kid, but...really. The number of times I've seen people burnt by non-trivial regexps in production code is absurd. "Oh, I need to mangle this CSV that's in the wrong format"? Sure, write a one-off…

I completely agree. Honestly regular expressions are hard to get a handle on anyway. I've done software development for about 12 years now and I probably run into a regular expression pretty regularly and I still find them hard to read and understand. Almost every single time they do things that can easily be accomplished with a loop and a tiny bit of string manipulation and, honestly, even if the regex was a little faster it's unlikely to be so much faster than you need to make the micro-optimization of using regex instead of some looping.

I try to avoid regex where possible and in the event that I do need to use it I try to document it the best I can and to make sure it's as simple as possible to avoid weird issues like this.

Re: How I fixed a bug in Atom

#127

Post by kungtotte »

Klathmon wrote: post #85
ousta wrote: post #58

Performance wise I never understood why ATOM is even used. it is lackluster compared to a notepad++ and there is a delay in every action: loading the software, clicking on a tab, on a menu, on an option. it seems to me like a very wrong idea to push the web into softwares

When was the last time you used Atom? It's definitely not the fastest opening editor, and it does have performance issues, but they tend to be more rare than common. The 2 that bite me are: * the update/install screens in the settings tend to be a bit slow * opening "large" files that have 1000+ characters per line will either hang or crash the browser depending on the size. If it's a "normal" looking source file, it…

It's by far the slowest compared to Sublime Text 3 and Visual Studio Code. VSCode and Atom obviously suffer from being Electron based compared to ST3, so the comparison there isn't exactly fair, but VSCode is noticeably faster to load and snappier to work with even loaded up with third party plugins. I have a similar amount of plugins for each of the three (10-15) too, so no real difference there.

And honestly I don't see a marked difference in visuals between those three. After installing my zenburn colour scheme they're virtually identical with similar if not identical UI features.

I don't expect the Electron based editors to match ST3 for performance (at least not yet), but honestly it's kind of embarrassing how slow Atom is compared to VSCode, particularly when it comes to things like checking for package updates and just starting up.

This is all based on using all three editors within the last three months (I've been swapping around trying to find what I like).

Re: How I fixed a bug in Atom

#128

Post by jandrese »

pilif wrote: post #110

In general, when you are working on a problem and you think "let me use a regex for that" and then you come up with ^\s*[^\s()}]+(? [^()]*\((?:\g |[^()]*)\)[^()]*)*[^()]*\)[,]?$ to solve your problem, then you have IMHO come across a problem which you should not be solving using regular expressions. Case in point is counting and balancing parentheses which is very easily done using a single loop over the string in qu…

The worst part is that as soon as he mentioned regular expressions I knew exactly what the problem was.

Regexes are powerful and useful but also dangerous. People who don't thoroughly understand them and try to get fancy often run into problems like this. In general you shouldn't be using them to parse a computer language anyway, it is something you should be using a tokenizer/parser for.

Re: How I fixed a bug in Atom

#129

Post by alextgordon »

issaria wrote: post #87
TazeTSchnitzel wrote: post #55

Earlier quoted context omitted.

CoffeeScript is supposed to be this nice Ruby/Python-esque sugar for JS. It does resemble those languages, but it's not nice, it's very... stabby. Indentation is unintuitive and makes code do completely different things (whereas in Python it just delimits blocks, and if you get it wrong the compiler will moan at you). Functions implicitly return the last value they produce. You can omit brackets in function calls - b…

Coffeescript is not perfect, however, nowadays people went crazy for ES6/ES2015, and suddenly nobody complains readability of babel output. I've worked with both, ES6 is definitely a big progress on Coffeescript, but it takes like 80% of the things from coffee IMO, except the indentation syntax and list comprehension, added an `import` keyword. My point is: don't complain about coffeescript while cheer at ES6, they a…

Throughout its life, CoffeeScript has been by disparaged by those who just seem to really hate it's existence for some reason. At first it was "you can't debug generated code!", now that everybody is using generated code it's "coffeescript is the past, you don't want to live in the past do you?"

Except... CoffeeScript does all sorts of nice things that Babel does not. List comprehensions. Lack of == operator. Correct modulo operator. Block regexes. Triple-quoted strings. The @ syntax.

There is a strong cult-like vibe to the JS community, and I really find it off-putting. They have taken a technical limitation "Browsers only support JS" and turned it into a socially enforced rule "You may only use JS". Fuck 'em.

Re: How I fixed a bug in Atom

#130

Post by hencq »

zamalek wrote: post #70
cyphar wrote: post #10

First of all, this is why people should stop adding stupid features to regular expressions. A sane regular expression implementation has no pathological cases. DFA generation can be done in O(n^2) from memory (in the absolute worst case O(n) is average), and matching can't be worse than O(m) or similar (n is the size of the regex and m the size of the string). When you add features like back references and recursive…

I strongly doubt the AST would be needed. You could probably do this in a trivial loop state machine. It can't even be called laziness: that regex took time to work out - far longer than a switch-based state machine would have taken to write in the first place. Aside: out of curiosity it would have been interesting to see how a Thompson NFA[1] would have dealt with this. [1]: https://swtch.com/~rsc/regexp/regexp1.htm…

> Aside: out of curiosity it would have been interesting to see how a Thompson NFA[1] would have dealt with this.

It wouldn't have dealt with it right? NFAs and DFAs are equivalent and them being actually regular means they can't do things like count parentheses.

Post reply on HN