101–105 of 105 posts
Earlier quoted context omitted.
No. Rule one is making code that works correctly and quickly, in a short about of time. This is 100% of the job. If you think that "maintainability" and "readability" and "popular" libraries, and "code reuse" and "good variable names" and code that "smells good" to you, help someone do that, then great: That's an argument we can have just by pointing to anyone who gets rule one without those things. However. There's…
> There's another kind of person - and there's a lot of them - who thinks those things are important by themselves , and that putting those things ahead of what I think are rule one is ever acceptable. I think you totally understood my humor. Thanks! I saw a good blog in 2011 about how it is a waste of time to overbuild things since mostly you are only ever going to use that code for the specific purpose you are writ…
I don't think those caveats are obvious to a junior (or otherwise inexperienced) developer. Maybe some of them are obvious, but I don't think anyone runs into these enough daily that programming by dogma actually helps.
And yet I do see value if there are rules! Why should we think about having "good variable names" or not if most of the time "good variable names" don't cause much harm, and most of the time not having them does?
It's just that I don't think this is a real problem; I don't believe anyone actually makes that choice.
I think if something doesn't have "good variable names" (as an example), then it's possible someone was programming who couldn't think of good ones (to which the rule wouldn't help anyway), and it's possible that these are good variable names, and that it's our opinion that is wrong (perhaps because we don't yet understand what we're looking at). NB) I'm not saying both are equally likely.
To put it another way, how can one recommend programming by brute force, "as long as you've got "readability" and "popular" libraries, and "code reuse" and "good variable names" and so on... What can we possibly add to that list that will be even a good substitute for a few decades of experience successfully delivering software?
Earlier quoted context omitted.
> Only send to eval what fits through a matcher for a very small subset of the language That's exactly what I meant by "dedicated expression parser". (Not sure why you name it "matcher", though. Please be aware that a regex-based matcher will almost certainly fail for that task. You usually want a grammar, i.e. parser, which is more powerful, and shorter, and easier to read and to verify.) EDIT: To those who downvote…
There is a difference between a recogniser, which answers the question "does this belong to the language", and a parser, which outputs a data structure. All you need here is a recogniser, and then pass the string through to eval which will do it's own parsing. Recognisers are smaller than parsers. If you relax the rules, as the gp said, you can get away with something like a regex to do the job. While regex's are bad…
Please note that the term "recogniser" is very fuzzy, it could mean a regex matcher, a parser or even a turing-complete thing. Not very helpful for this discussion.
> a parser, which outputs a data structure
Please note that a parser is not required to output a data structure. In classic computer science, the parser of a context-free grammar usually has a minimal (boolean) output: it just either accepts or rejects the input.
If your "recognizer" is too weak (e.g. regexes), you risk not properly checking the language (see below).
If your "recognizer" is too powerful (e.g. turing complete), you risk tons of loopholes which are hard to find and hard to analyze. You probably won't be able to prove the security, and even if you do, it will probably be hard work, and even harder for others to follow and to verify.
But if your "recognizer" is a parser, you have a good chance to succeed in a safe way with minimal effort. Proving security is as simple as comparing your grammar with the ECMAscript standard.
> you can get away with something like a regex to do the job [...] with the crazy things JS lets you do a recogniser for a relaxed language is likely to still let potentially dangerous code though
That's exactly my point: Sure, you can try to build a protection wall based on regexes, but there's no reason to do that. Use a proper parser right away and don't waste your time with repeating well-known anti-patterns.
Earlier quoted context omitted.
That would be awesome!
Okay :) We're still removing a few bytes but when it's done I'll make a commented version.
Earlier quoted context omitted.
There is a difference between a recogniser, which answers the question "does this belong to the language", and a parser, which outputs a data structure. All you need here is a recogniser, and then pass the string through to eval which will do it's own parsing. Recognisers are smaller than parsers. If you relax the rules, as the gp said, you can get away with something like a regex to do the job. While regex's are bad…
> difference between a recogniser Please note that the term "recogniser" is very fuzzy, it could mean a regex matcher, a parser or even a turing-complete thing. Not very helpful for this discussion. > a parser, which outputs a data structure Please note that a parser is not required to output a data structure. In classic computer science, the parser of a context-free grammar usually has a minimal (boolean) output: it…
All of the literature I remember from my uni days on formal grammers had a recogniser defined as something that accepts/rejects, and a parser as something that builds a data structure.
It's difficult to retrospectively find the literature, because outside of formal grammars recogniser _is_ used more loosely. But a few Wikipedia articles [1] [2] [3] and their referenced literature [4] [5] do agree with me.
> A recognizer is an algorithm which takes as input a string and > either accepts or rejects it depending on whether or not the string > is a sentence of the grammar. A parser is a recognizer which also > outputs the set of all legal derivation trees for the string.
[1] https://en.wikipedia.org/wiki/Parsing#Computer_languages
[2] https://en.wikipedia.org/wiki/Earley_parser#Earley_recognise...
[3] https://en.wikipedia.org/wiki/CYK_algorithm#Generating_a_par...
[4] http://reports-archive.adm.cs.cmu.edu/anon/anon/usr/ftp/scan...