91–100 of 189 posts
Maybe everyone does it and everybody is happy with it working only in 90% of cases, but it just seems like the wrong approach to me.
Isn't arbitrarily-long nesting or matching any sort of palindrome, where you count up and down, the classic case of something you should never do with a regex, because they're finite automata? People don't build parsers because of masochism, but because regular expressions are provably insufficient to capture things like nesting. You need to go at least one level up on the Chomsky hierarchy[1] to pushdown automata fo…
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
I understand the need for people to be able to "easily" hack on it (easily in quotes here because really that just means "people who know web languages"), but that goal could still be accomplished in a native application that embedded a JS runtime for plugins.
[1]: https://discuss.atom.io/t/high-usage-cpu-and-memory/16165/3
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 am not trying to harp on Vim or Emacs, I myself am a Vim user and use it for C++ code.
"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…
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…
The easy-to-hack bit is not about the specific scripting language but about the UI being completely hackable.
No other editor (except emacs) lets you hack the interface as well as Atom.
And any attempt at exposing enough hooks to allow a native text editor UI to be as hackable would, in a kind of Greespun's 10th rule, probably result in a bug ridden, poor implementation of an HTML engine.
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…
This is an effect of the language, not the problem space. Backtracking REs make it very easy to write bad code, and then most languages make writing the parsing code hard.
If you're in a language that makes parsing code easier, like Haskell, then the tradeoff isn't anywhere near so bad. I don't mention Haskell just because it's the trendy thingy, I mention it because parser combinators really do make for some very easy parsers, and while parser combinators can exist in other languages they tend to be very syntactically heavyweight. Perl 6 is supposed to make parsing perhaps even easier, but I haven't played with it to know.
Parsing isn't really that hard, it just plays very poorly with Algol-inspired syntax.
To be clear, since this is the Internet and the presumption of disagreement is strong, this post is not an explanation of why you're wrong... it's an explanation of why you're right. It is absolutely a true statement that in most languages you're way better off bashing out a dangerous RE than writing a proper parser even for something as simple as this.
Earlier quoted context omitted.
... with regex.
With anything less than a full-featured lexer and parser of the latest edition of the language in question, I'd say. Including understanding of whatever metaprogramming features or preprocessors that are in play.
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…