A regular expression matcher By Rob Pike and Brian Kernighan (2007)
cs.princeton.edu
cs.princeton.edu
int matchstar(int c, char *regexp, char *text)
{
do { /* a * matches zero or more instances */
if (matchhere(regexp, text))
return 1;
} while (*text != '\0' && (*text++ == c || c == '.'));
return 0;
}I recommend implementing this as an exercise, rarely do you see that much classic CS theory put to a practical use in one place.
match :: String -> String -> Bool
match ('^':rest) text = matchLocal rest text
match rex (c:rest) = matchLocal rex (c:rest) || match rex rest
match _ _ = False
matchLocal :: String -> String -> Bool
matchLocal [] _ = True
matchLocal "$" [] = True
matchLocal (c:'*':restR) (t:restT) = c == t && matchLocal restR (starSkip c (t:restT))
matchLocal (r:restR) (t:restT) = (r == '.' || r == t) && matchLocal restR restT
matchLocal _ _ = False
starSkip :: Char -> String -> String
starSkip c (t:rest) = if c == t then starSkip c rest else t:rest
starSkip _ [] = []Adding a few lines of css (setting body width, font-size to 16, line-height to 1.4, Georgia for font and larger font size for headings ) makes for a decent reading experience.
body {
width: 70%;
font-size: 20px;
margin: auto;
font-family: sans-serif;
line-height: 30px;
}Sans-serifs are generally harder to read. Note, for example, how virtually all books are set in serifs. The primary reason sans-serifs are widely used in computers is the lack of decent display resolution required to display the actual serifs. So if you are using a larger font size to read something off the screen, there is no reason not to use a serifed typeface.
However, in typography and type designer circles it is commonly accepted that Serifs are superior for consuming large quantities of text. Also in layman terms - serifs make the glyphs more distinct and easier to recognize at a glance, in contrast to the sans where there are several glyph pairs that look virtually the same.
Experimental physicist comes to a theoretical physicist office,
bring a graph from a recent experiment and asks for a help with
interpreting the results.
- Well, it's all rather obvious. Here's a peak, here's a dip,
because of this, that and third.
- Hold it, hold it... you are looking at it upside down.
- Ah, right, right. *Rotates the graph*. Oh, it's now even more
obvious than before.
In other words, the "actual science" you are referring to frequently ends up to be nothing more than a matter of interpretation and a subject to all sorts of biases. Especially when it concerns something as unquantifiable as "comfort of reading". Just pick up a couple of fiction books, one set in serif and another in sans-serif, go through a pageful of text and see for yourself.Comfort of reading is very quantifiable. You can present text to a bunch of people in serif and sans serif fonts (double-blind and randomized) and ask them to rate how pleasant the text was. You can be clever and ask questions that measure understanding and retention, or you can ask them how much they enjoyed reading the passage, and these will give you indirect measures of reading comfort. Or you can be blunt and ask if they enjoy reading in the font, though this will pick up biases more. Either way is significantly more scientific than an appeal to common knowledge, though.
> Just pick up a couple of fiction books, one set in serif and another in sans-serif, go through a pageful of text and see for yourself.
This isn't science. This is just bias confirmation. ("Wow, I prefer the one I expected to prefer!")
But for the record, my e-reader font is set to Gill Sans.
Throwing around power words like "science" and "compelling evidence" based on a couple of references plucked from a blog post - sorry, but you are well in a meta area, preaching about general subject matter without any regard to the context. You are not the only one who's aware what science and scientific methods entitle, but then you should also be well aware of a bunch of junk that gets published in a format of scientific research, gets quoted and re-quoted and eventually accumulates notable status even though it hasn't even been peer-reviewed once. This happens all the time and it's a part of "science", so being skeptical is a part of the package. And the more obscure the area of the research, the more skepticism is warranted. You surely know that being that well-versed in all things science.
--
Your e-reader doesn't have the resolution required for good quality rendering of serif fonts. Hence the Gill Sans.You're right to be skeptical. You're not right to be dismissive.
--
My phone also uses sans-serif fonts almost exclusively and I read a ton of stuff on it. It definitely has a high enough resolution (>300ppi) for serif fonts.
The inferences we make about functional differences in the aesthetics of type would clearly be biased by this phenomenon. It might certainly be possible for controlled observations to reveal that reading speeds are faster for serif type; but this might be due to the fact that the reader is used to it, as most long works are already printed in serif type, in part due to the assumptions of book designers that serif type is faster to read!
Setting it as a percentage will obviously always make it look the same since it scales. However, a percentage on a huge screen usually makes it too wide to read lines comfortably.
You pretty much have to pick your poison, though IMO about 600 px is the maximum width for a line before it's horrible to read on a full hd screen.
max-width: 600px;
This stops your text from being excessively wide, but also doesn't prevent smaller screens from making it more narrow.Of course you could also use points or ems if you prefer.
But, having an extension like Stylebot installed and using a tiny custom CSS does offer an advantage - the CSS applies across the domain and takes effect every time the page is loaded.
For example, see this gallery - http://imgur.com/a/MxFtD
If you're going to judge this code based on both pathological haystacks but also pathological needle regexs, then you have to admit that this code, which has linear space usage in the pattern length is far better than PCRE, which has exponential time in the pattern length[1].
Considering its succinctness, I find that pretty impressive.
An equivalent would need to pass indexes to sub functions to avoid additional copies.
(I'd seen Pike's code years before in _The Practice of Programming_, so it's not independent.)
I will say that the problem is much easier if you have a good grounding in the basics of compilers, while that knowledge is not hugely useful very often. Any positive value as a test will come from correlation with interest in CS IMO.
The only bad part is that most candidates can't even write a correct strstr(3), so it becomes incredibly depressing.
This was really a most pleasurable and insightful read. True elegance!