Hacker News Reader

>Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory.

If that was Haskell's problem, its effects would be unique to Haskell. Rather, Haskell, like Erlang, Lisp, Eiffel, Smalltalk, and, in its early days -- and it had to fight to overcome this -- Java: these all have or had the same problem, which is that they don't integrate well with the "outside world". As a result, a great deal of effort is expended in the developer communities surrounding these languages to reinvent the wheel, axle, spoke, tire, hubcap, and spinner, which prevents said developers from making things that are truly interesting.

Languages which work with the "outside world" can be used to develop great software even if they are not popular, like Lua and CoffeeScript. Go, Swift, Scala and Rust learned this. The most obvious point of contrast, though, is how quickly Clojure became more popular than Scheme/Racket, despite being basically the same thing.

I like to see Clojure definitely scheme-inspired, but it is a very different language. Scheme has this approach where you can build almost anything out of cons, car, cdr.

After using Clojure for a while, all this cons, car, cdr stuff of Scheme feels like being stuck in implementation detail.

With the scheme community insisting on (1) recursion as the primary means for looping (2) no general polymorphism in the language standard I see no future in Scheme.

(1) - I have seen the light with Clojure's `for` macro. While it is not much more as a `map` (or a python/haskell list comprehension) its that kind of sugar that is really readable and is a good platform for beginners to reach up to map, fold, and other higher order functions.

(2) - Lists have car, cdr, Lazy lists in Scheme have stream-car, stream-cdr. I.e. I cannot use an algorithm that works on lists on lazy lists, etc. Even some lightweight dispatch here would make scheme so much more powerful and useful.

So: While clojure is not much more than Scheme, it demonstrates how a little more can actually make a huge difference in usability and adoption

PS: I really like Scheme as a small, simple language that gives you a good idea how an interpreter might work under the hood.

In what way does Lua interact with the outside world? Are you referring to it being embeddable, or the FFI in luajit2?

Also, in what way does Swift work with the outside world? It seems to be locked in pretty tightly in its own little world?

>In what way does Lua interact with the outside world?

Lua's C API allows Lua programs to bind to any C library. It's probably better at this than anything else out there, and there have been some attempts at really ambitious things like automatically generated Qt bindings: https://github.com/mkottman/lqt

>in what way does Swift work with the outside world?

Swift uses the Objective-C runtime. It interoperates with Objective-C very well and is designed to do so; by definition this means it also interoperates with C quite well. See:

http://en.wikipedia.org/wiki/Swift_(programming_language)#Li...

> Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory.

Oh please, you just devalued your entire comment with that untrue and derisive comment. Haskell is used by people who highly value composability, purity, correctness, and who believe mutable state should have a big red flag around it and be limited as much as possible.

I think you have just proven his comment about the attitude of Haskell users.

Purity, composability, correctness, and avoidance of mutability are hardly category theoretic or exclusively praised by Haskellers. You could claim that Haskellers are particularly enthusiastic in their desire to optimize for those things, but now you have to describe why that's a bad thing.

And it's still not related the gp's points of badmouthing other languages or being unmarketable.

Try reading again what I wrote.

Nothing I said is about "Purity, composability, correctness, and avoidance of mutability" and "why that's a bad thing", and all about "badmouthing other languages or being unmarketable".

I didn't badmouth any other language in that comment.

I've had a lot of trouble here too. Too often, the languages crowd will care more about the language itself rather than the problems you are solving with it. Most recently, I designed an algebraic query language, and some Haskellers were like... and it's written in Scala?

I don't know about you, but I'd rather do real math (or at least take a stab at it) in Scala than write more routing web frameworks in Haskell. Ideally, I would be writing it in Haskell (or Idris ;)) but the lack of willingness to cross over to the other side and interact with "normal" programmers really hurts us, and I'm honestly a little fed up with the fundamentalism. There are really smart folks out there with a lot of domain experience that we alienate when we blow off stepping stone languages like Scala.

>Too often, the languages crowd will care more about the language itself rather than the problems you are solving with it.

If they didn't, you'd probably not call them "the languages crowd" and we'd never get any new inspirational theories and principles out of them.

I'm not familiar with the community - why do Haskell folks look down on Scala?

The common opinion is that Scala is a poor man's Haskell, with few of the strengths and more weaknesses. It's seen as, at best, a stepping stone from imperative languages to "real" functional languages.

I see. What are the perceived weaknesses and lack of strengths of Scala as compared to Haskell?

I cannot speak for the either the Haskell or Scala communities, being a newbie in both, but here is my opinion of why Scala is "the poor man's Haskell":

- Scala's type system feels at the same time more complex and less powerful. It has worse type inference, for example.

- Being a hybrid language, Scala offers fewer guarantees than a pure FP language. For example, its type system isn't adequate to express and constrain side effects.

- Scala seems more verbose and less elegant than Haskell to me.

- Compatibility with Java means Scala has some warts like allowing nulls. Yes, you have the Option type. But something you expect to be of type Option can still be null due to carelessness!

