copergi

That is the most elaborate strawman I have seen in a while. You are now literally saying "haskell is dumb because they do what I think they should do. They should do what they already do instead."

>If you have a risk of arbitrary changes in APIs happening in any minor update

You don't. API changes require changing the major version. Read the PVP.

>There is nothing unique to Haskell about this

Precisely my point.

>Of course, you can also tell pip to install only within a specific version range if you ever need to.

Same with cabal. So what is the problem again?

I've had experience on both sides, plus know some other people who have been recently hiring haskellers. I have a huge problem hiring haskell people because the company I work for kinda sucks. I don't want to work here, so I can't really be surprised that nobody else does either. Haskell users seem to be more picky about where they work and what they work on, so if you've got micromanagement and "do this wrong because I said so" going on, you'll have a hard time. Where as you can still easily get hordes of PHP programmers willing to tolerate anything.

On the other hand, someone hiring remote haskell programmers for a company where the culture values quality had 100+ applications for half a dozen openings and really has their pick of a lot of top notch people. I think if you can offer a good job, finding haskell people isn't a problem. But if you can't, then I would stick to popular_language_x.

>Why Hackage packagers like to specify upper bounds I'm not sure of

Because having working code spontaneously break is very bad. You can't just blindly pretend any future versions of all your dependencies will work without updating your code. APIs change. So you specify the version range your code works with.

>Backwards compatibility either is very hard to achieve in Haskell

Backwards compatibility is the whole point of upper bounds.

>But at least pip, npm and gems are a breeze compared to cabal.

I had constant problems with pip. Because it will blindly install the latest 'foo' dependency even though the API changed and now my app is broken.

>Haskell's laziness makes slow code and code that use up a lot of memory hard to locate, and at times require significant refactoring, to correct

This is largely mythology built up around a misunderstanding of the grain of truth at the core of it. Lazyness can create pathological performance issues, just as strictness can. 90% of the time neither matters, 5% of the time you need strictness, 5% of the time you need laziness. Using strictness in haskell is very simple, and knowing when you need to is very easy to learn. The profiling tools make it incredibly obvious when laziness is causing a problem. And I can't even imagine a case where it requires significant refactoring. It is generally adding a couple of "!"s or importing Module.Strict instead of Module.Lazy.

I think you are vastly overstating things. You need an acceptable level of adoption. One where there are high quality libraries for common needs. One where you can hire experts. Beyond that level, increasing popularity doesn't really get you anything. Haskell is already beyond that level.

Has there been any talk of getting some of the holes in google's cloud offering filled? I would switch to google in a heart beat but I am using route53, SQS, cloudfront, glacier and VPC. That is a lot to be giving up. I also didn't see anything about any sort of health/service checking/alerting support, but I probably just missed it.

Immutability and collections were two separate list items. And "it doesn't count cause I don't want it to" doesn't really change anything.

You missed immutability, collections, and first class functions.

>GHC can be freakishly slow

So can scalac. Many compilers have pathological performance cases. Just repeating "the sky is green" over and over won't make it so. It is well known and widely accepted that scalc is slower than ghc. You don't have to like it, or even accept it. But responding with nonsense strawman arguments as if I am bashing scala is pathetic even by hn standards. You made false claims, I pointed out that they are false. Quite simple.

>People are also working on fixing many of the problems raised by Paul Philips

Of course they are. Why do you think "people are fixing those problems" is evidence to support your claim that those problems don't exist?

Yes?

I never suggested he was leaving. I wasn't even referring to a talk he gave. I said he is easily the worlds foremost expert on scalac, and he does not think it is fast, or that it is slow because it has to do a lot of work other languages don't. He thinks it is slow because it needs to be re-written to not be a mess.

GHC is faster than scalac, and GHC is the slowest haskell compiler. Ocaml optimizing compiler completely destroys scalac (and GHC), nevermind the bytecode compiler which is way faster than that. Being tired of reality doesn't change reality. When the single most knowledgeable person in the world on the internals of scalac talks about why scalac is slow, it is more likely that he is correct than some random scala fanboy on hn.

>Scala's type-system is much more static, leaving much less room for accidental bugs. Scala's compiler does things that in other languages you'd need to run specialized tools to get the same results or to write more tests

That is a bogus excuse. Languages with better type systems have faster compilers: haskell, clean, F# and especially ocaml. Paul Philips makes a pretty convincing argument that scalac is slow because it is a big mess.

Yes, I keep every test app I've ever written on hand just in case an infamous language_X troll demands proof anytime I mention that I saw the sky once and it looked blue.

No it isn't. Those tell you what types the values represent. We're talking about the actual source code itself. In lisp, the source code is itself a perfectly ordinary lisp value. That is what homoiconicity is. That is not something scala has, nor is it something scala wants to or claims to have.

Scala has a poor type system, and poor support for concurrency. It's terrible DSL problem is not a selling point. Nothing he talked about was crazy or required writing mind-bending code, that is the point. IntelliJ's scala support is still, to this day, completely broken. Have you tried using it?

Almost everything you listed as not in java is in java 8. Your distinction between "advanced" and "stuff I like" is a false one. Other people who aren't familiar with what you are familiar with will call those things "advanced". And when you learn those things you call "advanced", you will move them into the "stuff I like" category.

Perhaps, but I've already gone back to surfing the web in those 10 seconds. And scala provides pretty poor type safety compared to how bad the compile time is. I don't actually use PHP, I was just pointing out how the claim that play's workflow is just as productive is inaccurate.

I was testing with a trivial app, so 1 doesn't apply. There were no assets, so 2 doesn't apply. Ghc is notoriously slow at compiling, and it managed to recompile/reload the equivalence haskell test app in the time it takes to alt+tab and hit refresh.

This bizarre lisp fetish where everyone wants to call every language "basically lisp but..." needs to die. Scala is not basically lisp. Neither is python, or ruby, or javascript. Lisp is not just "has lambdas".

How do you figure? What scala data type is scala source code?

>Play's refresh-recompile trigger means it is not meaningfully less productive than PHP

Except with PHP you hit refresh and it is done. With play you wait 10 seconds and it is done. There is a huge difference.

>You can also stay away from advanced / theoretical / crazy parts of Scala most of time.

The parts that make it worth using in the first place?

>You don't need to use Scalaz, advanced type system features etc

Might as well stick with java then. You're not getting the benefits of scala vs java, but you are still paying the costs like compile times and poor tool support.

We're discussing both. The original question posed was something like "what amazing stuff has been built on crumbling foundations", and the response was "wikipedia". I don't necessarily agree with the sentiment of the question, but wikipedia is not a good example of amazing technology.

>Still takes a couple of seconds, though

How big is your code base, and is it all in one huge file or something? Our stuff is reloaded and ready before I've alt+tabbed back and hit refresh.

That's exactly what they did, that's what they are announcing here.

Neither of those would even remotely qualify is accomplishments in computing. But they also are terrible examples. Facebook isn't using PHP anymore, that's what this discussion is all about. Wikimedia is terrible, and wikipedia is almost exclusively static content being served by squid.

"Type checking is faster than other statically typed languages" is quite different from "other statically typed languages don't offer this workflow", which is what was claimed.