Dogs rush to help when owners cry, study suggests - <AUTHOR> https://www-m.cnn.com/2018/07/24/health/dogs-human-crying-empathy-study/index.html <comment><USER2> I often tell people that I love my dog more than any human has ever loved a child, but I don't love this study.

The result is fairly obvious to any dog owner, but the study is representative of the type of "pop" science that appears so often in the news but carries little actual significance. 34 dogs total, 17 in each group (humming vs crying), 9 of which respond to humming and 7 of which respond to crying, albeit the latter much faster than the former. Of those 34 dogs, 16 were therapy dogs. While the time difference is large, more dogs respond to humming than crying.

So we have a very small sample size which is biased towards therapy dogs. It is also very susceptible to p-hacking. Why "Twinkle Twinkle Little Star"? Was this the song that produced the largest effect out of 20 different songs? Why do more dogs respond to the humming than crying but the dogs that do respond to crying act so quickly? Were the crying sounds much louder than the humming? Why not crying vs yelling, both of which are likely of similar volume? And so on.

<comment><USER3> Do you think you experience emotions differently than other human beings? It seems really presumptuous to say you love somthing more than others ever have. Presumptuous and insulting.

Furthermore, i think alot of people would say sacrifice is the greatest display of love, and I would bet a whole lot more parents have sacrificed a whole lot more for their children then anything you have sacrificed for for dog.

<comment><USER4> I'm sure he takes his dog to "dog care" every day, where it's played with constantly (not caged). He would never leave his dog alone in his 500 square foot apartment all day, barking it's loneliness to the delight of his neighbors.

While such dog care can be very expensive, he sacrifices that money even more gladly than a mother would for her child's care. This is what he implies with his statement, and I see no reason he would lie to us.

<comment><USER5> You can't analyze a person's behavior, especial their emotional behavior, without including cultural context. Society does not appreciate people leaving toddlers home alone, but they do not care if you do so with a puppy. That alone is enough to make the matter of "dog care" irrelevant in assessing someone's feelings on the matter.

<comment><USER6> Yes, but the poster loves his dog more than any human has ever loved their child. He does not merely conform to societal norms with such love.

<comment><USER5> Clearly such an exceptional dog-lover won't conform to your expectations about how that love manifests, either.

</comment></comment></comment></comment></comment></comment><comment><USER7> When we first brought my daughter home from the hospital we let our old pug smell her. He growled once when she first cried, then tilted his head from the sound.

Later we put her in her first bath - she shrieked! We did this in the middle of our living room in a small plastic tub on the floor. We were sitting on the floor; I sat on my knees. He (Cyrano) sat with us and while she shrieked, he placed one of his paws on one of my legs. He'd never done anything like that in his entire life. It looked so... human. It was so strange a family member took a picture of the event.

I miss that old boy. He was a good dog.

</comment><comment><USER8> Our newborn daughter cried right after we came home from the hospital, and our dog immediately started barking at mom and dad. Weirdly, the dog has never barked in reaction to the baby ever again since that first time.

My wife and I have a hypothesis that the dog was worried we couldn't hear the baby, and was reassured when seeing us tend to the baby quickly.

<comment><USER9> This may be outdated now, but I read a lot of canine behavioral research when I got my (late) dog about 16 years ago. She was a white German Shepherd Dog named Stella, and I miss the hell out of her. One recurring theme was a dog's role in their "pack" (in the case of pets, the humans and other pets they live with).

A dog who understands that their owner is the "alpha" will bark as a warning to them. Example: It was recommended that, if a dog barked at the door when someone knocked/rang owners praised their dog—"Good warning, thank you!" (and maybe a treat)—and then re-engage them quickly with another command ("sit!") if you choose not to investigate. They'd ostensibly come to learn that their single bark was their job.

I did this with Stella, and whenever someone came to the door, she barked _once_ , ran to me, and sat down, because she learned I may or may not answer it, and her job was done. If someone was _lurking_ , she'd bark, run to me, go back to where she saw the person, and if they were still there, this would repeat, regardless of praise. It stood out as unusual, and research suggested that that's what she wanted me to know. "This is different, boss! Come look!"

I used this concept in all her training and interactions; humans were her betters, and I was her alpha. Pack animals (it was said) got anxiety when the pecking order wasn't clear to them. That anxiety causes all sorts of what we call "problem behavior" (barking excessively, chewing/scratching at the door when their human leaves the house, rushing through open doors, etc.).

She was the most loving, fun, hard-working, peaceful, well-behaved dog I ever owned, and I believe it was coming to view our family as (from her canine perspective) her pack that made her training and integration into our lives such a success.

<comment><USER10> Dominance theory and the alpha pack stuff is very outdated. It sounds like you had a great relationship with your dog though. Giving them a job (warning), redirecting the behavior (barking with sit) so it doesn't carry on.

<comment><USER9> It may be so—as I suggested. :)

FWIW (anecdata warning) two of my friends have since owned dogs, training them using the same concepts. Perhaps it's a combination of breed (some breeds may retain more of their evolutionary pack awareness than others) and the specific sorts of training exercises (e.g. make them sit and wait when a door is opened, allowing the humans to go first and then say "okay" when the dog can go through), but their dogs are always held up as exemplars of "good dogs" when the topic comes up. No anxiety, no destructive chewing, no excessive barking, o impatience, no bolting…

Every lesson and interaction was predicated on the dog's position in the hierarchy of the human family ("pack"), and the only "tool" used outside of verbal and hand commands was a tasty treat (no clickers, no shock collars, no halters, no spray bottles, no physical discipline, etc.)

Crates were used, but never as a form discipline or "convenience holding". That was their safe place to sleep and eat, and that's it.

I guess what I'm saying is: if the theory is outdated, a lot of the concepts that informed the training regimen that I learned back are effective today.

"They're good dogs, Brent."

</comment></comment></comment></comment><comment><USER11> Developing our co-evolution with dogs was perhaps the greatest thing humans ever did...we really don't deserve dogs.

<comment><USER12> I wonder if it was entirely human, or if it was the proto-dogs themselves that self selected - it would have had to been the the animals that were already predisposed to hanging with us that would have been domesticated - I doubt ancient human's would have gone out of their way to capture, pen up, and train them.

<comment><USER13> The new "Cosmos" series has an episode that touches on the domestication of dogs [1]. It talks about variations in hormone levels of wolves: some naturally feared humans less and were rewarded with scraps of food. And thus formed an early symbiosis with man.

