> Specialization is productive and efficient [...]
... When the solution fits inside the lines of a particular specialty; otherwise, you need a different specialist, and knowing which one is not at all trivial. From time to time, the solution doesn’t fit within any established lines, in which case you’ll never find it at all this way.
Which is why the commonly expressed sentiment that domain experts should stick to their domains of expertise drives me up the wall. Especially the experts in question are scientists and the specific lines can be ... less than well established, to put it mildly.
That is not to say there aren’t plenty of examples of people being wrong outside their domain, but that’s not even a problem. Being confidently wrong would be one. Unfortunately, that’s not how the incentives are set in most places.
The fact is we need both. A team of generalists and specialists should be able to achieve far more than one or another. Specialists have deep domain knowledge and experience, but at the same time they are "standing too close to the elephant". Generalists, especially those that have shallower experience but over a wide range of different domains can provide a framework of analogies that can bridge the gap between domains.
This may be right for a big distributed open source project or something, but most things I work on are proprietary within companies, and in that case it's easy to just pick something better and standardize on that. My current company is pretty much standardized on yaml, which isn't my favorite, but it's fine and better than json and we don't argue about it much. Things get serialized to json pretty often, but most stuff that is checked in and intended to be human readable is not json. A different company could easily pick cue or whatever else and it would work just as well.
I think this is a neglected point. For application config, the scope over which standardisation pays off is smaller than for data. It can be company-sized. Or language-sized - if all Ruby library use YAML, that's great for Rubyists; if all Java apps use properties files, that's, believe it nor not, pretty great for Java programmers.
The world is starting to realize most people's job are not that complicated, including high standing positions, and that on top of this, a huge number of workers are not that great at their job.
Well, yes, the world runs on average. Its runs on meh.
Unfortunately, I don't think it's a problem with Python as an organization, but rather an artifact of the popularity of Python and the legal protection it now must muster.
We have support for duckdb (and CSVs and Parquet through duckdb). We don't support python, but some people have also told us they have used evidence as the front-end for a python project - used python to do data transformation and calculations, then dumped the results into a duckdb file in an evidence project and built the visuals and narrative in evidence.
"Containerized" approaches with evidence are also quite interesting - lets you combine several tools and use evidence as the last mile. Here's a great example: https://github.com/matsonj/nba-monte-carlo
I did not know this. Is it for theft prevention, or more like a deterrent to e.g. would-be clandestine arms manufacturers. I'm aware CNC machines can be quite pricey, but they otherwise seem like an impractical target for theives. At least a tractor has wheels.
this is what Microsoft is trying with Office 365 GPT approach, where they are siphoning training data from every company and offering graphs and summaries in return
I tend to see people wanting to optimize for one or the other, and that they they even manage to tie it to politics and morality.