Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Sell Excellence

docs.google.com

Post reply on HN
Print view View original

111–120 of 124 posts

Re: How to Sell Excellence

#111

Post by michaelochurch »

jaggederest wrote: post #109
michaelochurch wrote: post #100

Earlier quoted context omitted.

Until you can 'get work done' without the equivalent of graduate-level math classes The problem is the name "monad", not the concept itself. You don't actually need to know anything about category theory to do I/O. You just need enough exposure to the concepts to know why the Monad type class is so repeatedly relevant as to be given a named abstraction. People have a hard time getting past the name . You don't need t…

> You don't need to be a category theorist to use monads in Haskell. I find that demonstrably false. Every time I run into problems and ask for help, the answer is "there is this other mathematical concept that solves that problem". It's not just monads, it's comonads, monad transformers, GADTs, Functors, phantom types, arrows, arrow transformers, the list keeps going. In addition, they're only described in terms of…

This is an excellent resource: http://dev.stephendiehl.com/hask/

There's also Chris Allen's guide: https://github.com/bitemyapp/learnhaskell . You can also go through the (good, but very dated) book, Real World Haskell.

Sometimes you have to find the tutorials and blog posts first. The lens type signatures aren't the easiest to understand, and sometimes its easier to just use things "empirically" without fully understanding them, and then get a sense of the type signatures when you really want to know what the compiler's actually doing. Being able to use lenses is not as hard as understanding why its intimidating rank-2 type signature is the right one.

Finally, sometimes it helps to de-generalize. To replace (Monad m) with IO, for example, and think about what that special case might mean.

For example, the type signature for Control.Arrow.first is:

    first :: Arrow a => a b c -> a (b, d) (c, d)
If you're a beginning Haskeller, your reaction is going to be "WTF"? Well "Arrow" is a type class more general than function. (It could be the "effectful function" type or Kleisli arrow, a -> IO b.) If you specialize with a = (->), you get the more concrete type signature:

    first :: (b -> c) -> (b, d) -> (c, d)
... and it's much more clear what it does.

As for nomenclature, I don't disagree. I had this discussion with Brian Hurt (and owe him for the insights): we'd be more marketable if we called Monoid "Appendable" and Functor "Mappable". Monad is one where it's hard to come up with a more accessible name for it: it abstracts over computational context (i.e. what do we actually mean when we talk about computational effects) but that would be a mouthful of words and not any more clear.

Re: How to Sell Excellence

#112

Post by CamperBob2 »

duncanawoods wrote: post #89

That chart on slides 29-35 which claims you will be 600% more productive with Haskell than C#/Java after 5 years... Its just made up isn't it? This is part of the problem. If you try to convince someone smart, experienced but skeptical by making things up, you hurt your own case.

Yeah, I like how he attacks the "false precision" of stack ranking and similar business practices, in the midst of an entire presentation full of it.

Re: How to Sell Excellence

#113

Post by sclv »

solomatov wrote: post #42
rdtsc wrote: post #28

Earlier quoted context omitted.

Well OP asked about Clojure so Erlang fits the profile. But you make an interesting point in a way. One can ask, ok here are two non-strictly functional languages that seem to be fairly practical. Used for large distributed mission critical systems. Would they be better off written in Haskell? Would they have been written at all if creators only knew about Haskell? How large is the relationship between fault tolerant…

>But you make an interesting point in a way. One can ask, ok here are two non-strictly functional languages that seem to be fairly practical. Used for large distributed mission critical systems. I think there're at least these problems with Haskell: * The language is badly designed. See the number of extensions which aren't standardized but widely used. See also obvious problems such as requirement to use renames whe…

This is a terrible and also hilarious argument. Instead of saying Haskell has too many newfangled ideas, you're instead arguing that it has an insufficient amount of them.

So Haskell has newfangled innovations compared to the big players, and it _also_ has a mature ecosystem in widespread use.

This puts it ahead of Purescript and Idris for adoption in large scale projects (although I would readily agree that both those languages are pretty great too).

I maintain that lazy evaluation works great, it just requires optimizing along different paths than devs are used to -- but it doesn't incur more "overhead" to optimize code than is the case in typical strict languages, which _also_ have to pay that cost, just in different sorts of optimization and reasoning.

