[actionfromafar]

Disregarding the article for a second, has anyone else had the pattern that "parse don't validate" makes sense in object oriented style, but less sense in functional style programming? Like parsing and validating blurs into each other.

[LittleLily]

In my experience it makes even more sense in functional programming languages, not less, since they usually also have more powerful type systems that help with actually representing parsed vs unparsed data.

[gspr]

> Disregarding the article for a second, has anyone else had the pattern that "parse don't validate" makes sense in object oriented style, but less sense in functional style programming?

Parse, don't validate was written around Haskell!

[actionfromafar]

What I tried and apparently failed to express with "parsing and validating blurs into each other." was that parsing more easily becomes "just what you do" in functional style of programming. To the point that nowadays I can no longer really remember what I did back when I tried to "validate" things instead of parsing them.

[andrepd]

The tl;dr is that instead of representing emails as type String and manually sprinkling is_email(str) throughout your code, you represent as type Email, which has a function parse(String) -> Option<Email>. The type system then ensures the checks are present whenever they have to be, and nowhere else.

This is extremely natural to do in a language like Haskell or Rust. And incredibly unnatural to do in C++ for instance.

[short_sells_poo]

I hope this is not trolling so I'll bite. It is incredibly natural to represent an object, such as an email, as an Email class in object oriented languages like C++. It'd then have a constructor that accepts a string and constructs the email object from said string, or maybe a parse(string) -> Option<Email> thingy. The type system then ensures the checks are present whenever they have to be, and nowhere else.

Tl;dr: there's nothing extra that functional or OO programming give you here. Both allow you to represent the problem in a properly typed fashion. Why would you represent an email as a string unless you are a) deeply inexperienced or b) have some really good reason to drop all the benefits of a strongly typed language?

[bananaboy]

I completely agree with you but I think sometimes folks carry some piece of data around as a string or int instead of something more concrete like a class or a strongly typed enum etc purely out of laziness!

[MarsIronPI]

I think the old Lisp tradition of using lists for everything is related to this somehow. On the other hand, in Common Lisp programmers can define custom types that have to fulfill a predicate function. Then, if they declare the types of their functions, most implementations will generate type-checking code unless instructed not to. So in Common Lisp you can use lists for everything but still have type-checking, at some cost to efficiency. :D

[leodavi]

Well, in C++ the constructor must return a value of its class type - you can't return an Option<T> from a constructor on T, for example, and since constructors are the canonical way to construct an object, it creates stylistic and idiomatic friction when you start using free functions to create a Maybe<T> instead of constructors.