- Some libraries used by the Scala community, such as Actors in Akka, seem to eschew the static type systems that's the raison d'etre to use something like Scala (or Haskell) and seem a lot like dynamic typing, except without the simplicity of dynamic typing.

- Lastly, the highly opinionated "Mostly functional programming doesn't work" [1][2]

[1] http://queue.acm.org/detail.cfm?id=2611829

[2] https://news.ycombinator.com/item?id=8084302

I think the issue is that Haskell people basically assume that if they don't have feature X themselves, it has to suck and can't count as a strength of another language.

For instance, Scala's OO/module system is one of the best ones out there, but is readily dismissed by Haskell people, despite modularity being a complete train-wreck in Haskell.

Personally I feel most Haskellers wish that Haskell had ML style modules—there just needs to be a way to make them play with Typeclasses properly. It's being actively worked on at this moment, actually!

I think there's a good argument, albeit one I'm not qualified to make, about whether Ml modules or Scala objects are better.

> …his impression is that there were plenty of Haskell people there that seemed to barely tolerate having any talk about Scala in the conference.

It’s a conference about functional programming. If they believe that functional languages are better for software development than imperative languages, then they may see hybrid languages as making unnecessary and detrimental concessions.

> Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory.

You’re repeating the false meme that I/O in Haskell is difficult or theoretical, and furthermore implying that learning is a bad thing.

> It’s a conference about functional programming. If they believe that functional languages are better for software development than imperative languages, then they may see hybrid languages as making unnecessary and detrimental concessions.

If that kind of extremism was applied in discussion of other paradigms, we'd be excluding mention of "hybrid languages" like C++ from discussions of Object Oriented Programming.

> If that kind of extremism was applied in discussion of other paradigms, we'd be excluding mention of "hybrid languages" like C++ from discussions of Object Oriented Programming.

If I had mentioned exclusion, yes. C++ is mentioned at OOP conferences like ECOOP and OOPSLA as often as Scala is mentioned at FP conferences like ICFP, CUFP, and Lambdahack. But I have little doubt that a strawman proponent of a pure-OOP language such as Smalltalk—or Self or Ruby or Java or whichever language embodies the definition of OOP you prefer—would be as miffed about the use of C++ in lieu of their preferred language as hibikir’s friend’s strawman Haskeller is about Scala.

And anecdotally, the top C++ developers I’ve worked with didn’t have anything good to say about object-oriented programming anyway.

> the top C++ developers I’ve worked with didn’t have anything good to say about object-oriented programming anyway.

Which makes sense. C++'s support for OOP is pretty painful. It would be like hating functional programming because of being exposed to it in APL.

> If I had mentioned exclusion, yes.

You provided an explanation for a why people "barely tolerated" (i.e., preferred to exclude) mention of hybrid languages at FP confrerences.

> And anecdotally, the top C++ developers I’ve worked with didn’t have anything good to say about object-oriented programming anyway.

It is hard to get a good grasp of OO in C++, if you don't experience pure OO languages, at least for some time.

Multi-paradigm languages like C++ are great, but that power can work against learning a specific paradigm properly.

Good program design, regardless of the paradigm requires experience and the ability to use the tools that expose paradigm best practices.

Badmouthing of hybrid languages is the order of the day by extremely prominent members of the FP community, even if they end up using said languages in their presentations.

Those hybrid languages (e.g. Python, F#, and Scala) are great for new development but awful when you have to maintain low-quality legacy code. That said... I think that observation applies far beyond functional programming. (It's rare, but certainly possible, for bad Haskell code to exist.) A common impetus behind language churn is the programmer's desire to justify green-field development (which is fun, even in C++) instead of career-damning legacy maintenance (which is unpleasant, even in good languages).

Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory.

This is an exaggeration of that prejudice. I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand. Functor, monoid, and monad sound a lot scarier than they actually are.

pedantic, but I really wouldn't call Python a hybrid language on the same level as F# and Scala. Python's functional programming capabilities are pretty poor (not to mention that things like TCO are missing).

Not to say that Python is a bad language, but having continuously tried to program in a functional style I've found that more iterative-seeming code ends up being more idiomatic and maintainable.

> do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand.

That is extremely true. Even in widely-used packages, you'll rarely find good official documentation (quickstarts or the like).

Sure, for a lot of packages , types are good enough (if you have a package to read a CSV file, all you need to do is find the CSVConf -> Handle -> [[String]] function), but with the bigger, more framework-y packages, there are so many types internal to the system that you _have_ to read through everything to do even simple things.

Too much time is spent trying to explain how the language (which ends up being simple) works and not enough time on practical guides on how to actually do things.

This has become a bit of a rant, but in Math (the kind most people go through in middle school), you always learn specific cases before going into general theory. Unfortunately, a lot of Haskellers end up being mathematicians of the PhD style, where they're fine with just going into general theory. Examples are useful!

> awful when you have to maintain low-quality legacy code

When is it not awful to maintain low-quality legacy code?

> I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) [...]

Well, the unofficial motto of the Haskell community is "avoid success at all costs" after all :) [1]

[1] https://www.simple-talk.com/opinion/geek-of-the-week/simon-p...