I don't know what to make of this. Honestly, where I'm from (Canada), depending on the circle, it feels like hugs are nearly a social norm, even between people who've just been acquainted.
For myself, I like MacPorts better than Homebrew because in my experience it's subject to less breakage, less flaky interaction with tools like rvm or python, and has a better project philosophy overall. And I personally like that it's not in Ruby but I understand the opposing opinion too ;)
I like this, but I feel it's a little optimistic (or pessimistic depending on your view). Isn't asking ML researchers when AI will dominate human performance a bit like asking a barber if you need a haircut?
I'm trying to see the analogy ... if I ask a barber if I need a hair cut and they say "Of course you do." they may be lying because they want the $15 (well, I'm bald so ...)
How does the ML researcher gain from lying "In year X" if they don't believe that to be true? It's a tenuous connection.
Ha, that's fair, I take your point. I was being a little glib. I didn't mean to suggest conscious malice on the barber's part -- only that the barber may be incented to provide more haircuts than are strictly necessary.
Perhaps the analogy works better if the barber is a friendly, honest person, who takes professional umbrage when they see other people with longer hair :)
One aspect of qualification is domain knowledge, which experts certainly have. Another aspect of qualification is calibration, which can only be proved & adjusted over time with a track record. A number of academic studies of prediction markets and other forecasting systems have shown that well-calibrated non-experts, with no skin in the game, often do better than actual experts, who often have poor track records as a result of incentives (or selection) to hype and extremize.[1]
Philip Tetlock has written on this topic for years. Two of his books are Expert Political Judgment and Superforecasting.
Edit: So to directly answer your question, rather than AI experts, I'd prefer technology experts (AI or otherwise) with a track record of well-calibrated predictions.
A historian of science, business professor, or futurist, might provide perspective on when people automating previous trades estimated they'd be automated; how long until they were; how long previous innovations spent in various stages of translation; and how this compares to what is known so far about the AI pipeline.
It has less to do with title than systematized knowledge of models, but people with those titles are more likely to have invested in acquiring this knowledge and these models.
Perhaps labour economists, demographers, or sociologists?
I don't believe ML researchers are unqualified -- it's more of a potential incentive problem. I don't think it's unreasonable to suggest that people involved with / employed by a technology may have a tendency to exaggerate its benefits.
Ideally I'd trust the numbers here more if there was at least a cross-section of knowledgeable people being surveyed across a few different disciplines (or at least more than one).
Wow, that's a very cogent and intelligent response.
What does the superhi...way have to do with online learning specifically? Even if you paid a consultant to tell you otherwise, it's still not the greatest name ..
A lot of brand names have vague or no references to what they do – Apple, Nike, Google, Heroku – we had a few other initial names that were like "Craft" and "Tailor" but didn't really work for us. We tried the more obvious ones and our customers didn't like them.
I'm still happy with the name two years later though and still love our branding. With the name we could use it in a few ways to make it more about learning... "learn the SuperHi way", "SuperHi school", etc.
We're also a bootstrapped company, so zero investment available for spending $$$ on a domain name. In the end, we went with what felt right for us and what our customers liked.
I would echo another comment here and say that it depends. However (speaking from my own perspective) depending on the discipline there's no specific need to do a PhD in order to understand and apply machine learning.
It also depends on what you mean by "advanced degree". I have an undergraduate degree in physics/math and a master's in economics/finance, and I find between those two things I've been able to follow developments in machine learning and also to apply them to my work. In fact, I used to get a bit annoyed with those who would imply that I "must" do a PhD ... I would say that's certainly true if I wanted to invent new estimators etc., but otherwise not so much. A PhD can be great for other reasons but it's not the sort of thing required for actually doing my job.
I agree with you and also with the person you replied to. But more generally -- is it fair to say that cardinality describes size as opposed to quantity? If you go with the quantity concept instead then 1-based numbering makes sense and agrees with ordinary usage.
(Disclaimer: I used to hate 1-based indexing, for reasons similar to what you are saying, but I'm brainwashed by R these days and now rather like it.)
> is it fair to say that cardinality describes size as opposed to quantity?
Nope, size is equivalent to quantity in this context. But ordinals describe position in an order as opposed to size/quantity. If you want to connect them mathematically, you would usually map a scale to a quantity measure, where the first unit position on the scale is the zero-position, the second unit position is the one-position, and so on--so, a quantity of size three units reaches from the position 0 on the scale to the position 3 on the scale.
> (Disclaimer: I used to hate 1-based indexing, for reasons similar to what you are saying, but I'm brainwashed by R these days and now rather like it.)
Well, it doesn't matter unless you have to to arithmetic with the indices, you might as well label them with letters from the alphabet, so if you don't need that, it's simply a matter of getting used to it. But in general-purpose programming languages, array indices are often computed, and 1-based indexing is as sensible there are having an integer type that doesn't have a zero. It's not that you cannot work with it, but it makes things unnecessarily complicated.
Ugh, ugh, ugh.
I just tried Homebrew for the third time the other day and it made a complete mess of my /usr/local/bin and also screwed up my install of rvm ... never again will I give it a chance. Sorry, but IMO Homebrew is crufty, opinionated software with poor separation of concerns. Macports is the (objectively?) better choice for my needs.
In that case you might be glad to hear that in v1.0.0:
> Homebrew’s default repository installation location changed to /usr/local/Homebrew to keep your /usr/local cleaner
Personally, I really like Homebrew and have never had problems (c.f. MacPorts which gave me big problems a few years ago), but I don't use /usr/local for much else, so that's probably why.
Heh, fair enough and thank you, good to know :) Maybe in another year or two my frustration will have abated somewhat. Don't get me wrong, I think it's great that the devs recognized using /usr/local/bin was a bad decision (even if they were kind of forced to because of Apple's SIP).
However -- I just remember, when Homebrew was getting started, all the supercilious (dare I say arrogant?) advice in the docs ... oh, just install to /usr/local, "seriously", etc. (Looking for a reference in archive.org right now ...) Even their whole "Macports driving you to drink?" thing rubbed me the wrong way -- maybe I'm humour-deficient, but I think to criticize another project when your alternative isn't clearly better is just bad taste.
That being said, I am genuinely curious: is there any one awesome thing is that Homebrew does that Macports can't do? Or better, what kind of problems arise from using Macports? I recognize that packaging in Ruby is probably more convenient than in TCL, but other than that? It seems to me that Homebrew is just getting closer to what Macports did (correctly) in the first place. The only way Macports has ever inconvenienced me is requiring a fresh install from time to time when Apple updates their OS, which (for my use case) is minor.
MacPorts isn't without problems, but I can't use Homebrew. Just the message that is printed when you `brew install texlive` is a deal breaker. I don't want to manage packages separately from my package manager, that's crazy and defeats the purpose of a package manager.
I still use MacPorts and I am quite happy with it -- although I've tried to switch away a couple of times, I can't bring myself to uninstall a piece of software that's worked so reliably and faithfully for me over the years.
Maybe it's just that Homebrew turned me off right away. Back in the bad old days, when the Python 2/3 split was more serious than it is now, I had a heck of a time trying to get pandas and scipy running with Homebrew. I haven't given it a try lately so perhaps things are better now.
(I am probably also the kind of person where all the hectoring the Homebrew docs would do about installing to /usr/local eventually got on my nerves ... )
That being said, I don't use MacPorts versions of things like TeX or Ruby (I prefer MacTeX and plain old rvm).
I use macports but I am not happy about having to install full blown XCode in order to install macports in order to install (insert trivial, minor package here).
Has this changed ?
I am basing this on my experience of both Snow Leopard and Mavericks ... and in those cases, I had to download and install XCode. Further, this is (I suppose) more a criticism of OSX and how it does not include basic tools ...
xcode-select --install on the CLI has been available since Mavericks (I think) and will install the CLI build tools without need to install the multi-gigabyte Xcode. I don't personally use macports, but that command should pretty much solve your issue.
I don't consider installing Xcode to be an unreasonable thing to do to - consider that 70+% of the people who buy a mac have no need for the compilers or system libraries. So it doesn't seem unreasonable to me - I mean, my debian box doesn't come with any of the devtools installed - and its a couple gigs of software to install.
