mping

Google doesn't need you to pay, they only need you to do your thing using Android, Chrome, Google Analytics, Google Search, Google Maps, etc. They will monetize on your usage. I'm OK with the concept, but the implementation ethics can be, to put it gently, debatable - most of the time people are not aware of the privacy implications.

This is not a simple problem. Language barrier alone will prevent people from going to Austria, never mind the weather.

My own experience is the opposite. My son learned to use a balance bike since 2 years old, a couple of weeks before his 3rd birthday we got a regular bike, on the same night we ran alongside him riding his bike grabbing his jacket in case he fell. He started riding the same night.

This is obviously not a competition, but the faster your kid learns the more fun they will have. If you are ok with training wheels that's fine too.

You miss the point. Using the style attribute everywhere causes duplication; using css classes can quickly lead to bloat where you have lots of unused classes.

This is a way of paying only for what you actually use.

Well the immutability hype allowed the author to build the previous incantions of the library. At this point, I hoped everyone understood the tradeoffs of using abstractions. Otherwise we should all be programming on assembly.

ORMs are different from SQL generators; an eg: typesafe sql generator can be a great thing; the problem is mapping sql results (wWhich are basically rows of data) to Objects. Objects have identity, but an SQL row can be anything, even if most of the time it's a full row from a table with a primary key.

As an example, if you do a query for Object o but with partial fields, and later you query for same object but full fields, are they the same object? SQL doesn't care, but in application code you need to ensure they are the "same", because objects will flow in between functions and if you eg: do o.setAge(30), you want both of the live objects to reflect that (for the same transaction).

It's a hard problem with lots of compromises or rules, and I think most people are better off just with a query api.

The way I learned is that you try not to meddle unless you have wisdom (meaning you have some kind of enlightenment). My opinion is that unless I was the one tormenting other beings, I wouldn't meddle in other person's affairs, specially by killing. This is a good example on the importance of finding a teacher, a Good Knowing Advisor, someone that can dispel these doubts for you.

There's the obvious self-defense exceptions, if a lion or a person would attack me or my family I would shoot him, but an enlightened being may act differently because they may understand something we don't.

This is correct; the "no kill" rule is something you aim for, it doesn't mean you necessarily achieve it. In Mahayana Buddhism there's a story about the Buddha's prior lives, where he decided to kill someone out of compassion: the victim wanted to murder a lot of people, but the future-Buddha killed him to avoid his suffering [1]. Likewise, the Buddhist precepts are training rules, not necessarily commandments that will take you to hell if you break them.

[1] http://venyifa.blogspot.com/2008/09/story-of-compassionate-s...

IIUC it means they should at least be killed in a more "humane" way, instead of being boiled alive.

Most comments here are probably from people that never meditated. You can be hooked on something like an app for meditation, and yet while meditating you can be detached from that. While you form a habit you can use tricks to get the habit to stick, we do it all the time with children.

If you measure success by active users I doubt it will become popular but the meditation habit can absolutely be families until it becomes natural.

A data lake is a system designed for ingesting, and possibly transforming lots of data, a "lake" where you dump your data. This is different from an eg postgres db (a single source of truth for a crud app for example), because it captures more data (eg events) and it's normally not consistent with the single source of truth (the data may arrive in batches, imported from other database, etc). Because the volume of data is normally huge, you need a cluster to store it, and some way of querying it.

Snowflake and data bricks are companies that operate in this space, providing ways to ingest, transform and analyze large volumes of data.

Excellent point. I would add there is a hidden dimension that is defined subjectively by the programmer (eg static vs dynamic) which means that there is probably multiple ways to define "simple" (depending on the user's taste), but still I feel lisps hit s local maximum in terms of language design.

Sure, people could write books before the printed press, but guess what? You lower the barrier to entry and stuff happens. If the LAPD declares it an epidemic, isn't that good reason to be at least slightly alarmed?

You can have monads in clojure (eg: http://funcool.github.io/cats/latest/#monad) but the problem I see is that they are infectious and kinda force you to use them everywhere. In other languages, it's more palatable because the compiler checks for types, and normally there is some sugar to make it easier on the eyes. Besides, I think monads are a bit off the clojure way, even if they happen to exist somehow (eg promesa and manifold libraries).

In my opinion, science has no tools to verify life after death, regardless of what one believes. Besides, the onus of (dis)proving life after death is for the individual, not for the religious group. Most of them already have their systems set up.

My understanding is that Buddhism doesn't say that you "stand before judgment", but instead explain what is the process of life and death, cause and effect, that was observed through the eyes of superior individuals who cultivated and developed great concentration and wisdom.

We all know how the carbon tax ended.

This is crazy. You suggest that if AWS changes billing somehow, his startup should shoulder the cost? If you don't trust it don't use it.

Rust wants to be the new C without C warts, using the compiler to ensure memory safety (up to a point), promoting immutability and having generics baked in.

I'm not a C programmer, but I think Rust can fit almost everywhere C can fit.

If vaccines bring hospitalizations down they are already a win. The percentage doesn't say much about the number of hospitalizations. In a country where lots of people are vaccinated, I would expect lots of vaccinated people in the hospital too. Like others said, it also depends on the cohort (age, vulnerability, etc.).

Where should one get the other side? Genuinely interested

In Mahayana tradition, there are many many Arhats (not only in the Mahayana but in the Hinayana too), and some Bodhisattvas, even today. Of course, they don't announce it but they were certified by Patriarchs.

You imply that the bulk of the costs are labour costs, but medical invoices in the US suggest otherwise.

Can't uuids be time based?

There was an SQL layer but performance was sub-par IIRC. There was also a blog post somewhere explaining why it's probably not a good idea to build an SQL layer on top of a KV store, devil in details, etc.

Edit: found it https://www.voltdb.com/blog/2015/04/foundationdbs-lesson-fas...

Not sure what to think of it, I'm not a DB expert by any means but the post sounds plausible enough and the SQL layer is discontinued AFAIK. I guess with each new abstraction layer you leave some perf on the table.

This is what I imagine experienced clojure developers can squeeze out of a language like clojure. I would venture that they can train a junior programmer in a couple of weeks, and make them productive very fast.

I guess they could make it work in any language but judging by the description clojure is indeed a great fit, due to the macro capabilities, flexibility and solid runtime via JVM.

Surprisingly, there are already integrations in my home country; I took a look at tink [1] some time ago (no affiliation whatsoever) and they look legit. I'm sure there are more SaaS like them.

[1] https://docs.tink.com/market-capabilities/aggregation

I would love if clojure had a solid gradual typing story just as ta has. There is core.typed library but I haven't tried nor is it widely employed.

However I think its a valid trade-off, and with sufficient experience you learn to navigate the issues just like in JavaScript.

If you have the chance to work with a team, you can get proficient in a couple of weeks. What you don't know right now is probably how the glue code for a cljs project works (eg shadow-cljs) and the core library.

It's a trade-off, you trade certainty of types validated by the java compiler that comes with alot of ceremony with conciseness and agility provided by the repl, the downside being you need to ensure the result via tests and discipline.

Source code quality and developer ergonomics are somewhat subjective, so its natural different people have different opinions.

Personally, I quite like the clojure tradeoffs.

Although I agree with you in principle, in practice most of js devs never worry about such things. It's mostly library authors and such. And there are cases where a != a, I think for NaN (not a number).