dhd415

I thought Gates' take on the human relational aspects of AI to be thoughtful, but I am surprised that his analysis on the economic and jobs aspect of AI offers little more than the party line. Every other technological advance that improved productivity (Industrial Revolution, etc.) has resulted in the loss of some jobs but the creation of jobs in other areas and an overall increase in the standard of living (although admittedly not uniformly distributed across the population). Why will AI be different?

This question is orthogonal to the question of whether ABA accreditation is beneficial.

My longest employment stint was at such a company and it was a very good experience for me. That said, even though I worked at such a company for a while, I don't have a very good idea how I would go about identifying other such companies with open roles. Any suggestions on how to do that?

Organizations such as the ACLU and the American Red Cross are registered organizations and I doubt you'd advocate for restricting or redefining their civil rights. Perhaps you'd draw the line at for-profit organizations, but that doesn't make it better. Should Ben & Jerry's or Patagonia or other corporations with notable positions on social issues not enjoy the protection of civil rights from those who oppose them?

The bottom line is that any restriction or redefinition of civil rights is fraught with negative unintended consequences. It should be an option chosen with extreme care.

There are certainly legitimate concerns about the influence of Amazon and other large corporations, but the solution is not so simple as what you suggest. Corporations are associations of people, so you are advocating for civil rights for individuals up until they associate with others and act or speak collectively. That would be radically detrimental to the meaning of civil rights.

I've found my moderately-priced Eaton 5S 1500 unit to perform considerably better than any of the non-pro APC models I used before it.

This. I finally switched from using various APC models to an Eaton 5S 1500 unit for my desktop and a couple peripherals and it's much better while still being comparably priced.

I would say that infrequently used tools are an especially good choice for battery-powered cordless tools when the alternative is typically a tool powered by a gas small engine. For example, I need a chainsaw for infrequent jobs, but every time I ran it, I'd have to fiddle with the carb and the spark plugs, throw out old gas, make a new gas/oil mix, etc., so it was a major pain and I'd use it only if I really, really needed it. I replaced it with a 36v Makita chainsaw and it's a breeze to use every time.

This is most definitely true, but I think it highlights the mistaken idea that individual healthcare is a commodity. I think we all recognize that an excellent home builder, auto mechanic, attorney, software developer, etc., can have an outsized impact on the outcome of potentially severe or expensive situation but we often put less effort into finding a healthcare provider for a particular malady. I've had some severe negative outcomes from questionably competent, focused-on-billing doctors where I would have been better off not seeing a doctor at all than seeing them. Unfortunately, there's no reliable way to separate the truly skilled doctors from the ones who barely passed their boards.

Their X Compact line of phones was great with high-end SoCs and incredible battery life but unfortunately, they haven't released any new phones in that line for several years so they're pretty dated now.

Doesn't appear to be available yet for Chrome in the Chrome Web Store or for Android in the Google Play Store, either. :(

Taking this approach to using a database is always a judgement call, but putting logic in the database is probably useful a lot more often than the "nine times out of ten" that the article claims. And the tradeoff in this approach contradicts the last line in the article: "Utilize the full extent of your database’s capabilities, but don’t put domain logic in it." Putting logic in your database is often necessary to make full use of its capabilities.

In applications with complex storage needs and/or performance-sensitive IO needs, I prefer to think about databases as an additional tier that provides complex storage services (as is precisely the case with most modern databases). As an example, I once worked on message routing and transformation server. From the perspective of the application logic, messages simply needed to be durably persisted and retrieved. At the level of the storage layer, I wanted message versioning, provenance, copy-on-write semantics to minimize on-disk size, and indexes to support at least two different retrieval patterns. All of the items at the storage layer were implemented in stored procedures. In other words, the database supplied a custom "storage API" to the business logic tier for persisting and retrieving messages that implemented those routines in a database-specific way that did not concern developers at the application layer.

The main arguments against this approach are:

* It will tie you to a specific database. This is true, but almost irrelevant since anything other than the most trivial usage of a database will inevitably make use of a feature or syntax specific to the database that would require modification were one to migrate to another database. Further, the mere idea of database independence is kinda' silly. No one talks about how writing your application layer in one particular programming language will limit the ability to migrate to another programming language. We should make technology choices around programming languages, databases, etc. with the intention of matching their strengths to the problem at hand fully understanding that tradeoffs are being made and that rework will be necessary if those choices are ever revisited.

* SQL used for writing stored procedures is not as good (for some definition of "good") as other programming languages used in the application layer. SQL is certainly different than most imperative or functional programming languages, but it's expressive and well-suited for its purpose. If you really need to make use of the capabilities of a database, it would behoove you to develop some proficiency in SQL.

* Putting logic in the database breaks modern CI/CD processes. IMO, this is the most compelling argument against it. That said, there is tooling that exists for putting stored procedure and other database logic in version control, automatically deploying it to a database, and running tests on it. These tools are not as commonly used, but they do exist. I've also used tooling that introspected the database objects such as stored procedures, etc., and automatically generated type-safe application code to interact with those database objects. That provided compile-time guarantees that application and database code were in sync at least with respect to number and types of arguments, etc. Whether it makes sense to go to the effort of integrating this tooling into your development process is a judgement call, but it can be done and I've seen it work well for application with demanding database needs.