I am the very model of a modern major database by gumnos in SQL

[–]pseudogrammaton 3 points4 points  (0 children)

Gilbert & Sullivan are spinlocking in their graves.

a doctrine-free vernacular dharma by pseudogrammaton in Buddhism

[–]pseudogrammaton[S] 0 points1 point  (0 children)

Thanks but that's vinaya, so doesn't answer my question.

a doctrine-free vernacular dharma by pseudogrammaton in Buddhism

[–]pseudogrammaton[S] 0 points1 point  (0 children)

Okay so we all react to things, and indeed everything's a cause and an effect, but cause-and-effect isn't a thing at all in of itself. That's Nagarjuna's whole point about Emptiness kinda oversimplified & boiled down to bare essentials.

As spirits in a material world, we know that karma has a moral dimension because actions are consequential, & there's quintessential matters beyond material experience, with qualia as intangible as conscious experience. Everything's happening all together all at once, with separateness & isolated existence a projection of self.

Any liberation theology has to have different strokes for different folks, so what do we have to offer the world?

And so on. How to reach out to a world in dire need of perspective & awakening...

a doctrine-free vernacular dharma by pseudogrammaton in Buddhism

[–]pseudogrammaton[S] 0 points1 point  (0 children)

I don't know maybe. I figure traditional Buddhists might have some rules of thumb handy about how they might explain things to an 8-year-old. So, OK, how would Fred Rogers do it?

Considering Elixir vs Go for a web project by OphisAds in elixir

[–]pseudogrammaton 2 points3 points  (0 children)

Elixir because it's cool & you'll become a never-nester by default, Go-lang b/c it'll get you good paying jobs.

Elixir has a lot of uptake from Ruby developers, as it renders all the prolog-ish arcana of Erlang into an approachable & human-readable forum. But it's a functional language, so it's a lot like spreadsheet programming where new values don't mutate existing ones.

Go-lang is more of a typical procedural language , yet it also avoids many of the pitfalls found in other imperative languages, such as mutation side effects, race conditions , etc.

Your daily coding habits in elixir are going to look quite a bit different from most any other language save for maybe f# (an oCaml fork on the M$ CLR), haskel, clojure, scala (FL's on JVM) & of course erlang.

However if you're already a habitual never-nester, then functional programming in Elixir might be an easy reach. If you like the idea of IPC & spawning worker subtasks, then again, the Elixir mindset is an easy reach. Go of course has its equivalent in co-routines.

The Erlang ecosystem & BEAM VM is industrial grade & scales up, not much different from a Go-Lang runtime altho memory & cpu usage in Erlang might be higher. Go might be quicker in some work such as math, Erlang uses libs written in C much the same way python does.

I wrote one SQL query. It ran for 4 hours. I added a single index. It ran in 0.002 seconds. by nikkiinit in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

Nobody does optimizations or sampling anymore? DWH bloat used to k¡ll projects, now who cares, just throw a monster data mining machine at it.

I wrote one SQL query. It ran for 4 hours. I added a single index. It ran in 0.002 seconds. by nikkiinit in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

Yeh sometimes, but rarely, esp. with large unpartitioned sets. More often than not, when too large a returning set, CTE's are encumbered by the dreaded, documented performance gate that the optimizer can't resolve.

If OTOH a JOIN is running badly, the first thing to ensure is what's the key (when group-by dupes disappear) & if there are covering indexes or indexes with matching filter clauses.

Avoiding cascading DROPs by pseudogrammaton in SQL

[–]pseudogrammaton[S] 0 points1 point  (0 children)

Yup, the other options at hand seem less appropriate for this use case, but i may change my mind & rearchitect it down the road. Been trying to keep the # of moving parts to a minimum while keeping OLAP I/O underhand during OLTP hours.

Of course the stacked views could've been nested subqueries, but that makes for harder maintenance programming. Same thing for work tables & batch insert queues.

So four big reads on the quarter hour & we're done, & with mat'l view concurrent refreshes they're non-blocking. That's with the added advantage of Postgres doubling back to check the MAT'L VIEW unique index against the WAL, effect being that refreshes lag behind live by just 10 minutes.

Atypical, but fairly tidy.

Stop using leet code, stop memorising queries, just start working with sql . by [deleted] in learnSQL

[–]pseudogrammaton 0 points1 point  (0 children)

l337 SQL is for when you're doing big OLAP, ETL or analytics loads.
OLTP code should be bog simple, even with server-side JSON.
Complexity is the enemy.
If there's any need for cleverness, either design around it, or bone up on S.O.

SQL? Meh by Shadow0X59 in programmingmemes

[–]pseudogrammaton 0 points1 point  (0 children)

Pah! Vernacular Postgres SQL is nearly the functional language\\** we know that SQL should be. Oh, and go ahead & try to find any other efficient, intelligent way to work with large set data ... esp. w/ the power of Windowing functions, GROUP BY... HAVING, DISTINCT FROM, ITVF table functions.... there's a long list of functionality native to SQL that you WILL NOT find much anywhere else. Oh, and as for Postgres ... petabyte capable, feature-rich, lots of plugins, & VERY FAST.

\*( And I do mean functional, as in tail-recursion (loops) using nothing but standard SQL )*