I love regular expressions
-
At least the non-backtracking subset. DFA regular expressions. - they are a compact way to describe a simple syntax - they are plain text and brief, easily communicatable and transferable - they are cross platform (at least DFA), running in most any engine - they are incredibly efficient (again, DFA) - they are versatile, able to do validation, tokenization, and matching as well That's probably why they will always be with us. They are maybe the perfect canonical execution of a Chomsky type 3 language. Sure, they can be really terse, but this is as much a strength as it is a weakness, because it facilitates some of the above. I know some people hate them, and I can understand that. But show me a better way.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Joking aside, more trivially I believe the term "regular" refers to the third level of Chomsky's hierarchy, which, precisely, is defined as Type3-Regular. DFA (Deterministic Finite Automaton) are FSA (Finite State Automaton).
What the absolute ever. :-D
-
Love your sig 🤣🤣🤣
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
At least the non-backtracking subset. DFA regular expressions. - they are a compact way to describe a simple syntax - they are plain text and brief, easily communicatable and transferable - they are cross platform (at least DFA), running in most any engine - they are incredibly efficient (again, DFA) - they are versatile, able to do validation, tokenization, and matching as well That's probably why they will always be with us. They are maybe the perfect canonical execution of a Chomsky type 3 language. Sure, they can be really terse, but this is as much a strength as it is a weakness, because it facilitates some of the above. I know some people hate them, and I can understand that. But show me a better way.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Love how you post an opinion - always a valid one - and then (I assume) watch the conversation roll through. Bet you’re a gem at parties. I learned the basics of regular expressions many years ago when learning Perl. While I still use it on occasion for simple searches involving a specific character sequence, I don’t use it regularly (pun acknowledged) - aside from a few functions like email-check etc.
Time is the differentiation of eternity devised by man to measure the passage of human events. - Manly P. Hall Mark Just another cog in the wheel
-
:) close cobol brings back a lot programming memories
"A little time, a little trouble, your better day" Badfinger
-
Love how you post an opinion - always a valid one - and then (I assume) watch the conversation roll through. Bet you’re a gem at parties. I learned the basics of regular expressions many years ago when learning Perl. While I still use it on occasion for simple searches involving a specific character sequence, I don’t use it regularly (pun acknowledged) - aside from a few functions like email-check etc.
Time is the differentiation of eternity devised by man to measure the passage of human events. - Manly P. Hall Mark Just another cog in the wheel
It's because I slept. :) But yeah, I get bit overwhelmed when I get a lot of responses, so I kind of respond as I'm able.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Oh yes! Two, if you're a Yank :)
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
how about natural language to regex translator? such a thing? i am checking.
"A little time, a little trouble, your better day" Badfinger
It seems like it would be difficult to describe a non-trivial match in human language. Though you might be able to feed a regex expression to ChatGPT and ask it what it matches - sort of the reverse of what you suggested.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
how about natural language to regex translator? such a thing? i am checking.
"A little time, a little trouble, your better day" Badfinger
A long time ago I wrote a tool. The tool allowed you to multiply select portions of text and it would attempt to generate regexs that would only match the selected text It didn't work very well, at least my implementation but I think the idea has merit.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm absolutely with you on that. Also, with PCREs, the /x switch allows you to indent and comment to your heart's content, so you can write perfectly legible code, and there are on-line engines where you can drop your expression and your input and watch step by step while it does its magic. I'm not sure that I do a day's work without writing a regex and I know of no tool with anywhere near the power for parsing text. ~~~~~~~~ <°}}}>«<
seismofish wrote:
I know of no tool with anywhere near the power for parsing text.
Well, tokenizing text at least. :) I've written plenty of parsers, everything from LL(1) to GLR. GLR is the most powerful parsing algorithm I know of, allowing you to parse ambiguous grammars and return one tree for each possible interpretation. My parsers almost always use regex to tokenize, but they don't use it to parse. Instead, I take those tokens, and a Push Down Automaton and use that to generate trees. Sorry, not trying to be pedantic so much as continue to convo.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
The problem with regular expressions, is that most of us use them once every couple of years and we have to relearn everything from scratch every time. For someone who's doing RE everyday, it's simple; I used to have a boss that was like that; we all went to her to write/debug our RE. (and we never document the RE in the code :rolleyes: )
CI/CD = Continuous Impediment/Continuous Despair
A modest proposal: Learn the DFA subset. Commit it to memory, and forget the rest. DFA is the non-backtracking subset of regular expressions () - capture and group [] - match char ranges * - match zero or more + - match one or more ? - match zero or one . - match any single character | - match a or b (a|b)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
At least the non-backtracking subset. DFA regular expressions. - they are a compact way to describe a simple syntax - they are plain text and brief, easily communicatable and transferable - they are cross platform (at least DFA), running in most any engine - they are incredibly efficient (again, DFA) - they are versatile, able to do validation, tokenization, and matching as well That's probably why they will always be with us. They are maybe the perfect canonical execution of a Chomsky type 3 language. Sure, they can be really terse, but this is as much a strength as it is a weakness, because it facilitates some of the above. I know some people hate them, and I can understand that. But show me a better way.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
At least the non-backtracking subset. DFA regular expressions. - they are a compact way to describe a simple syntax - they are plain text and brief, easily communicatable and transferable - they are cross platform (at least DFA), running in most any engine - they are incredibly efficient (again, DFA) - they are versatile, able to do validation, tokenization, and matching as well That's probably why they will always be with us. They are maybe the perfect canonical execution of a Chomsky type 3 language. Sure, they can be really terse, but this is as much a strength as it is a weakness, because it facilitates some of the above. I know some people hate them, and I can understand that. But show me a better way.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Memories? I still use it.
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
Richard Attenborough voice in his semi-whisper: Behold, the rare COBOL programmer in the wild, they used to roam in giant herds but are now solitary creatures. What will become of the banking ecosystem when the species becomes extinct?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
StarNamer@work wrote:
"why can't they just put the letters in alphabetical order so they're easy to find?"
A better question is "why are we so enslaved to tradition that we keep using a layout optimized for the Remington No 2 mechanical typewriter over 100 years ago?" And, please, don't get me started on the sexagesimal system used for time and degrees! :D
Mircea
Mircea Neacsu wrote:
why are we so enslaved to tradition that we keep using a layout optimized for the Remington No 2 mechanical typewriter over 100 years ago
I believe because, despite claims (and faked data), no alternative has been shown to actually be better. If I recall correct one of the magazines, either "Skeptical Inquirer" or "Skeptic" had at least one article in say the past 10 years that documented the history of that. Possible that there might be some that are as good as, but then that by itself is no reason to switch.
-
The problem with regular expressions, is that most of us use them once every couple of years and we have to relearn everything from scratch every time. For someone who's doing RE everyday, it's simple; I used to have a boss that was like that; we all went to her to write/debug our RE. (and we never document the RE in the code :rolleyes: )
CI/CD = Continuous Impediment/Continuous Despair
-
At least the non-backtracking subset. DFA regular expressions. - they are a compact way to describe a simple syntax - they are plain text and brief, easily communicatable and transferable - they are cross platform (at least DFA), running in most any engine - they are incredibly efficient (again, DFA) - they are versatile, able to do validation, tokenization, and matching as well That's probably why they will always be with us. They are maybe the perfect canonical execution of a Chomsky type 3 language. Sure, they can be really terse, but this is as much a strength as it is a weakness, because it facilitates some of the above. I know some people hate them, and I can understand that. But show me a better way.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
I know some people hate them,
I certainly don't hate them since I use them quite a bit. Of course no one provides a comment for what they are intended to match. Nor how the match works. But I have seen quite a few that I knew to be wrong. That is concerning.
honey the codewitch wrote:
- they are cross platform (at least DFA), running in most any engine
Not sure what you mean by that. The engine that runs the regex is the only 'cross platform' part possible in that. The regex expressions themselves depend only on the engine so the expression itself has nothing to do with the platform. Perhaps you were referring to that the simplest syntax works in different engines though. But once one uses something more complex that is not necessarily true. But at least with javascript, java and C# they to a great extent use the same syntax.
-
Richard Attenborough voice in his semi-whisper: Behold, the rare COBOL programmer in the wild, they used to roam in giant herds but are now solitary creatures. What will become of the banking ecosystem when the species becomes extinct?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
A long time ago I wrote a tool. The tool allowed you to multiply select portions of text and it would attempt to generate regexs that would only match the selected text It didn't work very well, at least my implementation but I think the idea has merit.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
At least the non-backtracking subset. DFA regular expressions. - they are a compact way to describe a simple syntax - they are plain text and brief, easily communicatable and transferable - they are cross platform (at least DFA), running in most any engine - they are incredibly efficient (again, DFA) - they are versatile, able to do validation, tokenization, and matching as well That's probably why they will always be with us. They are maybe the perfect canonical execution of a Chomsky type 3 language. Sure, they can be really terse, but this is as much a strength as it is a weakness, because it facilitates some of the above. I know some people hate them, and I can understand that. But show me a better way.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I use regular expressions regularly. The downside is that it is difficult for newcomers to understand them. But as long as you add comments to your code it shouldn't be a problem. And many languages allow you to add comments WITHIN the regular expressions, making them even easier to understand. (I frequently create my regexes with comments in C# and then take out the comments afterwards, leaving the original version within commented-out code.)