6 ms·

That was a fun read, and I loved that little joke with NPM packages. I find SQL, Regular Expressions, DNS, Client-side caching, CORS, TLS, and a few other thin

by Ayesh 4y ago

That was a fun read, and I loved that little joke with NPM packages. I find SQL, Regular Expressions, DNS, Client-side caching, CORS, TLS, and a few other things to be a MUST when hiring people, because most of the over-engineered crap can be avoided with a little bit of expertise with these. I spend most of my semi-leisure time with some good Regex books and golfing too. Modern databases are amazing. Every few months, I take pleasure and not shy away in refactoring some complex and frequent queries into SQL views, carefully replace data logic (but not business logic) into stored procedures, and replace certain batch scripts with one-off queries.

jjice 4y ago
Favorite regex books? Only one I've read is Mastering Regular Expressions by Jeffrey Fridel and I loved it. If you have any more recs, I'm all ears.
- ttfkam 4y ago
  Excellent book! I was only about 25-30 pages into the first edition when it all finally clicked for me. I've never feared a regex since.
masto 4y ago
I was recently discussing something that involved knowing whether a string consisted of only a single repeated character. Having spent many years in the trenches with Perl, my first thought was /^(.)\1*$|^$/, which is the kind of thing people dismiss as "line noise" because they haven't spent a few minutes learning a language that can easily express what you want. We have this trend now from people who like languages like Go where answering the question "does this string consist of a single repeated character" begins with "I would now like to reserve space for a 64-bit integer which I shall henceforth refer to as 'i'...", and that's considered a virtue.
- cbm-vic-20 4y ago
  Let's see if I remember Perl regexps: '/': this is a regular expression. '^' at the beginning of a line, '(.)' match any character, and remember it for later. '\1' match the same character that you just remembered, '*' zero or more times. '$' then match the end of the line. '|' Or, '^$' match the beginning and end of the line with nothing in between.
- yyyk 4y ago
  >reserve space for a 64-bit integer which I shall henceforth refer to as 'i' In this scenario, regex processing should allocate more and be slower. The for loop is more optimal even if takes more lines. There's probably some SIMD solution which would be the fastest.
  - marcosdumay 4y ago
    It's probably slower by a constant amount. It also probably allocates a constant amount of memory. On an compiled language, odds are that the regexp is faster and uses the same amount of memory.
- vsareto 4y ago
  >because they haven't spent a few minutes learning a language Regex is pretty far from an easy-to-learn language and you're going to need more than a few minutes with it. Like, imagine if a standard string library only had functions with a single character name and how awful that would be to use.
- wruza 4y ago
  s/\./[\\s.]/ iirc. Or s/\/$/&s/ if the engine implements it.
- edflsafoiewq 4y ago
  all(c == str[0] for c in str)
- tracker1 4y ago
  I think the only thing I might add is a guardrail for strings that are too long, and might behave really badly with regexp.