Re: How to Sell Excellence

#114

Post by sclv »

jaggederest wrote: post #109
michaelochurch wrote: post #100

Earlier quoted context omitted.

Until you can 'get work done' without the equivalent of graduate-level math classes The problem is the name "monad", not the concept itself. You don't actually need to know anything about category theory to do I/O. You just need enough exposure to the concepts to know why the Monad type class is so repeatedly relevant as to be given a named abstraction. People have a hard time getting past the name . You don't need t…

> You don't need to be a category theorist to use monads in Haskell. I find that demonstrably false. Every time I run into problems and ask for help, the answer is "there is this other mathematical concept that solves that problem". It's not just monads, it's comonads, monad transformers, GADTs, Functors, phantom types, arrows, arrow transformers, the list keeps going. In addition, they're only described in terms of…

GADTs, phantom types, and arrows (not to mention monad transformers) aren't "mathematical terms" in that the names aren't borrowed from mathematical terminology.

They're just _terms_. But to you they are new terms. So you call them "mathematical terms" because obviously if you haven't heard of it, then it must be complicated math.

It isn't.

If you stop thinking that every new concept you meet in the world (or at least in Haskell) is a "mathematical concept" and start thinking it is "just a thing that is new and I can learn" then maybe you will stop feeling this way.

For that matter, none of the things you list except for Functors and Monad Transformers (which are just "ways to build monads") are idiomatic for "basic" haskell programming, and the next step up, GADTs is a straightforward feature to learn when you need.

If you read something like RWH or LYAH, you'll notice they don't cover arrows or GADTs that much. That's because they're not considered core concepts. If you set out to learn "all the things" and then discover that there are a lot of things, perhaps the problem is just that you set out to learn "all the things" under the false impression that you need to in some immediate way.

Re: How to Sell Excellence

#115

Post by sclv »

jaggederest wrote: post #110
mightybyte wrote: post #99

Earlier quoted context omitted.

