SayWhatIMean

You may be a racist.

Parens turn out to be an asset, not a drawback to the language. Allowing macros. Tooling like lispy/paredit takes advantage of the parens too.

Ty for the share.

I think diff is OK as a verification check after a deployment. But diff is not OK to generate the change script itself.

It's not about abusing the diff. It's about diff being fundamentally the wrong technique to transition from state (C)urrent -> (T)arget.

A diff cannot always bring you to the desired T. The diff only factors in 2 states (C and T) and not X,Y,Z which you may have an import from and which may need to occur during a transitional state before T is reached.

It doesn't factor the desired state T may not even exist to diff against if developers move forward adding objects not for this release. It makes things easier on web developers at the expense of deployments.

Which "scales" better? Migration tools scale better at letting web-devs free wheel in the DB.

For bullet proof deployments migration tools don't scale. They excel at the simple cases but hit a hard limit.

BTW any details on what kind of data in production broke a deployment? Heads up to avoid it myself.

Migration frameworks superior? No way.

Migration frameworks work on diffing dev with a copy of the deployment target. This is inferior. If you rename a table it may drop the table losing all data, then create a new one. It has no way of knowing a rename from 2 unrelated tables. It includes junk/testing objects that should never pollute proudction.

Hope your bank is not using one of these migration frameworks.

Nubmered scripts are the way to go. With a strict policy to never update a script, only create new ones. You're modifying state, so you must capture ordered steps that moved you from state 1 -> 2. This will avoid a host of subtle issues. After a release you can create a backup as a baseline for the next set of scripts to run against.

Nice becuase you can get SQL syntax highlighting.

Lisp is honestly the best language you can choose assuming you know it well and have mastered the tooling. And it can be much faster than other dynamic languages like python or ruby.

But your focus on the language over the product is wrong. Google built their empire on crusty old boring C++. No fancy live interactive coding. Language only makes you happy. The product makes the user happy.

Wikipedia says engineering's original meaning is from latin:

  >meaning "cleverness" and ingeniare
  >meaning "tocontrive, devise"