Becoming Productive in Haskell • Hacker News Board

Re: Becoming Productive in Haskell

#151

Post by AnimalMuppet » Fri, Apr 24, 2015, 7:24 PM UTC

DanWaterworth wrote: post #64

lmm wrote: post #4

> So, I started calling it Mappable. Mappable was easy for me to remember and was descriptive of what it did. A list is a Functor. A list is Mappable. I wish there was a language or library that was willing to take the Haskell functionality and just give it all names like this.

This is actually possible with the ConstraintKinds extension in GHC. type Mappable = Functor type NotScaryFluffyThing = Monad This makes Mappable a synonym for Functor and likewise for Monad. (This is not necessarily a good idea; it goes against the principle of least surprise, but it'll work).

My code definitely needs more NotScaryFluffyThings in it.

Re: Becoming Productive in Haskell

#152

Post by hyperpallium » Fri, Apr 24, 2015, 7:26 PM UTC

QuantumRoar wrote: post #25

Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…

Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc.

But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and frozen.

I predicted that the natural resolution would be languages with both (i.e. optional static types, especially at important interfaces) - but while this feature exists, it hasn't taken off.

Instead it seems that performance is the main attraction of static types in the mainstream (java, c#, objective-c, c, c++); and ML-family and Haskell are popular where provable correctness is wanted.

Re: Becoming Productive in Haskell

#153

Post by hyperpallium » Fri, Apr 24, 2015, 7:26 PM UTC

QuantumRoar wrote: post #25

Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…

Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc.

But you're right, as projects get larger, a priori design and static types quickly become essential.

I predicted that the natural resolution would be languages with both (optional static types, especially at important interfaces) - but while this feature exists, it hasm t taken off.

such languages

Re: Becoming Productive in Haskell

#154

Post by akurilin » Fri, Apr 24, 2015, 7:32 PM UTC

pjungwir wrote: post #106

I've got a side project webapp I'd like to use to learn some Haskell. What is the most mainstream Rails-like web application framework out there? By Rails-like I mostly mean convention-over-configuration, with a strong ecosystem of plugins so I don't have to re-invent the wheel for auth, file uploads, etc. So far I've seen: - Yesod - Snap - Happstack - Scotty - Spock Right now I'm learning Yesod, but I don't feel con…

Yesod's great. There's a bit of a learning curve, but it comes with a LOT of batteries.

Re: Becoming Productive in Haskell

#155

Post by AnimalMuppet » Fri, Apr 24, 2015, 7:34 PM UTC

jayvanguard wrote: post #115

Guvante wrote: post #112

Earlier quoted context omitted.

While your point isn't invalid it is important to keep in mind that popularity is not a valid proxy for quality. Also he is focusing on large companies who have huge reasons they can't use Haskell, mostly related to internal resources. If you have several hundred Java engineers (for example) you literally cannot just switch to Haskell, it wouldn't work.

Completely agreed about quality. Popularity is highly correlated to actual utility though. Lisp falls into the same category. High quality and very interesting but it will never, ever gain widespread use. Don't believe me? A half century of proof exists. Haskell is already at a quarter century. Both are very cool and everyone should learn them to some degree because they will make you a better programmer but neither…

But beware lag time.

That is: Some languages aren't suitable for general use. Some aren't... and then they are. But popularity probably correlates with how suitable the language was at least two years ago, and maybe more like 10. (Call it 5 as a compromise.)

So popularity doesn't tell you that the language is unsuitable now. But I agree, there is a correlation. Programmers for the most part aren't stupid sheep, afraid to use something new.

Re: Becoming Productive in Haskell

#156

Post by tel » Fri, Apr 24, 2015, 7:47 PM UTC

JadeNB wrote: post #138

tel wrote: post #55

Earlier quoted context omitted.

I've personally found it very easy to handle "exceptions" in Haskell. Partial answers feel "bad" in Haskell because all the core functionality is clean enough to not need them, but on the other hand that makes for some of the best tools around for dealing with partiality.

> Partial answers feel "bad" in Haskell because all the core functionality is clean enough to not need them Not to need them, sure, but not not to use them. (I swear that's the right number of 'not's.) I don't understand why something like Neil Mitchell's `Safe` isn't just the way that things are done by default.

Ugh, yeah, total agreement here. Historical accident, I suppose. I try to pretend like `head` and `tail` just don't exist.

You can always recognize a file where I'm doing list ops because I define `uncons :: [a] -> Maybe (a, [a])` at the top of the file, haha.

Re: Becoming Productive in Haskell

#157

Post by the_why_of_y » Fri, Apr 24, 2015, 7:47 PM UTC

david-given wrote: post #14

The author's comments on noise chime true with me: every time I give Haskell a try I end up struggling with frustrating and opaque vocabulary, sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. I really like the author's suggestion of mentally translating Functor to Mappable. Are there any other synonyms for other Haske…

> e.g. C++ also has functors, and they're completely unrelated to Haskell functors.

You can't blame that one on Haskell or the functional community - the term was already established before the C++ community decided to use it in spite of pre-existing definitions. They even ignored Prolog's pre-exising abuse of the term functor :-)

A few similar terminological accidents of history come to mind, where the original definition of some term is now obscure and a different definition popular:

- POSIX capabilities (as implemented in e.g. Linux), which are a security mechanism that has nothing to do with what security researchers have been calling capabilities since the 1970s

- Microsoft operating systems using the term "Format" for creating a file system, despite the fact that it is impossible to actually format hard disks at the hardware level since the 1990s

- imperative programming languages abusing the term "function" to mean procedures with side effects

- "thunk" meaning a stub that emulates/bridges different calling conventions, instead of a call-by-name (or lazy) closure

- "Tea Party" used to refer to a fine rock band from Canada

Re: Becoming Productive in Haskell

#158

Post by tel » Fri, Apr 24, 2015, 7:52 PM UTC

hyperpallium wrote: post #152

QuantumRoar wrote: post #25

Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…

Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc. But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and fro…

To be honest, I think Haskell is the best language I know of for fast iteration as well. You can successfully create and manage far worse, yet working code when you've got a good type-driven guardrail. A common pithy quote, which I agree with wholeheartedly, is that "`IO` is the best imperative language out there today".

There's definitely a lot of missing documentation about this folk practice of "fast, loose, shitty Haskell" due to the strong culture of pretty code that's also enabled by Haskell. I remember seeing a video presented at CUFP that went into the merits here, though.

Essentially, this is a "tricky" concept because you want to design your types to be exactly as restrictive as you can afford without having to think too much. It probably requires a good grasp of the Haskell type system applied in full glory in order to bastardize it just right.

So, tl;dr?

I think types are the ultimate fast iteration tool, but this is not a well-documented practice.

Re: Becoming Productive in Haskell

#159

Post by tel » Fri, Apr 24, 2015, 7:56 PM UTC

dllthomas wrote: post #99

david-given wrote: post #14

The author's comments on noise chime true with me: every time I give Haskell a try I end up struggling with frustrating and opaque vocabulary, sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. I really like the author's suggestion of mentally translating Functor to Mappable. Are there any other synonyms for other Haske…

As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront. I agree that a shared vocabulary is important, but standardizing in a way that makes the mathematical writings on the topic more accessible seems a big win. Moreover, "functor" is a bit more precise than "mappable" - a functor is a mapping that preserves structure.…

I'm... hesitantly okay with "Functor == Mappable", but I really think Monad should be "Embedded DSL" and Monoid "mergeable". Or really Semigroup.

Monad is definitely abnormally difficult to humanize. The trio (T, ∀ a. a -> T a, ∀ a b. (a -> T b) -> (T a -> T b)) is really hard to nail down.

Re: Becoming Productive in Haskell

#160

Post by avmich » Fri, Apr 24, 2015, 8:07 PM UTC

hyperpallium wrote: post #152

QuantumRoar wrote: post #25

Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fidd…

Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc. But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and fro…

"Civilization advances by extending the number of important operations which we can perform without thinking about them." A. N. Whitehead.

It's often said that a Lisp advantage is to be able to write sloppy - without fully understanding what's needed. I guess you can model that degree of "less constraints" in Haskell as well? Otherwise constant forcing "understand what you're doing" can sometimes be a burden.