> If Java is a general purpose language (can't be used for systems without translation due to the JVM), then so is anything-which-compiles-to-JS. Fair point. I guess my thinking here is that PureScript is unlikely to replace Haskell. It is possible , but I think there are a few reasons that probably won't happen. The first is that it's mission statement "PureScript is a small strongly typed programming language that…

> Second is that it is way behind Haskell in terms of infrastructure, ecosystem, and a lot of core language/compiler features that enable general purpose programming. No, it's way ahead because it's based on Javascript, and javascript is having umpty-billion libraries developed for it right now. Of course that's not actually a good thing at the moment but they'll settle down at some peoint. > This is a big misconcept…

> as of right now, you need to know category theory to understand the language and it's base libraries.

This is patently false. You need to know what a Functor and a Monad are, as typeclasses with attendant laws.

But you don't need to know the definition of a "Category" much less any actual CT.

There's nothing baked in. I think people just use "I need to learn CT" as an excuse for not learning things, to be honest.

Re: How to Sell Excellence

#116

Post by dllthomas »

jaggederest wrote: post #109
michaelochurch wrote: post #100

Earlier quoted context omitted.

Until you can 'get work done' without the equivalent of graduate-level math classes The problem is the name "monad", not the concept itself. You don't actually need to know anything about category theory to do I/O. You just need enough exposure to the concepts to know why the Monad type class is so repeatedly relevant as to be given a named abstraction. People have a hard time getting past the name . You don't need t…

> You don't need to be a category theorist to use monads in Haskell. I find that demonstrably false. Every time I run into problems and ask for help, the answer is "there is this other mathematical concept that solves that problem". It's not just monads, it's comonads, monad transformers, GADTs, Functors, phantom types, arrows, arrow transformers, the list keeps going. In addition, they're only described in terms of…

To a first approximation, no one uses arrows aside from the function instance. I've never encountered an arrow transformer in the wild.

Re: How to Sell Excellence

#117

Post by [deleted] »

rdtsc wrote: post #13
ryandvm wrote: post #4

At the risk of sounding inflammatory... I would be willing to believe that purely functional languages are the "one true way" if there were even the slightest bit of empirical evidence to support it. But where are all the successful large scale projects built with Haskell (or Clojure or whatever)? The biggest FP project I was aware of was Twitter using Scala and they ended up completely backing away from it. Yikes. T…

> But where are all the successful large scale projects built with Haskell (or Clojure or whatever)? How about Erlang. Let's try it, just from the top of my head: * AXD 301 Switch -- Classic. Powers and control phone switch networks of whole countries. Claims 99.9999999% reliability. * Basho Riak -- popular NoSQL database, highly scalable nodes are peers * RabbitMQ -- popular message queue used by enterprises * Whats…

[deleted]

Re: How to Sell Excellence

#118

Post by jaggederest »

michaelochurch wrote: post #111
jaggederest wrote: post #109

Earlier quoted context omitted.

> You don't need to be a category theorist to use monads in Haskell. I find that demonstrably false. Every time I run into problems and ask for help, the answer is "there is this other mathematical concept that solves that problem". It's not just monads, it's comonads, monad transformers, GADTs, Functors, phantom types, arrows, arrow transformers, the list keeps going. In addition, they're only described in terms of…

This is an excellent resource: http://dev.stephendiehl.com/hask/ There's also Chris Allen's guide: https://github.com/bitemyapp/learnhaskell . You can also go through the (good, but very dated) book, Real World Haskell. Sometimes you have to find the tutorials and blog posts first. The lens type signatures aren't the easiest to understand, and sometimes its easier to just use things "empirically" without fully unders…

I know all these things now - my point is that it took me years to get them to a level where I understand what they mean well enough to implement them anew. You can't say that about other languages.

Nobody is going to 'build a community' around a language that is so effectively obtuse, and when called on it, says 'here are tutorials' - tutorials are not the point. RTFM isn't a decent response to 'your language is difficult to learn and use'.

Re: How to Sell Excellence

#119

Post by mightybyte »

seanmcdirmid wrote: post #59
mightybyte wrote: post #54

Earlier quoted context omitted.

I'm using GHCJS and Reflex. Reflex is a recently released FRP library that makes a huge difference in one's ability to abstract GUI code. I personally feel that this combination of GHCJS + Reflex is the first thing I've used that makes web front end programming tolerable. A week ago there was a presentation about it at the NY Haskell Meetup. Look for videos of it to be posted early next week.

Ah, that's new! Is there any documentation on Reflex? A quick google search isn't working.

Oh, there is the try-reflex readme.

https://github.com/ryantrinkle/try-reflex/blob/master/README...

Re: How to Sell Excellence

#120

Post by oggy »

amazing_jose wrote: post #67
oggy wrote: post #60

Earlier quoted context omitted.

So why are you using Python now and not C/C++?

Balance, c/c++ (and even to some extend Java), are not appropriated for what I normally build: web systems. The balance that Python offers me, where performance is achieved by other means than the programming language (systems), with an access to libraries (data analytics, web frameworks, devops...) that cannot be easily matched by C/C++/Java. And about Haskell... well, I suppose it offers amazing performance and tec…

But that was the point, that not all programming languages are created equal. I only have anecdotal and personal experience to back this up, but I believe that a vast majority of people familiar with both Python and C would much prefer the former for Web development (as you do).

Looking at the big picture, computers are so ubiquitous now because they provide significantly better tools for all kinds of businesses. It's fairly obvious that programmers themselves can also benefit from improved tools. And our main tools are programming languages - although there are obviously also other parts to the puzzle (IDEs, compilers, build + deployment + CI systems). I think we are already better in that some of our mainstream languages today are nicer to use than most of those 30 years ago. However, the difference is not huge, and my impression is that the language development was largely done from personal experience of individual language creators, and has largely ignored the research advances made in the area of programming languages. Notable exceptions are garbage collection, and Clojure and Haskell (if we can consider them mainstream).

Now of course, there are other, both non-technical considerations that are also affected by language choice. Availability of libraries or programmers are obvious examples. But the real question is of course whether incorporating these advancements offers a real, measurable benefit, and I think that's what you're hinting at. The problem is that the benefits are hard to measure in a sensible way. Frankly, I don't think that the metric you propose (which, if I understand correctly, is "measure the cost/revenue ratio of projects in language X at company Y against the average ratio for all projects at company Y) can give reliable answers. How do you measure the revenue of something like Haxl? I think the language choice is going to remain a personal decision in the end.

Post reply on HN