- Merad 4y ago
  To be honest this sounds like the very definition of "you solved the problem with regex, and now you have two problems". In essentially every language in existence the question you're asking can be solved with a simple loop and perhaps 3-4 lines of code. In many languages it's easily expressed as a one liner, i.e. (with C#) `s.All(c => c == s[0])`. I really don't get the love affair that some devs have with regex. In my 10 year career I think I don't think I've run into more than a dozen problems in a production system that _required_ regex to solve. When you're working with robust modern languages there's almost a solution other than regex that's significantly easier to understand + maintain, and probably a lot more performant to boot. Is regex useful for other things, especially cli stuff like grep and sed? Oh yes absolutely. But generally speaking I really don't want it in my code base unless there's no other choice.
  - RadiozRadioz 4y ago
    10 years and a dozen problems? Conversely, I encounter pattern matching problems and use RegEx near daily. Both these perspectives are anecdata, neither are useful. > and probably a lot more performant to boot I highly doubt your home-grown pattern matching functions could beat the decades of optimization that have gone into RegEx engines, in anything but the most trivial of patterns (like the one demonstrated here). Creating your own ad-hoc pattern matcher instead of using the ubiquitous one built into your language is like the junior in the article re-implementing JOINs. Sure, you may be able to beat the engine occasionally on particularly simple patterns, but I guarantee you'll lose out overall. RegEx is not inherently slow, and it is definitely possible to maintain. See industries with serious text processing demands like bioinformatics, where Perl is still used extensively. They could not operate like they do if they shied away from RegEx like many developers seem to.
    - pixelbath 4y ago
      > Creating your own ad-hoc pattern matcher instead of using the ubiquitous one built into your language GP was using LINQ, which is a first-class language construct in C#. I'll grant that it may not be _as_ optimized as Perl's regex routines, but it's hardly ad-hoc or slow.
- adammarples 4y ago
  len(set(x)) == 1
fifilura 4y ago
I am curious about the "but not business logic" part. Can you make it more concrete what are the parts that you chose not use SQL for?
- ttfkam 4y ago
  If the biz logic is about structured data storage and transformation, it belongs in the database. If the biz logic relates to data validation (data types and data affinity), it belongs in the database (and probably should be checked elsewhere as well). If it relates to data integrity and correctness (foreign keys, check constraints, uniqueness, cascade behavior, etc.), it belongs in the database. If it relates to communication with external services (email, queues, file storage, HTML rendering, data compression, scheduling, lookups to 3rd-party APIs, pure computation, etc.), it very much does not belong in the database. All of these are "business logic". All are important. Use the right tool for the job at hand. Set theory for the databases, general purpose computing for the app layer.
  - fifilura 4y ago
    Then I think we have different definitions of business logic? HTML rendering, email, data compression, ... for me never belonged to the business logic.
    - ttfkam 4y ago
      I could agree with HTML rendering and compression, but sending an email during user registration or as part of an event notification is 100% business logic.

by Ayesh 4y ago

jjice 4y ago

Favorite regex books? Only one I've read is Mastering Regular Expressions by Jeffrey Fridel and I loved it. If you have any more recs, I'm all ears.

ttfkam 4y ago
Excellent book! I was only about 25-30 pages into the first edition when it all finally clicked for me. I've never feared a regex since.

masto 4y ago

I was recently discussing something that involved knowing whether a string consisted of only a single repeated character. Having spent many years in the trenches with Perl, my first thought was /^(.)\1*$|^$/, which is the kind of thing people dismiss as "line noise" because they haven't spent a few minutes learning a language that can easily express what you want. We have this trend now from people who like languages like Go where answering the question "does this string consist of a single repeated character" begins with "I would now like to reserve space for a 64-bit integer which I shall henceforth refer to as 'i'...", and that's considered a virtue.

cbm-vic-20 4y ago
Let's see if I remember Perl regexps: '/': this is a regular expression. '^' at the beginning of a line, '(.)' match any character, and remember it for later. '\1' match the same character that you just remembered, '*' zero or more times. '$' then match the end of the line. '|' Or, '^$' match the beginning and end of the line with nothing in between.
yyyk 4y ago
>reserve space for a 64-bit integer which I shall henceforth refer to as 'i' In this scenario, regex processing should allocate more and be slower. The for loop is more optimal even if takes more lines. There's probably some SIMD solution which would be the fastest.
- marcosdumay 4y ago
  It's probably slower by a constant amount. It also probably allocates a constant amount of memory. On an compiled language, odds are that the regexp is faster and uses the same amount of memory.
vsareto 4y ago
>because they haven't spent a few minutes learning a language Regex is pretty far from an easy-to-learn language and you're going to need more than a few minutes with it. Like, imagine if a standard string library only had functions with a single character name and how awful that would be to use.
wruza 4y ago
s/\./[\\s.]/ iirc. Or s/\/$/&s/ if the engine implements it.
edflsafoiewq 4y ago
all(c == str[0] for c in str)
tracker1 4y ago
I think the only thing I might add is a guardrail for strings that are too long, and might behave really badly with regexp.
Merad 4y ago
To be honest this sounds like the very definition of "you solved the problem with regex, and now you have two problems". In essentially every language in existence the question you're asking can be solved with a simple loop and perhaps 3-4 lines of code. In many languages it's easily expressed as a one liner, i.e. (with C#) `s.All(c => c == s[0])`. I really don't get the love affair that some devs have with regex. In my 10 year career I think I don't think I've run into more than a dozen problems in a production system that _required_ regex to solve. When you're working with robust modern languages there's almost a solution other than regex that's significantly easier to understand + maintain, and probably a lot more performant to boot. Is regex useful for other things, especially cli stuff like grep and sed? Oh yes absolutely. But generally speaking I really don't want it in my code base unless there's no other choice.
- RadiozRadioz 4y ago
  10 years and a dozen problems? Conversely, I encounter pattern matching problems and use RegEx near daily. Both these perspectives are anecdata, neither are useful. > and probably a lot more performant to boot I highly doubt your home-grown pattern matching functions could beat the decades of optimization that have gone into RegEx engines, in anything but the most trivial of patterns (like the one demonstrated here). Creating your own ad-hoc pattern matcher instead of using the ubiquitous one built into your language is like the junior in the article re-implementing JOINs. Sure, you may be able to beat the engine occasionally on particularly simple patterns, but I guarantee you'll lose out overall. RegEx is not inherently slow, and it is definitely possible to maintain. See industries with serious text processing demands like bioinformatics, where Perl is still used extensively. They could not operate like they do if they shied away from RegEx like many developers seem to.
  - pixelbath 4y ago
    > Creating your own ad-hoc pattern matcher instead of using the ubiquitous one built into your language GP was using LINQ, which is a first-class language construct in C#. I'll grant that it may not be _as_ optimized as Perl's regex routines, but it's hardly ad-hoc or slow.
adammarples 4y ago
len(set(x)) == 1

fifilura 4y ago

I am curious about the "but not business logic" part. Can you make it more concrete what are the parts that you chose not use SQL for?

ttfkam 4y ago
If the biz logic is about structured data storage and transformation, it belongs in the database. If the biz logic relates to data validation (data types and data affinity), it belongs in the database (and probably should be checked elsewhere as well). If it relates to data integrity and correctness (foreign keys, check constraints, uniqueness, cascade behavior, etc.), it belongs in the database. If it relates to communication with external services (email, queues, file storage, HTML rendering, data compression, scheduling, lookups to 3rd-party APIs, pure computation, etc.), it very much does not belong in the database. All of these are "business logic". All are important. Use the right tool for the job at hand. Set theory for the databases, general purpose computing for the app layer.
- fifilura 4y ago
  Then I think we have different definitions of business logic? HTML rendering, email, data compression, ... for me never belonged to the business logic.
  - ttfkam 4y ago
    I could agree with HTML rendering and compression, but sending an email during user registration or as part of an event notification is 100% business logic.