In that case it's the regional "Guitar Center" or "Yamaha Music School" or whatever that provides (i) a marketplace that also lends credibility to the instruction and (ii) scaling via group lessons and as a result take a cut from the pie.
1,299 karma · joined April 11, 2010
In many developed nations, this definition would comprise a large majority of the population, and some people who would be considered poor on relative terms there (i.e. make less than half the average income) would comfortably fit into this definition of a global middle class.
Maybe they just did a sensible assessment of the options.
- Is there a risk in being dependent on an SaaS business that may rise prices or go out of business? Yes, definitely
- Are sheet metal shops in a position for upfront investments in an asset that will be useful in the long term? Yes, definitely, and more so than an enterprise customer who'll just expend a 200$/mo charge on the company credit card
- Are sheet metal shops used to taking care of business-critical assets? Yes, definitely
Much of today's SaaS software is based on the premise that people can buy it without permission from the higher-ups because
- the monthly charge is low enough to escape scrutiny
- the function of the software is not business-critical enough that lock-in is a problem or it looks cool enough to the CEO and the alternative is something clearly inferior (nothing, or Excel Macros)
Once you move out of the enterprise/startup space into structures which function differently (and it's not that they are "fighting change", it's just that they're built on different foundations), you need to check these assumptions.
but using Python throughout, or even Python with a sprinkling of Cython/C++/C for performance, allows for cleaner and faster engineering than using a special language for each niche.
I don't think that R has a bigger problem with non-programmers being bad software engineers than Python has - there are plenty of people who know Python passably and are quite happy that they can be productive without being good software engineers (versus Java where the intent of the language is biased for everyone to write code with a minimum quality standard rather than everyone to write code with focus on being productive). But you can find decent Python software engineers, and more recently you can find decent software engineers who also know enough of the niche in question to produce high-quality production code in that niche from the get-go rather than throwing models over a data science - engineering wall that exists between two departments.
I'd say that all of these are factors that don't add or detract from the value of the paper itself - it's a "hey I tried this and it works ok despite not going in the obvious direction". So, limited experiments but IMO competently done and with usable information.
It's a pity that all papers nowadays have a gazillion authors, from well-funded research labs, with as-dry-as-possible language that hides the real research behind a "we knew this all along rather than figuring it out along the way" facade. OTOH that's what you get in a large fairly mature research field, where most competent people get hired by research labs and then do lots of collaborative research that scales well and subsequently need to show publication counts to secure further funding.
as in: people will continue to suffer for about a decade while good alternatives readily spring up but suffer slow adoption?
I think what mostly kills the appeal is 1) The actual keywords in the language are not that many (<50) and have a technical meaning where knowing English is only of limited help. 2) Much of what we do today uses library of code from others, where either you limit your audience by using non-English function (and/or class) names or you use English function names and hope that everyone will understand them to the necessary degree.
All of these factors contributed to Scala adopters like LinkedIn subsequently retracing their steps and doing new development only in Java.
So, academic origins are fine (many good programming languages have academic or at least research-influenced origins), but an academic attitude to the development work that a language should support (predictability of breaking changes, possibility of good IDE support) harms the adoption of a language.
> We polled our users and asked them what they would be willing do donate and the average was twenty seven dollars, and of course we have thousands of users
Which is based on the illusion that you get an unbiased sample when you ask users to respond to a poll. You don't - the people most likely to sacrifice a moment of their time are also those more likely to come forward with money, conversely those who didn't fill out the questionnaire probably have a majority of people who won't give any money.
These threads and those threads are not the same. The 16-threads SMT processor will happily chew on 16 different programs, processes or whatever the load at the moment is, e.g. if you use Python's multiprocessing you can create 16 processes and they'll be executed in parallel.
fork() can handle multiple threads but you have to be attentive when cleaning up etc. - quite often, code using fork() will get confused when you spawn threads, and code using threads will get confused when you fork()
Free Software ideology (yes, it is one) also won't tell you how to make the lives of those people better who - for whatever good or bad reason - can't tinker themselves out of their problems. Which is mostly everyone. In that sense, teaching them about Free Software instead of about ethics is a similarly bad idea as wanting to teach people Christianity instead of ethics. Christian and Free Software culture give you some start when it comes to ethics, but can't replace ethical considerations themselves.
In general, yes. If you call something an Open Source project, however you take on certain responsabilities that you wouldn't otherwise have, such as not playing bait-and-switch, and can hope for people sending in bug fixes and patches (and even signing copyright assignments if required for dual licensing).
If it were just "doing things for free" and not receiving anything in return, FOSS would not interest anyone and we'd get back to the shareware world of the 90s where (as a user) you got an evaluation license but no stake. Some developers prefer the shareware model to going full OSS, which is fine. Playing bait-and-switch by turning an Open Source project (with the community and the help and credibility that potentially come out of it) into a Shareware product will, like any bait-and-switch, irritate people.
this seems to be aggravated by zoning laws and NIMBYism in the US where localities will not tolerate high-density housing that is an eyesore but provides little homes to people who'd otherwise not have one (or have to pay higher prices than they otherwise would)
And the answer is that the faculty selection process is - for art history as much as for other faculties - skewed towards a narrow sub-demographic that is predominantly white and male from a well-to-do background. If you call that discrimination I'll agree with you, but it's not a kind of discrimination that would be specific to either art history or computer science.
Even if you look outside Stanford https://art.vassar.edu/bios/ you can see a definite difference in gender distribution between adjuncts (poorly paid, mostly female) and full professors (mostly male).
At least in Germany, this is being changed by rules that give female applicants preferential treatment when there are (as is common) more male than female applicants for a professorship, and at least in female-dominated courses of studies we now see more female professors.
So we seem to have gender (+other, less visible) discrimination in many cases where managers, professors and other roles are selected in a competitive manner. And we have ways to change this if universities and private enterprise play along. But this has nothing to do with females not choosing CS as a major, and it has nothing to do with females not entering programmer jobs.
Motivation goes beyond "being interested" in something. If you ask why there aren't more men studying art history it would be rather silly to say that men are less interested in art history. Then again, if you said that men don't pursue art history because they (most often) wouldn't be able to sustain a family on an art historian salary - and are expected to do so, while women find it appealing because appreciating art and understanding social and political undercurrents is more important than earning potential to them. (I don't know many art historians but see here for an example: https://www.pomona.edu/academics/departments/art-history/why...)
We could also ask why art history is not a candidate for "new collar jobs" (i.e., having people with associate-level degrees in art history) or why we don't have art history bootcamps for men. Part of the answer is that - at least since GC languages and Ruby on Rails - we do have good uses for people with shallow CS knowledge, or at least that there are less people interested in erecting high barriers of entry. The answer to that is that CS is thought of as skills-based and shallow, another aspect that is more likely to dissuade (especially white middle-class) women from pursuing a 100% CS career while it will help pull in people combining domain expertise with at least some CS skills.
> Only when the job became prestigious were they pushed out by men. I clearly recall the days when programming was thought as the domain of the pimple-faced nerds with the thick glasses, way before the brogrammers and other "cool" nerd types came along. Law and medicine are all more prestigious and by your reasoning would have pushed out women even more. So there's something you're missing, and actively missing it even when reality waves its hand to you.
Just one google query gives something more nuanced, such as this: https://austinstartups.com/the-tech-gender-gap-a-2016-progre... which rightly points out that the percentage of women was rising in CS as much as in medical and law until around 1985. And if you look at the graphic here https://blogs.sas.com/content/sascp/2018/12/05/booming-enrol... you notice that it's not women leaving the field, it's more men coming to CS while the number of women stays the same until they leave in troves at the following bust cycle.
You keep using evidence from the 50s (i.e., 70 years back) as explanation of today's state of affairs, but the evidence points that the 50s don't tell us anything about why we don't have more women programmers. Instead, ask why women got pushed away by post-bubble insecurity and maybe (and this is interpretation) some stigma that we as CS people have that pushes out women.
You explain with discrimination (which was real in the 50s according to most evidence we have) what is in parent's case better explained as a difference in motivation (making a five-figure salary by being responsible for humans is more attractive to the average US woman than being responsible for modules of code is).
Your secretarial school figure is a strawman to make the parent post look like a strawman. There's a legitimate discussion to be had on why women nowadays are found in a higher proportion in medical school and to law school than to CS, and there is a multitude of reasons that are more plausible than purely discrimination. Let's start to tease them apart without merely stopping at the clichés.
which would be a thing unheard of if we were still in 1993. We aren't, and you find people happily using iOS or Android devices that do mostly web browsing and video watching and would functionally be a toy or a paperweight if you transported them back to 1993.
Computing has changed in the last 25 years. Paradoxically, more people are using FOSS than before while fewer would subscribe to the kind of Free Software purism (totalitarism?) that the FSF advocates. Windows running a (GNU/)Linux subsystem is a victory of Open Source, but a defeat for the Free Software movement.
Which brings us to
> if they align practically or philosophically with the FOSS movement
and I'd call this a ruse - the Open Source movement developed as a countercurrent to FSF's ideology around Free Software mostly in the shape of people that liked Free Software (both as in Freedom and as in Beer) as well as software licensed under more liberal licenses but did not see the idea of Copyleft as central to their enterprise. There is a FOSS movement, replete with sympathisers and drama and everything around it, but it's at best a strict superset of the Free Software movement that also contains people with non-FSF-compatible opinions.
Many common points exist - showing your reasoning and evidence rather than to appeal to authority, and the idea that hypotheses should be falsifialbe (in the sense of Thomas Kuhn) to be central ideas. Both of these very good idea in all situations in which you're actually interested in the truth, rather than having a shoot-first-ask-questions-later situation where you need to act on imperfect information.
There's no disaster waiting to happen, at least not in comparison to other tools of reasoning being misused. Sophism (i.e. people playing mind games to make their claims look better) exists inside and outside of science, just as self-interest and wanting to increase your own sphere of influence do, but that's no fault of the scientific method (any more than it is a fault of religion when it occurs there). Any system that lends credibility and authority to people will (loosely mis-citing Bourdieu) attract power-mongery.
It's the (now-)unsavoury point of platform businesses, who step into the business relation between a user and a service provider to mine and aggregate and profile data to provide value in a surveillance economy. Would this even fly in GDPR-land, where you can only process data within the narrow confines of the actual business relationship?