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

51–60 of 64 posts

Re: Learn Regex The Hard Way

#51

Post by haraball »

scorpion032 wrote: post #45
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?

Your wish has been granted: http://txt2re.com/ I use this all the time. No wonder I don't know to hand write a Regex.

Here's another tool I use when testing my regex: http://regexpal.com/

Nice tool for testing the regex on a given data set.

Re: Learn Regex The Hard Way

#52

Post by furyg3 »

zedshaw wrote: post #18
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.…

Yep, I'm going at it from another direction where I teach the symbols like a language, and then it makes it easier to explain how they work later. I agree that state machines are a great way to understand them, but I don't think they're practical for using them and they just complicate getting capable in it.

Just wanted to chime in, thanks a lot for making the guide with this approach. Sysadmins, specifically, will find this to be a great resource.

Many people start out tweaking config files, editing other's scripts, manipulating logs and output data, and then eventually sit down and say "Damn, it's about time I learned how to really write good [bash/perl/python/regex]". I find the theory behind it interesting, but it's a bit of a distraction for many.

Re: Learn Regex The Hard Way

#53

Post by Locke1689 »

YuriNiyazov wrote: post #48
zedshaw wrote: post #24

Earlier quoted context omitted.

I don't think your opinion is shit, I just think your perspective has changed because you actually can code. The hardest thing for a beginner is just the syntax. If you've never written code before then the symbols in programming are alien as hell. By focusing on seemingly repetitive syntax drills I get them skilled progressively until syntax isn't a problem. Another thing you might be missing is under each exercise…

I agree that syntax is the hardest thing. Based on my experience tutoring, I would add the following (which was surprising to discover at first): the second hardest thing is the order of evaluation. I've seen students write down a = do_something1(do_something2()) and be unable to explain that do_something2() actually happens before do_something1(), and to see that the code is loosely equivalent to b = do_something2()…

The worst is when you're teaching C and you have to explain that

    void * a = do_something1(do_something2(), do_something3());
is not equivalent to

    int b = do_something2();
    int c = do_something3();
    void * a = do_something1(b, c);

Re: Learn Regex The Hard Way

#54

Post by marchdown »

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

I know the theory pretty well, but writing actual regexes always felt so slow and frustrating that I really welcome this kind of rote hand-holding tutorial. I might finally learn the arbitrary DSL that everyone seems to have settled on.

Re: Learn Regex The Hard Way

#55

Post by YuriNiyazov »

Locke1689 wrote: post #53
YuriNiyazov wrote: post #48

Earlier quoted context omitted.

I agree that syntax is the hardest thing. Based on my experience tutoring, I would add the following (which was surprising to discover at first): the second hardest thing is the order of evaluation. I've seen students write down a = do_something1(do_something2()) and be unable to explain that do_something2() actually happens before do_something1(), and to see that the code is loosely equivalent to b = do_something2()…

The worst is when you're teaching C and you have to explain that void * a = do_something1(do_something2(), do_something3()); is not equivalent to int b = do_something2(); int c = do_something3(); void * a = do_something1(b, c);

Because the order of evaluation of arguments is not defined?

Re: Learn Regex The Hard Way

#56

Post by bad_user »

mekoka wrote: post #7
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.…

I'm not a CS graduate. I first learned of state machine from an article posted here on HN a few months ago. I learned regular expression from the regular-expression.info site and from the first 4 chapters of Jeffrey Friedl's book over 5 years ago. I don't recall an introduction to NFA/DFA from them either. I'm pretty comfortable with regex and use them regularly (no pun intended) and so far, I don't feel that I've mi…

An understanding of finite-state machines is useful, because that way you'll understand the limitations you have when using regular expressions, which have been grossly misused.

It also helps you write optimal regular expressions - for instance if your regular expression clearly describes a DFA, then it will probably perform well. Otherwise in many cases you can optimize it - just as you can turn any NFA into a DFA.

It isn't so clear and cut these days however, as the regexp capabilities provided by modern libraries exceed the capabilities of finite state machines - for instance the engine in Perl 5.10 has support for recursion, which means a regular expression in Perl 5.10 can describe a Pushdown Automaton (PDA) instead, so things get way more complicated.

Either way, I suggest you do some reading on Automata Theory, because it's fun and not that hard.

Re: Learn Regex The Hard Way

#57

Post by spp »

mekoka wrote: post #7
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.…

I'm not a CS graduate. I first learned of state machine from an article posted here on HN a few months ago. I learned regular expression from the regular-expression.info site and from the first 4 chapters of Jeffrey Friedl's book over 5 years ago. I don't recall an introduction to NFA/DFA from them either. I'm pretty comfortable with regex and use them regularly (no pun intended) and so far, I don't feel that I've mi…

Chapter 4 of Jeffrey Friedl's "Mastering Regular Expressions" goes in depth about NFA/POSIX NFA/DFA. It even has car analogies!

Re: Learn Regex The Hard Way

#58

Post by drmohundro »

zedshaw wrote: post #24
nikcub wrote: post #10

Earlier quoted context omitted.

as a Python dev I scanned the python book and I thought it dwelled too much on string formatting, focused on teaching syntax and not programming, and the language was a bit terse. but then a friend of mine told me that he and a few other people he knew learnt python from that book, so either later revisions got better or my opinion is shit.

I don't think your opinion is shit, I just think your perspective has changed because you actually can code. The hardest thing for a beginner is just the syntax. If you've never written code before then the symbols in programming are alien as hell. By focusing on seemingly repetitive syntax drills I get them skilled progressively until syntax isn't a problem. Another thing you might be missing is under each exercise…

I'm a CS grad, but I had zero knowledge of programming when I entered college - I knew some basics about HTML and I could fix some basic computer issues but that is it. I remember trying to open an executable in Notepad and thinking to myself, "uh oh, this is going to be really hard."

I was still struggling with syntax issues into my second year of school. It's not a good feeling to be debugging null pointer issues and data structures when you're not confident with the syntax.

Re: Learn Regex The Hard Way

#59

Post by TWAndrews »

chrisguitarguy wrote: post #25
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?

It's just like teaching anything: nothing is really fun until you can do something. I teach guitar, so let me use that as an example: it's my job as a teacher to get students to love the guitar so they (1) continue with it, and (2) come to the next lesson. the only way I can make sure students get excited is if they can do some thing. So I could bog them down with a bunch of theory and stuff, or explain the mechanics…

Learn Guitar the Hard Way would be an awesome addition to the mix.

Re: Learn Regex The Hard Way

#60

Post by mattwilsoninc »

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'm on the first legs of the Learn Python the hard way. I like the examples and explanation. Doing it is really the best way to learn. The great aspect about the book/course is that Zed provides examples of pitfalls that come with experience, so you learn the language at a faster rate.
Post reply on HN