3 ms·
I think it's easier in general to work on an application that's up and running . Architecting a new system in a language you're new to would be much more time c
by justinhj 13y ago
I think it's easier in general to work on an application that's up and running . Architecting a new system in a language you're new to would be much more time consuming. But in the case where the groundwork is laid you get by with much less language depth. Recent someone posted on here about how financial analysts were able to use a subset of Haskell in the field without really having to think of it as programming at all, as all the plumbing under the DSL is covered up.
- implicit 13y agoI'm the author of the article. This is very true in every language, and doubly so in Haskell. If you just take the language as it is without any context, the language leaves whole classes of problems with a ridiculous overabundance of potentially viable solutions. The one that springs to mind most prominently is error handling. What's the right way to do this? Option types? Exceptions? EitherT? We even explored a library that used type classes to provide Java-style checked exceptions. We sorted this out early, when the "team" was just 2 people working in extra hours, but if we'd still been in that state when we scaled up, the project would have been a disaster. FYI, the solution we came up with was to use option types for all recoverable errors. We only use exceptions for nonrecoverable failures that should trigger production alerts.