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

151–160 of 189 posts

Re: How I fixed a bug in Atom

#151

Post by klibertp »

andrewingram wrote: post #53
Lazare wrote: post #44

Earlier quoted context omitted.

First, good news: The Atom teams is (slowly) moving away from Coffeescript towards modern JS, and I think they'd agree (unofficially) that the choice proved to be a mistake. Beyond that... 1. The JS world moves stupidly fast, and Coffeescript is a relic of a now-vanished age. It was born, it evolved, and it died. Back in those long ago days of, um, 5 year years ago, there was no ES6, and Coffeescript looked a lot mor…

In fairness, I built a fairly large app using CoffeeScript and it still took a lot of brainpower to read it compared to JS. All the typical complaints about ambiguous-looking syntax match my experiences exactly. I ended up with a general workflow of having my Coffeescript source and the generated JavaScript sitting side-by-side so I could check that the output was what I was expecting. I've only had the urge to do th…

I wrote a couple of (simple) apps in LiveScript, which is similar to CoffeeScript, but is still way ahead of ES6 in terms of features[1]. I had to look at the generated source only once: when I was debugging and ultimately fixing a bug in the compiler. That's expected: had my C compiler had a bug, I'd have to look at asm output, too.

Normally, pre-source maps, I'd also look at generated JS when debugging in the browser, but this is no longer the case. Other than the mentioned compiler bug I didn't have to look at the generated JS even once in my 2-3 years of using LiveScript.

I think a good question to ask would be why did you have to look at the generated source. What did that give you, and what could replace it? Is looking at the generated source the most efficient way to achieve your goals?

[1] The "killer feature" of LiveScript, for me, is its support for functional programming on par with support for OO. It reminds me of Scala or F# in that regard.

Re: How I fixed a bug in Atom

#152

Post by emodendroket »

jandrese wrote: post #128
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.

Well, when the only tool you have is a hammer...

Re: How I fixed a bug in Atom

#153

Post by emodendroket »

jarcane wrote: post #144
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…

Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. -- Jamie Zawinski To which I might dare add, "... and so does whomever next has to read this code."

This is actually a place where "whoever," rather than "whomever," would be correct, even in the most conservative style.

Re: How I fixed a bug in Atom

#154

Post by pcwalton »

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…

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 quicksort based on the size of the collection.

This approach gives you the best of both worlds: speedy operation in the common cases in which recursive backtracking beats the Thompson NFA, all the regex features you know and love, and worst case polynomial running time for regexes that the Thompson NFA supports.

I don't think it would have prevented this bug, though, because I don't think the Thompson NFA supports the recursive backreference thing that this regex uses.

Re: How I fixed a bug in Atom

#155

Post by joepvd »

zamalek wrote: post #136
hencq wrote: post #130

Earlier quoted context omitted.

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

I miscommunicated the question: "how well would have a Thompson NFA have dealt with this?" I.e. How many magnitudes of order faster would it have been? If it was faster?

NFAs do not do backtracking. So the solution space would look different. More sane, and more performant, but it would not be a pure regex solution.

Re: How I fixed a bug in Atom

#156

Post by emodendroket »

JetSetWilly wrote: post #18
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 don't always want to spend insane amounts of time writing full AST parsers. Sometimes it is a lot easier to write a simple, hacky, throwaway regex. It's a bit much to claim that backtracking regular expressions, a very useful tool sometimes, should never ever be used and everybody should waste loads of time writing careful code even in situations where it isn't required. The problem is not the tool. The problem is…

> Sometimes it is a lot easier to write a simple, hacky, throwaway regex.

I mean, yes, but I'd argue that "I am writing software which will spend a significant amount of its time parsing code" is not one of the times when that is an appropriate instinct.

Re: How I fixed a bug in Atom

#157

Post by mamcx »

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…

I have a project that wish to be Cross-platform (windows, osx, linux in that order).

The only tool I could use with some decent widgets is Delphi (but cost too much and kill the idea of release the tool as open source).

After that, what exist? QT is horrible. GTK look bad and weird (equal others like wkWidgets). Doing one for each target is the best but harder.

I know some people think QT/GTK is good, but as user of Delphi, them are ugly in comparison and less featured. Even winforms is barely a match.

HTML+JS+CSS is far easier, at least, to get the look. Then is the problem in how make it attractive for contributors.

I wish exist a way to get a html fast/light html rendered for the GUI.

Re: How I fixed a bug in Atom

#158

Post by morgante »

Lazare wrote: post #44
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…

First, good news: The Atom teams is (slowly) moving away from Coffeescript towards modern JS, and I think they'd agree (unofficially) that the choice proved to be a mistake. Beyond that... 1. The JS world moves stupidly fast, and Coffeescript is a relic of a now-vanished age. It was born, it evolved, and it died. Back in those long ago days of, um, 5 year years ago, there was no ES6, and Coffeescript looked a lot mor…

> If you're not, it looks like gibberish. But that's true of any language.

That's not true though. I'm not familiar with C++, for example, but it doesn't look like gibberish when I look at it. Nor does Go, as another example, even though I've never written a line of it.

CoffeeScript, on the other hand, still is hard for me to parse—even as someone who has written thousands of lines for it.

There are very real differences in readability between languages.

Re: How I fixed a bug in Atom

#159

Post by morgante »

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…

> My point is: don't complain about coffeescript while cheer at ES6, they are mostly the same.

No, they are really not.

ES6 does not change the semantics of the language. It adds a couple of new useful features, but it still maintains the basic readability of JS.

I've written production apps in both. With Coffeescript, I regularly encounter problems where the generated output is not what I expected given the input and the only way I discovered that was examining the output JS.

With ES6/Babel, I have literally never inspected the generated output. It's never produced code contrary to what I expect.

Re: How I fixed a bug in Atom

#160

Post by IshKebab »

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…

Yeah I was disappointed when he got to the crazy regex. Realised it was an unreadable mess, but then didn't realise that the real fix is not to use regex.
Post reply on HN