Parse, Don't Validate (2019)

Post by np_tedious » Sat, Jun 26, 2021, 1:56 PM UTC

chriswarbo wrote: post #69

seanwilson wrote: post #48

From the Twitter link: > IME, people in dynamic languages almost never program this way, though—they prefer to use validation and some form of shotgun parsing. My guess as to why? Writing that kind of code in dynamically-typed languages is often a lot more boilerplate than it is in statically-typed ones! I feel that once you've got experience working in (usually functional) programming languages with strong static ty…

I have the same feeling after spending a few years with Haskell, StandardML, Agda, Idris, Coq, etc. One trick I've found very useful is to realise that Maybe (AKA Option) can be though of as "a list with at most one element". Dynamic languages usually have some notion of list/array, which we can use as if it were a Maybe/Option type; e.g. we can follow a 'parse, don't validate' approach by wrapping a "parsed" result…

Post by mixedCase » Sat, Jun 26, 2021, 1:57 PM UTC

inbx0 wrote: post #60

k__ wrote: post #56

Earlier quoted context omitted.

Is using "row polymorphism" the same as using a "structutal type system"? I never heard about the former.

Not really, and correct me if I'm wrong but afaik TS doesn't actually do row polymorphism so much as structural subtyping - although the difference between the two is pretty small and you can get pretty close to row polymorphism with structural subtyping + generics. But even if these were the same thing and we want to be a bit pendantic since this is HN after all, structural type systems often support some kind of su…

  function rowPolymorphic(record: R): R & { a: string } {
    return {
      ...record,
      a: record.a.toString(),
    }
  }

  const rec = rowPolymorphic({
    a: 123,
    b: "string",
  })
  console.log(rec.b)

Post by adamlett » Sat, Jun 26, 2021, 2:00 PM UTC

Zababa wrote: post #65

adamlett wrote: post #59

I think making this about the type checker is a bit of a red herring. There is nothing in this – otherwise excellent – advice that can’t be applied to a dynamically typed language like Ruby. It’s the same insight that leads OOP folks to warn against the Primitive Obsession code smell ( http://wiki.c2.com/?PrimitiveObsession ). It’s also the insight that leads to the Hexagonal Architecture ( https://en.wikipedia.org/w…

The advantage of the type checker is that it automatically check types for you. If you have only one function that produces a parsedArray and multiple functions that accept a parsedArray, you can be sure where they come from.

Post by kortex » Sat, Jun 26, 2021, 2:04 PM UTC

ukj wrote: post #68

kortex wrote: post #67

Earlier quoted context omitted.

Sure you can. You just need the right amount of indirection and abstraction. I think almost every language has some escape hatch which lets you implement dynamic dispatch.

This is a trivial and obvious implication of Turing completeness. Why do you even bother making the point? With the right amount of indirection/abstraction you can implement everything in Assembly. But you don't. Because you like all the heavy lifting the language does for you. First Class citizens is what we are actually interested in when we talk about programming language paradigm-choices. https://en.wikipedia.org…

Post by dkersten » Sat, Jun 26, 2021, 2:07 PM UTC

ukj wrote: post #68

kortex wrote: post #67

Earlier quoted context omitted.

Sure you can. You just need the right amount of indirection and abstraction. I think almost every language has some escape hatch which lets you implement dynamic dispatch.

This is a trivial and obvious implication of Turing completeness. Why do you even bother making the point? With the right amount of indirection/abstraction you can implement everything in Assembly. But you don't. Because you like all the heavy lifting the language does for you. First Class citizens is what we are actually interested in when we talk about programming language paradigm-choices. https://en.wikipedia.org…