Hacker News Reader

Comment by losvedir | Hacker News Reader

Yesod is surreal.

I experimented with it at one point and tried to change a form field from required to optional. Boom! The whole application wouldn't compile...

The properties of the form are reflected in the type system and changing required to optional changed the type. That means I had to track the effect through the application and everywhere that just assumed the data was there had to be updated to handle both cases.

It was so restrictive and confusing I gave up for the time being (until I learn Haskell better), but it was an eye-opening glimpse of the power of types.

View on HN

That's actually one of the reasons I like it. Instead of allowing your application to live in a half-working state, you're required to fix such things.

While it might not be as instantly gratifying and being able to refresh and see the page is still working, in the long run it saves a lot of headache.

I would strongly prefer to work in an environment that detected the error and gave me the power to trace through the app to resolve it while still letting the damn program run in the mostly-working state. The mental cost to review hundreds of lines of code to work out the implications of every change before you can see any results is a problem - it breaks the creative flow, it prevents experimentation.

The mental cost to review hundreds of lines of code to work out the implications of every change before you can see any results is a problem - it breaks the creative flow, it prevents experimentation.

Type errors don't require such a mental cost. Once you learn how to actually read the error messages it becomes almost brain-dead simple. Compile, jump to the error message (hopefully your editor can help here), fix, recompile.

it breaks the creative flow, it prevents experimentation.

I disagree. What prevents experimentation is the fear of the unknown regression. Strong types give you the reassurance you need to boldly refactor without worrying that you'll miss something.

Aren't the errors generated by nonconforming types a way to trace through the app? That's the point of a strong type system: code that by definition won't work isn't allowed to run.

  ghc -fdefer-type-errors

I wonder if this isn't an argument for optional typing. Experiment earlier, track down possible bad paths later

I'm not using Haskell for things like this yet, but I must admit, this is one of the features that draws me to it as a language for web development. The idea of type safe HTML and requests is really interesting to me.

Have you heard of Ur? It takes this idea even further - http://www.impredicative.com/ur/

This sounds like the big win that's promised with type systems.

I really feel like Snap is a much more pragmatic approach to types. Where Yesod uses tons of metaprogramming and DSLs to make HTML and CSS type safe, Snap focuses on being a great Haskell system and HTML/CSS continue to be whatever they are. In practice this seems to be a good trade off because to get type safety in HTML/CSS the way Yesod does, you take on a lot of complexity and black magic.

The one place I wish I had better type safety in Snap is the SQL level. Yesod has Persistent which you can use with Snap but Persistent follows the same "black magic" design principles. I really wish there was a tool that handled PostgreSQL-specific query type checking and migration and that's it. No JSON/noSQL to SQL abstraction etc (which is cool if you want it but just a lot of if you don't). Once I pick a DB I don't want to constantly be generalizing away from it which is a conceptual overhead.

While I agree to some extent, I have to say the metaprogramming in Yesod does a good job at exposing solid information models for its abstractions, unlike, say reflection based metaprogramming in C# or Java. I find it pretty easy to bend it to my will, even if Yesod itself is quite opinionated.

Reply on news.ycombinator.com