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

181–189 of 189 posts

Re: How I fixed a bug in Atom

#181

Post by na85 »

josteink wrote: post #40

Completely unrelated to the issue at hand... I had no idea Atom was written in CoffeeScript. I thought it was written in Javascript, which made me positive at the thought of hacking into it. But this code? Definitely giving me a headache, and my interest went down to zero. There seems to be a meme and unchallenged claim in hacker circles that CoffeeScript is somehow more "readable" and easier to understand. Allow me…

>TLDR: CoffeeScript seems like a bad choice for just about everything and I can't see why any big project with a desire for contributors would even consider using it.

I'd say the same for JavaScript

Re: How I fixed a bug in Atom

#182

Post by pcwalton »

mwcampbell wrote: post #171
pcwalton wrote: post #154

Earlier quoted context omitted.

You don't need to throw out your favorite regex features—backreferences aren't stupid, they're useful and usually harmless! Rather, a good regex engine should start with recursive backtracking (ideally JIT'd) and fall back to the Thompson NFA if the regex supports it and the recursive backtracking approach is taking too long. Think of it like the adaptive sorting algorithms that switch between insertion sort and quic…

Do you know if any major regex implementations use the adaptive approach you're suggesting?

I don't know of any that can actually switch during regex execution, but TRE at least will choose Thompson NFA if it can and fall back to recursive backtracking if backreferences are used.

Re: How I fixed a bug in Atom

#183

Post by odbol_ »

wmonk wrote: post #143
random_rr wrote: post #112

Earlier quoted context omitted.

No, he fixed a function of Atom, the original title is valid.

The regex he fixed was committed into the package atom/language-go, not into atom core. It was only an issue when writing go code.

Dude, you don't need to be so semantic. The headline had "atom" in the title, it had to do with Atom the editor, what more do you want? Do you think every headline should be excruciatingly specific and exact? Might as well just put the whole article in the headline.

Re: How I fixed a bug in Atom

#184

Post by jquast »

HeXetic wrote: post #107
boulos wrote: post #11

I got to the bottom and couldn't believe that the solution chosen was to modify the regexp instead of use a for loop. He did such a great job explaining that the code is really just trying to count the number of parentheses or braces to see if they're imbalanced, that it felt the next step was "so I wrote a really simple set of loops that is fast enough on short strings and way less crazy otherwise".

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. - Jamie Zawinski

"There are horrible people who, instead of solving a problem, tangle it up and make it harder to solve for anyone who wants to deal with it. Whoever does not know how to hit the nail on the head should be asked not to hit it at all."

- Nietzsche

Re: How I fixed a bug in Atom

#185

Post by random_rr »

wmonk wrote: post #143
random_rr wrote: post #112

Earlier quoted context omitted.

No, he fixed a function of Atom, the original title is valid.

The regex he fixed was committed into the package atom/language-go, not into atom core. It was only an issue when writing go code.

I fixed my car the other day by changing a tire - well, technically, I fixed a problem in the car/going-on-the-highway package. But no one on earth would talk or write like that.

Re: How I fixed a bug in Atom

#186

Post by cyphar »

wfunction wrote: post #20
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…

> The conversion from DFA to NFA [...] I believe you mean NFA to DFA. > [...] would require O(n^2) in that case I believe you mean O(2^n). https://en.wikipedia.org/wiki/Powerset_construction#Complexi...

Actually, the O(n^2) thing is correct for an NFA simulation that tracks states not paths. While there might be O(2^n) paths, there are n states you can be in at any one point.

https://swtch.com/~rsc/regexp/regexp1.html

Re: How I fixed a bug in Atom

#187

Post by cyphar »

reacweb wrote: post #27
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…

The support of fancy features like backtracking does not cause any degradation of performance for simple regular expressions. You are not obliged to use them, but they do not hurt you when you do not use them. Some other people may love them despite their poor complexity.

> The support of fancy features like backtracking does not cause any degradation of performance for simple regular expressions.

Well, backtracking is how you implement your engine. So "simple" regular expressions that don't use any of the features backtracking provides (like backreferences) will cause exponential complexity, like:

a?a?a?a?aaaa for a string "aaaa"

Re: How I fixed a bug in Atom

#188

Post by zeveb »

cyphar wrote: post #178
zeveb wrote: post #147

Earlier quoted context omitted.

> So, there really was no trade off for the power vi and emacs offered (less powerful alternatives of the time were still just as inaccessible), where now there is. There's simply nothing out there as good as emacs. Nothing. Eclipse, IntelliJ, Atom, SublimeText, all those pale in comparison. vim has its positive points (it's an excellent way for a human to edit line-oriented text), but ultimately it too falls down in…

> vim has its positive points (it's an excellent way for a human to edit line-oriented text), but ultimately it too falls down in the general case I think the only thing that Vim doesn't do that it should is actually use a proper language for scripting. Emacs has elisp, but Vim has VimScript which is a horribly stunted langauge. Aside from that, I much prefer vim to emacs. Just because everything is mode-based, and t…

Check out spacemacs: the modes of vim, and the extensibility of emacs. Not really by cup of tea, but it sounds pretty cool.
Post reply on HN