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

31–40 of 189 posts

Re: How I fixed a bug in Atom

#31

Post by threatofrain »

ilaksh wrote: post #8

"How I fixed a bug in Atom that affected almost no one, and then spent quite a lot of time writing an article about it, then wrote a title that attempted to give me more credit than I deserved" .. which is his main pass time if you see his other posts, rather than spending his effort on fixing bugs that actually affect a lot of people. I am sorry but I don't really appreciate it and have trouble getting over the misr…

If you had restrained your point to the misrepresentative title then you might have built consensus. Instead you lead with a creditworthiness argument, which was your weaker and more sensational point.

Re: How I fixed a bug in Atom

#32

Post by andreasklinger »

jakub_g wrote: post #24

It seems there's a need of a regex linter (eslint plugin?) that could warn on pathologically complex regexes. Is building this kind of plugin feasible? Having said that, probably few people would explicitly opt in to using such a plugin unless it's bundled by default to some linter.

technically yes. but i wouldnt be surprised if deciding on "best practices" is hard given that regex are very often used to get something "just to work".

Re: How I fixed a bug in Atom

#34

Post by xixixao »

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…

Because regular expressions such as that one can be applied line by line which becomes important for thousands of lines file and because you can adopt them more easily between languages: they are more loose. This is the reason why all text editors use them (IDEs can choose to use an AST).

Re: How I fixed a bug in Atom

#35

Post by thaumasiotes »

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.

Actually, this is false. A lot of regex implementations use a backtracking approach in all cases, causing pathological behavior even on regexes which match a regular language (and so should never take any significant amount of time to process).

See https://swtch.com/~rsc/regexp/regexp1.html, which gives

a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

(see the backtracking? me neither) as an example.

Re: How I fixed a bug in Atom

#37

Post by spinningarrow »

> This defines a named capture group, .

I thought JavaScript regexes don't support named capturing groups. Is Atom using some library or custom functionality for that?

EDIT: Or is it a CoffeeScript addition? In their table of contents I only see regex blocks mentioned though (http://coffeescript.org/#regexes).

Re: How I fixed a bug in Atom

#38

Post by oneeyedpigeon »

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".

There's a comment by 'dave' - presumably, an atom dev - explaining why that's not as quick a fix as you'd hope. But, yes, as soon as I got to the part in the article that read something like '... using backtracking to handle an unknown level of nesting ...' I reached pretty much the same conclusion: stop using regexps for this!

Edit: I think it might actually be the same 'dave' who authored the article, which demonstrates how much he's learnt just by fixing this one bug.

Re: How I fixed a bug in Atom

#40

Post by josteink »

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 to disagree, and I suspect there's quite a few like me. This code is harder to read. I think I understand what the code does, but I can no longer be certain about the language semantics. That introduces needless uncertainty.

And it just broke all my pre-configured and pre-setup JS-tooling. Can't use any of that for this codebase. Just great.

So what's up with people writing applications and projects in NodeJS, a prime JS-environment which supports "all" modern Ecmascript-features, classes included, and then decide to go use a non-standard language for their app?

And for what gains? How did Coffeescript make this code more readable or easier to debug? It didn't. And now you need to debug code compiled from the actual code you wrote. How does that do anything except make everything harder?

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.

Post reply on HN