jarrett

> virtually every developer I know well enough to know what they prefer uses either Linux or Windows

Interesting. It must be clustered, as you say.

I use a Mac largely because there are a handful of professional apps that don't run on Linux. (Otherwise, I'd probably go with Mac hardware and a Linux OS.) Which implies that the demands of my industry is what pushed me (and perhaps the people I know) onto Macs.

> there is probably a correlation between those who prefer a Mac and those who prefer a GUI.

It's not so much that I personally prefer a GUI. (I don't, in general.) It's that I make a lot of software for other people, so GUIs aren't a matter of preference but of professional obligation. Also, there are certain applications I'd like to do where a GUI is pretty much the only sensible option: Design tools, certain types of games, etc.

To make this discussion more concrete, here are some problems I've thus far found on the Mac:

- GHC ships with the wrong compiler path for (some version s of?) OS X, causing various C-related stuff to fail. https://gist.github.com/cartazio/7131371

- ghc-pkg gets itself into an error state pretty quickly after installing a fresh Haskell Platform, and ghc-pkg recache must be run.

- You must manually request the latest version of cabal-install. cabal install cabal-install by default gives you a version without sandboxes.

These are just a few of the issues that come to mind; I've run into quite a few more in my Haskell explorations. You can imagine how this state of affairs would cause a lot of developers to give up. I'm not at all blaming anyone in the truly wonderful Haskell community. Everything about Haskell is done volunteers, and I'm grateful for their work. I'm just offering a theory as to why Haskell hasn't been embraced as warmly as, say, Node or Go.

> Maybe the Mac/Haskell overlap is just too small?

Probably so. Though I would suggest that the neither one is a small niche in itself. Mac especially--it's the favored platform for every developer I know except one. Yes, it's less popular outside tech circles (probably due in part to the price).

Imagine this scenario: There are tons of Mac users who want to learn Haskell. They try it, but can't install libraries. The Haskell community never hears from them; one could say the system failed silently. Meanwhile, Linux works fine, and the Haskell-Linux community keeps growing.

So perhaps there's a self-reinforcing Linux-centric bias in the developer population.

Is there still plenty of coal that's easy to extract with primitive technology? If so, why hasn't it already been mined? (I would think the low-hanging fruit would go first.)

I believe historically that was achieved with stone tools. So you make some stone axes, hatchets, adzes, chisels, etc. You use those to bootstrap a basic metallurgy setup, including chopping the trees for charcoal.

I think energy is the bigger challenge. In Britain in the 1600s, for example, the growth rate of trees couldn't keep up with the demand for charcoal. That was one of the factors that led to the widespread mining of coal, which previously had not been a major energy source in Britain.

The easily mineable fossil fuels are pretty much depleted now. We rely on advanced technology to extract the fossil fuels that power us today. A rebooted civilization might be stuck with charcoal. In which case its energy usage would be capped by the growth rate of the forests.

The sandbox sounds great. I haven't been able to get Cabal 1.8 to install on a Mac, but I'd love to try it.

I hear that, and I hope that project works out. But I'm still interested in developing native apps. There's a reason so many professional applications (games, intensive apps like Photoshop and Blender, etc) are still native.

You may have seen The Birth and Death of JavaScript:

https://www.destroyallsoftware.com/talks/the-birth-and-death...

I don't know whether that prediction will come true. But obviously it hasn't thus far. For now, if I need native performance, I need native code. Sadly, that means C, C++, or Java until such time as Haskell libraries compile reliably.

Manual is OK if there's at least a clear path to getting something to install. I don't see that path, though.

My biggest issue is that I don't have the expertise to debug an obscure Haskell compilation error. I won't develop that expertise unless I can use Haskell over the long term on real projects. I can't do that unless libraries are available. So it's a chicken and egg problem.

I think the same is true for many people who'd like to dive deeper into Haskell. If we can't initially lean on the work of expert package maintainers, we can't ever become Haskell experts ourselves. I believe the developer community could expand very quickly if this problem could be solved.

I'd love to, but Haskell Platform ships with an old version of Cabal that doesn't have sandboxes. The new version of Cabal itself doesn't compile on the Mac. (In keeping with the theme of "nothing compiles.")

Edit: At least, I can't get the new version of Cabal/Cabal Install working on my Mac.

Sometimes I do. Often, if a Haskell package doesn't have a Github repo, I don't know how to contact the developers or submit a bug report. Is there a standard place on Hackage or in ghc-pkg where one can find that info?

Yes. It does not compile on my Mavericks machine. Same with every graphics package I've tried.

On a related note: The article (quite reasonably) avoids discussion of the graphics library, but I want to know more about that side of things. I wish graphics got more attention in the Haskell ecosystem in general.