[1] [https://www.youtube.com/watch?v=aQHBmY6LbiA](https://www.youtube.com/watch?v=aQHBmY6LbiA)

<comment><USER12> It did seem strange my thoughts were being narrated by Neil deGrasse Tyson while I typed. That was a fun series.

</comment></comment></comment></comment><comment><USER14> Shoot, this is how I recapture our dog when he gets loose. Chasing him is no good, he thinks that's a game, so I just collapse on the sidewalk and yell for him to come help. He trots right back over to me.

<comment><USER15> I have a greyhound who occasionally likes to go for a run by himself. He doesn't think of it as a game, it seems to me that he's just off to patrol his territory. It's not just his running speed that makes him hard to catch, either. His reflexes are so quick that when I grab for his collar, if he doesn't want me to grab it, I can't. He's like those ninja movies where the fight scenes are sped up.

Last time he went for a run I had to get the car! Found him playing with some kids at the local sports ground - I'm glad greyhounds have such a pleasant nature, and love people so much, because if he'd appeared any more aggressive than a giant and playful puppy, there might have been problems.

</comment></comment><comment><USER16> I had a mild panic attack during a LSD trip and my dog curled on my side and basically « sucked » my anxiety and made me feel relaxed.

On another day, my wife remembered a sad event in her life and began to cry silently. Our dog woke up and came to sit at her side calmly.

We don't deserve dogs.

<comment><USER15> Some time back, my partner had a really sad event in her life, and she sat on the couch crying. We have two dogs, a happy yet dumb-as-a-rock greyhound, and a collie-staffie cross. The collie noticed, jumped up on the couch, and cuddled into her to (try and) make her happy again.

When we lost her pack mate to cancer, a few years ago, she sat on the couch for ten days, didn't eat, just lay with her head between her paws. We were all heartbroken, myself most of all, but she was too sad to help anyone this particular time. After she recovered, she helped me a lot.

We don't deserve dogs, but dogs are awesome and we could learn a lot from them. "Be the person your dog thinks you are!" ― J.W. Stephens

</comment></comment><comment><USER17> _" It is interesting to think that all these anecdotes of dogs rescuing humans, they could be grounded in truth, and this study is a step toward understanding how those kinds of mechanisms work," she said._

I don't understand this comment, does Emily Sanford think all these stories are made up?

The few times I've hurt myself enough to verbally whine both my 15 month old pups have swiftly approached, and they're in a markedly different state to when I call them over to play.

<comment><USER18> > I don't understand this comment, does Emily Sanford think all these stories > are made up?

More likely she's not immediately attributing these stories to "dogs intentionally come to the aid of humans."

People anthropomorphize pets to an enormous extent. One can imagine plenty of other reasons why a dog might e.g. alert the neighbors that their owner is in trouble ("I'm hungry and my owner isn't feeding me" is a very simplistic one off the top of my head).

It's well worth being skeptical about.

</comment></comment><comment><USER19> Reminds me of this video: "Dogs Tested to See Whether They'd Defend Owner During Home Invasion" [https://www.youtube.com/watch?v=NZ74oFctP_g](https://www.youtube.com/watch?v=NZ74oFctP_g)

Spoiler alert: dogs are probably not as helpful as their owners think during high stress scenarios.

<comment><USER17> That video's contrived. Of course your average companion dog or hound / gundog isn't going to really know what to do when an intruder appears.

Try the same experiment with dogs who've been trained for protection. Search YouTube for _protection dog_.

<comment><USER19> I don't think it's contrived compared to the expectations that ordinary people have of their dogs. Dog owners likely secretly think that their pooch is going to protect them, even if they're not _protection dogs._

<comment><USER20> You don't need a trained, protection dog. E.g. Labradors are toys, being bred to be playful and loving. A half breed of a pit bull doesn't count much either.

What you need is an aggressive race. Also females tend to be more protective AFAIK.

I had a Rottweiler for example, that I was walking without a leash near my building because to my knowledge she was well behaved, but with no special training other than me talking with her daily. So one day I was attacked by a homeless person and my dog, came from the bush where she was peeing and nearly bit his hand off. Well she was about 50 Kg and size and weight do count.

And another day she stood her ground to a pack of 3 or 4 street dogs. What can I say, was living in a bad neighborhood.

Also in our country we still have many classic shepherds that practice transhumance, with these 2 races of dogs being very popular, called "mioritic shepherd" and "caucasian shepherd", including all kinds of half breeds, and these shepherd dogs can get pretty big and get used for defense against thieves, wolves, you name it.

And they don't need training btw. They aren't kept for emotional support, they are kept to defend the herd and with the harsh conditions involved, they can get really, really aggressive. And actually it's the same story if you go to the country side where people keep dogs to protect the house and livestock. Dogs being entirely utilitarian, they only get food and shelter in exchange, not love, so they know what needs to be done in case of intruders.

My grandparents had a saying — if you want a dog that can protect you, you should never allow other people to feed or pet it.

<comment><USER21> > Labradors are toys, being bred to be playful and loving. A half breed of a > pit bull doesn't count much either.

Interesting that you'd say this -- I think there's always exceptions to these rules, and here's mine:

I had a half-laborador, half-pitbull. Like a lab, she was very aware of people's emotions, and like a pit, she was strong, aggressive, and had a very high pain threshold. (She barely reacted when we pulled porcupine spines out of her nose with pliers.) Unfortunately, this was a problematic mix. If I was the least bit uncomfortable with somebody, even if it was just social anxiety and I wasn't in any danger, she would start growling and try to make them go away. And she viewed every other dog as a mortal threat, to which she would react with murderous fury. I have no doubt that if I had felt physically threatened, she would have done serious and possibly disproportionate damage.

I wasn't able to take her out much.

<comment><USER15> A friend of mine has a staffie/bull terrier cross, with who knows what else in her. The dog has the nicest nature I can imagine (that's the staffie), and usually seems like a really affectionate animal with no aggressive traits.

One day, he was out walking her, and three guys came up to him. They stood around my friend in the usual threatening triangle formation, so no matter which way he faced someone was behind him. They started accusing him of stealing from them, and started to get aggressive until one noticed his dog and asked if she attacked. Just a moment later, she launched herself at the three of them - only the tight leash saved them from being bitten. She'd die to protect her family.

Whenever I visit him, she "attacks" me - launches herself at me so I can lavish attention on her for as long as possible. If he ever had to get rid of her, I'd take her in a heartbeat, but depriving her of the kids she loves so much would be one of those heartbreaking moments you'd never want to see.

</comment></comment></comment></comment></comment></comment><comment><USER22> I suspect most dog owners will not be surprised by this.

<comment><USER23> Well sure. The whole value in these sorts of studies is that pet owners' intuitions are untrustworthy, as they have a very strong inclination to anthropomorphize their pets.

<comment><USER24> I've heard people object to anthropomorphizing animals before, and it's always seemed like a very odd objection to me. Dogs and cats react very similarly to us when it comes to things like threats or fear or play. That makes sense given that a lot of the evolutionary constraints on any predatory animal are going to be similar. Additionally, dogs absolutely co-evolved with humans, with us adapting to understand and build relationships with them and them evolving to incorporate themselves into our communities.

I'm not saying pets are exactly the same as humans, but I do think that you're going to be hard-pressed to find a better heuristic for dog behavior than thinking about what a non-verbal human would do in their situation.

(I know you didn't make a particularly strong statement here; I'm just responding to other objections I've heard).

<comment><USER5> The problem is that people don't even consider other mental models. It's easy to say "I can't do that", but that doesn't mean a dog can't do it: it has a dog brain, so it is obviously not limited to feeling what humans would feel in situations.

It's a _justifiable_ heuristic, but it is still a heuristic, and it's we choose because we are very biased toward human conceptualizations. So we shouldn't say it is a _good_ heuristic, and we should be wary when relying on it to make decisions.

</comment></comment></comment></comment><comment><USER25> How about dogs that know (i.e., predict) when their owners come home?

[https://blogs.scientificamerican.com/cross- check/scientific-...](https://blogs.scientificamerican.com/cross- check/scientific-heretic-rupert-sheldrake-on-morphic-fields-psychic-dogs-and- other-mysteries/)

</comment><comment><USER26> I was a bit sick a few weeks ago and spent some time throwing up in the bathroom (the flu is not fun). My 10-year-old 14-pound jack russell terrier mix stood in the door of the bathroom not facing/watching me but staring outwards. I obviously can't be sure of this, but, I choose to believe that she realized I was not feeling well and was in a vulnerable position and was protecting me. Going to miss that girl someday.

</comment><comment><USER27> As a child, we had a cat that would do this - any time any of us cried, or even when we were really sad, she would come over and start miaowing and rubbing against us.

</comment><comment><USER28> Cats do too.

<comment><USER29> All of my parents' cats have been very attentive to bad states of mind in people. My sister has social anxiety and suffered from depression for a long time. All of their cats both past and present would/will pick up on this, and come to her, to snuggle and purr. As aloof as cats can seem, they do have a drive for companionship, and not just for food or snacks.

A warm, purring cat on your lap can be surprisingly therapeutic.

<comment><USER30> I've had a cat sleep on my chest, and my son sleep on my chest. They are both very grounding and calming experiences.

I suddenly wonder if imagining a cat sleeping on my chest would help me sleep.

<comment><USER31> Probably the same effect that a heavy blanket that increase the production of serotonin and has a calming effect.

</comment></comment></comment></comment><comment><USER32> Wolves can help also when encounter a child crying. The sound seems to trigger a cub protection response.

</comment><comment><USER33> IDK I love my dog but when I fake falling to the floor to see how she reacts she would come running and hump me

</comment><comment><USER34> Are they really trying here to get igNoble due to essentially wasting research money?

<comment><USER5> If you want to find "wasted" money, look to the entertainment and sports industries.</comment></comment>


Javascript OO Without Constructors - <AUTHOR> http://tobyho.com/2012/10/21/javascript-OO-without-constructors/

<comment><USER2> Interesting discussion on the javascript reddit about the pros/cons of this approach: [http://www.reddit.com/r/javascript/comments/11vpgp/javascrip...](http://www.reddit.com/r/javascript/comments/11vpgp/javascript_oo_without_constructors/)</comment>


Ask HN: Gut feeling on name change? bug.gd renaming to errorhelp.com - <AUTHOR>

Hey guys, we've decided to rename our bug.gd error site to ErrorHelp.com. I wanted to get a gut feel from HN on the name change as a final sanity check.
Background: We've invested a good bit in the bug.gd name over the past year and a half. We launched that way, with cheerful coverage on Digg, PCWorld, TC, Mashable, random news channels, etc. The press announcement pieces have settled down for now and the lion's share of our traffic is driven by Google and our Firefox extension.
We've begun selling services to corporations and IT groups where the "bug.gd" URL is more of a liability than an attention-getter. We're providing error search engines for help desks and corporate KBs so using a Grenada TLD raises more than a few eyebrows.
We currently use the sites as two different products: bug.gd is our community search engine and ErrorHelp.com focuses on companies. This dual approach makes things more difficult to describe to customers, too.
Questions: What's your gut reaction to the name change? Good idea? What gotchas have you seen when renaming products or services?
From what I understand (and our experiences in the past), the 301 redirects will eventually carry over our decent pagerank, etc. Has anyone had problems with that? Or problems with sitemaps after redirections, etc?
Thanks in advance! <comment><USER2> Errorhelp.com is better.

<comment><USER3> i agree. the original name is probably _too_ (forcibly) clever. walks the line that separates clever and confusing.

</comment></comment><comment><USER4> bug.gd is too web2.0, since you are selling things to corporations and IT groups, you need to stick to 1.0 names. Errorhelp is leaps and bounds better for your business

</comment><comment><USER5> Yeah I have to agree. bug.gd is cute but cute mainly sells teddy bears.</comment>


Why Scala is the best language available today - <AUTHOR> http://m50d.github.io/2013/12/04/language-design-is-hard.html <comment><USER2> I'm not normally one to complain about headlines, but I think the editorializing here does a huge dis-service to the blog post. It implies there is such a thing as one true best language, which is pretty obviously false. I almost didn't even bother reading the post because of it.

EDIT: If it gets changed, the submitted title is "Why Scala is the best language available today"

<comment><AUTHOR> The original headline doesn't tell you anything about what the post is about; when I've submitted posts under similar headlines they've sunk without trace.

<comment><USER2> I won't argue with you that the best way to get articles to not disappear is to give them a flamebait title, for sure.

</comment></comment></comment><comment><USER3> "This is the problem with dynamic syntax in, well, dynamic languages. As Philips puts it, ignorance is strength, and freedom is slavery..."

Hey man, that's like... your opinion

In my opinion types are a poor man's schema, my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo". I use schema libraries and asserts to both document the code and make sure you can't feed it wrong data. I even generate automatic html documentation out of my schema so my clients know what to send me, and this only in the places I need, no need to a schematize or assert every simple function with obvious parameters.

Maybe type annotation is more useful in OO languages, but as a clojure programmer, for me, data is just data, there's no behavior associated. If I really want type safety at compile time I can use core.typed only in the places I need it.

As a former long time java programmer (who tried scala for months) I welcome my new found freedom from type slavery, but that's just... my opinion.

<comment><USER4> Have you ever worked in enterprise projects with distributed teams, around > 30+ developers per site, grokking hundreds of code lines in a dynamic language without unit tests, because they are a waste of employee salary time?

I really value strong typed languages in such projects.

<comment><USER3> If you don't have unit tests in a distributed team of 30+ devs per site you are screwed in ANY language.

<comment><USER5> That's a fact. But there are languages you are more screwed in than others. Even a tiny amount of refactoring in a dynamically typed language makes it easy to break your build, while it's much less risky in a statically typed language. And if your hypothetical team has this codebase without unit tests, we can likely assume that other best practices, such as the notion of separation of concerns, is also considered a waste of time. If you can start refactoring the existing codebase with a more modular design AND be (relatively) confident that you're not breaking your app, you'll make it possible to introduce unit tests.

<comment><USER6> The way Clojure mitigates this is by having a REPL. Whenever I work on any code I can always run it immediately in the context of the application.

Let's say I'm refactoring a function, I can run it to see what it actually does and I can write a new function and test it immediately on the spot to make sure it has the same behavior.

When you're working in a REPL you always have confidence that whatever change you made does what you want immediately. There's no recompile cycle, you don't have to restart your application and build up the state to see what effect the change has.

This allows you to refactor things and be very confident that you're not breaking anything. Coupled with high level integration tests you can be confident that all the use cases work correctly without having to have a ton of unit tests.

Having worked with Clojure it really shocks me that most modern languages do not have any REPL integrating in the editor and you still have the code/compile/run cycles.

<comment><USER5> Let's say you change your function by adding a new parameter, or you modify the order/type of existing parameters. How does your REPL save you, then? You can make sure that your new function works correctly, but not that all call sites are correct. In my experience, not that many codebases have "high-level integration tests", which are kind of an orthogonal issue compared to unit tests (you still need unit tests if you want maintainable Haskell, in spite of the type system and REPL).

<comment><USER6> The REPL lets you test any call sites immediately after you make a change. I do this all the time at work. Let's say I change a function that accesses the database, I can update the function then update the call sites and run them right there and then.

At least in Clojure, the REPL is integrated in the IDE. I can use the IDE to tell me where the call sites are what references the function, jump to definition, etc. Then I can send code from the editor directly to the REPL to test it out.

I use Intellij with the Cursive ([http://cursiveclojure.com/](http://cursiveclojure.com/)) plugin, but you can do the same thing with Emacs and Eclipse.

My experience is that unit tests make sense in some scenarios, but not in every situation. On the other hand, high level integration tests act as a contract for your application. You should have these regardless of whether you're working with a dynamic or a static language.

<comment><USER5> > The REPL lets you test any call sites immediately after you make a change. I > do this all the time at work. Let's say I change a function that accesses > the database, I can update the function then update the call sites and run > them right there and then.

At least the ones you know about. Now, take your codebase to 100k lines, 75% of which you didn't write. Good luck.

Wrt to integration tests: they're a pain to set up, and the complexity creeps it really easily. It's straightforward to unit-test edge cases, but the combination of layers makes it much more difficult to rely on integration tests for this kind of thing. Plus, integration tests usually take a long time to run. Rapid feedback is important.

<comment><USER6> The code base I'm working on has been developed for about 3 years by a team of 4 people. I have no trouble navigating it, nor does anybody else on the team.

If you're working with a half decent IDE, it can do things like tracking down function usages for you very easily.

>Wrt to integration tests: they're a pain to set up, and the complexity creeps it really easily.

That has not been my experience at all. Clojure has very nice testing frameworks that makes this trivial.

>It's straightforward to unit-test edge cases, but the combination of layers makes it much more difficult to rely on integration tests for this kind of thing.

The REPL allows doing a lot of what unit tests are normally used for. When you make a change you test it live in the REPL. This is no different from running a unit test.

>Plus, integration tests usually take a long time to run. Rapid feedback is important.

Hence why you don't run them all the time. The REPL provides you with rapid feedback, much more rapid than running unit tests I might add. Meanwhile, the integration tests are used for overall sanity testing.

<comment><USER5> > The code base I'm working on has been developed for about 3 years by a team > of 4 people. I have no trouble navigating it, nor does anybody else on the > team.

Good. Except, next time you hire somebody, you may get accidents.

> If you're working with a half decent IDE, it can do things like tracking > down function usages for you very easily.

Oh, certainly, but it kind of invalidates your claim that REPL + integration tests is enough to maintain a codebase.

> That has not been my experience at all. Clojure has very nice testing > frameworks that makes this trivial.

Hm. I've worked with "very nice testing frameworks", but I'm not aware of any which helps with the two main issues that crop up when you create integration tests:

\- integration with external tools (external database, LDAP...)

\- amount of setup in your application necessary prior to running scenarios

> The REPL allows doing a lot of what unit tests are normally used for. When > you make a change you test it live in the REPL. This is no different from > running a unit test.

Well, considering that a well-tested unit of code (ie, what you put in a single file) is usually dwarfed in size by the test code itself, because you're testing a lot of scenarios, then you either spend an unholy amount of time in the REPL, or you don't test everything. Which brings me to my second point: unit tests will run the same tests every single time. And even better, _everybody_ in the team will run the same unit tests every single time.

A REPL is no substitute for unit tests. I'm not saying it's not useful, because it allows you to validate an idea fairly quickly, especially in simple cases, but it is absolutely not suited to validate the correctness of a piece of code.

> Hence why you don't run them all the time. The REPL provides you with rapid > feedback, much more rapid than running unit tests I might add.

I fully agree with that (though running unit tests on a single unit of code is very quick).

> Meanwhile, the integration tests are used for overall sanity testing.

Sure. But in my experience: most codebases have little to no integration tests, and they cover things like "make sure login is not broken" or "make sure saving an entry works" as opposed to "make sure login does not break with the login 'null'" or "make sure we reject an entry which contains invalid XML", because the cost of setting up scenarios is much higher than with integration tests.

<comment><USER6> >Good. Except, next time you hire somebody, you may get accidents.

That goes for any project in any language. You simply have to mitigate these things in a way that makes sense for your team.

>Oh, certainly, but it kind of invalidates your claim that REPL + integration tests is enough to maintain a codebase.

My point was that REPL allows you to test things quickly and can be used for many scenarios that unit tests are often used. For example, when you refactor code you can test it on the spot. The feedback loop is much tighter when you work with a REPL.

>\- integration with external tools (external database, LDAP...)

The goal is to test how your code behaves and not what the external tools are doing. In my testing I capture the expected response from the external system and replay it in the test. My interest is in what the application is doing with a given input.

>\- amount of setup in your application necessary prior to running scenarios

I'm not sure what this setup is exactly.

>Well, considering that a well-tested unit of code (ie, what you put in a single file) is usually dwarfed in size by the test code itself, because you're testing a lot of scenarios, then you either spend an unholy amount of time in the REPL, or you don't test everything.

The point is that the integration tests are used to test correctness. As long as they pass your application is doing what it's supposed to be doing. The REPL allows you to make sure that the change you just made does what you think it does.

>Which brings me to my second point: unit tests will run the same tests every single time. And even better, everybody in the team will run the same unit tests every single time.

Unit tests are also a huge overhead in maintenance. Any time you make a change in code, you have to go and update many tests. As you yourself point out, since you're testing many scenarios your tests often have more code than your actual application. With integration tests, you only need to change your tests when the business logic changes.

>A REPL is no substitute for unit tests. I'm not saying it's not useful, because it allows you to validate an idea fairly quickly, especially in simple cases, but it is absolutely not suited to validate the correctness of a piece of code.

I don't think unit tests are a valid way to ensure correctness either. Your individual pieces of code might be correct, but how they interact might be wrong. The only way to capture the actual use cases is by running end to end tests.

Conversely, as long as the end to end tests are passing that means that your application business logic works correctly. This is the only thing that's relevant from the user perspective.

>I fully agree with that (though running unit tests on a single unit of code is very quick).

This of course requires you to write and maintain the test for each single unit of code.

>Sure. But in my experience: most codebases have little to no integration tests, and they cover things like "make sure login is not broken" or "make sure saving an entry works" as opposed to "make sure login does not break with the login 'null'" or "make sure we reject an entry which contains invalid XML", because the cost of setting up scenarios is much higher than with integration tests.

Your argument here isn't that integration tests don't work, but teams you worked with haven't bothered using them correctly.

The same problem often happens with unit testing. I've seen many projects where people start out writing lots of unit tests, and then after a month or so things start sliding, then you have large swaths of code without tests and lots of failing tests, and then you just turn them off all together. That's a very common scenario in my experience.

<comment><USER5> > The goal is to test how your code behaves and not what the external tools > are doing. In my testing I capture the expected response from the external > system and replay it in the test. My interest is in what the application is > doing with a given input.

Fair enough. But according to your definition, this still does not test correctness, since if you feed your actual SGBD/LDAP/etc with invalid data, your program will still produce an error.

> I'm not sure what this setup is exactly.

Consider that you have, say, a web application. You have a form, and you change the email normalization rules.

With integration tests, you simulate a POST request with a the form data (all 56 fields of them), you capture the Location header in the result, because you need to know what ID you have generated, and you do a SELECT in your in-memory database to find out if your user email is correct.

With a unit test, you simply build a user, apply the normalization function, and validate that the email looks as expected. Which is one of these scenarios is likely to be less code?

> Unit tests are also a huge overhead in maintenance. Any time you make a > change in code, you have to go and update many tests. As you yourself point > out, since you're testing many scenarios your tests often have more code > than your actual application.

How do integration tests help with that? You're going to either end up with the same number of tests (but with more code) or you won't code the tests, and you may end up with a new issue in the bugtracker next time you release.

> I don't think unit tests are a valid way to ensure correctness either. Your > individual pieces of code might be correct, but how they interact might be > wrong. The only way to capture the actual use cases is by running end to end > tests.

I'm actually not advocating unit tests as an _alternative_ to integration tests, but as something complementary. It is an effective way to test the effectiveness of a unit of code, though.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Hm, I have an issue with the absolute qualifier "best". Best in what respect?

I'd personally say Python is best.. for general data manipulation. But it's slow.

Go is best.. for network and concurrent programming, but it's rough around the edges and comparably low level.

C is best.. for precise control of the hardware. No hand-holding here. But that's also it's weakness.

C++ is best.. has all the bells and whistles you can think of, and more. More of the later probably.

PHP is best for.. masochists and people used to it. It's also one of the quickest ways to create a web application by completely abstracting the low level stuff away.

C# is best.. for religious people and people who buy into the Microsoft ecosystem. Strong library selection.

Java is best.. for people who are looking for a job. As boring as enterprise is, they have money and look for Java devs.

VBA is best.. if you are on a locked down corporate environment, just because it's almost the only option.

<insert language> is best.. <advantages>, but <constraint>.

So, you want to tell me that Scala has all advantages and none of the disadvantages? I don't buy it..

<comment><USER8> Legally, best is a vacuous term, meaning "as good as anything else." So if you say "this is the best tire ever" you can't be sued, at least in an English speaking country (unless they spell it tyre).

Critically, never take a "best" statement at face value since these things can't be measured anyways.

</comment></comment><comment><USER9> I wish I had this much confidence in any one language.

I'm productive with Python, but it lacks many useful things and I'm no longer comfortable with the rampant mutation.

I like Haskell and the type system is extremely useful (typeclasses ftw), but I haven't managed to become productive using it.

Scala scares me like C++ does, through sheer size.

Rust is very interesting, but not yet mature enough. I'm not even certain that level of abstraction would generally be the one I want.

Clojure is perhaps the closest (especially with core.typed and ClojureScript), but the dependency on the JVM is unpleasant for me to say the least.

<comment><USER10> you might try julia. it's a bit like python with optional types and (the promise of) speed. i am hoping it works out (and agree in general with your viewpoint otherwise, except i haven't tried rust or kotlin).

</comment></comment><comment><USER11> Clojure and Haskell represent untyped and typed FP better and are nicer to use in actual work.

<comment><USER12> I disagree. I've used Clojure, Scala and Haskell in numerous projects and I'd personally choose Scala over Clojure every single time. Language arguments like this are pointless.

<comment><USER11> Well, that might be because you prefer typed languages, which then leads to Haskell in that case. You can't cherry pick one of the two options I mentioned and then act as if that invalidates the whole thing.

I also said not that Clojure and Haskell were vastly superior in every way, but that they individually represented their language niches better.

<comment><USER8> Haskell's options for nominal subtyping are incredibly limited; Scala goes much farther (lets not get into O'Haskell). Much of Scala's power is missing from Haskell, or at least, is quite differently directed. As for dynamic typing, Scala is definitely not trying to compete with a dynamic language.

<comment><USER11> Right, and how well do subtyping and implicits get along?

This is the problem, everything and the kitchen sink is tossed into Scala without any consideration for how well things work together because they've let it be a PLT grad students playground.

[http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...](http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu)

[http://www.youtube.com/watch?v=TS1lpKBMkgg](http://www.youtube.com/watch?v=TS1lpKBMkgg)

The Scala community didn't lose one its best core developers for nothing.

I mention Clojure and Haskell in the same breath because FP and immutability are what I care about and Scala fails to be a nice functional language.

<comment><USER8> No idea who your demigod is, but Martin is probably the best programmer I've worked with. How subtyping is combined with type inference in Scala is quite workable, not perfect, but not a train wreck either.

Scala isn't really the best functional language, but it might be the best OO language out there, especially with traits, no other statically typed language has done mixins as well.

<comment><USER11> Then please stop selling Scala as being about type-safety or FP, because it makes them look bad.

Edit:

Also the demigod is paulp who worked on the Scala compiler team for five years. Hard to miss if you watch Scala dev at all.

<comment><USER12> That demigod also has a very long list of complaints about Haskell and Clojure. He doesn't think either of them are worth using either.

<comment><USER8> Many PL enthusiasts aren't satisfied with any language (me included); there is plenty of critique to go around.

And why should we be satisfied?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> > To my eyes this is half the genius of Scala: things that would have to be > config files in another language are instead just Scala code that uses > particular functions and classes[2].

That's cute; he seems to think the reason for managing configuration information in separate files is due to the inflexibility of Java. Let's hope that one day he has to deal with a non-trivial project and is enlightened.

</comment><comment><USER14> > a language core should be small but flexible; despite the power and > complexity of Scala libraries, Scala's language specification is much > shorter than Java's

Looks like GrǬǬvy, also begun in 2003, went the other way, making its language grammar larger but its core methods small.

Beginning with a clone of Java's grammar, they expanded it with lots of extras, see [http://svn.codehaus.org/groovy/trunk/groovy/groovy- core/src/...](http://svn.codehaus.org/groovy/trunk/groovy/groovy- core/src/main/org/codehaus/groovy/antlr/groovy.g)

And for the core methods [http://groovy.codehaus.org/api/org/codehaus/groovy/runtime/D...](http://groovy.codehaus.org/api/org/codehaus/groovy/runtime/DefaultGroovyMethods.html) (note the methods marked "deprecated" still actually exist but were repackaged into other classes for Groovy 2.x).

</comment><comment><USER15> "Actors, a core feature in Erlang, are just another library in Scala." \- or any other language out there.

<comment><AUTHOR> Do you know a good actor library for another language? I'd be very interested to hear of one for Python, because I still have to use it sometimes.

<comment><USER16> For Java: [http://blog.paralleluniverse.co/post/49445260575/quasar- puls...](http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar)

Yes, you can use Akka from Java. Just to show that you don't need something like Scala to implement an actor system.

<comment><AUTHOR> I don't see any Java examples on that page, just Clojure.

</comment></comment></comment></comment><comment><USER17> I will not rehash my strong objections to Scala, but I think that this kind of discussion about programming language starts off on the wrong foot – the same wrong foot that led to what I perceive is everything that's wrong with Scala.

A new programming language that hopes to achieve wide adoption is a big deal. A very big deal. C has been in widespread use for 40 years now, and Java for almost 20. You _could_ switch a language every five years or so, but that means that you're not in "mainstream software development" but in some kind of Silicon Valley startup (a tiny minority among software developers). Mainstream software developers don't switch languages every five years, and in most case, not even every decade, so they'd better get the language right.

But what makes a programming language _right_? That is a big question. Obviously, adoption, which is also a result of marketing, is a major factor regardless of the language's intrinsic merits. Also, you must consider your domain. Ruby is great for short-lived projects; Java is great for big, complex projects with dozens or hundreds of developers.

But assuming you've taken all that into account, making a switch better be really justified. The problem with the article, I think, is it focuses on specific _language features_ (effects, delegation, etc.), which is what got Scala into trouble (IMO) in the first place.

When thinking about a new programming language, especially one not intended for research but for widespread adoption, this is not the way to go. I believe we should start by thinking what are the big problems with software developments, and how we can address them with a new language – one that does not simply offer this or that convenient feature, but gives a really big advantage, one that merits a switch. Java has done it with a GC for a C++-like language, and to a lesser degree, with threads. Clojure and Erlang address the issue of state - Erlang because of fault-tolerance, and Clojure (mostly) because of concurrency.

On the other hand, some languages, like Ruby, focus on "developer productivity", which often means getting to working, useful code quickly, while maintaining good readability. This is, no doubt, important (for some domains much more so than others), but is this a major problem of software development today?

Also, the article talks a lot about type safety. But type safety is language feature which is a means to an end. That end can be project maintenance/manageability, and arguably more correct code. But are there other ways of achieving this goal? I'm not saying there are, I'm just saying we should start by studying the problem, not examining particular solutions. Every language feature must be a part of solving a big problem; big enough to justify switching languages. After all, that's is a big deal so we better get it right. So, what _big_ problem are you trying to solve?

<comment><USER18> As some people already mentioned, you should really stop treating your personal opinions (which quite often lack both substance and any evidence) as the one true thing.

I also find it a bit irritating that you love the vague claims like in the last article, but don't like articles with a precise and to-the-point description of issues. It's almost like you want to love all negative articles on Scala, but have to hate even neutral or remotely positive ones, completely irregardless of the quality of the article and the issues raised in them.

It leads to this whole train-wreck of reasoning here which you seem to be forced to post in pretty much every post with the word "Scala" in it.

Nobody can prevent you from spending your time with things you hate, but from my experience, live is happier if you spend it on things you love.

I can't say it any better than dancapo said it here: [https://news.ycombinator.com/item?id=6844600](https://news.ycombinator.com/item?id=6844600) Maybe you should really at least try to consider the points he raises.

<comment><USER17> There is very little in my comment pertaining specifically to Scala. I did not like or dislike anything in the previous article as I barely skimmed it (unlike this one, which I've read). The specific issues mentioned in this one are all well and good, but since the main point here is about ditching an old language in favor of a new one, I responded to that. I don't know which "reasoning" you're referring to, as I simply pointed out that when discussing something that can be a major decision for a software company as switching languages, it's best not to start with specific language features, as they may lead you down the wrong path.

Also, I try to form my opinions after a lot of consideration, and you can be certain that I read most arguments against them. Sometimes I remain unconvinced, as in the case of Scala. I am not prejudiced against Scala. I think Martin Odersky is a very smart PL researcher, and when Scala first came out many years ago, I actually strongly advocated adopting it in a very, very large organization. My opinion has changed over the years, partly because of the path Scala has taken, partly because of new options that are now available, and partly because I've gained more experience with large projects and large teams.

My own criticism of Scala is, I believe, well informed; the fact that you consider its lack of minute detail as lack of evidence demonstrates the Scala's community obsession for tiny details to the detriment of a grander vision.

The comment you referred me to demonstrates the same. I do not dispute that Scala's features are well integrated _in the compiler_. It's a very nice compiler. What I meant in my comments on those other threads is that Scala mixes concepts whose mix creates a negative synergy, whose only purpose is that sometimes you can use one concept and sometimes you can use another. It doesn't matter that case classes are implemented as classes. Conceptually, they are meant to be used differently; again, that's getting bogged down in detail. Scala never gives a compelling _reason_ why it is so useful to mix different concepts in a single language and pay such a heavy price in complexity, other than "sometimes it's better to use one and sometimes another". That's not a hallmark of great design. What big _software development problem_ (as opposed to a PL research problem) does Scala solve?

<comment><USER18> > My own critique of Scala is, I believe, well informed;

Sorry, but no it isn't and it's painfully clear to a lot of people.

> the fact that you consider its lack of minute detail as lack of evidence > demonstrates the Scala's community obsession for tiny details to the > detriment of a grander vision.

You have a lot of talent in interpreting things the way you want. If people would have said "there are minor inconsistencies, but Scala has a grand vision it focuses on and that's what counts" you would have turned around and argued that it's the lack of attention to detail which makes everything in Scala horrible.

Sorry, but I have seen how you do this more than I care to count already. It gets tiring and embarrassing to read.

People have tried to tell you that "making up facts to retroactively fit your opinions" is not a good thing and then you just do it again:

> I do not dispute that Scala's features are well integrated in the compiler.

Let's just ignore the way you try to derail the debate here and move the goalposts around for a minute, because probably everyone who has spent 5 minutes to look at the actual source code realizes how mind-boggling wrong this claim is.

The compiler goes to great lengths to catch all the weird corner cases and shield it's users from inconsistencies which e. g. sometimes arise when running on a JVM or having to deal with other languages running on that platform.

Please have a look at javac, fsharpc and others. None of them come even close to effort scalac does to present its users with a consistent, coherent behaviour. They just let the user deal with all those minor annoyances.

> Scala never gives a compelling reason why it is so useful to mix different > concepts in a single language and pay such a heavy price in complexity, > other than "sometimes it's better to use one and sometimes another". That's > not a hallmark of great design.

Sorry, you mentioned it yourself already that your mainly interested in a language which dresses up Java's minor pain points. I can understand that when coming from that point of view trying to understand the reason why Scala does things in a certain way is not interesting. But you should at least differentiate between "there is no reason" and "I didn't care enough to look for the reason".

> What big software development problem (as opposed to a PL research problem) > does Scala solve?

\- Abstraction and code maintenance: In all languages, you can arrive at a certain point where refactoring/abstracting things any further (to increase readability, maintainability, modularity) doesn't add more value than it costs. The difference is that in Scala you are the one who can make this decision, not the compiler. This is a huge advantage, which can't be understated, but is also hard to describe if you haven't seen it yourself. Dropping into an unknown code base and being able to be positive that changing/fixing/modifying one item involves touching one place, instead of possibly dozens or hundreds of pieces of code, is a considerable benefit. (Not really related to this, but implicit classes are an interesting example of how lots of code maintenance issues are made impossible by design, when compared to inferior approaches like extension methods.)

\- Long-term evolution and extensibility: Scala gives you lots of options and tools to evolve your code in a way which minimizes the impact on the consumers of your code. Have a look at how Scala doesn't expose any public fields in classes, how easy ensuring binary compatibility is with tools like the Migration Manager, have a look how typeclasses enable you to design your code with extension points in mind right from the start, have a look how @deprecated and friends allow you to have meaningful transitions between old and new code if necessary. This reduces the amount of technical debt accumulated over a period of time and makes it easy to keep existing code bases up to the changing/growing requirements of the real world.

\- Closing the decade-old gap between data inside and data outside of a language: Type providers go a huge step toward a state where developers can just stop worrying whether their data is in the source code of their language, inside a database, stored in an XML file, or wherever else. This will be a huge productivity boost to all developers.

<comment><USER17> > Sorry, but no it isn't and it's painfully clear to a lot of people.

As is the opposite... Language debates are like that.

> -Abstraction and code maintenance...

No. Scala does not enforce that. You can no more be certain that changing one item involves touching one place in Scala than in, say, Java. Scala does not enforce (or even make violations hard) thread-local state modifications as Clojure does. It allows global, mutable, variables. Scala gives you some useful abstractions with one hand, while giving you harmful ones with the other. In fact, structural types are a prime example here. You can rename a method and your code will break just as it would in Ruby or JavaScript.

> -Long-term evolution and extensibility

This is really unsupported by evidence. How many Scala projects over, say, 2MLOC and older than 5 years are there? C++ had the same claim. Some of its abstractions helped maintenance, while some harmed it. But Scala's adoption is too small to tell.

> \- Closing the decade-old gap between data inside and data outside of a > language

Yeah, they're cool, but Java has had (compile-time) annotation processors (as well as AST generators) for quite some time, and they're well integrated with IDEs, too. Adding macros to the language seems a bit of an overkill.

Also, I really doubt that will be a "huge productivity boost". Data formats are pretty standardized. You don't come up with a new one every week, or even every month, and most common data formats already have "type providers" for most languages (say JSON, CSV, XML, SQL, protocol buffers, ASN.1). This is not a big, unaddressed, problem with modern software development.

<comment><USER18> > As is the opposite... Language debates are like that.

It would work much better if you didn't make up assumptions and tried to sell them as facts. There is a slight difference between "it's possible to disagree about X" and "your claim about X doesn't survive 2 minutes of fact checking".

> Scala does not enforce [...]

You can accept the points I made or discuss them, but this is just moving the goalposts AGAIN.

You asked "What big software development problem (as opposed to a PL research problem) does Scala solve?"

And I gave you a few points.

You didn't ask "Is Scala the best thing ever and the last language we need?" and I certainly didn't answer "Yes!". With your own straw-man which you're trying to make up now, probably only Haskell and a few close friends would suffice, but certainly none of the languages you're trying to sell. Hey, in Scala could at least use the effect plugin, but I haven't such a plugin for e. g. Kotlin yet.

> In fact, structural types are a prime example here. You can rename a method > and your code will break just as it would in Ruby or JavaScript.

Why should that happen?

> This is really unsupported by evidence.

Don't believe me, just look into to spec or try the language. Again I didn't claim that Scala solves all the problem and makes it impossible for malicious people to write code in a way which will break in the future. No language claims that and you didn't see me claiming that either. As I mentioned, Scala gives you a lot of useful tools which can reduce maintenance issues and some features are designed around the idea of helping you achieve that.

> Yeah, they're cool, but Java has had (compile-time) annotation processors > (as well as AST generators) for quite some time, and they're well integrated > with IDEs, too. Adding macros to the language seems a bit of an overkill.

I can't really tell whether this is sarcasm or not.

\- There is a reason why basically no language since Java adopted that model.

\- It's pretty damning to see that in the few months in which macros existed, more useful functionality was written than for Java annotation processing ever.

\- Annotation processing integrates very poorly with IDEs, I'd say not at all. Again, there is a reason why pretty much every annotation processing library needs a special IDE plugin to stop the IDEs from being confused. Just try developing with AspectJ in Eclipse without the AspectJ-for-Eclipse plugin. It just doesn't work.

\- Annotation processing adds additional hassle to the build script, which needs to be setup, configured and maintained. It's not the first time that I have seen that multiple annotation processing plugins interfered with each other, leaving behind unusable class files and runtime exceptions in production.

\- Again, IDE support is very poor. You can't even jump from an annotation to the corresponding annotation processing code. The IDE will just jump to the annotation declaration, which is completely unhelpful.

Do you want to have a guess which of the issues mentioned above can't exist by design in Scala's macros?

All.

> Also, I really doubt that will be a "huge productivity boost". Data formats > are pretty standardized. You don't come up with a new one every week, or > even every month, and most common data formats already have "type providers" > for most languages (say JSON, CSV, XML, SQL, protocol buffers, ASN.1). This > is not a big, unaddressed, problem with modern software development.

I kind of feel like you are missing the context here. I recommend watching one of the F# talks for an introduction. Again, just because you don't see the benefit or the reasoning behind it, doesn't mean that the brightest minds in our profession are all wrong.

<comment><USER17> > You can accept the points I made or discuss them, but this is just moving > the goalposts AGAIN.

I am really not. My claim is a general one about Scala's kitchen-sink design philosophy, and why it's inappropriate for an "big engineering" language, as opposed to fast development languages like Ruby or Perl, yet it is you who insist on focusing on detail, which is part of the problem. So I responded to the detail.

> Why should that happen?

Sorry, I made a mistake there. The compilation will break when you try to pass the object to a method that accepts that structural type.

> It's pretty damning to see that in the few months in which macros existed, > more useful functionality was written than for Java annotation processing > ever.

You are most certainly wrong here, though I can't prove it. You're forgetting that 99.9% of Java code is not open-source. In the organizations where I previously worked we used annotation processing where needed.

> Again, just because you don't see the benefit or the reasoning behind it, > doesn't mean that the brightest minds in our profession are all wrong.

Those brightest minds are usually the brightest minds in PL research. I don't think it's a coincidence that most of the languages designed by them, while brilliant in some respects, are not widely adopted in the industry. You can only attribute some of that to marketing. I also do not think it's a coincidence that all languages developed at Google, a company that knows a thing or two about large scale development, follow the Java philosophy.

I am not a PL researcher and not particularly interested in PL research aside from learning a thing or two about the potential of programming languages, but I am very much interested in moving the software development industry forward. Some of the things PL researchers focus on I find to be genuine problems with software development – like taming concurrency, which Haskell does a good job at though perhaps at an unacceptable cost to the industry, and Clojure and Erlang do an excellent job with despite their lack of PL researchers – while other areas, like developer productivity, I find to be the wrong problems to focus on.

Let me explain the last point because I think it's important. We have some good languages (Ruby, Python) that are excellent for productivity, and are extensively used in some domains. Where those languages fail - concurrency, large-scale engineering - productivity is less of an issue.

But then I found Clojure (and, mind you, I personally prefer static typing and think it's generally better for engineering, though I recognize this is just a means to an end), and saw a language that is probably as "productive" as Ruby, yet actually tackles the big issues (like making sure some careless team member does not introduce a very hard to find race condition).

I think Scala takes powerful though complex features and channels them – unlike, say, Haskell – into all the wrong places (productivity), and at the same time makes it impossible for a mere mortal to understand how a basic collection is written. You can argue details all you want with me, and say that you _could_ do this and _could_ do that, but a language that makes collections the domain of experts without at least fixing the _real_ hard issues, is just plain misguided.

<comment><USER18> > I am really not. My claim is a general one about Scala's kitchen-sink design > philosophy, and why it's inappropriate for an "big engineering" language, as > opposed to fast development languages like Ruby or Perl, yet it is you who > insist on focusing on detail, which is part of the problem. So I responded > to the detail.

And that claim is just not defensible in any kind of way. Have a look at C# and C++. Both of them are magnitudes more kitchen-sinky than Scala by pretty much every measurable metric. Both of them are considered to be "big engineering languages". Don't believe me, look into the spec.

Scala is certainly not the language which ships features which have been explicitly designed for working with the MS Office API for example. I can give you dozens more if you want.

> You are most certainly wrong here, though I can't prove it. You're > forgetting that 99.9% of Java code is not open-source. In the organizations > where I previously worked we used annotation processing where needed.

Well, there is certainly Scala code which isn't open-source, too. That doesn't mean that looking at the existing, available software out there is not a reasonable metric.

Anyway, even if that point was wrong, I have mentioned a lot of issues concerning Java's annotations processing and pretty much every item should be a deal-breaker if the goal wasn't to ship a failed experiment. People use Java annotation processing, because the alternatives are even worse, not because Java annotation processing is so great.

> Those brightest minds are usually the brightest minds in PL research. I > don't think it's a coincidence that most of the languages designed by them, > while brilliant in some respects, are not widely adopted in the industry.

Those are the brightest minds which shipped most of the stuff which made C# great. I wouldn't call C# PL research by any means.

> while other areas, like developer productivity, I find to be the wrong > problems to focus on.

Developer productivity is certainly not the sole focus of Scala. But developer productivity means that people have more time to look at the hard problems they are trying to solve instead of fighting the language and shipping the business value they are paid for instead of wasting time on unrelated issues.

A language which has e. g. concurrency done right, but is so painful to deal with that everyone writes single-threaded code to get home early, is completely useless.

> but a language that makes collections the domain of experts without at least > fixing the real hard issues, is just plain misguided.

Scala's collections are the most pleasant ones I have worked with and I think most people will disagree on that. I also think that Scala's trade-off on letting the library authors solve hard problems once instead of letting every user deal with them on their own each and every time they use it is a reasonable trade-off.

In other languages you would probably have to implement every operation yourself if you wanted to define a new collection type. Mostly tedious, error- prone work. In Scala instead, you understand the CanBuildFrom facility once and get almost the complete implementation for free, overriding only the operations you care about. Note that understanding CanBuildFrom is a one-time effort, while in other languages you will hit those issues every time you want to create a new collection type. Again, seems like a reasonable trade-off to me.

<comment><USER17> BTW, when I said developer productivity I didn't mean actual productivity (which is harder to quantify, as it includes all time spent on testing and maintenance throughout the lifetime of the project), but "developer productivity" as it's become known in PL vernacular to mean less boilerplate and fewer LOC.

And I guess we'll just agree to disagree, because I think we disagree about what's important even more than we disagree about the merit of each feature in Scala on its own. I believe Scala's tradeoffs are very misguided (and yeah, C++ is certainly similar) while you think they're justified. I believe that even an excellent feature should be left out of a language if it increases its complexity and the benefits do not solve a problem I care about every day, while you might think it's OK to increase a language's complexity even for features that won't be used so often. I think that in modern software development, application developers are better served by an opinionated language (especially when it comes to concurrency) while infrastructure software developers (assuming your software environment allows to easily mix languages) can certainly live with some annoying boilerplate if the language "closer to the metal", but both value simplicity; you might think that "one language to rule them all" with few constraints is preferable even at some cost to both types of developers.

<comment><USER18> > I believe that even an excellent feature should be left out of a language if > it increases its complexity and the benefits do not solve a problem I care > about every day, while you might think it's OK to increase a language's > complexity even for features that won't be used so often.

No, I don't think we disagree here at all and I think it's one of the design principles behind the language.

"do not solve a problem I care about every day" is just another phrase for "anything I'm remotely unfamiliar with". And again, just because you decided to not invest the time to understand thing X, doesn't mean all daily users of X are idiots.

You couldn't offer much here except structural types, so let me just take it is an example. Structural types were not "added" to the language because they are "so great and useful", but because it eliminated an inconsistency where one would have types which one could express and a subset of types which would be e. g. a valid type for a method's parameter.

Treating types consistently is a huge reduction in complexity for users because they don't have to divide types into types which can be used everywhere and types which can't be used everywhere. If you think this is just an academic idea, have a look at the weird corner cases this creates in Java where you can call methods on an instance directly, but if you assign that instance, the methods seem to not exist anymore.

Ceylon, by the way not only agrees on that with Scala, but the designers marked this as one of their pillars of language philosophy (principal types).

Almost everything you can do in Java is probably easier and more consistent in Scala. Claiming that those things which Java can't do (e. g. having a remotely useful type system (1), typeclasses, ...) make the language simpler is just trying to ignore that problems are not solved by wishing them to go away. Those things just crop up in an ugly way elsewhere, be it in ridiculously complicated frameworks, in bytecode manipulation, etc.

(1) There is a reason proponents of dynamically-typed languages bring up Java when they explain what's wrong with static typing.

<comment><USER17> > "do not solve a problem I care about every day" is just another phrase for > "anything I'm remotely unfamiliar with". And again, just because you decided > to not invest the time to understand thing X, doesn't mean all daily users > of X are idiots.

I wasn't calling anyone an idiot, and I don't know who you are, buddy, but I'm starting to get the feeling that I might have some years experience over you; perhaps even a decade, so chill.

Look, you can go on believing Scala is simple all you want for whatever measure of simplicity you define; Martin Odersky even tried using grammar size as a measure (personally, I wouldn't go for consistency as a measure, though, because machine language is also very consistent, but YMMV...)

Then, you can try to get the team working on the next aircraft-carrier control system (or a huge mail routing system or air traffic control software) to adopt Scala, and see how fast they throw you out the window.

> Claiming that those things which Java can't do (e. g. having a remotely > useful type system (1), typeclasses, ...)

Again with the features. _I don 't care about what type system a language has_ and how mathematically correct it is. I care about writing maintainable, correct and efficient code. Types might help achieve those goals, but it's not as if the more "correct" the type system is, the better those goals will be served. Why? some of the reasons are cultural, some have to do with the way humans think, and some have to do with the way computers "think".

You think Scala helps achieve those goals, I think Scala is detrimental to them. I abandoned Scala about 5 years ago and I have no intention of using it again, especially now when there are languages which I find superior to Scala in every respect that I think matters. If you feel Scala works for you I'm not going to convince you otherwise. For me and for the organizations I've worked for it didn't work at all.

<comment><USER18> > You think Scala helps achieve those goals, I think Scala is detrimental to > them. I abandoned Scala about 5 years ago and I have no intention of using > it again, especially now when there are languages which I find superior to > Scala in every respect that I think matters. If you feel Scala works for you > I'm not going to convince you otherwise. For me and for the organizations > I've worked for it didn't work at all.

I think this explains all of it. The thing you are talking about has pretty much no resemblance with Scala today. You can bash Scala-from-5-years-ago as much as you want as long as you stop misleading people that your claims are in any way relevant to what Scala is today.

Really, look at how your extrapolations from pre-historic Scala versions worked out til now. You only embarrassed yourself. I recommend being honest next time and just sharing your experience about Scala 2.5/2.6/2.7. I think we could all have a good time telling war stories, considering how hilariously unstable the compiler was at that time.

<comment><USER17> Dude, look, I stopped using Scala because it's gotten _sooo_ much worse worse with each version; whatever coherence it had at first, it quickly shed away in a frenzy of misguided notions about what developers really need. I actually liked it in the early days. My _claims_ are my view, as someone who's been developing software professionally for over two decades. I am well aware that there are those who disagree. Of course, you are entitled to your opinion. It could be the best damn language in the world for you, but it sucks for many, many others. I can tell you that some companies looked at Scala carefully and rejected it; some adopted it only to discard it a couple of years later. You should accept the undeniable fact that Scala does not appeal to some knowledgeable, experienced people, even after they consider it carefully. And it's OK - I like many things that other people don't like, and they have good reasons not to like them. I would concede that Clojure, too (and I _really_ think Clojure is an exceptionally well designed language), does not have a very broad appeal; neither does Scala.

Use it in peace. If 5 years from now a significant portion of the software development community is using Scala, then you were right and I was wrong; if not, you'd better recheck _your_ convictions. Maybe the language you like so much doesn't solve problems that hurt badly enough, or doesn't solve them well enough, for people to pay the price of its complexity and lack of coherence.

Either way, Scala has certainly taught us a few things and we can learn from its mistakes. Maybe some of the lessons will be used to create a language that works for me and those who see things my way, too.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> If you want Haskell, but don't want to leave the JVM, Frege might be an option.

[https://code.google.com/p/frege/](https://code.google.com/p/frege/)

</comment><comment><USER20> I have problems a few random floating statements: "decorators have well- defined semantics in Python" Python lacks well-defined semantics for just about anything. even simple expressions like 1.0 + 1/2 will evaluate to different things depending on which python version you're using.

"Even F# simply isn't powerful enough (never mind OCaml)" evidence, please?

<comment><USER18> Higher-kinded types, type-classes, traits ... just a few things which come to mind.

</comment></comment><comment><USER21> Best language for what? This is highly subjective.

<comment><USER22> The best Java improvement :)

<comment><USER21> Ceylon is a better improvement imho. The problem with scala is that it is not best for anything. It is a jack of all trades but does not surpass any competitor.

<comment><USER18> > It is a jack of all trades but does not surpass any competitor.

I think this a statement which deserves some actual facts.

</comment></comment></comment></comment><comment><USER23> I want a strongly and statically typed, preferably compiled, multicore PHP, basically. With good tooling, if the world was perfect. Scala seems to fit that in my limited playing, and seems to be the closest in terms of what I want out of a language in general. I'm still keeping an eye out though, as Scala does have some rough edges.

</comment><comment><USER15> It might be best overall, but specific features can be inferior to other languages. C#'s dynamic keyword for instance.

<comment><USER24> I don't think the author is denying this fact at all?

There's plenty in Scala that other languages do better, the author's claim is that no languages puts _all_ of its features together better than Scala.

<comment><USER15> Then the post subj should be changed, otherwise I could argue it's a "jack of all trades - master of none" kind of scenario.

</comment></comment></comment><comment><USER25> Possibly the worst post I've ever read here. Horrendous title and completely devoid of any useful content.

</comment><comment><USER26> Just another day on HN and another trolling, controversial post...

</comment><comment><USER27> Flagging for the editorialized title.

</comment><comment><USER28> so many Scala language flame wars! it must be doing something right!

</comment><comment><USER29> Why the sudden Scala love/hate on HN?

</comment><comment><USER30> Waiting for the 'why scala is a bad language' response

<comment><USER31> Oh, this already is a response to a posting from yesterday

[https://news.ycombinator.com/item?id=6829725](https://news.ycombinator.com/item?id=6829725)</comment></comment>


Soaping away your outer dirt may lead to inner evil - <AUTHOR> http://www.economist.com/displaystory.cfm?story_id=12630193

<comment><AUTHOR> Evidently, "to the pure, all things are pure."</comment>


StackOverflow is full of children - <AUTHOR> https://sethvargo.com/stackoverflow-is-full-of-children/

<comment><USER2> StackOverflow - like many popular forums - is a place where a lot of _inexperienced_ people end up spending their time. This is almost a tautology: "pop-forums full people that act inexperienced" end up that way because... inexperienced people end to flock towards popular sites full of like-minded people.

Given that most people will at least try to helpful, you end up with a lot of people re-distributing the bits of knowledge they've learned. This often starts as cargo-cult behavior, and - if left to grow in isolation - it can turn into groupthink[1].

It's easy to jump to the conclusion that some form of moderation or judicial process is needed; if the greater resource is to be saved, the trolls/n00bs/"children" need to restrained so they can't make a mess that pollutes the community. I think this approach fails to address the actual problem: that some people need a lot more _education_ before they can progress past the "inexperienced n00b"/"child" stage.

The mechanics in place at StackOverflow - even with its flaws - can be a very useful tool. If enough people who _are_ experienced (in technical or social areas) spent some time there regularly, the extra role models would help this greater social problem a lot. Answer the same n00b questions over and over is annoying, but that's the kind of effort it takes to maintain a community across generations.

[1] Regardless of what you think of the language itself (or this well-known rant against it), the article "PHP: a fractal of bad design"[2] is a good case-study of what happens if that groupthink is left in isolation far too long.

[2] [http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad- design/](http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/)

</comment><comment><USER3> I see this on Reddit, StackOverflow, Youtube, and pretty much every other community site. I'm not sure if it's because there are actual kids posting or socially inept and immature adults.

Either way, the mob mentality is startling and shows me why we need a proper judicial system.

<comment><AUTHOR> Definitely. I see this a lot, but this one affected me personally, which is why I felt the need to talk about it. I'm not sure where the level of immaturity happens. Maybe it's because we aren't interacting with humans directly?

<comment><USER4> I suspect a similar hypothesis.

The analogy I like to use is traffic. Imagine any other setting where if you make a minor mistake or go too slowly for someone else, people start yelling and cussing at you.

When in traffic, you can just drive away and odds are you will never interact with the same person again. The whole time your interaction was machine-to- machine rather than human-to-human.

Large, public web sites are quite similar. We don't interact on a human scale, but with a machine. Most of the people we interact with we'll never interact with again.

When you remove face-to-face communication and add a sense of anonymity, you remove a lot of the subtle social forces that normally keep people in check.</comment></comment></comment>


Humans Are Bad at Estimating Area: Avoid Pie Charts, Circles and 3D - <AUTHOR> https://capitalandgrowth.org/answers/Article/3173280/Humans-are-bad-at-Estimating-Area-Avoid-Pie-Charts-Circles-and-3D <comment><USER2> The bubble chart is possibly the worst visualizations, in close competition with the abominable word cloud. Yes, they are visually attractive, but so much more difficult to interpret than a trivial Pareto/bar chart.</comment>