I'm a self-taught developer with haskell in my arsenal, although that being said I have an MSc in theoretical physics which probably helps me appreciate the power of its paradigm.
You are sure he was never at a university? And why are you drawn to Haskell?
For me I only had to deal with it a bit at university and I found the concept interesting, but could not imagine non math people to use it for anything as a language of choice
And I think imperative languages are way more easy and clear to read and write.
I allways imagined that you have to be a math nerd to prefer Haskell, but apparently this guy is not a math guy, but loves Haskell .. so ok, good counterpoint.
> And I think imperative languages are way more easy and clear to read and write.
Because it's what you've had exposure to. Perhaps, they're even objectively easier to read and write, I don't know. It's also completely besides my point.
My point was that I want my programs to work as desired. That's orthogonal to how easy it is to read and write. I don't want runtime exceptions where I could've gotten a compile-time error.
But I had exposure to math functions much earlier. And I never liked their syntax. I did understood the math, but the math language made it harder for me.
And null pointer exceptions? They only happen to me very rarely, when I quickly hack something together and then it is a "oh forgot - and fixed" problem. The problems I do struggle with are non reproducable race condition fun etc. and I doubt haskell could help me with them.
Or I struggle, because I do not really understand my problem, or a certain libary ... or, because I misunderstood existing code.
So how on earth are correct programms orthogonal to how easy it is to read and write them?!? Did you ever had to use someone else code?
Or your own that you wrote 5 years ago (or sometimes 5 days)?
With any bigger project it is all about how easy it is to read and write them.
> And null pointer exceptions? They only happen to me very rarely, when I quickly hack something together and then it is a "oh forgot - and fixed" problem.
And you never run into NPEs in production? It's something you always discover during development? How?
> The problems I do struggle with are non reproducable race condition fun etc. and I doubt haskell could help me with them.
In a pure system, thread race conditions are impossible. You can still get race conditions for your external effects, which is unavoidable.
The parent said they didn't know what for-in was, which implies they were using a language like C for their side projects which only has for (i=0;i<n;i++) loops.
My CS degree (2002-2006) did not explicitly cover "for x in y" iterators. But it did cover an understanding of algorithms and data structures well enough that I could implement one.
That was probably before they were really in style e.g. C# didn't add foreach / iterators until ~2005 with v2.0 and your curriculum probably lags a bit behind the industry state-of-the-art unless it was Ivy league
It has not been very long since CS degrees were taught entirely in C89 or C++98, and there are a lot of us who won't touch Python or Java unless forced to.
exactly - I had a similar learning curve (and no CS degree) where I could never remember what certain methods did but I knew exactly what to google for the answer
The article essentially claims that the more people there are the more likely it is that _someone_ will intervene. Which isn't the same as no one feeling less inclined to help since there are other people around.
The whole point of the "bystander effect" is that this diffusion of responsibility leads to nobody intervening. Nobody cares if the chances of a specific bystander intervening goes down when there's a crowd, all that matters is whether someone intervenes, and the bystander effect claimed that a crowd meant the chances of intervention would go down overall.
I'm understanding that's not the finding, although that's the popularly understood point. You would expect each person to be individually less likely to help when there are other people around. Somebody else might have already intervened, and you might just be getting in the way. Not everybody can help, at least not at once. I mean, in some situations, people actually fear to intervene, and have a legitimate fear for their own safety, but if they can call the police once they're secure (or if they are clearly secure e.g. viewing from a distance), people do it. A lot of people called about Kitty Genovese as it was happening, watching it from their apartments. That became a newspaper article - which was basically typical right-wing linkbait: it wasn't slow police response, it was the heartless crowd that killed Kitty.
That Slate dot com tier take became a theory, developed experiments, and discovered something that was obviously mathematically true: if not everybody in a group helps someone that they see in distress (only a subset do), but individuals always help when alone, then in groups, the average time before response for each individual is going to go up, and the average likelihood of any response at all from a particular individual is going to go down.
This would be true even if people were always helped faster by groups rather than individuals, and a subset of every group always intervened. The types of people that bystander experiments found to be likely interveners could just adhere to the stereotypes that people think of as physically authoritative and look to when something occurs. People look to them to intervene (large, male, athletic, maybe ethnic or rough looking in criminal/street situations) maybe those people intervene because there no one for them to pass the responsibility off to.
