I can't say I know much about AI stuff or BEAM. But my best guess is that elixir native ML should integrate well with OTP's distributed computing capabilities. As an outsider to the elixir ecosystem, I've seen glimpses of elixir ML here and there but no mention of attempting to bridge the python ML ecosystem into elixir.
I said design an intelligence test that a good chunck of humans wouldn't also fail.
I'm sorry to tell you this but there are many humans that would fail your test. Even otherwise healthy humans could fail your test nevermind Anterograde Amnesia, Dementia etc patients
You think that if we told the average fifth grader in america that they must remember something that is VERY IMPORTANT a week later, and then had them do, say, a book report on a brand new book, and then asked them the very important fact, a 'good chunk' would fail?
Lol yes. People will fail. Any amoumt is enough to show your test is clearly not one of general intelligence unless you believe not all humans fit the bill.
Is it a matter of not finding the problems solved by LAMP/js frameworks interesting? Or in the cases where you solve the same issues as the frameworks, are you not finding the upsides of using frameworks compelling enough to justify learning them enough to become more productive?
I have a few difficulties working on ordinary web CRUD apps:
1. I'm really bad at memorizing things, I'm better at memorizing principles. Which makes most APIs like Rails and Django difficult for me. This is probably why I ended up writing my own SSG where everything is just a Node.js import, even HTML is (via JSX, via my own lightweight runtime).
2. I'm really bad at accepting doing things the wrong way when the right way is so much better and obviously so. For example, I struggle to force myself to use EJS or any traditional express-compatible templating engine. This is also why I wrote my own on-top-of-node runtime with JSX support.
Could be worded better but I would interpret it as "No web development skills required to start developing web apps entirely in R/Python". You're still expected to learn web development but within the context of an R/Python environment
Text-based interfaces still have the same issue with being able to make a typo or tab completing without checking. Seems like the major advantage is that these text based tools are able to be versioned well through scripts. This might be fixed with a GUI version of autohotkey, turning these gui interactions into a script.
Mandated peer review, planned actions, and automated risk evaluation are part of our infra pipeline. This typically doesn't exist outside of software dev style pipeline.
I was about to disagree but the automated risk evaluation (ARE) part definitely qualifies your whole statement. Going to go off on a tangent: how do we introduce automated risk evaluation to environments outside of software development. Implementing ARE as software is probably the most efficient method in terms of time and resources. But ideally (some) users of ARE should be able to improve on it. In the case of "traditional" engineering (civil/electrical/chemical etc.) there are engineers who specialize in numerical methods and can improve on ARE. But what about professions where software development skills are not as widespread (or seen as a legitimate contribution to the field). There are still probably going to be members of these professions with software development abilities but is there a point where other methods could be considered (i.e. electrical/mechanical methods) for ARE implementations.
Platforms such as Etsy, Gumroad and ironically Substack are significantly (if not totally) targeted towards the long tail. An argument can be made that these platforms are not successful enough to justify serving the long tail, but the author started the article with concern for counterculture and then ties widespread financial success as a metric for healthy countercultures. A better metric would be the amount of viable lifestyle businesses operating within cultural niches but no data on this is present within the article.
The author makes several references to a consulting project where they also state that serving niches is not viable, this is probably true for whatever client was looking to branch into this. With the provided examples, the article reads as a defense of those previous findings.
You can model passive circuits with RLC ordinary differential equations (depending on the setup of the equations there's some algorithms such as Runge Kutta to solve them numerically). Afaik you can model some active components with ordinary differential equations, but I wouldn't be surprised if you had to resort to partial differential equations (More or less a "complete" electromagnetic simulation at that point).
The water molecules aren't chemically bonded to the ions, but they are "bonded" by intermolecular forces. Although weaker than a chemical (intramolecular) bond, the intermolecular forces are still strong enough to "bond" water molecules to the ion. So either only water molecules not "bonded" to ions can pass through these channels, or the pressure differential across the channel can free the water molecules from the ions.
It’s force per area so it’s definitely a pressure, the difference is just that the driving mechanism is chemical potential instead of a difference in number of particles.
Tough a system put into contact with a resevoir of a constant concentration should try to increase in volume until the concentrations on both sides are equal.
It's probably the 'constant concentration' part that is confounding the two. It is connecting number of particles with volume, whereas the canonical ensemble has them as separate terms.
That's part of the issue in research though, you don't know what will have value. The actual problems that particle/nuclear physicists attempt to solve might not be valuable but the engineering required for the experimental apparatus could be revolutionary.