The options right now are pretty dismal. There is quite literally not a single Haskell graphics or GUI package that I've been able to install on OS X. I'd love to use Haskell to build games or desktop GUI apps, but without a library for OpenGL, windowing, etc., it's not practical.

This isn't just whining, though. I bring this up to ask: What can I, as a relatively green Haskell developer, do to improve the situation? Is there a realistic path for a new Haskell user to get involved in the package ecosystem?

I'd be willing to bet that a great many developers like me wanted to try Haskell, but gave up when they found out how many Cabal packages don't compile. I think fixing that would do a lot for Haskell's mainstream acceptance.

I think the package ecosystem is a big barrier. I code on OS X, and it seems like half the Haskell packages I try to install fail to compile. I always get super motivated to do my next project in Haskell, but then give up when I can't install the required libraries. Maybe the situation is better on Linux.

In any case, I think Haskell will need reliable package management on at least OS X and Linux before most developers consider it a serious choice for real projects.

I think the parent comment is saying that 1Password would record the rules per site, not maintain a global list of rules that satisfies all sites. The latter would indeed yield an empty set, as some sites require a special character and some require no special characters.

Along similar lines, I've wondered whether an enterprising scientist could glamorize the search for null results by deliberately targeting previously published papers. So you don't just formulate random hypotheses, test them, and then report the null hypothesis. Instead, you pick out an influential paper and debunk it experimentally. I presume you'd consider suspiciousness when choosing your targets. E.g. a p-value just under 0.05 would be one signal you'd consider.

If journals like dramatic submissions, perhaps mythbuting previous papers would provide the requisite drama. Scientists out there, how do you think that would go over with journals?

But it's not a binary choice between a) excluding everyone without LinkedIn and b) spending an infinite amount on search. Surely, there are affordable ways to evaluate engineering candidates other than their LinkedIn profiles. For example, looking at resumes alone is often sufficient to exclude 90% of applicants, simply because 90% of applicants list no relevant skills or experience.

Well yes, all of those criteria are bad business, if taken as absolutes. They can all be factors, for sure. But as absolute requirements, they just weed out good candidates.

> I have come to the conclusion that most companies don't give a shit about candidates as long as they are getting enough. Hell, even some companies that bitch and moan about "talent shortages" seem to have their own Pareto principle bullshit getting in their way.

It sounds like a lot of the companies you've encountered have embraced irrational business practices. That can definitely happen. I'm not convinced it's the norm, though. And I'm sure that it shouldn't be.

:) To devil's advocate myself, though:

Where does this logic end? On the extreme end of the spectrum, we can agree that a doctor who skips the disinfectant is categorically a bad hire. But what about less extreme cases? Where do we draw the line? What about a developer who doesn't use version control? Or who doesn't use automated tests? What if they do use those things, but within those genres, they've chosen tools you happen to despise?

So I think it's tricky to know which products should be considered mandatory for quality hires.

That being said, I still stand by my comment on LinkedIn. The more debatable examples I gave above are tools that directly affect the quality and efficiency of a developer's work. LinkedIn is not, and that's a pretty big distinction.

Oh absolutely, if it delivers value to you in those ways, by all means use it. I don't think it would help me personally in that regard, but if it did, I might reconsider.

I suspect that LinkedIn is more useful to some people than others. And that's fine. Most products are like that. My comment above was really just arguing against the idea that LinkedIn usage somehow correlates with the quality of a candidate.

> I have a lot of resumes to scan and this metric works most of the time.

Works in what sense? Does it reliably help you make the best hires? Are you sure? (I hypothesize that it does not, and you might not even know it.)

