Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn Regex The Hard Way

regex.learncodethehardway.org

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Learn Regex The Hard Way

#31

Post by capkutay »

delwin wrote: post #5

What do you guys think of Zed Shaw's teaching style? As I'm not a beginner programmer, I can't really evaluate correctly — to me it seems like a odd approach to programming pedagogy, but perhaps it works. Any non-programmers want to shed light on why his style works?

I went through LPTHW without losing motivation, wanting to quit, or being too confused to go on. I'd say this is what really sets it apart from other programming books. Also, very functional. You know what you're doing every step of the way and he tries to speak to you like a person while helping you graspt the material. There were only a few instances doing the extra credit where I really felt stuck. His books force you to write a lot of code. After 1/2 way, I'd genuinely be excited to go to the next chapter. In terms of simulating your own personal CS tutor, LPTHW was awesome.

Re: Learn Regex The Hard Way

#32

Post by irahul »

jdthomas wrote: post #3

Not to sound like a pretensions CS guy ... but how can you have a book on regular expressions without even mentioning DFA/NFA? Maybe its just me, but (back in my day) I found learning about finite automata made regex just click. Edit: ahh, I see now mentioned in intro that "I'm going to be very practical and straight forward about it. No NFA to DFA conversion. No crazy explanations of push down finite state automata.…

Personally I don't find NFA/DFA helpful with learning regular expressions.

To a newcomer, even a naive implementation of NFA/DFA doesn't make sense. Consider this small gist https://gist.github.com/1414061

I have a feeling a newcomer will come out none the wiser even if he were shown this. And this is just a naive implementation - no nfa to dfa conversions, inefficient implementation etc.

I would root for state diagrams though. Generally diagrams help people see patterns mere text doesn't.

Re: Learn Regex The Hard Way

#33

Post by zedshaw »

mturmon wrote: post #30

The regex shell is a neat idea. In many situations I'd like to generate strings accepted by the regex, to check that my regex is tight enough. I know this is hard in general (for lots of reasons, basically all reducing to "there are a lot of strings and no easy way to iterate through them in a satisfying way"). But, has anyone made any progress on this for the "easy" cases?

I thought about trying but it's hard to dip into the regex data structure (if there is one) and also display it in some sort of meaningful way.

Other than that, Regetron is kind of just enough of a tool to get you through the book and have no friction. I think for more advanced regex exploration there's http://kodos.sourceforge.net/ and I believe there's a few javascript ones in the browser and even a few very advanced ones in Java.

Re: Learn Regex The Hard Way

#34

Post by irahul »

suivix wrote: post #4

The (?i) is a confusing part of that example expression, and I don't see why it's necessary.

It's good to know about it. Earlier at an employer we had a system where a processor in the pipeline took regular expressions as input - you can pass regular expressions but not the flags. (?i) is the only way you can indicate case-insensitive in these cases.

Re: Learn Regex The Hard Way

#35

Post by tbrooks »

zedshaw wrote: post #33
mturmon wrote: post #30

The regex shell is a neat idea. In many situations I'd like to generate strings accepted by the regex, to check that my regex is tight enough. I know this is hard in general (for lots of reasons, basically all reducing to "there are a lot of strings and no easy way to iterate through them in a satisfying way"). But, has anyone made any progress on this for the "easy" cases?

I thought about trying but it's hard to dip into the regex data structure (if there is one) and also display it in some sort of meaningful way. Other than that, Regetron is kind of just enough of a tool to get you through the book and have no friction. I think for more advanced regex exploration there's http://kodos.sourceforge.net/ and I believe there's a few javascript ones in the browser and even a few very advanc…

I'm sure this has made the rounds before: http://rubular.com/

Re: Learn Regex The Hard Way

#36

Post by spicyj »

zedshaw wrote: post #26
leeoniya wrote: post #6

just decided to randomly click a chapter. in 12.1 wouldn't ^[0-9]+|[A-Z]+$ in fact need to be written as ^([0-9]+|[A-Z]+)$ or non-capturing ^(?:[0-9]+|[A-Z]+)$ i doubt the intent was to alternate NL/EOL assertion. seems like a novice oversight and does not instill confidence in the rest of the material. or am i missing something?

Hmm, well the book is being written so there's potential for some errors, but I believe you are wrong here. You're confusing match with search semantics. Your above works because by default Regetron searches. If you turn on match it doesn't match your proposed test below. Try this: http://codepad.org/uPpwKPJS Notice when you turn on !match it doesn't find your test. Also, keep in mind that this is just introducing th…

I agree with the GP --

http://codepad.org/YmsaEtJS

Re: Learn Regex The Hard Way

#37

Post by zedshaw »

spicyj wrote: post #36
zedshaw wrote: post #26

Earlier quoted context omitted.

Hmm, well the book is being written so there's potential for some errors, but I believe you are wrong here. You're confusing match with search semantics. Your above works because by default Regetron searches. If you turn on match it doesn't match your proposed test below. Try this: http://codepad.org/uPpwKPJS Notice when you turn on !match it doesn't find your test. Also, keep in mind that this is just introducing th…

I agree with the GP -- http://codepad.org/YmsaEtJS

Great, another example of regex engines not doing anything you tell them. I'll look at changing it but () isn't going to work there it has to be taught later.

Re: Learn Regex The Hard Way

#38

Post by scrame »

Thats pretty awesome. Regex's the tool (vs. the concept of "regular expressions" that comes up in interpreters/compilers) is a supremely useful utility when used sparingly, and surprisingly portable between languages.

Regex's are in a (not-)sweet spot of practical languages that aren't taught in school. For all the hype of ruby, et al. being able to make "DSL's", its surprising how mystical an _actual_ DSL, that is portable between languages (through PCRE) is held.

Unfortunately, like many other tools, can be used sparingly after a lot of practice writing crappy regex's, and having to eat your own dogfood (so you learn its not an "ultra-fast parser", or that you shouldn't chain substitutions on user-generated input).

A rote tutorial -- in the style of LPTHW -- is excellent.

Re: Learn Regex The Hard Way

#39

Post by zedshaw »

spicyj wrote: post #36
zedshaw wrote: post #26

Earlier quoted context omitted.

Hmm, well the book is being written so there's potential for some errors, but I believe you are wrong here. You're confusing match with search semantics. Your above works because by default Regetron searches. If you turn on match it doesn't match your proposed test below. Try this: http://codepad.org/uPpwKPJS Notice when you turn on !match it doesn't find your test. Also, keep in mind that this is just introducing th…

I agree with the GP -- http://codepad.org/YmsaEtJS

Ok, both of you are wrong. It's got nothing to do with EOL, it's the parse order of precedence of | which makes it parse as (or (^[0-9]+) ([A-Z]+$)), but I was reading it as ($ (^ (or ([0-9]+) ([A-Z]+)))). Now I know why I should change it rather than I just suck.

Re: Learn Regex The Hard Way

#40

Post by spicyj »

zedshaw wrote: post #39
spicyj wrote: post #36

Earlier quoted context omitted.

I agree with the GP -- http://codepad.org/YmsaEtJS

Ok, both of you are wrong. It's got nothing to do with EOL, it's the parse order of precedence of | which makes it parse as (or (^[0-9]+) ([A-Z]+$)), but I was reading it as ($ (^ (or ([0-9]+) ([A-Z]+)))). Now I know why I should change it rather than I just suck.

I'm not exactly sure how you thought I was interpreting it -- that's exactly how I understood the original comment and I still think that was leeoniya's point.
Post reply on HN