Yes, every hiring manager has lots of resumes to scan. But I wouldn't consider that a logical justification for establishing an arbitrary criterion that's likely to weed out some of the very best candidates. (As others have stated, there anecdotally appears to be a trend wherein the very best don't bother with LinkedIn.)

> why would you hire a web developer that didn't have their own domain?

As stated in my other comments, I'm in the not-Linked-In camp. But still, I must take issue with the above. I happen to own a number of domain names, but I don't have a personal site at the moment. That's simply because I don't need one. At the moment, I successfully rely on other signals of my trustworthiness as an engineer.

When would I want to create a personal site? If I worked on many small projects for many small clients, I'd constantly be in a sales cycle, so I'd have a personal site for that purpose.

So in answer your question: "why would you hire a web developer that didn't have their own domain?" I'd hire such a web developer if she were qualified, quite simply. If she lacked a personal site because she had to practical reason to create one, I wouldn't hold that against her. I'd think it reflected well on her judgment of priorities.

> I assume you're either very junior, shady, or clueless, and none of those is good.

I'm quite certain I'm none of those things. I'm gainfully employed and well-respected. Yet I'm not on LinkedIn. Why? Because I prefer to minimize my social media footprint, because I've heard a lot of things about LinkedIn that rub me the wrong way, and because I don't see a clear value proposition.

So no, my absence from LinkedIn has nothing to do with me being a bad candidate for a job. If you assume it does, you miss out on a good hire.

I think any statement of the form "a person who doesn't use product X is necessarily a bad candidate" is absurd, unless product X is something like disinfectant and the job is something like doctor.

I have to wonder if he was thinking about, for example, a reusable implementation of a hash table. And if we was, why in the world wouldn't he want that. Running with the hash table example: I use them many, many times a day, and if I had to reimplement them every time, I'd be sunk. Just a few moments ago, I wrote a script to check for duplicate entries that looked something like this:

  seen = {}
  elements.each do |element|
    if seen[element]
      raise "Duplicate element: #{element.inspect}"
    end
    seen[element] = true
  end

It's quick and dirty and isn't a shining example of architecture. But it found my duplicates and let me move on with my day. But what if I didn't have a reusable hash implementation to lean on? Would I even have attempted to write that script? Or would I have done my duplicate checking manually, wasting about an hour?

> and not also the existence of a database with the right schema, the ability to connect to it

I like testing those things on which my model depends. It gives me much more confidence. Why wouldn't I want to test them?

> as well as the correctness of the code that rolls back any side effects.

That's a drawback. No arguments from me on that one.

> Doctors rejected hand washing for a long time because there was no theory behind why it would improve patient care

The germ theory of disease and experiments supporting the theory predate medical sanitation. (Pasteur's work did come after, but he wasn't the first.) The medical community's initial rejection of handwashing was not due to a scientifically motivated demand for a sound theory. Rather, it was due in large part to doctors' unwillingness to believe that they were the ones spreading disease from patient to patient. Additionally, the medical community at the time did not embrace the scientific method to the extent that it does today. Had it, handwashing would have been evaluated in a controlled study and proven effective.

It's a valid question. The article takes the following premise: Parapsychology gets positive results following the scientific method as defined by prevailing norms in the scientific community. So why can't we draw the conclusion that parapsychology is as legitimate as other branches of science? What is to separate it?

I would offer a pseudo-Bayesian[1] answer to that question. Parapsychology aims to prove hypotheses that lacks theoretical foundations. Our current understanding of physics and biology weigh strongly against the existence of psychic phenomena. Even before any experiment is conducted, we must admit that psychic phenomena are unlikely to exist. Our experimental results must be evaluated in light of that prior probability.

Thus, parapsychology is and should be held to a higher burden of proof than other branches of science. We should demand more rigorous experimental designs, stronger effects, and smaller p values. This XKCD presents a similar idea, if you substitute "psychic phenomena exist" for "the sun has gone nova":

http://www.explainxkcd.com/wiki/index.php?title=1132:_Freque...

[1] I say "pseudo" because I'm not a statistician by trade. I'm basing my argument on my rather superficial understanding of Bayesian statistics. I still think it's a valid argument in its own right, but I don't claim that it's an accurate representation of Bayesian statistics.

> It's pretty easy to get burned going either direction

Quite true, though I'd argue that YAGNI is still true as a probabilistic maxim. You'll make the "will I need it" decision many thousands of times in your career. If you follow YAGNI consistently[1], it will help you more often than it hurts, and you'll come out ahead in the long run.

[1] But nobody is saying you should ignore concrete evidence that you will need something later. That's its own cargo cult. If there's good reason to believe YAGNI doesn't apply in a particular case, don't follow it in that case.

> there is a benefit to default values, and that's a unified design throughout the web.

If only browsers provided better defaults. As it stands, very few people would consider the browser defaults acceptable.

> it's no surprise Wikipedia uses black text on a white background with blue hyperlinks

Yes, Wikipedia does use black text, a white background, and blue links. But they do not merely rely upon the default browser stylesheets. They use custom font-face, font-size, line-height, and margin properties even for the basic <p> tag. And that's saying nothing about all the other elements that often have borders, padding, backgrounds, and so on.

Yep. Namely: typeface, font size, line height, margins, font color, background color. Those are some pretty basic properties you'll want to set for even the most minimal design. CSS is how you set them. (I suspect that almost nobody would want to use the browser defaults for all these values.)

> Certainly it's crummy and dishonest

For those of us who are less familiar with dsploit, can you explain why it's crummy and dishonest? All I know about it I got from reading the project's summary just now. Ostensibly, it's a penetration testing tool. Penetration testing is a legitimate and necessary part of security auditing.

Can the tools and knowledge of the security industry be exploited by malicious attackers? Of course it can. But as the theory goes, blackhats are going to use the best available attacks regardless of whether whitehats publicize their tools and knowledge. Thus, it's better for legitimate developers to learn how to penetration test, share their tools, and spread knowledge of the exploits far and wide, so that legitimate developers the world over may know their enemy and better defend against attacks.

Is there reason to believe dsploit is anything more nefarious than a legitimate penetration testing tool?